NOTE TO ADMIN: If I put this in the wrong place, feel free to move it.
Currently, OMP utilizes a form of P2P multiplayer. Given the fact that this has multiple problems in the long run (MJD calibration, data loss, network lag, etc. etc.), and the fact that Orbiter has built in physics, I believe that a form of "Passive" multiplayer would be more effective.
Basically, the theory behind passive multiplayer is that, we let the Orbiter physics engine do it's job by updating a P2S (Peer to server) database only when necessary. this prevents the "spaghetti connection" problem commonly found with P2P.
The "Passive" model uses a table style database, each column representing a single vessel, and each line representing the data required for the multilayer to work (not going into detail here, DEV's will have to figure this out). a column can be set to have a name but a null user value (used to say who is who). Making a NULL user value for a column can be used for vessels spawned by other DLLs (E.G. fairings or UCGO cargo). User spawned vessels can be set to have a user value, but have the focus value to NULL (This is obvious).
Each client will have a copy of the database stored locally, updated only when the server says there's an update. This help eliminate traffic and lets the physics engine do most of the dirty work. RCS and rockets can be updated by the same system, still letting the physics engine do all the fun stuff.
For docking and simulation accuracy reasons, when a user-focused vessel get within a certain distance of another User-focused vessel, a P2P connection is better. taking advantage of this, a P2P connection will be established between the vessels with a faster update rate, so that docking can be safe an accurate.
here's a topic that has been much debated: Time acceleration. I think that the client can "separate" from the server temporarily to time warp, as the simulation values on the database are relative to the closest planet. when the vessel comes out of time warp, the MJD re-calibrates to the server time and the relative values to the body (E.G. mars) stay the same. in short: same orbit, different date.
well, that's my two cents, I'm not going any further than that as I have my hands full already(Shuttle A MK4 and UVGCO).
Currently, OMP utilizes a form of P2P multiplayer. Given the fact that this has multiple problems in the long run (MJD calibration, data loss, network lag, etc. etc.), and the fact that Orbiter has built in physics, I believe that a form of "Passive" multiplayer would be more effective.
Basically, the theory behind passive multiplayer is that, we let the Orbiter physics engine do it's job by updating a P2S (Peer to server) database only when necessary. this prevents the "spaghetti connection" problem commonly found with P2P.
The "Passive" model uses a table style database, each column representing a single vessel, and each line representing the data required for the multilayer to work (not going into detail here, DEV's will have to figure this out). a column can be set to have a name but a null user value (used to say who is who). Making a NULL user value for a column can be used for vessels spawned by other DLLs (E.G. fairings or UCGO cargo). User spawned vessels can be set to have a user value, but have the focus value to NULL (This is obvious).
Each client will have a copy of the database stored locally, updated only when the server says there's an update. This help eliminate traffic and lets the physics engine do most of the dirty work. RCS and rockets can be updated by the same system, still letting the physics engine do all the fun stuff.
For docking and simulation accuracy reasons, when a user-focused vessel get within a certain distance of another User-focused vessel, a P2P connection is better. taking advantage of this, a P2P connection will be established between the vessels with a faster update rate, so that docking can be safe an accurate.
here's a topic that has been much debated: Time acceleration. I think that the client can "separate" from the server temporarily to time warp, as the simulation values on the database are relative to the closest planet. when the vessel comes out of time warp, the MJD re-calibrates to the server time and the relative values to the body (E.G. mars) stay the same. in short: same orbit, different date.
well, that's my two cents, I'm not going any further than that as I have my hands full already(Shuttle A MK4 and UVGCO).