IsUnitType bug fixed or not ?

08-10-2009, 08:01 PM

I've never saw this bug, but it seems IsUnitType could return an invalid boolean if you don't use with == true/false in a boolexpr.

JASS:

library IsUnitTypeBug initializer bug

globals
    private constant unittype WHICH_UNITTYPE = UNIT_TYPE_STRUCTURE
    private constant integer VALID_UNITID = 'htow' //townhall
    private constant integer INVALID_UNITID = 'hfoo' //footman
endglobals

private function Conditions1 takes nothing returns boolean
    return IsUnitType(CreateUnit(Player(0),VALID_UNITID,0.,0.,0.),WHICH_UNITTYPE)
endfunction

private function ExecutedOrNot1 takes nothing returns nothing
    call BJDebugMsg("test 1 valid")
endfunction

private function Conditions2 takes nothing returns boolean
    return not IsUnitType(CreateUnit(Player(0),INVALID_UNITID,0.,0.,0.),WHICH_UNITTYPE)
endfunction

private function ExecutedOrNot2 takes nothing returns nothing
    call BJDebugMsg("test 2 valid")
endfunction

private function bug takes nothing returns nothing
    local trigger bug1 = CreateTrigger()
    local trigger bug2 = CreateTrigger()
    
    call TriggerRegisterPlayerEventEndCinematic(bug1,Player(0))
    call TriggerAddCondition(bug1, Condition(function Conditions1))
    call TriggerAddAction(bug1,function ExecutedOrNot1)
    
    call TriggerRegisterPlayerEventEndCinematic(bug2,Player(0))
    call TriggerAddCondition(bug1, Condition(function Conditions2))
    call TriggerAddAction(bug1,function ExecutedOrNot2)
    
    if TriggerEvaluate(bug1) then
        call TriggerExecute(bug1)
    endif
    
    if TriggerEvaluate(bug2) then
        call TriggerExecute(bug2)
    endif
endfunction

endlibrary

I've tested this assumption with this code and it works fine.
So do you remember that it failed "randomly", or in other words, works perfectly most of the time with the same code, and suddenly fail for an unknown reason ?

Or was it in some particular cases and always failed with the same code ?

08-10-2009, 08:19 PM	#2
Captain Griffen	It was particular cases. Which, I cannot remember.

08-10-2009, 08:31 PM	#3
Troll-Brain	Found a link : http://www.wc3jass.com/viewtopic.php?t=2370 And indeed it fails with UNIT_TYPE_TOWNHALL. So is it necessary to always add == true for all unittypes with wc3mapoptimizer ?

08-10-2009, 08:37 PM	#4
Rising_Dusk	Who cares if it is? Vex's optimizer replaces the IsUnitType bugged-cases with the working method anyways.

08-10-2009, 08:38 PM

Troll-Brain

Quote:

Originally Posted by Rising_Dusk

Who cares if it is? Vex's optimizer replaces the IsUnitType bugged-cases with the working method anyways.

In fact it was more if blizzard read this and fix it in the future patch (we can dream, can't we ?)

08-10-2009, 08:39 PM

Rising_Dusk

Quote:

Originally Posted by Troll-Brain

(we can dream, can't we ?)

I'm with ya' on that. I still want a GetPointZ function so we can phase out locations altogether.

08-10-2009, 08:44 PM	#7
Troll-Brain	But for this we can use a global location with MoveLocation, fair enough, no ? Also is it true that this function can return different values for each player, depends their graphic options ? I've tried it with the lowest possible, and a friend with the highest possible, and it seems we get the same values (both did screenshots). I used a shockwave ability or such.

08-10-2009, 08:47 PM	#8
Anitarf	This reminds me, I should update SpellEvent to finally get rid of GetSpellTargetLoc. :) Edit: Troll-Brain: As far as I know, GetLocationZ is synced as long as you don't use terrain deformations (either with triggers or with spells; animated walkable destructables can be an issue, too).

08-10-2009, 08:53 PM

Troll-Brain

Quote:

Originally Posted by Anitarf

Edit: Troll-Brain: As far as I know, GetLocationZ is synced as long as you don't use terrain deformations (either with triggers or with spells; animated walkable destructables can be an issue, too).

I used a spell like i said and it seems we were getting the same value, but i used R2S, instead of R2SW, so only 3 digits, i don't know if it does matter or not.

But it's good to know.

08-10-2009, 09:00 PM	#10
Toadcop	no it does return different values 100%. well terrain deforms are crap anyway.

08-10-2009, 10:55 PM

#11

Karawasa

Quote:

Originally Posted by Toadcop

well terrain deforms are crap anyway.

Yup. Great way to cause a ton of lag.

08-11-2009, 08:01 AM	#12
Troll-Brain	But we can hope it won't, if we use spells which create deformations. @Toadcop : So even if there is not any deformation it can return different values for each player ? If it's true that makes me sad ...

08-11-2009, 09:38 AM

#13

Toadcop

Quote:

@Toadcop : So even if there is not any deformation it can return different values for each player ?

no it can't usualy ofc... it will, if you create "localy" walkable destructable... which is possible. (they also cause performance hits btw i mean walkable destructables)

08-11-2009, 12:17 PM

#14

Karawasa

Quote:

Originally Posted by Troll-Brain

But we can hope it won't, if we use spells which create deformations.

Carrion Swarm = Shockwave except without deformation. That may help someone somewhere, it sure did for me.

08-11-2009, 06:08 PM

#15

Troll-Brain

On-Topic :

UNIT_TYPE_HERO -> (should) work

EDIT : UNIT_TYPE_DEAD -> (should) work

UNIT_TYPE_STRUCTURE -> (should) work

UNIT_TYPE_FLYING -> require the ==boolean thing in order to (probably) work properly

UNIT_TYPE_GROUND -> (should) work

UNIT_TYPE_ATTACKS_FLYING -> (should) work

UNIT_TYPE_MELEE_ATTACKER -> (should) work

UNIT_TYPE_RANGED_ATTACKER -> (should) work.

UNIT_TYPE_SUMMONED -> (should) work only inside an if/then block

I don't how to test the unittype UNIT_TYPE_GIANT

UNIT_TYPE_STUNNED doesn't seems to wok at all, at least not on summoned stunned units, and was bored to test for the other unittypes, feel free to check them.

@Toadcop : Well, it's pretty obvious ...

@Karawasa : Interesting but it seems it has no problem with hardcoded abilities which make deformations.