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.
This allows completely avoiding the call overhead if there
are none. The downside is that the event object now has to
be a userdata with lots of metamethods.
- This context requires core suspend lock and asserts it in a few places.
- Special 'event' objects are introduced. They can be invoked as
functions, in which case they iterate all their fields and call
them as functions. Errors are printed and consumed.
- When a plugin is opened by the core context, events registered in
a special array are linked to it. The system is organized so as to
avoid even trying to pass the event to lua if the module isn't loaded.
- To ensure reload safety functions have to be wrapped. Every call
checks the loaded state and locks a mutex in Plugin. If the plugin
is unloaded, calling its functions throws a lua error. Therefore,
plugins may not create closures or export yieldable functions.
- The set of function argument and return types supported by
LuaWrapper is severely limited when compared to being compiled
inside the main library.
Currently supported types: numbers, bool, std::string, df::foo,
df::foo*, std::vector<bool>, std::vector<df::foo*>.
- To facilitate postponing initialization until after all plugins
have been loaded, the core sends a SC_CORE_INITIALIZED event.
- As an example, the burrows plugin now exports its functions.
- Associate a default output stream with the whole connection.
If not explicitly specified in the constructor, uses stdout.
- Add methods that use this default stream to RemoteFunction.
- Add easily usable wrappers for CoreSuspend and CoreResume.
This is an incompatible change to the plugin ABI.
The Console is not thread-safe unless used indirectly
via color_ostream_proxy, so everything should use their
per-thread stream.
Allow defining commands with guard conditions, and binding
one or more commands to alphabetic and function keys. When
the relevant key is pressed, the first listed command with
successfully evaluated guard is chosen.
For consistency, the guard is also checked when the command
is invoked from the console; this requires suspending the
core inside PluginManager, before invoking plugin code.