Difference between revisions of "OMP"

From OrbiterWiki
Jump to navigation Jump to search
(formatting, sp, categories)
(Added category.)
 
(42 intermediate revisions by 15 users not shown)
Line 1: Line 1:
 +
[[Image:ompgui.png|thumb|right|OMP client's user interface .]]
 +
 
{{Addon|
 
{{Addon|
1=[http://www.snoopie.at/face/omp/?Home OMP homepage]|
+
1=[http://omp.ddns.net http://omp.ddns.net]|
 
2=Friedrich 'Face' Kastner-Masilko
 
2=Friedrich 'Face' Kastner-Masilko
 
}}
 
}}
  
==History==
+
This add-on is also available at [https://www.orbiter-forum.com/resources/omp-2016.3459/ OMP 2016 2017-05-14] at Orbiter-forum/resources.
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]].
 
 
 
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.
 
  
==Current status==
+
'''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]].
Development is still going, and the 0.3 pack is about to be released. Although no public servers are currently known, users volunteer to host quite a bit. "Virtual space agencies", such as SimNasa, and Virtual Nasa, now use OMP for their missions.
 
  
==Installation==
+
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.
  
OMP, in my opinion, is the easiest Orbiter Multiplayer project to configure, to this date. The 0.3 patch, which is still under development, but fully downloadable, gets rid of most of the NAT problems.
+
==Version history==
Most of the PCs are able to run it, and OMP sends 8 kb packets, so, virtually any type of internet connection can use OMP, as well as host OMP servers. Heres a "short" checklist to setting up an OMP client. Please follow the procedures in order, and you will be flying with your buddies in no time:
+
* '''V0.1''' - 2005-09-06 Alpha release
 +
* '''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.
 +
* '''V0.1''' - 2005-09-10 Patch 2: Added jump feature - see documentation.
 +
* '''V0.1''' - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations
 +
* '''V0.1''' - 2005-09-17 Patch 4: Fixed default server config file
 +
* '''V0.1''' - 2005-09-20 Patch 5: Server and Client log to file, too
 +
--------
 +
* '''V0.2''' - 2006-04-23 Second alpha release
 +
* '''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
 +
* '''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
 +
--------
 +
* '''V0.2.9.6''' - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team
 +
--------
 +
* '''V0.6.1''' - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods
 +
--------
 +
* '''V0.7''' - 2012-05-05
 +
* '''V0.7.1''' - 2012-05-18
 +
* '''V0.7.2''' - 2013-07-21
 +
* '''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.
 +
* '''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.
 +
* '''V0.8''' - 2014-10-09 Compatibility break - PTP protocol and jitter-avoidance updates
 +
* '''V0.8.1''' - 2015-07-08 Introduction of hand-over features (persistence)
 +
* '''V0.8.2''' - 2017-05-23 Switch to Orbiter 2016, added animation support via save state transmission
  
# Download the OMP 0.2 pack from here: http://www.snoopie.at/face/omp/?Releases
+
==Status==
# Extract the zip archive in the orbiter directory.
+
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.
# Download the following files from http://www.snoopie.at/face/omp/?Development
 
#* Orbiter plugin
 
#* Default configuration for the Orbiter plugin
 
#* Dummy scenario file for the automatic startup feature
 
# Put the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!
 
# Put the Default configuration for the orbiter plugin in Orbiter\modules\plugin directory. OVERWRITE THE PREVIOUS FILE!
 
# Put the Dummy scenario file for the automatic startup feature in orbiter\scenarios OVERWRITE THE PREVIOUS FILE!
 
# Disable any firewalls.
 
# Open the orbiter launchpad, and under the modules tab, activate the OMPClient module.
 
# When you activate that module, a dialog will pop up. That's the OMP client.
 
# Click in the server text field. Delete the IP inside it, and put the server IP you are trying to connect.
 
# Click on standard.
 
# Under name, put the username you want. Put a password you can remember, and hit connect Orbiter.(Launch Orbiter changes to connect orbiter)
 
  
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:
+
==Networking issues==
  
# 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 here: http://whatismyipaddress.com/
+
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.
# Make sure ports 1500 and 2500 are forwarded, for both UDP and TCP 
 
# Try reconnecting.
 
  
 
==Features==
 
==Features==
  
* See other people online
+
* Remote vessel replication - see vessels of other clients inside your Orbiter session
* "Jump" feature, so the users can jump to each other when ever they want
+
* Dock support
* Dock with other users
+
* On-orbit and ground operations
* Extremly easy set up
+
* Integrated text-based chat
* Any user can "jump" into another user's cockpit
+
* "Jump" feature - jump to other vessels immediately to save time
* Users can chat with each other
+
* Orbiter Playback function works with OMP
* Orbiter Playback funtion works with OMP
 
* Everything is in realtime
 
 
* Support for different planetary systems
 
* Support for different planetary systems
 +
* [http://www.brynosaurus.com/pub/net/p2pnat/ Hole-punching] and [[w:STUN|STUN]] analysis for easy connection setup
 +
* Missile toy - demonstrates advanced interactions in the distributed simulation
 +
* Transmission of vessel save states, so animations and various settings are reflected on remote machines
 +
 +
[[Image:ompschematic.png|thumb|right|OMP technology schematic.]]
 +
[[Image:ompserverhelp.png|thumb|right|TCP session on OMP server.]]
 +
 +
==Technology==
 +
 +
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.
 +
 +
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.
 +
 +
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.
 +
 +
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.
 +
 +
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.
 +
 +
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.
 +
 +
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.
 +
There are 5 reasons to send an absolute SI instead of a relative one:
 +
* 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.
 +
* 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.
 +
* 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.
 +
* A jump command is running.
 +
* 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:
 +
** the current simulation’s viewport high ℎ in pixels,
 +
** the current field of view 𝑓𝑜𝑣 in degree,
 +
** the maximum size of both vessels 𝑠 in meter and
 +
** the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.
 +
 +
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:
 +
* the reference object is available,
 +
* it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and
 +
* the vessel to be updated is no superstructure slave.
 +
 +
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.
  
Basically anything that's possible in Orbiter. With these features, you can do a lot. All you need is imagination.
+
==Online Servers==
 +
[http://omp.ddns.net http://omp.ddns.net]
  
* Live tutorials. Docking with ISS, landing. All can be done in realtime.
+
==See also==
* Have competitions. Aerobatics air shows. Races.
+
* [[Multi-player]] -- an overview of multi-player add-ons for Orbiter
* Do historical flights with your buddies. Launch the Mercury Atlas with your buddies. Have someone chase that Atlas in a DG. Be a chase plane for the shuttle landing.
+
* [[Orbiter.World]]
* Use OMP for home cockpits.
+
* [[IRCMFD]]
* Teachers can use OMP for their classes, so the teacher would be with their students at all times. Even in simulation.
+
* [[Multiorb]]
* Explore different planetary systems with your friends.
+
* [[Orbiter MMORPG]]
 +
* [[Project Hamac]]
  
OMP is extremly easy to set up. With the current technology, almost everybody can use OMP. There are still limitations, such as no animation support, or MFD synchronization. But it's an amazing feeling when you hear that "Docking confirmed", and you know that you are not just docking to a computer, but a real person.
+
[[Category: Articles]]
[[Category:Addons]][[Category:Multiplayer addons]]
+
[[Category:Add-ons]]
 +
[[Category:Multi-player add-ons]]

Latest revision as of 03:52, 15 October 2022

OMP client's user interface .

Project home: http://omp.ddns.net
Author: Friedrich 'Face' Kastner-Masilko
Current version: Unknown
Compatibility: Unknown


This add-on is also available at OMP 2016 2017-05-14 at Orbiter-forum/resources.

Orbiter Multiplayer Project (OMP) was announced on IRC as project to 'properly' execute a 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.

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.

Version history[edit]

  • V0.1 - 2005-09-06 Alpha release
  • 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.
  • V0.1 - 2005-09-10 Patch 2: Added jump feature - see documentation.
  • V0.1 - 2005-09-11 Patch 3: (Hopefully) fixed the CTD bugs for various situations
  • V0.1 - 2005-09-17 Patch 4: Fixed default server config file
  • V0.1 - 2005-09-20 Patch 5: Server and Client log to file, too

  • V0.2 - 2006-04-23 Second alpha release
  • 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
  • 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

  • V0.2.9.6 - 2006-09-21 Public development closed, start of closed beta-testing. First release to beta-team

  • V0.6.1 - 2012-03-03 Start of public beta-testing with release on Orbiter Hangar Mods

  • V0.7 - 2012-05-05
  • V0.7.1 - 2012-05-18
  • V0.7.2 - 2013-07-21
  • 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.
  • 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.
  • V0.8 - 2014-10-09 Compatibility break - PTP protocol and jitter-avoidance updates
  • V0.8.1 - 2015-07-08 Introduction of hand-over features (persistence)
  • V0.8.2 - 2017-05-23 Switch to Orbiter 2016, added animation support via save state transmission

Status[edit]

Around August 2016, development moved from a scattered O-F-subforum/Bitbucket existence to a concentrated offering at 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.

Networking issues[edit]

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.

Features[edit]

  • Remote vessel replication - see vessels of other clients inside your Orbiter session
  • Dock support
  • On-orbit and ground operations
  • Integrated text-based chat
  • "Jump" feature - jump to other vessels immediately to save time
  • Orbiter Playback function works with OMP
  • Support for different planetary systems
  • Hole-punching and STUN analysis for easy connection setup
  • Missile toy - demonstrates advanced interactions in the distributed simulation
  • Transmission of vessel save states, so animations and various settings are reflected on remote machines
OMP technology schematic.
TCP session on OMP server.

Technology[edit]

The concept of OMP is a client/server-based architecture with timestamped stream communication. The system uses SNTP timeservers to synchronize both clients and server to 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 PTP mechanism can be used to synchronize clients to the server clock, eliminating the need for contacting external timeservers.

Not shown in this sketch is the communication between clients. This communication is similar to the UDP transmissions between client and server and resembles peer-to-peer networks in order to downsize streaming latency.

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.

Clients start a 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 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.

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.

As soon as a client joins the multi-player session, it tries to synchronize the simulation’s 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.

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. There are 5 reasons to send an absolute SI instead of a relative one:

  • 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.
  • 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.
  • 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.
  • A jump command is running.
  • 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:
    • the current simulation’s viewport high ℎ in pixels,
    • the current field of view 𝑓𝑜𝑣 in degree,
    • the maximum size of both vessels 𝑠 in meter and
    • the formular 𝑑 < 0,5 ∙ 𝑠∙ℎ / tan(𝜋∙𝑓𝑜𝑣/360). This estimates the user’s eye-monitor distance with half a meter.

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:

  • the reference object is available,
  • it is either relative to another vessel or absolute and the client is within the space-time bubble – regarding time – of the server and
  • the vessel to be updated is no superstructure slave.

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.

Online Servers[edit]

http://omp.ddns.net

See also[edit]