Oolite Bulletins

I've had a bit of an idea. I'm posting it now cos if I don't I'll never stop fettling with it. I think it's a fairly workable idea but it will need some work to the core application in order to be feasible. My problem is that I really think this idea has legs but haven't got the time or the ability to look into it myself so would be relying on others. So, here goes.

Proposal Overview

Oolite save game file contains

• - player name
  - ship type
  - current location
  - hyperspace targeted location
  - combat rating
  - legal status

Why not use this information to automate the generation of other player ships in the local player's "Ooxperience"?

Suggested Architecture

Modifications to Oolite Core application

• - plist/XML file containing connection information to remote server (File1)
  - specification and scope to read to and write from file1
  - code change to send player save game information to this server
  - code change to read remote player information from the server to a plist/xml file (file 2)

Remote requirements

• - one live web server to store database or file (SQLite or MySQL?)

OXP requirements

• - link to plist/XML file containing connection information to remote server (file 1)
  - process what remote players are in the local player's system
  - parse remote player ships that are present and load suitable model(s)
  - contain special rules for each remote player (although this could be stored on the server along with the basic information)
  - on saving a game (or similar key point), local player's latest save game data is uploaded to the central server specified in file1
  - on hyperspace countdown, remote player information is downloaded from the server and stored in file2
  - on hyperspace exit, information from file2 is read, and if any remote players are in the local system their information is loaded in and a ship generated for them. They would be simply located on the normal path between witchpoint beacon and station.

Notes

1. The local player's save information can be uploaded on game save or during hyperspace countdown.

2. Only one save game per remote player would be actively parsed, based on the most recent filestamp. The OXP could contain functionality to omit player information older than a certain age. Code to check for multiple player files from the same player could be implemented too (IP address stored in database maybe?). This would stop players uploading loads of player information and spamming the spacelanes (whether deliberately or accidentally) – only one "pilot" at a time would be used from any one player.

3. The remote player information can be checked at various points to update file2. The points could include:

• - docking
  - launching
  - hyperspace egress / exit
  - saving game
  - loading game

4. If a remote player is using an OXP or customised ship, the system can check that the relevant OXP is present on the user's computer and if not can either:

• - find and install the relevant OXP from a repository (wiki, oosat etc)
  take the information from the remote player's computer (with the user's consent obtained via an option in the Settings)
  - find an alternative or similar ship from those installed.

Risk Management

We would need to establish

• - if this functionality can be included through Oolite code modifications and OXP development – developers would be best placed to answer this.
  - How long it would take to download and upload the player information and thus where the load/save routine would be best placed for minimum game interruption
  - Could the upload/download routine be done in the background as play progresses?
  - Settings required for privacy – players may not want to be part of the commoonity, or opt in or out when they want.
  - Regarding note 4 above, there would be a need to prevent faulty code permeating the commoonity via any downloaded OXPs if that functionality was included. if players have in-development code on their OOlite installs, then this requirement is more important. Of course, this functionality could be controlled by the settings as well.

Wohoo, the idea is wonderful!

Really neat idea. Another thought that might go with it could perhaps be a sort of bulletin board or email system one could check for message when docked at a station. Short messages or replies to messages could possibly be downloaded and uploaded at that time, or ignored if the player is in a hurry or whatever. That way it wouldn't intrude badly on gameplay.

But the main idea you have would be a really neat addition to the Personalities OXP, Selezen.

The only security issue would be SQL squirting, but most coders these days are savvy enough to prevent that.

Do any developers have an opinion on the doability of this idea?

IIRC Ahruman has stated very clearly that Oolite will never be given the ability to read or write anything apart from save files and log files.

Nice idea, Selezen. I have some points/issues though.

Notes 2: "Only one save game per remote player would be actively parsed, based on the most recent filestamp." I have test/development save games it doesn't make sense to include them. Nor does it for backup save files Also it is likely I have multiple save games where I am completely in different locations so I would be jumping about if I played each save game alternatively.

Notes 4: a) "find and install the relevant OXP from a repository (wiki, oosat etc)" would be an absolute no-no for security reasons never mind that we don't have a mechanism for auto install of OXPs. That concept was mooted a while back and some work was done on it but not completed. If it existed I wouldn't want Oolite to install any OXP without my say so, after all it could be part of an OXP that adds features I don't want. The additional issue is that Oolite doesn't support installing an OXP on the fly and it would rather hard to add.
b) "take the information from the remote player's computer (with the user's consent obtained via an option in the Settings)" is another complete no-no for obvious security reasons.
c) "find an alternative or similar ship from those installed." is tricky as what rules would apply for a finding similar ship type.
A more sensible idea is for the player registered with this to create a list of ships that is stored on the server in preference order with the last having to be a native Oolite ship.

Risk Management:
a) "if this functionality can be included through Oolite code modifications and OXP development." From my knowledge of the code alone I can see that this would have to involve core changes.
d) "Settings required for privacy – players may not want to be part of the commoonity, or opt in or out when they want." This would have to be an opt in system. Oolite isn't Facebook.

Other issues/points
There is the time aspect. Your date/time could be years different from mine, but I assume you only want to do this idea in the first place is to give a bit more realistic feel for NPC behaviour and add flavour, so this is probably unimportant.

If I kill a player (s)he would need to be removed from the list of pilots appearing otherwise it doesn't make sense.

Who would be running this server and service for free?

Regards,

PG

Selezen wrote:

The only security issue would be SQL squirting, but most coders these days are savvy enough to prevent that.

Do any developers have an opinion on the doability of this idea?

There are many, many more security issues: once you can write something directly to disk, you can potentially write anything to disk, and potentially execute it... batch/shell scripts are amazingly powerful, and new attack vectors have been discovered at an alarming rate for the last 10-15 years...

Darn. All bad news for this idea then. Security is more of an issue than I thought, obviously. My thoughts were that since the I/O controls would be wrapped within the software itself, limitations could be put in place for the file types that can be uploaded. If the program itself says "only ASCII file types with the extension oolite.save can be parsed" then that would be a hard and fast rule.

Are there any ways around the issues or is it a case of "no means no and stop arguing"?

@PG: since my web hosting is unlimited bandwidth, I'd be more than happy to host the server end.

Also, other player deaths would be handled the same way as local player deaths - escape pod and "miraculous recovery". The time differences are irrelevant, as it's not a true multiplayer experience - more of a pseudo-multiplayer facade. Oolite isn't going to be multiplayer, but somehting like this idea would give a more dynamic experience of other people's presence in the game with minimal administration for the player or an OXP developer (such as the Personalities OXP which relies on the player making the information available and then the OXP manager creating the update).

Selezen wrote:

Are there any ways around the issues or is it a case of "no means no and stop arguing"?

It is possible that I would accept a clearly-written, well-documented, cross-platform patch to optionally enable networking behaviour along the lines you describe. I have absolutely no interest in implementing it myself.

Great! Well, hope springs eternal!! Thanks, Ahruman.

Does anyone have the Objective-C knowledge to attempt this?

i could probably provide a functional specification, but a tech spec would be outside my ability.

Anyone fancy collaborating?