# ChallengeNext multi-user event in Moon orbit... stay tuned

#### Boxx

Donator
To be frank, I think the event yesterday was a half-success only: there were 7 of us connected but only 3 visible, too bad!! But it's ok, as it is part of the experiment as well. Lessons learned:
• Stack of add-ons + Connection process = too heavy procedure
• Training (for beginners) is desirable in advance: for setup and piloting
• The Twitch page helped to understand what was going on. For sure that's a good addition
• The server and its local client (ORBIX) ran well (we doubled the CPU and the RAM just on Friday, the streaming appears too demanding)
• It is a place for fun encounters, even before the event
• One can move someone else's vessel: the after-party showed the pilot Jankzi playing a "Smack!" with ORBIX
Here are some links for those who want to follow this experiment:
The next event should be a "butterflies flight" with a vessel to be selected among 2 possible, then taking off by hoovering from a Moon station and starting a Low Moon Orbit as a swarm (not too ambitious?)

Jankzi's Smack! to ORBIX:

Last edited by a moderator:

#### Boxx

Donator
@Face :
• The NTP tag has one or many Server children tags.
• A Server tag has attributes "Address", "Misses", "Delay", "Alarm". "Address" is the SNTP server host name. "Misses" is the amount of allowed SNTP call misses before the server is suspended. Suspension means, that the server is not taken into account while randomly choosing servers for SNTP calls. The "Delay" means how many suspended "hits" the random algorithm must do on the server before it is reactivated again. It is a multiplier, meaning that value of "Delay" times value of "Misses" is the exact amount of suspended "hits". "Alarm" at last means at which point the server is permanently suspended from being taken into account. Again, this is a multiplier, meaning that value of "Alarm" times value of "Delay" is the exact amount of misses allowed for the permanent suspension taking place.
• The Timing tag has attributes "Transmitter", "GarbageCollector", "SNTP", and "Resync".
I'm coming back to these settings.

Apparently my OS (on a virtual machine) needs SNTP. I understand that I could as well select multiple "possible" sntp servers... and why not, indeed. Then, the more the better, isn't it?

Timing tag is possible on both Client and Server sides. What does it mean for each one?!, for instance if "Transmitter" contradicts/collides between server and client(s)?

Nevertheless, I am testing again the no-SNTP configuration: then all non-dashed tags and attributes (in documentation) should be given, shouldn't they?

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
@Face :

I'm coming back to these settings.

Apparently my OS (on a virtual machine) needs SNTP. I understand that I could as well select multiple "possible" sntp servers... and why not, indeed. Then, the more the better, isn't it?

Timing tag is possible on both Client and Server sides. What does it mean for each one?!, for instance if "Transmitter" contradicts/collides between server and client(s)?

Nevertheless, I am testing again the no-SNTP configuration: then all non-dashed tags and attributes (in documentation) should be given, shouldn't they?
Your setup does not need SNTP. What is important is that clients are synchronized to the server clock, but not that the server clock is synchronized to UTC. It is necessary that both client and server configurations omit the SNTP tag. If the server syncs to UTC but the clients don't, it is not so problematic, but the server could get a "hickup" from stalled SNTP server calls (e.g. if the single SNTP server you configured is down or blocks you due to DDOS measures). If one or more clients sync to UTC, but the server doesn't, they won't sync at all. Best thing is to leave out the SNTP on both sides.

Transmitter timing on both sides is how long the sender loop waits before it does another round. Nothing more. Since the protocol is not a handshaking one, but more like a streaming thing, differences in the values don't matter beyond the immediate effects of a fast or slow transmitter. Probably the combination of transmitter and garbage-collector timing is more important: if e.g. the server has a long transmission interval of say 1 minute, but the client garbage-collector is set to 1 second, you will only see remote vessels for one second, then they are gone for almost a minute again.

Therefore I'd recommend to stay with the values that come with the distribution. On both sides. Those are:
• no SNTP tag in client config, only transmitter timing configured to 200ms
• no SNTP tag in server config, transmitter timing set to 200ms. The SNTP call timing is set to 2s there, as well as the resync interval set to 1m, but this has no effect.
BTW: you can experiment with timings during the session as well, by means of using the in-chat commands that are escaped with "%" on default settings. Entering "%help" in the chat window will list you the available commands. That's only available in clients, of course. No such thing on the server side.

#### steph

##### Well-known member
I probably won't partake anytime soon, I still need to polish my orbital rendezvous techniques to be able to do it without abusing the fast forward feature, but how much bandwith would be needed for a usual play session? Say, could I connect via a mobile hotspot etc?

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
I probably won't partake anytime soon, I still need to polish my orbital rendezvous techniques to be able to do it without abusing the fast forward feature, but how much bandwith would be needed for a usual play session? Say, could I connect via a mobile hotspot etc?
OMP is lightweight on bandwidth on the client side, especially if the session has few users. You have one TCP stream and one UDP transceiver. I guess with 10 users it would work just as well over 56k modems.

#### Boxx

Donator
Therefore I'd recommend to stay with the values that come with the distribution. On both sides. Those are:
• no SNTP tag in client config, only transmitter timing configured to 200ms
• no SNTP tag in server config, transmitter timing set to 200ms. The SNTP call timing is set to 2s there, as well as the resync interval set to 1m, but this has no effect.
These settings have been deployed for 2 days without failure, so we can indeed consider them stable. Thank you for your support.

BTW: you can experiment with timings during the session as well, by means of using the in-chat commands that are escaped with "%" on default settings. Entering "%help" in the chat window will list you the available commands. That's only available in clients, of course. No such thing on the server side.
Indeed, and quiet advanced commands.... to be explored step by step

Also, I could see on ORBIX' log that multiple short connections from many places were attempted (UK, Germany, US / several locations, Slovakia, Indian ocean...). These connections were very short, i.e. 1 to a few seconds up to 90s, without succeeding at showing a "vessel" with its Tail-ID. Does it mean that users try to connect and fail? please report if so. Or are these only attempts by some bots.....

(attached = v2-2, includes modified OMPClient.xml)
* EDIT * Attachment updated, use the ZIP attached in the very first post of this thread

Last edited:

#### Boxx

Donator
I probably won't partake anytime soon, I still need to polish my orbital rendezvous techniques to be able to do it without abusing the fast forward feature, but how much bandwith would be needed for a usual play session? Say, could I connect via a mobile hotspot etc?
On our side, I want to prepare a "simple" lunar space meeting, then we hope to be able to deploy an "OMP" version with a save/restore function between client and server, to allow users to keep their vessel from a connection to the next. So we still have a little work ahead...

In the meantime, the use of OMP behind a low bandwidth connection is worth reporting. ORBIX can serve as a target: if it appears stable in your client, it means that your own vessel likely appears to be stable by others.

Or if ORBIX crashes, you can see it on Twitch... and no drama with that, actually you can try a Smack! (docking) with ORBIX, it's fun and if ORBIX client crashes I will reset it a bit later.

#### Boxx

Donator
Debris removal now: there are 2 boosters and 1 main tanker left uncontrolled in low Earth orbit, on OrbiterX server. "Shoot them" (!) and take control of the Twitch channel.
• Warning: never "shoot" a debris in space or you'll create many more!!! Here, it's for test, fun & training, the debris will auto-magically disappear Actually a nice addon would be some grabing device to get dropped at close range from a debris, to grab it, de-tumble it and drag it to re-entry... any volunteer?
• Once connected on OrbiterX (orbiterx.obspm.fr, port 1515, user name as vessel's ID, password "toto" please):
• Fly to rendez-vous with the debris shown by Twitch ("Debris-99", at the time of writing)
• Target-lock on it with CTRL+ALT+C until target sign gets green
• Shoot with CTRL+ALT+Space. You've got only 3 missiles.
• If successful, the debris will disappear and Twitch will focus on your own vessel, that you can fly back to re-enter and land. You're welcome to stream from your own channel as well (and to PM me).
• Please don't shoot ORBIX on Rochambeau tarmac, or you will loose the Twitch broadcast (and the debris).
You MUST have OrbiterX v2-4.1 installed (see first post of the thread). If you installed a previous version, re-install this package and make sure to remove "OMPMissile.dll" from Modules\Plugin (the latest version must be at Modules level, and only there). Updates of this file may be provided, stay tuned. In the package, you'll find the LifeMFD addon, give it a try!

These training missions in Earth orbit are prepared to wait until the next event on the Moon (that we do not forget). In December, we had a few Search & Rescue missions to de-orbit ORBIX, that was locked with no propellant in Low Earth Orbit (see Twitch highlights). With debris removal, a first try is also available in the highlights.

Not that easy, good hunt!

Last edited:

#### General_Mile_1

##### New member
I installed everything but sadly it doesnt work for me, I got error message Unable to connect to server version '0'! Minimum supported version is '0.8'

#### Attachments

• image.png
389.4 KB · Views: 6

#### Boxx

Donator
Something else is wrong. You should see the message "Server version 'OMPServer 0' seems not supported (mini '0.8'). Continue anyway.":

Code:
OrbiterX
Dura Lex Gravitate,
sed Lex Gravitate
---    the Global Brain   ---
EM1.3 at Rochambeau Airport
Server version 'OMPServer 0' seems not supported (mini '0.8'). Continue anyway.
Joined server...
---------------

About this warning: don't pay attention, with my package you are already in version 0.8++ but I still have not disabled this false warning (yet another small thing to fix before a serious release...)

Then : you should use Orbiter (not Orbiter_NG, that may not work... I haven't checked at the moment) + my zip package in version OrbiterX 2-4.1 (or later) provided in the first post of this thread. Thank you for this feedback. It is valuable as I am currently working on the persistent feature... stay tuned.

#### Boxx

Donator
I installed everything but sadly it doesnt work for me, I got error message Unable to connect to server version '0'! Minimum supported version is '0.8'
For sure you need my zip package 2-4.1 but have you got Visual Studio 2019 installed on your computer?

(I know, it should not be needed, but it reminds me a bug report with my addon LifeMFD...)

Replies
4
Views
319
Replies
9
Views
1K
Replies
58
Views
5K
Replies
118
Views
10K
Replies
4
Views
730