[rhelgeby]

It seems like that it's an old feature request: https://bugs.alliedmods.net/show_bug.cgi?id=5274

It even has a patch implementing just what I need. Don't know why it hasn't been given priority though, or even accepted.

[benefitOfLaughing]

Originally Posted by rhelgeby It seems like that it's an old feature request: https://bugs.alliedmods.net/show_bug.cgi?id=5274 It even has a patch implementing just what I need. Don't know why it hasn't been given priority though, or even accepted.

For security reason, maybe. It might be have to isolate from other plugin.

[benefitOfLaughing]

I have an idea: Create a extension for Zombie Reloaded. It is too difficult to hold such a modularized design at Plugin-Level without any extension. You need to get access from Sourcemod Extension API.
You can gain some advantages from Extension API. Handle API allows you OnHandleDestroy event, assign a owner(plugin) for handle.
Especially the Handle API can hold such the Memory-Leak problem, or Plugin-Unload (Handle will be destroyed too if the owner is the unloaded-plugin)...
Of-course, you have to hold the platform-differences: Compile Extension for windows, linux, mac.

[rhelgeby]

I'm trying to avoid dependencies on third party extensions, although the entire Zombie API is a good candidate as an extension. It's easier to implement at the plugin level if I have access to forwards I need.

It is already exposed in a patch in the bug I linked to above. I, or someone else just have to implement it and do a pull request (in addition to setting up dev environment for SourceMod, compiling and testing).

This issue is no blocker, it's just something that would be really useful.

[rhelgeby]

Early Implementation of Hot-Plug Support

Here's the result of of an early implementation of hot-plugging the module manager while a test module is loaded.

sm plugins load zr-test-modulemanager
[SM] Loaded plugin zr-test-modulemanager.smx successfully.

sm plugins load zr-modulemanager
L 07/31/2014 - 12:42:41: [zr-modulemanager.smx] Loading module manager.
Initializing module manager API.
L 07/31/2014 - 12:42:41: [zr-modulemanager.smx] Module manager loaded.
L 07/31/2014 - 12:42:41: [zr-test-modulemanager.smx] Module manager available.
L 07/31/2014 - 12:42:41: [zr-modulemanager.smx] Created module "zr_test_modulemanager": f10064
L 07/31/2014 - 12:42:41: [zr-modulemanager.smx] Adding module to index. pluginID=e40059 | module=f10064
L 07/31/2014 - 12:42:41: [zr-test-modulemanager.smx] Registered module: f10064
[SM] Loaded plugin zr-modulemanager.smx successfully.

sm plugins unload zr-modulemanager
L 07/31/2014 - 12:42:52: [zr-test-modulemanager.smx] Module manager removed.
L 07/31/2014 - 12:42:52: [zr-modulemanager.smx] API_DeleteModule: module=f10064 | plugin=e40059
L 07/31/2014 - 12:42:52: [zr-modulemanager.smx] Deleted module: f10064
L 07/31/2014 - 12:42:52: [zr-test-modulemanager.smx] Deleted module.
L 07/31/2014 - 12:42:52: [zr-modulemanager.smx] Module manager unloaded.
[SM] Plugin Zombie:Reloaded Module Manager unloaded successfully.

You see that I first load the test module (zr-test-modulemanager) successfully. It does nothing because it detected that the module manager is not available yet, and wait for it to load.

Then I load the module manager. The test module detects it and register itself as a module.

At the end I remove the module manager while the test module is still loaded. The test module detects that too and unregisters itself in the module manager.

Its using the OnLibraryAdded and OnLibraryRemoved to detect the changes. The goal is that every feature in ZR should detect changes in dependencies and unload or reload themselves seamlessly.

Test module source: https://github.com/rhelgeby/sm-zombi...dulemanager.sp

[rhelgeby]

I thought I should just give a quick update:

After hot-plug support was implemented, development stalled again due to a bug. The bug is an issue with OnLibraryAdded being called to early (not a bug in SourceMod, just a limitation in my implementation). It's called before a library plugin is initialized, and things breaks when the module try to use that uninitialized library.

That's one issue. There's another issue with boilerplate code required in a module to properly wait for all dependencies to be ready. This code may be duplicated between multiple modules, even for the same dependencies. So I decided to make a simple dependency manager.

Dependency Manager

The dependency manager is basically just a wrapper for OnLibraryAdded and OnLibraryRemoved, with some extra features that I need. I try to design this so it will work with these library events in SourceMod.

Modules need two events:

• OnDependenciesReady - Triggered when all its dependencies are ready (not just loaded). In this event, modules should initialize.
• OnDependenciesUnavailable - Triggered when one or more dependencies are no longer available, such as when a library plugin was unloaded. In this event, the module should disable itself and clean up resources.

Using these two events we make it possible to do hot-plugging of modules while reducing the burden of checking dependencies.

Modules use natives in the dependency manager to declare its dependencies, and then simply waits for the ready-event.

The dependency manager will also provide some natives for registering a library, with a name that matches the one sent to RegPluginLibrary. It will keep track of availability of all libraries and notify modules when all their dependencies are met.

To solve my first issue, the manager will provide natives for manually triggering the ready-event, so that modules won't receive OnDependenciesReady until all libraries are loaded and initialized.

The hot-plugging demo in my previous post works because the module manager doesn't need initialization. Once I started working on other modules, hot-plugging was broken. With the new dependency manager it should be back on track.

It's really cool to see the modules dynamically respond to the changes in the environment. The really tricky part is to make the code simple and elegant, but I'm on to something now.

[rhelgeby]

Here's the first version of the Dependency Manager API: https://github.com/rhelgeby/sm-zombi...b9775879fc7b40

You're welcome to add comments on the commit if you want to.

[rhelgeby]

Status Update

My progress on the API and the implementation is on a halt due to issues after the transitional SourcePawn syntax was released.

Objects
I depend on the ability to make dynamic "objects" (that are not enum arrays, but more like a key/value store). My object library handled that, but it's broken on 1.7. I think it's manageable if I just use hash maps for objects with getter and setter functions for predefined keys. It's just that my object library did a lot more with constraints and validation, instead of having to duplicate very similar logic everywhere.

Function References
In addition there's an issue with dynamic function calls (used for events and callbacks). I need to store function references in an array or a hash map, but there's no way to do that anymore. Storing function names as strings works, but the disadvantages are too big: no signature validation, and renaming is error prone (the string won't be checked by the compiler).

So, in short there are two major issues blocking progress on the modular API: ability to make dynamic objects and store function references.

Cleanup in ZR
Instead I've been working on improving the code in ZR 3.1. While experimenting with ZTele I've updated it to the 1.7 syntax and cleaned the code. I'm trying to set a new code style standard to use in ZR. Trusted developers can get direct access to the repository, and others are very welcome to do pull requests.

ZR 3.1 is not that bad if we can decouple internal modules. Modules are somewhat decoupled already. Then they will be prepared to be extracted to individual plugins when it's time. I hope to be able to integrate a game adapter to make it easier to implement multimod support (don't ask when, because I don't know).

There are many good reasons to keep working on ZR 3.1. The code is mature and stable, many bugs have been fixed, lots of features are implemented. Rewriting all this in new plugins is a huge task with high risk of never being released (and introducing new bugs). Greyscale and I failed to do that in 2010-2012. That's two years of work that was never released. Though, we've solved a lot of concepts and problems that will be useful now.

The key to this transition is small steps, smaller than I initially thought. This means that ZR will probably stay as a monolith plugin for a while. It's more important that the code is clean, decoupled and well structured (then it's easier to handle new requests). So, I want to keep good old ZR and work on that.

[8guawong]

i'm not really a coder so just wondering what exactly is broken with the current release?
the knockback seems to be fixed with the movement unlocker for csgo
so whats next?

[rhelgeby]

Nothing is broken in the current release, it's been working fine for years now. It's just that it's hard coded for CS: S. The tricky part is to make it work on multiple games. The unofficial CS: GO version by Jargon is essentially a fork - a separate plugin modified for CS: GO.

I've been working on ideas and concepts for a few years to merge these versions into the same plugin. That's the next goal. While working on that, I'm trying to clean the code a bit.