Jesus4Lyf
Good Idea™
- Reaction score
- 397
>and then add some Conditions dynamicly.
Sounds like something Event would be useful for.
Sounds like something Event would be useful for.
ExecCount attaching
Furthermore, the usage section doesn't even document the set/get data functions.
If a map using this system lasts longer than the mapper expected, core functions of the map would suddenly fail for not one but TWO reasons - the offset may not be set high enough, and the maximum number of triggers may not be set high enough. What if a map has a high turn-around on triggers?
Worst of all, you haven't documented ANY of these downsides! A moderator, posting an unstable system, naming it after a stable and well founded and used system (TimerUtils) is really quite misleading. Calling it TriggerUtils is a misnomer.
And why name this after TimerUtils anyway? This doesn't support NewTrigger/ReleaseTrigger recycling, which the name suggests it might.
Your set/get data functions don't inline. What's the point of using H2I in a way that's both slow AND unstable?
Jass:
set Time=Time+1
set r = TimerGetElapsed(Tim)+Time*TimeoutTime should represent the total time passed in the game. This is actually inefficient anyway, you should just use TimerUtils or something.
At very least, I would like to see a name change.
This system will work when you implement ExecCount attaching, name DestroyTriggerEx ReleaseTrigger instead, make it still destroy the trigger after time, but also in the mean time generate a new trigger with the same ExecCount number, and make the get/set data functions inline. Until then I would not use this system.
set Taken[ModuloInteger(t2i(destroyedTrig),8191)]=false
loop
set newTrig=CreateTrigger()
exitwhen not Taken[ModuloInteger(t2i(newTrig),8191)]
call DestroyTrigger(newTrig)
endloop
wtf is that supposed to mean? Where is this terrible coding practice of which you speak? I think I may just neg rep you for a useless, derogatory post...expplain yourself or be gone
I would have expected better from you
function GetTriggerData takes trigger t returns integer
local integer id = t2i(t)-Offset
debug if t==null then
debug call BJDebugMsg("|c00ff0303GetTriggerData error: null triggers cannot have retrievable data.")
debug elseif id<0 then
debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger id is too small, reduce Offset value.")
debug elseif id>RealArraySize then
debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger id is too large, increase ArraySize value.")
debug elseif TriggerData[id]<=0 then
debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger has no attached data.")
debug endif
return TriggerData[id]
endfunction
I would have expected better from you
Still, it may need some extra safety like a gamecache backup since you never know what the user can do.
Why should you have N triggers when you could just have 1? There is no difference, other than the whole leaking events thing. TimerUtils has a valid claim to its existence; we use timers for precision, thus one timer rounding off periods and such is just not good enough for things which require such exactness. But for triggers?
-[1]- (one unit event to a local, dynamic trigger) x (instances of your spell)
-[2]- (one unit event to a global, static trigger) x (instances of your spell)
-[3]- (one any unit event to one trigger) x (1)
Notice how they are all the same thing, ranked from worst efficiency (both of processing power and in time taken to write the code) to best. You are enabling the creation of level 1 code here. Keep in mind that level 1 coding in this case is TERRIBLE. See? Right there. That was my point. You are asking people to use this and go write TERRIBLE code with it.
-
Why? So you can say, "I made this system and people use it! Yay! I am a god!" Seriously? Come on:
Sure they are, mostly Waagh.
Is there any way you could inline this thing:
JASS:function GetTriggerData takes trigger t returns integer local integer id = t2i(t)-Offset debug if t==null then debug call BJDebugMsg("|c00ff0303GetTriggerData error: null triggers cannot have retrievable data.") debug elseif id<0 then debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger id is too small, reduce Offset value.") debug elseif id>RealArraySize then debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger id is too large, increase ArraySize value.") debug elseif TriggerData[id]<=0 then debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger has no attached data.") debug endif return TriggerData[id] endfunction
to something like:
JASS:
but still keep the debug messages? This way it's going to get as fast as possible when attaching and such (assuming set function is done the same way). Still, it may need some extra safety like a gamecache backup since you never know what the user can do.
I lolled.
I dont use dynamic triggers either, but that doesnt mean that someone can use them without bugs. And yes I think they evil and everything, but I still realize that they can be used without bugs so they there must be something good in them too.
I just dont believe anymore that there is only one and the only way to code things and all the other ways suck. ( Thats Jesu4Lyfs fault actually. He makes so damn weird systems that I had to question my old beliefs. )
Pretty funny actually. I never expected anything from you Waaaagh, but you still managed to amuse me.
( funny thread ) User can do anything and no matter what you do they still find some way to fuck up everything. Just have good error messages in your system and you are fine.
And about TriggerExecuteCount attaching. Doesnt TriggerExecuteCount attaching require you to call shitloads of TriggerExecutes to get different indexes for all triggers? Seems lil bit weird method to me, since H2I works too..
debug local integer id = t2i(t) - offset
// all the tests, ifs, safety, etc.
return TriggerData[t2i(t)-Offset]
If time represents the total time passed, the local real r isn't required.JASS:set Time=Time+1 set r = TimerGetElapsed(Tim)+Time*Timeout
Time should represent the total time passed in the game. This is actually inefficient anyway, you should just use TimerUtils or something.
exitwhen i>Count
if ExpirationTime<i><=r then</i>
exitwhen ExpirationTime<i>>Time</i>
> just as an example, any of the hero arenas I have made have never exceed 3,000 handles at any given time
Totally wrong, I had a game of your Mini Element Arena with 21k handles just before the end.
Anyway, high handle count does not mean absolutely anything (mostly for the part where your map "sucks"). I wouldn't even care if I had 100k handles as long as my map worked and had no lag issues (assuming the problem couldn't be fixed but I doubt such a situation can happen)...