Weird Lua misbehavour - what am I missing here?

[Iocun]

All right. I have the following bit of code somewhere:

Code: [show] | [select all] lua

if (vitals.health>=oldhealth) and not ((vitals.health==vitals.maxhealth and vitals.mana==vitals.maxmana) or paracelsus.afflicted("blackout") or parry.succeeded or paracelsus.hit_avoided) then
		paracelsus.illusionDetected = true
		para.note(string.format("Damage check failure (Health: %i -> %i).", oldhealth,vitals.health), "red")
end

If you're wondering what para.note executes, it's a simple echo, really:

Code: [show] | [select all] lua

para.note = function (message, color_arg)
	local color = color_arg or "grey"
	cecho("\n<grey>><"..color..">"..message.."\n")
end

Now, if I read through that first if, I read that as long as vitals.health is smaller than oldhealth, the if will always execute as false and not execute, right?

Then how could this happen:

1614[ ], 3967(99%), 100%, 99% cexkdb 10.8%-(19:57:18.111)
Mioswen swings a gleaming scimitar at you with all her might.
Lightning-quick, Mioswen jabs you with a gleaming scimitar.
888[-726], 3967(99%), 100%, 99% cexkdb 10.8%-(19:57:18.254)
>Damage check failure (Health: 1614 -> 888).

Obviously, by that "Damage check failure" echo, at the point this fired my oldhealth was 1614 and vitals.health was 888. How then could the if be evaluated to "true"? (Which it seems it did.)

I had no errors in the error view, and this is the only script I have that echoes such a "Damage check failure".

The only way I could see this happening is if either vitals.health or oldhealth changed its value after the if but before the para.note. Is there any way this could happen? (vitals.health is updated via a gmcp event, by the way.)

P.S. This issue only comes up very rarely, at seemingly random moments, making it very hard to reproduce.

[tsuujin]

At a glance, my first thought is that your if structure is very complex and thus difficult to read and interpret. It might simply be that there's a loophole in the large NOT section we're not seeing. You could clean up the code a little bit to eliminate that possibility.

Code: [show] | [select all] lua

function isIllusion()
    if vitals.health < oldhealth then return false end
    if vitals.health == vitals.maxhealth then return false end
    if vitals.mana == vitals.maxmana then return false end
    if paracelsus.afflicted("blackout") then return false end
    if parry.succeeded then return false end
    if paracelsus.hit_avoided then return false end
    return true
end

if isIllusion() then 
    paracelsus.illusionDetected = true
    para.note(string.format("Damage check failure (Health: %i -> %i).", oldhealth,vitals.health), "red")
end

note: this is hacked out code, to provide an example. You'd need to check over the logic of it to make sure I got it right. I know it makes for more lines of code, but it's much simpler to read and debug which is more important in my opinion... and you could always combine a few of those lines safely if you wanted.

[Vadi]

Yeah, it is pretty puzzling:

Code: [show] | [select all] lua

> =false and not true
false
> return false and not false
false
> 

It's not possible for the value to change, I don't think between the check and the note happening. The only explanation I have is that by accident, both are strings?

Code: [show] | [select all] lua

> return ("888") >= ("1614")
true
> 

What you could do it add a non-intrusive way to debug this - before your if statement, add an echoLink with a small value that echoes embedded values plus the outcome of the boolean (don't use this in a tooltips, old ones will have the wrong info, have it echo to the screen instead when you click it).

[Iocun]

Ooh, I think you got it Vadi. I didn't even know you could use > and < on strings, so I assumed that if they were strings I would have got an error, so I didn't look into that much further. Turns out I was wrong! They are indeed strings.

Well, they were strings, since obviously I fixed that now!

Wasn't an issue anywhere else in my system, since everywhere else I use them with some mathematical operators that coerce them into numbers.

This also explains why the issue only came up in a few specific situations, i.e. whenever my health went from four digits to three, or from three to two. Might have noticed that if I had looked more carefully.

@tsuujin: Yeah, you're right, I could write it in a slightly more readable way. Although it -is- more easily readable in my Mudlet than on these forums, since Mudlet doesn't break up the condition into several lines, which makes it more cryptic here.

[Vadi]

Good stuff!