[Snippet] AutoFly (UnitIndexer Version)

[Nestharus]

This resource has moved here.

--

gone

 

[Bribe]

Module inits, le sigh. In Luck, it would look like this:

lib AutoFly(UnitIndexer):
    onInit:
        EVENT_ANY_UNIT_INDEXED.register(Filter(lambda bool:
            if GetEventUnit().addAbility('Amrf'):
                GetEventUnit().removeAbility('Amrf')
        ))

Enough propaganda, approved!

 

[Magtheridon96]

I did something close to this in some thread a few days ago ^^
Yours is better :/

 

[Troll-Brain]

That is typically the kind of script which sould be done by each user and not submitted as a resource.

In example i've personnaly create a custom CreateUnit function which make each unit created flyable and index it.

 

[Nestharus]

Not everyone knows this algorithm...

It's like sometimes I try to find an algorithm online and there will be 0 tuts on it... it'll be like, everyone knows it, but nowhere is it explain. Doesn't that drive you crazy as well?

Also, this is just a cnp into a map to make everything work, nothing special necessary =). Using a custom CreateUnit function means that you have to change all CreateUnit calls in every resource you might be using to use your own CreateUnit function.

 

[Troll-Brain]

Not everyone knows this algorithm...

I meant it's pretty easy to inline, also i think it's obvious for most of us.
And for the others this script is good as an exemple.

It's like sometimes I try to find an algorithm online and there will be 0 tuts on it... it'll be like, everyone knows it, but nowhere is it explain. Doesn't that drive you crazy as well?

As i say it's good as an example.

Also, this is just a cnp into a map to make everything work, nothing special necessary =).

It requires your library UnitIndexer.

Using a custom CreateUnit function means that you have to change all CreateUnit calls in every resource you might be using to use your own CreateUnit function.

Not hard, you can even do that with a simple text editor.
But i'm agree it's a personnal thing.

 

[Nestharus]

There's a non UnitIndexer version and an AIDS version at TH under that thread I linked.

 

[Troll-Brain]

There's a non UnitIndexer version and an AIDS version at TH under that thread I linked.

You take it too much for you, my point is that you can inline it easily for your map, that's all.
Sometimes some scripts should be just inlined.

 

[Magtheridon96]

library AutoFly /* v1.0.0.0
                    -Credits to Azlier for original
                    -thehelper.net/forums/showthread.php/139729-AutoFly
*************************************************************************************
*
*   Makes SetUnitFlyHeight possible
*
*************************************************************************************
*
*   */uses/*
*   
*       */ UnitIndexer /*           hiveworkshop.com/forums/jass-functions-413/unit-indexer-172090/
*
************************************************************************************/
    private function i takes nothing returns boolean
        if UnitAddAbility(GetIndexedUnit(),'Amrf') then
            return not UnitRemoveAbility(GetIndexedUnit(),'Amrf')
        endif
        return false
    endfunction
    private module Init
        private static method onInit takes nothing returns nothing
            call RegisterUnitIndexEvent(Condition(function i), UnitIndexer.INDEX)
        endmethod
    endmodule
    private struct Inits extends array
        implement Init
    endstruct
endlibrary

This way, it's slightly faster

 

[Bribe]

It would be slower because then you have to evaluate the boolean of unitaddability instead of just calling it.

 

[Nestharus]

ehhh, I don't know which one would be faster, but the dif in speed between them is so marginal that it doesn't even matter >.>. The fact that I can't even tell which one is faster is proof of that, lol.

 

[Troll-Brain]

ehhh, I don't know which one would be faster, but the dif in speed between them is so marginal that it doesn't even matter >.>.

Speed freak redemption.

The fact that I can't even tell which one is faster is proof of that, lol.

Or not, coz it's mostly because you don't know it xD.

 

[Magtheridon96]

Looks like some we need some Benchmarks

edit
The speed difference would be about ~0.0001 seconds

 

[Nestharus]

Ok.... and which one was faster

 

[Magtheridon96]

I said "would be about". I didn't say "is"
I'll do the benchmarks when I have time ... Or maybe someone else could

 

[Bribe]

Opening thread.

I think Magtheridon96 wants you to do this:

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

 

[Magtheridon96]

Actually, this:

private function i takes nothing returns boolean
    return UnitAddAbility(GetIndexedUnit(), 'Amrf') and UnitRemoveAbility(GetIndexedUnit(), 'Amrf') and false
endfunction

That way, it always returns false

 

[Bribe]

That's useless, the return value doesn't matter.

 

[Magtheridon96]

But returning true would make the VM check for any queued triggeractions to execute :/

 

[Bribe]

Telling the VM to interpret "and false" undoubtedly takes more time than for it to internally check if a stack is empty. Seriously. JASS is at least a hundred times slower than the program that interprets it.

Not to mention writing "and false" is a waste of a developer's time, consumes map space, and a waste of our time discussing it.

 

[ScorpioT1000]

private function i takes nothing returns boolean
    return UnitAddAbility(GetIndexedUnit(), 'Amrf')...) and UnitRemoveAbility(GetIndexedUnit(), 'Amrf')
endfunction

is something like that:

call	_Z14UnitAddAbilityv
testb	%al, %al
je	.L4
call	_Z17UnitRemoveAbilityv
testb	%al, %al
je	.L4
movl	$1, %eax
jmp	.L5

.L4:
movl	$0, %eax

.L5:
popq	%rbp

.LCFI8:
.cfi_def_cfa 7, 8
ret

when

private function i takes nothing returns nothing
    call UnitAddAbility(GetIndexedUnit(), 'Amrf')...)
    call UnitRemoveAbility(GetIndexedUnit(), 'Amrf')
endfunction

is like

pushq	%rbp

.LCFI6:
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq	%rsp, %rbp

.LCFI7:
.cfi_def_cfa_register 6
call	_Z14UnitAddAbilityv
call	_Z17UnitRemoveAbilityv
popq	%rbp

.LCFI8:
.cfi_def_cfa 7, 8
ret

still no difference? mathing jass handle processing it's assembly is much more bigger than above

 

[Bribe]

Scorpio, you need an if/endif block in your second code. Otherwise it errors if the unit already had that ability.

 

[Magtheridon96]

The code takes advantage of the short-circuiting JASS has for Boolean expressions

(The support is not perfect, as bugs can be found in the precedence when you start to use more complex expressions with (or, and, not) all combined, but parentheses fix all of that)

 

[Bribe]

Mag, I haven't run into those issues even without parenthesis. Is there some test that I missed?

 

[Magtheridon96]

Consider true or true and false.

You'd expect true and false to evaluate first making the whole expression evaluate to true because AND should have higher precedence than OR, but in JASS, it appears that they evaluate from left to right. I never noticed this before because I used parentheses to structure boolean expressions that mix different operations.

In JASS, the entire expression returns false.

Even though this seems to be the spec because JASS has no spec and thus the implementation is the spec in itself, I hate this so much and thus I consider it a bug just like how I consider raw pointers in C++ a bug. They are a pest I tell you

 

[LeP]

Consider true or true and false.

You'd expect true and false to evaluate first making the whole expression evaluate to true because AND should have higher precedence than OR, but in JASS, it appears that they evaluate from left to right. I never noticed this before because I used parentheses to structure boolean expressions that mix different operations.

Nope i wouldn't expect this. Maybe i'd expect other languages to behave the way jass does? Wouldn't that be as valid?
Why should and have higher precedence than or? Most of the time parentheses are a good thing b/c every operator is strange to us except +- and */ since we learned them forever.
Maybe it's a bug-fix if it forces you to write easier to comprehend code?

Even though this seems to be the spec because JASS has no spec and thus the implementation is the spec in itself, I hate this so much and thus I consider it a bug just like how I consider raw pointers in C++ a bug. They are a pest I tell you

Muh feelings. I don't like this therefore it's a bug
I'm not a fan of writing call b4 every call-statement in jass yet i don't consider it a bug.

---

Look, i don't even care if and and or have the same precedence or not. But this totaly doesnt't matter. It's a small annoyance for people thinkging every language should be alike or which take too much focus on syntax.
One could argue that precedence itself is bad and throw all that away. You can do some quite cool stuff when you throw away syntax.

 

[Magtheridon96]

Muh feelings. I don't like this therefore it's a bug.
I'm not a fan of writing call b4 every call-statement in jass yet i don't consider it a bug.

Your definition of bug is not mine.

 

[LeP]

Your definition of bug is not mine.

That's fortunate, isn't it?