Perfect IsUnitAlive

[Viikuna]

Getting the manacost of abilities is no problem actually.
Since those are static values, you can just build some database to get those values.


But some natives for manipulating manacost and cooldown would indeed be nice...

 

[Rushhour]

yep that can be done ofc, but when you keep changing the values to balance things out.. then it gets stupid. You can also have some "system" like checking the manaamount at spellbegin and checking at spellend but there are some more problems like channeling spells,...
We have to live with what he have
happy mapping

Edit: Found some strange stuff 0o:
Simple testing result in this:

• Custom script: set udg_SellGold=(3/4)*GetUnitGoldCost(GetUnitTypeId(GetTriggerUnit()))
  • Custom script: call BJDebugMsg(I2S(udg_SellGold))

always results in 0

• Custom script: set udg_SellGold=GetUnitGoldCost(GetUnitTypeId(GetTriggerUnit()))
  • Custom script: call BJDebugMsg(I2S(udg_SellGold))

displays the correct amount 0o
--> multiplications work well, but as a division like (1/2)* or (3/4)* .. is in front of it, I always get 0. I also tried some R2I(I2R(...)) or simply R2I(..) ! This is... stupid 0o

 

[Nestharus]

Actually, my guide has a complete list of working natives from common.ai... Chapter 9 Natives

http://www.thehelper.net/forums/showthread.php?t=137090


That list was compiled after testing each and every native in common.ai to see which one's worked and which one's didn't (well, most of them, a lot of it was just logic on my part ^_^).

I used to just have that list for myself, but when I wrote the guide I put it in there. I made that list when I wrote Stock (previously known as Gcsn).

 

[Jesus4Lyf]

In plain JASS, the deprecated set keyword is used (makes it easier to see)

Ahh, all the reasons I'm glad that's in GY.

So this native fails to detect removed units immediately, and that's it only flaw?

 

[Nestharus]

I believe the reason for the RemoveUnit bug is that it cleans up memory on an interval, so the memory isn't cleaned up until the end of the interval.

What this means is that if you remove a unit that is alive, it'll still be in memory while your code is running.


Now, to fix this you could make a unit dead whenever you remove a unit by overriding the native with a definition.

 

[Jesus4Lyf]

>Now, to fix this you could make a unit dead whenever you remove a unit by overriding the native with a definition.
You've gotta understand that this is silly. The only situation UnitAlive returns true for a removed unit is straight after removing it. ...
... meaning you know it's not alive, lol. Probably, 0.0 seconds after, you would find it counts as dead. In what situation would this be a problem?

 

[Nestharus]

>You've gotta understand that this is silly. The only situation UnitAlive returns true for a removed unit is straight after removing it. ...
... meaning you know it's not alive, lol. Probably, 0.0 seconds after, you would find it counts as dead. In what situation would this be a problem?

You might be using a resource that runs on a custom event. You remove a unit and then you run it or w/e and the resource runs whether the unit is alive or dead, so the resource doesn't know what you did.

Here's an example-

native UnitAlive takes unit id returns boolean

scope Demo initializer Initialization {
    private unit u
    private trigger t = CreateTrigger()

    private bool Test() {
        if UnitAlive(u) {
            printf("Alive")
        }
        else {
            printf("Dead")
        }
        return false
    }
    
    private void Testing() {
        u = CreateUnit(Player(0), 'hpea', 0, 0, 0)
        RemoveUnit(u)
        TriggerEvaluate(t)
    }
    
    private void Initialization() {
        TriggerAddCondition(t, Condition(function Test))
        TimerStart(CreateTimer(), 2, true, function Testing)
    }
}

Now, I can't even think of something where this might happen, but we all know how some people are ^_-. Where I think something may sound ludicrous, like the above, someone else might think it's the greatest idea ever, lol.

Only possible thing I can think of that encounters a scenario similar to this uses timers, so this bug wouldn't even occur ><.

Example-

native UnitAlive takes unit id returns boolean

scope Demo initializer Initialization {
    private unit u
    private trigger t = CreateTrigger()
    private timer repeat = CreateTimer()
    
    private bool Test() {
        if UnitAlive(u) {
            printf("Alive")
        }
        else {
            printf("Dead")
        }
        return false
    }
    
    private void Testing() {
        u = CreateUnit(Player(0), 'hpea', 0, 0, 0)
        RemoveUnit(u)
        TimerStart(repeat, 0, false, function Test)
    }
    
    private void Initialization() {
        TriggerAddCondition(t, Condition(function Test))
        TimerStart(CreateTimer(), 2, true, function Testing)
    }
}

 

[Narks]

scope TheGame 

function IsUnitAlive takes unit u returns boolean
    if UnitAlive(u) and GetUnitTypeId != 0 then
        return true
    endif
    return false
endfunction

endscope

 

[Azlier]

More research. Get this.

call RemoveUnit(RAZELLE)
if GetUnitTypeId(RAZELLE) == 0 or IsUnitType(RAZELLE, UNIT_TYPE_DEAD) then
    call BJDebugMsg("DEAD")
endif

Does not display dead.

call RemoveUnit(RAZELLE)
if GetWidgetLife(RAZELLE) <= 0.405 then
    call BJDebugMsg("DEAD")
endif

Does not display dead.

So, in fact, all the methods share that one flaw of a unit not being dead immediately after removal.

 

[Narks]

fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

hook RemoveUnit

and do stuff



On another note, how does Jesus get like JASS highlighting without quote box?

 

[Sevion]

[noparse][ljass]stuff[/ljass][/noparse]

 

[Narks]

[ljass] that is cool [/ljass]

Anyway, I guess UnitAlive is pretty good.

 

[Jesus4Lyf]

So I guess that's why someone once told me ages ago that you should always kill units before removing them, and I did so ever since... :nuts:
And I mean maybe 5-6 years ago.

 

[Narks]

I know that you should always kill destructables before removing them, because else an incoming projectile on a removed destructable would crash - maybe the same applies for units?

 

[Tru_Power22]

More research. Get this.

call RemoveUnit(RAZELLE)
if GetUnitTypeId(RAZELLE) == 0 or IsUnitType(RAZELLE, UNIT_TYPE_DEAD) then
    call BJDebugMsg("DEAD")
endif

Does not display dead.

call RemoveUnit(RAZELLE)
if GetWidgetLife(RAZELLE) <= 0.405 then
    call BJDebugMsg("DEAD")
endif

Does not display dead.

So, in fact, all the methods share that one flaw of a unit not being dead immediately after removal.

I don't know why this is surprising. Your not technically killing the unit when you remove it.

Makes sense to me.

 

[Azlier]

It's dead 0 seconds after the trigger finished running though.

 

[Nestharus]

Well, RemoveUnit not displaying dead also makes 100% perfect sense to me. GetUnitTypeId with it also makes perfect sense as it's not cleared from memory yet : \.


I explained that-

What this means is that if you remove a unit that is alive, it'll still be in memory while your code is running.

: P

It's dead 0 seconds after the trigger finished running though.

Not really right to say that. It's dead at the end of while loop. Old style games like wc3 generally run on an infinite while loop.

Hell, newer games that are indie still run on infinite while loops, haha. Look at XNA.