The screens you're referring to are controlled by remote command messages through the script engine, and the messages are guaranteed to be received in order, so your mod has scripts telling the client to show that screen after they've loaded in... or else is just sending the MsgLoadInfoDone message way too late and the client is still checking if it's done after finishing loading the map. Loading too fast to delay it, basically; the OG client scripts check every 500ms to see if MsgLoadInfoDone has been received, so if that message comes too close to the end of the load (or after), it can wake and pull up the loading gui after completion.
Classic mod for example apparently has a thing to send info to clients multiple times with a 6 or 7 second scheduled delay (already having sent MsgLoadInfoDone, in that case, though), which could conceivably exceed your load time.
I could add a hook in the client script patches to stop the client doing 500ms checks to see if the load info is done after they've already loaded, but that will only prevent those specific cases bringing up the LoadingGui, not any other issues with sending the commands or pushing other screens like the DebriefGui too late.
Interesting! I was atttemping to join Classic mod servers when experiencing this issue. (Chocotaco's servers). I do notice the preview build does seem to load much quicker so maybe this is exactly the issue im running into. I have the game installed on a SATA SSD, not even NVME, not sure how to slow its load time somewhat to test.
I do have a thing that brings up a special debrief with server info etc that is on a hard set timer when you first load in. Possibly client loaded in before that screen pops. I'll try shortening it a few seconds now that things are much faster.
Also some other things Ive noticed: Plasma and Shocklance are sometimes disappeared. Haven't seen the Shocklance myself.
And IFFs are cutting off at the edge of the screen. Fov thing?
For safety, you could also either cancel the scheduled debrief if it's pending when serverCmdMissionStartPhase3Done is received, or abort in the function doing the sending if %client.isReady == true
I had seen the plasma disappear in certain conditions before, could've been a back-face culling issue, but hadn't seen it with the shocklance... will have to reproduce to prevent it.
The IFF search fov is standard, untouched hardcoded engine behaviour, and at least for hostiles is in part due to how the sensor visibility network operates (although it's possible a separate cross-referenced variable isn't being updated, keeping it a little tighter than it should be). I didn't want to unilaterally decide on pulling it out and rewriting it to widen with the screen (while respecting sensor visibility, i.e. only friendlies in your periphery would have icons, unless the enemy is in active sensor scope), or how far to allow it to go, because it could be argued that full-field IFF scanning would give an additional advantage to players with ultrawide screens in competitive play. I haven't played competitively in decades, so that's another feedback area.
Let me know if there are other crashes you run into there, I don't spend a ton of time building nav graphs, so I've only addressed the ones I've encountered.
Comments
The screens you're referring to are controlled by remote command messages through the script engine, and the messages are guaranteed to be received in order, so your mod has scripts telling the client to show that screen after they've loaded in... or else is just sending the MsgLoadInfoDone message way too late and the client is still checking if it's done after finishing loading the map. Loading too fast to delay it, basically; the OG client scripts check every 500ms to see if MsgLoadInfoDone has been received, so if that message comes too close to the end of the load (or after), it can wake and pull up the loading gui after completion.
Classic mod for example apparently has a thing to send info to clients multiple times with a 6 or 7 second scheduled delay (already having sent MsgLoadInfoDone, in that case, though), which could conceivably exceed your load time.
I could add a hook in the client script patches to stop the client doing 500ms checks to see if the load info is done after they've already loaded, but that will only prevent those specific cases bringing up the LoadingGui, not any other issues with sending the commands or pushing other screens like the DebriefGui too late.
Interesting! I was atttemping to join Classic mod servers when experiencing this issue. (Chocotaco's servers). I do notice the preview build does seem to load much quicker so maybe this is exactly the issue im running into. I have the game installed on a SATA SSD, not even NVME, not sure how to slow its load time somewhat to test.
Krash,
Thank you so very much for this QOL update !!!! I am in the process of making 2 new
bot maps, & I never could get a successful spawngraph file built no matter what I
tried. I couldn't build a bot nav graph, either. So, I installed a seperate version
of T2 with RC2A & your QOL update & I used that version to build the new spawngraph
& the new navgraph file & it worked perfectly :) No UE CTD at all :) I then take the .spn
& .nav file from the QOL installation & move it back into my bare-bones installation &
continue editing normally to finish the map out. I was very close to giving up on making
new maps... Thanks so much !!! :)
I do have a thing that brings up a special debrief with server info etc that is on a hard set timer when you first load in. Possibly client loaded in before that screen pops. I'll try shortening it a few seconds now that things are much faster.
Also some other things Ive noticed: Plasma and Shocklance are sometimes disappeared. Haven't seen the Shocklance myself.
And IFFs are cutting off at the edge of the screen. Fov thing?
Video: https://youtu.be/mEK7RNG2zuE
For safety, you could also either cancel the scheduled debrief if it's pending when
serverCmdMissionStartPhase3Doneis received, or abort in the function doing the sending if%client.isReady == trueI had seen the plasma disappear in certain conditions before, could've been a back-face culling issue, but hadn't seen it with the shocklance... will have to reproduce to prevent it.
The IFF search fov is standard, untouched hardcoded engine behaviour, and at least for hostiles is in part due to how the sensor visibility network operates (although it's possible a separate cross-referenced variable isn't being updated, keeping it a little tighter than it should be). I didn't want to unilaterally decide on pulling it out and rewriting it to widen with the screen (while respecting sensor visibility, i.e. only friendlies in your periphery would have icons, unless the enemy is in active sensor scope), or how far to allow it to go, because it could be argued that full-field IFF scanning would give an additional advantage to players with ultrawide screens in competitive play. I haven't played competitively in decades, so that's another feedback area.
Let me know if there are other crashes you run into there, I don't spend a ton of time building nav graphs, so I've only addressed the ones I've encountered.
So far so good with this.