[vJASS] [Snippet] SuspendUnit

[IcemanBo]

Info

Sometimes it's not recommended to use the PauseUnit() function,
because it has some (usually) unwanted side effets like:

• Buffs/effects suspend.
• Orders are stored when paused, and fired on UnPause.
• Can screw up animations. (link)
• Unit does not accept PowerUpss, UnitAddItem returns true, but item is not picked up. (link)

But in some cases we might want need a good alternative which completly makes a unit unuseable.

Code

library SuspendUnit /* v1.1    By IcemanBo (credits to Maker for this method)

    Alternative for the PauseUnit() function without known side effects.
    A paused unit will be completly unuseable until unpaused.
    Unit's current order will be forgetten.
    
            API
          ¯¯¯¯¯¯
    function SuspendUnit(unit, boolean) returns nothing
    
    function IsUnitSuspended(unit) returns boolean
    
        
    Instructions:
   ¯¯¯¯¯¯¯¯¯¯¯¯¯¯

    After copying the library save the map and restart the editor.
    When done, then comment out the next line:*/
    
    //! external ObjectMerger w3a ANcl paus Ncl6 1 "defend" anam "Channel Pause" acat "" atat "" aher 0 alev 1 Ncl1 1 10000 aani "stand" aeat "" |

    globals
        private constant integer PAUSE = 'paus'
        private constant integer DEFEND = 852055
    endglobals
    function SuspendUnit takes unit u, boolean b returns nothing
        if (b) then
           call UnitAddAbility(u, PAUSE)
           call IssueImmediateOrderById(u, DEFEND)
        else
            call UnitRemoveAbility(u, PAUSE)
        endif
    endfunction
    function IsUnitSuspended takes unit u returns boolean
        return (GetUnitAbilityLevel(u, PAUSE) > 0)
    endfunction
endlibrary

Small test map is attached. (demo code is not up to date)

 

[Zwiebelchen]

Pause --> call SetUnitPropWindow(unit, 0)
Unpause --> call SetUnitPropWindow(unit, GetUnitDefaultPropWindow(unit))

 

[Kazeon]

Orders are stored when paused, and fired on UnPause.

Is this true? Will the unit ignore any order given when paused (only stores orders before pause)? I can use this for something if so.

Eh, sorry to ask here.

 

[PurgeandFire]

Pause --> call SetUnitPropWindow(unit, 0)
Unpause --> call SetUnitPropWindow(unit, GetUnitDefaultPropWindow(unit))

Can't they still turn?

 

[Almia]

Sometimes, moderators can't accept PauseUnit because of it's side effects. Actually there are some reasons why people still submit spells that use it :
1) to "control time". For example, the Chronosphere spell actually "stops the time", so this includes anything (Except for periodic spels) like animations and buffs. It is intended to be that way and I don't see a reason why Moderators always dump the Chronosphere spell if it has to be made that way in the first place.
2) Animations. If there is another way to pause an animation, that would be great.

About the SetUnitPropWindow, Units can still turn while having a PropWindow of 0. Also PropWindow returns radians afaik.

 

[Bribe]

Yes, units can still turn which is why I use PropWindow in Retro. This is a stun ability resource not a pause unit resource, am I right? Or which ability did you use?

 

[BPower]

So it's an alternative way to "pause" a unit. That's nice.

I think every method has it's ups and downs and you have to evaluate every case
different. PauseUnit for example has also some pros as it decreases computation time
for that unit. That's why we use it in dummy unit recycling snippets.

 

[Zwiebelchen]

2) Animations. If there is another way to pause an animation, that would be great.

call SetUnitTimeScale(u, 0) freezes any animation in place.

About the SetUnitPropWindow, Units can still turn while having a PropWindow of 0. Also PropWindow returns radians afaik.

If you don't want units to turn, you can always just stun them. There's so many stun snippets out there it's not even funny.

Also you can combine prop window with set unit turn speed.

 

[Almia]

call SetUnitTimeScale(u, 0) freezes any animation in place.

I didn't know about this one. Thank you, i should test it anytime soon.

 

[pred1980]

Pause -->

call SetUnitPropWindow(unit, 0)

Unpause -->

call SetUnitPropWindow(unit, GetUnitDefaultPropWindow(unit))

works perfect! No library needed!

 

[PurgeandFire]

@pred: it would be better to call that ensnare.

If you don't want units to turn, you can always just stun them. There's so many stun snippets out there it's not even funny.

Also you can combine prop window with set unit turn speed.

yeh, but then you can't set a unit animation, right? (idk, honest question)

 

[Zwiebelchen]

yeh, but then you can't set a unit animation, right? (idk, honest question)

You can; I've been using a stun snippet for years to effectively halt units while moving them around in knockback effects; animations play just fine; it's only that the stun effect itself plays the "stand" animation once. You just need to overwrite that.

 

[Almia]

I have a Dash system and I can say animations works fine, even orders afaik

 

[IcemanBo]

Stunning will probably end up in having the pretty same effect in "disabling" units. (have not really tested for differences)
But approach is mostly different. And here I don't care about durations, but just the state itself. Paused/Unpaused.
It's pretty straight forward. Some other suggestions in thread only disable movement behaviour of unit,
and en up in effects something like "ensnare" like has been said correctly by PnF.

 

[Zwiebelchen]

What happens if the unit has a regular defend ability? Will it change the state of the regular defend ability when it's used?
If so, then stunning would be superior to this.

 

[IcemanBo]

^No, it should not. Though I can't test it atm by myself, as I dont have wc3 installed. :/

 

[Zwiebelchen]

^No, it should not. Though I can't test it atm by myself, as I dont have wc3 installed. :/

I am pretty sure it does interfere with defend, as you can not change the order string of the defend ability and you just call call IssueImmediateOrderById(u, DEFEND) in your snippet.

Basicly, if you try your snippet on a footman, he will go into defend mode.

 

[Maker]

Also you can combine prop window with set unit turn speed.

With turn speed set to 0, units can still turn. They turn very slowly though.

 

[IcemanBo]

@Zwiebelchen, you can check out the demo.

 

[Bribe]

I recommend renaming this to SuspendUnit/IsUnitSuspended. I will test this later, put please make that change in lieu of likely approval.

 

[IcemanBo]

I have nothing against changing API to "suspend". Will change it, but maybe I just wait for now, maybe there is something else.

 

[Bribe]

OK, somehow it doesn't screw with units who have defend. It seems the WC3 engine prioritizes recently-added abilities when the order is given.

Please change the library name to SuspendUnit, then the functions to SuspendUnit and IsUnitSuspended. I will approve this then.

 

[IcemanBo]

Changed name.

 

[Kazeon]

(UnitRemoveAbility(u, PAUSE) and UnitAddAbility(u, PAUSE) and IssueImmediateOrderById(u, DEFEND)

Isn't it better to check ability's level than having three function calls.

GetUnitAbilityLevel(u, PAUSE) > 0

then comment out the next line@:*@/

No kissing around pls.

 

[Bribe]

Edit, never mind. I realize now what you're saying upon viewing the code again. IceMan, please update with that adjustment.

(UnitRemoveAbility(u, PAUSE) and UnitAddAbility(u, PAUSE) and IssueImmediateOrderById(u, DEFEND)

Isn't it better to check ability's level than having three function calls.

No, because if the unit doesn't have the ability UnitRemoveAbility returns false and the other 2 never get evaluated.

function F takes nothing returns boolean
    call BJDebugMsg("Test")
    return true
endfunction
function J takes...
    if false and F() then
...

You'll never see the BJDebugMsg.

 

[IcemanBo]

Yes, nice catch. Ty!
You don't like kisses? :*

Bribe, true, but if unit is paused it indeed will do more function calls.

 

[Bribe]

Approvéd

 

[edo494]

the magics of short circuit evaulations

 

[Bribe]

There are 3 issues which have been brought to my attention:

1) Silenced units cannot deploy this ability.
2) Stunned units will not issue this order until after the stun, so additional orders during the stun can override the infinite-channel ability.
3) Unlike with stuns, the order queue is emptied.

Looks like stuns are the best way to go.

 

[IcemanBo]

Thanks for this, Bribe!

Have you maybe tested if silence is somwhow in conflict with stun, too?
Could you maybe provide the map with demo code? Would simplify redo your tests.

That order queue gets emptied was known already.

 

[Bribe]

How would silence affect stun?

 

[IcemanBo]

GY this if stun is superior.

 

[Bribe]

Graveyarding due to latest information pointing out some important bugs with this resource.