C4PlayerInfo stores the PIF_HasRes flag for savegames and network synch. The
resource system isn't used in replays however, so the flag is wrong there. Clear
it when loading a replay, so a later assertion in the cleanup code doesn't fail.
So actually be29346165d6 turned out to be an incorrect fix. The actual
problem is much more subtle: the ordering of objects within the same
plane by their ID could cause the sector list order to not match the
main list order anymore. This has been fixed by re-arranging the code in
question.
I hope this really fixes#711.
The CRC was basically only used to decide which files to include in update
groups, but calculated for every group and then stored in the file on disc.
And for some unknown reason, updates themself didn't produce the right
numbers in the file.
This means that c4groups with this change cannot reproduce groups written
by older c4groups and vice versa, but this isn't necessary for updates, and
reading is compatible both ways.
Except for the ways that C4Update fails to remove the CRCs.
This speeds up loading of packed files significantly. It's not optimal,
though, because the order in which textures are loaded by the engine
is not known by c4group (it depends on their occurence in the Scene.material
file). This could be fixed by specifying custom packing orders for every
object we have. But then again maybe switching to a different format which
allows for random access might be more worth it.
Updates work only when the game data is at the same location as the binary.
If this is not the case then the game was probably installed differently,
for example via the distribution or with make install. In this case we
cannot do automatic updates but we also want to use a different system path.
This fixes the linux development snapshots and release tarballs. They were
broken in the sense that they didn't find their game data.
I hate StdStrBuf. It's just close enough to any sane string class that you think
it does reasonable things, then when you don't look it will turn around and stab
you in the back with a rusty fork.
The usage of timsort instead of std::sort at this point is twofold. First,
it's faster in our case where the array is already sorted in many cases
(remember this is called at least once a frame). And it's not just a bit
faster either but a lot. I have measured a factor of 7 on my system.
Second, in our Windows autobuilds there is a crash within std::sort which is
very hard to debug because it's hardly reproducible with anything other than
the autobuilds (I tried hard). If the crash goes away with timsort then
great, if not then maybe it's easier to debug since the code is in our tree.
Tobias Zwick