MultiPlayer Proof Of Concept: Oolite Communicator

[hiran]

Hello all,

this is not really an OXP yet it is addon functionality that you may enjoy while playeing Oolite:
Oolite Communicator. This is an early version to proove the concepts work.

The target is to combine our singular Ooniverses and allow some interaction to happen. So far it allows us to exchange messages, fuel, money or commodities.

If you are interested to evaluate, participate, and/or discuss with us, check out the downloads available at
https://app.box.com/s/6lw8q49pw7hhxnziatkipdejhu2wiaht

We have packages for Linux (tar, deb), Windows (zip) and Mac (tar). For the technically uninterested there is a Virtualbox appliance available via bittorrent.

Hiran

[Cholmondely]

Downloaded!

[Cholmondely]

Umm...

Is this one of those Russian babushka dolls?



Downloaded, clicked to unzip, and I get a folder with another one inside!

Click to unzip that, and I get another folder with yet another one inside!

Click to unzip that, and I get another folder with yet another one inside!

Et cetera, et cetera, et cetera...



I thought you were German, not Russian...


Retires in confusion, muttering and burbling incoherently

[hiran]

Umm...

Is this one of those Russian babushka dolls?



Downloaded, clicked to unzip, and I get a folder with another one inside!

Click to unzip that, and I get another folder with yet another one inside!

Click to unzip that, and I get another folder with yet another one inside!

Et cetera, et cetera, et cetera...



I thought you were German, not Russian...


Retires in confusion, muttering and burbling incoherently

You are intended to download a zip file and unzip that. That's it.

Yes, inside there is another folder with a .jar file - and technically jar files are nothing but zip folders. That's how java applicatins are packaged, and neither do I have the power or the will to change that. But you are not asked to unzip those as well. Noone will stop you from doing so however...

Instead of continually unzipping, have a look at the readme.md file...

[Cholmondely]

You are intended to download a zip file and unzip that. That's it.

Yes, inside there is another folder with a .jar file - and technically jar files are nothing but zip folders. That's how java applications are packaged, and neither do I have the power or the will to change that. But you are not asked to unzip those as well. Noone will stop you from doing so however...

Instead of continually unzipping, have a look at the readme.md file...

Apologies, I was tired and got carried away with the fervent unzipping!

I can't read the readme.md - it seems not to open or be openable on my magnificent, marvellous and mighty machine which is utterly confusticated by out-of-place semi-colons and curly brackets...

[hiran]

You are intended to download a zip file and unzip that. That's it.

Yes, inside there is another folder with a .jar file - and technically jar files are nothing but zip folders. That's how java applications are packaged, and neither do I have the power or the will to change that. But you are not asked to unzip those as well. Noone will stop you from doing so however...

Instead of continually unzipping, have a look at the readme.md file...

Apologies, I was tired and got carried away with the fervent unzipping!

I can't read the readme.md - it seems not to open or be openable on my magnificent, marvellous and mighty machine which is utterly confusticated by out-of-place semi-colons and curly brackets...

Hmmm. I chose the extension based on github/Bitbucket and other practices. Maybe I should simply name it .txt because it is nothing else.
You may open the file with any text editor.

[Cholmondely]

You are intended to download a zip file and unzip that. That's it.

Yes, inside there is another folder with a .jar file - and technically jar files are nothing but zip folders. That's how java applications are packaged, and neither do I have the power or the will to change that. But you are not asked to unzip those as well. Noone will stop you from doing so however...

Instead of continually unzipping, have a look at the readme.md file...

Apologies, I was tired and got carried away with the fervent unzipping!

I can't read the readme.md - it seems not to open or be openable on my magnificent, marvellous and mighty machine which is utterly confusticated by out-of-place semi-colons and curly brackets...

Hmmm. I chose the extension based on github/Bitbucket and other practices. Maybe I should simply name it .txt because it is nothing else.
You may open the file with any text editor.

I did exactly that and it opened without a hitch.

[hiran]

Hmmm. I chose the extension based on github/Bitbucket and other practices. Maybe I should simply name it .txt because it is nothing else.
You may open the file with any text editor.

I did exactly that and it opened without a hitch.

Ok. Future releases will contain a readme.txt file.

[hiran]

The only question would be how it could be possible to send events to OXPs via the debug console.

Create a base OXP that each player needs to have installed, which for the sake of example we'll call "CrossPlay". Inside this, you can set up a variety of variables and functions to perform all your cross-system gameplay. Then, if player A triggers something (an event that would initiate a multi-player mission, lets say), that would be triggered in their local "CrossPlay" OXP and settings would then be changed. Then, your multiplayer secondary app would poll the settings of the CrossPlay OXP and find a changed setting, which would then be sent to all other connected players. Now, everyone would have the mission/setting/etc.

That's how I imagine it would work in broad terms. As always, the devil's in the detail. For a test run on some sort of community/multi-player mission, I'd probably try for a "Collect 1000t of Computers and deliver them to X", where each player's contribution to the goal can be tracked.

Sounds great. Also the first common mission of delivering a massive amount is good.
There are two things however:
* I am no OXP developer, so I'd need some support here
* I would like to keep dependencies to specific OXPs away from the developed code

So my idea would be to have pairs of components: A central component to track/control global status, and OXPs to manage actions locally. The Oolite Communicator would then transport messages between these components but does not need to understand them. It would allow us to add/change/remove missions dynamically, and if a player has no matching OXP installed these messages would be ignored simply.

Which means we need to have a way to detect whether an OXP is installed and send messages to it. Plus we need to come up with some documentation so 'global mission developers' would know what to do.

[hiran]

The new version - if properly configured - can now start Oolite automatically.
This will knit the Communicator and Oolite further together as the user only has to start one application.

[Cholmondely]

I've downloaded both sets of goodies. Is there anything I need to do with them before our session?

[hiran]

So we tested the latest version, which is a complete rewrite and worked better than before. Of course there is room for improvement:

1) It does not feel realistic to send goods into a flying spaceship's cargo hold from distant star systems or even galaxies.
2) Incoming messages are not presented with the in-game options, which requires the Oolite Communicator window to be visible in parallel to Oolite - this is annoying

for 1), we want to change the flow: One player can deposit goods (for himself or for other players) at any station and the recipient will get an email about this. Once docked to that station, the goods can then be picked up.
for 2) Should the Oolite Communicator detect events worth communicating, it would trigger in game communication:
- other player's chat messages would end up as commsMessage
- global events would be distributed via GNN

This raises the questions:
How can a commsMessage be invoked from the Debug Console?
How can a GNN message be sent from the Debug Console?

[another_commander]

How can a commsMessage be invoked from the Debug Console?

player.commsMessage("Your message here")
If you have spoken messages set to Comms Only or On, consider also player.audioMessage("Your message here"), which will cause the message to be spoken rather than printed.

[hiran]

How can a commsMessage be invoked from the Debug Console?

player.commsMessage("Your message here")
If you have spoken messages set to Comms Only or On, consider also player.audioMessage("Your message here"), which will cause the message to be spoken rather than printed.

Nice feature!
Sending a message to the comms is working for me. However this audioMessage stuff remains silent.

So I checked my game settings, and I can see "Spoken messages: off" in grey, similar as "Voice" and "Gender". But I cannot change the values - the cursor will just skip the grey settings. What may I be missing?

[another_commander]

So I checked my game settings, and I can see "Spoken messages: off" in grey, similar as "Voice" and "Gender". But I cannot change the values - the cursor will just skip the grey settings. What may I be missing?

These options are set on a per-save basis, so they are greyed out at the intro screen menu. Once you start your game they should become accessible.