The global variables ended up with the temporary name list created during
load that didn't necessarily contain all variables or even in the right
order. As far as I can tell, this happened since 2005, but nobody noticed
because the list of global variables didn't tend to change between save and
load.
This was partly broken by 427cf61d729a. However, already before that,
the size of the overlay was depending on the ingame size of the object
on whose picture the overlay was being drawn. This didn't make much sense
and now the size of the overlay is equal to the area on which the picture is
drawn in the first place.
and not at the time the drag is started, which is a bit later, after the mouse
has been moved a few pixels in order. This makes it easier to start dragging
when hitting the drag object on an edge.
Instead of having custom code drawing the picture in C4DefGraphics.cpp,
re-use C4Def::Draw().
This changeset changes the coordinate system on which draw transformations
are applied to sprite picture overlays. The transformation is no longer
applied in the frame of the overlay picture but in the frame of the object on
which the overlay is drawn. This was already the case before for mesh
graphics, so this change unifies the interpretation of draw transformations
for sprite and mesh graphics.
The Tools Workshop has been changed accordingly so that object is production
are properly displayed on the sign. This also fixes the pictures of some
objects being off the sign.
These are the ones that the blender 2.6 exporter sets automatically. We don't
support them yet but we want to be able to load the material script
nevertheless. Many of the additional options are set to their default values
anyway.
For functions that are not appended/included, this is done by reusing them.
Functions that are not in the new script version are left with their code
raising and error. Appended/included functions are handled by a reference count.
The parser doesn't need it to find the functions it has to parse anymore.
And the global proplist can be cleared before removing the functions,
instead of having engine functions deregister themselves and script
functions being deregistered when their linked function is removed.
Instead of carefully inserting functions at the start or end of the list,
build the list just before the parser runs, at the same time as filling
the proplist where the functions are looked up.
This way, the overloaded function is simply the one that was previously in
the proplist, is not needed outside of the overloading function, and can thus
be replaced in the proplist.
This requires replacing C4AulScript::Def with C4AulScript::GetPropList() and
C4DefScriptHost::Def, and making C4GameScriptHost::GetPropList return the
scenario proplist prototype.
Definition calls won't be able to change the local variables, of course.
Other proplists will be able to use local variables once they can have
functions.
0 is neither object nor definition, so the ordinary typecheck suffices.
Also change the error message to use '->' instead of object or definition
call.
gettimeofday returns wall clock time, which can jump around, which is bad for
our purposes. clock_gettime(CLOCK_MONOTONIC, ...) does exactly what we need - a
stable measurement of time since an arbitrary point.
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.
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.
The behavior is still not perfect yet since the attachment of the object
to the SolidMask may re-position the object by 1 pixel. I am not sure
this can be solved correctly since there are three coordinates involved
who can be (and, generally, are) different on a sub-pixel level. These
are the object's position itself the position of the solidmask object
and the position of the solidmask (which is constrained to pixel boundaries).
However, the attachment code only knows the object and the solidmask, not
the solidmask object, so it possibly cannot properly account for this.
These font sizes don't work well ingame and are too ugly to show to the player, all remaining font sizes work well enough with resolutions ranging from 800x600 to 1920x1080.
This fixes joining games in local networks where the PID_ConnRe
packet can arrive earlier than the main thread manages to flag
the connection as accepted.
The planet folder is used to develop the game data and should come first.
The pure exepath is only used on windows, where it is the system data path
and should come last.
It will still fail for multi-textured meshes or textures with special
drawing options. This could be fixed eventually using a shader or
applying colormod/MOD2 in an additional texture unit.
With this change, MSVC will build binaries in ${CMAKE_CURRENT_BINARY_DIR}
without adding any more subdirectories. It will also expect its data in a
directory called "planet" immediately below the binary directory.
Since MSVC allows building multiple configurations from the same input file,
the resulting binaries will be suffixed by the configuration type. An exception
is RelWithDebInfo, which will have no suffix; this was chosen over plain Release
to aid in debugging.
Building OpenClonk will work out of the box for in-source builds, but
out-of-source builds will have to create a symlink or a directory junction.
We consider this an acceptable drawback; it was proposed that if you use the
non-default option of an out-of-tree build, you will also know how to create a
link or a junction to, or copy the planet directory.
This changeset also revives looking for game data in the same directory as the
binary, which was part of c3fc1ee1ec8c [Peter Wortmann].
This time, the relocation code checks for a "System.c4g" in either
the executable path or a "data" folder directly below. CMake makes
sure that this points somewhere sensible for normal builds.
TODO:
* Check whether this actually works under Unixes. Can "ln -sf"
delete important stuff? Is there a safe alternative?
* Further unify with the Mac Os solution. Other platforms might
auto-pack for release builds too, for example - and it might
be a good idea to have a proper data subdirectory in Mac bundles
as well.
The various small utilities do not use the engine Log implementation but
one that simply prints to stdout. Instead of duplicating that one, link a
common one into the utilities.
The NoNil variant thus has the shorter name, because most code should
use it. Conversion checks mostly secure code that uses the value and would
crash with a nullpointer. The exception are function parameters, which all
also accept nil and 0 and check for nullpointers in the function itself.
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 deletion only happened when saving as a savegame.
C4Console::SaveScenario also is a much more natural place to do the
copying, since it already contained the part where the new path was copied
to Game.ScenarioFilename.
This replaces the BUILD_TO_PLANET option and makes in-tree Makefile builds
run without further work. Out-of-tree builds need a symlink to planet from
the build directory.
Armin Burgmeier