| 01-03-2007, 05:40 AM | #1 |
I've been doing some extensive testing in my map AotZ on a few specific heroes -- And it appears that a boolean expression just... Isn't properly picking some units on occasion. I can't really figure out why. It works a good 95% of the time, but on occasion it simply will not pick the proper units. It's totally bizarre, because I've seen this happen on occasion with other heroes as well. There's really no rhyme nor reason to when it happens or why it does. JASS:function Realignment_OnslaughtDrop_Check takes nothing returns boolean return IsUnitEnemy(GetFilterUnit(), GetOwningPlayer(udg_u_Kisrug)) and GetWidgetLife(GetFilterUnit()) > 0.405 and IsUnitType(GetFilterUnit(), UNIT_TYPE_GROUND) and GetUnitAbilityLevel(GetFilterUnit(), 'Avul') <= 0 endfunction I guess what this boils down to is this -- Are there any known bugs or issues with using Boolean Expressions? Or must it be an issue hidden in my code somewhere? |
| 01-03-2007, 05:45 AM | #2 |
IsUnitType needs to be compared to a value. http://www.wc3jass.com/viewtopic.php?t=2370 Anything of the Is natives that could have been implemented with bitflags, it's best to be careful and compare. |
| 01-03-2007, 05:51 AM | #3 |
Okay, so I should compare it to true and it will return properly in all cases? I suppose I should update every boolexpr in the map with that then. Hrmph, that doesn't sound pretty. And that post on wc3jass says I should compare any of the Is...() natives to true? So then... JASS:function Realignment_OnslaughtDrop_Check takes nothing returns boolean return IsUnitEnemy(GetFilterUnit(), GetOwningPlayer(udg_u_Kisrug)) == true and GetWidgetLife(GetFilterUnit()) > 0.405 and IsUnitType(GetFilterUnit(), UNIT_TYPE_GROUND) == true and GetUnitAbilityLevel(GetFilterUnit(), 'Avul') <= 0 endfunction |
| 01-03-2007, 05:57 AM | #4 |
IsUnitEnemy should be fine. IsUnitAlly has been reported broken, and while it's unconfirmed it seems likely to me. |
| 01-03-2007, 06:02 AM | #5 |
Fair enough. A final question though -- Is it normal that when doing BoolExprs as I was before that they would fail only a rather small percent of the time? Because they are not failing all of the time, only on occasion. Oh well, either way thanks tons. EDIT: I don't know if this means anything, but doing further testing I just discovered something very weird. My boolexpr above works in all cases except one -- When the unit that normally would be picked is walking. I'm 100% sure that that is when it doesn't work... But got me as to why not. Let me test it with this modification you suggested and I'll see what happens. |
| 01-03-2007, 09:52 AM | #6 |
I've found boolexprs to be buggy when existing for more than an instant, and giving really wierd results (different results in almost identicle circumstances, destroying a local in one thread destroying the local in a different thread, etc.). |
| 01-03-2007, 10:19 AM | #7 |
Dusk, you've just run into one of the mysteries of the WCIII coding engine. Bugs such as these appear in GUI boolean checks as well, and i've never yet managed to work out why. I've found (eventually) reproducable bugs in the checks for if a unit is an enemy, if a unit is an ally, if a unit is a hero, if a unit is a structure and several other unit type boolean checks, the bugs appear consistantly on multiple machines with both true and false checks. The % varies, but it's usually around 2 - 3% through the check for allies is up at the 73% mark. I have no idea why this happens, but sometimes the check bugs up and instead of returning the correct answer (true or false) it either returns the incorrect answer or nothing at all. I remember one of the testmaps checked to see if a footman was a hero once every .1 seconds and printed the response, i noticed that approximately 1 in 110 times it would return true instead of false or nothing at all (so it would print a blank instead of True or False.) I then made it print what unit it was running the check against, and for some odd reason whenever it bugged up and returned nothing, it returned a blank field as the unit. As far as i can tell from this result, sometimes when running a boolean check on unit type, the engine 'loses' the unit and returns nothing at all. I'm guessing it's another programming error. |
| 01-03-2007, 11:12 AM | #8 |
Actually I think this is a fairly straightforward bug. IsUnitType and apparently IsUnitAlly are implemented with bitflags. Warcraft does "unittype & checktype" to evaluate truth. This can get you true/false integers that are a power of two like 64. Unfortunately the Jass VM's conditional jump instructions don't reliably interpret values other than 0 or 1. The work around, comparison, works because == and != correctly treat non zero values as always true. Please test this for yourself by return bugging booleans to integers and vice versa. Remember to work around the inter-native type return bug bug by assigning values to variables after return bugging. Griffen your problems sound plain cranked out, I don't know what's going on there. |
| 01-03-2007, 12:13 PM | #9 |
The real issue is that boolexprs think that !=1 is false instead of thinking that !=0 is true otherwise these natives are no issue, when they are in if then elses or exitwhen . |
