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.
Whoa, this fixed an unhandled exception issue in windows 10 I would run into trying to run the game since 2024 lol. Testing the rest of the game and I'll come back with anything.
Edit: I also crash after a successful match ends and starts loading a new map.
I can't do anything about any crash reports that don't have the error address and the crashlog.
There is a new build in the first post though that includes limited protection against the game trying to write data on objects that have already been removed, which in theory could happen when a SimGroup is removed on the client with the object still in it.
Other changes:
Rewrote the DirectX interop shared memory synchronization for modern hardware levels (OpenGL 4.5 + D3D11) to use GL_EXT_memory_object and GL_EXT_semaphore and a D3D fence instead of relying on the legacy NV_DX_interop2 extension, which, despite being an Nvidia extension, is not well supported on Nvidia devices (at least not as documented). While rarely used extensions, in theory there's more recent driver support, and on supported devices this should have the best local input latency response on your screen when you'd rather not let the GPU just churn out extra unused frames, and should not block on the CPU side. Of course, I'd rather not be targeting DirectX specifically, but interop with DXGI is the shortest path to providing the low latency option with accurate hardware timings rather than using vsync estimates.
The 10 bit color mode will be selected by default on supported displays.
$pref::Video::exclusive = 1; may provide smoother DXGI frame timing on some hardware when fullscreen, however this will not use variable refresh rates
DXGI interop still doesn't have a safe fallback to pure OpenGL when it's able to set up the device and swapchain but create/connect the interop buffer. Next time, maybe.
Restored previous backface culling behaviour on shape rendering, which may fix rare projectile visibility issues (haven't reproduced, start recording a demo if you see it on multiple shots)
Added a little more safety checking to loading wave files before passing the buffer to Miles (still goes through old path though, may need checks on that part if issues persist)
Added a check on removing SimObjects to abort running again if the Removed flag has already been set
Added a (currently unread) server status flag for indicating that the server is in online mode with native TN auth supported
Fixed the $Host::Linux variable not being hooked up to allow disabling the penguin icon on Wine servers (or adding it if for some reason you want to)
Extended the IFF icon visibility to horizontal FOV range. Fix is a bit of a stop-gap, but saves having to rewrite the whole search
I considered backporting some packet timing synchronization changes to better line up physics and projectiles received from the server to the exact tick, but because it requires changes to the protocol, it breaks demo compatibility, and supporting multiple client protocol levels gets complicated. Could be worth building out the ability for the server to use switch protocols for patched/unpatched clients, but the there's not really a practical way to on the fly strip it back down to an older protocol for demo recording...
ik you mentioned not having access to a mac for testing, unfortunately I'm running t2 on a macbook pro through porting kit 6.5.0 and getting an error every time I try booting up, idk how much you might be able to assist without testing yourself but hoping maybe you have some things I might be able to try to get it running, 2018 MPB w/ 2.6ghz i7 16gb ram running macos sequoia 15.6.1
Not being able to test a config myself just means someone else needs to be willing to test and report back as much detail as they can.
Might be hard to pin down without debugging Wine, but an error in uxtheme.dll would occur while SDL3 is setting up the window style, which does use relatively recent DWM mechanisms, but should have wide backwards compatibility – and nothing is really bespoke in that area (with the exception of earlier DPI awareness settings, not hit here).
Do you know if it's a recent Wine version (if it's too old, you might also run into other issues), or if it can be updated? Can you check to make sure your winecfg doesn't have Tribes2.exe set to use a compatibility profile for an old Windows version? Can you try toggling the options for allowing the window manager to decorate windows on the graphics tab? Or maybe try setting the desktop integration theme to "no theme"?
Ahh, this is looking like the actual cause was a memory leak loading the audio data up into Miles – it's just straight up slowly running out of allocation space. There was a custom Dynamix extension for loading audio which kept the buffer in the same place it's processed in memory, and when reimplementing the processing to fix the glitches it was changed to copy the buffer over to Miles... and I unfortunately missed that the original code never frees the buffer that's input into that extension unless it fails.
That'll definitely get fixed this week. Might tweak it again later to reduce i/o when reusing audio.
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.
Whoa, this fixed an unhandled exception issue in windows 10 I would run into trying to run the game since 2024 lol. Testing the rest of the game and I'll come back with anything.
Edit: I also crash after a successful match ends and starts loading a new map.
I can't do anything about any crash reports that don't have the error address and the crashlog.
There is a new build in the first post though that includes limited protection against the game trying to write data on objects that have already been removed, which in theory could happen when a SimGroup is removed on the client with the object still in it.
Other changes:
$pref::Video::exclusive = 1;may provide smoother DXGI frame timing on some hardware when fullscreen, however this will not use variable refresh ratesI considered backporting some packet timing synchronization changes to better line up physics and projectiles received from the server to the exact tick, but because it requires changes to the protocol, it breaks demo compatibility, and supporting multiple client protocol levels gets complicated. Could be worth building out the ability for the server to use switch protocols for patched/unpatched clients, but the there's not really a practical way to on the fly strip it back down to an older protocol for demo recording...
Krash, do you have a patreon or some other way I could buy you a coffee?
ik you mentioned not having access to a mac for testing, unfortunately I'm running t2 on a macbook pro through porting kit 6.5.0 and getting an error every time I try booting up, idk how much you might be able to assist without testing yourself but hoping maybe you have some things I might be able to try to get it running, 2018 MPB w/ 2.6ghz i7 16gb ram running macos sequoia 15.6.1
Not being able to test a config myself just means someone else needs to be willing to test and report back as much detail as they can.
Might be hard to pin down without debugging Wine, but an error in uxtheme.dll would occur while SDL3 is setting up the window style, which does use relatively recent DWM mechanisms, but should have wide backwards compatibility – and nothing is really bespoke in that area (with the exception of earlier DPI awareness settings, not hit here).
Do you know if it's a recent Wine version (if it's too old, you might also run into other issues), or if it can be updated? Can you check to make sure your winecfg doesn't have Tribes2.exe set to use a compatibility profile for an old Windows version? Can you try toggling the options for allowing the window manager to decorate windows on the graphics tab? Or maybe try setting the desktop integration theme to "no theme"?
With the latest patch I was able to get into a second round without a crash.
Went back to Miles audio, might be what happened.
Ahh, this is looking like the actual cause was a memory leak loading the audio data up into Miles – it's just straight up slowly running out of allocation space. There was a custom Dynamix extension for loading audio which kept the buffer in the same place it's processed in memory, and when reimplementing the processing to fix the glitches it was changed to copy the buffer over to Miles... and I unfortunately missed that the original code never frees the buffer that's input into that extension unless it fails.
That'll definitely get fixed this week. Might tweak it again later to reduce i/o when reusing audio.