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.
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?