Even when standing directly over a plant, you would sometimes not harvest it because its midpoint would be out of the Clonk's rectangle. Now the Clonk only has to touch plants.
Instead of Y - Hgt > LandscapeHeight (or, equivalently, Y > LandscapeHeight + Hgt), it was checked for Y + Hgt > LandscapeHeight, which would remove objects too early.
Rolling works via SetXDir anyway, so the ComDir change is not necessary. It would just lead to issues because the ComDir would never be reset and the Clonk would keep on walking until the next key press.
This actually led to an infinite recursion in Mine Rescue when clicking on the goal. The goal menu would link to the goal itself which would link to the elevator -> case -> elevator -> case...
Now only layout stuff is in the layout proplists.
I noticed that with multiple goals one always gets a background. But I guess that had already been the case beforehand? Anyway, that's another issue.
When JCaesar dropped all Boost fallbacks, this also meant that we
wouldn't be able to build on Ubuntu 12.04 LTS anymore (because that
comes with an ancient libstdc++ which has a broken <regex>). Until we
update the Travis config to use their newer container-based build
infrastructure, there's no point having them build everything when we
already know it'll fail.
Nobody uses pkg-config on Windows, and we already have a perfectly
viable solution for finding libraries - it's called CMake. We're still
defering to pkg-config when it exists because who knows what arcane
cflags might be required on some systems.
mape uses several headers from OpenClonk that are marked for
pre-compilation. MSVC does not support using headers flagged as such
without also linking to the object file that gets generated from the
compilation step.
The minimum GTK version is now GTK+ 3.4, which is available since 2012.
It's part of Ubuntu LTS 12.04, and so should be available on any halfway
modern linux distribution.
This should allow getting rid of using deprecated GTK+ API much easier.
More a work-around than a fix. I didn't really dive into WHY the problem happened, but you'd always throw away a different item and not the CH one. Probably because either DropInventoryItem or GetItemPos does something weird, but meh..
It's somewhat experimental by now. The old behaviour can be obtained by
setting normalMapStrengthMax to the same value as normalMapStrengthMin.
I hope this helps a bit with #1418.
Armin Burgmeier