What features would you expect in orbiter Multi-player?

In flight sims, Earth is not rotating, nor are the celestial objects reachable or moving.
The Moon in FSX moves accurately, as does the starfield (though I suspect it's the starfield rotating around the earth, rather than the earth itself rotating). Sunrise/sunset times also fairly accurately account for the season, but that might also be done via "cheating."
 
The Moon in FSX moves accurately, as does the starfield (though I suspect it's the starfield rotating around the earth, rather than the earth itself rotating). Sunrise/sunset times also fairly accurately account for the season, but that might also be done via "cheating."

So, what happens if Player A and B start at the same time in the same location in FSX with the full moon visible, if A accelerates x8 or so? Could both Players agree on flying "into the direction of the moon" and still go in the same direction, or will A see the sun going up, while B still sees the moon after 1 hour play-time?

If the former is true, FSX is just speeding up the aircrafts, cheating on the traveling aspect of the simulation. Having such a framework for e.g. virtual airlines will soon break immersion, if you can get your passengers over the atlantic equally fast with a DC-3 and a SR-71.

If the later is true, FSX suffers from the same problem as Orbiter, it is just outside its scope to be a headache to players (well, maybe the day/night thing is troublesome).

Forgive me my ignorance, I only once used flight sim multiplayer on FS9 and didn't pay much attention to the actual solution of the above mentioned detail there. I vaguely remember it to be the "speedup" thing, though. What is it like in FSX?

regards,
Face
 
So, what happens if Player A and B start at the same time in the same location in FSX with the full moon visible, if A accelerates x8 or so? Could both Players agree on flying "into the direction of the moon" and still go in the same direction, or will A see the sun going up, while B still sees the moon after 1 hour play-time?

If the former is true, FSX is just speeding up the aircrafts, cheating on the traveling aspect of the simulation. Having such a framework for e.g. virtual airlines will soon break immersion, if you can get your passengers over the atlantic equally fast with a DC-3 and a SR-71.

If the later is true, FSX suffers from the same problem as Orbiter, it is just outside its scope to be a headache to players (well, maybe the day/night thing is troublesome).

Forgive me my ignorance, I only once used flight sim multiplayer on FS9 and didn't pay much attention to the actual solution of the above mentioned detail there. I vaguely remember it to be the "speedup" thing, though. What is it like in FSX?
Edit: I take it back, FSX doesn't allow time acceleration when connected to a multiplayer session, the option is grayed out. Not sure what fireballs was testing when he said this:
I just checked in FSX- It is shown as an increase in velocity (i.e. the one plane appears to zoom past at ludicrous speeds).

You have to consider though that the built-in FSX multiplayer wasn't designed for longhaul flights lasting several hours. Its primary goal was to allow a couple of people to get together for some sightseeing, or a short hop from one airport to another, or a short race, or just messing around in the vicinity of an airport. Time acceleration isn't really needed for that.

I'm not sure about VATSIM, though--since it's really going through FSX single-player, it might actually "work" properly (ie, real time acceleration on a per-player basis), but it's designed to be used more for long-haul flights and synchronization between players doesn't matter nearly as much.

On the more social point of utilizing that "warp-drive," VATSIM has the following in its tips page for new pilots:
Do not pause your simulator or use time acceleration without ATC approval when in controlled airspace.


---------- Post added at 02:17 ---------- Previous post was at 01:59 ----------

The FSX multiplayer design doesn't apply well to Orbiter, though--there's no sightseeing to do and flying KSC-Habana and back would get boring by the 20th trip, I imagine. With the exception of ORL, there's not really much you can do in Orbiter in the course of 30minutes or so of sim time--you could get to stable LEO in that time, but certainly not get to a station unless you were using a direct-ascent profile (which I imagine most Orbiteers can't do).

Really, everything that Orbiter is better than other sims at pretty much requires time acceleration to avoid dying of boredom.

A server without time acceleration could result in some interesting dynamics, though--it would be rather busier around KSC when a direct ascent window is open than during other times, for example. This would naturally bring people together on the server at given times, rather than the "single-player with more lag" problem you run into with the time-bubbles concept.

Of course, with both major spaceports that ship by default in O2010 having only one runway each, things would get kind of crowded...
 
Last edited:
Edit: I take it back, FSX doesn't allow time acceleration when connected to a multiplayer session, the option is grayed out.

Aha. Interesting, thanks.

The FSX multiplayer design doesn't apply well to Orbiter, though--there's no sightseeing to do and flying KSC-Habana and back would get boring by the 20th trip, I imagine. With the exception of ORL, there's not really much you can do in Orbiter in the course of 30minutes or so of sim time--you could get to stable LEO in that time, but certainly not get to a station unless you were using a direct-ascent profile (which I imagine most Orbiteers can't do).

Agreed. I see time-acceleration in Orbiter as essential feature, too. Any multiplayer system trying to support Orbiter in its philosophy of being a playground in space would have to cope with it, IMHO.

A server without time acceleration could result in some interesting dynamics, though--it would be rather busier around KSC when a direct ascent window is open than during other times, for example. This would naturally bring people together on the server at given times, rather than the "single-player with more lag" problem you run into with the time-bubbles concept.

Then again, "server without time acceleration" is just a subset of the time-bubble concept. Just stick to one bubble controlled by the server admin. This is basically what OMP is doing now.

regards,
Face
 
In flight sims, Earth is not rotating, nor are the celestial objects reachable or moving. You can not project flight sim solutions to Orbiter, that's why it is so hard to do here.

Your proposal seems like you don't understand basic Orbiter functionality (my apologize if I misunderstood that), and here is why I think so:

Orbiter's main purpose is space flight simulation. As such, planning and executing trajectories in space is a common operation. A trajectory is about position-change over time w.r.t. the celestrial objects (or other vessels). If you speed up only your vessel to get a flight-sim style time-acc, you basically break your trajectory and will never reach your target. Doing so is nothing but another FTL engine and has nothing to do with time-acc as Orbiter executes it.

regards,
Face

You are correct in saying that I am somewhat new to Orbiter. I first started learning in January. I have only done one successful lunar transfer, but I can launch, rendezvous and dock with anything in Earth orbit with ease. Reentry is the hard part. Thats my main skill I need.

Anyways, the bubble method is the closest we have a got to a good system, and it has my vote. But I still think a mission control-client should be developed too. Theres that Orbiter Mission to Mars 'Prometheus', I believe, and a mission control would be great for those missions. Another key aspect of this is overall user-friendliness (even if one doesn't understand the system, most do, and the other can be taught) and stability.

Regards,
Kevin Burns
 
I like the time bubble idea, what about different orbiter system "rooms" like instances of the solar system with one "moderator" kind of like some group board game rooms or chess rooms. the moderator can also accelerate and decelerate time, but only the moderator, who probably created the room. other people can join up to that room and ask what they are up to, or a mission statement could be posted. say...moderator is building space station, they could ask the guest if they want to bring them parts with a xr vehicle or rocket while they are space tugging around with the dragonfly. the guests could request time accelerations from the moderator, with target "stop Time+"

for example, I'm a guest and I want to time accelerate 30 min. perhaps there could be an mfd style request form that says acceleration: 100x, duration: 1800 sec. or alternatively a "target time elapsed" so I request from the moderator to skip to "57800 sec" it could even be sent to the moderator as a popup box, then the moderator could approve it or put it in a que, ooor it could just show up in a que. say the moderator is just about to finish making a docking connection, and says "ok, wait 120sec pleas" the moderator finishes making the connection, and approves the time skip once docked and squared away. then the sim jumps to 10x or 100x and stops at 57800sec or whater time 1800 sec corresponded to.

it seems like it would be pretty easy to coordinate because the instruments can tell you exactly when you are going to reach critical points for maneuvers.

also, if the moderator wants to time accelerate they could send a warning to everyone to stabilize themselves, or ask if there is some crucial stop time that something needs to be done:

for example, moderator warning "Time jump 3600 sec"
guest one: "i request stop at 3400sec"
guest two: "I request stop at 1500 sec"
guest three: "3600 sec OK"

then the moderator could make time stops at 1500 and 3400

it would definitely have to be limited to smaller groups of probably 10 simmers max though


What about creating some kind of role play system, for example a job system in place and an example job could be station building or Iss refuel etc the possibilities are endless.

also incorporate some kind of weapon/damage system for the seperate ships what do you think?


this already exists in the form of add-ons and scn add-ons!

as for the weapons i can imagine someone camping somewhere and shooting people down with some kind of homebrew super weapon or a nuke-all thing.

----not that orbiter is anywhere even slightly close to this type of sim.
 
I like the time bubble idea, what about different orbiter system "rooms" like instances of the solar system with one "moderator" kind of like some group board game rooms or chess rooms. the moderator can also accelerate and decelerate time, but only the moderator, who probably created the room.
<snip>

What you described is what I had in mind, too. I like your choice of terminology even better than "time-bubble" and "owner of bubble". "Room" and "moderator" is closer to what people are used to due to IRC, and it will help to transport the notion of separate "universes". Nothing like talking in familiar words...

regards,
Face
 
oh thats funny, i actually was thinking i like the term "time-bubble" better. but with that in mine i reread your post and it makes alot more sense to me now haha :lol:
 
Edit: I take it back, FSX doesn't allow time acceleration when connected to a multiplayer session, the option is grayed out. Not sure what fireballs was testing when he said this:

Well to be honest, my first instinct was to test in a deserted area in VATSIM (hardly use the gamespy online anymore). So I will correct my statement my saying time acceleration works in VATSIM :)
 
Well to be honest, my first instinct was to test in a deserted area in VATSIM (hardly use the gamespy online anymore). So I will correct my statement my saying time acceleration works in VATSIM :)
VATSIM just uses FSX single-player, so it wouldn't have the same restriction.
 
If you want space combat, Orbiter isn't the best platform to do it.

I get your general drift, and I don't want to go offtopic, but I'll have to highly disagree with that statement. There are no space warfare simulators out there that use real principles, to my knowledge- it's more or less sci-fi. Orbiter might be able to present the solar system in a way never before applied to space tactics and/or strategy.

Nevertheless, making it "fun" and workable as a good addon is a different matter... one that IMO depends mostly on how good the addon develop(ers) are.
 
I get your general drift, and I don't want to go offtopic, but I'll have to highly disagree with that statement. There are no space warfare simulators out there that use real principles, to my knowledge- it's more or less sci-fi. Orbiter might be able to present the solar system in a way never before applied to space tactics and/or strategy.

Nevertheless, making it "fun" and workable as a good addon is a different matter... one that IMO depends mostly on how good the addon develop(ers) are.

hahah many people out there don't even consider ORBITER "fun" to begin with. :rofl:

o well everybody entitled to own opinion.

i think the easiest way to begin a space warfare addon would be to have the basics- such as a collision detector. if you were using solid ammo this would be a requirement. even if you didn't see any damage, detecting the hit would be key and an accomplishment

maybe a rudimentary straight line laser aiming detection, that is to say, if you pointed the laser in "such and such" direction, would it be pointed at the target? again, not necessary to have damage to start.

i guess it would need to be able to produce a projectile from a ship as well, i have seen this already in some of the star trek add-on, but they were "dumb" (like fire-and-forget) and just flew off with no adjustable parameter except maybe in config.
 
Theres that Orbiter Mission to Mars 'Prometheus', I believe, and a mission control would be great for those missions.
So far, OFMM has rejected the idea of a multiplayer aspect because of the complexity and superfluousness of it. Instead, we're going to plan each mission out carefully beforehand, and then share SCN files.
But who knows? We're still in early development, so if a stable OMP release were available by the time we started scheduling flights, it might come under consideration. Of course, if it came under consideration, it would likely require some dramatic changes in the scheduling and execution of missions...
 
@eveningsky339: Maybe my quick repeat was not enough to get it through...
I am not a clever man. :tiphat:

try to think of "sync" not as a simple time-set, but as a controlled time-acc speedup (or slow-down) to reach the other bubble's MJD. This way, Saturn would be in the same position after sync, because the upsyncing simulation is going through the same (more or less) time-travel. Granted, some minor differences could show up, but it will not affect user interaction.

regards,
Face
Ah, I think I have a better understanding. It sounds like the only viable way to make multiplayer for Orbiter a reality.
 
VATSIM just uses FSX single-player, so it wouldn't have the same restriction.

Indeed it does, but it uses an external client to connect to the network. Then you can interact with ATC and the other planes, because you can see the other aircraft logged on when flying on VATSIM.
 
For now I think the way time warp in multiplayer will have to work by the "request" system. I would love to see the time bubble feature but I guess this would take a long time to code in and perfect.

Now how exactly do we keep track of who is in what time frame, and how would the syncing process work anyways? It would be simple for a 2 or 3 player server, but what if we have 10 people at different times, it would seem too chaotic to meet anyone.
 
i could be confused but if yer talkin about the request system i was trying to describe, there wouldn't be any desynchronization, because everyone would always be in the same time frame, as in, when the moderator speeds things up, everyone would experience the same speed up, just the same way that if you have multiple ships in orbiter they all experience the speed-up.

the reason for the request management would be that person one feels "safe" for a long period of time, and person two feels "safe" for a shorter period of time, then they could both skip ahead until the shorter period of time had elapsed, then person one would have to wait for person two to complete their maneuver in real time, and they would both speed up to the later time frame that person two wanted to do something.

as a safety feature, people who are not moderators could be granted the ability to make "emergency time stops" in case they see that they accidentally left their hover on 2% or something.
 
I was talking about the "time bubble" method, and how it may be confusing to have so many different times in one server. I bet many people will look like :shrug:

I think your idea would be the simplest to make and probably the only one that will work smoothly so far, and it would be a lot less of a load on peoples computers.
 
Yes...I agree with the emergency stop idea. Once the guy in peril does his correction, he can send out a warning and then resume. It seems this will require significant work from the moderator though, keeping track of the shortest jump request. Also someone playing in real time would have to^be constantly alert and deal with time jump requests. But I guess we need to decide and start somewhere.
 
Yes...I agree with the emergency stop idea. Once the guy in peril does his correction, he can send out a warning and then resume. It seems this will require significant work from the moderator though, keeping track of the shortest jump request. Also someone playing in real time would have to^be constantly alert and deal with time jump requests. But I guess we need to decide and start somewhere.


Maybe instead of a warp time length (how many seconds) the person who requests a warp just says how much time warp (x10, x100, etc), and he/she will stop it when they are ready. No admin management there, all they have to do is set the warp.

edit: And of course as mentioned before players can alert when they are ready for a warp or not to prevent things rotating at 500 trillion RPM
 
Last edited:
Back
Top