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. :)
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"