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]

It still works!

[Jannify]

Would this make sense to be merge before or after #2023 ?

[SpaceMonkeyy86]

I don't think it matters. They shouldn't break each other, right?

[SpaceMonkeyy86]

The PR is ready for review now. Just one thing - currently, if the client is in the queue, the loading screen disappears and they can play as normal. However, when they start syncing it reappears and anything they did is undone. This is unintentional, but I left it in for now since it's nice to be able to jump/swim around while waiting instead of just looking at a static image on a loading screen. Should we keep this in? Maybe add something to the queue enter message to let the player know what is happening?