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