Multiplayer Finally being created

[N_Molson]

I agree with Martins & Urumpwe. MFD that does not simulate ships subsystems or plausible software ruin the immersion. And there would be nothing wrong with a toolbar, as long you can hide it.

 

[Grover]

did we agree on the time compression issue? because i think ive found an alternative. (other than "slewing" as i suggested earlier)

how about we just make the simulations work on a smaller scale? at the most, maybe a launch from ground-LEO, where you could meet up with other orbinauts on the way (if you can adjust your trajectory well enough) or even have a STC (space traffic controller) to guide people, they request to make their maneuover (raise Pe, adjust INC etc) and the STC co-ordinates this as well as simplae airport and airspace stuff.

the problem would then be launch windows, you would have to get everyone to start at similar times, then launch them quick so they dont have a big alignment burn later.

there are still problems, but its only a half hour to go all the way to the ISS from KSC (~8 mins ascent (XR2) and then mostly waiting) and a little less to re-enter to come back to KSC, so you could either start docked at the ISS or at KSC, then go from one to the other, accompanied by fellow orbinauts.

what to do in your cruising phases? in a group, people can move about between each other (range <1KM) and not have to much of an effect on trajectories, as long as one person remains on an accurate trajectory, and everyone else stays close, youll be fine.


in this case, i reccoment 2-3 controllers at max (if they seem a good idea to you guys), being one at KSC (or ascention island ) one for the ISS (or whatever else) and possibly one for the approach to ISS, making sure that there's always space between incoming DGs, so theres no "collisions"

just a few ideas, what do you think?

 

[Wishbone]

So it is 1:1 all the way, isn't it? The sim should be playable, meaning one doesn't have to wear a diaper while doing re-entry, and it should be equally interesting to all the players. I'd object to being chosen as a flight controller, or a collision detection engine since these are quite boring occupations. No, the hard questions have to be answered, even as we can see the light now that graphics clients are separate from the core engine, the task of syncing clients across the globe to the server ground truth is still far from finished.

 

[N_Molson]

My two cents :

- For "global" servers : time accel fixed at 1x. The players could accelerate time on their side, but this would "remove" their ship from the server. When they step back to 1x, their ship coordinates would be transmitted to the server where their ship would "respawn". This feature would be disabled under a given altitude, and when another ship is near. The "illusion" would be quite good that way. This isn't very realistic, but the immersion could be quite good in a futuristic environement (DGs, ShuttleAs...)

- Players who want to fly together an historical (or fictionnal) mission could create their own server, where they could vote (F1-F2) for a "time accel request". This could work since the players would aim at the same objective, and would not be too numerous (probably under 10). They could decide to "stop" the scenario and data would be saved into their respective computers.

 

[Hielor]

- For "global" servers : time accel fixed at 1x. The players could accelerate time on their side, but this would "remove" their ship from the server. When they step back to 1x, their ship coordinates would be transmitted to the server where their ship would "respawn". This feature would be disabled under a given altitude, and when another ship is near. The "illusion" would be quite good that way. This isn't very realistic, but the immersion could be quite good in a futuristic environement (DGs, ShuttleAs...)

Except not.

Simple example:
Server is running at 1x time accel. I'm standing at KSC at 8am in the morning, local KSC time. I time-accelerate to move forward a total of 10 hours and 1 minute in sim-time, taking only 1 minute in real-time, so the server now thinks it's 8:01am and I think it's 6:01pm.

How then do you resolve all of the differences between me and the server? For me, the Earth has moved 10 hours further along its orbit, so if you just transmit my coordinates to the server (as you suggest), I'll be floating in space at a point the Earth won't reach for another ten hours. If you synchronize with the planet (so I remain stationary at KSC), I will have seen the sun move almost completely across the sky. When I get re-synchronized to the server, the sun will jump from an hour or so before sunset to a couple hours after sunrise.

The moon and ISS will be different places than they were a moment before, which makes things like rendeszvous impossible (I time accel to orbit and catch the ISS, then turn off time accel and the ISS will be in a completely different place).

How is this even remotely a good illusion or "immersive"?

 

[Wishbone]

How then do you resolve all of the differences between me and the server?

By keeping all the calculations on the server and giving you a thin client.

 

[Hielor]

By keeping all the calculations on the server and giving you a thin client.

:facepalm::facepalm:

Did you even read the rest of my post after the part you quoted?

A thin client does nothing to resolve the problem of time acceleration. You still have player A, at some time different from the server standard, and everything in player A's personal universe is in a different place from where it is on the server. That's not a trivial problem to resolve, and there's no solution that will be "realistic" or "immersive."

 

[jinglesassy]

Why dont we just make the planets stationary and the moons and the non-controllable to fix the interplanetary issue. Or intermoonitary issue. For the rendezvous and docking issue make a system where it registers who is on a intercept trajectory for more then a minute then move then to within 10 kilometers of it still on the intercept trajectory. Not the best but can you think of a better idea?

 

[Urwumpe]

Why dont we just make the planets stationary and the moons and the non-controllable to fix the interplanetary issue. Or intermoonitary issue. For the rendezvous and docking issue make a system where it registers who is on a intercept trajectory for more then a minute then move then to within 10 kilometers of it still on the intercept trajectory. Not the best but can you think of a better idea?

Why have more than just Earth then?

If you make the planets stationary, all orbital calculations will be wrong and interplanetary travel is completely impossible without MUCH higher fuel demands. So you also need to remove the gravity of the sun. Straight Line travel... Is that still orbiter then?

 

[Face]

Why dont we just make the planets stationary and the moons and the non-controllable to fix the interplanetary issue. Or intermoonitary issue. For the rendezvous and docking issue make a system where it registers who is on a intercept trajectory for more then a minute then move then to within 10 kilometers of it still on the intercept trajectory. Not the best but can you think of a better idea?

I already outlined a better idea. The time-bubble concept is still valid and allows for unmodified Orbiter experience in multiplayer.

 

[jinglesassy]

And wouldnt that still mess up planets movement for each person?

 

[Face]

And wouldnt that still mess up planets movement for each person?

Would you care to read up on the subject, please?

No, it would not mess with planets movement.

 

[Wishbone]

The thin client idea means that the server generates and sends out SPICE kernels for the time that has passed between the player going into "hibernation" and his wake-up. The client does not calculate anything, but simply re-enacts all attitude and position and status changes as a kind of playback. If a player wants to interact with the craft, fine, he switches to 1:1, and submits commands that will be executed on the server and then backpropagated to him and other participants.

 

[garyw]

So if I want to go to the moon and fire my engines on Monday for a three day TLI I'd better be there on Thursday or I might go smack into the moon?

 

[deltawing777]

I wonder. What about server linking? One server is running one thing or area or solar system. another server is running somthing else another somthing else. ANd you get handed off from server to server. You can run at least 2 maybe 3 servers on one pc.all with assignable ports. Im not sure how to explain it but could this be of some benefit as far as time accel? Or maybe a server for each planet and moon for our solar system. The servers really dont consume that much resources when running on a good machine (dual core or higher)

 

[garyw]

How would that be of help during time acceleration? Server one which is running the area (or solar system) is still out of sync with server 2 and three.

 

[Wishbone]

Monday and Thursday: you send to the server the conditions under which it will wake you up. The same goes for other players. The server runs to the first checkpoint at whatever acceleration/integration timestep it takes to yield acceptable accuracy, and pauses the simulation, sends the first player a wakeup signal and waits for response until some sensible timeout (e-mail or IRC or whatever), then continues at 1:1 until another timeout (allowing the player to enter commands) then fast forwards the integration till the second checkpoint, etc. etc.

 

[garyw]

either way, you still need to be available at the time your vessel reaches the moon?

 

[Wishbone]

And yes, if you don't respond in time to the wakeup call, your lunar mission or jovian slingshot may be continued to the bitter end - unless you have sent Lua scripts for the bot to manage your craft in your absence.

EDIT: which is why autopilots are crucial. The nitty gritty details are best left to the Colossus, players should take part in higher-level decisionmaking.

 

[Face]

I wonder. What about server linking? One server is running one thing or area or solar system. another server is running somthing else another somthing else. ANd you get handed off from server to server. You can run at least 2 maybe 3 servers on one pc.all with assignable ports. Im not sure how to explain it but could this be of some benefit as far as time accel?

No. Time acceleration as it happens in Orbiter is effectively time travel. A solution for time-acc in multiplayer would have to model time travel. Otherwise it would model FTL, which would make your solution subject to "why Orbiter, then?" kind of questions.

The time-bubble solution in essence models a multiverse approach to time travel. There traveling is between "universes", each of them having their own pace and offset. The travel itself is the synching via slower/faster time-acc-setting and/or ScnEditor-like time setting.
In this solution you are not accelerating one client's ships, but the whole universe itself. It just happens to have some "universes", and only clients in the same universe see each other.

A possible extension to the solution could be "ghost" ships by means of recording a ships trajectory through time-line, and later "replaying" them as transparent vessels in all "universes".

To date, this is the only solution I know to withstand both the "no FTL" and "consistent point-of-view" arguments.

This solution has one drawback, however: causality ( ORLY? ). As with all time travels, you soon fall into paradox-pitfalls, if you use the framework for something like e.g. role-playing.
I described a possible extension to the solution to cope with this problem in such use cases. In essence it is a kind of "quantum-state" model, not only putting all Orbiter-controlled objects into the multiverses, but e.g. role-playing objects as well. If you transverse "universes", you have to decide how you merge them... but this takes too long and is too complicated to reiterate here. Just go to the MMORPG thread to read up on it.

OTOH, for a multiplayer framework, the causality problem is no real one. After all, it should support Orbiter's sandbox-style as transparently as possible.

regards,
Face