Page 3 of 8
Re: Brainstorming for a MultiUser OXP
Posted: Sun Jun 20, 2021 1:11 pm
by Cody
The
.GNUstepDefaults file is very fussy - get something wrong, or miss a semi-colon, and it will overwrite itself to the default.
If you're tinkering with the
.GNUstepDefaults file, always make a back-up first - and take care!
Nite Owl wrote: ↑Sun Jun 20, 2021 12:58 pm... if memory serves, the file does a very good job of sorting itself out as far as loading and listing are concerned.
Correct!
Re: Brainstorming for a MultiUser OXP
Posted: Sun Jun 20, 2021 1:40 pm
by hiran
Nite Owl wrote: ↑Sun Jun 20, 2021 12:58 pm
Be sure that your entry in .GNUstepDefaults looks exactly like the following and it should work.
The entry should be near the bottom of the file grouped with several other settings.
If Oolite is that picky I am already busted. My .GNUstepDefaults file has XML syntax, so I cannot take your example as verbatim.
Nite Owl wrote: ↑Sun Jun 20, 2021 12:58 pm
If the entry does look exactly like the above but it is still not being written to the file on a permanent basis then only one other possibility occurs to me. Does the folder/location of the .GNUstepDefaults file have writable permissions enabled?
Now this sounds strange. Who is supposed to write the file?
I take it that Oolite uses it to remember settings. My modifications should occur when Oolite is not running. Otherwise Oolite will read on startup and write on shutdown.
Now what happens if I have wrong settings? I take it they will not be used by Oolite and then forgotten when writing out the file on shutdown. But would I get ever some acknowledgement that the setting has been parsed and accepted by Oolite? Some message in the logfile maybe?
Or is it intentional that I have to place that value into the file before every startup?
Re: Brainstorming for a MultiUser OXP
Posted: Mon Jun 21, 2021 11:27 am
by hiran
hiran wrote: ↑Sat Jun 19, 2021 6:54 am
phkb wrote: ↑Sat Jun 19, 2021 12:00 am
Actually I was playing around with that one. A 'Hello world' message to the logfile was successful, a 'HTTP GET' request so far not.
But let's assume the EcmaScript Engine is not limited and thus can run networking code, and one day I have the data transfer running.
I think I am stuck. Regardless whether I try to create a URL object, some XMLHttpRequest object or just call the global method fetch, I get ReferenceErrors in the logfile:
Code: Select all
JavaScript exception (AllTogether 0.2): ReferenceError: fetch is not defined
Does anyone have an example how to access some online resource from a JavaScript event handler?
Re: Brainstorming for a MultiUser OXP
Posted: Mon Jun 21, 2021 11:54 am
by phkb
hiran wrote: ↑Mon Jun 21, 2021 11:27 am
Does anyone have an example how to access some online resource from a JavaScript event handler?
I’m not sure if the entire JavaScript model has been set up in the scripting model available in Oolite. I’ll have to have a look through the source code to confirm though.
Re: Brainstorming for a MultiUser OXP
Posted: Tue Jun 22, 2021 6:27 am
by hiran
phkb wrote: ↑Mon Jun 21, 2021 11:54 am
hiran wrote: ↑Mon Jun 21, 2021 11:27 am
Does anyone have an example how to access some online resource from a JavaScript event handler?
I’m not sure if the entire JavaScript model has been set up in the scripting model available in Oolite. I’ll have to have a look through the source code to confirm though.
This is a real showstopper. So I'd be very happy if you could check that out for me.
Re: Brainstorming for a MultiUser OXP
Posted: Tue Jun 22, 2021 11:40 am
by thecoredump
That's why I thought more about a 2 oxps plugin :
- the first on containing only the "galaxy update", a config file describing events
- and the second, requiring the first, containing the scripts to giving life to those events
And then the player only have to frequently update the first OXP.
But it needs some sort of "Game Master" to update the first OXP.
Re: Brainstorming for a MultiUser OXP
Posted: Tue Jun 22, 2021 1:30 pm
by hiran
thecoredump wrote: ↑Tue Jun 22, 2021 11:40 am
That's why I thought more about a 2 oxps plugin :
- the first on containing only the "galaxy update", a config file describing events
- and the second, requiring the first, containing the scripts to giving life to those events
And then the player only have to frequently update the first OXP.
But it needs some sort of "Game Master" to update the first OXP.
How would you implement the frequent updates? Is that left to the second OXP (which does not resolve the problem at all), or the user to fire off the expansion manager? Cholmondeley is one among probably many users who does not want to be forced into updates...
Also be aware we already are going for a compromise as multiplayer Oolite seems not technically feasible.
So the architecture I am suggesting is that players can 'meet' and 'interact' at least when meeting in the station, also allowing them to pursue a common mission (whatever that mission might be).
Now what you suggest is a reasonable higher dynamic on the current missions but I'd be missing the interaction completely. In my eyes it would no longer reach the gist I was after. Which does not mean there is no value. Compared to the static missions Oolite offers till date it would still be revolutionary.
Re: Brainstorming for a MultiUser OXP
Posted: Wed Jun 23, 2021 7:13 am
by cim
phkb wrote: ↑Mon Jun 21, 2021 11:54 am
hiran wrote: ↑Mon Jun 21, 2021 11:27 am
Does anyone have an example how to access some online resource from a JavaScript event handler?
I’m not sure if the entire JavaScript model has been set up in the scripting model available in Oolite. I’ll have to have a look through the source code to confirm though.
Correct - a lot of what people think of as the Javascript "standard library" is more of a consequence of the most common interpreter being a web browser which has its own set of additional standards. fetch() etc doesn't exist in Node.js either - there, you use the http class to make connections. Network support was never implemented in Oolite, and neither was any of the XML/HTML parsing stuff for much the same reason.
What you would need to do - and it would only work in a debug build, but that's not a massive drawback in practice - is:
1) The debug console connects to Oolite over a loopback TCP connection. It can run JS commands to both read and write data.
2) From Oolite's point of view, there's nothing special about the debug console - any application could implement that protocol.
3) So you'd write a separate app (in whatever language you liked) which connected to Oolite on one side using the debug protocol, and the server on the other with whatever protocol you wanted, and relayed information between the two.
Re: Brainstorming for a MultiUser OXP
Posted: Wed Jun 23, 2021 7:38 am
by another_commander
If you are going to go the way of writing your own app for communication with Oolite, then understanding the console protocol will probably be helpful. Here is some related information:
http://wiki.alioth.net/index.php/Oolite ... P_protocol
Re: Brainstorming for a MultiUser OXP
Posted: Wed Jun 23, 2021 9:00 am
by Cholmondely
hiran wrote: ↑Tue Jun 15, 2021 10:29 am
Somehow when flying in my own, self-hosted Ooniverse it feels a bit lonely.
Just to say, this sort of thing it not my cup of tea, but since you are trying to do something different, I'd like to support... so if you ever do get it off the ground I will want to participate and give it a try.
Re: Brainstorming for a MultiUser OXP
Posted: Wed Jun 23, 2021 6:32 pm
by hiran
cim wrote: ↑Wed Jun 23, 2021 7:13 am
phkb wrote: ↑Mon Jun 21, 2021 11:54 am
I’m not sure if the entire JavaScript model has been set up in the scripting model available in Oolite. I’ll have to have a look through the source code to confirm though.
Correct - a lot of what people think of as the Javascript "standard library" is more of a consequence of the most common interpreter being a web browser which has its own set of additional standards. fetch() etc doesn't exist in Node.js either - there, you use the http class to make connections. Network support was never implemented in Oolite, and neither was any of the XML/HTML parsing stuff for much the same reason.
That is sad but I understand at the time of integrating the JavaScript engine noone thought of my use case.
In Node.js it is possible to
add libraries for network access. I guess this is not possible with Oolite.
cim wrote: ↑Wed Jun 23, 2021 7:13 am
What you would need to do - and it would only work in a debug build, but that's not a massive drawback in practice - is:
1) The debug console connects to Oolite over a loopback TCP connection. It can run JS commands to both read and write data.
2) From Oolite's point of view, there's nothing special about the debug console - any application could implement that protocol.
3) So you'd write a separate app (in whatever language you liked) which connected to Oolite on one side using the debug protocol, and the server on the other with whatever protocol you wanted, and relayed information between the two.
Hmmm. That is a completely different approach. More stuff to implement - but in the end a lot more powerful.
I even suspect this interface could help in
Dual monitors / fullscreen mode
if the 'debug console' just opened another window to display HUD information.
Jupp, that is something that could work.
I will give it a try - it will just take time...
Re: Brainstorming for a MultiUser OXP
Posted: Wed Jun 23, 2021 6:34 pm
by hiran
Cholmondely wrote: ↑Wed Jun 23, 2021 9:00 am
hiran wrote: ↑Tue Jun 15, 2021 10:29 am
Somehow when flying in my own, self-hosted Ooniverse it feels a bit lonely.
Just to say, this sort of thing it not my cup of tea, but since you are trying to do something different, I'd like to support... so if you ever do get it off the ground I will want to participate and give it a try.
Thank you for the thumbs up. I will definitely need help with this.
If it gets airborne we need to test, document, invent a story and the such. You are definitely welcome.
Re: Brainstorming for a MultiUser OXP
Posted: Fri Jun 25, 2021 3:33 am
by hiran
hiran wrote: ↑Wed Jun 23, 2021 6:32 pm
cim wrote: ↑Wed Jun 23, 2021 7:13 am
What you would need to do - and it would only work in a debug build, but that's not a massive drawback in practice - is:
1) The debug console connects to Oolite over a loopback TCP connection. It can run JS commands to both read and write data.
2) From Oolite's point of view, there's nothing special about the debug console - any application could implement that protocol.
3) So you'd write a separate app (in whatever language you liked) which connected to Oolite on one side using the debug protocol, and the server on the other with whatever protocol you wanted, and relayed information between the two.
Hmmm. That is a completely different approach. More stuff to implement - but in the end a lot more powerful.
I even suspect this interface could help in
Dual monitors / fullscreen mode
if the 'debug console' just opened another window to display HUD information.
I was able to install a simple TCP server that would log everything to stdout. Oolite debug version connected and the output looked somewhat usable.
I failed applying Java's XML parser (it would not like the content in the prologue) so now I am taking a look at the existing DebugConsole.
->
https://bb.oolite.space/viewtopic.php?f=3&p=277263
Re: Brainstorming for a MultiUser OXP
Posted: Sun Jun 27, 2021 10:37 pm
by hiran
cim wrote: ↑Wed Jun 23, 2021 7:13 am
What you would need to do - and it would only work in a debug build, but that's not a massive drawback in practice - is:
1) The debug console connects to Oolite over a loopback TCP connection. It can run JS commands to both read and write data.
2) From Oolite's point of view, there's nothing special about the debug console - any application could implement that protocol.
3) So you'd write a separate app (in whatever language you liked) which connected to Oolite on one side using the debug protocol, and the server on the other with whatever protocol you wanted, and relayed information between the two.
Seems like I am getting somewhere. Although I have never seen the debug console in action (but studied a bit of it's source) now I have something that
- can listen to TCP connections requested by the debug Oolite build
- accept connections and react on bytes sent
- separate the packets and parse them as plist
- show configuration in GUI as a hierarchy of variables
- show Console Output messages as a scrolling log window
There are values not communicated so far that I believe can be retrieved/modified via commands, such as
- installed OXPs
- read and modify ship cargo (manifest?)
- read and modify player's credit balance
- read and modify GNN messages, news feeds, commodity market, missions
So far I have not sent any packet to Oolite. Will try to enact the sample session at
http://wiki.alioth.net/index.php/Oolite ... transcript.
But I am also wondering whether everything that gets communicated in these nice plist packages is Strings. If I ask for a ship's loaded cargo I hope to get one good plist rather than a plist containing a string containing the cargo...
Re: Brainstorming for a MultiUser OXP
Posted: Mon Jun 28, 2021 10:13 pm
by hiran
I am one step further now, and it seems the technical hurdle on Oolite is taken.
hiran wrote: ↑Sun Jun 27, 2021 10:37 pm
- installed OXPs
- read and modify ship cargo (manifest?)
- read and modify player's credit balance
- read and modify GNN messages, news feeds, commodity market, missions
I was able to read and modify the ship's cargo as well as the player's credit balance.
I sent console and comms messages.
No clue however how to check the installed OXPs or hack into the email message system, which seems unidirectional anyway.
So I believe it makes sense to have a separate window allowing message exchange with other players. These messages can be sent directly to other players or to all players (in the same station, in the same system, in the same galaxy, in Ooniverse). Goods shipment or money transfer could be special messages. Message transfer only works while docked as the ship hooks into the station's LAN.
There is still quite something to do...