Netdemos Record Maps in Odd Increments
Not odd as in funny, odd as in odd numbers. The maps are in 1,3,5,7,9,11,13,15,17 in the demo provided. The even numbers in the demo appear to do nothing. Perhaps it has to do with intermission? Or in duel2020's case, lack-there-of?
*** Bug 1298 has been marked as a duplicate of this bug. ***
I've got some data on the netdemo issues:
1. netdemo rewinding to prev map is broken in 0.8.0 but works in 0.7.0
2. I don't seem to be able to run most versions between 0.7.0 and 0.8.0 to test exactly where it breaks
3. the netdemostats command shows that duplicate map entries are being added. The first map in the demo will be listed as map 1 in the demo UI, the second map will be listed as map 3, and the third map will be listed as map 5. When you try to rewind to the previous map, demo map index 3 does actually skip to demo map index 2 and then immediately goes to map index 3.
Total time: 100 seconds
Current position: 1 seconds (1%)
Number of maps: 7
> 01 Starting time: 0 seconds
> 02 Starting time: 21 seconds
> 03 Starting time: 21 seconds
> 04 Starting time: 54 seconds
> 05 Starting time: 54 seconds
> 06 Starting time: 82 seconds
> 07 Starting time: 82 seconds
This is a short demo I made.
- map01 is 01
- map02 is 02 and 03
- map03 is 04 and 05
- map04 is 06 and 07
I observed that NetDemo::writeMapChange() was being called twice for all maps after the first map. This was causing each subsequent map to have duplicate entries in the netdemo map table.
The CL_FinishedFullUpdate() method was being called every time a map changed as well as CL_LoadMap(). Both methods ultimately call NetDemo::writeMapChange(). Between 0.7.0 and 0.8.0, the server behavior changed to send svc_fullupdatedone upon every map change. This behavior likely changed in this commit: https://github.com/odamex/odamex/commit/5f8765095a8d8f054d1e18780f9b073b227e6577#diff-d2f054fbe4f6ba4dd17e8a7deaf2c091