TRUE == FALSE

[phlinn]

I threw the following line into combat.lua and the message printed as soon as I entered combat.

if (TRUE == FALSE) then msg_print("Panic!")end

I originally found that unarmed() == TRUE was considered false. After further checking both TRUE and FALSE are treated as false values, but 'Not' of either one is treated as true. However, switching to lower true and false works as expected.

So (TRUE == FALSE) returns true, but (true == false) returns false.

[Variaz]

True and false are kind of messy actually... It's probably best to use the booleans without specifying True or False in conditions. Like:

if(variable == FALSE)

You should probably use this instead:

if(variable)

[phlinn]

for the time being i replaced all upper case true and false with their lowercase counterparts, because search and replace is a lot easier. you might want to do that with the official combat.lua. It is what was causing the disabling blows to fail, and there are a lot of checks for blocked == TRUE

[Variaz]

So it was a true/false problem that was causing the problem... thanks for finding it out. I'll be sure to try your suggestion!

[phlinn]

ok, i've cleaned up the py_attack_execute function in combat.lua a bit. Enabling correct handling of true and false let me find out that something I was fighting as a test had a 100% chance to block. This didn't seem right, but it seems that lots of creatures have a counter type of 17, with 100%. Should I hard limit the counter chance to 75?

[Variaz]

No. Counter Number 17 is a counter for melee and ranged attacks, and monsters with 17:100 have 100% to TRY to block melee and ranged attacks...but that does not mean they always succeed. Whether or not they succeed is based on a hit rate, as if the monster was trying to hit you. So the higher your AC, the lower the chances of the counter working.

Counter 21 is different, in that it's chance is a direct chance to block any hits with 100% accuracy. So A 21:25 counter would mean 25% to block the incoming attack. 21:100 means you will never hit the monster with a melee attack. Do not hard-code it to max 75... 100% may be what I want some monsters to have... *evil grin*

[phlinn]

Ahh, I missed the call to monster_hit_player, and needed to do a few more combat rounds of testing.

[phlinn]

I did some further testing in 0.2, and I reccomend placing the the following 2 lines in init.lua before loading the other modules.

FALSE=false
TRUE=true

otherwise, they are both nil instead of being booleans and 'if (nil)' evaluates as false. Alternately, replacing FALSE and TRUE with their lower case versions in each file would work as well.

This may reveal other bugs in the combat.lua, as certain sections will get evaluated that wouldn't before. For instance, it will actually be possible to backstab, and to use a high monk's disabling blows ability. No, I didn't explicitly check backstab, but I did check 'if (TRUE)' and it evaluated as false, so I see no way the backstab sections could occur as it is currently written. Disabling blows still have a problem with the way it sets speed and defense. Setting speed = hitrate - anything would be a rather large buff to the target.

[Variaz]

Hmmm, I didn't think about adding constants definitons in init.lua... thanks for the advice!