Refactor|Plugins: Fixed hidden assumption in plugin ID assignment
The mechanism for tracking the plugin ID for the currently executing plugin hooks was a massive kludge that relied on the order in which Plug_AddHooks() had been called. Now the plugin IDs are tracked in a sensible manner: an ID is assigned to each plugin upon loading, after which the engine is responsible for letting everyone know which plugin execution has been passed to, if any.
In practice, whenever Plug_AddHook() is called from a plugin, the engine must make sure that DD_SetActivePluginId() has previously been called. DD_SetActivePluginId() should also be called whenever control is passed to the functions exported from the game (gx).
Plugins can now be loaded in any order.
Todo: Ditto for Windows (use the same code).
Todo for later: Make a nice mechanism for calling a function in gx while automatically setting the active plugin ID.
Added by skyjake about 12 years ago
Added by
Refactor|Plugins: Fixed hidden assumption in plugin ID assignment
The mechanism for tracking the plugin ID for the currently executing
plugin hooks was a massive kludge that relied on the order in which
Plug_AddHooks() had been called. Now the plugin IDs are tracked in a
sensible manner: an ID is assigned to each plugin upon loading, after
which the engine is responsible for letting everyone know which plugin
execution has been passed to, if any.
In practice, whenever Plug_AddHook() is called from a plugin, the
engine must make sure that DD_SetActivePluginId() has previously been
called. DD_SetActivePluginId() should also be called whenever control
is passed to the functions exported from the game (gx).
Plugins can now be loaded in any order.
Todo: Ditto for Windows (use the same code).
Todo for later: Make a nice mechanism for calling a function in gx
while automatically setting the active plugin ID.