[JASS] TriggerSleepAction question

[Bribe]

I am unable to test this out... can someone please tell me what would happen in this circumstance? My objective is to create a knockback effect without using hashtables, but I don't know if the TriggerSleepAction will register...

function testrun takes real x, unit u returns nothing
    call TriggerSleepAction( x )
    call SetUnitX( u , GetUnitX( u ) + 10 )
    call SetUnitY( u , GetUnitY( u ) + 10 )
endfunction
function loop takes nothing returns nothing
    local real x = 0.
    local unit u = GetSpellAbilityUnit()
    loop
        set x = x + 0.01
        call testrun( x , u )
        exitwhen x > 0.50
    endloop
    set u = null
endfunction

Edit: yes, I do know that TSA has a minimum wait of .26, but I am hoping the minute differences between the wait times will sometimes register at a slightly different time.

 

[Dynasti]

The unit would move. Slowly.. I suspect.


I'd recommend a timer for this kind of use. Long loops of waits are never good.

 

[Bribe]

Wait, so the TriggerSleepAction affects the loop? No, that's not what I want. I want it to only sleep the function, not the loop (so that essentially 50 waits are cued and will play out very quickly after .26 seconds)!

 

[Teelo]

Each iteration of the loop will be waiting for the call to test_run() to finish before it can continue with the loop. If you want the loop to keep running, use something that will just queue up the call to test_run(), like a timer!
Well, that wont work because you cant put parameters in a timer call

 

[Mooglefrooglian]

Create a timer, wait .26 seconds with it, then loop 50 times and call the function.

Not so hard!

Alternatively, if you have JNGP, .execute() is what you want.

function testrun takes integer i, unit u returns nothing
    call TriggerSleepAction(.1) //Goes to .3ish
    call SetUnitX( u ) = GetUnitX( u ) + 10
    call SetUnitY( u ) = GetUnitY( u ) + 10
endfunction
function loop takes nothing returns nothing
    local integer i
    local unit u = GetSpellTarget()
    loop
        set i = i + 1
        call testrun.execute( i , u ) //starts new thread, requires JNGP to use.
        exitwhen i > 50
    endloop
endfunction

That might lag a bit though, I've found .execute() to not be quite perfect. Smarter idea would be to use the timer anyways.

Also, your loop is wrong. You need to initialise i to 0, or you used to have to. It starts off null. Or at least, I think you have to. I had the problem before, but maybe JNGP autocorrects that?

Finally, your SetUnitX and Y is wrong. It is a function, not a variable.

And, to end it off, GetSpellTarget() isn't a function. GetSpellAbilityUnit is, though.

Here is my timer version.

scope Spam initializer Init
    globals
        private hashtable Hash
    endglobals
    
    private function Init takes nothing returns nothing
        set Hash = InitHashtable()
        //Set up your trigger here
    endfunction
    
    function testrun takes unit u returns nothing
        call SetUnitX(u, GetUnitX(u) + 10)
        call SetUnitY(u, GetUnitY(u) + 10)
    endfunction
    
    private function Tick takes nothing returns nothing
        local timer t = GetExpiredTimer()
        local integer i = 0
        local unit u = LoadUnitHandle(Hash, GetHandleId(t), 0)
        loop
            exitwhen i > 50 //will loop 51 times
            call testrun(u)
            set i = i + 1
        endloop
        call FlushChildHashtable(Hash, GetHandleId(t))
        call DestroyTimer(t)
        set t = null
    endfunction
    
    private function loop takes nothing returns nothing
        local unit u = GetSpellAbilityUnit()
        local timer t = CreateTimer()
        call SaveUnitHandle(Hash, GetHandleId(t), 0, u)
        call TimerStart(t, 0.26, false, function Tick)
        set t = null
    endfunction

endscope

However, your final goal is to create a knockback without hashtables? This wont. This will instantly blink your unit something around 500 range.

First, go read up on JASS. You dont appear to have a solid grounding. At all. Second, don't attempt a knockback until you know what your doing. Your SetUnitX() mistake is extremely bad and shows you don't know how functions work, which means you dont understand basic coding.

Finally, the idea of a knockback without hashtables is a single timer that ticks every 0.04 seconds or so, and loops through an array of units and moves them that way. There are some good tutorials on how to accomplish those, go find them.

 

[PurgeandFire]

Your method works. But not very well. The unit will be moved at a very jittery pace, and increasing the wait time will just make the movement seem more blocky. =P (Btw, yeah I tested this in a map just now, so these are legit results)

I'm well aware that you know how to use timers, so I won't bother explaining them. =D That was just meant to be a test function. This has been thought of for MUI, but it isn't very functional, which is why we result to timers. TriggerSleepAction() varies in how long it waits. The shortest wait I've received from it was 0.07895 or so. The next shortest was ~ 0.0985. (Based on the speed of TriggerSleepAction() itself and the accuracy of TimerGetRemaining). But to get these results you'll have to input 0 or a negative value. Even then, it isn't the greatest, since it will cause even more jitterness, due to the extreme variation. I think I've had it wait even from a range of 0.07895-0.25 waits! But that's only if memory serves me correctly.

People say using hashtables for maps are bad, but they really aren't. They suit the map and are easy to use. Yes, using array systems designed for structs are about twice as fast, but I don't get pissed when I'm playing and have to wait more nanoseconds for code to execute. =P People also say that it is inefficient due to the 256 limit, but who really reaches that much? If you have that many imported spells, then maybe. Or if you make like 1 hashtable each time a code is ran. Usually you'll only use like 1 hashtable for most of the map, and then just some extra for the spells. If you do find yourself creating them a lot, you can always just use FlushParentHashtable() on one-time use hashtables. (This will allow for one extra hashtable creation for each time you flush a hashtable, it is like destroying it)

A nice idea, but it (sadly) is a little less than functional.

 

[Bribe]

That's why I'm hoping that you'll be able to put parameters in a timer call in StarCraft 2... no need for hashtables for timer-based spells. Alternatively, they could figure out an exact-wait system.

 

[Mooglefrooglian]

That's why I'm hoping that you'll be able to put parameters in a timer call in StarCraft 2... no need for hashtables for timer-based spells. Alternatively, they could figure out an exact-wait system.

We already have that, and I even made my own system. Its not hard to attach data to timers!

People say using hashtables for maps are bad

What. That has got to be the stupidest thing I have ever heard. An O(1) search is *BAD*? >.>

 

[Bribe]

The whole point of this thread is to not use Hashtables. Which, as has been stated, it's impossible to achieve this in WC3. But please show me this Timer that takes non-hashtable parameters, or this system you've developed that doesn't use hashtables.

 

[Berb]

You and me, we have the same problem. You want to make a knock-back without using timers, and I want to make a car without using an engine.

Even if you're expecting an optimal return of 0.25 on your waits, do you have any idea how noticeable that will be to the eye? The variation will only make it look worse. Even a constant repetition every 0.04 seconds is noticeable, so there is no way that you're going to get it to work in any desirable fashion by using TriggerSleepAction.

 

[Bribe]

My wistful expectation was that the functions would produce movement at 0.26, 0.28, 0.30, etc.

gg

 

[Berb]

Also, all of the knock-back specifics (distance, time knocked back, etc.) would all have serious issues because TriggerSleepAction, while given a "constant" value, will not pause the thread for that specific amount of time, resulting in the unit probably being paused for far longer than necessary, without moving very far at all.

This is all of course in addition to the fact that you'll get random blips where TriggerSleepAction pauses for far more than the desired amount of time (0.25 could pause for 2 seconds) in which case the entire concept fails.

 

[Bribe]

random blips where TriggerSleepAction pauses for far more than the desired amount of time

Beautiful. I wonder why this function glitches so much...

 

[Teelo]

Its all about CPU cycles, processes, forks... Go take an architecture/kernel course