Brainstorming for a MultiUser OXP

[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!

... if memory serves, the file does a very good job of sorting itself out as far as loading and listing are concerned.

Correct!

[hiran]

Be sure that your entry in .GNUstepDefaults looks exactly like the following and it should work.

Code: Select all

"always-flush-cache" = yes;

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.

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?

[hiran]

I think shipDockedWithStation is what you’re looking for.

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?

[phkb]

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.

[hiran]

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.

[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.

[hiran]

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.

[cim]

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.

[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

[Cholmondely]

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.

[hiran]

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.

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.

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

Jupp, that is something that could work.
I will give it a try - it will just take time...

[hiran]

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.

[hiran]

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

[hiran]

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...

[hiran]

I am one step further now, and it seems the technical hurdle on Oolite is taken.

- 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...