After updating the extra init file in my pack, I realised that many of
the changes could be merged into the standard init.
This enables a few more UI improvements, adds neglected keybindings, and
removes the roses-init and binpatches sections (third-party only and
obsolete respectively).
Now, a pointer to NULL is cast to the type in question, avoiding the need to
call new() or delete() with potentially-misaligned types. Also,
virtual_identity::find has been tweaked to prevent it from crashing on NULL
vtable pointers.
This was suggested by Angavrilov.
Handle cloth crafts correctly; handle pit jobs correctly; handle
bookcase construction correctly; deal with new break behavior better;
change assignment of clean labor; tweak hauling assignments slightly to
avoid overallocation; assign pull lever to everyone and clean to all
nonbusy dwarfs
Deprecated in Lua 5.3, but still contains some useful things, like extract()
Also helps maintain backward-compatibility with scripts that target older DF
versions (e.g. Mifki's dfremote project)
In some situations (e.g. 32-bit Linux), "intptr_t" is defined as "int", which is
equivalent to "int32_t", leading to issues with duplicate definitions. In other
situations with GCC, "intptr_t" is "long", which isn't covered by any intNN_t
types. Also, definitions for "long" already had to be added on Windows, because
no fixed-width types in MSVC are equivalent to "long".
Switching to non-fixed-width types should hopefully cover all of these
situations. If this doesn't cover any integer types that we need, it will
be caught quickly, e.g. by references to integer_traits<T> in LuaWrapper.cpp.
- Add uint64_t
- Add special case for long on different platforms
- Require OS and architecture to be specified
NOTE: integer alignment on x64 is probably still incorrect
- Passing the architecture is needed to determine sizeof(long)
- Passing the OS prevents potential issues when cross-compiling between Windows
and non-Windows (although this is unlikely)
DFHACK_BUILD_ARCH is no longer cached on Windows since it is not possible
to build Win32 targets with the Win64 generator or vice versa. No change
for GCC builds.
PeridexisErrant
lethosor
Kelly Kinkade
Lethosor
Carter Bray