Join queue despaghettification

[SpaceMonkeyy86]

• The join queue logic is now centralized in a single async method and no longer relies on fallible callbacks
• It is now impossible for the queue to get stuck even if a player crashes their game while connecting
• Players enter the queue once the base game has finished loading to reduce unnecessary delays

[tornac1234]

Probably some things I've not seen yet and didn't test that many figure cases.
One issue I've found is PlayerDisconnected() doesn't trigger a queue continuation. If you join with 2 players, and when both are in the waiting queue and you suddenly Atl+F4 one of the clients, the server will be put in pause state without resuming for the other one (it waited for 5 minutes tho but that's a "worst case" situation while we would have just been able to resume the queue once we know that the loading player was disconnected).

Also there's no way to tell that you're waiting once you're in the loading. You should get informations with like the number of player in front of you in the queue and maybe a maximum wait time calculated by number of players in queue * InitialSyncTimeout, we should definitely add some more visual elements for the player instead of locking him in there without any information. I think we discussed this once, I proposed that we would have some sort of UI on top of the screen showing the informations we want (those proposed above and the timing passed waiting also) and a way to leave the queue and head back to the main menu.

I would not want this merged without at least some information given to the player, and then we'd set the UI I proposed for a later PR.

[SpaceMonkeyy86]

I agree, this PR needs a dedicated UI screen to be production-ready. I think we should go ahead and add it now because it's bad practice to merge a PR that says "Finish me later with another PR."

[tornac1234]

Would like to hear about where this is going. Should we try to restrict the scope of this PR (e.g. postpone early loading which needs more work as said above) to at least have the fixes merged ?

[SpaceMonkeyy86]

I think so, adding new menus sounds more like a beta feature. We do need to add at least some kind of additional UI to the loading screen, however.

[tornac1234]

How's this going ?

[SpaceMonkeyy86]

I took a very long break from this project because I was busy and my interests had changed, so I haven't been keeping up with things very closely. Actually, I was thinking of getting back into Nitrox, and this is a good time to do it. This PR is functional (last time I checked) but to be "polished" it still needs some sort of UI on the loading screen to show progress, or just to modify the vanilla progress bar. That would be better suited for a separate PR. Other than that, it should work (I just need to fix the conflicts).

[SpaceMonkeyy86]

Ready for review again. This PR is a blocker for a few things such as loading screen info (and it's also just a lot faster/smoother than the current implementation), so I would like to see this in the upcoming release if possible. We should also do in-game testing, where we build a lot of bases and vehicles to make the sync take longer and try various combinations of joining at the same time and crashing the game to make sure the server holds up.

[SpaceMonkeyy86]

Ok, changes made 👍

[Jannify]

LGTM CW