IFAT; IFAF issues

@Agro hacked up some pretty fast events for an asm condition for me to test out, and I found out what I figured to be a sneaking suspicion that I had had before.

Talk_Event:
IFAT 0x30 <my asm condition>
TEX1 0x84B
REMA
ELSE 0x31
ENIF 0x30
ITGC <Character> <Cool Item>
ENIF 0x31
ENDA

Names removed to keep privacy for @Agro in case it’s need or something; idk, but they’re not relevant.

So I made this just for testing purposes to make sure my routine sucks and not the events:

.thumb
mov r0, #0x1
bx lr

For those of you who don’t even know a bit of assembly, this is the equivalent of saying “Always True”.
So I insert it into the ROM and… I get the cool item. Sweet. I mean, no, not sweet; why is it following the false condition on a true return?

My point is this, I think the IFAT and IFAF conditions are mislabeled; if IFAT triggers the if-conditioned-commands when the routine returns false. Could anyone peer-review this and make sure I’m not just going crazy? Is it supposed to work this way?

I’ve definitely run into some funky shit like this before where flipping between IFAF and IFAT gave me what I wanted but I couldn’t possibly point out when specifically because it seems to go either way. Perhaps @Arch could shed some light on his experiences?

Bump, anyone else wanna confirm/refute this? Is the EA std lib just messed up? Should it be fixed?

I don’t think I’ve ever used IFAT or IFAF, but if the issue is a simple mixed up label, I say it should be deemed as such. Might well fix it.

…Where did this get solved?

Once upon a time the conditions for IFET (IF EventID True) and IFEF (if false) were swapped, so it might be possible? @Nintenlord? I summon thee perhaps?

I don’t know how I wouldn’t have noticed this - it seemed to work fine for me? Might just depend on how the routine’s being written? I dunno.

I fixed this