Magtheridon96 and I wrote this revised script, it is a co-authorship of sorts. I suppose I could write "by Vexorian, Magtheridon96 and Bribe" but I'd really prefer if you just updated TimerUtils.

The reason it doesn't work in module initializers is because when you use hashtable a new timer isn't created because tN is equal to 0 (because you initialize in a library Init instead of a module init and TimerUtils bugs in hashtable mode when timers overflow).

If I had my wishes I would really like it if you updated your TimerUtils library. Then we can stop with this unpleasant trend of re-writing systems.

In fact, while we are on this subject it would make the most sense humanly possible if JassHelper were updated so that initializers, whether be module, struct or library, initialized before any library requiring it.

The rest are not needed features, though nice to have, but don't slow anything down except in ReleaseTimer. I made the change in ReleaseTimer so that more than QUANTITY timers could not be recycled, because there are sometimes spikes in the game where lots of timers might be needed but not all would need to be recycled.

I figured out about the thing with onInit when I wasn't looking at the site. Quite honestly, I think the best thing I could do is update jassHelper to remove struct and module onInit altogether, because it is really ridiculous how every library wants to initialize before modules.. But then modules wouldn't work very great, I guess.

I will update TimerUtils to have NewTimerEx and a module onInit. sigh.

I figured out about the thing with onInit when I wasn't looking at the site. Quite honestly, I think the best thing I could do is update jassHelper to remove struct and module onInit altogether, because it is really ridiculous how every library wants to initialize before modules.. But then modules wouldn't work very great, I guess.

That's quite an understatement. Such a change would also break a ton of libraries that are widely used, yet their maintainers are no longer active to make the necessary changes (if those changes are even possible, as you say this would make modules less functional). We'd have a huge surge of new people rewriting old libraries again, as if that isn't enough of a problem already.

I agree about the widespread use of module initializers being ridiculous, though. Most libraries don't need to do it.

Are the edits Vex made to TimerUtils adequate for me to graveyard this, Bribe?

There is still the issue that you and I have addressed where overflow timers in hashtable-mode bug because the "set tT[0] = CreateTimer()" line is only there if hashtable mode is "off".

You can go ahead and ditch this resource as I never wanted it in the first place, what I wanted was a system that can be linked to that works 100%.

On an side note Vex now uses .evaluate() on the init function plus a textmacro instead of a wrapper, which unfortunately makes the code way longer than before while being completely avoidable by doing the approach I have here.