Miles crashed trying to do sample rate conversion on a wave file – possibly a file with incorrect headers, but I've played every sound included with the game without seeing a problem. A wave format with 32-bit samples could cause this, or just a corrupt/partial file on disk.
Interestingly though this part of the Miles mixer code doesn't actually get used for most gameplay sounds anymore specifically because it has issues processing ADPCM samples. It should only still be in use in looping environmental emitters and microphone playback. Do you remember what map this was on to see if it was an issue with one of the files used for its background audio?
It's possible to remove use of this resampler entirely in a later update if it still has issues.
There is a specific issue that some of us have experienced where the game will "stutter" when zooming. The issue can be described as:
1) Press the zoom key
2) Brief stutter, where the game freezes (half a second at most)
3) Then everything continues fine.
I would generally say that this is occurring once per zoom for a specific direction. For example, if I face a specific direction, and I zoom + stutter, and then I go back to normal view, and then I immediately press zoom again without moving, I will not stutter again. In other words, it's like the game has to take time to briefly load something. However, once loaded, everything is okay.
However, the moment you move again or face another direction, you'll stutter again when zooming. I also feel this is more impactful with maps with a larger viewing distance.
All of the above said, after experimenting with various settings, I believe I narrowed it down to the Textures => Terrain Texture Detail slider. If I put the slider all the way to the right for the max value, then I experience the above issue. However, if I move the slider slightly to the left, then the zoom issue completely disappears. I attached a screenshot with my setting. I'd make a recording, but it'd be impossible to tell when I'm actually pressing the zoom key.
At least two other people were experiencing this same issue, and making this adjustment seems to have fixed it for them as well.
Oh, that's mipmap generation on dozens of baked terrain sector tiles being generated and selected all in the same frame. It'll be removed in the next build, it wasn't meant to be left on, I was tuning the detail scaling while writing the new terrain renderer.
If you have a modern gpu you can try enableHybridTerrain(1); for now to bypass the OG baked texture blending and do the composition realtime on the GPU.
I used to be able to change my audio source in t2 on the fly by minimizing and selecting audio source through speaker in taskbar but now after the patch this no longer works. The audio will switch in Windows but remain the same in Tribes. It's sort of annoying cause sometimes I like to start playing with my speakers then put my headphones on when I get on Discord comms.
Thanks. I confirm that running enableHybridTerrain(1); fixes the issue, even when I have Terrain Texture Detail at maximum.
Follow-up: Is there any advantage to setting enableHybridTerrain(1); vs not? I ask, because if so, I'll just script it to turn on when I start T2 each time.
(Piggyback: I also have the same issue as fnatic's last post about the audio source. It would be nice if there was a "default" option, where it just defaulted to whatever windows is using. The biggest issue is that, after you join a match, you can't change the audio source again. You have to quit T2 fully, and then select the source before rejoining.)
enableHybridTerrain moves the bulk of the terrain rendering work from the CPU to the GPU.
The original renderer generates all of the terrain geometry you see on screen on the CPU dynamically every single frame, and the textures you'd see were all software blended and cached in memory, combining each material and the lightmaps for large areas in batches of what blocks are expected to be visible. The patch by default already accelerates terrain rendering with a number of optimizations and replaces the software blender with a faster GPU implementation of the same process, but at its heart it still works the same way; every time terrain is rendered, a stack of new meshes are generated and submitted to the GPU, textures are generated if not in the cache, and the higher the view distance and tiles needed, the more work the CPU needs to do, the more memory needed, the more state changes and data communicated to the GPU, and dozens if not hundreds of draw calls depending on enabled features. It's not always the biggest blocker per frame, but it can consistently lock up the main thread for a few milliseconds on a larger map or with a slower CPU.
The hybrid terrain renderer generates a single grid mesh on the CPU and saves it in GPU memory, and only submits new textures (materials, the height map, light maps, or splat maps) when that data changes. This essentially means when terrain needs to render, the CPU only needs to submit a minimal amount of changed state data per frame (e.g. dynamic lights), and can render the entire terrain in one or two draw calls. The GPU does the work of calculating the height of each vertex, and combining the various textures on the fly every frame. Because a modern GPU can do this work in parallel extremely fast, it should almost always be faster than the traditional renderer on newer hardware. On iGPUs with shared memory and older systems though, it's not a sure thing, especially on the version included in that release.
It'll need to be optimized further and certain features used shortcuts that aren't available on all drivers for the earlier pass – the cutouts for empty holes for example may or may not work on your system. Once that's done it'll be added to the options menu somewhere, but if it appears to work fine now, it's fine to use. Running the command sets a client pref, so you don't necessarily need to add the command elsewhere, although opening the editor would currently disable it and require running the command again.
I believe the Miles output selection might've been an issue with an old API it switched to as a fallback, I'll have to check the startup code for it again. It's likely there's a conflict somewhere in the code preventing automatic stream routing, because Miles has always been set up to only select the default output device.
For the audio source issue try deleting Mssdx7sh.m3d and Mssdx7sl.m3d from GameData for the Miles stream routing issue – these are Miles 3D provider backends for DirectSound3D 7 software modes with high/low HRTF, and they don't show up in the menu on most systems, but it seems when the game tests them it might be leaving the device attached and preventing the automatic stream routing in Window's DirectSound WASAPI layer from working.
Don't know if this one is just my config as haven't heard others seeing it but occasionally my spawn will load with grenade launcher and ammo count on my spinfusor.
Yeah, that's all scriptable stuff that the patch generally shouldn't touch, so it could be your config. A modded server might send a limited set of commands to change the reticle and what's displayed, but your client scripts decide how to interpret it.
Try to record a demo if you can reproduce it, because if it's the server doing it, it'll do the same thing played back on a clean config or unpatched game.
Looks like that's the same beacon hud crash you had previously; the fix I described (preventing rendering beacons when your control object is not a player) was added to last week's build.
There isn't, since the only time the UI scale is changed by the game, it'll be represented after the onUpdateRenderTargets callback runs (following creation of new buffers or resizing of existing buffers), and UI scale changes alone are nominally always done by client scripts calling setUIScale
Any script that needs to use the UI scale should never read the pref though, if that's your goal: it's unset by default, and not directly linked to the internal value as some variables are (because setUIScale needs to update shader uniforms), so calling getUIScale() to return the active scale is necessary to avoid undefined behaviour.
There's no such call for the aspect lock pref; the way it works needs to bubble down through the game's existing internal GUI heirarchy parent/child resize calls, so you'd always want to use the canvas extents to find the current ratio.
Which build did you last install? This is a debris object that'd already been deleted running the removal code again on receipt of a packet from the server, and changes a few versions back should've prevented this.
If you've got the game installed in more than one spot, it's possible you might've patched a different install than was run by the shortcut you ran here. The more recent build had a bit more detail added to the crashlog file that would identify the version, and the memory management changes that should generally limit the possibility of this crash were included a few weeks back
Most likely what happened then. I had a couple non-patched version backups leftover from when we were first trying this, now deleted and the patch redirected to my shortcutted install.
There's a hotfix on the first post since I know that terrain issue is probably annoying, and it'll be a little bit longer before I can finish testing some pieces I wanted to add.
This one should include the following:
Remove Mssdx7sh.m3d and Mssdx7sl.m3d (legacy provider causing issues leaving buffers open on failed load)
Reset some Miles configuration values to their original defaults
Fix flying vehicle contrails when renderer is running with extremely low deltas (the particle engine is limited to 1ms integer durations, vehicles would attempt modulating trail delta by linear velocity and attempt sub-millisecond inputs)
Fix listen servers sometimes not listening
Fix rare accounts with shorter signatures not being able to complete handshakes (clientside, not a server issue)
Fix terrains doing unnecessary mipmap generation work on tile texture blending
The hybrid terrain renderer is somewhat more optimized and should support a wider variety of hardware/drivers. Unfortunately the Mesa driver for Haswell iGPUs on Linux still wasn't rendering correctly in my test case, but that's a device where the original terrain renderer will generally perform better due to the GPU's memory/bandwidth limitations. The detail sliders are connected, but may not have much of a noticeable impact on performance.
Amazing work as always Krash, thank you. Wondering how you fixed the deadstops, and if you've considered a dedicated server only install with just the bits needed for Krash optimised dedicated serverage? That would be kewl.
Also, how is it bots don't suffer deadstops, and does eliminating ipx from the stack have any bearing on bots as bots connect via ipx?
The short version is that because the collision test needs to solve both for terrain and for interior brushes where objects may hit an edge (think the acute angled corner of a slanted roof) at speed rather than the flat part of a surface plane, it was generalized to detect the most likely collision case for a given extrusion (basically the bounding box of a rigid body transformed to suit its orientation/momentum that frame). In most cases this worked fine: objects are rarely in a scenario where there's ambiguity between the two, you're almost always on a slope, or relatively static, or heading straight for something that's obviously a collider, however, with terrain...
If the object's bounding box were to interpenetrate the plane being tested, or if the base of the bounding box were coplanar with it, it would essentially switch to testing the front face of the box against the "edge" of the plane, presenting a collision normal directly in opposition to your movement when you hit the edge of a given terrain square; best case traversing it at lower speeds as though it were a step, worst case dead stopping, as though you'd hit a wall... because for all the engine knows, you did.
The updated version always uses surface normals for collisions with terrains and coplanar interior brushes. Terrains don't have any edges we should be colliding with, the entire thing is meant to be representing a single contiguous surface (holes notwithstanding) and can't technically even produce any geometry where you'd expect to collide with an edge. Arguably when hitting the convex "edge" intersection between two planes at the crest of a hill, a smoothed average between the two neighbouring surfaces might be a better option than using the normal of the primary plane being hit as it is now – but that's neither here nor there, it'd probably never be noticed and would be a minor divergence.
Bots generally speaking aren't often in scenarios where they'd hit the conditions necessary to get incorrect normals for a collision (you usually need to be going fast and have a bit of downward momentum on a flat surface), and even on the off chance they did hit it they'd treat it like any other minor obstruction and continue following the nav graph. There was nothing specifically preventing them from hitting deadstops, but they'd move on within a server tick or two, so to a human player it would look like they've just decided to change course.
Bots don't use network connections. They inherit from the GameConnection class because the engine uses objects of that type to control players/vehicles and have nametags and skins and whatnot, but moves/inputs for AIConnection objects are created and consumed directly within the game loop without touching the network stack.
Dedicated servers running this patch only load the code needed for dedicated servers, no client code is loaded (beyond linking Miles, which the Tribes2.exe has always done, but no Miles code is actually run unless you run the commands to start it up). It's not really practical to split it out into different distributions because everything the server needs is needed by the client... I mean, technically it'd be possible to move the client-specific code into another DLL loaded by IFC22.dll, but it'd need a lot of restructuring.
Comments
Miles crashed trying to do sample rate conversion on a wave file – possibly a file with incorrect headers, but I've played every sound included with the game without seeing a problem. A wave format with 32-bit samples could cause this, or just a corrupt/partial file on disk.
Interestingly though this part of the Miles mixer code doesn't actually get used for most gameplay sounds anymore specifically because it has issues processing ADPCM samples. It should only still be in use in looping environmental emitters and microphone playback. Do you remember what map this was on to see if it was an issue with one of the files used for its background audio?
It's possible to remove use of this resampler entirely in a later update if it still has issues.
@Krash
There is a specific issue that some of us have experienced where the game will "stutter" when zooming. The issue can be described as:
1) Press the zoom key
2) Brief stutter, where the game freezes (half a second at most)
3) Then everything continues fine.
I would generally say that this is occurring once per zoom for a specific direction. For example, if I face a specific direction, and I zoom + stutter, and then I go back to normal view, and then I immediately press zoom again without moving, I will not stutter again. In other words, it's like the game has to take time to briefly load something. However, once loaded, everything is okay.
However, the moment you move again or face another direction, you'll stutter again when zooming. I also feel this is more impactful with maps with a larger viewing distance.
All of the above said, after experimenting with various settings, I believe I narrowed it down to the Textures => Terrain Texture Detail slider. If I put the slider all the way to the right for the max value, then I experience the above issue. However, if I move the slider slightly to the left, then the zoom issue completely disappears. I attached a screenshot with my setting. I'd make a recording, but it'd be impossible to tell when I'm actually pressing the zoom key.
At least two other people were experiencing this same issue, and making this adjustment seems to have fixed it for them as well.
Oh, that's mipmap generation on dozens of baked terrain sector tiles being generated and selected all in the same frame. It'll be removed in the next build, it wasn't meant to be left on, I was tuning the detail scaling while writing the new terrain renderer.
If you have a modern gpu you can try
enableHybridTerrain(1);for now to bypass the OG baked texture blending and do the composition realtime on the GPU.I used to be able to change my audio source in t2 on the fly by minimizing and selecting audio source through speaker in taskbar but now after the patch this no longer works. The audio will switch in Windows but remain the same in Tribes. It's sort of annoying cause sometimes I like to start playing with my speakers then put my headphones on when I get on Discord comms.
Thanks. I confirm that running
enableHybridTerrain(1);fixes the issue, even when I have Terrain Texture Detail at maximum.Follow-up: Is there any advantage to setting
enableHybridTerrain(1);vs not? I ask, because if so, I'll just script it to turn on when I start T2 each time.(Piggyback: I also have the same issue as fnatic's last post about the audio source. It would be nice if there was a "default" option, where it just defaulted to whatever windows is using. The biggest issue is that, after you join a match, you can't change the audio source again. You have to quit T2 fully, and then select the source before rejoining.)
enableHybridTerrain moves the bulk of the terrain rendering work from the CPU to the GPU.
The original renderer generates all of the terrain geometry you see on screen on the CPU dynamically every single frame, and the textures you'd see were all software blended and cached in memory, combining each material and the lightmaps for large areas in batches of what blocks are expected to be visible. The patch by default already accelerates terrain rendering with a number of optimizations and replaces the software blender with a faster GPU implementation of the same process, but at its heart it still works the same way; every time terrain is rendered, a stack of new meshes are generated and submitted to the GPU, textures are generated if not in the cache, and the higher the view distance and tiles needed, the more work the CPU needs to do, the more memory needed, the more state changes and data communicated to the GPU, and dozens if not hundreds of draw calls depending on enabled features. It's not always the biggest blocker per frame, but it can consistently lock up the main thread for a few milliseconds on a larger map or with a slower CPU.
The hybrid terrain renderer generates a single grid mesh on the CPU and saves it in GPU memory, and only submits new textures (materials, the height map, light maps, or splat maps) when that data changes. This essentially means when terrain needs to render, the CPU only needs to submit a minimal amount of changed state data per frame (e.g. dynamic lights), and can render the entire terrain in one or two draw calls. The GPU does the work of calculating the height of each vertex, and combining the various textures on the fly every frame. Because a modern GPU can do this work in parallel extremely fast, it should almost always be faster than the traditional renderer on newer hardware. On iGPUs with shared memory and older systems though, it's not a sure thing, especially on the version included in that release.
It'll need to be optimized further and certain features used shortcuts that aren't available on all drivers for the earlier pass – the cutouts for empty holes for example may or may not work on your system. Once that's done it'll be added to the options menu somewhere, but if it appears to work fine now, it's fine to use. Running the command sets a client pref, so you don't necessarily need to add the command elsewhere, although opening the editor would currently disable it and require running the command again.
I believe the Miles output selection might've been an issue with an old API it switched to as a fallback, I'll have to check the startup code for it again. It's likely there's a conflict somewhere in the code preventing automatic stream routing, because Miles has always been set up to only select the default output device.
For the audio source issue try deleting
Mssdx7sh.m3dandMssdx7sl.m3dfrom GameData for the Miles stream routing issue – these are Miles 3D provider backends for DirectSound3D 7 software modes with high/low HRTF, and they don't show up in the menu on most systems, but it seems when the game tests them it might be leaving the device attached and preventing the automatic stream routing in Window's DirectSound WASAPI layer from working.That worked. Thanks.
Don't know if this one is just my config as haven't heard others seeing it but occasionally my spawn will load with grenade launcher and ammo count on my spinfusor.
Yeah, that's all scriptable stuff that the patch generally shouldn't touch, so it could be your config. A modded server might send a limited set of commands to change the reticle and what's displayed, but your client scripts decide how to interpret it.
Try to record a demo if you can reproduce it, because if it's the server doing it, it'll do the same thing played back on a clean config or unpatched game.
Looks like that's the same beacon hud crash you had previously; the fix I described (preventing rendering beacons when your control object is not a player) was added to last week's build.
Oh duh, I missed that build. I'm updated now.
Question: is there a script callback for UI Scale changes?
There isn't, since the only time the UI scale is changed by the game, it'll be represented after the
onUpdateRenderTargetscallback runs (following creation of new buffers or resizing of existing buffers), and UI scale changes alone are nominally always done by client scripts callingsetUIScaleAny script that needs to use the UI scale should never read the pref though, if that's your goal: it's unset by default, and not directly linked to the internal value as some variables are (because setUIScale needs to update shader uniforms), so calling
getUIScale()to return the active scale is necessary to avoid undefined behaviour.There's no such call for the aspect lock pref; the way it works needs to bubble down through the game's existing internal GUI heirarchy parent/child resize calls, so you'd always want to use the canvas extents to find the current ratio.
Which build did you last install? This is a debris object that'd already been deleted running the removal code again on receipt of a packet from the server, and changes a few versions back should've prevented this.
It should be the most recent build, but perhaps I should try reinstalling it.
If you've got the game installed in more than one spot, it's possible you might've patched a different install than was run by the shortcut you ran here. The more recent build had a bit more detail added to the crashlog file that would identify the version, and the memory management changes that should generally limit the possibility of this crash were included a few weeks back
Most likely what happened then. I had a couple non-patched version backups leftover from when we were first trying this, now deleted and the patch redirected to my shortcutted install.
There's a hotfix on the first post since I know that terrain issue is probably annoying, and it'll be a little bit longer before I can finish testing some pieces I wanted to add.
This one should include the following:
Amazing work as always Krash, thank you. Wondering how you fixed the deadstops, and if you've considered a dedicated server only install with just the bits needed for Krash optimised dedicated serverage? That would be kewl.
Also, how is it bots don't suffer deadstops, and does eliminating ipx from the stack have any bearing on bots as bots connect via ipx?
The short version is that because the collision test needs to solve both for terrain and for interior brushes where objects may hit an edge (think the acute angled corner of a slanted roof) at speed rather than the flat part of a surface plane, it was generalized to detect the most likely collision case for a given extrusion (basically the bounding box of a rigid body transformed to suit its orientation/momentum that frame). In most cases this worked fine: objects are rarely in a scenario where there's ambiguity between the two, you're almost always on a slope, or relatively static, or heading straight for something that's obviously a collider, however, with terrain...
If the object's bounding box were to interpenetrate the plane being tested, or if the base of the bounding box were coplanar with it, it would essentially switch to testing the front face of the box against the "edge" of the plane, presenting a collision normal directly in opposition to your movement when you hit the edge of a given terrain square; best case traversing it at lower speeds as though it were a step, worst case dead stopping, as though you'd hit a wall... because for all the engine knows, you did.
The updated version always uses surface normals for collisions with terrains and coplanar interior brushes. Terrains don't have any edges we should be colliding with, the entire thing is meant to be representing a single contiguous surface (holes notwithstanding) and can't technically even produce any geometry where you'd expect to collide with an edge. Arguably when hitting the convex "edge" intersection between two planes at the crest of a hill, a smoothed average between the two neighbouring surfaces might be a better option than using the normal of the primary plane being hit as it is now – but that's neither here nor there, it'd probably never be noticed and would be a minor divergence.
Bots generally speaking aren't often in scenarios where they'd hit the conditions necessary to get incorrect normals for a collision (you usually need to be going fast and have a bit of downward momentum on a flat surface), and even on the off chance they did hit it they'd treat it like any other minor obstruction and continue following the nav graph. There was nothing specifically preventing them from hitting deadstops, but they'd move on within a server tick or two, so to a human player it would look like they've just decided to change course.
Bots don't use network connections. They inherit from the GameConnection class because the engine uses objects of that type to control players/vehicles and have nametags and skins and whatnot, but moves/inputs for AIConnection objects are created and consumed directly within the game loop without touching the network stack.
Dedicated servers running this patch only load the code needed for dedicated servers, no client code is loaded (beyond linking Miles, which the Tribes2.exe has always done, but no Miles code is actually run unless you run the commands to start it up). It's not really practical to split it out into different distributions because everything the server needs is needed by the client... I mean, technically it'd be possible to move the client-specific code into another DLL loaded by IFC22.dll, but it'd need a lot of restructuring.