What features would you expect in orbiter Multi-player?

[Bloodworth]

I like the idea of a single room in which we can work on real time missions. You would be able to interact with others if you chose too, but due to the sheer size of space, you would not have to if you so chose. I like the idea of a voice comm system built in. This way there could be a programmed time delay between transmission and reception as the range between vessels and/or ground control increases. For instance, a pilot orbiting mars transmits something to a ship/station/ground control at earth, the system records the transmission, saves it, and broadcasts it to the intended target 20 minutes later. An open line transmission would be saved and broadcast to everyone online at times relative to their distance from the broadcast source. I admit, I can see the need to possibly have somebody (moderator) responsible for time acceleration, but I would also like to see some way of keeping your ship in existence even while you are not on line. If you are doing an interplanetary mission (without warp or jump drives) and the room is capped at 1000x time accel, you are never going to get there if you can only play an hour a day or three; therefore some means of either keeping your ship in space even after logging off, or a means of tracking your ships progress in real time while you are off-line would be useful.

 

[fireballs619]

I think we should start out with the time request method, and get a working multiplayer implemented. Once the multiplayer gets implemented, people can start on developing a 'time bubble/room' method, as that is probably the best and most efficient method. If the problem of time acceleration can be solved, there is not much stopping orbiter from having a good, functioning multiplayer.

The time request method would work best, I think, if it had some sort of Mission control, who could handle all of the requests. To help the original poster, here is a list of things that have been requested in this thread so far:

1. Chat and VOIP input. VOIP can be solved using TeamSpeak or similar clients.
2. Time acceleration
   1. Request method, with build up to bubble method.
   2. Warp Drive MFD
   3. Proximity Method
3. Misson Control Function-Possibly in form of a MFD
   1. Integration and use with request method.
4. Co-piloting functions

Thats all so far. I will add here as more is requested.

 

[dumbo2007]

Yeah lets get a module set up that uses the Raknet library to talk to another sim successfully and see what happens when time accelerations is started on both simultaneously.

http://www.jenkinssoftware.com/

The library appears to be in beta

 

[gertz]

what about an orbital station, dockable, where users can walk, chat as ummu?

 

[fireballs619]

what about an orbital station, dockable, where users can walk, chat as ummu?

I think that would be something that would have to be implemented in single player first-not trying to fit it in multiplayer at the start. At that point, we are starting to get into a RPG/MMO type thing, which I am a strong opponent to. Orbiter is a simulator and when you start to add those types of things in, you take away what makes Orbiter, Orbiter. I would personally not want this in multiplayer.

 

[NosferatuAce]

Hi all, I just happen to come across this an decided to post a suggestion or two..
For one, servers a going to be needed, maybe an addition to the orbiter launchpad for online mode can be used.
Lag is going to be a problem. so a minimum amount of information should be sent to and from the server
If a server has an addon that you don't have, it will either not show up, be requested upon entering, or will be replaced by a default object (say if you don't have the shuttle pack, it will be replaced by the default atlantis), if you have something the server doesn't have, then it won't show up.
Time acceleration is limited/not available(that will create some problems for other users)
thats about it for suggestion, but does orbit have

 

[statickid]

Time acceleration is limited/not available

sorry but :rofl::hail::woohoo::jiggy::rofl::LOL!:rlyflag:

 

[NosferatuAce]

sorry but :rofl::hail::woohoo::jiggy::rofl::LOL!:rlyflag:

Eh, sorry, I do realize that its clear that time acceleration wouldn't be allowed, I just wanted to add it as a suggestion, I'm not trying to make it seem as though NO ONE had ever thought of it.

 

[Izack]

Eh, sorry, I do realize that its clear that time acceleration wouldn't be allowed, I just wanted to add it as a suggestion, I'm not trying to make it seem as though NO ONE had ever thought of it.

Yeah...maybe you should read the thread...

 

[Moach]

ok, i have an idea...

it's kinda like the "bubbles" idea, but a wee bit more on the flexible side...


the idea is to implement "instanced targets" - wait what? - you ask?

think of a "target instance" of kinda like your local, parallell universe -- your own little "island" of time and space
while all players are connected and can talk to eachother simultaneously - NOT all ships are visible, only the ones sync'd to your instance for that target...

so, the ISS is a target, as is KSC... when you fly there on your own, you're entering YOUR INSTANCE of it, other players can be in other instances, since the ISS will be in a different position over different times...

instances are target-space-oriented, so say you´re approaching the ISS from a relative distance of 300km...
you may then choose to sync up with the ISS instance that's closest to your MJD - your ship will be warped so it appears in the same relative position and veocity to the station, as time magically "jumps" into another date, taking the station (and you) with it...

now, you can see other pilots sync'd in to that same instance... and they would see you pop in from out of nowhere...

you cannot accelerate time while sync'ed, doing so breaks your link to that instance - others will see you disappear


so, done with the ISS, you proceed to the moon... once clear of the ISS and far from other players view, you can accelerate again and you'll be alone in your own bubble of time (still able to chat with others, of course, but not see them)


but say you wanna arrive at the moon and meet up with your friends there... jump up and when you're approaching the base, sync up with the most suitable instance for the local area, and you'll be able to see your friends there -
you'll soon forget the instant "snap" that the sky would do as you warp into sync with the local target and it's time-frame (don't worry, its just the moon being repositioned a few million miles and taking you with it)...

to you and the target as you see it, nothing is changed, you're still on your unaltered approach path... from the target's perspective, that is...


whenever a player logs into the main server (?) he gets connected to the most readily available instance of the area where he spawns... you can use a special MFD to chat with others and change the instance you're sync'd to in a sort of browser thing


this i call "relativistic multiplayer"... regular MP sims don't have to worry about this, because key locations aren't moving around over time, but when you're in orbit, everything is moving - so i devised this method to allow players to sync in to "relatively fixed" moving targets...


of course, you're not "forced" to sync in... if you're docking-port greedy ad want the ISS all for yourself or something, you can simply not sync in, and it'll be not too different than single-player...
except that, whenever a player is disconnected from any target instance, he creates his own - his ship being the target - allowing others to sync in to him, if they want to.. however, this is only possible in 1x sim-rate...

and for safety reasons - you can't sync with a target that's too distant from you (can't sync to a Jupiter instance if you're in LEO) - a relativistic repositioning at large distances would probably throw you into kingdom come



what do you think? doesn't that fix the time-warp problem?



then there's the mater of proxy-meshes so addon ships are visible to those who don't have it... i'd advise a simple SDK so addon-makers like myself could integrate into their ships a bandwidth-friendly mesh for multiplayer streaming

this would be so awesome if it were to be done!

 

[squeaky024]

Not to be pessimistic about the time bubble thing but after puting some thought into it, the time bubble idea seems to be very confusing for players (not the concept, the people playing might have a hard time keeping track of who is at what time) and it may also put a large strain on the server and the connection.

 

[Hielor]

Not to be pessimistic about the time bubble thing but after puting some thought into it, the time bubble idea seems to be very confusing for players (not the concept, the people playing might have a hard time keeping track of who is at what time)...

Not really, it's fairly straightforward. Keeping track of who is at what time is relatively simple: people who aren't at your time don't show up for you.

and it may also put a large strain on the server and the connection.

Why? It'll actually reduce load on the connection, since you won't need to transmit data for people who are in a different bubble...

 

[Moach]

well... i imagine there would be a multiplayer control-room type dialog, from which you could browse targets, players and see in what MJD they're in, then you just double-click one to sync-in to that target (provided you're within maximum range)

this DOES, in fact reduce the strain on the server - quite a bit, actually... the only free-flowing information would be the occasional bit of chat text... everthing more demanding, like positions and stuff, gets broadcasted only to actively sync'd target



my idea is that, unlike the original "bubbles" method, there's no live interaction between players in different dates and time-accelerations...

think of sync'ing in to a target like tuning the comms radio to a channel, only that when you do - you quickly warp to it's local MJD, and also, get repositioned so you end up in the same relative position to it as you were before synchronizing


making this uncomplicated for players is a simple matter of interface design... a good list-view should make things pretty clear and be easy to browse through

this list view would show every available target (stations, planets, moons, bases...) and what "bubbles" are available for it, then sub-list players sync'd to each particular bubble
it could be sorted by name, MJD-delta, distance-delta, number of players, etc...


targets which you are nerby (in your local time) enough to sync-in, are shown as active, and you can bouble-click yourself into connection with it...

time waps, and you're now approaching the target, as you were, but in a different date :thumbup:


it may seem like a tricky concept at first, but once you get your head around it, you'll see it's actually quite straightforward... and it's pretty much the only way of getting proper multiplayer going

 

[Face]

ok, i have an idea...

so, the ISS is a target, as is KSC... when you fly there on your own, you're entering YOUR INSTANCE of it, other players can be in other instances, since the ISS will be in a different position over different times...

instances are target-space-oriented, so say you´re approaching the ISS from a relative distance of 300km...
you may then choose to sync up with the ISS instance that's closest to your MJD - your ship will be warped so it appears in the same relative position and veocity to the station, as time magically "jumps" into another date, taking the station (and you) with it...

<snip>

but say you wanna arrive at the moon and meet up with your friends there... jump up and when you're approaching the base, sync up with the most suitable instance for the local area, and you'll be able to see your friends there -
you'll soon forget the instant "snap" that the sky would do as you warp into sync with the local target and it's time-frame (don't worry, its just the moon being repositioned a few million miles and taking you with it)...

Whenever I read "magical" and "instant snap", I feel uncomfortable with a proposal. This is my opinion on it:

1. If the system is doing something "magical" or "instant", it breaks the immersion for Orbiter users. Granted, you can always do some FTL fuzzing-around, but it will always have that cheating feeling to me. Besides that, OMP already has a built-in FTL jump functionality for the quick ISS meetings.
2. Your proposal basically creates overlapping objects (multiple ISS instances) that you need to link together somehow. How do you determine that player A's "myISS" object is to be linked to player B's "GreatStationInTheSky" object according to your "target" idea?
3. How would you deal with interactive targets? Let's say ISS has RCS control and player A is switching focus to his own, personal ISS instance, just to alter the trajectory a bit in order to let it de-orbit. If he now switches back to his DG and chases the ISS, he suddenly is transferd into a stable Orbit with (what?) relative velocity to a perfectly fine ISS of (whoever?) else... sounds rather confusing to me.
4. Do you propose to hold all global server objects as duplicates on every machine? If not, how does one create his targets in order to be able to reach them? If so, wouldn't that cause scalability issues?
5. You have a very good point regarding bases here. I too think that bases (and planets) should be linkable targets, but not for the purpose of jumping someone around space-time, but for the purpose of precision regarding state-vectors. I have a negotiation phase in OMP where a common object database is built up. All clients agree on object identifiers in order to make state vectors adressable (aka relative state-vectors). This database contains planets, bases and vessels. Every non-static object (i.e. vessels or vessel-bases) is hosted by exactly one client, though.
6. I think your proposal is creating an additional - even more confusing - automatism on top of the bubble concept. Both of your scenarios can be reproduced with the pure bubble concept and a FTL addon.

The bubble concept is more than I've described here in my quick repeats. E.g. you can of course go back in time, either by effectively stopping the simulation until the bubble catches up, or by simply using Orbiter's SetMJD feature to set your simulation to the appropriate time. The point is, that it is not adding concepts beyond what it necessary to Orbiter.

Your proposal is very interesting, but it is more pointing into the MMORPG direction, where you can have goals and parties and "targets". Nevertheless, your ISS scenario is a valid use-case. To me, it goes like this:

• A and B are starting in the same bubble. A is hosting a DG starting at the cape, B is hosting a DG in moon orbit and a ISS in LEO.
• A is going to ISS, B is doing a approach on Brighton with his DG.
• While A needs a time-acc for the coasting&rendevous phase, B is on final (and not interested in speeding up his ISS).
• Now A can either wait for B to complete his final, or time-acc on his own and rendevous "into-the-blue", as B's ISS will disappear if he leaves B's bubble.

This is certainly a headache, and your proposal would solve this, but with the magic jump in the end. Given that A will want to do the space equivalent of touch&go (i.e. go back to earth immediately after rendevous), your proposal would make detailed flight plans impossible in such cases, as you can't plan the jump's actual location, because it is depending on B's mood - more or less.

So - as a take-away - I think we could use your ideas here to fix that scenario without something instant or magic: snapshot objects. In the scenario above, where A don't want to rendevous "into-the-blue", he can leave the bubble, but create a local placeholder that is just a marker for the supposed trajectory of the ISS. This marker will go with the time-acc, in order to give A a visual feedback. As soon as A arrives at the appropriate meeting point, he deletes the marker. He is now where the ISS would be if B is catching up to A's bubble without altering the trajectory of the ISS. If B don't want to do that, A can only decide to go back to B's bubble again, in either stopping the simulation until B catches up, or using the scenario editor to SetMJD (which is a magic device on its own). In all cases, the relation of flown trajectory to position in space-time is not broken (with the exception of ScnEditor, which is "magical", but at least stock).

what do you think? doesn't that fix the time-warp problem?

Yes, it fixes the time-warp problem because it is using the bubble concept as base.

then there's the mater of proxy-meshes so addon ships are visible to those who don't have it... i'd advise a simple SDK so addon-makers like myself could integrate into their ships a bandwidth-friendly mesh for multiplayer streaming

OMP already takes this into account by means of mapping. The server maps vessel classes to proxy classes. E.g. DGIV to Deltaglider or unknown classes to a stub class. Thus, no SDK would be needed, addon-makers could just create a second - "dumbed-down" - version of their vessels.

If you think about online-distribution, this opens a can of worms due to legal issues. I'll not go that road...

this would be so awesome if it were to be done!

As I always say: do it yourself! If you can't do it, you are welcome to tell us about your ideas, but then they will only be that... ideas.

Not really, it's fairly straightforward. Keeping track of who is at what time is relatively simple: people who aren't at your time don't show up for you.
...
Why? It'll actually reduce load on the connection, since you won't need to transmit data for people who are in a different bubble...

Seconded.

regards,
Face

---------- Post added at 03:41 PM ---------- Previous post was at 03:34 PM ----------

my idea is that, unlike the original "bubbles" method, there's no live interaction between players in different dates and time-accelerations...

I think you got that wrong. The bubble concept has no live interaction between players in different dates and time-accelerations either.

it may seem like a tricky concept at first, but once you get your head around it, you'll see it's actually quite straightforward... and it's pretty much the only way of getting proper multiplayer going

It all depends on the definition of "proper". As I said, sudden jumps and dislocations are not in my definition of it. But I understand that you can live with it, and I also think your proposal would be a nice addition for the MMORPG thread. Would be interesting to apply it on the whole market, prices, resources discussion, too.

regards,
Face

 

[FSXHD]

I think the bubble/room method should be used first. If there was just one room with time acceleration, say if I was docking to the ISS or performing some other precise orbital maneuver, I wouldn't want a sudden time acceleration and crash into something other than the docking port. And even if it was based on a request system, the person requesting time accel. could get frustrated, and problems could ensue. And besides, I would only use multiplayer for flying the same mission with other people, not my everyday flying - therefore I would much rather have the bubble/room method implemented first.

 

[statickid]

personally i would mainly want to have multiplayer for some of the following types of scenarios (just me, personally, just throwing this out here not trying to convince anyone that these are the best reasons):

I would want to do shorter missions, like rescue simulations of emergency, where every person has their own UMMU, like the pack-in scn have a cripple delta glider eject all the players into space on a bad burn-up course, all players can stabilize their own "guy" and then at the same time, someone will pilot a pickup ship. players can try to all group together for fast pickup.

another cool idea i would want MP:
Super-Ultra-Mega-Hypersonic-Racing! now maybe for starters this is a type of MP that can be done without time acceleration because the races would be short-ish (30 mins-hour? hahaha) for example, there could be a reentry race to KSC, where everyone starts out on the same reentry path and first to land on the runway wins (or the last person to not blow up from trying to speed too much) or even just the old ksc to wideawake, but in real-time with everyone racing, not just posting times/vids...


shoot was gonna write some more but i gotta go >>>>>>

 

[FSXHD]

These are all good ways to utilize the multiplayer, but it would only be effective in a room/bubble method. That is why I do not like the idea of an overall time acceleration request environment.

 

[Salun]

THe ability to have multible clients control one vessel. Say Me and a friend take off in a XR2 to the ISS. My buddy flys the assent. I pilot to the rendezvous and when we get there he hopes out and does an EVA. Or say I fly a B-52 with the X-15 under the wing. He drops and then I spawn a chase plane for when he lands.

 

[FSXHD]

THe ability to have multible clients control one vessel. Say Me and a friend take off in a XR2 to the ISS. My buddy flys the assent. I pilot to the rendezvous and when we get there he hopes out and does an EVA. Or say I fly a B-52 with the X-15 under the wing. He drops and then I spawn a chase plane for when he lands.

I like that idea greatly. If it were possible, a mission control option should be implemented too.

 

[Moach]

perhaps i need to elaborate some more on the target-sync possibility...

this is the concept i have in mind after chewing a bit on my "targets" idea:


the main problem is... in global "sun" space, EVERTHING is moving... so the slightest difference in MJD will cause sync issues... unless...


we use stations, bases and planets as local sync-reference points...
whenever you're near such a point, you'll see other players around it - even if those players have a different date, and in a global sense, this means for instance, their ISS is not at the same position as yours, you'll still find them near around YOUR ISS

how? in what stretch of logic can a player be in more than one place at once?

simple: your position is always broadcasted in relative space to your nearest sync-target


so it doesn't matter when you're approaching a base or station, when you'll get there, there will be players, since they are relative-sync'd to that target, and they will be able to see you, in that same manner


but what if i wanna do a rescue mission, or build a space station with my friends?

tricky one, huh? not really...

sync-targets are laid in a hierarchy based on what's orbiting what... so the moon is a child of the earth, which is child of the sun, etc...

if one were to create a sync-target, (as is the case of station-building or rescue scenarios), this target would be parented by the object it's in orbit of


you're not able to see players who aren't sync'd to your target...

and yet, simply reporting positions through the server on a nearest-target local space, eliminates the magic-jump problem, as well as solving the time-warp riddle

and eases up the bandwith overhead considerably - as no-one has to keep track of multiple instances of the same object... its just reporting positions on a local space



alternativelly, you can force-sync with a given player, so both have the same MJD - but this will inevitably involve a little time-warp magic