Discussion Passive multiplayer

[cinder1992]

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

 

[Stevodoran]

Sounds great

---------- Post added at 12:22 PM ---------- Previous post was at 12:21 PM ----------

we should use those new ideas

 

[jedidia]

in short: same orbit, different date.

wouldn't that wreak havoc with the positioning of vessels? I mean, if you want to put the load of the calculations to the individual physics engines, you cannot afford to have the planets in different positions in each simulation. I might be orbiting a planet that is not there in your simulation, so if your computer is doing the physics work on your side, I WON'T be orbiting in your simulation. And if I would be, I'd be orbiting an empty spot in the heavens on your machine...

On the other hand, if you just keep it all relative to the orbits of a "master-positioning", you'll have ships disapearing from space and re-apearing in some orbits from one second to the other. Not to mention that the planet on your machine and the master probably has a different rotation now, so you might be touching down at olympus base from your point of view, but landing somewhere completely different on the master. It sounds like a rather impractical arrangement.

 

[cinder1992]

Ok, to refine the time-warp thing, I'm going to look onto the orbiter scenario system.

the orbital elements of the vessel and the MJD are two separate values and the orbital elements are relative to the body that the vessel is orbiting. from what I know, changing the MJD doesn't affect these values in any way. once the time warp has been "completed", the MJD will roll back to the server MJD and the orbital elements relitive to the body that the vessel is orbiting (after the time warp) stay the same.

It also seems that you missed the MJD "roll back", this will help, but it will still wreak havoc with people that do slingshots :/

 

[Izack]

Isn't it easier to just change the time acceleration to physical acceleration? That way, there wouldn't be any mucking about with the MJD; no one could change it, so everyone would still be in the same place in time while maintaining the ability to travel interplanetarily in a practical amount of real-world time.

I think that idea has already been discussed in the prime OMP thread, though.

 

[cinder1992]

I believe it was, and the die-hard anti-warpdrive people won that argument.

and just to refine the topic: I couldn't care less about time warp at this time because there is no clean way to do it.

 

[jedidia]

the orbital elements of the vessel and the MJD are two separate values and the orbital elements are relative to the body that the vessel is orbiting. from what I know, changing the MJD doesn't affect these values in any way.

No, but when I'm making a trip from earth to mars, the Orbit changes to sol first. When I'm going to mars with time acceleration, my mars would be in another position than the mars in the actual time, and it would have another rotation. So when I arrive there and the MJD rolls back, Mars will rotate back too, so it would suddenly be in another orientation when I get there. Then again, there are worse things.

I take it that the vessels being under time acceleration would vanish from the visible universe anyways (i.e. another player could not track a vessel that is currently under time acceleration), so the popping up out of nowhere is there anyways. Just have to watch out for collisions... :lol:

 

[cinder1992]

ok I see your point, Maybe whoever uses this will write some code to keep the latitude, longitude, and equ. inc.. (grammar fail: do I need the double full-stop there?)

Oh, and the chances of collision in space (even in orbit) are 1,000,000:1. (do NOT quote Terry Pratchett, I KNOW those crop up 9 times out of 10.)

 

[Face]

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.

Hm. You will have all those problems with your proposal, too. I don't see where it should 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.

I have to admit, I don't see the big difference to OMP here. Just to make sure you know what you are talking about:

1. OMP sends periodic updates of all hosted vessels of a client to the server (to update its database) and neighbour clients in visible range (to update the visuals of the locally displayed vessels).
2. Without activity (thrusting, RCS, etc.), the period is long (10 secs), with activity it is short (e.g. 200ms).
3. Between updates, the physic engines of the clients calculate the position of all vessels displayed.
4. If neighbours are out of visible range, they can only display another vessel via the tracking function. In this case, the server's database is used and the server sends the vessel's state information.
5. If clients receive vessel state information, they compensate for the lag (detected by timestamp difference - synced by NTP) by means of RK4 propagation.

As I see it, your proposal is very similar to what OMP is already doing.

here's a topic that has been much debated: Time acceleration.

:facepalm: Yes, much debated. Nevertheless, I still see the bubble system as only option. Everything else is flawed IMHO.

OTOH, a different approach to multiplayer would be much appreciated, so please start working and come up with a prototype, so we can evaluate it...

regards,
Face

 

[Shinrar]

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.

Here is the main problem I see with this...

Mid course corrections.

Let's say I'm in orbit around earth at sever start time. So is everyone else. No-one has accelerated time, yippee!

Now lets say I want to fly to Mars! Alright, so I line up my inclination - warping to get to my nodes. Oh well, not close to anyone else, so no problems - right? Anyways.
Burn time!

Now I'm on my way to Mars, in a zillion times time acceleration. Wooosh! Everyone else is still in orbit, in real time. So Mars isn't moving (fast), but to me, it is - right on target to where I'm going to be!

Wait a second - it seems I made a mistake. Time to do some MCC, to compensate for my errors that are showing up in my TransX projection. So I drop down to realtime...

The server detected I'm in orbit around the Sun, so it moved me back to the MJD of the server, but kept my orbital elements the same. Drat. That means Mars is back where it started! So I'm on course to an empty spot in Mar's orbit.

I know you're trying to come up with a good idea to solve the problem, and we all appreciate that, but everyone likes to come up with ideas to solve the little problems, and put minimal effort into the big problem - Time Acceleration.

 

[jedidia]

Oh, and the chances of collision in space (even in orbit) are 1,000,000:1. (do NOT quote Terry Pratchett, I KNOW those crop up 9 times out of 10.)

:lol:

maybe blindfolding and standing on one leg helps...

 

[computerex]

I think as far as a multi-player system for Orbiter is concerned, the most fun will be in being able to dock/fly/talk with one another, being able to observe what someone else is doing, jumping to their position if necessary. Interplanetary transfers require time acceleration to do in a reasonable time, and the majority of the flight is done in coasting, while the majority of the important procedures are conducted in real time.

So with that in mind, I think the best solution for this would be being able to synchronize to the time of a client, or a group of clients. Imagine a modern multiplayer game. You have multiple rooms you can go into. A "time bubble" would be something similar. Users should be able to create virtual "rooms", titled, for example, "Messing at KSC", or "Messing with warp drive in low lunar orbit". Each virtual room has a time of its own. The creator of the room then should have the power to accelerate time, or it could be done by some voting system. After the time acceleration is done, there should be some mechanism to synchronize all clients to the room master's time.

The reason why I say that is because when we are actually playing orbiter, we are usually playing it in real time. Otherwise we are going to get something to eat or something else while we are coasting to some planet. There should be no reason to complicate OMP just because of this, because the reward is being able to see some vessel in deep space, without even a sense of motion.