OMP Discussion

[Face]

2 major improvements:
* most clients won't need port-forwarding anymore and
* sync is much faster and more stable

Some minor things:
* STUN analysis of your connection,
* reworked documentation,
* superstructure detection for better docking experience,
* faster join procedure,
* support for vessel remove patterns (aka XR2_bay problem),
* more precision with NTP algorithm,
* reloadable configuration on server
* many, many bugfixes

To see what changed, use this revset: http://omp.ddns.net/hg/omp/changelo...3.5.0 alpha / OMPServer V0.5.5.0 beta"::0.6.1
It will show you a list of all commits between the 0.3.5.0 client release and the current one.

regards,
Face

 

[Scruce]

Installed OMP,
Installed XR2 Ravenstar,
Installed ORL,
Ran 'Orbiter_ng'
Activated 'OMPClient' in 'Modules' tab,
Clicked 'Connect Orbiter' in the primary tab.

First try killed the whole process slowly.

Second try made clicking 'Connect Orbiter' futile, after a few seconds, I was back at square one and had to click 'Connect Orbiter' again, only for the step to repeat itself.

Orbiter.log:

**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 7.00201e-008 sec
Found 0 joystick(s)
Devices enumerated: 6
Devices accepted: 5
==> RGB Emulation
==> Direct3D HAL
==> Direct3D T&L HAL
==> Direct3D HAL (ATI Radeon HD 4300/4500 Series       )
==> Direct3D T&L HAL (ATI Radeon HD 4300/4500 Series       )
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfigurator.dll .... [Build 100830, API 100830]
Module ExtMFD.dll ............ [Build 100830, API 100830]
Module Framerate.dll ......... [Build 100830, API 100830]
Module FlightData.dll ........ [Build 100830, API 100830]
Module ScnEditor.dll ......... [Build 100830, API 100830]
Module Rcontrol.dll .......... [Build 100830, API 100830]
Module ScriptMFD.dll ......... [Build 100830, API 100830]
Module LuaConsole.dll ........ [Build 100830, API 100830]
Module transx.dll ............ [Build 100824, API 100823]
Module LuaMFD.dll ............ [Build 100830, API 100830]
Module CustomMFD.dll ......... [Build 100830, API 100830]
Module Meshdebug.dll ......... [Build 100830, API 100830]
Module RaceCheckpointMFD.dll . [Build ******, API 060425]

 

[Face]

Installed OMP,
Installed XR2 Ravenstar,
Installed ORL,
Ran 'Orbiter_ng'
Activated 'OMPClient' in 'Modules' tab,
Clicked 'Connect Orbiter' in the primary tab.

ORL online is a superset of ORL and OMP, you don't need to install them separately. OMP is neither tested nor expected to run on any OVP client at all.

 

[Scruce]

ORL online is a superset of ORL and OMP, you don't need to install them separately. OMP is neither tested nor expected to run on any OVP client at all.

So, what do I do?

 

[orb]

So, what do I do?

Run orbiter.exe, and not orbiter_ng.exe.

 

[Scruce]

Run orbiter.exe, and not orbiter_ng.exe.

Running 'orbiter.exe' yielded the same results as 'orbiter_ng.exe', the Launchpad freezes and becomes unresponsive. The only way to start up again is to use Windows Task Manager to kill the program.

 

[Pipcard]

With the recently released ORL,
Orbiter is at x2.0 speed before crashing at 7-10 seconds in the simulation.

---------- Post added at 04:10 PM ---------- Previous post was at 03:51 PM ----------

So looking at the Windows Event Viewer (thanks orb for letting me know about its existence), these are the errors associated with the Orbiter crashes:

 

[Face]

Running 'orbiter.exe' yielded the same results as 'orbiter_ng.exe', the Launchpad freezes and becomes unresponsive. The only way to start up again is to use Windows Task Manager to kill the program.

3 more things I can think of:
* do you have .NET runtime 2.0 installed?
* did you also try on a vanilla Orbiter install?
* do you have a "OMPClient.crash" file in your Orbiter's root? If so, open it with a text editor and check the reason for the early crash.

---------- Post added at 10:07 ---------- Previous post was at 09:55 ----------

With the recently released ORL,
Orbiter is at x2.0 speed before crashing at 7-10 seconds in the simulation.

It could well be that this is a symptom of the animation support that slipped in accidentally. Try to connect to the server when there is not much activity, so chances are low to catch unsolicited recording events. If nobody else is there, opening/closing doors/hatches/gears, it should keep you connected.

Besides this, you can check the log for information. As noted in the documentation, the configuration for the log is at Modules/Plugin/OMPClient.log4net and defaults to log all information to Modules/Plugin/OMPClient.log . The later file might contain some hints in the end section. In order to have all the loggers active BEFORE you try your connect, go to the log tab in the client window and check all boxes.

 

[Pipcard]

It could well be that this is a symptom of the animation support that slipped in accidentally. Try to connect to the server when there is not much activity, so chances are low to catch unsolicited recording events. If nobody else is there, opening/closing doors/hatches/gears, it should keep you connected.

So disabling animations (how do you do that) will stop the crashes?

 

[Face]

So disabling animations (how do you do that) will stop the crashes?

No. Disabling animation support will stop it, and you can't do it without recompiling the sources on your own. That said, I'm working on a temporary solution that just replaces Ren's server with a version that doesn't broadcast recording events. Should work, too.

 

[Pipcard]

So when's that temporary solution going to come?

If OMP ever works for me, can it have missiles so that we can have actual dogfights?

 

[Face]

So when's that temporary solution going to come?

If OMP ever works for me, can it have missiles so that we can have actual dogfights?

It is ready when it's ready.

If it isn't working for you now, I guess missiles are so far in the future for OMP that you should just stop trying it out. Instead, please go for another project for dogfights, I'm sure they need beta-testers as soon as their first release is done.

regards,
Face

 

[RacerX]

Face will disabling animation support allow the space shuttle to work? I have done some testing with it and the crash is always the same. When another client in visual range at the very moment of syncing is completed that client crashes.

${IF 1}${DESC}Atlantis at Wideawake
${NAME}:Shuttle
STATUS Landed Earth
POS -14.4433220 -7.9687560
HEADING 270.00
AFCMODE 7
PRPLEVEL 0:1.000000 1:0.996000 2:1.000000
NAVFREQ 0 0
CONFIGURATION 0
GEAR 0 0.0000
END

If I change ${NAME}:Shuttle to ${NAME}:Atlantis
In this case I will actually see the shuttle but not the whole stack in the viewing client. Everything is fine even during sync. At the moment The Throttle is applied the viewing client crashes. It doesnt matter what ship I use in the viewing client it always crashes. What is the common denominator in these 2 scenerios that is causing the crash?

 

[Face]

Face will disabling animation support allow the space shuttle to work? I have done some testing with it and the crash is always the same. When another client in visual range at the very moment of syncing is completed that client crashes.

The animation support bug is not connected with a specific vessel. It is simply a problem with calling VESSEL2 callback for event playback. However, this could be a reason for some freak situations to play out. Please check with a PuTTYtel session to the server while reproducing the crash. Do you see some GINFO lines with text like "GEAR UP", "ROLL" or somesuch?

If so, it might be an event that is recorded and transferred that causes the remote Shuttle to crash.

In this case I will actually see the shuttle but not the whole stack in the viewing client. Everything is fine even during sync.

The "not the whole stack" is normal, because OMP just creates the remote Shuttle like ScnEditor would do.

At the moment The Throttle is applied the viewing client crashes. It doesnt matter what ship I use in the viewing client it always crashes. What is the common denominator in these 2 scenerios that is causing the crash?

So is it now throttle or just coming into visual range that crashes the second client? Do you mean that as a difference between stock and Shuttle Fleet shuttles?

 

[RacerX]

Thanks Face I will try all of those things later and I will try to have a detailed answer later on tonight when I have time to resume my testing.

 

[RacerX]

The animation support bug is not connected with a specific vessel. It is simply a problem with calling VESSEL2 callback for event playback. However, this could be a reason for some freak situations to play out. Please check with a PuTTYtel session to the server while reproducing the crash. Do you see some GINFO lines with text like "GEAR UP", "ROLL" or somesuch?

If so, it might be an event that is recorded and transferred that causes the remote Shuttle to crash.



The "not the whole stack" is normal, because OMP just creates the remote Shuttle like ScnEditor would do.



So is it now throttle or just coming into visual range that crashes the second client? Do you mean that as a difference between stock and Shuttle Fleet shuttles?

I got the shuttle to work using the older OMP client and server (OMP Client V0.3.3.0 alpha / OMPServer V0.5.3.0 beta) and using this server.xml setup:

${IF 1}${DESC}SpaceShuttle@Wideawake
${NAME}:Atlantis
STATUS Landed Earth
POS -14.4433210 -7.9687530
HEADING 273.78
PRPLEVEL 0:1.000 1:1.000 2:1.000
NAVFREQ 0 0
CONFIGURATION 0
CARGODOOR 0 0.0000
GEAR 0 0.0000
KUBAND 0 0.0000
ARM_STATUS 0.5000 0.0000 0.0000 0.5000 0.5000 0.5000
END
The newest client server did show a GINFO at SRB_IGNITION at that exact moment the viewing client would crash. I will test more with SSU and Shuttle fleet tomorrow. I have put the SSU pad and MLP at wideawake and successfully launched also using ${NAME}:Atlantis as the shuttle

 

[Face]

The newest client server did show a GINFO at SRB_IGNITION at that exact moment the viewing client would crash.

Yep, that's the dreaded animation support. It basically broadcasts recorder events to all clients and plays them back there. Looks like that crashes the client.

I will test more with SSU and Shuttle fleet tomorrow. I have put the SSU pad and MLP at wideawake and successfully launched also using ${NAME}:Atlantis as the shuttle

OK. Many thanks for the testing. Would you mind creating an account here and reporting those issues with the bug-tracker? Of course it works anonymously, too.

regards,
Face

 

[RacerX]

Account created will fill in the blanks now

 

[Face]

Thanks for the write-up. Here some points that caught my eyes in your description:

This could help somebody trying to re-create what I have done here
these are my settings
1: In the server.xml is as follows
<snip>
I have UPNP enabled in my router. I did not forward ANY ports. Thats what UPNP is for! (Automatic port forwarding as needed)
notice 192.168.1.103 is the "local ip address".

You don't need UPNP for forwarding ports inside a LAN. You may need it to open firewall holes, though. In any case, UPNP is a security risk and far from being a silver bullet to solve connection problems, so please do not advertise it as such in connection with OMP.

2: You then connect with the client running on the server PC on "network" tab using
Server-LAN ("hairpinning") wait for sync! This is usually around -6 or -5 in the MJD grey box area on the OMP staus tab

If you do not use the server for out-of-LAN clients, the Server-LAN setting is unnecessary. As long as you stay inside the same LAN, neither Custom nor Server-LAN setting is recommended.

3: Get on another PC connected in your lan network and connect to the server (in my case it is 192.168.1.103) using Server-LAN (hairpinning") and wait for the sync -6 or -5. Both clients should see each other and vice versa.

Server-LAN see above.

4:Server.xml addition I used
<snip>
And dont forget to give this a MFD also in server.xml or server will crash on launch.

Did you mean the client crashes on launch? Because the server doesn't pay much attention to the actual scenario content, it would surprise me to give an effect to miss out an MFD section.

Could you also post a revised reproduction recipe in the issue on BB? It would be helpful to have it sit right there if I review the issues later.

regards,
Face

 

[RacerX]

I edited the above post because for some reason I can not sync anymore. So I would not cause any confusion I just edited the above post untill I am sure I was correct. I have Turned off UPNP and forwarded the ports but now I am seeing and have been seeing some sort of error. I think I am blocked from the NTP time servers somehow