[vJASS][Utility]Game Time

[Nestharus]

This resource has moved here.

--

gone

 

[Saia_Djinn]

didnt i hear about the boolexpr null leak? use BoolexorUtils and the BOOLEXPR_TRUE value to fix leak

 

[Nestharus]

Huh?

 

[Yixx]

that is not a boolexpr, it is a null function, as in "It will run (null) if the timer ends".

This is easy, but still nice. Now we wont have to make it ourselves, which is actually the real point of a system or utility, GJ..

Though i would try to find out the maximum value of a real in JASS and increase 'gameTime' to that.

 

[Reaper2008]

Though i would try to find out the maximum value of a real in JASS and increase 'gameTime' to that.

Or set it to 99999999999 and hope that works ^^ .

 

[MapperMalte]

public function Get takes nothing returns real
return TimerGetElapsed(runGameTime)
endfunction

What a crappy name!

GetElapsedGameTime() is better

 

[Nestharus]

It used to be GetElapsedGameTime, but Get is shorter, and GameTime is already in the name : p, lol.

Also, reals can pretty much go up to any number : |. I used 100000 as it stays in the 32 bit limit (anything above 32 bit for real will slow way the hell down) and it will run for 1.9 years before stopping : P.

 

[Yixx]

Mapper Malte, you see the word public ? That means it will add a prefix, as i am sure you will know, which makes the name a whole lot less lame.

Oh, wait, 1000000/60/24/365.25 = 1.901
That is indeed 1.9 years lol xD,, ok fair enough,,

 

[MapperMalte]

I know, but the name is still crappy.
I don't want to memorize the name of each function, I rather have consistent patterns.
And this function doesn't follow them.

 

[TriggerHappy]

I know, but the name is still crappy.
I don't want to memorize the name of each function, I rather have consistent patterns.
And this function doesn't follow them.

Agreed, I hate all of Nestharus's naming conventions =)

 

[aznricepuff]

    private function StartGameTime takes nothing returns nothing
        call TimerStart(runGameTime, gameTime, false, null)
        call DestroyTrigger(startGameTime)
        set startGameTime = null
    endfunction

That's just asking for handle stack corruption. You're destroying a trigger using it's own action thread.

 

[Dreadnought[dA]]

    private function StartGameTime takes nothing returns nothing
        call TimerStart(runGameTime, gameTime, false, null)
        call DestroyTrigger(startGameTime)
        set startGameTime = null
    endfunction

That's just asking for handle stack corruption. You're destroying a trigger using it's own action thread.

Explain more please, because I tend to do that a lot as well..

 

[aznricepuff]

If you destroy a trigger while one of its actions is still running, you risk handle stack corruption and by proxy, your map bugging seriously/crashing.

 

[Dreadnought[dA]]

So, would calling a function that waits 0.01 seconds then destroys the trigger work? As long as the destroyed triggers actions don't run longer than 0.01 seconds ofc.

 

[aznricepuff]

I've heard that sometimes trigger actions will still be active even after the action function returns, which makes NO sense to me but frankly I wouldn't be surprised if it turned out to be true considering all the other crap that blizz put into JASS.

 

[Element of Water]

Isn't there a native to stop a trigger? Or you could simply crash the thread by doing local real r = 1./0.

 

[aznricepuff]

I'm too lazy to test these things since it would take way too long...destroying triggers and wait for a few hours to see if your map crashes or not.

And don't you use integer division by 0 to crash a thread? I thought reals supported division by 0. Then again this just could be because I'm used to floats in every other language supporting division by 0.

 

[Element of Water]

Just tested crashing the thread and it works with either reals or integers.

 

[Nestharus]

Also.. I've used destroy triggers constantly, even in full blown maps. After a hundred games of 1-3 hour matches, 0 crashes, 0 handle stack corruption, and 0 desyncs.

I think it's safe to assume that this is safe ^_^. Also, considering the memory that some of my stuff uses, I prefer to clean up all leaks as opposed to most of them, even if those leaks are presumably "dangerous" to clean up by others standards. The fact that I've never seen a problem with them unless I "intentionally" make a problem leads me to believe that people are just dramatizing these issues.

 

[Element of Water]

How do you know 0 handle stack corruption? How can you tell?

 

[Nestharus]

I played a map online I made a while back for a few days that uses various systems that destroy triggers -.-. The games would last anywhere from 5 minutes to 4 hours. I'd play about 18 hours a day. I believe I played this map for a total of 4 days.

The only bug I ever ran into in that map was a command for giving gold and lumber to other players on your team. The reason I had bugs with this command was because I didn't put too much safety into it as I was primarily focused on speed... people kept trying to break it by inputting text instead of numbers =p. In games where people didn't attempt to trade, there were never any desyncs or crashes. In all games, there were 0 desyncs.

Now, it's impossible to provide solid proof. When used improperly, you can create handle stack corruption, and so in some cases, destroying triggers and timers will kill the map its inside of. However, in this case, I can assure you that this does not cause handle stack corruption.

Furthermore, why is this not just on a TriggerRegisterTimedEvent over the TriggerRegisterTimerExpireEvent (just winging these). The reason is that a timer is lighter than a trigger and thus slightly faster =). Why? It doesn't use a stack and instead calls a function directly : p.

So in response to this question-

How do you know 0 handle stack corruption? How can you tell?

I have observed it enough times to say that in this case I "assume" that there is no handle stack corruption.

Code isn't magic, and if something doesn't make any sense then you either aren't seeing the whole picture or it's not true ^_^. Now, this is just a theory on my part, but I believe the only way for a trigger to remain active even 20 seconds or w/e after it was executed (no sleeps or anything) is if other triggers are running through that period with multiple actions and what not. Now, I have not tested this so I don't know for sure. What I do know is that triggers take precedence when they begin running. When you execute a trigger from another trigger, that executed trigger will run through and then will return to the initial trigger. In this way, if you did this

Trigger 1 executes Trigger 2
Trigger 1 executes Trigger 3
Trigger 2 executes Trigger 4
Trigger 3 executes Trigger 2

Trigger 1 Start
1 -> 2
2 -> 4
2 <- 4
2 <- 1
1 -> 3
1 <- 3
Trigger 1 Continue and End
2 -> 4
4 <- 2
Trigger 2 Continue and End

So I guess if you have multiple actions on a trigger and other triggers begin running on other actions, maybe those other triggers will take precedence, but that makes absolutely no sense ^_^. What makes more sense is that those other triggers get added to the stack and execute one after another as soon as the current trigger finishes =).

Now, when destroying a trigger, a trigger obviously can't run anymore if it's destroyed... so, wc3 will destroy it at the end. If you attempt to destroy it 2x, that will probably cause problems as it frees up the memory 2x (2nd time is null, so it just sends the handle counter back 1 more than it's supposed to go).

Now, apparently people tried this and thought, wth, it only destroyed once (I wasn't one of them so I can't vouch), so people tried a TriggerSleepAction in between. Because the trigger was asleep, it thought the trigger was finish so it cleared out the memory. The function that was on the trigger runs up again (no following functions will run as the trigger is cleared) and then it sees another DestroyTrigger, so it clears it up again (clearing nothing as no trigger exists, but sending the handle counter back 1).

This is the only way I can see handle stack corruption.

Now with timers, when a function on a timer is set to run while one is already running and both destroy that timer, handle stack corruption can occur. If the other one runs after the timer is destroyed, then you don't have handle stack corruption. If the timer is destroyed twice or multiple timers (multiple functions all destroying same timer and running on same timer) then that will obviously cause handle stack corruption : ).

Now, if I am wrong in any of this (a lot of it is just theory), then please feel free to intervene. I don't claim to know the inner workings of wc3, so all of this has only come from logic that has sprung up from tests =).

In finality, i can't see how a trigger that is run once can destroy itself twice ^_^. Playing the map has shown me this concept and I have never seen an example that proves otherwise. The only examples I have ever seen for handle stack corruption is the very specific one I mentioned above, in which you destroy a trigger, put it to sleep, and then destroy it again. I also provided the reasoning as to why the corruption occurs.

 

[Element of Water]

You played one map for 4 days, 18 hours a day??? You sad, sad person.

 

[Nestharus]

You played one map for 4 days, 18 hours a day??? You sad, sad person.

You asked me how I knew

 

[aznricepuff]

http://www.wc3c.net/showthread.php?t=105477

I think the above makes this a candidate for graveyard.

 

[TriggerHappy]

http://www.wc3c.net/showthread.php?t=105477

I think the above makes this a candidate for graveyard.

I would say so too, except I don't think GameClock is submitted here.

 

[aznricepuff]

Neither are TimerUtils, Table, GroupUtils, etc. But I'm still going to reject clones of those.

 

[Nestharus]

I didn't make this while looking at any other similar system, also this is faster as it does less, so I wouldn't call it a clone. It's quite simple and is actually categorized as a snippet on The Helper : ).

 

[Element of Water]

I think this is way better still. And look, they're going to merge it with the one aznricepuff linked to. Yours, Nestharus, doesn't have a patch on that.