Compared with the ZR 3.1 branch it's certainly a step in the right direction. I would consider to do further splitting of features into individual plugins so each plugin has a
single responsibility (team management, infection effects, class attributes, ZTele, etc).
Also, if this is a fork of ZR, you need to use another name than Zombie Reloaded to avoid conflicts and confusion (including API natives). This name is already taken.
For inspiration, see my
Zombie API (
implemenation).
I think the major challenge here is not the technology, but time and energy needed to accomplish this. Remember that rewriting all features in ZR is a
huge amount of work. It's easy to forget how complex something really is, even though the features sounds simple. They've been fine tuned and many bugs have been fixed. Rewriting will most likely introduce new bugs and new fine tuning. Greyscale and I have already tried to rewrite ZR using an internal modular structure back in 2010, but progress stalled completely in 2011.
What we have in ZR is called technical debt. In projects with technical debt it's really tempting to just scrap it and start over, but we forget how much work that really is. ZR
is still working, it's just a bit difficult to change stuff.
Instead I propose to gradually improve ZR internally to pay down that debt. First step would probably be to make it compile in SourceMod 1.7. Then each feature can be isolated inside ZR so that they can be extracted to individual plugins later. This is the reason I've been trying to work on a bare module and event system so these plugins can communicate. The transitional language kinda broke this. I need dynamic objects or structs (JSON anyone?). ^^
Here are two articles about this issue:
Linear Mode
