Idea Orbiter Common Register

[Kozak]

Just read the "Orbiter Forum Space Station" thread and thought a thousandth time how good will it be to have a MMORPG-like multiplayer engine for Orbtier. Such a thing, unfortunately, will require core rewriting or extensive support from addon makers - both requirements seem unlikely to be satisfied in close perspective.

However, Artlav's dynamic satellites addon proved that the main concepts are not impossible. So, while a full multiplayer engine looks like being a quite scaled task, we can look forward for something a little less ambitious. So I've decided to express my ideas here - maybe someone will get inspired by it and we'll get one step closer to a integrated multi-pilot environment.
As a (hobby) developer and a software engineer, I know, how difficult it is to work without a clean task. So, this idea is formulated like a "requirements specification" for a programmer - so, if one will want to realize it, he will have a clear plan to start with.

So - let's wrap up with lyrics and go straight to dry descriptions.

Orbiter Common Register concept

Main objective:
To create a common vessel and base environment.

Components:

• (My)SQL database
• standalone or PHP/ASP server
• administration interface
• client Orbiter plugin

Also, 2-5 administrators are needed.

Client requirements:
- a common set of station components (e.g. Greg Burch's "Space Station Building Blocks 4.0") and other addons (like Dansteph's Prelude base)

System work may be split into 2 main modes:
Mode 1.Download

The SQL database is a central point of the system. Here are stored:

• Logins/passwords
• User groups
• Station data. Precisely:
  1. Type, name and orbit elements
  2. Creation MJD
  3. Owner group
• Transaction (vessel creation/destruction) log

A server, which is run on the same or separate machine, serves requests from clients. On request, it gives out a full list of currently launched at current client MJD stations and satellites (see below).

On Orbiter startup, the plugin connects to the server and downloads the information about launched stations and satellites, and then repeats the request on a regular basis - e.g. every year of game time. Only stations that 1.are present at current MJD 2.are present in client addons are taken into account. So, for example:
- If you fly an Atlantis in 2000AD, you'll not see a new station, built in 2145
- If you take a two-year (sim-time, of course ) ride in Vespucci-class ship to Saturn, starting in 2144, you'll get a nice surprise when back - a shiny year-ago built station
Also, the client plugin should make its own cahce of data, so if the connection is not available, the player still gets an enjoyable environment.

Mode 2.Upload
More complex part.
When a VSA wants to create a space station, it should make a request to administrator. He will add a dummy module with given parameters to the database. Then, the VSA may begin to assemble the station. The process is as follows:

1. a VSA authorized pilot logs in to the system. (see below)
2. The pilot flies to the station and installs a module.
3. After that he opens the plugin window and tells to add a module XXX, docked to dock #Z of module YYY, to the database

Then the following occur:

• Server checks if YYY belongs to that user group
• Server checks if YYY's dock #Z is free
• If everything is right, the server adds the new module XXX, owned by the VSA to the DB. Voila!..

So, the client plugin should have (in a window opened by Ctrl+F4):
- Login window
- Refresh Now button (with a 3 minute delay timer to avoid DoS)
- "Add component..." menu, active only when logged in.
- "Delete component" menu.

The transaction log should help if a "saboteur" of one of groups maliciously deletes a VSA's property or fills the database with random vessels.

Waiting for comments.

 

[Face]

Orbiter Common Register conept

Interesting concept.

On Orbiter startup, the plugin connects to the server and downloads the information about launched stations and satellites, and then repeats the request on a regular basis - e.g. every year of game time. Only stations that 1.are present at current MJD 2.are present in client addons are taken into account. So, for example:
- If you fly an Atlantis in 2000AD, you'll not see a new station, built in 2145
- If you take a two-year (sim-time, of course ) ride in Vespucci-class ship to Saturn, starting in 2144, you'll get a nice surprise when back - a shiny year-ago built station

The problem I see with this idea is this: you have to deal with 2 independent timelines - simulated and real. If you started the Vespucci tour yesterday and get back today, you may still see nothing, because the other folks will add the year-ago station tomorrow. If someone else takes the tour the day after tomorrow, he'll get the experience you described. You need to enforce causality to avoid such a "glitch in the matrix".

A second problem I can see is collisions. What if someone runs a mission to extend a station with module XXX on port 1, but another one tries the same with module YYY on port 1. Will the slower one be punished with a "request denied"? In combination with the "time travel" problem described above, this could get even worse.

That said, I'm looking forward to a proof-of-concept, since the "persistent-universe" concept with multiple timelines is one of OMPs goals. Would be interesting to see such a system in action...

regards,
Face

 

[Kozak]

The whole point of the conept is adding some static scenery, which, however, will carry a mark of somone's work. And the point is to keep is as simple as possible.

The problem I see with this idea is this: you have to deal with 2 independent timelines - simulated and real. If you started the Vespucci tour yesterday and get back today, you may still see nothing, because the other folks will add the year-ago station tomorrow. If someone else takes the tour the day after tomorrow, he'll get the experience you described. You need to enforce causality to avoid such a "glitch in the matrix".

In such situations one should forget about game MJD and think of the plugin as a real-time station exchange tool. Station building MJD is only a guarantee that you'll not see ISS at 1400AD. All the conflicts are resolved based on real time.

A second problem I can see is collisions. What if someone runs a mission to extend a station with module XXX on port 1, but another one tries the same with module YYY on port 1. Will the slower one be punished with a "request denied"? In combination with the "time travel" problem described above, this could get even worse.

The player should get an error message, update the data, then attach the module to a different spot or abandon it. The MJD, again, does not count - so, e.g., if one carries a module "NewOne" at 2105 game year, but earlier than another who tries to attach a "NewTwo" at 2104G.T. - "NewOne" will be the module installed. System works in real time.

I'd gladly begin to develop this project, if someone will join it - due to lack of experience in programming server applications, I'll manage only client part.