Snippet AutoFly

[Azlier]

This simple, efficient script makes it so that [lJASS]SetUnitFlyHeight[/lJASS] automatically works on the units in your map. It should be more efficient than adding and removing Crow Form each time a spell is cast.

// AutoFly - by Azlier
//  Requires a vJass preprocessor

// How to import:
//  1. Create a new trigger called AutoFly.
//  2. Convert the trigger to custom script, and replace all the code inside with this.

library_once AutoFly

private function Actions takes nothing returns boolean
    return UnitAddAbility(GetFilterUnit(), 'Amrf') and UnitRemoveAbility(GetFilterUnit(), 'Amrf')
endfunction

private struct Hack extends array

    static method onInit takes nothing returns nothing
        local region r = CreateRegion()
        local rect re = GetWorldBounds()
        local group g = CreateGroup()
        local integer i = 15
        call RegionAddRect(r, re)
        call TriggerRegisterEnterRegion(CreateTrigger(), r, Filter(function Actions))
        call RemoveRect(re)
        set re = null
        
        loop
            call GroupEnumUnitsOfPlayer(g, Player(i), Filter(function Actions))
            exitwhen i == 0
            set i = i - 1
        endloop
        call DestroyGroup(g)
        set g = null

    endmethod

endstruct

endlibrary

AIDS version. Credit goes to kenny!.

Spoiler

// AutoFly - by Azlier, AIDS version by Jesus4Lyf
//  Requires a vJass preprocessor, AIDS

// How to import:
//  1. Create a new trigger called AutoFly.
//  2. Convert the trigger to custom script, and replace all the code inside with this.
//  3. Import AIDS if it is not in your map already.

library AutoFly requires AIDS
    private struct Hack extends array
        private static method AIDS_filter takes unit u returns boolean
            return UnitAddAbility(u, 'Amrf') and UnitRemoveAbility(u, 'Amrf')
        endmethod
        //! runtextmacro AIDS()
    endstruct
endlibrary

Non-vJass version.

Spoiler

// AutoFly - by Azlier

// How to import:
//  1. Create a new trigger called AutoFly.
//  2. Convert the trigger to custom script, and replace all the code inside with this.

function AutoFly__Actions takes nothing returns boolean
    return UnitAddAbility(GetFilterUnit(), 'Amrf') and UnitRemoveAbility(GetFilterUnit(), 'Amrf')
endfunction

function InitTrig_AutoFly takes nothing returns nothing
    local region r = CreateRegion()
    local rect re = GetWorldBounds()
    local group g = CreateGroup()
    local integer i = 15
    call RegionAddRect(r, re)
    call TriggerRegisterEnterRegion(CreateTrigger(), r, Filter(function AutoFly__Actions))
    call RemoveRect(re)
    set re = null
        
    loop
        call GroupEnumUnitsOfPlayer(g, Player(i), Filter(function AutoFly__Actions))
        exitwhen i == 0
        set i = i - 1
    endloop
    call DestroyGroup(g)
    set g = null

endfunction

 

[Romek]

Why do you need a custom ability for something like this?

Also, this won't work on units created in struct initializers, so I suggest you initialize this in struct too.

private function Init takes nothing returns nothing
    local trigger t = CreateTrigger()
    local region r = CreateRegion()
    call RegionAddRect(r, GetWorldBounds())
    call TriggerRegisterEnterRegion(t, r, Filter(function Actions))
endfunction

Could be:

private function Init takes nothing returns nothing
    local region r = CreateRegion()
    call RegionAddRect(r, GetWorldBounds())
    call TriggerRegisterEnterRegion(CreateTrigger(), r, Filter(function Actions))
endfunction

 

[Troll-Brain]

It does not work on units created outside of the map area

True.

But, you can't create units outside the map area, even the playable map area
Only SetUnitX/Y can do that.
So your function MakeUnitFlyable is useless.

This trigger can so fire several times for the same unit, but anyway i think i'm the only one crazy dude witch do that

 

[Azlier]

>But, you can't create units outside the map area, even the playable map area

Yay! I'll remove it right away.

>Why do you need a custom ability for something like this?

It avoids strange bugs.

Making changes...

 

[Troll-Brain]

Instead of delete the line, comment the object merger line is a better option.

 

[Azlier]

Indeed it is. But that requires more brain power to get pretty much the same result.

 

[Troll-Brain]

Yes. If only humans were less ... humans.

I guess this is fine like it, to preserve users from themselves.

 

[Romek]

> It avoids strange bugs.
Such as?

 

[Azlier]

Adding and removing Storm Crow form will break Druids of the Talon.

You need a check to prevent that, and this beats that in efficiency.

 

[Romek]

And [ljass]if UnitAddAbility(...)[/ljass] wouldn't work?
It probably takes more time loading that ability at map init than the time you save between using a new ability in the actual map.

 

[Troll-Brain]

Personally i would define/hook the function CreateUnit.
It would be irrelevant compare to the time required of the unit creation by itself.
In this way i'm sure it won't have unneeded enter region events fired.

If you wonder why the hell i put some units outside the whole map, check this link :
http://www.wc3c.net/showpost.php?p=1106773&postcount=70

Anyway i don't really care about it, since i already use it like that, i just wanted to give my opinion.

Hmm, i haven't played with the "chaos" abilities because of the issues, i simply leave the unit specific event leak and don't recycle units, except dummies ones , but does this still work with such units ?

 

[Azlier]

Alright. Make two maps with two versions of this, one with Storm Crow, the other with the dummy ability. Give them the same name, and put them in the Maps folder at random. Can you tell which is which from inside Warcraft?

>but does this still work with such units ?

Excellent question. I'll test that.

 

[Troll-Brain]

Uhh ...

Just forget what i've said about the hook/define, usually, units are not only created with the native function CreateUnit :banghead:
They can be trained, bought, summoned, built ...

 

[Azlier]

It works on Chaosed units. Yay.

A unit morphing via Chaos doesn't fire the event again, as expected.

 

[Troll-Brain]

A unit morphing via Chaos doesn't fire the event again, as expected.

I didn't wanted to mean that.
I mean, you can still change the flying height of a not flying unit after the unit have gotten a chaos ability?
In other words, the flying bug is still valid, or you have to add/remove the ability one more time ?

 

[Azlier]

Just a useless bit of info. I placed a footman, gave it Siege Engine chaos, ordered it, and set flying height.

Wait a minute. I forgot to wait until the footman fully changed form. Hold on.

EDIT: Works flawlessly.

 

[Troll-Brain]

Good.
I'm with Romek though, just use UnitAddAbility as a boolean.

 

[Azlier]

If that's what you want. Sigh.

 

[Romek]

> Can you tell which is which from inside Warcraft?
No. Which is exactly why you should just do what I said instead of using object merger to create an ability (which can then be a nuisance), increase the map size (both insignificantly and unnecessarily), and make the user have to delete the line.
Yes, you may be thinking "Oh noes, big deal". Though notice that all of that is completely unnecessary.

As for making Azlier change this snippet just because you move the occasional unit outside the map area, I think that's pointless.
The event firing again does no harm. And I can assure you that the vast majority of users will not be moving units so far outside the map.

 

[Azlier]

FYI, it's already been changed to use Crow Form.