Invalid redirection treated as 0

[Orden4]

Describe the bug

Was recently made aware of a patch of mine malfunctioning on Ikemen. I pretty quickly found the culprit to this part:

[State ]
type = nothitby
trigger1 = !ishelper
trigger1 = helper(2519),rootdist x = [-75, 75]
trigger1 = movetype != H
value = SCA

I know, I should've checked whether the helper exists first, but I hadn't really gotten into the swing of suppressing debug output when I made him. Anyway, I figured this bug could easily be present on tons of characters when used on Ikemen, so I decided to make a bug report.

To Reproduce

1. Download this character: https://www.mediafire.com/file/g5m0db7qud1reua/SAS_ForceAI.rar/file
2. Start a match, note that he is permanently unhittable unless he uses his lvl 3 super mine and moves away from the mine.

Expected behavior

In mugen, trigger1 = helper(2519),rootdist x = [-75, 75] will evaluate as false when that helper does not exist.

Screenshots / Video

No response

Engine Version (or source code date)

v0.99-rc.2

Operating system

Windows

Extra context or search terms

No response

[potsmugen]

Interesting. I wonder if Ikemen even has the concept of "bottom" as found in Mugen. Every one of those cases I tried seems to just evaluate to 0, which can lead to bugs like that.

In Mugen helper(2519),rootdist x = [-75, 75] is evaluated as bottom = [-75, 75] which returns bottom (false) In Ikemen helper(2519),rootdist x = [-75, 75] is evaluated as 0 = [-75, 75] which returns 1 (true)

Seems like a relatively big difference in logic handling.

[Orden4]

I did some further testing on this front, and actually it seems that the range comparison is actually the only weird one. I tested everything that I could think of on mugen 1.1a4, and the results were as follows (x = an invalid redirection, i.e., helper(2519),rootdist x, n = any number)`:

FALSE:

• x = [-n, n]
• x > 0
• x < 0
• x != 0
• x * n
• x / n
• x % n
• x ** n

TRUE:

• x = 0
• x != [-n, n]
• x >= 0
• x <= 0
• x + n
• x - n
• x = x (also if they're different invalid redirections)
• n ** x

Besides that, for boolean operators it acts identically to false. Anyway, all of them are actually in-line with it evaluating to 0, except for the range operator stuff. Even if you do something like x = [-2147483648, 2147483647] it will still be false, so clearly there's just some hardcoded behaviour here that circumvents the entire operation.

Also, there is one other ultra cursed one, but that I think is safe to ignore lol. The ultra cursed one is x ** 0 or x ** x (same result). This seems to just randomly be true or false, although if you display it to clipboard it always outputs 1696948. I kind of suspect that it's somehow ending up parsing pointers or other random bits of memory, although frankly I haven't the faintest idea.

[potsmugen]

Wolf_Stak just noticed that treating invalid redirections as 0 is how things worked in Winmugen. That probably explains why Suehiro had it like that.

So I guess the concept of bottom would be cool to have (like Mugen 1.0 and 1.1), but it's not as important as expected.