I tried out your game, and I noticed two things as it loaded.
The rate at which assets are loaded is slower the fewer assets are in the loading queue
New assets are added to the loading queue while the game is loading
It sounds like it’s entirely possible for the rate of loading and the rate of new things requiring loading to perfectly match each other.
You should check what’s being loaded. You’re likely to find that when loading fails, the last things being loaded are assets that exist only temporarily.
I released an update which applied the new solver as well as somewhat reducing the complexity of how the script welds vehicles, but joining today my own beefy computer stuck on the “assemble” section for 36 seconds before kicking me from the server so I’m back to square one.
I have a few vague ideas on the next steps to solve the issue but I could use some feedback as I’m still way out of my depth with this stuff. I’m 99% sure the cars must be responsible because they’re pretty much the only thing in the game that relies on physics. I’m thinking of trying:
Union as many parts of the frames as possible to reduce the necessary weld count.
Fusing the vehicles with WeldConstraints and see if the behavior is any different
Preweld the vehicles beforehand so they don’t have to be dynamically welded each time they spawn.
Use attachments instead of welds for wearable cosmetic items (on the off chance vehicles are not the cause)
These things will take some time so any feedback on what to try first or a different approach would be greatly appreciated.
Also @rbadam if possible could you share what the aforementioned internal investigation turned up?
When I was making a paintball game, having many parts physically simulated on the server (i.e. NetworkOwner is nil) while the player is loading caused the window to hang. I found this out while stress testing my game. I had to resort to using raycasts instead of parts.
Are you using a ton of parts which are simulated on the server?
I just enabled something that should reduce the freeze by about 3x, any chance you can verify?
There was a certain issue with places that are made of lots of parts and each part is individually anchored. It would attempt to ask the question whether something was fixed in place, which would attempt to traverse an internal structure. Turns out if you have every part marked as anchored, it’s simply easier to ask if they part is anchored rather than try to traverse its parents in case they are anchored too.
Old code was causing a quasi quadratic lookup in certain physics regions. Anyway should hopefully be faster now (although this isn’t the final fix), let me know if that helped.