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-12-2014 , 02:42   Re: The Future of Zombie Plugins
Reply With Quote #3

This is almost exactly how the Zombie API is intended to work.

The only difference is that the function callbacks in hooks are not type safe:

PHP Code:
stock bool:AddHookIfExists(bool:bHookManLoaded, &iBitArrayiBitToCheck, const String:sHookName[], Function:fFunc, const String:sPassedHook[]) 
If I pass a function with no parameters into fFunc, while the hook actually expect it to have parameters, it will crash.

This is solved with functags, which also means we'll have to create a hook native for every single type of callback. It's quite similar to adding listeners in Java, where each type of event has it's own method for registering listeners for a particular event. I think this is called the observer pattern.

A native for hooking events may accept a group (enum array) of callbacks specified with functags so that we don't have to create that many natives. But only group callbacks that makes sense, such as OnClientInfect, OnClientHuman or OnRoundStart and OnRoundEnd.

Type safety on event callbacks is absolutely essential. We must catch these errors as early as possible (which is on compile time). Otherwise the API won't be robust enough. Developers will make silly typo mistakes, or forget to update the callback function signature when the hook is changed. Although a hook callback type should not be changed after a release, that would break backwards compatibility.

MVC pattern
Otherwise I think we should go for something based on a MVC pattern so that code is loosely coupled and easier to maintain.

An example for the player class system would be something like below. It is simplified a lot because my idea for the class system is also based on event listeners and plugins for each class attribute (or a group of them).

Model:
The player class. One include file (or API) that provides operations on a single player class such as getters and setters.

Repository:
The class database. Stores all classes in memory and provides an API for inserting, and searching.

Controller/Manager:
Player class logic. API for applying a class on a player, doing stuff on infection, round start and so on.
__________________
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-13-2014 at 10:29.
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