As said, you could see if there's something in RtC you can use. Aside from that, I know the way I do it is 1.21 or whatever it is I'm using. You still have to write a test that will accurately measure things, even if you get that working... =/ lol
Heh, you should ask questions about the T32 thing in the T32 thread, I'll be happy to answer them where people can all contribute and learn together...
In regards to benchmarking, you need a 1.21b installation. Heh.
And if you get it up, you'll get probably much higher figures than mine, but the percentages should be around the same. ^_^ (I have a slow computer for benching.)
Don't worry, KT_GetData() is one of the most confusing pieces of code you'll ever read.
Especially because it works completely differently depending on which half of the system your code happens to be running on.
If you want to attach data to a trigger, use TriggerExecCount directly if the code will be run on initialisation, or precache some exec counts and use it as an array index if it will be done at runtime. The idea is you don't want to do the exec counts during the game, because it could cause lag for high instances (complicated, isn't it?).
If you want to attach to a timer, use T32 or KT2. (T32 for 0.03125 periods.)
>the way you code just inspires me lol xD
Thanks! XD I like to do a few tricks to keep my stuff from breaking on the next patch and it also happens to make it really efficient. =]
My last post should help explain how I did it for low periods, for fast periods I injected the exec count into the flow of KT's GetData list thing. I made a single node that links to itself, and before your function fires, it sets the node's value to the exec count of the trigger. It's just an interface thing. So it could be a bit faster, but for periods above 0.3 seconds, the speed thing doesn't matter (as long as it's still fairly fast).
I did something nasty. There's an "And" boolexpr operator in wc3, and I found a use for it: creating a nice interface in KT2. What is actually attached to the trigger is not your function as a boolexpr, it's And(Condition(yourFunc),Condition(ifYourFuncReturnsTrue)) and ifReturnsTrue returns false. The And "operator native" (if you will) uses short circuit evaluation - meaning if the first returns false, it knows the end result is false, so it doesnt run the ifReturnsTrue. Since that ifReturnsTrue function returns false, it will all return false either way. In the ifYourFuncReturnsTrue function, I perform the removal actions. Thus the pleasant KT2 experience of "return true", "return false".
For higher periods, I attach each instance to its own trigger, but for lower periods I attach everything for one period on one trigger... And the GetData function ticks over to the next data (hence why it must be called exactly once in the code). (Btw, And(a,b) boolexprs need to be destroyed.)
You use condition functions that return false and then the number of times the actions have been executed (exec count) is the struct. Typecast it back, and before hand, execute the actions that many times. You can also precache a unique execution count, use it as an array index (like in DTS there) and store the struct in the array.
KT2 also does something funky for low periods which is much harder to understand. It maintains a parallel linked list to a bunch of conditions on single triggers. It's attached by converting the period into a unique number. Funny things.
Is the school system in your country similar to Chinese school system? I could never imagine being a teacher in a Chinese school, what's expected of students and teachers is just so different from what I'd be looking for as a teacher