Raised This Month: $ Target: $400
 0% 

The Future of Zombie Plugins


  
 
 
Thread Tools Display Modes
Prev Previous Post   Next Post Next
rhelgeby
Veteran Member
Join Date: Oct 2008
Location: 0x4E6F72776179
Old 01-25-2014 , 11:47   Re: The Future of Zombie Plugins
Reply With Quote #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?
Attached Files
File Type: zip zombie-api-2014-01-25.zip (8.2 KB, 285 views)
__________________
Richard Helgeby

Zombie:Reloaded | PawnUnit | Object Library
(Please don't send private messages for support, they will be ignored. Use the forum.)

Last edited by rhelgeby; 01-25-2014 at 12:02.
rhelgeby is offline
Send a message via MSN to rhelgeby
 



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 12:40.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode