Multiplayer Finally being created

[garyw]

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.

Kinda takes the fun out of hands on flying doesn't it?

 

[orb]

unless you have sent Lua scripts for the bot to manage your craft in your absence.

Kinda takes the fun out of hands on flying doesn't it?

Sorry, but I imagined an eggdrop IRC bot as an autopilot, and that would be fun... :rofl:

 

[deltawing777]

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

Wow thats getting pretty deep face....Ill just take your word for it lol.

 

[Wishbone]

If you can tie several people from all over the globe and from all the timezones to their chairs, the problem can be insta-solved through the least-commanded acceleration mechanism and full propagation of the state to clients through a low-latency network. Locking them in one room (with LAN) with plenty of refreshments also helps.

---------- Post added at 03:59 PM ---------- Previous post was at 03:53 PM ----------

I'd leave multiverse to sci-fi, though. DoD simulation community have been doing all this for decades, with no quantum mechanics in a purely Newtonian way. Re-inventing the bike is interesting but takes time. Please see the link on [ame="http://en.wikipedia.org/wiki/Distributed_Interactive_Simulation"]Distributed Interactive Simulation - Wikipedia, the free encyclopedia[/ame], and also http://www.sisostds.org

 

[Face]

I'd leave multiverse to sci-fi, though. DoD simulation community have been doing all this for decades, with no quantum mechanics in a purely Newtonian way. Re-inventing the bike is interesting but takes time. Please see the link on Distributed Interactive Simulation - Wikipedia, the free encyclopedia, and also http://www.sisostds.org

Funny that you mention it, because OMP was built with these specifications in mind .

You didn't mention the fact that DIS is real-time only, though. And pretty vague in some aspects, too.

Before you talk about re-inventing the bike, please show us the DIS specification dealing with individual node time acceleration. I don't know of anything even remotely similar in those standards...

But as you seem to have a good perspective how this all should be implemented, perhaps you can help the OP in developing his multiplayer system? After you helped him with the compiler setup, of course...

 

[Wishbone]

Everybody folds his own parachute and everybody sets up his own compiler. As for help in MP, top priority in my vision goes to automating and optimising repetitive tasks like launch, rendezvous, intercept, low-thrust trajectory management (solar, solar electric, ion), attitude maneuvers.

 

[Hielor]

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.

:facepalm:
That's not time acceleration, that's an autopilot.

Time acceleration in Orbiter allows me to sit down to a scenario with the ship docked at Mir, undock, perform a TLI, and arrive in lunar orbit in less than an hour of sitting-at-the-computer time, without sacrificing realism within the simulation.

Your proposal doesn't allow that.

 

[Wishbone]

If other players don't have checkpoints during your trip to the Moon (say, they are going to Jupiter) the server would allow you to get to the Moon in an hour just the same as in solitaire mode.

 

[Hielor]

If other players don't have checkpoints during your trip to the Moon (say, they are going to Jupiter) the server would allow you to get to the Moon in an hour just the same as in solitaire mode.

...What?

But I thought the server was always 1:1?

Problem with your plan, what if there was a launch window that I wanted to utilize sometime during that period? Now I'm SOL?

 

[hribek]

Everybody folds his own parachute and everybody sets up his own compiler. As for help in MP, top priority in my vision goes to automating and optimising repetitive tasks like launch, rendezvous, intercept, low-thrust trajectory management (solar, solar electric, ion), attitude maneuvers.

And once everything is AP handled, all you have to do is check if the autopilot isn't going crazy and control UMmus when something breaks? :lol:

:facepalm:
That's not time acceleration, that's an autopilot.

Time acceleration in Orbiter allows me to sit down to a scenario with the ship docked at Mir, undock, perform a TLI, and arrive in lunar orbit in less than an hour of sitting-at-the-computer time, without sacrificing realism within the simulation.

Your proposal doesn't allow that.

If I get it right, it would work just like a normal Orbiter simulation. But in this Multiplayer mode the time acceleration schedule would have to be negotiated/agreed on with other players. I think that this approach would work best for things like "Orbiter Mission to NameYourFavouriteHeavenlyBody", where the scheduling has to be prepared anyway.

The whole thing might get sort of turn-based if people who request 1x time acceleration can only play in certain hours. It could even advance to the point that you give the request "I'd like to get to MJD 54321 at 12:34:56 GMT on next Tuesday". When everybody says "ok, I'm waiting for some date" the time acceleration is set to a value that gets the sim to the first desired MJD at the user's requested time when he can play.

The time acceleration, causality, bubbling issues etc. can be converted to scheduling. That should work if the simulation has some goal, guidelines or rules, is meant for a certain mission, and/or the participants are cooperative and tolerant to each other.

If you don't want to bother waiting for other players, this approach will not work.

...What?

But I thought the server was always 1:1?

Problem with your plan, what if there was a launch window that I wanted to utilize sometime during that period? Now I'm SOL?

I believe you would request that as a checkpoint. Either you fly it, prepare a launch autopilot, let someone fly it for you or the game pauses and everybody waits for you to fly. (Or you say when you can get on and the acceleration is set according to that)

 

[Wishbone]

hribek is right, that's the idea.

 

[indonesianorbinaut]

good job!!!!!! :10sign: with extra :11sign:

 

[deltawing777]

And once everything is AP handled, all you have to do is check if the autopilot isn't going crazy and control UMmus when something breaks? :lol:



If I get it right, it would work just like a normal Orbiter simulation. But in this Multiplayer mode the time acceleration schedule would have to be negotiated/agreed on with other players. I think that this approach would work best for things like "Orbiter Mission to NameYourFavouriteHeavenlyBody", where the scheduling has to be prepared anyway.

The whole thing might get sort of turn-based if people who request 1x time acceleration can only play in certain hours. It could even advance to the point that you give the request "I'd like to get to MJD 54321 at 12:34:56 GMT on next Tuesday". When everybody says "ok, I'm waiting for some date" the time acceleration is set to a value that gets the sim to the first desired MJD at the user's requested time when he can play.

The time acceleration, causality, bubbling issues etc. can be converted to scheduling. That should work if the simulation has some goal, guidelines or rules, is meant for a certain mission, and/or the participants are cooperative and tolerant to each other.

If you don't want to bother waiting for other players, this approach will not work.



I believe you would request that as a checkpoint. Either you fly it, prepare a launch autopilot, let someone fly it for you or the game pauses and everybody waits for you to fly. (Or you say when you can get on and the acceleration is set according to that)

With the ability to kick somebody if they are holding up the game...or have a countdown timer when its your turn after so many seconds you forfit your turn. That way if sombody forgets or gets distracted the other people aren't getting held up.

 

[ghostrunner01]

My idea would be to have different servers for different things. For instance: Server 1 is for interplanetary travels. All players are in the same ship doing different things. Some special ships would have to be developed. 1 player would be in charge of engine management, another would be life support, and one player would be the commander who who decide where to go. There could be a rank system and the person with the highest rank would be commander. Its sort of a Role-playing game.

Server 2 would be a free flight server with no time acceleration. Players could do anything they want.



OR:

We could go with time acceleration and have each players time acceleration independent from each other. Example:

Player 1: Time Acceleration: 100X
Player 2: Time Acceleration: 1X

Player 1 would be shooting off to Mars while player 2 would see the ship in normal time. The players would end up with different times, so there could be an option to sync those times so the 2 players' times would equal each other.

Sorry if thats really confusing, its hard to get my ideas into words.

 

[Rtyh-12]

I don't know whether there's any acceptable solution for MP. However, on OHM...

[ame="http://orbithangar.com/searchid.php?ID=5013"]http://orbithangar.com/searchid.php?ID=5013[/ame]

Looks like you've got competition!

 

[Face]

I don't know whether there's any acceptable solution for MP. However, on OHM...

http://orbithangar.com/searchid.php?ID=5013

Looks like you've got competition!

I don't know how you can have a competition between zero/nada/nitschewo and something that has been around for about 5 years now...

 

[Xyon]

Having actually taken part in a session with OMP I am much more aware of its development level - Yes, it has some way to go before it's finished, being upgraded to O2010-P1 not being the least of them (I'll help with that if I can), but it's rather more stable than I thought it was, and actually worked out as quite a playable system - we went for some flying around WIN in DeltaGliders, and face watched me crashland twice >.<

As face says, OMP has been in development for quite a while, and has genuine promise. Building a multiplayer system from scratch just seems pointless while this framework exists, honestly, it's just going to be a whole long slog at it to come out with something less stable and worse than OMP, if anything at all.

 

[Keatah]

I read these OMP threads from time to time. I'm not personally interested in anything multi-player other than realtime side-by-side formation flying or docking. I use Orbiter for creating and setting the mood during evening parties and such. Or just meditating. Makes folks give plenty of ooooohhhss and aaahhhss when they ask if it is a screensaver. Nope! ..try this joystick right here. It really makes for nice visuals on big screens. The looks on folks faces when they roll the DG or XR2 with Saturn as a backdrop is cool. Then they call their buddies over to "check this out". The excitement soon fades when there are no lasor gunz or stuff to blow up. Some intellectuals will start asking questions, but most everyone goes back to getting drunk..

Well anyways, I would tend to guess OMP will need a variety of modes, including a hyper-drive for interplanetary journeys, real-time high accuracy mode for docking & rescue ops, turn based gameplay for strategic ops and planning.

One mode of operation cannot cover all scenarios all the time. And if time acceleration is a problem, well then, we need to work around it! Simple as that. Imho, time acceleration is cheating, and if you're gonna cheat, let's do it with style. We can bend relativity as much as we need to here, to make the game work. Again, when time acceleration is on, Orbiter is just a videogame.

All this jumping back and forth about what is and what isn't 'Orbiter' is only going to get worse. So my humble req to the devs, make this highly configurable to try to satisfy everyone. Certain scenarios will need a low latency 1:1 server. Other scenarios will be allowing ships to wink in and out from hyperdrive activities.

Maybe OMP should only work in certain scenarios, period!

Afterall, NASA missions operate 100% realtime. Sometimes I think slower:lol:

 

[Rtyh-12]

I don't know how you can have a competition between zero/nada/nitschewo and something that has been around for about 5 years now...

Dunno, but if such a competition arises, it will be bad for this guy but good for the rest of us, because competitions make developments go faster and better.

 

[Keatah]

Dunno, but if such a competition arises, it will be bad for this guy but good for the rest of us, because competitions make developments go faster and better.

In the case of orbiter, I'd prefer to see co-operation instead of competition. With co-operation many different ideas can be put into one super-sonic-stellar package. Also less chance for two standards to be developed. Orbiter is complex enough as it is!

For commercial software, its the other way around. The best program makes the most money! And the market can often bear 2 or 3 standards, like memory cards, or operating systems, and so on.

Just imagine two versions of OMP, and one version works with ships default to Orbiter, and the other version of OMP only works with 3rd party add-ons!! That ain't cool..