https://www.orbiterwiki.org/api.php?action=feedcontributions&user=Face&feedformat=atomOrbiterWiki - User contributions [en]2024-03-29T07:11:39ZUser contributionsMediaWiki 1.35.2https://www.orbiterwiki.org/index.php?title=OMP&diff=16748OMP2017-05-25T14:46:36Z<p>Face: Added Orbiter.World</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://omp.ddns.net http://omp.ddns.net]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''Orbiter Multiplayer Project (OMP)''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. This meant that it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods<br />
--------<br />
* '''V0.7''' - 2012-05-05<br />
* '''V0.7.1''' - 2012-05-18 <br />
* '''V0.7.2''' - 2013-07-21<br />
* '''V0.7.3''' - 2013-08-05 This version fixes some bugs in the fast vessel class lane and primarily comes with a missile toy to test the former.<br />
* '''V0.7.4''' - 2013-12-20 This version fixed bugs regarding the missile "work-flow" by means of introducing attachment support. In addition, STUN analysis was enhanced.<br />
* '''V0.8''' - 2014-10-09 Compatibility break - PTP protocol and jitter-avoidance updates<br />
* '''V0.8.1''' - 2015-07-08 Introduction of hand-over features (persistence)<br />
* '''V0.8.2''' - 2017-05-23 Switch to Orbiter 2016, added animation support via save state transmission<br />
<br />
==Status==<br />
Around August 2016, development moved from a scattered O-F-subforum/Bitbucket existence to a concentrated offering at [http://omp.ddns.net http://omp.ddns.net] . Together with public servers for OMP itself as well as a supporting Teamspeak3, this service also hosts the source-code as well as dedicated discussion forums.<br />
<br />
==Networking issues==<br />
<br />
From the 0.6.1 version on, most NAT problems are worked around by means of hole-punching and STUN analysis. OMP sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup<br />
* Missile toy - demonstrates advanced interactions in the distributed simulation<br />
* Transmission of vessel save states, so animations and various settings are reflected on remote machines<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right. Beginning with version 0.8, an optional [[w:Precision_Time_Protocol|PTP]] mechanism can be used to synchronize clients to the server clock, eliminating the need for contacting external timeservers.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is also used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the the right class (mesh) and name of the neighbor vessels are to be seen, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the appropriate space-time bubble’s MJD (currently there is only one globally available server bubble). The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). Concurrently, all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body.<br />
<br />
The server decides, what vessel is in visible range of what other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). It consists of a target vessel ID (the vessel of the receiver client), a source vessel ID (the vessel of the sender client) and IP and port of the receiver client the sender should send to. Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client.<br />
There are 5 reasons to send an absolute SI instead of a relative one:<br />
* The source vessel is not in the same space-time bubble – regarding space – as the target vessel. This is merely indicated by different gravitational bodies.<br />
* The target vessel is not available right now – if there was no absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it is not possible to calculate relative coordinates.<br />
* The source vessel velocity w.r.t. the gravitational body is smaller than 1000 m/s. This is considered “non-orbital speed” and should be within the tolerance of the established synchronization.<br />
* A jump command is running.<br />
* The distance between source and target vessel is greater than the sub-visual range, or the velocity difference between source and target is greater than 1000 m/s. The sub-visual range 𝑑 in meter is determined by:<br />
** the current simulation’s viewport high ℎ in pixels,<br />
** the current field of view 𝑓𝑜𝑣 in degree,<br />
** the maximum size of both vessels 𝑠 in meter and<br />
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP. However, SI information is only taken into account if:<br />
* the reference object is available,<br />
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and<br />
* the vessel to be updated is no superstructure slave.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
==Online Servers==<br />
[http://omp.ddns.net http://omp.ddns.net]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[Orbiter.World]]<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=Orbiter.World&diff=16747Orbiter.World2017-05-25T14:44:44Z<p>Face: fixed link to http</p>
<hr />
<div>{{Addon|<br />
1=[http://orbiter.world/ http://orbiter.world/]|<br />
2=Muhammad Ali aka computerex aka Majid<br />
}}<br />
<br />
'''Orbiter.World''' was announced in this [http://orbiter-forum.com/showthread.php?t=38288 thread] on Orbiter forums.<br />
<br />
==Status==<br />
In May 2017, with the announcement of the project, a [http://orbiter.world/orbiter.online.zip working prototype] was released. The source code is publicly available by means of a [http://github.com/computerex/orbiter.online GitHub repository].<br />
<br />
==Technology==<br />
<br />
Orbiter.World uses a server/client concept with polling mechanisms. Clients use 3 Orbiter plugins:<br />
* mjdcontroller - synchronizes the current simulation to the server time<br />
* ServerPersister - allows to "persist" a simulation object so its state gets send to the server regularly<br />
* ClientPersister - polls the server for object states and displays remote vessels accordingly<br />
<br />
The used communications protocol is HTTP, the payload is JSON-encoded. In essence, [http://en.wikipedia.org/wiki/Representational_state_transfer ReST] principles are used for communication.<br />
<br />
==Online Servers==<br />
[http://orbiter.world/tele http://orbiter.world/tele]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[OMP]]<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=Orbiter.World&diff=16746Orbiter.World2017-05-25T14:44:20Z<p>Face: Created page with "{{Addon| 1=[http://orbiter.world/ http://orbiter.world/]| 2=Muhammad Ali aka computerex aka Majid }} '''Orbiter.World''' was announced in this [http://orbiter-forum.com/showt..."</p>
<hr />
<div>{{Addon|<br />
1=[http://orbiter.world/ http://orbiter.world/]|<br />
2=Muhammad Ali aka computerex aka Majid<br />
}}<br />
<br />
'''Orbiter.World''' was announced in this [http://orbiter-forum.com/showthread.php?t=38288 thread] on Orbiter forums.<br />
<br />
==Status==<br />
In May 2017, with the announcement of the project, a [http://orbiter.world/orbiter.online.zip working prototype] was released. The source code is publicly available by means of a [http://github.com/computerex/orbiter.online GitHub repository].<br />
<br />
==Technology==<br />
<br />
Orbiter.World uses a server/client concept with polling mechanisms. Clients use 3 Orbiter plugins:<br />
* mjdcontroller - synchronizes the current simulation to the server time<br />
* ServerPersister - allows to "persist" a simulation object so its state gets send to the server regularly<br />
* ClientPersister - polls the server for object states and displays remote vessels accordingly<br />
<br />
The used communications protocol is HTTP, the payload is JSON-encoded. In essence, [https://en.wikipedia.org/wiki/Representational_state_transfer ReST] principles are used for communication.<br />
<br />
==Online Servers==<br />
[http://orbiter.world/tele http://orbiter.world/tele]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[OMP]]<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=Multi-player&diff=16745Multi-player2017-05-25T14:18:34Z<p>Face: Added Orbiter.World</p>
<hr />
<div>==Background==<br />
Pretty much since the dawn of [[Orbiter]], users have asked: ''how can I play online with my friends?''<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Advantages==<br />
* Allows live tutorials, like teaching new players how to dock with the ISS.<br />
* Have competitions, aerobatics air shows or races. <br />
* 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.<br />
* Use multiple computers for home cockpits.<br />
* have multiple players forming the crew for more complex spacecraft, for spreading the workload among them.<br />
<br />
==Hurdles==<br />
<br />
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.).<br />
<br />
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.<br />
<br />
So what?<br />
<br />
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.<br />
<br />
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!<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==The situation in Orbiter 2006==<br />
<br />
In [[Orbiter 2006]], the [[API]] got enhanced by functions for manipulating the simulation time.<br />
<br />
* [[oapiSetSimMJD]]<br />
* [[oapiTime2MJD]]<br />
* [[oapiSetPause]]<br />
* [[oapiGetPause]]<br />
* [[oapiGetSysMJD]]<br />
<br />
With this new set of functions, it is now possible to solve some of the synchronization problems in earlier versions of [[Orbiter]]. <br />
<br />
==Attempts==<br />
<br />
*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.<br />
*[[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.<br />
*[[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.<br />
*[[Orbiter MMORPG]] is an attempt on creating a full-fledged multiplayer "game" within the Orbiter environment.<br />
*[[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].<br />
*[[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.<br />
<br />
No comprehensive product has yet been produced, and consequently this area of Orbiter development should still be considered experimental.<br />
<br />
==See also==<br />
<br />
[[:Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=16744OMP2017-05-25T14:06:35Z<p>Face: Update for 0.8.2 release</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://omp.ddns.net http://omp.ddns.net]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''Orbiter Multiplayer Project (OMP)''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. This meant that it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods<br />
--------<br />
* '''V0.7''' - 2012-05-05<br />
* '''V0.7.1''' - 2012-05-18 <br />
* '''V0.7.2''' - 2013-07-21<br />
* '''V0.7.3''' - 2013-08-05 This version fixes some bugs in the fast vessel class lane and primarily comes with a missile toy to test the former.<br />
* '''V0.7.4''' - 2013-12-20 This version fixed bugs regarding the missile "work-flow" by means of introducing attachment support. In addition, STUN analysis was enhanced.<br />
* '''V0.8''' - 2014-10-09 Compatibility break - PTP protocol and jitter-avoidance updates<br />
* '''V0.8.1''' - 2015-07-08 Introduction of hand-over features (persistence)<br />
* '''V0.8.2''' - 2017-05-23 Switch to Orbiter 2016, added animation support via save state transmission<br />
<br />
==Status==<br />
Around August 2016, development moved from a scattered O-F-subforum/Bitbucket existence to a concentrated offering at [http://omp.ddns.net http://omp.ddns.net] . Together with public servers for OMP itself as well as a supporting Teamspeak3, this service also hosts the source-code as well as dedicated discussion forums.<br />
<br />
==Networking issues==<br />
<br />
From the 0.6.1 version on, most NAT problems are worked around by means of hole-punching and STUN analysis. OMP sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup<br />
* Missile toy - demonstrates advanced interactions in the distributed simulation<br />
* Transmission of vessel save states, so animations and various settings are reflected on remote machines<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right. Beginning with version 0.8, an optional [[w:Precision_Time_Protocol|PTP]] mechanism can be used to synchronize clients to the server clock, eliminating the need for contacting external timeservers.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is also used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the the right class (mesh) and name of the neighbor vessels are to be seen, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the appropriate space-time bubble’s MJD (currently there is only one globally available server bubble). The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). Concurrently, all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body.<br />
<br />
The server decides, what vessel is in visible range of what other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). It consists of a target vessel ID (the vessel of the receiver client), a source vessel ID (the vessel of the sender client) and IP and port of the receiver client the sender should send to. Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client.<br />
There are 5 reasons to send an absolute SI instead of a relative one:<br />
* The source vessel is not in the same space-time bubble – regarding space – as the target vessel. This is merely indicated by different gravitational bodies.<br />
* The target vessel is not available right now – if there was no absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it is not possible to calculate relative coordinates.<br />
* The source vessel velocity w.r.t. the gravitational body is smaller than 1000 m/s. This is considered “non-orbital speed” and should be within the tolerance of the established synchronization.<br />
* A jump command is running.<br />
* The distance between source and target vessel is greater than the sub-visual range, or the velocity difference between source and target is greater than 1000 m/s. The sub-visual range 𝑑 in meter is determined by:<br />
** the current simulation’s viewport high ℎ in pixels,<br />
** the current field of view 𝑓𝑜𝑣 in degree,<br />
** the maximum size of both vessels 𝑠 in meter and<br />
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP. However, SI information is only taken into account if:<br />
* the reference object is available,<br />
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and<br />
* the vessel to be updated is no superstructure slave.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
==Online Servers==<br />
[http://omp.ddns.net http://omp.ddns.net]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=16478OMP2016-08-31T12:13:35Z<p>Face: Status update</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://omp.ddns.net http://omp.ddns.net]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''Orbiter Multiplayer Project (OMP)''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. This meant that it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods<br />
--------<br />
* '''V0.7''' - 2012-05-05<br />
* '''V0.7.1''' - 2012-05-18 <br />
* '''V0.7.2''' - 2013-07-21<br />
* '''V0.7.3''' - 2013-08-05 This version fixes some bugs in the fast vessel class lane and primarily comes with a missile toy to test the former.<br />
* '''V0.7.4''' - 2013-12-20 This version fixed bugs regarding the missile "work-flow" by means of introducing attachment support. In addition, STUN analysis was enhanced.<br />
* '''V0.8''' - 2014-10-09 Compatibility break - PTP protocol and jitter-avoidance updates<br />
* '''V0.8.1''' - 2015-07-08 Introduction of hand-over features (persistence)<br />
<br />
==Status==<br />
Around August 2016, development moved from a scattered O-F-subforum/Bitbucket existence to a concentrated offering at [http://omp.ddns.net http://omp.ddns.net] . Together with public servers for OMP itself as well as a supporting Teamspeak3, this service also hosts the source-code as well as dedicated discussion forums.<br />
<br />
==Networking issues==<br />
<br />
From the 0.6.1 version on, most NAT problems are worked around by means of hole-punching and STUN analysis. OMP sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup<br />
* Missile toy - demonstrates advanced interactions in the distributed simulation<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right. Beginning with version 0.8, an optional [[w:Precision_Time_Protocol|PTP]] mechanism can be used to synchronize clients to the server clock, eliminating the need for contacting external timeservers.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is also used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the the right class (mesh) and name of the neighbor vessels are to be seen, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the appropriate space-time bubble’s MJD (currently there is only one globally available server bubble). The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). Concurrently, all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body.<br />
<br />
The server decides, what vessel is in visible range of what other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). It consists of a target vessel ID (the vessel of the receiver client), a source vessel ID (the vessel of the sender client) and IP and port of the receiver client the sender should send to. Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client.<br />
There are 5 reasons to send an absolute SI instead of a relative one:<br />
* The source vessel is not in the same space-time bubble – regarding space – as the target vessel. This is merely indicated by different gravitational bodies.<br />
* The target vessel is not available right now – if there was no absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it is not possible to calculate relative coordinates.<br />
* The source vessel velocity w.r.t. the gravitational body is smaller than 1000 m/s. This is considered “non-orbital speed” and should be within the tolerance of the established synchronization.<br />
* A jump command is running.<br />
* The distance between source and target vessel is greater than the sub-visual range, or the velocity difference between source and target is greater than 1000 m/s. The sub-visual range 𝑑 in meter is determined by:<br />
** the current simulation’s viewport high ℎ in pixels,<br />
** the current field of view 𝑓𝑜𝑣 in degree,<br />
** the maximum size of both vessels 𝑠 in meter and<br />
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP. However, SI information is only taken into account if:<br />
* the reference object is available,<br />
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and<br />
* the vessel to be updated is no superstructure slave.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
==Online Servers==<br />
[http://omp.ddns.net http://omp.ddns.net]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=16435OMP2016-04-24T09:00:22Z<p>Face: fixed PTP version note</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://bitbucket.org/face/orl-online http://bitbucket.org/face/orl-online]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. This meant that it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods<br />
--------<br />
* '''V0.7''' - 2012-05-05<br />
* '''V0.7.1''' - 2012-05-18 <br />
* '''V0.7.2''' - 2013-07-21<br />
* '''V0.7.3''' - 2013-08-05 This version fixes some bugs in the fast vessel class lane and primarily comes with a missile toy to test the former.<br />
* '''V0.7.4''' - 2013-12-20 This version fixed bugs regarding the missile "work-flow" by means of introducing attachment support. In addition, STUN analysis was enhanced.<br />
* '''V0.8''' - 2014-10-09 Compatibility break - PTP protocol and jitter-avoidance updates<br />
* '''V0.8.1''' - 2015-07-08 Introduction of hand-over features (persistence)<br />
<br />
==Status==<br />
Around January 2016, development stopped due to doubts about the legality of OMP's license. The repository on [http://bitbucket.org/face/omp BitBucket] was closed to the public.<br />
However, a migration to a dedicated hosting and administration of the project (repository, server, forum/discussion) is planned for Summer 2016.<br />
<br />
==Networking issues==<br />
<br />
From the 0.6.1 version on, most NAT problems are worked around by means of hole-punching and STUN analysis. OMP sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup<br />
* Missile toy - demonstrates advanced interactions in the distributed simulation<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right. Beginning with version 0.8, an optional [[w:Precision_Time_Protocol|PTP]] mechanism can be used to synchronize clients to the server clock, eliminating the need for contacting external timeservers.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is also used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the the right class (mesh) and name of the neighbor vessels are to be seen, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the appropriate space-time bubble’s MJD (currently there is only one globally available server bubble). The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). Concurrently, all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body.<br />
<br />
The server decides, what vessel is in visible range of what other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). It consists of a target vessel ID (the vessel of the receiver client), a source vessel ID (the vessel of the sender client) and IP and port of the receiver client the sender should send to. Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client.<br />
There are 5 reasons to send an absolute SI instead of a relative one:<br />
* The source vessel is not in the same space-time bubble – regarding space – as the target vessel. This is merely indicated by different gravitational bodies.<br />
* The target vessel is not available right now – if there was no absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it is not possible to calculate relative coordinates.<br />
* The source vessel velocity w.r.t. the gravitational body is smaller than 1000 m/s. This is considered “non-orbital speed” and should be within the tolerance of the established synchronization.<br />
* A jump command is running.<br />
* The distance between source and target vessel is greater than the sub-visual range, or the velocity difference between source and target is greater than 1000 m/s. The sub-visual range 𝑑 in meter is determined by:<br />
** the current simulation’s viewport high ℎ in pixels,<br />
** the current field of view 𝑓𝑜𝑣 in degree,<br />
** the maximum size of both vessels 𝑠 in meter and<br />
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP. However, SI information is only taken into account if:<br />
* the reference object is available,<br />
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and<br />
* the vessel to be updated is no superstructure slave.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
==Online Servers==<br />
[http://omp.ddns.net http://omp.ddns.net]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=16434OMP2016-04-24T08:59:33Z<p>Face: Versions updated</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://bitbucket.org/face/orl-online http://bitbucket.org/face/orl-online]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. This meant that it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods<br />
--------<br />
* '''V0.7''' - 2012-05-05<br />
* '''V0.7.1''' - 2012-05-18 <br />
* '''V0.7.2''' - 2013-07-21<br />
* '''V0.7.3''' - 2013-08-05 This version fixes some bugs in the fast vessel class lane and primarily comes with a missile toy to test the former.<br />
* '''V0.7.4''' - 2013-12-20 This version fixed bugs regarding the missile "work-flow" by means of introducing attachment support. In addition, STUN analysis was enhanced.<br />
* '''V0.8''' - 2014-10-09 Compatibility break - PTP protocol and jitter-avoidance updates<br />
* '''V0.8.1''' - 2015-07-08 Introduction of hand-over features (persistence)<br />
<br />
==Status==<br />
Around January 2016, development stopped due to doubts about the legality of OMP's license. The repository on [http://bitbucket.org/face/omp BitBucket] was closed to the public.<br />
However, a migration to a dedicated hosting and administration of the project (repository, server, forum/discussion) is planned for Summer 2016.<br />
<br />
==Networking issues==<br />
<br />
From the 0.6.1 version on, most NAT problems are worked around by means of hole-punching and STUN analysis. OMP sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup<br />
* Missile toy - demonstrates advanced interactions in the distributed simulation<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right. Beginning with version 0.7.5, an optional [[w:Precision_Time_Protocol|PTP]] mechanism can be used to synchronize clients to the server clock, eliminating the need for contacting external timeservers.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is also used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the the right class (mesh) and name of the neighbor vessels are to be seen, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the appropriate space-time bubble’s MJD (currently there is only one globally available server bubble). The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). Concurrently, all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body.<br />
<br />
The server decides, what vessel is in visible range of what other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). It consists of a target vessel ID (the vessel of the receiver client), a source vessel ID (the vessel of the sender client) and IP and port of the receiver client the sender should send to. Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client.<br />
There are 5 reasons to send an absolute SI instead of a relative one:<br />
* The source vessel is not in the same space-time bubble – regarding space – as the target vessel. This is merely indicated by different gravitational bodies.<br />
* The target vessel is not available right now – if there was no absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it is not possible to calculate relative coordinates.<br />
* The source vessel velocity w.r.t. the gravitational body is smaller than 1000 m/s. This is considered “non-orbital speed” and should be within the tolerance of the established synchronization.<br />
* A jump command is running.<br />
* The distance between source and target vessel is greater than the sub-visual range, or the velocity difference between source and target is greater than 1000 m/s. The sub-visual range 𝑑 in meter is determined by:<br />
** the current simulation’s viewport high ℎ in pixels,<br />
** the current field of view 𝑓𝑜𝑣 in degree,<br />
** the maximum size of both vessels 𝑠 in meter and<br />
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP. However, SI information is only taken into account if:<br />
* the reference object is available,<br />
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and<br />
* the vessel to be updated is no superstructure slave.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
==Online Servers==<br />
[http://omp.ddns.net http://omp.ddns.net]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=16433OMP2016-04-24T08:38:15Z<p>Face: Status update</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://bitbucket.org/face/orl-online http://bitbucket.org/face/orl-online]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. This meant that it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods<br />
--------<br />
* '''V0.7''' - 2012-05-05<br />
* '''V0.7.1''' - 2012-05-18 <br />
* '''V0.7.2''' - 2013-07-21<br />
* '''V0.7.3''' - 2013-08-05 This version fixes some bugs in the fast vessel class lane and primarily comes with a missile toy to test the former.<br />
* '''V0.7.4''' - 2013-12-20 This version fixed bugs regarding the missile "work-flow" by means of introducing attachment support. In addition, STUN analysis was enhanced.<br />
==Status==<br />
Around January 2016, development stopped due to doubts about the legality of OMP's license. The repository on [http://bitbucket.org/face/omp BitBucket] was closed to the public.<br />
However, a migration to a dedicated hosting and administration of the project (repository, server, forum/discussion) is planned for Summer 2016.<br />
<br />
==Networking issues==<br />
<br />
From the 0.6.1 version on, most NAT problems are worked around by means of hole-punching and STUN analysis. OMP sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup<br />
* Missile toy - demonstrates advanced interactions in the distributed simulation<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right. Beginning with version 0.7.5, an optional [[w:Precision_Time_Protocol|PTP]] mechanism can be used to synchronize clients to the server clock, eliminating the need for contacting external timeservers.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is also used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the the right class (mesh) and name of the neighbor vessels are to be seen, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the appropriate space-time bubble’s MJD (currently there is only one globally available server bubble). The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). Concurrently, all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body.<br />
<br />
The server decides, what vessel is in visible range of what other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). It consists of a target vessel ID (the vessel of the receiver client), a source vessel ID (the vessel of the sender client) and IP and port of the receiver client the sender should send to. Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client.<br />
There are 5 reasons to send an absolute SI instead of a relative one:<br />
* The source vessel is not in the same space-time bubble – regarding space – as the target vessel. This is merely indicated by different gravitational bodies.<br />
* The target vessel is not available right now – if there was no absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it is not possible to calculate relative coordinates.<br />
* The source vessel velocity w.r.t. the gravitational body is smaller than 1000 m/s. This is considered “non-orbital speed” and should be within the tolerance of the established synchronization.<br />
* A jump command is running.<br />
* The distance between source and target vessel is greater than the sub-visual range, or the velocity difference between source and target is greater than 1000 m/s. The sub-visual range 𝑑 in meter is determined by:<br />
** the current simulation’s viewport high ℎ in pixels,<br />
** the current field of view 𝑓𝑜𝑣 in degree,<br />
** the maximum size of both vessels 𝑠 in meter and<br />
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP. However, SI information is only taken into account if:<br />
* the reference object is available,<br />
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and<br />
* the vessel to be updated is no superstructure slave.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
==Online Servers==<br />
[http://omp.ddns.net http://omp.ddns.net]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=15877OMP2014-07-25T11:52:28Z<p>Face: Updated to new version and server situation</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://bitbucket.org/face/orl-online http://bitbucket.org/face/orl-online]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. This meant that it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods<br />
--------<br />
* '''V0.7''' - 2012-05-05<br />
* '''V0.7.1''' - 2012-05-18 <br />
* '''V0.7.2''' - 2013-07-21<br />
* '''V0.7.3''' - 2013-08-05 This version fixes some bugs in the fast vessel class lane and primarily comes with a missile toy to test the former.<br />
* '''V0.7.4''' - 2013-12-20 This version fixed bugs regarding the missile "work-flow" by means of introducing attachment support. In addition, STUN analysis was enhanced.<br />
==Status==<br />
As of Juli 2014, software development is ongoing by means of a [http://bitbucket.org/face/omp BitBucket project]. Both server and client software were rewritten using .NET technology.<br />
<br />
In early December 2008, a [http://bitbucket.org/face/orl-online fork] called ORRL (Orbiter Rocket Racing League) was established - consisting of additional content by various other developers - to create a more intriguing environment for online racing competition. This is based on the ORRL ideas introduced in [http://orbiter-forum.com/showthread.php?t=5490 Orbiter-Forum].<br />
This branch of OMP was updated in January 2011 to stabilize the system for the purpose of online racing and make it compatible with Orbiter 2010.<br />
<br />
==Networking issues==<br />
<br />
From the 0.6.1 version on, most NAT problems are worked around by means of hole-punching and STUN analysis. OMP sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup<br />
* Missile toy - demonstrates advanced interactions in the distributed simulation<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right. Beginning with version 0.7.5, an optional [[w:Precision_Time_Protocol|PTP]] mechanism can be used to synchronize clients to the server clock, eliminating the need for contacting external timeservers.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is also used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the the right class (mesh) and name of the neighbor vessels are to be seen, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the appropriate space-time bubble’s MJD (currently there is only one globally available server bubble). The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). Concurrently, all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body.<br />
<br />
The server decides, what vessel is in visible range of what other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). It consists of a target vessel ID (the vessel of the receiver client), a source vessel ID (the vessel of the sender client) and IP and port of the receiver client the sender should send to. Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client.<br />
There are 5 reasons to send an absolute SI instead of a relative one:<br />
* The source vessel is not in the same space-time bubble – regarding space – as the target vessel. This is merely indicated by different gravitational bodies.<br />
* The target vessel is not available right now – if there was no absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it is not possible to calculate relative coordinates.<br />
* The source vessel velocity w.r.t. the gravitational body is smaller than 1000 m/s. This is considered “non-orbital speed” and should be within the tolerance of the established synchronization.<br />
* A jump command is running.<br />
* The distance between source and target vessel is greater than the sub-visual range, or the velocity difference between source and target is greater than 1000 m/s. The sub-visual range 𝑑 in meter is determined by:<br />
** the current simulation’s viewport high ℎ in pixels,<br />
** the current field of view 𝑓𝑜𝑣 in degree,<br />
** the maximum size of both vessels 𝑠 in meter and<br />
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP. However, SI information is only taken into account if:<br />
* the reference object is available,<br />
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and<br />
* the vessel to be updated is no superstructure slave.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
==Online Servers==<br />
[http://omp.ddns.net http://omp.ddns.net]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=Multi-player&diff=15795Multi-player2013-11-15T15:56:14Z<p>Face: Fixed OMP development note</p>
<hr />
<div>==Background==<br />
Pretty much since the dawn of [[Orbiter]], users have asked: ''how can I play online with my friends?''<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Advantages==<br />
* Allows live tutorials, like teaching new players how to dock with the ISS.<br />
* Have competitions, aerobatics air shows or races. <br />
* 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.<br />
* Use multiple computers for home cockpits.<br />
* have multiple players forming the crew for more complex spacecraft, for spreading the workload among them.<br />
<br />
==Hurdles==<br />
<br />
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.).<br />
<br />
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.<br />
<br />
So what?<br />
<br />
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.<br />
<br />
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!<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==The situation in Orbiter 2006==<br />
<br />
In [[Orbiter 2006]], the [[API]] got enhanced by functions for manipulating the simulation time.<br />
<br />
* [[oapiSetSimMJD]]<br />
* [[oapiTime2MJD]]<br />
* [[oapiSetPause]]<br />
* [[oapiGetPause]]<br />
* [[oapiGetSysMJD]]<br />
<br />
With this new set of functions, it is now possible to solve some of the synchronization problems in earlier versions of [[Orbiter]]. <br />
<br />
==Attempts==<br />
<br />
*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.<br />
*[[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.<br />
*[[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.<br />
*[[Orbiter MMORPG]] is an attempt on creating a full-fledged multiplayer "game" within the Orbiter environment.<br />
*[[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].<br />
<br />
No comprehensive product has yet been produced, and consequently this area of Orbiter development should still be considered experimental.<br />
<br />
==See also==<br />
<br />
[[:Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=14161OMP2012-03-05T11:20:56Z<p>Face: Updated information for 0.6.1 and removed obsolete installation procedure</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://bitbucket.org/face/orl-online http://bitbucket.org/face/orl-online]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods<br />
--------<br />
==Status==<br />
As of March 2012, software development is ongoing by means of a [http://bitbucket.org/face/omp BitBucket project]. Both server and client software were rewritten using .NET technology.<br />
<br />
In early December 2008, a [http://bitbucket.org/face/orl-online fork] called ORRL (Orbiter Rocket Racing League) was established - consisting of additional content by various other developers - to create a more intriguing environment for online racing competition. This is based on the ORRL ideas introduced in [http://orbiter-forum.com/showthread.php?t=5490 Orbiter-Forum].<br />
This branch of OMP was updated recently (January 2011) to stabilize the system for the purpose of online racing and make it compatible with Orbiter 2010.<br />
<br />
==Networking issues==<br />
<br />
From the 0.6.1 version on, most NAT problems are worked around by means of hole-punching and STUN analysis. OMP sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is also used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the the right class (mesh) and name of the neighbor vessels are to be seen, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the appropriate space-time bubble’s MJD (currently there is only one globally available server bubble). The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). Concurrently, all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body.<br />
<br />
The server decides, what vessel is in visible range of what other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). It consists of a target vessel ID (the vessel of the receiver client), a source vessel ID (the vessel of the sender client) and IP and port of the receiver client the sender should send to. Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client.<br />
There are 5 reasons to send an absolute SI instead of a relative one:<br />
* The source vessel is not in the same space-time bubble – regarding space – as the target vessel. This is merely indicated by different gravitational bodies.<br />
* The target vessel is not available right now – if there was no absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it is not possible to calculate relative coordinates.<br />
* The source vessel velocity w.r.t. the gravitational body is smaller than 1000 m/s. This is considered “non-orbital speed” and should be within the tolerance of the established synchronization.<br />
* A jump command is running.<br />
* The distance between source and target vessel is greater than the sub-visual range, or the velocity difference between source and target is greater than 1000 m/s. The sub-visual range 𝑑 in meter is determined by:<br />
** the current simulation’s viewport high ℎ in pixels,<br />
** the current field of view 𝑓𝑜𝑣 in degree,<br />
** the maximum size of both vessels 𝑠 in meter and<br />
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP. However, SI information is only taken into account if:<br />
* the reference object is available,<br />
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and<br />
* the vessel to be updated is no superstructure slave.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
==Online Servers==<br />
[http://omp.dyndns-server.com http://omp.dyndns-server.com]<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=13573OMP2011-06-21T09:08:47Z<p>Face: /* Status */</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
==Status==<br />
As of June 2011, software development is ongoing by means of a [http://bitbucket.org/face/omp BitBucket project]. Both server and client software were rewritten using .NET technology.<br />
<br />
In early December 2008, a [http://bitbucket.org/face/orl-online fork] called ORRL (Orbiter Rocket Racing League) was established - consisting of additional content by various other developers - to create a more intriguing environment for online racing competition. This is based on the ORRL ideas introduced in [http://orbiter-forum.com/showthread.php?t=5490 Orbiter-Forum].<br />
This branch of OMP was updated recently (January 2011) to stabilize the system for the purpose of online racing and make it compatible with Orbiter 2010.<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the client wants to see the right class (mesh) and name of its neighbor vessels, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the server’s MJD – being a fault tolerant average of all client’s MJDs. The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). As soon as a client is in sync with the server regarding MJD (i.e. all celestial bodies are in proper position), all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body with major influence.<br />
<br />
The server decides, which vessel is in visible range of which other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client, depending on:<br />
* the velocity of the vessel w.r.t. the gravitational body – currently everything below 1000 m/s is considered “non-orbital speed”, therefore absolute coordinates can be transmitted – and<br />
* the availability of the target vessel (i.e., the vessel of the neighbor client) – if there wasn't an absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it can not calculate relative coordinates.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
In order to automate the above mentioned steps for login and logoff, the client software uses the following procedure for instant Orbiter scenario launch:<br />
After the [[multi-player]] session scenario has been generated with a special name (“$Multiplayer session$” ensures the scenario showing up as first entry in the scenario list in the launch pad), the system remote-controls the Orbiter launchpad to select that scenario and launches the simulation. The same remote-controlling ensures, that no other scenario can be launched in the meantime by disabling the appropriate buttons and controls.<br />
<br />
==Online Servers==<br />
There are no public servers available at the moment.<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=13572OMP2011-06-21T09:03:16Z<p>Face: Online Servers update</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
==Status==<br />
As of January 2011, software development is ongoing by means of a [http://bitbucket.org/face/omp BitBucket project]. Both server and client software were rewritten using .NET technology.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta-test team using the newest client snapshots.<br />
<br />
In early December 2008, a [http://bitbucket.org/face/orl-online fork] called ORRL (Orbiter Rocket Racing League) was established - consisting of additional content by various other developers - to create a more intriguing environment for online racing competition. This is based on the ORRL ideas introduced in [http://orbiter-forum.com/showthread.php?t=5490 Orbiter-Forum].<br />
This branch of OMP was updated recently (January 2011) to stabilize the system for the purpose of online racing and make it compatible with Orbiter 2010.<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the client wants to see the right class (mesh) and name of its neighbor vessels, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the server’s MJD – being a fault tolerant average of all client’s MJDs. The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). As soon as a client is in sync with the server regarding MJD (i.e. all celestial bodies are in proper position), all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body with major influence.<br />
<br />
The server decides, which vessel is in visible range of which other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client, depending on:<br />
* the velocity of the vessel w.r.t. the gravitational body – currently everything below 1000 m/s is considered “non-orbital speed”, therefore absolute coordinates can be transmitted – and<br />
* the availability of the target vessel (i.e., the vessel of the neighbor client) – if there wasn't an absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it can not calculate relative coordinates.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
In order to automate the above mentioned steps for login and logoff, the client software uses the following procedure for instant Orbiter scenario launch:<br />
After the [[multi-player]] session scenario has been generated with a special name (“$Multiplayer session$” ensures the scenario showing up as first entry in the scenario list in the launch pad), the system remote-controls the Orbiter launchpad to select that scenario and launches the simulation. The same remote-controlling ensures, that no other scenario can be launched in the meantime by disabling the appropriate buttons and controls.<br />
<br />
==Online Servers==<br />
There are no public servers available at the moment.<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=13223OMP2011-01-04T16:44:13Z<p>Face: Updated status</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
==Status==<br />
As of January 2011, software development is ongoing by means of a [http://bitbucket.org/face/omp BitBucket project]. Both server and client software were rewritten using .NET technology.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta-test team using the newest client snapshots.<br />
<br />
In early December 2008, a [http://bitbucket.org/face/orl-online fork] called ORRL (Orbiter Rocket Racing League) was established - consisting of additional content by various other developers - to create a more intriguing environment for online racing competition. This is based on the ORRL ideas introduced in [http://orbiter-forum.com/showthread.php?t=5490 Orbiter-Forum].<br />
This branch of OMP was updated recently (January 2011) to stabilize the system for the purpose of online racing and make it compatible with Orbiter 2010.<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the client wants to see the right class (mesh) and name of its neighbor vessels, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the server’s MJD – being a fault tolerant average of all client’s MJDs. The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). As soon as a client is in sync with the server regarding MJD (i.e. all celestial bodies are in proper position), all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body with major influence.<br />
<br />
The server decides, which vessel is in visible range of which other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client, depending on:<br />
* the velocity of the vessel w.r.t. the gravitational body – currently everything below 1000 m/s is considered “non-orbital speed”, therefore absolute coordinates can be transmitted – and<br />
* the availability of the target vessel (i.e., the vessel of the neighbor client) – if there wasn't an absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it can not calculate relative coordinates.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
In order to automate the above mentioned steps for login and logoff, the client software uses the following procedure for instant Orbiter scenario launch:<br />
After the [[multi-player]] session scenario has been generated with a special name (“$Multiplayer session$” ensures the scenario showing up as first entry in the scenario list in the launch pad), the system remote-controls the Orbiter launchpad to select that scenario and launches the simulation. The same remote-controlling ensures, that no other scenario can be launched in the meantime by disabling the appropriate buttons and controls.<br />
<br />
==Online Servers==<br />
There is one public server available at the moment. For more information goto [http://orbiter-forum.com/blog.php?u=91 deltawing777 blog].<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=Orbiter_MMORPG&diff=12732Orbiter MMORPG2009-11-22T10:53:46Z<p>Face: Put Brad Hawthorne's vision in place.</p>
<hr />
<div>=Orbiter MMORPG=<br />
<br />
'''Orbiter MMORPG''' started in a [[http://orbiter-forum.com/showthread.php?t=11137 thread on Orbiter-Forums]], bringing up the idea of Orbiter role playing in a persistent universe for what seemed like the 100th time. What followed was a discussion about why nobody is actually doing the work instead of only talking. Some users actually plucked up their courage and started to outline their ideas properly.<br />
<br />
This page tries to be both a collaboration point for the development of a design document and a reference for future discussions on the topic.<br />
<br />
The following topics present the ideas of certain users.<br />
<br />
==Kaito's Idea of an Orbiter Multiplayer Platform==<br />
This was made by Kaito from Orbiter-Forum on November 15th, 2009.<br />
<br />
Following a discussion on Orbiter-Forum, someone though of a Orbiter RPG. Everyone pointed him to these multiplayer links. However, if you think about it, there can be two different idea's for multiplayer: an "Orbiter" type multiplayer, where there are no set goals, the goals are made by your brain, or an "RPG" type multiplayer, where you have a goal, no matter how small or insignificant. A common "goal" in most MMORPG's is to become stronger. A goal for an RPG Style Orbiter would be to, say, make a base on the moon, or keep some explorers alive by sending supplies.<br />
<br />
===Synchronizing time===<br />
I have a feeling this would be "simple" (I am not a coder, so I don't know to much about this): Have a server, and when someone connects to this server, change the clients time to the servers time<br />
<br />
===Lag===<br />
Eve Online has exactly one server, and they can support more then 40,000 people on it. Why? Because they have over 1,500 "solar systems", each with their own stations, asteroid belts, etc. All these are "hubs", where nearly everyone gathers. Almost no one is in between these "hubs". If you are not inside one of these "hubs", the ships aren't rendered, so there isn't much lag caused by one client. This same sort of idea can be used in orbiter: Don't retrieve information on it unless it is within rendering range. Now, of course, this causes a problem when you are going to the ISS, and there are 15 people in line, waiting to dock. If this is the case, maybe intentionally slow-down the information sent to the Client. Example: The Rendering Distance is 100km. You are 101km away from ISS, just passing into Rendering Distance now. There are 15 people around the ISS currently, which would surely slow-down your client if the information was sent all at once. So, orbiter renders each ship "separately" based on a "Level of Importance". The ISS would be rendered first, then maybe at 95km, another ship, then at 90km, another ship. This way, You would still see all the ships in time to make adjustments, but your client wasn't flooded all at once with a bunch of information that wont be useful until later. <br />
<br />
===Goals===<br />
The idea of goals and consequences could be what drives Orbiter Multiplayer. Forgetting to de-orbit your fuel tank and having it be a problem for the next guy could lead to a bunch of different things (Space Terrorism and Grieving (Intentionally causing other players to have a bad time)). However, teamwork could also arise: Trying to build a space station by yourself would be difficult, so you would need more people to help construct it, launch, monitor, etc.<br />
<br />
===Time Acceleration===<br />
The nice thing about Orbiter is the ability to make time go fast. You can land on the moon and be back in time for lunch. However, this causes an obvious problem in multiplayer. However, I think this could be resolved in some sort of way:<br />
1) Confine most things to Earth and Moon. If someone has the time and patience to go to Mars, no one is stopping them, but it would be a boring 7 months.<br />
2) If someone would like to time accelerate, put in a "request", which would be sent to everyone on the server at the time. If there is one "decline", then the time acceleration would not go through, until everyone agreed. The "request" would state the degree(10x, 100000x) and time (5 seconds, 10 seconds) of the acceleration.<br />
3) "Off-line" people would be affected by this acceleration, but they could not vote. They would be subject to the needs of everyone else<br />
3.1) This poses a problem. Lets say someone is going to the moon, and they log off. The next day they log on to find out they already passed the moon because of an un-natural amount of time acceleration by other players. I think people would learn that this is a necessary evil of time acceleration<br />
4) Abuse of the system: Yes, people could abuse it, but that's what fair moderators are for.<br />
<br />
== [http://orbiter-forum.com/showthread.php?p=133982 Orbiter Online - Milestone 0 Goals Thread] by Brad Hawthorne ==<br />
<br />
===0. Define the purpose, scope and background of the add-on===<br />
Orbiter Online is to be a set of add-ons for the Orbiter simulator. The purpose of the project is to add another layer of complexity and interest for the Orbiter community to enjoy, help build and be a part of. This is merely adding a social aspect to the simulator and a few systems to give meaning to flying other than just because you can. We could easily design something too complex to implement -- which is not what I want to see. I'd like to see us come up with something both feasible and fun that can plug into Orbiter.<br />
<br />
It is the near future. Earth still has the current political structure as present day but we're just now establishing semi-permanent commercial footholds in Earth orbit, the Lunar surface, Mars surface and certain portions of the asteroid belt.<br />
<br />
Earth Initiatives: There have been incentives pushed for low and null gravity manufacturing and production of products outside the Earth gravity well. Also certain factions of Earth government are pushing a "clean Earth" initiative that seeks off-Earth resources to replace and phase out many of the resource dependencies that drive the Earth economy. A shift from terrestrial coal and fossil fuels to new resources that can be found on the Moon or other places within the solar system.<br />
<br />
Lunar and Mars Initiatives: The Moon and Mars also have colonization initiatives currently in place to seek development on those locations. Resources on both locations are in high demand to accomplish colonization goals and establish on-site industrial base for futher expansion.<br />
<br />
Outer-Rim Initiatives: Why not have a wild outer rim, without established big bases like in the inner solar system, but instead some island-like wild settlements, like for example the Jovian or Kronian system. After all, it would be some sort of gentrification in the solar system, if you politically start out like that - bigger companies that take less risks would displace smaller, more risk-seeking companies, forcing them further outward for not getting into lossy competition with the big ones. Of course, you would then need also ship wharfs and factories, which would be more around Earth, but maybe establishing small wharfs and factories outside the inner solar system might offer some good plots.<br />
<br />
===1. Define core developer positions for the add-on===<br />
<br />
* '''Project Coordinator''' - A position meant to help steer the overall project and play cat herder as needed with project devs and resources.<br />
* '''Programmer''' - The key people who take the concepts and make them reality. This would be a title that would cover aspects such as server programmer, add-on programmer, voice-chat integration programmer, etc...<br />
* '''Media Artist''' - Works on both 2D and 3D art assets for the add-on. Includes a wide range of media assets for user interface, cockpit panels, ship models, etc...<br />
* '''Systems Designer''' - A catch-all title for those with interest in helping with the theoretical aspects of the add-on design including but not limited to all aspects of the game such as economy, building, corporations, mining, construction and anything in-between. Systems mechanics and how those systems interact.<br />
* '''Quality Control''' - A group of people within the dev pool that test all aspect of the add-on and notify the dev pool if any bugs or balance issues need to be addressed. This would also be the group who would test out individual add-on assets for compatibility with the Orbiter Online add-on to make sure there are no incompatibilities.<br />
<br />
===2. Define the sub-systems of the add-on===<br />
<br />
* '''Key Add-On Systems''' - Economy, Communication, Quests, News<br />
* '''Economy''' - Establish and define a system based on finite resources, the exploration of the resources and the ability to harvest them. Have the further ability to manufacture useful items from those base resources though construction and manufacturing mechanics. Impose a supply and demand mechanic on every entity in the add-on.<br />
* '''Communication''' - Define the ways communication could occur within the add-on. Text communication could be piped in via an IRC interface and voice chat could be integrated via either ventrillo or teamspeak SDK with appropriate time delays enforced within the client-server design. An email system might also be useful to explore.<br />
* '''Quests''' - I envision the quest system for the add-on to use dynamic player generated content based on supply-demand needs of the playerbase. Quest content could also be generated by News events or goals internal to your corporation or country affiliation. Quests could be at the level of plots and missions. Plots would be elements of a bigger storyline, while missions happen in between and only have side effects on the plots.<br />
* '''News''' - Current events and how they unfold within the add-on is an important aspect to give meaning to the interaction in the add-on. While supply-demand mechanics will drive much activity being made aware of such supply-demand issues via add-on News will also be important.<br />
<br />
===3. Put infrastructure in place for dev group to communicate===<br />
<br />
* '''Forums''' - Face has offered use of the OMP sub-forums for this.<br />
* '''IRC''' - irc.orbithangar.com #orbiter-online<br />
* '''VoIP''' - VoIP embedded in multiplayer framework as needed.<br />
* '''Wiki''' - To help document the add-on<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[OMP]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=12731OMP2009-11-22T10:25:23Z<p>Face: Added MMORPG link</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
==Status==<br />
As of January 2009, software development is ongoing by means of a [http://bitbucket.org/face/omp BitBucket project]. Both server and client software were rewritten using .NET technology. At this time no public servers are known. Some [[Virtual space agency|Virtual space agencies]] used OMP for their missions before public development was closed.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta-test team using the newest client snapshots.<br />
<br />
In early December 2008, a [http://bitbucket.org/face/orrl fork] called ORRL (Orbiter Rocket Racing League) was established - consisting of additional content by various other developers - to create a more intriguing environment for online racing competition. This is based on the ORRL ideas introduced in [http://orbiter-forum.com/showthread.php?t=5490 Orbiter-Forum].<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the client wants to see the right class (mesh) and name of its neighbor vessels, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the server’s MJD – being a fault tolerant average of all client’s MJDs. The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). As soon as a client is in sync with the server regarding MJD (i.e. all celestial bodies are in proper position), all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body with major influence.<br />
<br />
The server decides, which vessel is in visible range of which other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client, depending on:<br />
* the velocity of the vessel w.r.t. the gravitational body – currently everything below 1000 m/s is considered “non-orbital speed”, therefore absolute coordinates can be transmitted – and<br />
* the availability of the target vessel (i.e., the vessel of the neighbor client) – if there wasn't an absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it can not calculate relative coordinates.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
In order to automate the above mentioned steps for login and logoff, the client software uses the following procedure for instant Orbiter scenario launch:<br />
After the [[multi-player]] session scenario has been generated with a special name (“$Multiplayer session$” ensures the scenario showing up as first entry in the scenario list in the launch pad), the system remote-controls the Orbiter launchpad to select that scenario and launches the simulation. The same remote-controlling ensures, that no other scenario can be launched in the meantime by disabling the appropriate buttons and controls.<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Orbiter MMORPG]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=Orbiter_MMORPG&diff=12730Orbiter MMORPG2009-11-22T10:20:34Z<p>Face: Moved Kaito's idea to here.</p>
<hr />
<div>==Kaito's Idea of an Orbiter Multiplayer Platform==<br />
This was made by Kaito from Orbiter-Forum on November 15th, 2009.<br />
<br />
Following a discussion on Orbiter-Forum, someone though of a Orbiter RPG. Everyone pointed him to these multiplayer links. However, if you think about it, there can be two different idea's for multiplayer: an "Orbiter" type multiplayer, where there are no set goals, the goals are made by your brain, or an "RPG" type multiplayer, where you have a goal, no matter how small or insignificant. A common "goal" in most MMORPG's is to become stronger. A goal for an RPG Style Orbiter would be to, say, make a base on the moon, or keep some explorers alive by sending supplies.<br />
<br />
===Synchronizing time===<br />
I have a feeling this would be "simple" (I am not a coder, so I don't know to much about this): Have a server, and when someone connects to this server, change the clients time to the servers time<br />
<br />
===Lag===<br />
Eve Online has exactly one server, and they can support more then 40,000 people on it. Why? Because they have over 1,500 "solar systems", each with their own stations, asteroid belts, etc. All these are "hubs", where nearly everyone gathers. Almost no one is in between these "hubs". If you are not inside one of these "hubs", the ships aren't rendered, so there isn't much lag caused by one client. This same sort of idea can be used in orbiter: Don't retrieve information on it unless it is within rendering range. Now, of course, this causes a problem when you are going to the ISS, and there are 15 people in line, waiting to dock. If this is the case, maybe intentionally slow-down the information sent to the Client. Example: The Rendering Distance is 100km. You are 101km away from ISS, just passing into Rendering Distance now. There are 15 people around the ISS currently, which would surely slow-down your client if the information was sent all at once. So, orbiter renders each ship "separately" based on a "Level of Importance". The ISS would be rendered first, then maybe at 95km, another ship, then at 90km, another ship. This way, You would still see all the ships in time to make adjustments, but your client wasn't flooded all at once with a bunch of information that wont be useful until later. <br />
<br />
===Goals===<br />
The idea of goals and consequences could be what drives Orbiter Multiplayer. Forgetting to de-orbit your fuel tank and having it be a problem for the next guy could lead to a bunch of different things (Space Terrorism and Grieving (Intentionally causing other players to have a bad time)). However, teamwork could also arise: Trying to build a space station by yourself would be difficult, so you would need more people to help construct it, launch, monitor, etc.<br />
<br />
===Time Acceleration===<br />
The nice thing about Orbiter is the ability to make time go fast. You can land on the moon and be back in time for lunch. However, this causes an obvious problem in multiplayer. However, I think this could be resolved in some sort of way:<br />
1) Confine most things to Earth and Moon. If someone has the time and patience to go to Mars, no one is stopping them, but it would be a boring 7 months.<br />
2) If someone would like to time accelerate, put in a "request", which would be sent to everyone on the server at the time. If there is one "decline", then the time acceleration would not go through, until everyone agreed. The "request" would state the degree(10x, 100000x) and time (5 seconds, 10 seconds) of the acceleration.<br />
3) "Off-line" people would be affected by this acceleration, but they could not vote. They would be subject to the needs of everyone else<br />
3.1) This poses a problem. Lets say someone is going to the moon, and they log off. The next day they log on to find out they already passed the moon because of an un-natural amount of time acceleration by other players. I think people would learn that this is a necessary evil of time acceleration<br />
4) Abuse of the system: Yes, people could abuse it, but that's what fair moderators are for</div>Facehttps://www.orbiterwiki.org/index.php?title=Multi-player&diff=12729Multi-player2009-11-22T10:19:57Z<p>Face: Moved Kaito's idea to MMORPG page</p>
<hr />
<div>==Background==<br />
Pretty much since the dawn of [[Orbiter]], users have asked: ''how can I play online with my friends?''<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Advantages==<br />
* Allows live tutorials, like teaching new players how to dock with the ISS.<br />
* Have competitions, aerobatics air shows or races. <br />
* 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.<br />
* Use multiple computers for home cockpits.<br />
* have multiple players forming the crew for more complex spacecraft, for spreading the workload among them.<br />
<br />
==Hurdles==<br />
<br />
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.).<br />
<br />
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.<br />
<br />
So what?<br />
<br />
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.<br />
<br />
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!<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==The situation in Orbiter 2006==<br />
<br />
In [[Orbiter 2006]], the [[API]] got enhanced by functions for manipulating the simulation time.<br />
<br />
* [[oapiSetSimMJD]]<br />
* [[oapiTime2MJD]]<br />
* [[oapiSetPause]]<br />
* [[oapiGetPause]]<br />
* [[oapiGetSysMJD]]<br />
<br />
With this new set of functions, it is now possible to solve some of the synchronization problems in earlier versions of [[Orbiter]]. <br />
<br />
==Attempts==<br />
<br />
*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.<br />
*[[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.<br />
*[[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, however as of April 2007, this development has been made private and the system is not available for public download.<br />
*[[Orbiter MMORPG]] is an attempt on creating a full-fledged multiplayer "game" within the Orbiter environment.<br />
*[[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].<br />
<br />
No comprehensive product has yet been produced, and consequently this area of Orbiter development should still be considered experimental.<br />
<br />
==See also==<br />
<br />
[[:Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=Multi-player&diff=12728Multi-player2009-11-22T10:18:43Z<p>Face: Added MMORPG page.</p>
<hr />
<div>==Background==<br />
Pretty much since the dawn of [[Orbiter]], users have asked: ''how can I play online with my friends?''<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Advantages==<br />
* Allows live tutorials, like teaching new players how to dock with the ISS.<br />
* Have competitions, aerobatics air shows or races. <br />
* 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.<br />
* Use multiple computers for home cockpits.<br />
* have multiple players forming the crew for more complex spacecraft, for spreading the workload among them.<br />
<br />
==Hurdles==<br />
<br />
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.).<br />
<br />
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.<br />
<br />
So what?<br />
<br />
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.<br />
<br />
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!<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==The situation in Orbiter 2006==<br />
<br />
In [[Orbiter 2006]], the [[API]] got enhanced by functions for manipulating the simulation time.<br />
<br />
* [[oapiSetSimMJD]]<br />
* [[oapiTime2MJD]]<br />
* [[oapiSetPause]]<br />
* [[oapiGetPause]]<br />
* [[oapiGetSysMJD]]<br />
<br />
With this new set of functions, it is now possible to solve some of the synchronization problems in earlier versions of [[Orbiter]]. <br />
<br />
==Attempts==<br />
<br />
*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.<br />
*[[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.<br />
*[[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, however as of April 2007, this development has been made private and the system is not available for public download.<br />
*[[Orbiter MMORPG]] is an attempt on creating a full-fledged multiplayer "game" within the Orbiter environment.<br />
*[[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].<br />
<br />
No comprehensive product has yet been produced, and consequently this area of Orbiter development should still be considered experimental.<br />
<br />
==Kaito's Idea of an Orbiter Multiplayer Platform==<br />
This was made by Kaito from Orbiter-Forum on November 15th, 2009.<br />
<br />
Following a discussion on Orbiter-Forum, someone though of a Orbiter RPG. Everyone pointed him to these multiplayer links. However, if you think about it, there can be two different idea's for multiplayer: an "Orbiter" type multiplayer, where there are no set goals, the goals are made by your brain, or an "RPG" type multiplayer, where you have a goal, no matter how small or insignificant. A common "goal" in most MMORPG's is to become stronger. A goal for an RPG Style Orbiter would be to, say, make a base on the moon, or keep some explorers alive by sending supplies.<br />
<br />
===Synchronizing time===<br />
I have a feeling this would be "simple" (I am not a coder, so I don't know to much about this): Have a server, and when someone connects to this server, change the clients time to the servers time<br />
<br />
===Lag===<br />
Eve Online has exactly one server, and they can support more then 40,000 people on it. Why? Because they have over 1,500 "solar systems", each with their own stations, asteroid belts, etc. All these are "hubs", where nearly everyone gathers. Almost no one is in between these "hubs". If you are not inside one of these "hubs", the ships aren't rendered, so there isn't much lag caused by one client. This same sort of idea can be used in orbiter: Don't retrieve information on it unless it is within rendering range. Now, of course, this causes a problem when you are going to the ISS, and there are 15 people in line, waiting to dock. If this is the case, maybe intentionally slow-down the information sent to the Client. Example: The Rendering Distance is 100km. You are 101km away from ISS, just passing into Rendering Distance now. There are 15 people around the ISS currently, which would surely slow-down your client if the information was sent all at once. So, orbiter renders each ship "separately" based on a "Level of Importance". The ISS would be rendered first, then maybe at 95km, another ship, then at 90km, another ship. This way, You would still see all the ships in time to make adjustments, but your client wasn't flooded all at once with a bunch of information that wont be useful until later. <br />
<br />
===Goals===<br />
The idea of goals and consequences could be what drives Orbiter Multiplayer. Forgetting to de-orbit your fuel tank and having it be a problem for the next guy could lead to a bunch of different things (Space Terrorism and Grieving (Intentionally causing other players to have a bad time)). However, teamwork could also arise: Trying to build a space station by yourself would be difficult, so you would need more people to help construct it, launch, monitor, etc.<br />
<br />
===Time Acceleration===<br />
The nice thing about Orbiter is the ability to make time go fast. You can land on the moon and be back in time for lunch. However, this causes an obvious problem in multiplayer. However, I think this could be resolved in some sort of way:<br />
1) Confine most things to Earth and Moon. If someone has the time and patience to go to Mars, no one is stopping them, but it would be a boring 7 months.<br />
2) If someone would like to time accelerate, put in a "request", which would be sent to everyone on the server at the time. If there is one "decline", then the time acceleration would not go through, until everyone agreed. The "request" would state the degree(10x, 100000x) and time (5 seconds, 10 seconds) of the acceleration.<br />
3) "Off-line" people would be affected by this acceleration, but they could not vote. They would be subject to the needs of everyone else<br />
3.1) This poses a problem. Lets say someone is going to the moon, and they log off. The next day they log on to find out they already passed the moon because of an un-natural amount of time acceleration by other players. I think people would learn that this is a necessary evil of time acceleration<br />
4) Abuse of the system: Yes, people could abuse it, but that's what fair moderators are for<br />
<br />
==See also==<br />
<br />
[[:Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=12442OMP2009-01-24T19:18:53Z<p>Face: Status update</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
==Status==<br />
As of January 2009, software development is ongoing by means of a [http://bitbucket.org/face/omp BitBucket project]. Both server and client software were rewritten using .NET technology. At this time no public servers are known. Some [[Virtual space agency|Virtual space agencies]] used OMP for their missions before public development was closed.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta-test team using the newest client snapshots.<br />
<br />
In early December 2008, a [http://bitbucket.org/face/orrl fork] called ORRL (Orbiter Rocket Racing League) was established - consisting of additional content by various other developers - to create a more intriguing environment for online racing competition. This is based on the ORRL ideas introduced in [http://orbiter-forum.com/showthread.php?t=5490 Orbiter-Forum].<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the client wants to see the right class (mesh) and name of its neighbor vessels, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the server’s MJD – being a fault tolerant average of all client’s MJDs. The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). As soon as a client is in sync with the server regarding MJD (i.e. all celestial bodies are in proper position), all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body with major influence.<br />
<br />
The server decides, which vessel is in visible range of which other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client, depending on:<br />
* the velocity of the vessel w.r.t. the gravitational body – currently everything below 1000 m/s is considered “non-orbital speed”, therefore absolute coordinates can be transmitted – and<br />
* the availability of the target vessel (i.e., the vessel of the neighbor client) – if there wasn't an absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it can not calculate relative coordinates.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
In order to automate the above mentioned steps for login and logoff, the client software uses the following procedure for instant Orbiter scenario launch:<br />
After the [[multi-player]] session scenario has been generated with a special name (“$Multiplayer session$” ensures the scenario showing up as first entry in the scenario list in the launch pad), the system remote-controls the Orbiter launchpad to select that scenario and launches the simulation. The same remote-controlling ensures, that no other scenario can be launched in the meantime by disabling the appropriate buttons and controls.<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=12272OMP2008-11-17T12:54:54Z<p>Face: Updated current project status.</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
'''OMP''' was announced on [[IRC]] as project to 'properly' execute a [[Multi-player|multi-player]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multi-player projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multi-player]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Version history==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
==Status==<br />
As of November 2008, software development is ongoing by means of a [http://sourceforge.net/projects/orbitermp SourceForge project]. Both server and client software were rewritten using .NET technology. At this time no public servers are known. Some [[Virtual space agency|Virtual space agencies]] used OMP for their missions before public development was closed.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta-test team using the newest client snapshots.<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multi-player]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the client wants to see the right class (mesh) and name of its neighbor vessels, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multi-player]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the server’s MJD – being a fault tolerant average of all client’s MJDs. The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). As soon as a client is in sync with the server regarding MJD (i.e. all celestial bodies are in proper position), all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body with major influence.<br />
<br />
The server decides, which vessel is in visible range of which other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client, depending on:<br />
* the velocity of the vessel w.r.t. the gravitational body – currently everything below 1000 m/s is considered “non-orbital speed”, therefore absolute coordinates can be transmitted – and<br />
* the availability of the target vessel (i.e., the vessel of the neighbor client) – if there wasn't an absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it can not calculate relative coordinates.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
In order to automate the above mentioned steps for login and logoff, the client software uses the following procedure for instant Orbiter scenario launch:<br />
After the [[multi-player]] session scenario has been generated with a special name (“$Multiplayer session$” ensures the scenario showing up as first entry in the scenario list in the launch pad), the system remote-controls the Orbiter launchpad to select that scenario and launches the simulation. The same remote-controlling ensures, that no other scenario can be launched in the meantime by disabling the appropriate buttons and controls.<br />
<br />
==See also==<br />
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter<br />
* [[IRCMFD]]<br />
* [[Multiorb]]<br />
* [[Project Hamac]]<br />
<br />
[[Category:Add-ons]]<br />
[[Category:Multi-player add-ons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=6299OMP2007-02-01T21:10:59Z<p>Face: Added version history, technology section and some pictures</p>
<hr />
<div>[[Image:ompgui.png|thumb|right|OMP client's user interface .]]<br />
<br />
{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
==History==<br />
OMP was announced on [[IRC]] as project to 'properly' execute a [[Multiplayer|multiplayer]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multiplayer projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter [[multiplayer]] system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Versions==<br />
* '''V0.1''' - 2005-09-06 Alpha release<br />
* '''V0.1''' - 2005-09-09 Patch 1: Buffer sizes has been increased to 4096 in order to allow longer startup messages on server. Documentation extended with checklists.<br />
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.<br />
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations<br />
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file<br />
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too<br />
--------<br />
* '''V0.2''' - 2006-04-23 Second alpha release<br />
* '''V0.2''' - 2006-04-27 Patch 1: Fixed a problem with OMPDefault.cfg; fixed a server security breach; implemented a 5s delay of absolute-only transmission after a jump in order to allow re-jump and jump to another (far away) vessel of the same client<br />
* '''V0.2''' - 2006-05-02 Patch 2: Fixed a problem with server's sync controller, causing indeterministic CTDs after some time; added main thruster groups level transmission - now you can see particle streams of remote vessels and attitude bursts<br />
--------<br />
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team<br />
--------<br />
==Status==<br />
As of January 2007, development is ongoing but closed to the public. At this time no public servers are known. Some [[Virtual space agency|Virtual space agencies]] used OMP for their missions before public development was closed.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta-test team using the newest client snapshots.<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
<br />
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]<br />
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]<br />
<br />
==Technology==<br />
<br />
The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses [[w:SNTP|SNTP]] timeservers to synchronize both clients and server to [[w:UTC|UTC]]. The 3 elements in the concept – client, server and timeserver – can be seen in figure to the right.<br />
<br />
Not shown in this sketch is the communication between clients. This communication is similar to the [[w:UDP|UDP]] transmissions between client and server.<br />
<br />
Basically, there is one server hosting a “universe” for all connected clients. This “universe” is a specific Orbiter configuration and should be known by every client. I.e., every client must know what Orbiter configuration it has to start before it connects to the server. This will be changed in later versions towards automatic negotiation in order to assure proper client/server configurations.<br />
<br />
Clients start a [[w:TCP|TCP]] session with the appropriate server and can check out the server environment (users, information about vessels, scenario information etc.) similar to an [[IRC]] or [[w:telnet|telnet]] session. They actually join the [[multiplayer]] session by sending an appropriate command followed by their name, password and receiving port. The server responds with the reserved receiving port on the server side. Clients can then start the actual simulation link.<br />
<br />
The TCP session is used for transmission of text information of any kind to keep UDP packet sizes small. An open TCP session is therefore a must, if the client wants to see the right class (mesh) and name of its neighbour vessels, because this text information is transmitted via TCP rather than UDP with an automated negotiation sequence.<br />
<br />
As soon as a client joins the [[multiplayer]] session, it tries to synchronize the simulation’s [[w:MJD|MJD]] to the server’s MJD – being a fault tolerant average of all client’s MJDs. The server transmits this information by means of a '''Keep Alive''' UDP packet (KA). As soon as a client is in sync with the server regarding MJD (i.e. all celestial bodies are in proper position), all vessels hosted by the client are transmitted to the server by means of the absolute position w.r.t. the appropriate gravitational body with major influence.<br />
<br />
The server decides, which vessel is in visible range of which other vessel and transmits the appropriate information by means of a '''Group Information''' UDP packet (GI). Each client processes it’s GI list and sends either an absolute or a relative '''State Information''' UDP packet (SI) to the neighbor client, depending on:<br />
* the velocity of the vessel w.r.t. the gravitational body – currently everything below 1000 m/s is considered “non-orbital speed”, therefore absolute coordinates can be transmitted – and<br />
* the availability of the target vessel (i.e., the vessel of the neighbor client) – if there wasn't an absolute coordinates transmission before, the target vessel is not visible to the client yet, therefore it can not calculate relative coordinates.<br />
<br />
If a client receives an SI, it creates or updates the appropriate vessel with a generic name (based on the global ID of the vessel) and a default class. This default vessel will be exchanged with the proper name and class later on, if the client was able to gather the information from the server via TCP.<br />
<br />
If streaming of SI or GI is interrupted (either because the server is offline, the neighbor client is offline or – less dramatically – the vessel is out of visible range) for more then 5 seconds, the appropriate vessel is removed.<br />
<br />
In order to automate the above mentioned steps for login and logoff, the client software uses the following procedure for instant Orbiter scenario launch:<br />
After the [[multiplayer]] session scenario has been generated with a special name (“$Multiplayer session$” ensures the scenario showing up as first entry in the scenario list in the launch pad), the system remote-controls the Orbiter launchpad to select that scenario and launches the simulation. The same remote-controlling ensures, that no other scenario can be launched in the meantime by disabling the appropriate buttons and controls.<br />
<br />
==See also==<br />
[[Multiplayer]] -- an overview of multiplayer addons for Orbiter<br />
<br />
[[IRCMFD]]<br />
<br />
[[Multiorb]]<br />
<br />
[[Project Hamac]]<br />
<br />
[[Category:Addons]]<br />
[[Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=File:ompserverhelp.png&diff=6298File:ompserverhelp.png2007-02-01T20:43:01Z<p>Face: A OMP server session showing the response to the '''help''' command.</p>
<hr />
<div>A OMP server session showing the response to the '''help''' command.</div>Facehttps://www.orbiterwiki.org/index.php?title=File:ompschematic.png&diff=6297File:ompschematic.png2007-02-01T20:13:47Z<p>Face: Schematic of OMP technology</p>
<hr />
<div>Schematic of OMP technology</div>Facehttps://www.orbiterwiki.org/index.php?title=File:ompgui.png&diff=6296File:ompgui.png2007-02-01T20:01:21Z<p>Face: GUI of OMP client</p>
<hr />
<div>GUI of OMP client</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=6295OMP2007-02-01T19:52:18Z<p>Face: Cleaned up the list a bit...</p>
<hr />
<div>{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
==History==<br />
OMP was announced on [[IRC]] as project to 'properly' execute a [[Multiplayer|multiplayer]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multiplayer projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter multiplayer system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Status==<br />
As of January 2007, development is ongoing but closed to the public. At this time no public servers are known. Some [[Virtual space agency|Virtual space agencies]] used OMP for their missions before public development was closed.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta test team using the newest client snapshots.<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* Remote vessel replication - see vessels of other clients inside your Orbiter session<br />
* Dock support<br />
* On-orbit and ground operations<br />
* Integrated text-based chat<br />
* "Jump" feature - jump to other vessels immediately to save time<br />
* Orbiter Playback function works with OMP<br />
* Support for different planetary systems<br />
<br />
==See also==<br />
[[Multiplayer]] -- an overview of multiplayer addons for Orbiter<br />
<br />
[[IRCMFD]]<br />
<br />
[[Multiorb]]<br />
<br />
[[Project Hamac]]<br />
<br />
[[Category:Addons]]<br />
[[Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=6294OMP2007-02-01T19:46:07Z<p>Face: Changed header for this outdated tutorial</p>
<hr />
<div>{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
==History==<br />
OMP was announced on [[IRC]] as project to 'properly' execute a [[Multiplayer|multiplayer]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multiplayer projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter multiplayer system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Status==<br />
As of January 2007, development is ongoing but closed to the public. At this time no public servers are known. Some [[Virtual space agency|Virtual space agencies]] used OMP for their missions before public development was closed.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta test team using the newest client snapshots.<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installing early versions==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* See other people online<br />
* "Jump" feature, so the users can jump to each other when ever they want<br />
* Dock with other users<br />
* Users can chat with each other<br />
* Orbiter Playback funtion works with OMP<br />
* Everything is in realtime<br />
* Support for different planetary systems<br />
<br />
==See also==<br />
[[Multiplayer]] -- an overview of multiplayer addons for Orbiter<br />
<br />
[[IRCMFD]]<br />
<br />
[[Multiorb]]<br />
<br />
[[Project Hamac]]<br />
<br />
[[Category:Addons]]<br />
[[Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=6293OMP2007-02-01T19:39:41Z<p>Face: /* Networking issues */</p>
<hr />
<div>{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
==History==<br />
OMP was announced on [[IRC]] as project to 'properly' execute a [[Multiplayer|multiplayer]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multiplayer projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter multiplayer system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Status==<br />
As of January 2007, development is ongoing but closed to the public. At this time no public servers are known. Some [[Virtual space agency|Virtual space agencies]] used OMP for their missions before public development was closed.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta test team using the newest client snapshots.<br />
<br />
==Networking issues==<br />
<br />
From the 0.2.2 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installation tutorial==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* See other people online<br />
* "Jump" feature, so the users can jump to each other when ever they want<br />
* Dock with other users<br />
* Users can chat with each other<br />
* Orbiter Playback funtion works with OMP<br />
* Everything is in realtime<br />
* Support for different planetary systems<br />
<br />
==See also==<br />
[[Multiplayer]] -- an overview of multiplayer addons for Orbiter<br />
<br />
[[IRCMFD]]<br />
<br />
[[Multiorb]]<br />
<br />
[[Project Hamac]]<br />
<br />
[[Category:Addons]]<br />
[[Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=6292OMP2007-02-01T19:38:34Z<p>Face: /* Status */</p>
<hr />
<div>{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
==History==<br />
OMP was announced on [[IRC]] as project to 'properly' execute a [[Multiplayer|multiplayer]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multiplayer projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter multiplayer system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Status==<br />
As of January 2007, development is ongoing but closed to the public. At this time no public servers are known. Some [[Virtual space agency|Virtual space agencies]] used OMP for their missions before public development was closed.<br />
<br />
The current development model consists of one private server - hosted by the author of OMP - and a beta test team using the newest client snapshots.<br />
<br />
==Networking issues==<br />
<br />
From the 0.3 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installation tutorial==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* See other people online<br />
* "Jump" feature, so the users can jump to each other when ever they want<br />
* Dock with other users<br />
* Users can chat with each other<br />
* Orbiter Playback funtion works with OMP<br />
* Everything is in realtime<br />
* Support for different planetary systems<br />
<br />
==See also==<br />
[[Multiplayer]] -- an overview of multiplayer addons for Orbiter<br />
<br />
[[IRCMFD]]<br />
<br />
[[Multiorb]]<br />
<br />
[[Project Hamac]]<br />
<br />
[[Category:Addons]]<br />
[[Category:Multiplayer addons]]</div>Facehttps://www.orbiterwiki.org/index.php?title=User:Face&diff=5985User:Face2006-10-16T19:27:15Z<p>Face: JumpDriveMFD released</p>
<hr />
<div>I am '''Face''' at almost every cyberspace place out there. This stupid-at-first-glance nickname is almost never occupied.<br />
<br />
== About Me ==<br />
My website URL is [http://www.snoopie.at/face/omp http://www.snoopie.at/face/omp] and was created for providing information about my (never-ending) project [[OMP]].<br />
<br />
== Contributions ==<br />
[[Special:Contributions/Face|Click Here]].<br />
<br />
== Orbiter Addons ==<br />
This is a list of my Orbiter addons - released and WIP:<br />
<br />
===Currently Released===<br />
*[[Shortcuts]] - Orbiter 2006 plugin that brings back the missing MFD mode selection shortcuts<br />
*[[InstantLaunch]] - Instant launch technology demonstrator<br />
*[[ReleaseMFD]] - Simple MFD mode for detaching the focussed vessel from all attachment parents<br />
*[[JumpDriveMFD]] - FTL transportation system<br />
<br />
===In Development===<br />
*[[OMP]] - the Orbiter [[multiplayer]] addon<br />
*[[BaseEditor]] - In-game surface base editor</div>Facehttps://www.orbiterwiki.org/index.php?title=User:Face&diff=5841User:Face2006-09-11T18:00:20Z<p>Face: </p>
<hr />
<div>I am '''Face''' at almost every cyberspace place out there. This stupid-at-first-glance nickname is almost never occupied.<br />
<br />
== About Me ==<br />
My website URL is [http://www.snoopie.at/face/omp http://www.snoopie.at/face/omp] and was created for providing information about my (never-ending) project [[OMP]].<br />
<br />
== Contributions ==<br />
[[Special:Contributions/Face|Click Here]].<br />
<br />
== Orbiter Addons ==<br />
This is a list of my Orbiter addons - released and WIP:<br />
<br />
===Currently Released===<br />
*[[Shortcuts]] - Orbiter 2006 plugin that brings back the missing MFD mode selection shortcuts<br />
*[[InstantLaunch]] - Instant launch technology demonstrator<br />
*[[ReleaseMFD]] - Simple MFD mode for detaching the focussed vessel from all attachment parents<br />
<br />
===In Development===<br />
*[[OMP]] - the Orbiter [[multiplayer]] addon<br />
*[[JumpDriveMFD]] - FTL transportation system<br />
*[[BaseEditor]] - In-game surface base editor</div>Facehttps://www.orbiterwiki.org/index.php?title=Talk:OMP&diff=5809Talk:OMP2006-09-07T18:38:25Z<p>Face: /* New status */</p>
<hr />
<div>==New status==<br />
<br />
Because public development has been closed, I think removing or redefining the "Network Issues" and "Installation" section is necessary. What you think?<br />
<br />
:What about moving the current state into an article "OMP 0.2" for acheiving it, for the case you go back to development? Also as it will be very hard to make people delete OMP from their HDs, the installation guide could be kept that way. I could make a big red "Obsolete addon" warning on top of it, so it should be clear, that they cannot expect you to do support for this version. --[[User:Urwumpe|Urwumpe]] 11:49, 6 September 2006 (MSD)<br />
<br />
::I think changing the "Network issues" into something like "Current development issues" and replacing "Installation" with a decent history entry might be even better. If nobody has problems with it, I'd like to make something up in the article for the start, so we can discuss about it a bit clearer.--[[User:Face|Face]] 22:38, 7 September 2006 (MSD)</div>Facehttps://www.orbiterwiki.org/index.php?title=Talk:OMP&diff=5804Talk:OMP2006-09-05T18:05:16Z<p>Face: </p>
<hr />
<div>Because public development has been closed, I think removing or redefining the "Network Issues" and "Installation" section is necessary. What you think?</div>Facehttps://www.orbiterwiki.org/index.php?title=OMP&diff=5803OMP2006-09-05T18:01:51Z<p>Face: /* Status */</p>
<hr />
<div>{{Addon|<br />
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|<br />
2=Friedrich 'Face' Kastner-Masilko<br />
}}<br />
<br />
==History==<br />
OMP was announced on [[IRC]] as project to 'properly' execute a [[Multiplayer|multiplayer]] environment in Orbiter. Presumably this meant it would take care of more of the conventional space-simulator multiple player caveats and be more of an end-user oriented product than the previous, mostly experimental multiplayer projects [[IRCMFD]] and [[Multiorb]].<br />
<br />
Using low-level TCP and UDP connections between machines, OMP may be considered a third-generation Orbiter multiplayer system, although it's understood that each machine is still responsible for its own physics.<br />
<br />
==Status==<br />
As of September 2006, Development is ongoing, but closed to the public. Although, at this time no public servers are known, users volunteer to host quite frequently. Some [[Virtual space agency|Virtual space agencies]], now use OMP for their missions.<br />
<br />
==Networking issues==<br />
<br />
From the 0.3 patch most NAT problems are worked around and OMP now sends 8 kb packets, so, virtually any type of internet connection can use, as well as host OMP.<br />
<br />
==Installation tutorial==<br />
<br />
# Download the OMP 0.2 pack from [http://www.snoopie.at/face/omp/?Releases here]<br />
# Extract the zip archive in the orbiter directory. <br />
# Download the following files from [http://www.snoopie.at/face/omp/?Development here]<br />
#* Orbiter plugin<br />
#* Default configuration for the Orbiter plugin<br />
#* Dummy scenario file for the automatic startup feature<br />
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!<br />
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!<br />
# Disable any firewalls.<br />
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module. <br />
# When you activate that module, a dialog will pop up. That's the OMP client. <br />
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.<br />
# Click on standard. <br />
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)<br />
<br />
This should get most of the users connected, if they follow the procedures correctly. If you are still having problems connecting, try this alternative method:<br />
<br />
# In the OMP client, click on Custom. The custom field should become active. Type your IP address in the custom field. If you don't know your IP address, get it [http://whatismyipaddress.com/ here].<br />
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP <br />
# Try reconnecting.<br />
<br />
==Features==<br />
<br />
* See other people online<br />
* "Jump" feature, so the users can jump to each other when ever they want<br />
* Dock with other users<br />
* Users can chat with each other<br />
* Orbiter Playback funtion works with OMP<br />
* Everything is in realtime<br />
* Support for different planetary systems<br />
<br />
==See also==<br />
[[Multiplayer]] -- an overview of multiplayer addons for Orbiter<br />
<br />
[[IRCMFD]]<br />
<br />
[[Multiorb]]<br />
<br />
[[Project Hamac]]<br />
<br />
[[Category:Addons]]<br />
[[Category:Multiplayer addons]]</div>Face