OHM OMX with Nex'Orbiter OMX v.1.1.0 (alpha) within Nex'Orbiter

[Boxx]

Boxx submitted a new addon:

OMX with OrbiterX - Orbiter Multi-Player in a persistent universe

First release of a new era of Orbiter Multi-Player features!

Warnings:

1. These OMX v.1.x.x versions are part of a series of Alpha versions. If you are not an advanced Orbiter user, you may feel discouraged. Please, come back later with versions Beta.
2. Advanced users shall use with a vanilla Orbiter 2016 install, as some default files are permanently replaced. You are warned.
3. Unfortunately, I could...

Read more about this addon...

 

[Boxx]

Here is a quick start guide, to take into OMX and its current implementation OrbiterX as a persistent universe (still highly epxerimental, you may lose your vessels):

• Connect at orbiterx.obspm.fr, with the User name you want and password "toto" (then, I can remove a zombie, if any)
• Select your starting pad at Rachambeau airport. Your vessel is named after your own name (for now)
• Take off, fly ro the Moon or wherever to you want.
• Before disconnecting, go to STC MFD, selects an existing user (ORBIX should be there 24/7) with STC button
• Check with "OFR" that your vessel can be offered (you'll get "<<<" if you control it actually)
• Then, click "GO" and wait until you see your vessel leaving away (use the Ship menu if needed)
• now, you can disconnect.

When reconnecting:

• Choose a different user name (as it creates a vessel with that name) and connect to the pad you want
• With Ship menu, select your previous vessel and go to STC MFD
• Use button "TAK" to check that you can get your vessel back
• Then click "BCK" to board on it (still you may need to use Ship menu again)
• you can check that you are in control of the vessel with the OFR button that will show "<<<"

Then, you can make maneuvers and transfer + disconnect again...

After 24 hours of tests, it appears that ORBIX client disconnects when another Client requests to take back one of its hosted vessel. ORBIX keeps working with all vessels but is no longer sync'd with the server!! Please confirm... Then, I have to restart ORBIX, hence losing (?) hosted vessels.

 

[Boxx]

ORBIX keeps working with all vessels but is no longer sync'd with the server!! Please confirm...

Help!

Actually ORBIX is fully alive with all hosted vessels functional. Is there any way to re-connect to the server (even manually) with the same IP, same port(?), and then restore the previous status as seen from the server?

 

[Boxx]

it appears that ORBIX client disconnects when another Client requests to take back one of its hosted vessel.

It does not happen every time. For people interested in troubleshooting network issue, a detailed report of this issue is given in the gitlab here. I'm also here to support some investigation or make additional tests. In the meantime, we'll keep going with this risk of disconnection (it's the aim of an Alpha version, isn't it?)

I'm planning to make regular flights from Mars to Phobos, which are quiet short trips at 1G-thrust (<1h) and very nice approach and landing. Anybody can join for formation flying.

 

[Boxx]

Boxx updated OMX with OrbiterX with a new update entry:

OMX 1.0.0 (alpha) Fix in the zip file

(still alpha version) For some reason, a file did not survive the zip/unzip process. Hence, download specifically "Orbiter.Multiplayer.client_dll.jpg", change the suffixe "_dll.jpg" into ".dll" and place / replace into Modules/Plugin/DotNET.

I hope I will find out soon what's wrong while zipping/unzipping this file specifically.

Read the rest of this update entry...

EDIT: Fix found

 

[Boxx]

For some unknown reason, also the .dll file provided as a fix (1.0.1) is not always downloaded in a proper way (maybe an issue with linux vs. windows binaries while downloading?... it reminds me something with FTP, maybe similar...). If your Orbiter runs without OMClient module selected but the Launchpad crashes to desktop just after selecting OMPClient module, that's the reason.

If somebody can advise me a way to provide the .dll binary in full integrity, I'm interested.

 

[Boxx]

Solution found!
A default option in Windows, called "SmartScreen", may lock some downloaded files. Although I do not recommand to disable this option, you can unlock the downloaded .dll by displaying its properties (right click on the file) and check "unlock" checkbox. I can't say why this problem never happened to me before....


EDIT: this issue seems related to unzipping from the default "Download" folders. Then, download the zip files to some other local folder.

 

[Boxx]

Boxx updated OMX with Nex'Orbiter with a new update entry:

OMX v.1.1.0 (alpha) within Nex'Orbiter

Addon presentation was edited, please read it. New features in OMX v1.1.0:

• MFD STC shows if a vessel is locally controlled and if it is grounded (landed)
• Shorter GINFO sent (extended only in "transfer")
• Landed status reviewed and extended (inspired by ParkingBrake)
• More stability in vessel transfers, keeping thrust or parking status
• (fix) vessel status on non-spherical surfaces managed locally and shared remotely
• (fix) remote vessel suspended and/or jittering above...

Read the rest of this update entry...

 

[Boxx]

Now OMX is super-easy to install: just unzip into a vanilla Orbiter 2016 (to avoid conflicts) and accept all replacements. Reminder: OMX will remain a GPLv2 engine. It supports a persistent universe (i.e. deep space, saving states, continuous propulsion, life support, cooperation). It does not target a "connect, fly and forget" concept (which is also nice, like the "Lite" addon, but different).

However... after 1.5 year at developing OMX as a fork of OMP, I am convinced that it must be greatly simplified and, at first, become tolerant to disconnections. With all due respect for the devs of OMP who included many features (10k+ lines of code for the client only), I want to "descope" it. This thread is to let know my plans and, if anyone wants, to provide warnings, suggestions or questions.

Top Dev Priorities:

• The server shall be re-written (in C++?) and shall target state vector management via file-writing, not only in RAM (while still compatible with many(?) connections).
• Connection: the interface will be minimized to the strict minimum (no user-controlled logging, stun, time parameters...), mandatory features will be moved to the "STC" MFD. User account management will take priority (does a vessel already exist or not? if yes, go to it, otherwise you're an invitee with no savings...)
• Vessel class: each accepted vessel class needs to be carefully validated (for "transfer" capabilities), thus only the DeltaGliders and the Wheel stations will be recognized for some time.
• UDP: at the moment I don't know how to replace this, but it could become a goal (nbcfrosty talking about web sockets....). Indeed, UDP requires to explicitly open some ports in the user's Internet access, which is too complex. In the meantime, I will probably change client's RK4 into a Kalman filtering to decrease the rate of UDP sending.

 

[Boxx]

• The server shall be re-written (in C++?) and shall target state vector management via file-writing, not only in RAM (while still compatible with many(?) connections).

What about PostgreSQL linked to C++ server with libpqxx... would also pave the way to mulitple (Linux or Windows) servers in redondance...

 

[Face]

OMP in the beginning also had a C++ server implementation. I've abandoned that because of many problems with platform-dependency and memory corruptions in multi-user scenarios. The managed .NET server implementation was much more stable. My suggestion would be to stick with .NET, but use the new versions of it (>5.0). In addition, best practice is to make it work in the cloud from the get-go, this way you can benefit from good scalability (if done right) and availability percentage.

I agree that persistency is key to make the experience better, and for that storing information in a database is a good way forward. However, I find offline propagation also an important aspect of persistency, but so far didn't manage to integrate Orbiter as a propagation machine directly into such a server implementation. My current experiment uses a .NET server running on Azure featuring a storage-account big table for state management, together with a protocol to feed dedicated propagator clients that "fly" your vessel during your absence.

I also agree on UDP: the advantage of twitch-based gaming it offers is not worth the troubles it's causing in setup. Instead of this I'd suggest to start with simple HTTP endpoints and a polling approach. In my tests I learned that web-sockets can open up a whole different can of worms: scalability issues.

On the subject of reducing the sandbox to a more controlled environment, I'm also in your camp. The goal of my experiment was to find a viable way to not only create a persistent multi-player world, but also one that gives meaning to the actions by means of enabling causality under time acceleration. I.e.: gamification should be possible, so that you can e.g. introduce credits, assets, economy aspects, etc. Certainly this is only possible in a tightly controlled environment in contrast to the open sandbox where users can change the simulation whenever they want. It also makes testing easier.

Nice to see people still tinker with the multi-player idea in Orbiter. Have fun!

 

[nbcfrosty]

In my tests I learned that web-sockets can open up a whole different can of worms: scalability issues.

Can you elaborate? Websockets are very similar to HTTP.

 

[Boxx]

many interesting avises here, thank you, Face

stick with .NET, but use the new versions of it (>5.0).

I guess I can re-code a server in C++ (not C#) using .NET (5+, because <5 not supported after VS2019) and still compile to Linux tagets, can't I? (unless I use Windows' GUI... but if terminal only it should work in Linux)

 

[Face]

Can you elaborate? Websockets are very similar to HTTP.

As discussed already on Discord, Websockets and scalability have a difficult relationship. A simple google search yields many results for those terms, but this here is a good read to begin with: https://thenewstack.io/the-challenge-of-scaling-websockets .
To summarize: hidden states in many websocket implementations often lead to it being impossible to scale "horizontally" properly.
The best way to experience the problem is to try it, though. Go ahead and experiment, folks.

 

[Face]

I guess I can re-code a server in C++ (not C#) using .NET (5+, because <5 not supported after VS2019) and still compile to Linux tagets, can't I? (unless I use Windows' GUI... but if terminal only it should work in Linux)

Well, there is C++/CLR for .NET, but this basically compiles down to intermediate code, anyway. The advantage that .NET >=5 offers is that you don't need to compile for different targets anymore. A compiled application or DLL runs just the same on Linux as on Windows, given that you don't use platform-specific features like WPF. Since the server is separated from Orbiter's process anyway, why insist on making it with C++? You just make your life harder.

 

[Boxx]

Small information, good news:

my sponsor (i.e. my employer...) just renewed its support and confidence in Nex'Orbiter experiment. We'll open the website in a few weeks to tell just-a-little-more about the gameplay, that you could also influence with contributions... In the meantime, let's improve create the disconnection-tolerance, but this support already means free hosting of a server, few virtual machines, 3 PCs and IT support!