# OMP Discussion

Status
Not open for further replies.

#### jangofett287

##### Heat shield 'tester'
The DGIV auto-pauses the simulation when spawned. this is ok for the person controlling it as they're starting from a scenario, but for everyone else when the DGIV spawns their sync goes to hell.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Well, Dan's DGs always caused (and still cause) troubles in OMP. They are the sole reason for the class mapping system.

You can configure the server in such a way, that despite a user running DGIV, all other users see them as normal Deltagliders. It is just so that Ren did not set this in his hosting yet.

#### RacerX

##### Donator
Donator
Face can you post an example of how to configure the server in that way? That may be the answer I need to test the shuttles. Can you please post an example line of how to configure server.xml . I am assuming it has something to do with a redirect but I am unsure how to make it work

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Yes.

Locate the example server.xml from the package in /Server/Windows/ . Edit it with a text-editor and search for <Class Name="OMPDefault" Redirect="#" /> . This line and the previous 4 are examples for a class redirection definition.

Just add another directly behind the given one, and replace "OMPDefault" with the DGIV's class name (I guess it is "DeltaGliderIV" or somesuch), and replace "#" with "Deltaglider" (this is the stock DG's class name).

Whenever a client gets a new global vessel to be displayed, it first shows the OMPDefault vessel (the blue/green/yellow coordinated cross). It asks the server via TCP for the vessel's name and class. In this process, the redirection is in effect: the server returns the redirected class name, not the "real" one. So while a client may create or even start with a DGIV, other clients will only see it as a stock DG with the appropriate setting on the server.

The meaning of several wildcards in these definitions is documented in Appendix A of the PDF, near the bottom of the page. Also note that the "Generic" attribute there is for future use and not implemented ATM.

regards,
Face

#### RacerX

##### Donator
Donator
excellent I will test this also along with %state when I get home. thanks face

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
No JSMGE, so I guess not, but if you have some ideas of programs may can that, I can check if I have it or not.

I've thought a bit about your problem there and there is one thing more I can imagine: do you have any kind of fancy Windows theme or style activated by any chance? Or maybe a "chrome" enhancement (additional buttons in the window frame and somesuch)?

It could be that your system kind of wraps the Orbiter window and the handle returned is not the real Orbiter window, but its wrapper. In this case the program will fail to detect the button in the window, because obviously the wrapper wouldn't have a start button.

If so, could you try to deactivate the modifications to your windows and see if it works?

regards,
Face

#### RacerX

##### Donator
Donator
The redirect worked
<Class Name="DeltagliderIV" Redirect="Deltaglider" />
DGIV can be played in OMP . In this case You can't use the stock DG as a starting area though . I am on a cell phone will post more later
I did test the %state but was unsucessful. Buy the time I used it orbiter is already locked up

Last edited:

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
The redirect worked
<Class Name="DeltagliderIV" Redirect="Deltaglider" />
DGIV can be played in OMP . In this case You can't use the stock DG as a starting area though .

Why not? I know that the DGIV will be the only entry in the normally empty vessel class selection list, but this should have no influence on the location scenario generation, as long as you don't have a "\${CLASS}" clause in it.

I did test the %state but was unsucessful. Buy the time I used it orbiter is already locked up

I've mentioned the %state as a way to check if the event system is activated. You should be able to use it before you do the actions that lead to lock-up.

regards,
Face

#### SolarLiner

##### It's necessary, TARS.
I have tried the OMP Client with an another computer (because OMP can't locate Orbiter Start Button), and it fully works ! So my computer has a problem ...

#### RacerX

##### Donator
Donator
Ok I can now confirm using DGIV redirect from earlier post will cause a 2nd viewing client crash at sync if the second viewing client "Spawn" with a stock deltaglider. With that said if I use the DeltagliderXR1 as a redirect such as:
<Class Name="DeltaGliderIV" Redirect="DeltaGliderXR1" />
The second viewing client still can not spawn with a stock deltaglider.
Here is my server.xml I am testing as of now. http://pastebin.com/raw.php?i=2X9Lps3s I left the stock deltaglider starting area in there for testing purposes
And a Screenshot of starting areas and ships.

Only conclusion I can come up with is DGIV and Stock deltaglider are not compatable somehow. IMO I don't think this is a big issue as most people will opt for the DGIV anyways. I am only posting this in case there is a hidden bug somewhere.

Last edited:

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Ok I can now confirm using DGIV redirect from earlier post will cause a 2nd viewing client crash at sync if the second viewing client "Spawn" with a stock deltaglider. With that said if I use the DeltagliderXR1 as a redirect such as:
<Class Name="DeltaGliderIV" Redirect="DeltaGliderXR1" />
The second viewing client still can not spawn with a stock deltaglider.
Here is my server.xml I am testing as of now. http://pastebin.com/raw.php?i=2X9Lps3s I left the stock deltaglider starting area in there for testing purposes

I can't reproduce this here. With a mapping in place, everything work fine. Which location of the many you used up there did the crash trick on the second client?

Only conclusion I can come up with is DGIV and Stock deltaglider are not compatable somehow. IMO I don't think this is a big issue as most people will opt for the DGIV anyways. I am only posting this in case there is a hidden bug somewhere.

Well, the problem you are reporting is not really supporting this hypothesis. The whole purpose of the remapping is to NOT spawn a DGIV on the second client, but a stock Deltaglider. So there is no DGIV to be incompatible with the stock Deltaglider on the second client. Something else is hidding in there indeed...

regards,
Face

#### RacerX

##### Donator
Donator
I can't reproduce this here. With a mapping in place, everything work fine. Which location of the many you used up there did the crash trick on the second client?
[email protected] using this redirect
<Class Name="DeltaGliderIV" Redirect="DeltaGliderXR1" />

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
[email protected] using this redirect
<Class Name="DeltaGliderIV" Redirect="DeltaGliderXR1" />

I don't see a location "[email protected]", so I guess you mean "DG at Wideawake". Tried that, can't reproduce it.

But I'm worried that this might be just an event system bug. We didn't yet work out why an event seems to be transmitted in your setup.

Can you please reproduce it with the second client's log checkboxes all activated (do it before entering the simulation, also delete the OMPClient.log in the /modules/plugin/ folder)? Then please post the OMPClient.log, but be aware that the password you use for your client there will be visible in plain text, so choose a disposable one. Also post the Events.log in the same folder.

Maybe we can work it out this way.

#### RacerX

##### Donator
Donator
I will. problem is bad storms and my internet are offline right now. I am using cell phone. I have a video ready for upload. Also I need to clairify it crashes the 1st viewing client. the video will clairify what I mean

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
I will. problem is bad storms and my internet are offline right now. I am using cell phone. I have a video ready for upload. Also I need to clairify it crashes the 1st viewing client. the video will clairify what I mean

Ok, now I'm confused. So if I understand that right, your situation is as follows:

1. Redirect of DGIV to Deltaglider is set in server.xml, server is started.
2. Client 1 starts with location with DGIV
3. Client 1 syncs and sits there
4. Client 2 starts with location with Deltaglider
5. Client 2 syncs
6. Client 1 freezes? Client 2 freezes?
Maybe it is best to wait for your video...

#### RacerX

##### Donator
Donator
Ok, now I'm confused. So if I understand that right, your situation is as follows:

1. Redirect of DGIV to Deltaglider is set in server.xml, server is started.
2. Client 1 starts with location with DGIV
3. Client 1 syncs and sits there
4. Client 2 starts with location with Deltaglider
5. Client 2 syncs
6. Client 1 freezes? Client 2 freezes?
Maybe it is best to wait for your video...
Here is the video and the logs

Crashed client log here
http://pastebin.com/0esdistS

Other client here
http://pastebin.com/fJk1Fq8G

Redirect of DGIV to DeltagliderXR-1 is set in server.xml, server is started.
Client 1 starts with location with DGIV
Client 1 syncs and sits there
Client 2 starts with location with Stock Deltaglider at Wideawake (DG-S)
Client 2 counting down to sync
Client 1 freezes

Last edited:

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
I see, thanks for the detailed info. It looks like DGIV is not happy if a Deltaglider is spawn during simulation, at least the video and the logs suggest this. Did you try to use the ScnEditor to spawn a Deltaglider with a DGIV scenario without OMP? Maybe it isn't even related to the later at all...

That said, I've found a small inconvenience with the mapping system: it is case-sensitive, while Orbiter's class loading mechanism is case-folding (due to NTFS, I guess). I.e.: if you do not match the casing in the location definition with the class naming in the redirect mapping, it will not work, because VESSEL::GetClassName() always returns the string it found in the scenario file, not the casing of the file it loaded (or the actual class name in the config file, for that matter!).

I've changed this for the next server and client version now, so it will always case-fold class names before matching them.

regards,
Face

#### Ren Dhark

##### Member
NTP blocked

As i was checking my OMPClient.log i found a lot errors like that:
Code:
SNTP: Server pool.ntp.org was hit, but blocked... 0 hits left.
SNTP: Searching downwards.
SNTP: No more unblocked server available!
When this happens I get lag. Now i'm testing a changed OMPClient.xml with <NTP> section like a server.xml and also local NTP-Server, e.g. ch.pool.ntp.org. I did read somewhere that direct hit on pool.ntp.org can be blocked.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
As i was checking my OMPClient.log i found a lot errors like that:
Code:
SNTP: Server pool.ntp.org was hit, but blocked... 0 hits left.
SNTP: Searching downwards.
SNTP: No more unblocked server available!
When this happens I get lag. Now i'm testing a changed OMPClient.xml with <NTP> section like a server.xml and also local NTP-Server, e.g. ch.pool.ntp.org. I did read somewhere that direct hit on pool.ntp.org can be blocked.

Yes, this can happen if you set too fast timings. E.g. 1 seconds sample time, 10 samples, 5 seconds resync interval. The server will then block you according to its DDOS rules. That's why the system evenly distributes server access over all defined servers, and also skips missed servers for a given amount of "hits", thus lowering the load on one single server.

You can also use a distributed approach to NTP synchronization in OMP. Just configure your server as NTP server, and point both server and clients to that machine with a single configuration line. Of course all clients need to set this single NTP server then, otherwise the timestamps could drift away seriously, resulting in bad jitter artifacts.

That is why I've chosen to default to UTC time servers: it is the one "global" clock that we all can agree to.

regards,
Face

#### RacerX

##### Donator
Donator
I see, thanks for the detailed info. It looks like DGIV is not happy if a Deltaglider is spawn during simulation, at least the video and the logs suggest this. Did you try to use the ScnEditor to spawn a Deltaglider with a DGIV scenario without OMP? Maybe it isn't even related to the later at all...

That said, I've found a small inconvenience with the mapping system: it is case-sensitive, while Orbiter's class loading mechanism is case-folding (due to NTFS, I guess). I.e.: if you do not match the casing in the location definition with the class naming in the redirect mapping, it will not work, because VESSEL::GetClassName() always returns the string it found in the scenario file, not the casing of the file it loaded (or the actual class name in the config file, for that matter!).

I've changed this for the next server and client version now, so it will always case-fold class names before matching them.

regards,
Face
I tested it without omp. And you were right DGIV and DG-S in the same scenario do not like each other. What is even worse is there is nothing in the orbiter log file either to try to determine a cause. I did post the finding at Dan's addons page.

Status
Not open for further replies.

Replies
0
Views
61
General Question Cooperative flight
Replies
7
Views
634
Replies
27
Views
2K
Replies
18
Views
2K
Replies
0
Views
698