System ABC - Struct Attachment System

[Faust]

No it didn't. And yours didn't either.
I asked WHY are there 3 "ways", as I haven't really discovered any uses of B and C (they do the same).

 

[trb92]

This is why it has three different ways (A, B, C).

function [...]
local StructName data = StructName.create()
local StructName data2 = StructName.create()
local timer t = CreateTimer()
//Set some of the struct arguments, or whatever else you need to do.

//Now you need both of the structs in the callback function, for whatever reason.
call SetTimerStructA(t, data)
call SetTimerStructB(t, data2) //B is needed to attach a second struct to the same handle
//If you tried to use SetTimerStructA() to attach both structs, data2 would override data and you would only be able to obtain data2 in the callback function
//If you need to attach a third struct to this same handle, you could do so by using SetXXXStructC()
call TimerStart(t, timeout, function Callback)
endfunction

After you attach them with different letters, you can retrieve them using the same letter they were attached with.

This is exactly what Tyrande_ma3x and Smith_S9, and it does answer the question as you asked. If this isn't what you mean, try clarifying your question.

 

[Tyrande_ma3x]

Those are no "ways", the system attaches the structs with the same algorithm. B and C are used if you need 2 or 3 structs attached to one handle. You will discover use of this when you actually need it.

 

[Faust]

This is why it has three different ways (A, B, C).

function [...]
local StructName data = StructName.create()
local StructName data2 = StructName.create()
local timer t = CreateTimer()
//Set some of the struct arguments, or whatever else you need to do.

//Now you need both of the structs in the callback function, for whatever reason.
call SetTimerStructA(t, data)
call SetTimerStructB(t, data2) //B is needed to attach a second struct to the same handle
//If you tried to use SetTimerStructA() to attach both structs, data2 would override data and you would only be able to obtain data2 in the callback function
//If you need to attach a third struct to this same handle, you could do so by using SetXXXStructC()
call TimerStart(t, timeout, function Callback)
endfunction

After you attach them with different letters, you can retrieve them using the same letter they were attached with.

This is exactly what Tyrande_ma3x and Smith_S9, and it does answer the question as you asked. If this isn't what you mean, try clarifying your question.

Now I understand, thank you for the clarification.

 

[Cohadar]

I don't understand why some people claim ABC is not working for 1.24,
it works for both 1.23b and 1.24.

Maybe you need to get latest version of NewGen

 

[Jesus4Lyf]

Zomg, he's right.
My bad. I shouldn't believe what people say.

Apologies.

 

[Zwiebelchen]

Is ABC still worth using? I mean ... with all those new blizzard hashtable functions, aren't attachment systems obsolete?

 

[Azlier]

>aren't attachment systems obsolete?

For the ones that do hashing, pretty much. Hashtable's hashing (at least with a single hash) appears to be faster than Jass modulo hash.

H2I() - 0x100000 is still faster, I believe. It's unstable, though.

I'm going to stay with TriggerExecCount. Faster (and more stable) than both H2I() - 0x100000 and hashtables.

 

[Jesus4Lyf]

Is ABC still worth using? I mean ... with all those new blizzard hashtable functions

Good question, one that I ask myself.
Of course, some attaching systems didn't use hashing, like PUI, AIDS, T32, KT2, Rectwraps and Trackable2. These are the non-H2I attaching systems, which may be faster than hashtables. But H2I attaching systems are probably obselete, except for those which use H2I-0x100000 with precaching objects and recycling (TU Red).

 

[Zwiebelchen]

Basicly, after some days of intensive rewriting of my map's existing code (Gaias Retaliation ORPG) and trying to create a more user friendly and more effective aggro system than UAS, I came to the conclusion that ABC has become obsolete.
I don't even use PUI anymore. Blizzard hashtables seem to be a lot more relying and failure-resistant than any system I saw so far. It may be possible that non-H2I functions like PUI are still faster than hashtables, but, however, they are a lot more unstable.
I personally prefer safer, non-depending scripts far over the last piece of speed-optimizing, that is useless anyways because any 30 Dollar Ebay-PC can handle WC3 even with the slowest scripts ever.


ABC is fine for those that are too lazy to learn how to use blizzard hashtables effectively; however, I will try to avoid anything depending on additional scripts like ABC in the future. (Hopefully it decreases the number of crit errors on custom maps)

Sad, that blizzard didn't add these functions more early.

 

[Karawasa]

PUI is perfectly fine. I don't know what you're talking about when you say it's "more unstable." I can't speak for ABC though.

 

[Jesus4Lyf]

hashtables seem to be a lot more relying and failure-resistant than any system I saw so far. It may be possible that non-H2I functions like PUI are still faster than hashtables, but, however, they are a lot more unstable.

Some of the most unfounded nonsense I've seen so far.

 

[Zwiebelchen]

PUI is perfectly fine. I don't know what you're talking about when you say it's "more unstable." I can't speak for ABC though.

Well, I sometimes experienced indices missing (mostly in combination with "do not decay" units) - but I agree it could have been my mistake, too.
I didn't say that PUI is obsolete now, only that I wouldn't use H2I attaching like ABC anymore.

 

[kingkingyyk3]

Attach to trigger, there are no alternative as well other than H2I.
**You can use GetTriggerExecCount as well, but you need to change all the actions into conditions. lol. Big changes.