What features would you expect in orbiter Multi-player?

[supersonic]

No, because if you are aiming for another planet you will flyby way to early and miss your target by a few AU.

 

[eveningsky339]

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). Would this work for orbiter?

Odd, I was under the impression that time accel was not "allowed" in FSX multiplayer.

It would not work in Orbiter for interplanetary trips. Let's go back to the Saturn example. MFDs such as transx and IMFD calculate trajectories based on where Saturn is going to be in the amount of time it takes for you to coast there. So if your trajectory is going to get you to Saturn in one year, you are going to end up not where Saturn is at the moment you are creating the plan, but where Saturn will be in one year.

So, say you put time accel on. You go super fast while the rest of the solar system carries on at "normal time." ...See the problem?

 

[fireballs619]

It would not work in Orbiter for interplanetary trips. Let's go back to the Saturn example. MFDs such as transx and IMFD calculate trajectories based on where Saturn is going to be in the amount of time it takes for you to coast there. So if your trajectory is going to get you to Saturn in one year, you are going to end up not where Saturn is at the moment you are creating the plan, but where Saturn will be in one year.

So, say you put time accel on. You go super fast while the rest of the solar system carries on at "normal time." ...See the problem?

I understand now... perhaps the 'Bubble Method' is the only option. I know nothing about servers and multiplayer systems, so would that hard to implement?

 

[squeaky024]

We might all have to accept using a warp drive to get to anywhere at a reasonable time, in FSX we don't have planetary orbits to worry about when time warping.

Edit: I think it would be a challenge to code in a "time bubble" system, a host server will have to manage a lot of things anyways.

 

[Izack]

There are two problems with the bubble system. For one thing, you can't go back in time, and also there aren't going to be many people online at once. Between these two things, you're going to have 5-10 people, all at different points in time. It's like single-player Orbiter but with extra lag. Warp drives take the fun out of interplanetary travel. Looks like the only options are relegating the sim to cislunar space (or otherwise local) in realtime, or relying on scheduled events to keep players together.

(Well actually, I've used Face's Jumpdrive to go to Venus and Mars before, and it's actually pretty fun and challenging. Also really cool to watch from a third person perspective.)

 

[FSXHD]

Hardcore FSX Player's Ideas (First Post)

Hello! My name is Kevin Burns and this is my first post here. I have been reading many of the topics on the forums here over the past half year and I finally feel like I should post. I am an avid FSX pilot and user of their online multiplayer system called VATSIM (I'm currently flying on it right now across the Atlantic in real-time, yeah I know its sad) and I believe I can bring a few ideas to the table because of this experience. Okay, enough with the intro. No onto the problem.

I have a few viable options that could work for an Orbiter multiplayer system (with mission control).

1) The bubble method - I believe many of us think
that this is a option that will work, but the key to this method is good implementation into the end user interface which could take some time. We don't want a multiplayer system thats harder to learn than piloting a intergalactic voyage to Andromeda (sarcasm intended). On the flight sim network, we have pilot clients that allow you to easily control connection, flying, ATC, and other settings vital to a realistic flight. We would need something like this for any Orbiter multiplayer network.

2) the Warp Drive method - this is how we do it in flight sim, the whole universe/Earth stays on the same time scale, and only your aircraft is affected - meaning you will seem to be travelling at Mach 5 across the Pacific instead of the Mach 0.85 that the other guy is flying. You just get to your destination faster. In Orbiter's case, this would be just an extreme increase in velocity (but for ease of us, you could resume to normal speed at any time to perform any necessary burns, and the extreme increase/decrease in velocity wouldn't cause a huge and detrimental loss of fuel for your spacecraft, if at all). It is somewhat unrealistic, but I believe it would be the easiest option to implement in the first version of an official Orbiter multiplayer. We could implement this concept first, and develop the 'bubble method' and an easy way to interface it while the first version is operational. Then introduce a second version with the bubble method. This would allow us to have an operational multiplayer quicker, but also have a more realistic multiplayer later.

Now this is how I would imagine the development of a Orbiter multiplayer:

1- the development of a stable and user-friendly pilot client and server network
2- the deployment of this pilot client and server network using the warp drive method (now we have a usable multiplayer, but it still isn't realistic)
3- the development of an updated pilot client and server software to enable the bubble method while mkI of the multiplayer is online
4- deploy the bubble method multiplayer system and everyone's happy

Thats just my two cents. This is my first post so don't bite my head off if I say anything stupid, disrespectful, etc.

Regards,
Kevin Burns

 

[Izack]

to Orbiter-Forum, Kevin!

 

[fireballs619]

I think FSXHD's solution is viable. to the Forums Kevin!

 

[squeaky024]

Obviously to anyone opposing the bubble method, you can always warp and stay in the same time frame as everyone else (as long as they don't time warp too). I personally would like to see the bubble method implemented but I think it would be a major challenge to make it convenient for people to sync with other users time frames. It would be easy to just do things FSX style but that would be the same as using a warp MFD.

It really comes down to what each user prefers, but I think having each user control of their own time bubble will cause problems if they decided to meet and they are lets say, two months apart in time.

 

[fireballs619]

It comes down to the decision of sacrificing some realism (warping) to make a multiplayer functional. If that means the ability to dock with my friends, co-ordinate missions together, or do real time EVA's, I am willing to make that sacrifice. It's not like it affects single player . FSXHD's method still sounds best to me.

 

[FSXHD]

As I said, the warp drive method will be easiest to implement, and, though it isn't totally realistic, it works. You don't have to worry all about virtual parallel universes and the complexities of meeting up in the bubble method when using warp drive method. Implement warp drive first, and then develop the bubble method for the people who prefer ultra realistic missions.

Kevin Burns

 

[deltawing777]

Hm... I already proposed the spacetime-bubble concept to solve this problem. It was rejected for the MMORPG project, but I still think it is a proper solution for a "sandbox" style multiplayer project.

Quickly repeated:

• every user can choose arbitrary time-acceleration
• users using time-acc leave the server's time bubble and go with their own
• users willing to meet others have to synchronize with their bubble
• every bubble has a "leader" who is able to set the bubble's time-acc for e.g. interplanetary fleets
• users see each other only if in the same bubble, optionally "ghosts" are possible, being recordings of trajectories of other users at the appropriate MJD time

In your example, Player A and B would be in different time-bubbles, leaving either player A or B "stranded" in future and past, respectively. Player B can choose to sync with player A after landing, of course...

regards,
Face

Humm what if a mfd was required to play multiplayer? Maybe somthing like sensorMFD was required to use multiplayer in which if player A is not within player B's sensor range then time accel is allowed. If player A IS IN player B's range then time accel is locked and cant be used by either player. A or B could be a space station/vessel/planet base/etc....anything being used by a user ,a UCGO cargo truck for example.Once player B leaves player A's sensor range then it doesnt matter where player B is in relation to player A,(out of scanner and visual range,could of warped for that matter) untill player B comes across player A again or finds a new player,player C then it starts all over again. Sensor range could be X amount of miles/kilometers from any user whether that be a vessel/station/base etc..
maybe this is the "bubble" your refering to?


But in sticking to the topic of this thread The features I would like to see in a multiplayer would be first of all to be able to jump into a ship for example and be able to see what my buddy is seeing on his screen. for example my buddy is in pilot seat i would like to see the mfd's being switched and what was being typed into them and or console switches being turned off or on.I would like to be able to see from his/her perspective or just look left from co-pilots seat to see whats going on.(VC cockpits of course) Another thing I would like to see is a popup on the screen that says player X wants to give you the controls accept or reject y/n (he then goes for a spacewalk or Im being trained to dock for example. what a great way to train sombody in orbiter btw! :thumbup and of course a text chat.Voice chat not really to worried about there's so many voip proggy's out there teamspeak3,ventrillo, etc..... but a text chat for those who dont have mics.Then of course the MISSION CONTROL.My thoughts on that are here in this thread http://www.orbiter-forum.com/showthread.php?t=16142

 

[fireballs619]

Flaws with Deltawing's proposal

Yea my main wish here is some sort of mission control.

@deltawing777
Your proposal does not solve the problem of discrepancies in object location. If object A is a deltaglider, B a ravenstar, and inserting object C, the ISS, a problem arises. Imagine that A and B are on opposite sides of the planet, and object C is halfway between them in their orbit. If Object A time accelerates, but Object B does not, what does Object C (the ISS) do? Remain 1x or accelerate with Object A? Regardless of what it does, it will now have to different locations. One location, as viewed by Object A, will be much further along in it's orbit. The second location, as viewed by Object B, will be near the same spot, as it has not accelerated from B's frame of reference. Whose reference, A or B, do you now measure the distance from to see if acceleration is allowed?

My explanation probably isn't the best, but I couldn't think of another way to explain it.

 

[squeaky024]

If you guys understand Einstein's theory of Relativity, there you go, except much, much slower.

 

[Izack]

It's not so much relativity as it is a big ol' mundane headache.

 

[squeaky024]

It's not so much relativity as it is a big ol' mundane headache.

But the basic paradox is the same, two opposing reference frames in time.

 

[Shadow Addict]

I don't understand why so many people are against the RPG idea. If it was an opt-in sort of thing, then those who want a sandbox can play "classic" Orbiter, and those who want a more structured experience can use the RPG mode.

Also I'm a fan of the idea of intimate servers where everybody agrees on a time acceleration. I can't really imagine why two people would be in a server together if they weren't working together for something; it's not like you're going to run into somebody if you don't plan it.

 

[deltawing777]

Yea my main wish here is some sort of mission control.

@deltawing777
Your proposal does not solve the problem of discrepancies in object location. If object A is a deltaglider, B a ravenstar, and inserting object C, the ISS, a problem arises. Imagine that A and B are on opposite sides of the planet, and object C is halfway between them in their orbit. If Object A time accelerates, but Object B does not, what does Object C (the ISS) do? Remain 1x or accelerate with Object A? Regardless of what it does, it will now have to different locations. One location, as viewed by Object A, will be much further along in it's orbit. The second location, as viewed by Object B, will be near the same spot, as it has not accelerated from B's frame of reference. Whose reference, A or B, do you now measure the distance from to see if acceleration is allowed?

My explanation probably isn't the best, but I couldn't think of another way to explain it.

lock out C from time accel(ISS) object A and B are simply going 2 different speeds to the same target.humm target! targeting? maybe thats it. we need a targeting system. if target A and B are BOTH targeting C... C isnt allowed to time Accelerate a message pops up "more then one target incomming,time accel not allowed" so target A and B are simply approaching Target C at different speeds! when A and B are docked to C then C can Time Accel (taking A AND B with it )providing sombody else hasnt targeted it yet, meantime target D is on the planet trying to target C (with A and B docked)target D will just have to wait till time accel is turned off on C. D will get a message "target is time accel,please wait!"

 

[squeaky024]

But then its just a warp drive, the planets wont move causing problems with Transx.

 

[Face]

2) the Warp Drive method - this is how we do it in flight sim, the whole universe/Earth stays on the same time scale, and only your aircraft is affected - meaning you will seem to be travelling at Mach 5 across the Pacific instead of the Mach 0.85 that the other guy is flying. You just get to your destination faster. In Orbiter's case, this would be just an extreme increase in velocity (but for ease of us, you could resume to normal speed at any time to perform any necessary burns, and the extreme increase/decrease in velocity wouldn't cause a huge and detrimental loss of fuel for your spacecraft, if at all). It is somewhat unrealistic, but I believe it would be the easiest option to implement in the first version of an official Orbiter multiplayer. We could implement this concept first, and develop the 'bubble method' and an easy way to interface it while the first version is operational. Then introduce a second version with the bubble method. This would allow us to have an operational multiplayer quicker, but also have a more realistic multiplayer later.

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.

A system with the main purpose of Orbiter left behind is no solution IMHO.

1- the development of a stable and user-friendly pilot client and server network
2- the deployment of this pilot client and server network using the warp drive method (now we have a usable multiplayer, but it still isn't realistic)
3- the development of an updated pilot client and server software to enable the bubble method while mkI of the multiplayer is online
4- deploy the bubble method multiplayer system and everyone's happy

This sounds like a good plan, and in fact it is what I am working on. It should be noted, though, that the bubble-method is nothing you can bolt-on later. You have to take it into account in the design. Only my opinion, of course, but I guess I've build up quite some expertise now.

Thats just my two cents. This is my first post so don't bite my head off if I say anything stupid, disrespectful, etc.

OMH NOM NOM NOM :lol:

...and welcome to the forums!

@eveningsky339: Maybe my quick repeat was not enough to get it through... 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