(Requires jasshelper 0.9.Z.something, better just get something like 0.A.2.6 or later)

Timer recycling and attaching.
--
It began as Anitarf complaining about CSSafety's name considering it really has not much to do with the caster system anymore.

Ended up merging CSSafety and CSData, considerations:

Group recycling is good for legacy, but for actual usage using a single global group is better.

Attaching private values is great for timers and triggers. But we don't need dynamic triggers / the mantra is that dynamic triggers are evil. So we just need quick private attaching for timers? Well, maybe we could use private attaching for ... units or items but they already got user data, there are also dialog buttons but speed is not important there.

This system conflicts with CSSafety. If you got CSSafety in your map, you must delete it (And possibly include the compatibility fake CSSafety included in this post) before using TimerUtils. Within time, we'll wipe the old CSSafety, for example I'll use TimerUtils and the currently-fake CSSafety in the next caster system version.

This includes double-free protection, many implementations of New/ReleaseTimer don't take this into account, when a timer double-free happens in your map it becomes very hard to find, believe me, I know.

Two versions were provided so you can pick the one that suits your taste the better. But for example, if you make a spell with TimerUtils, it won't matter which flavor a person has in her map, it will work.

Now three flavors are in the same script and you can tweak the constants to use the one you want!

The flavors:

"Blue" TimerUtils DEFAULT
(When USE_HASH_TABLE is set to true)

Uses a hashtable object from wc3 patch 1.24b+ or later. These things are very fast though not as fast as just an array lookup. So it is the 'slowest'...

... But it is the safest! There are no limits to the number of timers you can have.

"Orange" TimerUtils (aka "old red")
(When USE_HASH_TABLE is set to false, and USE_FLEXIBLE_OFFSET is set to true)

Preloads QUANTITY timers at map init, then can use a subtraction based on the handle id of the first timer. The limit is something from QUANTITY to 8190 depending on the map.

"Red" TimerUtils
(When USE_HASH_TABLE is set to false, and USE_FLEXIBLE_OFFSET is set to false)

Tries to preload QUANTITY timers at map init, then can subtract a FIXED OFFSET. The limit is therefore smaller than orange TimerUtils. There is also a possibility it won't be able to preload enough timers, so you will have to MANUALLY TWEAK OFFSET until there is a correct value for your map.

Group recycling is good for legacy, but for actual usage using a single global group is better.

I wonder how one would go about coding for a system that makes so you only use one global group. I guess you would have to use a system like PUI(that uses custom unit data) and attach numbers to the members of each group but i'm unsure. That's the only relatively good way to distinguish members of different groups in one unit group i think.

Glad the thing finally dropped "CS" from it as Anitarf was right it was definitely misleading.

You don't normally need groups for more than Enums, in which case you just use a global group and a tricky boolexpr. The only times you actually need a group are for say, saving all the units affected by a spell or something similar.

__________________

By reading this signature, you agree that I cannot be held accountable for anything that I might say or do.

s this system better than TT? Meh, since i'm having issues with TT i'll give this a shot.

Why must everything be better? I am just trying to get something more consistent than CSSafety here.

Quote:

EDIT: What do you mean by lower values = fast but unsafe, should "safety" be of my concern?

If you use 8000, it may not work with timers that have high ids, but it will be very fast, you'll need to ensure that no timer would get a handle id higher than 8191+0x100000, I would suggest you to keep the default values if you have doubts.

Quote:

I wonder how one would go about coding for a system that makes so you only use one global group. I guess you would have to use a system like PUI(that uses custom unit data) and attach numbers to the members of each group but i'm unsure. That's the only relatively good way to distinguish members of different groups in one unit group i think.

I really, really think that dynamic group usage is not necessary. That's what I meant by one unit group, in fact, you may have 3 or 6 unit groups, the other day I made a whole unit attachment system using 10 groups, what we want to avoid is the need for DestroyGroup, besides of it being possible, I think it makes code simpler, make sure to post counter example cases.

QFT, yea... They all seem to all have "personal benefits" for each of them too if it wasn't enough to annoy the heck out of you trying to choose which ones to use. I think using like TT and HSAS works good.
(Since i think HSAS is faster than ABC, but not faster than TT. Also TT only uses 1 timer.
Another reason why is i don't like going back to gamecache really either.)

There should be just one general system that allows you to implement different methods with timers using macro's or something like

I don't see the need for anything more elaborate than cache storing of structs or direct array accessing, really. Anything else that has to do with attaching to timers is a load of bollocks as far as I'm concerned.

I don't see the need for anything more elaborate than cache storing of structs or direct array accessing, really. Anything else that has to do with attaching to timers is a load of bollocks as far as I'm concerned.

The problem with all these timer systems is that htey all have their own specific use in certain situations.

One timer system is much more suited in one map/script then another, and thats why we have like 10 of these systems floating around

To me it makes no difference, i make my own timer systems. If there was a very good tutorial fully explaining how attaching/hashing/pointers/handles works then I wouldn't be complaining but what inevitibly ends up happening is people end up using the completely wrong system