Challenge Next multi-user event in Moon orbit... stay tuned

[Boxx]

* EDIT (2022-12-31) *
This starting post in the thread will evolve to keep track of the past events and to prepare the next event:

• (past) Elephant Walk 2022-09-11: annoncement below and report here
• (past) surprise connection during a tutorial 2022-10-08... and fun! brief and link here
• (past) event on 2022-10-30 see brief and results
• (past) Search & Rescue missions in orbit (2022-dec), with a varying degree of success (see Highlights)!
• NOW: Debris removals (2023-jan)....
• NEXT: in Moon orbit (preparation on its way)

The latest version of the OrbiterX package is v2-4.1, attached below, or available here. Install the required Addons => see Note B below.
(if you just installed v2-4, simply move OMPMissile.dll from <yourOrbiter>\Modules\Plugin to <yourOrbiter\Modules. Sorry for that.)
--- (below = original post) ------------------------------------------------------------------

YOU ARE INVITED to an Elephant Walk on next Sunday, Sept.11th, 2022, at Rochambeau airport, French Guyana: CONNECT FROM 14:30 UTC, 11:30 local time (16:30CET, 07:30-10:30US from West to East, 23:30JST, 04:30HAST) with OMP on "orbiterx.obspm.fr".

1. Why? For the fun and for tests => see Note A, below.
2. Install the required Addons => see Note B.
3. Connect with OMP from 14:30UTC, and before 15:30UTC (end of event) => see Note C.
4. As soon as connected, leave your Pad to the TaxiWay in front of you (watch left and right!)
5. Drive to RunWay 08, at SPEED 3m/s (20-25kN is enough, adjust with brakes and tiny bursts Num+)
6. On RunWay 08 align left, then center, then right, then left etc... see picture.
7. Keep your distance (as shown) and your SPEED 3m/s until Exit E. (c.a. 10min), see picture.
8. From Exit E, you MUST either:
- quit to the left at Exit E, and visit the very cute Rochambeau Airport
- take off (the remaining runway shall be enough) and have fun in the air
- exit Orbiter (i.e. disconnect)

Recording could last until 15:30UTC. The video will be posted here if it is good. The event could become a big mess but we'll have fun anyway. The airport will remain open as long as you want. If you are not available this time, watch for the next event




Note A: Why?

We (fellows and I) have set up a new OMP server 24/7, i.e. a permanent universe. It is just opening publicly and we want to test it before developing a gameplay. This universe will be oriented to the exploration at 1G, survivability of the crew (weight & shocks, air, water, food, radiation) and cooperation. First, let's see if our server can afford a lot of connections... or if it crashes at some point! We have a lot to do but, in the meantime, we hope you can enjoy some events with us.

Note B: Required Addons

Have at least the following Orbiter Addons downloaded and installed, in this sequence, and accept all replacements:
0- a fresh Orbiter 2016, if you've got some Crash-to-Desktop.
1- jacquesmomo a.k.a. Papyref's Rochambeau URL here or torrent in ZIP attached, thank you Papyref!
2- From ZIP attached, extract folder "yourOrbiterFolder" in... your Orbiter folder.
(note: no need anymore to install Face's OMP addon as a new "OMX" version is included in the attached ZIP, thank you Face!)

Test your install (no need for connexion) with the scenario "OrbiterX > Tour from Rochambeau".

Only the basic DeltaGlider is available for now. The following addons are recommended as well, although not mandatory: Martin Schweiger's HiRes textures (torrent in ZIP), DanSteph's OrbiterSound (URL here), Jarmonik's D3D9 Client (if used with orbiter_ng, torrent in ZIP).

Note C: Connecting with OMP on the EW Day (see also the illustrations below)

• on the Launchpad, select the optional Modules LifeMFD and OrbiterSound
• on the Launchpad, eventually select OMPClient, a new window shall open
• in OMP subwindow, tab Network, input the Server "orbiterx.obspm.fr" with port 1515
• in OMP subwindow, tab Network, input User Name = YOUR ID (short, please) and Password "toto" (yes, t, o, t, o, for everybody so I can manage possible zombies in the server... thank you)
• on the Launchpad, click "Connect Orbiter" (bottom left)
• in OMP subwindow, click in the empty 1-line field above "Choose a vessel....", leave it blank and type Return
• then, doubleclik on the Pad you want to be connected to.

On the EW Day, I will record the event and also do my best to anime an Airport Traffic Control (ATC) on Discord > OMP channel (I'll have to train a little). Please go there to know what Pad is free before connecting, to hear and talk with the ATC, otherwise connect on a randomly chosen Pad. Hope it works

AS SOON AS CONNECTED, leave your pad with tiny bursts (and brakes) to free the pad and reach the taxiway in front of you. Average speed shall be 3m/s on ground, please, to avoid a big mess!!

By the way, you can already connect and discover the nice Rochambeau airport (after installing all addons). No traffic regulation. No status saved on exiting. You should see "ORBIX" vessel parked around (or see on Twitch channel if live). Then, come back on EW Day.

 

[Face]

Good luck with your setup! Just be aware that the O-F OMP download is not working since the migration from OHM. However, on the O-F OMP page, there is a link in the description pointing to the repo installation WIKI, which has a functional download link.

 

[Boxx]

Indeed, thank you for the warning! I edited the first post with your link.

 

[Boxx]

I was told that the correct wording for such event is "Elephant Walk" (not march)... which I corrected.
If anybody has advises, comments, questions, please post here, and it will help spread the word for the event until Sunday... For instance: what is an "Elephant Walk"?

... this:

 

[Boxx]

Dress rehearsal before Sunday:



Let's be optimistic: just imagine tens of DG like this, taking off one after one after the Elephant Walk, flying above the airport all together for a moment

ok, back to preparations, now let's see Discord > OMP channel.

 

[Boxx]

Help for tomorrow, Sunday 14:30 UTC (reminder) => I saw on the "orbiterx" server that at least 5 users connected without IDs. Then, I assume the connexion process is not that clear. Let's detail how to connect here and, remember, you can test your set up and the connexion (and some flight) as soon as now. Just feel free to give it a try.

HOW TO CONNECT:


1. (after downloading and installing the addons) in "Modules", check LifeMFD and SoundOrbiter (optional)
2. still in "Modules", check OMPClient => a new subwindow opens...
3. input orbiterx.obspm.fr and port 1515 as shown for the Server
4. input your NICKNAME (vessel's name) and "toto" for the password
5. then click "Connect Orbiter"
....

6. in the subwindow, put the cursor (i.e. click) in the empty line (shown by "6") THEN press ENTER
7. when the list of pads is displayed DOUBLE CLICK on the desired Pad

again, as soon as connected and operational, leave your pad to reach the taxiway just in front of you, then drive to the runway 08 at speed 3m/s.

(we'll try to make it simpler someday)

 

[Boxx]

we had some issues at coordinating (but fun!). Actually we lost somebody nicknamed Chups.
Dont' fly like me at t=19'15''
I am now very interested in any feedback (complexity, schedule, interest, future events and locations....). Please react. First feedback is:

• 7 IPs were connected according to the server
  
• but only 5 were visible (incl. Chups). Hence, there was some bugs... but what, for who, when?.... no idea
• apparently the event is well adapted for new Orbinauts (some users could not drive straight or smooth and some crashed )

This was a humble attempt but quiet fun already.

 

[Face]

Nice setup! Unfortunately, I'm very busy these days with RL stuff, so I was unable to join the fun. Some ideas for your next event:

1. You can use 2 clients on the same machine if you use MOGE and D3D9Client in parallel. I know that this works because I used this configuration to test client/server in the past, all on one machine. This might help you debug things like UDP problems, if they arise.
2. For ad-hoc coms, you can use the inline chat feature. Just type something in the OMP client window and it should be transmitted to everybody's client chat section. Of course voice is better, but at least initial coms and quick directional advice may work through this.
3. You can use the scenario editor with OMP. This way you can quickly play with formation setups like this due to its positioning feature. Even if the taxiing should be done for immersion, error corrections or fine-tuning can be done faster than turning that DG around.

 

[Boxx]

For ad-hoc coms, you can use the inline chat feature. Just type something in the OMP client window and it should be transmitted to everybody's client chat section. Of course voice is better, but at least initial coms and quick directional advice may work through this.

Yes, I was aware of this feature that works fine. However, I've seen users how close the OMPClient window as soon as connected... and I had so much to deal with OBS + Discord + my vessel, I could not add the writing!!

By the way, I just discovered how Twitch works (don't laugh), and I think it would be much better for these events to inform about available Connexion Pads and provide audio regulation. Orbiter on Discord is limited to subscribed users, hence maybe not the best channel. I will consider using Twitch for the next try. Soon.

You can use the scenario editor with OMP. This way you can quickly play with formation setups like this due to its positioning feature. Even if the taxiing should be done for immersion, error corrections or fine-tuning can be done faster than turning that DG around.

I'm surprised: if my vessel is A, and I jump into vessel B (somebody else's connexion) with the scenario editor or the Ship selector, I cannot modify its remote state, can I? I tried some time ago and it was my conclusion.

 

[Face]

I'm surprised: if my vessel is A, and I jump into vessel B (somebody else's connexion) with the scenario editor or the Ship selector, I cannot modify its remote state, can I? I tried some time ago and it was my conclusion.

Yes, you can't change remote vessels. What I meant was that often users are not aware that they can use ScnEditor to correct themselves if taxiing goes wrong.

 

[Boxx]

As we are preparing another Elephant Walk in October (hopefully) before organizing another easy & fun event .... on the Moon (yes!), soon after, here are a few news in preparation of this next event:

• the setup is a bit different from the last one: as soon as connected, your DeltaGlider already moves forward (thrust 6%). Don't panic: you will slowly leave the Pad and reach the taxiway (30 sec.), also it is a convenient thrust to stabilize at 3m/s. Watch around and take the taxiway to the left to reach Runway 08.
• WHENEVER you want, watch for the real-time webcam at Rochambeau (time is given in UTC, French Guyana local time is UTC-04:00, I think):
  • you can see the free PADs to connect to and, once connected, you can see yourself on the TV and your are seen from the whole world (and universe). If you want to connect alone or with friends before the event, just do so at your own risks, the airport is not controlled
  • Twitch link = real-time Rochambeau
  • This Twitch link, if LIVE, will be used to moderate the event in real-time. Have an account there before the event to chat during the stream (also "follow" this channel and "LIKE" the previous streams, thx)

FEEDBACK: Some tests on the real-time broadcast, yesterday over 24 hours, were quiet convincing. You can replay on Twitch the 3 visits we got on the airport and that I have extracted from the stream (2 by night and 1 by day, see the video comments). Also I could note that visitors from Cuba (close to French Guyana, actually) and from Slovakia (so far, wow!) connected without vessel identification. Then I am suspecting that the procedure to setup (addons) and to connect is still unclear. Tell us so, here, otherwise, we cannot improve. Counting on you... and hoping you'll enjoy.

Tentative date for the event: Saturday or Sunday within 22....30 October 2022, at 16:00UTC or 17:00UTC.

 

[Boxx]

Hi, I made a tutorial this morning (French Guyana time) on how to setup, to connect and to take off & land at night... and you know what? Somebody connected at the same time (maybe because I made the announcement on twitch yesterday for today) and hunted me during the tutorial !!!! ... well, it was really fun and it made a great event: a good pilot, apparently... until the crash

see 2022-10-08 "highlight" here from 00:23:30 in the Full video
(and "FOLLOW" and "LIKE" etc....).

 

[Boxx]

A few fellows and I have selected the 30th of October (Sunday) for the next Elephant Walk on the server orbiterx.obspm.fr. New Orbinauts or new users of the Multi-player module are especially welcome, before we move to more challenging events

The stream shall start at 17:00UT on Oct.30. Warning that Sunday, we will change from Summer time to Winter time in some countries (e.g. in France). The reference time is the one streamed on the real-time webcam on Twitch (given previously):

• The setup is stil the same like previously here (1st post of this thread). Do not forget to leave the pad as soon as connected?
• I know the connection process is still complex: everyday at 18:30UT on that Twitch until the event, I will be there for a Q&A session. Just ask.

The goal is still to test the servers with a fun & friendly event. If you've got some Twitch channel, don't hesitate to record from your own point of view as well!

 

[Boxx]

Finally, we experienced some instabilities (we were too lucky so far). Sometimes; somebody connects and it makes ORBIX client (the client on the server's computer) crash, but the server does not crash. This may be linked with NSTP issues as we can see that ORBIX client has some brutal acceleration (2.0x) and some important latency (MJD 39 / -6 / -81) as shown on this:


If you are experienced with this issue in OMP, I'm interested.
If you can test now, i.e. before the event, and report any issue (or no issue within 3 mn after connecting successfully), I'm interested as well. Also, I'm connected on Twitch every day at 18:30(UT) until the event, to discuss anything about this experiment........

In the Twitch stream, the bottom-left inset tells the server's status and as long as no red lines appear, it's ok. The main view is from ORBIX client, if it becomes black, it means that it crashed... Then report and I will go to the logs and see if we can investigate. Anyway, that's the aim of the experiment.

 

[Face]

Just remove the SNTP server definitions and run your server unsynchronized. The only thing that really counts is the sync between server and clients, not towards NTP. Server and clients sync with PTP in later versions of OMP, anyway.
Quite possibly your hickup there was due to a bad SNTP server response offsetting your server clock, and thus causing the ORBIX client to accelerate in order to catch up with it. Or somebody guessed your admin password and set the MJD forward with an admin connection. In any case, x2 is the maximum the sync mechanism uses automatically to catch up. You can override it for higher acceleration as long as the clocks are off sufficiently, but you can't limit it.

 

[Boxx]

I did so in both the server xml and the client xml and, indeed, ORBIX client did not crash anymore. Although multiple vessels (with different IP) can connect without making anyone else crash, they don't see one another as reliably as previously (they appear/disappear frequently). We saw this behaviour at the beginning of our server setup and solved it (wrongly?) by the use of our own sntp.

By the way, my OMP parameters may be wrong (I don't understand so well the sync' stories) and we ended up with this "TIMING" line on server's side. Was this correct?
<Timing Transmitter="200" SNTP="2000" Resync="60000" />

...that I changed back to the default values today, as follows:
<Timing Transmitter="1800" SNTP="250" Resync="2000" />

Server and clients sync with PTP in later versions of OMP, anyway.

Used OMP version is 0.8.2

 

[Boxx]

The crash of a client by the connection of another client still occurs (in addition of the sporadic visibilities by one another). We are looking at our logs for any drifts in our nstp servers in the last days. In the meantime, I re-installed the nstp.obspm.fr setting, which proved to ensure several days/weeks of stability. But I don't understand the detailed numbers. The OMP documentation (reminder 0.8.2) doesn't tell any details. Thank you Face, I don't want to harass you, so if anybody else has got explanations, it will be helpful as well:

• user-level explanations of the Latency numbers in OMPClient window (once connected)
• admin-level explanations of TIMING settings in the server.xml file (see prev.post)

 

[Face]

I did so in both the server xml and the client xml and, indeed, ORBIX client did not crash anymore. Although multiple vessels (with different IP) can connect without making anyone else crash, they don't see one another as reliably as previously (they appear/disappear frequently). We saw this behaviour at the beginning of our server setup and solved it (wrongly?) by the use of our own sntp.

By the way, my OMP parameters may be wrong (I don't understand so well the sync' stories) and we ended up with this "TIMING" line on server's side. Was this correct?
<Timing Transmitter="200" SNTP="2000" Resync="60000" />

...that I changed back to the default values today, as follows:
<Timing Transmitter="1800" SNTP="250" Resync="2000" />


Used OMP version is 0.8.2

In order for the PTP mechanism to be used, the client should not have SNTP configurations as well. I had an unsynchronized server running for a long time and never observed sync issues with it, so perhaps something else is at play in your setup.
What your timing lines there mean is as follows:

• The first line makes the server transmit every 200ms to a connected client, do 2s calls to SNTP, but wait after the specified number of calls (perhaps the default 30) for 60s, then makes the next NTP run. It makes a busy client stream and a slow sync.
• The second line makes the server transmit every 1,8s to a connected client, doe 250ms calls to SNTP, and wait only 2s after the NTP run. It makes a lazy client stream and a fast sync.

The crash of a client by the connection of another client still occurs (in addition of the sporadic visibilities by one another). We are looking at our logs for any drifts in our nstp servers in the last days. In the meantime, I re-installed the nstp.obspm.fr setting, which proved to ensure several days/weeks of stability. But I don't understand the detailed numbers. The OMP documentation (reminder 0.8.2) doesn't tell any details. Thank you Face, I don't want to harass you, so if anybody else has got explanations, it will be helpful as well:

• user-level explanations of the Latency numbers in OMPClient window (once connected)
• admin-level explanations of TIMING settings in the server.xml file (see prev.post)

Once again, I can only say that using the SNTP feature in server and clients is not the way to go. The OMP documentation shows details about the OMPClient window numbers on page 14:

The numbers to the right are actual measurements of the maximum (upper), minimum (lower) and median (middle) value of the real-time clock skew w.r.t. UTC of the current machine. Normally, this is between 800 and 20 us/s in both directions. Additionally, the middle numbers show the maximum (upper), minimum (lower) and average (middle) value of the current machine's simulation time offset w.r.t. the server's simulation time.

Naturally, this outdated documentation does not take into account that UTC (SNTP) is not necessary anymore. In the case of the unsynchronized server, replace "UTC" with "common time", which is essentially the server machine's free-running clock. Everything else is as it was before, so the doc is still valid.

In addition, the documentation contains a diagram of the syntax tree of the server configuration in appendix A on page 23:


I'll try to explain it further:

• The NTP tag has attributes "Samples", "History", "Offset", and "Skew". "Samples" is how many samples are taken via SNTP calls to generate one NTP "calculation". "History" is how many NTP "calculations" are stored to average the current clock skew. "Offset" is only used on startup and defines how far off the machine's clock is to UTC. "Skew" is also only used on startup and defines how "skewed" the machine's clock is w.r.t. the atomic clock base.
• 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". "Transmitter" is the time in milliseconds until the next transmission of data to server and neighbor clients is done. "GarbageCollector" is the time in seconds between GC runs, deleting remote vessels without update of transmission data. "SNTP" is the time in milliseconds until the next SNTP call is generated within an NTP run. "Resync" at last is the time in milliseconds between NTP runs.

As you can see, the SNTP/NTP algorithm is overly complex with many settings. That's why I've got rid of it by means of using PTP with an unsynchronized server instead. This was stable for years, actually. Even on Azure VMs.

 

[Boxx]

Thanks a lot, Face!! With your explanation, some figures of the documentation make more sense. Hopefully, the setup will be stable enough for the next event.

@all, potential attendees on Sunday: I'll make additional tests and, then, post a summary of the setup. To the maximum possible extent, I'm trying to NOT change the addons that we need, thus the same like in the very first post of this thread. But keep an eye here!

 

[Boxx]

Kind reminder for tomorrow, 5pm UTC (check your local time, the time in the server is the UTC time).

Here is a video briefing to connect and to drive, in my good Frenglish

Setup = same like the fist Elephant Walk (first post of this thread), i.e. at least:

1. Orbiter 2016 (thank you, Martin) +...
2. Face's OMP = this link (thank you, Face)
3. Papyref's Rochambeau = this link (thank you, Papyref)
4. OrbiterX v2-1.zip = this link
5. Keep a Twitch window opened on the LIVE for tchat & audio coordination = this link
6. Then, connect to orbiterx.obspm.fr, port 1515 (refer to note C in the very first post of the thread)

Hope to see a few of you tomorrow, Sunday 5pm UTC, on the tarmac at Rochambeau, French Guyana