[Bug?] Remove Death Status and "Target Dead Party Member" Intertwined

[C-Dude]

So I was playing around with spell options in FF3usme and I encountered what I believe to be a bug with removing "Death" status.

If you set a spell to heal, don't force it to retarget if dead, and set the spell to remove death status...

>When cast on a living target, it behaves as expected, restoring the health amount.
>When cast on a dead target, the caster steps forward, no animation plays, and nothing happens.

Normally I'd assume such a scenario is intended behavior, because there aren't any spells in Final Fantasy games that both heal and revive.  However, the lack of animation is what leads me to believe this is a bug... shouldn't this sort of thing result in a 'miss'? Or a display of 0 healing?


I bring it up because I've been playing with the Magitek list and I was going to make Healing Force both heal and remove death, as if any of your party dies in the intro there's absolutely no way to resurrect them.  Has anyone else run into this when doing magic edits?

[assassin]

iirc, it's "Can target only living entities" and "Miss (Dead XOR Undead) entities" that get tied together.  also iirc, this is just for normal attacks/spells, so well-timed pre-queued items can do things like removing Stone from a Petrified enemy.

it seems intentional to me.  they derive one property from another for spells.  in contrast, i think Item's code checks for certain, terminal statuses being marked to be lifted, and will create an exception in the property.  i believe that's necessary because Items lack the expansive ROM data bytes possessed by attacks/spells.

a more robust way (for spells) would be to find a free spell data bit, and let one of the properties be directly configurable by it.

[C-Dude]

iirc, it's "Can target only living entities" and "Miss (Dead XOR Undead) entities" that get tied together.  also iirc, this is just for normal attacks/spells, so well-timed pre-queued items can do things like removing Stone from a Petrified enemy.

it seems intentional to me.  they derive one property from another for spells.  in contrast, i think Item's code checks for certain, terminal statuses being marked to be lifted, and will create an exception in the property.  i believe that's necessary because Items lack the expansive ROM data bytes possessed by attacks/spells.

a more robust way (for spells) would be to find a free spell data bit, and let one of the properties be directly configurable by it.

I've looked into it further, and you're correct.  It must be intentional, because vanilla Life 3 has this same property.  If you que it up to protect a near-fatal ally and they fall before you cast it, then the white magic intro triggers but no animation follows.  If it DID, then Life 3 would work like Life 1 on dead targets (which isn't necessarily a bad thing, but I don't think that's what they wanted).

I guess because Magitek doesn't have the casting intro like white magic does, my making it target like that made the situation look glitchy.

So not a bug, but maybe something that could be addressed with a special spell effect (similar to Quake targeting?), having said effect check for and remove death first and then apply healing.

Thanks for the info.  I think I'll scrap the idea for now; it would have caused confusion anyway, since other healing spells wouldn't work in the same manner.  When I look into replacing "Zombie" status with the monster's Undead status, maybe I'll revisit this.