 |
|
Veteran Member
Join Date: Oct 2008
Location: 0x4E6F72776179
|

01-25-2014
, 11:47
Re: The Future of Zombie Plugins
|
#9
|
Here's an early incomplete draft of the core zombie API. Each include file is supposed to represent a single plugin. So far I've covered team management, basic modules and an event system using private forwards. Below I discuss a few new topics regarding this API.
Context Awareness
Some natives are context aware. That means if it's only supposed to do something with the caller's module, you don't have to pass the module ID. It will be looked up by the plugin handle by using the module manager.
The exceptions are when you want to do something with another module, or if there is a performance issue.
Dependencies
We need to support dependencies so that if a module that provides a service is disabled, all modules that depend on that service is notified or disabled too. And the opposite when the service is available again.
Instead of declaring dependencies on modules, I think it's better to depend on specific features. Then you avoid depending on other stuff you don't really need. And if a feature module becomes too big (player classes for instance) it can be split up into several modules without breaking other modules. The features still exists, but just moved to another module - so the dependency is satisfied.
Lookup and Cache
Most of the API is based on lookup functions. Modules need to discover what features that are available on plugin startup. I do this to force developers to use loose coupling, and to make the API dynamic. Essentially, the feature plugins doesn't know anything, they need to discover stuff themself.
One example is virtual teams. Even though there are predefined zombie and human teams, they must be looked up because the actual team ID may change if the team manager is reloaded. At runtime some module could actually create a new virtual team, but I haven't decided exactly how this should behave yet. Although the virtual teams in the zr-dev-base repository is sorted out - which is the basis of the team manager in this zombie API.
After lookup you may want to cache the results, unless the state is dynamic (such as ZM_IsClientZombie). The API should provide events to notify you when something that doesn't change that often (such as new teams), have changed.
I'm interested in what other plugin developers think about this. Are we going in the correct direction? Does the API make sense?
__________________
Last edited by rhelgeby; 01-25-2014 at 12:02.
|
|
|
|