The demo file is the most important thing for diagnosing demos or rendering issues, because they provide pretty much everything to try to reproduce the scene on a clean config. Here though it looks like the game skipped you over the lightmap baking phase and the LM manager only has the pre-baked interior LMs to work with. The demos you have are probably affected by the issue causing too many input packets to be recorded and causing an imbalance on playback. It's possible you may be able to get it to play by limiting the framerate or forcing vsync, but no guarantees there. Players not appearing where expected would depend on your interpolation settings; there's no data loss in the recordings produced in those versions, they've essentially just recorde too much data in one direction and expect more in the other.
I wouldn't worry about it too much, a bunch of demo fixes from a few weeks back are included for the next build and should result in these playing back normally.
Needed? Not technically, but they drastically reduce the time it takes to run scripts from file, particularly for a server with hundreds of scripts to run at startup. Without DSOs, everything has to be compiled every time you start.
With a faster script compiler, or a big overhaul to the script engine in general to improve its performance, maybe it'd make sense to phase them out, but as it stands having that cache saves the game having to lock up the main thread to repeat work, and that's generally a good thing.
Just played back: they're essentially recordings of your inputs and the packets received from the server, so playback is basically simulating a server connection. It shares so much with a standard connection that it'll wait to receive a response back from the server for a specific tagged packet, and that leads to the issue here when there's too many of one type, and things like the "ping" aren't going to be calculated correctly... which can result in latency ticks shooting the players off who knows where if they're not doing normal interpolation updates.
It means demos are pretty good for roughly observing what each interpolation setting does to enemy player movement, but, obviously not for these demos at the moment.
@fnatic i would try, a fresh install and no patch and play first, and see if all is working correctly, then patch and play and see and say. try before the all in one chocotaco pack. if the error returns after patching, or whenever, can deduce by the recreate steps. my guess is data corruption file.
Krash, I wonder if you can fix this problem with some of your future preview patch version. I recently found out that when I have very bad Internet connection troubles in a match, what that means is that the next match starts with my game being frozen. By that I mean that no key press does anything in-game. Mouse doesn't respond - moving nor clicking. Ctrl + Alt + Del works, though, as do, I believe, Alt-Tabbing out of the game. I can only see and hear things happening around me. Can't move. When that state happens, I can wait for my character to be killed. Then after a minute, I get put into observer mode. In there, left- and right-clicking my mouse works: I can cycle through game characters. Pressing spacebar works, too, to observe and unobserve. I can get back into the field (''the fray'') by left-clicking my mouse, but I'm still just frozen. I've had this problem for years. I've read that some others, too, have encountered it. Recently, I had very bad connection troubles and I ran into that frozen state about five or six times in a row. I don't know if there's any error log that I can post here the next time that happens. The game doesn't really crash; just everything becomes unresponsive. I guess I can start recording demos, in case that helps. :)
I'd need more specifics on what exactly you're experiencing, ideally with demos and video recording if you can reproduce it, and whether you're using third-party client scripts. For example, you'll need to clarify whether everything else around you seems normal, whether you can see a player walk up to you, whether you can see your own player get pushed around by a vehicle or an explosion, whether you can open the CC, whether you can watch players through the CC, whether you can use voice commands (and specifically whether animations like waving play on your player), whether any keys appear to take actions (switching to third-person, opening the inventory hud, etc), whether the sky is moving, whether there are any errors in your console.
If the gameplay on the server appears to be progressing normally, it's conceivable that a control set switch could take place out of order... once, maybe, if it's unable to get packets through for a prolonged period. If that were the case it should reset normally when going observer and respawning, though. The server can tell your client it needs to use a particular input set, and whether your control object is allowed to move, but your client is ultimately responsible for following through with those instructions – and that's where scripts could interfere.
If things are not progressing normally, e.g. you see other players frozen in place or jumping back and forth in place (or projectiles appearing without a player nearby), you may have invalid clientside interpolation settings.
I don't use powershell often, but if I'm not mistaken you'd want to use the [System.Diagnostics.ProcessPriorityClass]::High enum rather than 'High' when setting the priority. If you intend this to re-apply the change to the process whenever ispawn restarts it, I suppose you may want to add an outer loop to your script to block and wait for the process to exit and run everything again; as it is it looks like you're just applying your change to the first Tribes2 to start.
Can't really recommend setting the affinity on the whole process unless necessary for your system (like reserving the other cores for something else). The main thread already sets its own affinity at runtime, which was needed to achieve stable performance on some older systems I'd tested, although I meant to make this more configurable. The other threads... don't really benefit, and setting global affinity for the process may have a detremental effect. A very minor one on servers, obviously, but there is some networking overhead and work like client handshakes that's being done in the background.
Thanks for the response, I feel leaving it alone as to affinity is best knowing you've already sorted that. I guess I can just set pri in the ispawn string.
Comments
The demo file is the most important thing for diagnosing demos or rendering issues, because they provide pretty much everything to try to reproduce the scene on a clean config. Here though it looks like the game skipped you over the lightmap baking phase and the LM manager only has the pre-baked interior LMs to work with. The demos you have are probably affected by the issue causing too many input packets to be recorded and causing an imbalance on playback. It's possible you may be able to get it to play by limiting the framerate or forcing vsync, but no guarantees there. Players not appearing where expected would depend on your interpolation settings; there's no data loss in the recordings produced in those versions, they've essentially just recorde too much data in one direction and expect more in the other.
I wouldn't worry about it too much, a bunch of demo fixes from a few weeks back are included for the next build and should result in these playing back normally.
Needed? Not technically, but they drastically reduce the time it takes to run scripts from file, particularly for a server with hundreds of scripts to run at startup. Without DSOs, everything has to be compiled every time you start.
With a faster script compiler, or a big overhaul to the script engine in general to improve its performance, maybe it'd make sense to phase them out, but as it stands having that cache saves the game having to lock up the main thread to repeat work, and that's generally a good thing.
It'd be really useful to know what's unique about your config
Awesome, thank you.
Do interpolation settings affect how demos are recorded? Or just played back?
Just played back: they're essentially recordings of your inputs and the packets received from the server, so playback is basically simulating a server connection. It shares so much with a standard connection that it'll wait to receive a response back from the server for a specific tagged packet, and that leads to the issue here when there's too many of one type, and things like the "ping" aren't going to be calculated correctly... which can result in latency ticks shooting the players off who knows where if they're not doing normal interpolation updates.
It means demos are pretty good for roughly observing what each interpolation setting does to enemy player movement, but, obviously not for these demos at the moment.
@fnatic i would try, a fresh install and no patch and play first, and see if all is working correctly, then patch and play and see and say. try before the all in one chocotaco pack. if the error returns after patching, or whenever, can deduce by the recreate steps. my guess is data corruption file.
Krash, I wonder if you can fix this problem with some of your future preview patch version. I recently found out that when I have very bad Internet connection troubles in a match, what that means is that the next match starts with my game being frozen. By that I mean that no key press does anything in-game. Mouse doesn't respond - moving nor clicking. Ctrl + Alt + Del works, though, as do, I believe, Alt-Tabbing out of the game. I can only see and hear things happening around me. Can't move. When that state happens, I can wait for my character to be killed. Then after a minute, I get put into observer mode. In there, left- and right-clicking my mouse works: I can cycle through game characters. Pressing spacebar works, too, to observe and unobserve. I can get back into the field (''the fray'') by left-clicking my mouse, but I'm still just frozen. I've had this problem for years. I've read that some others, too, have encountered it. Recently, I had very bad connection troubles and I ran into that frozen state about five or six times in a row. I don't know if there's any error log that I can post here the next time that happens. The game doesn't really crash; just everything becomes unresponsive. I guess I can start recording demos, in case that helps. :)
Krash any inuput on why this seems to not be prioritising or affinitising as expected?
"@echo off
REM #######################################################
REM Tribes2 Classic dedicated server loader with adaptive PowerShell tuning
REM This batch file MUST be run from the GameData directory
REM #######################################################
REM --- Clean out old compiled script files ---
del .C:\Servers\T2\GameData\Classic\scripts\*.dso 1> nul 2>&1
del .C:\Servers\T2\GameData\Classic\scripts\autoexec\*.dso 1> nul 2>&1
del .C:\Servers\T2\GameData\Classic\scripts\packs\*.dso 1> nul 2>&1
del .C:\Servers\T2\GameData\Classic\scripts\turrets\*.dso 1> nul 2>&1
del .C:\Servers\T2\GameData\Classic\scripts\vehicles\*.dso 1> nul 2>&1
del .C:\Servers\T2\GameData\Classic\scripts\weapons\*.dso 1> nul 2>&1
REM --- Launch InfiniteSpawn with Tribes2 ---
start C:\Servers\T2\GameData\ispawn.exe 28000 Tribes2.exe -dedicated -mod Classic
REM --- Call PowerShell to adjust Tribes2 process after uptime threshold ---
powershell -NoProfile -ExecutionPolicy Bypass -Command ^
"$threshold = 60; ^
do { Start-Sleep -Seconds 5; $p = Get-Process Tribes2 -ErrorAction SilentlyContinue } ^
while (-not $p -or ((Get-Date) - $p.StartTime).TotalSeconds -lt $threshold); ^
$p.PriorityClass = 'High'; $p.ProcessorAffinity = 1; ^
Write-Host ('[{0}] Tribes2 priority=High, affinity=CPU0 applied' -f (Get-Date))"
exit"
I'd need more specifics on what exactly you're experiencing, ideally with demos and video recording if you can reproduce it, and whether you're using third-party client scripts. For example, you'll need to clarify whether everything else around you seems normal, whether you can see a player walk up to you, whether you can see your own player get pushed around by a vehicle or an explosion, whether you can open the CC, whether you can watch players through the CC, whether you can use voice commands (and specifically whether animations like waving play on your player), whether any keys appear to take actions (switching to third-person, opening the inventory hud, etc), whether the sky is moving, whether there are any errors in your console.
If the gameplay on the server appears to be progressing normally, it's conceivable that a control set switch could take place out of order... once, maybe, if it's unable to get packets through for a prolonged period. If that were the case it should reset normally when going observer and respawning, though. The server can tell your client it needs to use a particular input set, and whether your control object is allowed to move, but your client is ultimately responsible for following through with those instructions – and that's where scripts could interfere.
If things are not progressing normally, e.g. you see other players frozen in place or jumping back and forth in place (or projectiles appearing without a player nearby), you may have invalid clientside interpolation settings.
I don't use powershell often, but if I'm not mistaken you'd want to use the
[System.Diagnostics.ProcessPriorityClass]::Highenum rather than 'High' when setting the priority. If you intend this to re-apply the change to the process whenever ispawn restarts it, I suppose you may want to add an outer loop to your script to block and wait for the process to exit and run everything again; as it is it looks like you're just applying your change to the first Tribes2 to start.Can't really recommend setting the affinity on the whole process unless necessary for your system (like reserving the other cores for something else). The main thread already sets its own affinity at runtime, which was needed to achieve stable performance on some older systems I'd tested, although I meant to make this more configurable. The other threads... don't really benefit, and setting global affinity for the process may have a detremental effect. A very minor one on servers, obviously, but there is some networking overhead and work like client handshakes that's being done in the background.
Thanks for the response, I feel leaving it alone as to affinity is best knowing you've already sorted that. I guess I can just set pri in the ispawn string.