Editing Multi-player

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
Line 4: Line 4:
 
Used to '''multiplayer''' features in virtually all modern games from arcade-style shooters to photo-realisitic flight simulators, it seems it should be logical to simply extend these engines to Orbiter.
 
Used to '''multiplayer''' features in virtually all modern games from arcade-style shooters to photo-realisitic flight simulators, it seems it should be logical to simply extend these engines to Orbiter.
  
This is not good logic. An orbital simulation has to deal with several orders of magnitude greater speed differences between potential simulated craft. Therefore the topic has required much work.
+
It has proven not so.
 
 
==Advantages==
 
* Allows live tutorials, like teaching new players how to dock with the ISS.
 
* Have competitions, aerobatics air shows or  races.
 
* Do historical flights with other players supporting you, eg launch the Mercury Atlas with another player as mission control and have someone chase that Atlas in a DG or be a chase plane for the shuttle landing.
 
* Use multiple computers for home cockpits.
 
* have multiple players forming the crew for more complex spacecraft, for spreading the workload among them.
 
  
 
==Hurdles==
 
==Hurdles==
Line 17: Line 10:
 
Hurdles split into roughly two camps: logical and technical. Logical hurdles need cunning to overcome but are wholly soluble in the addon (eg. lag compensation). Technical problems relate to limitations placed on the addon by Orbiter itself (eg. being unable to jump simtime, inability to control landed craft etc.).
 
Hurdles split into roughly two camps: logical and technical. Logical hurdles need cunning to overcome but are wholly soluble in the addon (eg. lag compensation). Technical problems relate to limitations placed on the addon by Orbiter itself (eg. being unable to jump simtime, inability to control landed craft etc.).
  
The first logical problem with multiplayer in Orbiter is the range of speeds. The craft needs to be visible to other players while sitting on the ground at Havana, and equally when [[LEO|orbiting]] 200 miles above the Earth, either prograde or retrograde. That's a difference in speeds of 15 kilometres per second.
+
The first logical problem with multiplayer in Orbiter is range of speeds. The craft need to be visible to other players whilst sat on the ground at Havana, and equally when [[LEO|orbiting]] 200 miles above the Earth prograde, and equally retrograde. That's a difference in speeds of 15 kilometres per second.
  
 
So what?
 
So what?
Line 23: Line 16:
 
Well, in your driving game, if you have a tenth-of-a-second lag at 180mph, your car will appear to jitter 8 metres. Irritating, but still on the road.
 
Well, in your driving game, if you have a tenth-of-a-second lag at 180mph, your car will appear to jitter 8 metres. Irritating, but still on the road.
  
If your point of reference is the surface of the Earth, so you have no jitter on the ground, a tenth of a second in [[LEO]] will cause jitter of 750 metres -- half a mile. It's not going to be easy to dock when you're not sure which cubic kilometre your craft will be in next second!
+
If your point of reference is the surface of the Earth, so you have no jitter on the ground, a tenth of a second in [[LEO]] will cause jitter of 750 metres -- half a mile. It's not going to be easy to dock when you're not sure which cublic kilometre your craft will be in next second!
  
  
An example of a technical hurdle is how to deal with time acceleration, and different system times. Orbiter works out the rotation angle of the planet depending on the SimTime. Different start times, time accelerations, pauses etc. cause these to become desynchronised. Suddenly a vessel sitting on a pad at Cape Canaveral may appear half way across the Atlantic to one user and somewhere around India to another.
+
An example of a technical hurdle is how to deal with time acceleration, and different system times. Orbiter works out the rotation angle of the planet depending on the SimTime. Different start times, time accelerations, pauses etc. cause these to become desynchronised. Suddenly a vessel sat on the pad at Canaveral appears half way into the Atlantic to one user and somewhere around India.
  
Another technical hurdle would be supporting animations on ships (eg. opening the DG's docking doors), or telling the Shuttle to start in Orbiter configuration on everybody's system.
+
Another technical hurdle would be supporting animations on ship (eg. opening the DG's docking doors), or telling the Shuttle to start in Orbiter configuration on everybody's system.
  
 
As one delves deeper into this it becomes aparent the technical hurdles are the key to the viability of a multiplayer plugin. It's been postulated core support is required before a general interface can become effective.
 
As one delves deeper into this it becomes aparent the technical hurdles are the key to the viability of a multiplayer plugin. It's been postulated core support is required before a general interface can become effective.
  
==The situation in Orbiter 2006==
+
==Attempts==
 
 
In [[Orbiter 2006]], the [[API]] got enhanced by functions for manipulating the simulation time.
 
  
* [[oapiSetSimMJD]]
+
#Toni Ylisirniö developed the first recorded interactive multiplayer plugin with his seminal [[IRCMFD]]. Added mostly as a toy for regulars on Orbiter's [[IRC]], it needed manual updates and really only addressed the speed-difference hurdle by switching to relative-to-closest-vessel position reporting when vessels passed within 15km of each other. Development has ceased.
* [[oapiTime2MJD]]
 
* [[oapiSetPause]]
 
* [[oapiGetPause]]
 
* [[oapiGetSysMJD]]
 
  
With this new set of functions, it is now possible to solve some of the synchronization problems in  earlier versions of [[Orbiter]].  
+
#[[MultiOrb]] took the IRCMFD model and provided automation (to deal with the logical hurdle of advising other craft of orientation and accelerative changes), as well as expanding the supported craft range and addressing some of the relative position reporting issues. Again it didn't seek to address time differences. Development has ceased.
  
==Attempts==
+
#[[OMP]] is a still-ongoing project, unrelated to the others outside of discursive advice, providing a more in-depth framework and seeking to address the time difference problem by synchronising the PCs with the simplified Network Time Protocol. Believed still under developement.
  
*Toni Ylisirniö developed the first recorded interactive multiplayer plugin with his seminal [[IRCMFD]]. Added mostly as a toy for regulars on Orbiter's [[IRC]], it needed manual updates and really only addressed the speed-difference hurdle by switching to relative-to-closest-vessel position reporting when vessels passed within 15km of each other. Development has ceased.
+
#[[Project Hamac]] is a proof-of-concept technology demonstrator, offering virtually no solutions to Orbiter technical hurdles (bar docking), but addressing most logical problems by implementing a physics server-graphical thin client model. Development has transferred to the [http://openkosmos.sourceforge.net/ Kosmos project].
*[[MultiOrb]] took the IRCMFD model and provided automation (to deal with the logical hurdle of advising other craft of orientation and accelerative changes), as well as expanding the supported craft range and addressing some of the relative position reporting issues. Again it didn't seek to address time differences. Development has ceased.
 
*[[OMP]] is a still-ongoing project, unrelated to the others outside of discursive advice, providing a more in-depth framework and seeking to address the time difference problem by synchronizing the PCs with the simplified Network Time Protocol. Is still under development.
 
*[[Orbiter MMORPG]] is an attempt on creating a full-fledged multiplayer "game" within the Orbiter environment.
 
*[[Project Hamac]] is a proof-of-concept technology demonstrator, offering virtually no solutions to Orbiter technical hurdles (bar docking), but addressing most logical problems by implementing a physics server-graphical thin client model. Development has transferred to the [http://openkosmos.sourceforge.net/ Kosmos project].
 
*[[Orbiter.World]] is an attempt at building a persistent online world. In contrast to [[OMP]], clients send updates to a server, where they can be retrieved by other clients by means of polling. Is still under development.
 
  
 
No comprehensive product has yet been produced, and consequently this area of Orbiter development should still be considered experimental.
 
No comprehensive product has yet been produced, and consequently this area of Orbiter development should still be considered experimental.
Line 57: Line 39:
 
==See also==
 
==See also==
  
[[Category: Articles]]
+
[[:Category:Multiplayer addons]]
[[Category: Multi-player add-ons]]
 

Please note that all contributions to OrbiterWiki are considered to be released under the GNU Free Documentation License 1.2 (see OrbiterWiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)