Fuck you Warcraft 3, do my waits for me.

[doom_sheep]

Disclaimer: I mostly come here for specific purposes and am quite unaware of happenings, codecraft and the state of science. Everything following may be horribly wrong or invalidated by something simple I haven't heard of.

The problem:
Warcraft 3 really doesn't like waits. GUI "wait" is a cruel joke/eldritch monstrosity and triggers can't create timer variables, only refer to the pre-created ones. I said "give me a spell that does a thing 10 seconds after it is used", the world editor made inappropriate remarks about my mother.

Warcraft 3 is constantly running itself, because duh. But it can't run a wait without you first filling out fifty forms in chinese and sacrificing a goat. You're tempted to create a useless dummy unit that will notify the game for your effects at the end of its timed life, but a couple hundred instances of that will just kill the game.

So, really just go ahead and make some code to tell blizzard's code to do things exactly like what it's already figuring out for approximately all the hardcoded behavior?

Alternatively, find a function of the game that's effectively a timer, but hardcoded and replicable to your desire. I've made an extremely durable footman, and spawn a hero unit which gains a point of its main attribute and therefore damage with each iteration. the projectile is extremely slow and by changing the distance I'd create a timer. Though the attacker is removed shortly after sending it, the damage value of the projectile will remain and upon impact, remind the target what the array number of further instructions is. These units could be hidden away outside of camera bounds, or whatever.

Issues:
- Other than the Reaction Delay gameplay constant there are minimal inaccuracies in timing.
- Projectiles can live up to 60 seconds.

Questions:
- Efficient? Who knows.
- Reliable? ...Probably?
- Is there a better function to use for this?

Uses:
- ???

 

[Anitarf]

Just use TimerUtils?

 

[Dr Super Good]

Warcraft 3 really doesn't like waits. GUI "wait" is a cruel joke/eldritch monstrosity and triggers can't create timer variables, only refer to the pre-created ones. I said "give me a spell that does a thing 10 seconds after it is used", the world editor made inappropriate remarks about my mother.

Warcraft 3 is constantly running itself, because duh. But it can't run a wait without you first filling out fifty forms in chinese and sacrificing a goat. You're tempted to create a useless dummy unit that will notify the game for your effects at the end of its timed life, but a couple hundred instances of that will just kill the game.

WolrdEdit GUI is quite literally a "PoS". Even JASS does not give you easy delays for writing sequential code, forcing one to break code into separate sub-functions for scheduling later with timers or events.

Luckily Blizzard fixed this in StarCraft II. There the wait works perfectly, giving you precision to the nearest game frame (smallest unit of time that matters) and able to choose between real time (for UIs) and game time (for game mechanics).

 

[TheLordOfChaos201]

you could change your attack to a parasitic spell ability

they damage one every few seconds, this timer which is set by you can be any length of time

how to do this

change your spell to the parasitic spell. then set the attack points and seconds timer. then create a trig that removes that buff from your target after the damage is taken

if it's set like this
parasitic spell damages unit every 9 seconds
trig disables buff after 14seconds

Then there is hardly ever a chance your attack will damage twice and you have a nice easy timer

=) Hope this helps

 

[Dr Super Good]

The problem is that any approach to create a timer out of units with damage does not actually solve anything. It is less efficient and slower than simply using a timer and still requires functional fragmentation of a sequence.

 

[Chaosy]

Just use TimerUtils?

Can not be compared to the usefulness of a proper thread.sleep (wait).
Coding spells would be sooooooooo much easier with waits, timerutils does not really make it easier. Just more efficient. Mainly speaking from a GUI perspective.

edit: If this was somewhat viable I would find coding spells funny.

• Untitled Trigger 001
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
  • Actions
    • -------- do spell init stuff --------
    • For each (Integer A) from 1 to 3, do (Actions)
      • Loop - Actions
        • Wait 0.03 seconds
        • -------- do spell loop stuff --------

 

[doom_sheep]

From initial testing, variation seems to stay within the second decimal of a second.

This might just be usable.

--

hory shet

I thought this would be unusable for short waits but it may just be the opposite

 

[Wietlol]

delay is between 0 and 0.2 seconds... on small waits.
I havent tested it in large waits.

 

[doom_sheep]

Custom script: call UnitRemoveAbility(udg_TempUnit, 'Amov')
there was an initial random delay, but this appears to address it perfectly.

projectiles in flight for a long time seem to pick up random delays, though these are quite small. at 30 seconds it stayed under 0.010

there are a lot of factors in the projectile type that may be able to affect it somehow.

 

[Zwiebelchen]

Just quit whining, man up and learn JASS.

If GUI is too limited to you, stop letting it hold you back.

 

[Chaosy]

Just quit whining, man up and learn JASS.

If GUI is too limited to you, stop letting it hold you back.

Do jass have waits that actually works properly?

 

[Zwiebelchen]

Do jass have waits that actually works properly?

It doesn't need any. It has timers.

 

[Chaosy]

Timers sucks.

function x takes nothing returns nothing
    //do something
    call TriggerSleepAction(...)
    //do something else
endfunction

// vs

function y takes nothing returns nothing
     //do something else
endfunction

function x takes nothing returns nothing
    //do something
    call TimerStart(... function y)
endfunction

 

[Wietlol]

Ever worked with promises?

 

[Dr Super Good]

Just move to StarCraft II already. The below is possible there and it is accurate.

• Untitled Trigger 001
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
  • Actions
    • -------- do spell init stuff --------
    • For each (Integer A) from 1 to 3, do (Actions)
      • Loop - Actions
        • Wait 0.0625 seconds
        • -------- do spell loop stuff --------

Combined with how GUI has local variables and there are no leaks I wonder why so many people stay with WC3.

 

[Chaosy]

Ever worked with promises?

I am clueless.

 

[Wietlol]

Promises are basically waits for async code:

    doSomething().then((data) => {
        return doSomethingElse(data);
    }).then((data) => {
        return doSomethingMore(data);
    }).then((data) => {
        resolve(data);
    }).catch((err) => {
        reject(err);
    });

You will use it a lot when dealing with online programming... ussually API code.
Timers dont really differ that much if you know how to use them properly.

 

[Chaosy]

That seems like a horrible replacement for something as basic as a wait.

 

[doom_sheep]

the 0.100 is an attack delay or something, or possibly even a mistake by the comparison timer. maximum projectile lifetime appears to be 60 seconds.

other than that, only the last digit changes. it stays constant for 8 seconds then gets slightly erratic by the end.

 

[Wietlol]

That seems like a horrible replacement for something as basic as a wait.

It actually is the best way to do it... and I kind of got used to it cause of timers.

@doom_sheep
What is it actually you would like to have instead of timers?

 

[DracoL1ch]

Just move to StarCraft II already. The below is possible there and it is accurate.

• Untitled Trigger 001
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
  • Actions
    • -------- do spell init stuff --------
    • For each (Integer A) from 1 to 3, do (Actions)
      • Loop - Actions
        • Wait 0.0625 seconds
        • -------- do spell loop stuff --------

Combined with how GUI has local variables and there are no leaks I wonder why so many people stay with WC3.

cause nobody plays SC2 comparing to wc3/dota2 audience

 

[Anitarf]

Luckily Blizzard fixed this in StarCraft II. There the wait works perfectly, giving you precision to the nearest game frame (smallest unit of time that matters)

And how long is one game frame?

 

[Wietlol]

1/60 seconds? 1/120 seconds?
Or something more depending on how powerful your device is.

 

[Dr Super Good]

And how long is one game frame?

1/16 of a game second. Which is fine as there is interpolation for graphics.

 

[Anitarf]

1/16 of a game second. Which is fine as there is interpolation for graphics.

So, you can make a unit play an animation after 1/32 of a second?

 

[Dr Super Good]

So, you can make a unit play an animation after 1/32 of a second?

Why would you want to? If you want to play a very precise sequence with sub frame precision then you use actor events in the data editor as the actor system is not limited to game frames.

 

[GhostWolf]

That seems like a horrible replacement for something as basic as a wait.

Not related to WC3, but if you want to check out an elegant solution, look at Ruby's fibers.
Also, waits aren't basic at all.

 

[Chaosy]

To me it is.

A one-liner that waits for x seconds before executing the next line, it can't get much more basic than that.

 

[HappyTauren]

They are not basic to implement.

 

[Anitarf]

If you want to play a very precise sequence with sub frame precision then you use actor events in the data editor as the actor system is not limited to game frames.

Great, the data editor is better for coding things than the trigger editor.

 

[Dr Super Good]

Great, the data editor is better for coding things than the trigger editor.

For art/animation related tasks it is because it feeds straight into the graphics system allowing you much more precise control over art.

Anything that alters gameplay has to be done with triggers and is limited to 1/16 of a game second (usually 1/20 or less of a real second). This limitation is a non-issue as that is the minimum unit of deterministic time in StarCraft II anyway, so stuff that alters gameplay cannot happen with a shorter period.

 

[Anitarf]

For art/animation related tasks it is because it feeds straight into the graphics system allowing you much more precise control over art.

That's the problem. It's a graphical user interface that feeds straight into the graphics system instead of there being an intermediate level where I could write code, which would be inherently more powerful and productive than any kind of GUI (doesn't matter if it's the data or the trigger editor).

 

[Aniki]

Well, if one had a decent compiler it could possible translate code like:

function accurate_wait takes nothing returns nothing
    local integer i

    call BJDebugMsg("foo")
    wait 0.5
    call BJDebugMsg("bar")
    wait 1.0
    call BJDebugMsg("baz")
    wait 1.5

    set i = 1
    loop
        exitwhen i > 9

        call BJDebugMsg(I2S(i))

        set i = i + 1
        wait 0.1
    endloop

    call BJDebugMsg("done")
endfunction

to something like this:

globals
    timer w_timer = CreateTimer()
    integer w_state
    integer w_i
endglobals

function accurate_wait_loop takes nothing returns nothing
    // local integer i

if w_state == 1 then

    call BJDebugMsg("foo")

    set w_state = 2
    call TimerStart(w_timer, 0.5, false, function accurate_wait_loop)

elseif w_state == 2 then

    call BJDebugMsg("bar")

    set w_state = 3
    call TimerStart(w_timer, 1.0, false, function accurate_wait_loop)

elseif w_state == 3 then

    call BJDebugMsg("baz")

    set w_state = 4
    call TimerStart(w_timer, 1.5, false, function accurate_wait_loop)

elseif w_state == 4 then

    set w_i = 1

    set w_state = 5
    call TimerStart(w_timer, 0, false, function accurate_wait_loop)

elseif w_state == 5 then

    if not ( w_i > 9 ) then
        call BJDebugMsg(I2S(w_i))

        set w_i = w_i + 1
        call TimerStart(w_timer, 0.1, false, function accurate_wait_loop)

    else
        set w_state = 6
        call TimerStart(w_timer, 0, false, function accurate_wait_loop)
    endif

elseif w_state == 6 then

    call BJDebugMsg("done")

endif
endfunction

function accurate_wait takes nothing returns nothing
    set w_state = 1
    call accurate_wait_loop()
endfunction

which is hardly something anyone would want to write by hand for more than 5-10 states (compilers++).

Of course it would only work for functions that return nothing but it's still something =).

 

[Waffle]

you could always write another precompiler that searches for TriggerSleepAction and translates that to something that actually works...

good luck with that tho. getting all those corner cases right..

 

[Chaosy]

Even if you succeeded you'd still need to compete with JNGP unless you get the vjass source code.

 

[Pinzu]

This might be really dumb suggestion, but how long would you have to loop before you achieved a one second wait (the loop only increases the counter of int). Is that time universal or depends on the users computer even in multiplayer?

 

[Wietlol]

If you would only increase the counter of an int, you would use exactly 0 seconds to do that.
If you do that a billion times, it still takes 0 in-game seconds to do so, because the game doesnt go to the next frame until all actions are done.

On the other hand, it is not only increasing an int, it also starts a new timer.