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.
I've done a little experimenting with extending the hardcoded limit to the IFF display, and I do feel the sensor manager would keep it pretty fair: as I described, you'll only see friendly target IFFs in the extended view, except when an enemy is already detected either by you or another teammate actually looking in their direction, or if active sensors in your network have picked them up. Still, it remains true that people with wider aspect ratios would be given a little more awareness of what's going on around them.
It mostly just looks weird to see IFFs pop in when they're pretty deep into your screen, bumping the pickup window up would help that. So, biased response but I vote for extended IFFs on high FOV/aspect ratios given limitation of sensor manager. Some folks will still play tight FOVs by choice.
BF6 beta stirred up a lot of conversation on the auto spot feature versus the more manual predecessors. Hardly a settled debate, but I think high awareness is a good feature in Tribes. Not sure how deep the engagement will get on this thread towards finding a community consensus..
I agree with this, playing at 3440x1440 it did feel weird having the IFFs pop in when players are a fair ways into my FOV, my vote would be to bump up the pickup window.
Weird how? Just guessing based on your description it sounds like your alpha channel (used for the emap shiny/metalness effect) might be saved incorrectly. Are you using the SuperPNG photoshop plugin to export, or some other editor?
The error is probably the tournament client vl2, you can safely remove that
That is probably correct, yes it gives it a metallic look. I am modifying in paint, or AI, don't have PS. Oddly enough, it seems to work most of the time now.
Removing tournament client was the fix for console spam.
Yeah, since the game predates modern approaches and reads the map for this effect from a channel that'd show up as transparency in most viewers, the workflow can be a little tricky to work with. If you're not saving the alpha/transparency at all, it'll probably work fine, you just won't see the effect.
The problem with the IFFs disappearing near the edges of the view seems to happen even for really narrow FOVs, like even more narrow than the old standard unpatched game. It's not just a little bit near the edge either, it's like a couple of inches in on either side of the screen where they disappear. It really seems like a bug somehow
I think it would be great if it always matched the screen view. I think the original devs would have made it so the IFFs show up on the whole screen no matter the monitor aspect ratio or FOV.
It'd be possible to put something like Opus in, but I hadn't really given it much consideration because I figured most people prefer to use Discord. On the OpenAL sound driver integration, I did give the microphone input better recording quality (using SDL3's audio device subsystem, so technically not itself using OpenAL there), but obviously it still ends up going through that old Miles codec when sent over the network.
Mathematically those narrow FOVs you're setting aren't technically more narrow than the their equivalents in the standard unpatched game, and this is what I meant when I said the latest update does change the standard projection a smidge; like changing the lens on a camera. The previous version tried match the behaviour seen projecting horizontal fov degrees to 4:3 aspect ratios, but strictly speaking, given the same FOV values and deriving the projection from initial vertical input, you're now seeing more of the scene at the edges of the screen (compared to the default) at any aspect ratio above 1:1, so simple calculations using for example a dot product to test whether the angle is within a set view cone are going to diverge a little more from the characteristics of the camera.
I suppose it might be a good idea to have a choice between a fixed "HOR+" 4:3 adjusted value to closest match the old visuals/math and the (current) direct mapping to vertical FOV, the former just might seem kinda meaningless in the menus to someone trying to match a setting they use in other games.
I have no problem allowing IFFs to work on the full screen given how the sensor manager works, there's just no putting the cat back in the bag if it upsets anyone.
This cutoff is basically just the navhud stepping through all the general player targets the server has told the client they should be aware of, and deciding whether or not it's in a spot where the icon would be seen if it tries to render it. In the base game that check would roughly line up with the horizontal edges of the screen (i.e. where you see them appear is how far zoomed in you'd normally be), but right now, because that code hasn't been touched, it's too tight. It wasn't done as a gameplay consideration then, just making sure to only render what was needed.
The server sensor scope and fov values control whether a target in sight would be picked up by the network and communicated to your team, which is why extending it really shouldn't be problematic: if you spend a few minutes watching everyone move around in the command circuit (or ask an enemy player to use a jammer or sneak up to the side behind you), only the enemy players that you see show up there would have IFFs if they're not actually in front of you.
At the same address? This was caused by debris being removed from the scene trying to release one of its particle emitters, but I suspect the debris had already been deleted and freed already, probably in the same tick.
There were a few targetted fixes for things like explosions that had similar crashes, but if it might need a more general safety check if it's recurring.
I'll probably have another build for some fixes and minor rendering tweaks this weekend, but no promises on that latest issue if it turns out to be more complicated.
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.
I've done a little experimenting with extending the hardcoded limit to the IFF display, and I do feel the sensor manager would keep it pretty fair: as I described, you'll only see friendly target IFFs in the extended view, except when an enemy is already detected either by you or another teammate actually looking in their direction, or if active sensors in your network have picked them up. Still, it remains true that people with wider aspect ratios would be given a little more awareness of what's going on around them.
It mostly just looks weird to see IFFs pop in when they're pretty deep into your screen, bumping the pickup window up would help that. So, biased response but I vote for extended IFFs on high FOV/aspect ratios given limitation of sensor manager. Some folks will still play tight FOVs by choice.
BF6 beta stirred up a lot of conversation on the auto spot feature versus the more manual predecessors. Hardly a settled debate, but I think high awareness is a good feature in Tribes. Not sure how deep the engagement will get on this thread towards finding a community consensus..
Couple other test notes:
1) Tried a 1024x1024 weapon skin. It loads for a second then starts looking weird. Not sure if I'm bad at making skins.
2) console is spamming:
(ruby) Runtime error (6356692)
TNCommunity: Unmatched nonce in challenge returned by server...
I agree with this, playing at 3440x1440 it did feel weird having the IFFs pop in when players are a fair ways into my FOV, my vote would be to bump up the pickup window.
Weird how? Just guessing based on your description it sounds like your alpha channel (used for the emap shiny/metalness effect) might be saved incorrectly. Are you using the SuperPNG photoshop plugin to export, or some other editor?
The error is probably the tournament client vl2, you can safely remove that
That is probably correct, yes it gives it a metallic look. I am modifying in paint, or AI, don't have PS. Oddly enough, it seems to work most of the time now.
Removing tournament client was the fix for console spam.
Thanks!
Yeah, since the game predates modern approaches and reads the map for this effect from a channel that'd show up as transparency in most viewers, the workflow can be a little tricky to work with. If you're not saving the alpha/transparency at all, it'll probably work fine, you just won't see the effect.
Krash any consideration of updating the built in voice comms for a better codec and team only along with global comms?
The problem with the IFFs disappearing near the edges of the view seems to happen even for really narrow FOVs, like even more narrow than the old standard unpatched game. It's not just a little bit near the edge either, it's like a couple of inches in on either side of the screen where they disappear. It really seems like a bug somehow
I think it would be great if it always matched the screen view. I think the original devs would have made it so the IFFs show up on the whole screen no matter the monitor aspect ratio or FOV.
Thanks for working on this patch, it's awesome.
It'd be possible to put something like Opus in, but I hadn't really given it much consideration because I figured most people prefer to use Discord. On the OpenAL sound driver integration, I did give the microphone input better recording quality (using SDL3's audio device subsystem, so technically not itself using OpenAL there), but obviously it still ends up going through that old Miles codec when sent over the network.
Mathematically those narrow FOVs you're setting aren't technically more narrow than the their equivalents in the standard unpatched game, and this is what I meant when I said the latest update does change the standard projection a smidge; like changing the lens on a camera. The previous version tried match the behaviour seen projecting horizontal fov degrees to 4:3 aspect ratios, but strictly speaking, given the same FOV values and deriving the projection from initial vertical input, you're now seeing more of the scene at the edges of the screen (compared to the default) at any aspect ratio above 1:1, so simple calculations using for example a dot product to test whether the angle is within a set view cone are going to diverge a little more from the characteristics of the camera.
I suppose it might be a good idea to have a choice between a fixed "HOR+" 4:3 adjusted value to closest match the old visuals/math and the (current) direct mapping to vertical FOV, the former just might seem kinda meaningless in the menus to someone trying to match a setting they use in other games.
I have no problem allowing IFFs to work on the full screen given how the sensor manager works, there's just no putting the cat back in the bag if it upsets anyone.
Are you getting now what the server would deem 120fov by old standards for iff scope?
If the server allows higher fov (player.cs 132) does the client see and allow higher iff scope?
Ya, this is tough
Wonder if a server-side pref maximum allowed iff scope would work? I guess that could be spoofed too
This cutoff is basically just the navhud stepping through all the general player targets the server has told the client they should be aware of, and deciding whether or not it's in a spot where the icon would be seen if it tries to render it. In the base game that check would roughly line up with the horizontal edges of the screen (i.e. where you see them appear is how far zoomed in you'd normally be), but right now, because that code hasn't been touched, it's too tight. It wasn't done as a gameplay consideration then, just making sure to only render what was needed.
The server sensor scope and fov values control whether a target in sight would be picked up by the network and communicated to your team, which is why extending it really shouldn't be problematic: if you spend a few minutes watching everyone move around in the command circuit (or ask an enemy player to use a jammer or sneak up to the side behind you), only the enemy players that you see show up there would have IFFs if they're not actually in front of you.
If there's no further complications other than pissing off comp players. I think we should go for it. I was thinking there were some other reasons.
Got this as soon as a match ended. Has happened a few times I think
At the same address? This was caused by debris being removed from the scene trying to release one of its particle emitters, but I suspect the debris had already been deleted and freed already, probably in the same tick.
There were a few targetted fixes for things like explosions that had similar crashes, but if it might need a more general safety check if it's recurring.
I'll probably have another build for some fixes and minor rendering tweaks this weekend, but no promises on that latest issue if it turns out to be more complicated.