This is a lightweight, modular management framework designed specifically for the Squirrel language. With zero dependencies and ready to use right out of the box, it comprehensively resolves the issues inherent in traditional single-script architectures—such as disorganization, difficulty in maintenance, lack of hot-updating capabilities, and event conflicts.
Through a unified module manager, the framework facilitates module loading, unloading, dependency management, lifecycle control, automatic global event dispatch, and secure timer isolation—thereby enabling your server scripts to truly achieve an engineered, modular, and extensible architecture.
- Each module resides in a separate file with its own isolated scope, ensuring no mutual interference and resulting in a clean, easily maintainable code structure.
- Supports single-module loading, batch loading, and dependency-aware loading; automatically detects whether a module has already been loaded to prevent redundant execution.
- Features built-in `onScriptLoad` and `onScriptUnload` lifecycle hooks, which execute automatically whenever a module is loaded or unloaded.
- Covers events across all scenarios—including server, player, vehicle, item, command, and chat interactions—with all modules automatically listening for these events, eliminating the need for manual hook binding.
- Includes a dedicated `newTimer` function that binds timers directly to their respective modules; timers are automatically destroyed when a module is unloaded, effectively preventing memory leaks.
- Enables cross-module function calls and variable access via `getModule()`, facilitating seamless functional interoperability between modules.
- Supports the unloading of individual modules as well as a one-click option to clear all modules, allowing for hot-reloading without requiring a server restart.
- Avoids polluting the global scope and leaves native logic unmodified; integration is straightforward and compatible with all standard Squirrel environments.
Here is a simple example.
function onPlayerJoin(player) {
MessagePlayer("[#FFFF00]Hello " + player.Name, player);
}
function onScriptLoad() {
print("onScriptLoad: " + moduleName);
}
function onScriptUnload() {
print("onScriptUnload: " + moduleName);
a.Delete();
}
function hello(value) {
print("hello " + value);
}
a <- newTimer("hello", 1000, 0);
Place the script file into the "module" folder, then load the filename to add the script's functionality to the server.
ModuleManager.load("testModule");
This looks really good, and would have helped a lot the younger me.
Beginners should try to get used to this, as will make everything more clear in their scripts, and easier to debug. (especially when about leaks)
Great job!PS:
There are some things you might want to re-check :D
1. The filePath in ModuleManager is looking for directory "modules", while in your .zip you have "module" directory
2. The newTimer function should use funcName instead of this.funcName
3. onPlayerActionChange parameters are wrong
4. In debug.nut you are missing .len() in cmd "modules" for(), and the player argument in MessagePlayer
PS2:
Ah, I thought it allows using same event in multiple modules
EDIT:Seems like there is a bigger problem with your newTimer - passing vargv to NewTimer.
I remember somebody created one which accepts all types of data; you should check that out.
The very sample you provided isn't working due to that reason..
EDIT2: Ah, ofc was the lord
@. S.L.C. Extended Timers (https://forum.vc-mp.org/?topic=1487.0)
Hey there! Thank you so so much for your detailed feedback and kind words, You're 100% right about all the issues you spotted—total my bad on the upload mix-ups and code oversights! Also, thanks a lot for noticing the critical timer issue and mentioning S.L.C. Extended Timers. I will rebuild the timer system to support all argument types properly, so examples work correctly without errors.
Thanks again for helping me improve this framework, your feedback is really helpful. I'll upload the fixed and improved version soon.
This modular feature has been fully tested and runs flawlessly on a clean server. I have added an automated villa door—activated by pressing the 'M' key—as well as a test module for automatic health regeneration. Furthermore, the module can be modified using commands found within the debug module.
Within the module, you only need to focus on your new features. Please note that in `testModule`, timers must be created and destroyed using `newTimer` and `removeTimer`, respectively; furthermore, when using `vcmp` functions within `onScriptLoad`, you must employ weak references.
What is the next step?
function onScriptLoad() {
gate <- ::CreateObject(310, 1, -276.618, -495.992, 10.2778, 255);
gateStatus <- true;
key_M <- ::BindKey(true, 0x4D, 0, 0);
}
The `onScriptLoad` function within the module resides in a separate context table; therefore, to access methods located outside this table, you must use the double-colon weak reference syntax. This problem needs to be solved.
Additionally, the timer currently only supports creation and deletion; pause and resume methods still need to be added.
class WepPickup extends PickupClass {
wepID = null;
ammo = null;
constructor(model, pos, wepID, ammo) {
base.constructor(model, pos);
this.wepID = wepID;
this.ammo = ammo;
}
function onPickupPickedUp(player) {
player.GiveWeapon(wepID, ammo);
}
}
You can create custom classes that inherit from the `PickupClass` and override the `onPickupPickedUp` function to implement your own pickup logic. The `onPickupPickedUp` function executes automatically once a player picks up the item; simply creating a `WepPickup` instance within the `onScriptLoad` event is sufficient to implement a weapon pickup.
The Module Manager automatically dispatches the `onPickupPickedUp` event; by inheriting from `PickupClass`, the `onPickupPickedUp` method can be automatically executed within `WepClass`. That, in essence, is the underlying principle.