Linking to any library with ".framework" in its path on OS X causes
that directory to be included in the include path (with -F), which
causes all of the DFHack core to be rebuilt unnecessarily when
changing DF folders.
Without removing postings correctly, it was possible to end up with
multiple workers assigned to a job that workflow had suspended
multiple times, which caused crashes if more than one worker was
assigned to the same job by DF.
This adds an additional command, fix-job-postings, that runs
automatically when loading a world and fixes:
- Multiple job postings that point to the same job
- Job postings that point to a job where posting_index == -1
(i.e. jobs that should have no posting assigned)
Fixes#741
This was previously done right before SC_VIEWSCREEN_CHANGED events
were handled, meaning that code handling earlier events that used
top_viewscreen (rather than getCurViewscreen()) could refer to an
invalid viewscreen, i.e. in the tick after it was deleted.
Fixes#747
* Several fatal errors that occurred during core initialization didn't
stop initialization or set 'errorstate' properly, which caused
update hooks and other code to crash later. This has been fixed and
should address crashes like the one mentioned in #470.
* Errors when loading dfhack.lua now cause Lua::Open() to fail, which
triggers a fatal error in Core::Init()
* Failure to initialize the console no longer results in a call to
fatal() (since it didn't actually stop initialization previously)
This makes it possible for some plugins to detect the game state more
reliably - for example, prospector would previously fail when
embarking if the viewscreen_choose_start_sitest instance had any
children.
cur_savegame.save_dir can be populated when the save directory does
not yet exist after world generation (since the game can be aborted
at that stage without saving).
* GCC does not allow std::string instances or enums without a base
type to be passed as varargs
* Fixed path concatenation issue causing dfhack.init to not be loaded
* load/unload/reload are no longer restricted to plugins that exist
on startup
* Names passed to DFHACK_PLUGIN must match the plugin's filename
(remotefortressreader vs RemoteFortressReader, counters vs probe)
* "plug" output lists all plugins and state/command information
* Deleted plugins can be reloaded again if they are replaced
* load/unload/reload don't fail silently with broken plugins
* Built-in commands are recognized internally (e.g. "help help"
does not display "help is not a recognized command"), although help
for them is not yet implemented
* New command: "type" (bash-like) - shows where/how a command is
implemented
* "plug" can accept multiple plugin names
* "ls" displays more information about unloaded/unrecognized plugins
* "load all" changed to "load -all" (or "load --all", "load -a", ...)
Repos need to include a CMakeLists.txt file with calls to the
DFHACK_SCRIPTS macro, which functions similarly to DFHACK_PLUGIN.
The `open-legends` script from lethosor/dfhack-scripts is included
as an example.
This partially fixesDFHack/stonesense#32, in the sense that input
to Stonesense is no longer received by DF, but does not cause
Stonesense to receive input either.
git is run every time 'make' is run, but the generated include file
is only updated when necessary. Plugins will be loaded successfully
if their DFHack version matches core's (assuming OpenLibrary()
succeeds), but will produce a warning if their git commit doesn't
match core's.
lethosor
DoctorVanGogh
Lethosor
expwnent