Save Load timing in Segmented runs


I think we need to discuss saveload timing in segmented runs. Since it appears multiple segmented runs are timing them differently. I’m fairly sure one or two used the idea of 1 saveload = 1 tick, most likely based off an assumption from RTA runs. I believe some runs used a demo based time per save load, which supposedly displayed 0 tick save-flags, though appeared greater when checking the save files themselves. Finally, other runs are using the save files as the definitive method of timing.

With at least 3 different methods of timing voidclips/saveloads all bearing different results, I think it’s important to discuss a way forward to prevent future mistimed void clips and saveloads. Hopefully this discussion would bear a definitive way for void clips and saveloads in segmented runs to be timed, and potentially retimed.


As far as I know most runs use 1 saveload = 1 tick timing, can you provide any examples where it has been timed in a different manner?


AFAIK, the TAS uses 0 tick save flags. As in, they check the save flag of a demo which shows 0 ticks. On the other hand, Half-Life 2-30 has 0 tick segments listed in the timesheet.

From what I understand, 2-30 reads time directly from the save files. Taking the first and last save in a saveload chain and comparing their values, since save files count how much time has passed since the beginning of the map.

With a variety of differing timing methods, I think it’s important to have a standard in order to prevent unnecessary timeloss in future segmented runs.