Global timers block the setting of global variables, apparently

[temnix]

It's strange, but for some reason the start of a global timer in a script can block other actions preceding it. The setting of global variables, at any rate. Here is the example script where I encountered this. It was written like this originally:

IF
    Conditions...
THEN
    RESPONSE #1
       SG("DICED",1)
       SetGlobalTimer("DICED","GLOBAL",TWO_ROUNDS)
       
END

Below in the same script was a block checking for that timer's expiration:

IF

GlobalTimerExpired("DICED","GLOBAL")
Global("DICED","GLOBAL",1)

THEN...

Consequences...

The DICED global had to be at 1 to prevent the consequences from happening again and again; after the first time it was set to 0. Well and good, only nothing was happening. Eventually I realized that DICED was not getting set to 1. But when I moved the SG() action down, like this -

IF
   Conditions...
THEN
    RESPONSE #1
        
       SetGlobalTimer("DICED","GLOBAL",TWO_ROUNDS)
       SG("DICED",1)
       
END

- the system began to take notice. Are there other landmines like this in scripts I should be aware of?

Edit: Actually, it's worse that this. I went on with the script and what I found is that the engine confuses the names of global variables with identical names of global timers. In this example the DICED timer was triggering in one round no matter what length I assigned it: TWO_ROUNDS, FIVE_ROUNDS, it was all the same. The name of the timer was DICED, and the name of the related global, for convenience, was also DICED, and that caused the problem. I renamed the timer DICER, and then it began to trigger in due course. Not expected.

Edited September 14, 2019 by temnix

[kjeron]

The only difference between SetGlobal and SetGlobalTimer is that "GameTime" is added to the value of the latter, but they both set variables in the specified scope.

Edited September 14, 2019 by kjeron

[temnix]

3 minutes ago, kjeron said:

The only difference between SetGlobal and SetGlobalTimer is that "GameTime" is added to the value of the latter, but they both set variables in the specified scope.

kjeron flies to the rescue... Well, does that mean I could use timers with negative durations to undo quests or unset death variables?

[kjeron]

You can use "IncrementGlobal()" with positive value to extend a timer, or a negative value to shorten the timer, so long as the script that checks for the (expired) timer hasn't already fired (usually, really depends on how the script is setup and what safeguards it has).

Death variables are just another global variable, can easily be set to 0 (unset) with SetGlobal().

[Ardanis]

Slight correction - SetGlobalTimer() transforms its argument into time (multiply by 30, iirc) rather than adding to game time directly. So if you need to adjust a timer, increment it by time_in_seconds*30. Or 15, don't remember.

Realistically though, there's not much use for this feature other than setting variable to 0 to manually expire the associated timer. For anything else, be prepared to have to debug and fix your script logic.

Edited September 14, 2019 by Ardanis

[kjeron]

Yes, just like effect duration's, it converts gametime to ticks when storing the value, so a 15x multiplier.

[temnix]

You could use variable-incrementing to delay the onset of a timer. For example, death by water will occur in one turn, but every tap you turn increments the timer value by something, buying you more time. I had no idea this could be done. Also the globals can be incremented via spells.

[temnix]

It's time for an update of this topic. From what I understand, a global and a global timer are the same thing, only with the timer its value continues to increase - with time. But what if time reversed its course? It can do that with AdvanceTime() to something negative. If the jump back is long enough, is it is possible to arrive at a point where the timer has not yet run? Where (when) the value of the timer, and of the global, is 0 or less than 0? Is the timer considered to have started then already or not? Is it going to respond to both NotExpired and GlobalLT(1)? And if it is possible to go back to GlobalLT(1) with this application of AdvanceTime, then is that also possible for the "LOCALS" scope?

[kjeron]

Timer's don't change value once set.

When you call SetGlobalTimer(), it's sets that variable to the current (gametime + given value, in ticks).

The timer is 'expired' if gametime has passed that new value, or 'running' if it has not.