Substantial delay in connecting a player to a multiplayer server running JoshariasSurvival

What you were trying to do

Connect normally with a 2nd client to an already running game server without extensive load times. Varies based on modules enabled.

A hosting client doesn’t take an inordinate amount of time standing up the server and connecting to it. Issue does not present in plain CoreSampleGameplay.

With ManualLabor enabled (identified as a culprit in #4126) connecting took a moderate 30-45 seconds for player 2. With the rest of JS enabled it went to a full 3 minutes in one test.

What actually happened

Logging in for JoshariasSurvival did succeed after #4148 was merged, and didn’t slow down the host, however it took a full 2-3 minutes for no apparent constructive reason. @keturn has done some initial research noted on #4126 and on Discord (in #stabilization I think) that points to more potential issues like what #4148 fixes, that might be rooted in how Gestalt handles some stuff. So this may be a fix needed over there (either as a point release for the 5.x line or eventually by upgrading to 7.x)

Progress bar may hold some hints as to which parts are causing the delays. Asset scanning and system initialization seemed two big ones. Just trying to look real quick it seemed like about 45s for asset scanning. 1m for initializing systems for the first player to join a headless server. Think initialize systems took longer with a hosting client + client.

How to reproduce

• Host a server via game client running JoshariasSurvival (or configure override.cfg and run a headless server)
• Wait for the server to be fully online and connect to it with a second client
• Observe the loading time, progress bar, and stages of game logging

[keturn]

Recapping some of my ramblings from #stabilization:

Watching the connection/loading process with a profiler does reveal some slow things.

When I looked at some of those things (which do relate to asset scanning and initialization), I found some places I believe have potential for optimization.

The hitch is that I’m new to these tools for profiling multi-threaded Java applications, and I’m new to those parts of the source, and I have very little surety that the things I was looking at are the same things responsible for making multiplayer so much dramatically worse than it was a release or two ago. After all, it’s not like gestalt v5 changed in that time.

(though now that I mention it, it’s possible we did change something about the gestalt dependency in the TeraNUI branch.)

Bisecting the history to discover when the issue started would be very useful. Not only would it provide more confidence that we were looking at the right problem, I think it would do wonders for morale and maintainability to be able to say “this is what changed and this is the impact it had” to replace my current vague dread that something changed but no-one can say what.

I’m daunted by the thought of conducting a search that requires navigating not only engine’s version history, but that of JoshariasSurvival and its dependencies as well. I don’t know if there’s someone more fearless who is willing to tackle that, or if we first need to set up some tooling to facilitate that kind of multi-repo search process.

[keturn]

Now that Terasology is using gestalt-module v7, this is up for re-investigation.

See if we can still reproduce this. Maybe it was fixed by v7 itself.