OMP Discussion

[SolarLiner]

Remenbering my OMP problem, I have tested a solution.
I have two Orbiter installations. When I keep only one Orbiter Installation, OMP works.
So I deduce OMP is not multi-Orbiter installation compatible.

 

[Face]

Remenbering my OMP problem, I have tested a solution.
I have two Orbiter installations. When I keep only one Orbiter Installation, OMP works.
So I deduce OMP is not multi-Orbiter installation compatible.

This deduction is a bit premature. I have around 20 Orbiter installations here, with around 3 OMP setups, and all work.

Besides port clashes, I don't see why it shouldn't work even with multiple concurrently running instances of the server. In fact I've tried that myself - alas with an older version - without problems. Of course you have to specify different ports for the second instance...

regards,
Face

 

[RacerX]

This deduction is a bit premature. I have around 20 Orbiter installations here, with around 3 OMP setups, and all work.

Besides port clashes, I don't see why it shouldn't work even with multiple concurrently running instances of the server. In fact I've tried that myself - alas with an older version - without problems. Of course you have to specify different ports for the second instance...

regards,
Face

I to have used more then one instance at a time on single machine with multiple clients in omp. No issues. Multiple servers on single machine is also possible at least 2 updates back that I tested ie. star trek server and one realistic server. I shall test the newer served version when I get home just for my own curiosity

 

[Axertan]

Remenbering my OMP problem, I have tested a solution.
I have two Orbiter installations. When I keep only one Orbiter Installation, OMP works.
So I deduce OMP is not multi-Orbiter installation compatible.

I have multiple Orbiter and Orbiter+OMP installations on my system, and so far all of them work within my hardware limitations. (Read: They work.)
I have all of them extracted using the .zip method. But to my knowledge the installator does not write anything in registry, so it shouldn't be the problem.

---------- Post added at 21:09 ---------- Previous post was at 20:00 ----------

I tried OMP 0.7.1 download from bitbucket today with RacerX. He was launching a shuttle stack, while I was watching from the runway. Shuttle stack only appears as the orbiter, until the SRB's are jettisoned. After the SRB's were automatically added into the scenario, they appeared on my screen like a charm. Same with the ET.
Magnificent job Face, hats off! :tiphat:

 

[Face]

Hy there,

I'm currently implementing a replacement for the NTP mechanism on the client side. Basically it will use something like IEEE1588 PTP to gather time-stamps directly from the OMP server over the already hole-punshed UDP channel. This will eliminate the need for an NTP server on LAN setups, and additionally boost the accuracy between 10 and 100 times (i.e. instead of being synced up to 8ms, it will be more like between 1ms and 100µs, hopefully resulting in less jitter.

I'll test it as good as I can, but naturally I will need some peers on the net to make representative measurements. Anybody willing to do this?

 

[SolarLiner]

Depending on the time, I may be here to test.

 

[Face]

For those interested, there are the exchange files you need to patch a 0.7.4 version: https://bitbucket.org/face/orl-online/downloads . The code is - as always - here: http://omp.ddns.net/hg/omp

* Orbiter.Multiplayer.dll needs to go into /Modules/Plugin/DotNET AND your server folder
* Orbiter.Multiplayer.Client.dll goes into /Modules/Plugin/DotNET
* OMPClient.dll goes into /Modules/Plugin
* Orbiter.Multiplayer.Server.dll goes into your server folder
* ServerConsole.exe also needs to go into your server folder

With this present, you can create a complete LAN setup without the need for an external NTP server. Simply remove all NTP server definitions in the client/server XML configurations. This will deactivate the NTP pinging, and instead activate the direct PTP exchange in the client. Whatever the server clock is doing will then be propagated to every client.

For servers needing backwards-compatibility (i.e. older client versions should be able to synchronize), just keep the NTP configurations. They will slave your server clock to UTC, but still serve PTP to the clients.

For clients needing backwards-compatibility (i.e. newer client wants to connect to old server), defining at least one NTP server in the configuration will deactivate the PTP mechanism and keep your client synchronized to UTC again.

Finally, I think it would be cool if we can do a little test session at the coming weekend to collect some data about the performance of this new clock synchronization mechanism, especially for on-orbit operations.

regards,
Face

 

[Jarod]

I am available this weekend, but can only be a client, I'll need a clean install of Orbiter too, what version will be used ?

edit: nevermind, it's been a while, found how to reinstall all that is needed.

edit: everything is working and I can connect to a local server without problems, will wait for further instructions.

 

[Ren Dhark]

Finally, I think it would be cool if we can do a little test session at the coming weekend to collect some data about the performance of this new clock synchronization mechanism, especially for on-orbit operations.

Updated the server quick with new patch, did not really test it yet. I can help testing on Sunday.

 

[AssemblyLanguage]

I patched my local server and clients but both crashed without info. I rebuilt my server but it crashed until I added back:

<NTP Offset="-30.692192928436572" Skew="-17">
</NTP>

to both the server and the client XMLs.

 

[Face]

I was not clear about the configuration settings, sorry for that. Here is an example configuration for the client:

<?xml version="1.0"?>
<OMPClientConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Name="Nobody" xmlns="http://Orbiter.Multiplayer.Server">
  <Network IP="omp.ddns.net" TCP="1515" UDP="2500" Configuration="Standard" />
  <NTP Samples="10" />
  <Password>drewsfaster</Password>
  <Timing Transmitter="200" />
</OMPClientConfiguration>

As you can see, the NTP line is still there (it is as of now still needed to store the previous offset and skew), holding the samples value. I'd suggest to keep it at 10 for the tests.

For the server, the same is true: you need that single NTP line, even if you don't have NTP synchronization without NTP server lines. The XSD scheme currently requires the setting to be there, I'll fix that later.

---------- Post added at 13:39 ---------- Previous post was at 12:19 ----------

Thanks to Ren, RacerX and Jarod, I already found and fixed a small bug in the PTP protocol causing unnecessary collisions. This is just a fix to the OMPClient.dll, get the new one here: https://bitbucket.org/face/orl-online/downloads/OMPClient.dll

 

[Delta glider]

If you have OMP can you say that you are about to go on the server and say what time and what you want to do so people can meet up on the server.

I will be on the server at 16:00 GMT for racing and everything (my username is Delta_glider).

 

[Ren Dhark]

Maybe we can do a Meet and fly on OMP on a coming up weekend. Feel free to gather some pilots and I will update the OMP Mission Command with date & time.

Lately I have seen a small increase of new pilots using OMP, uncoordinated and at slightly different times, so your at the right place - just at the wrong time :lol:

 

[Delta glider]

As of yet only once when I was on, another person was on.

 

[Antoo]

Hi everyone, we flew with Ren last night, and I made a little video :

Video here :

Dansteph's forum thread about OMP Missions : http://orbiter.dansteph.com/forum/index.php?topic=13057

:tiphat: