Although the code already uses boost, boost/uuid hides the sha1
implementation in a deeply nested namespace, which is just too bizarre to
use. Also the name of that namespace suggests that it is just an
implementation detail that could go away without notice.
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.
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.
Conflicts:
CMakeLists.txt
src/lib/StdMesh.cpp
We do the same already for ERROR_FILE_NOT_FOUND. This fixes a harmless warning
when running the engine in a release directory where there is no planet/
directory.
Instead just attempt to load the filename given. This function is only
used from two places: C4Game::InitDefs and C4Game::DropFile. In both
cases segments and wildcard matching is neither needed nor desired.
This fixes a problem with loading definitions when the Clonk installation
resides in a directory with paretheses, such as C:\Program Files (x86)\.
This might well fix the problem in http://forum.openclonk.org/topic_show.pl?tid=905.
This leads to an obscure error otherwise where local definitions are skipped
from loading when running the scenario as clonk.exe Tutorial.ocf/Tutorial01.ocs.
The scenario loads fine as such but some definitions are missing and therefore
it doesn't work properly. See also http://forum.openclonk.org/topic_show.pl?tid=905.
This means that if the Clonk digs Earth but has a full inventory at the time
(so we can't generate Earth chunks), digging another material later can never
yield more than one Earth chunk.
This fixes make install, which previously tried to install nonexistant
packed groups from the source directory. Make it use the ones from
the build directory and build them during make all.
Martin Plicht