Untargetable/win if alive enemies not giving gold + XP

I'm testing a system to make defeated enemies transmog themselves into a non-attacking, untargetable KO'ed version of themselves instead of just disintegrating or crossfading, but are considered dead for all intents and purposes. Just to add some style and flavor to battle presentation. I did this by making their On Death Bequest Attack a self-targeted no damage attack that transmogrifies themself to their KO'ed version.

When I tested it, the transmog worked as planned and the battle ended when all 3 copies of the monster were killed. But the battle just ended without displaying any rewards. I checked, and there was no gold or XP in the status window either.

Is this working as intended or is it a bug? Also I put the same rewards on both the alive/normal and KO'ed version of the enemy just in case it might be considering either one to be dead. But it would seem that neither the alive or KO'ed version rewards get taken into account.

I would imagine it's working as intended, because they're transmogrifying into an untargetable form: IE, they're not actually dying? There might be a bitset or something to give rewards for stuff that respawns on death, but I think the idea is like... if you have a slime enemy that only "dies" for real if you target it with a fire attack, you don't want the guy to get a billion items from killin it some other way.

It would seem that way. I'm guessing that enemy rewards aren't added to the end of battle loot until their death animation plays out fully. Here, the transmog happens very fast, before the death animation finishes. That might be the reason why the enemy isn't considered dead, even though its hit points get depleted and even starts to play a death animation.

If I want to take this to the next step I'll probably need to try using on-death spawning instead of On Death Bequest. I get the feeling that might be complicated presentation-wise; the KO'ed version might spawn somewhere totally different than the enemy that just got killed.

Maybe have them on-death-bequest themselves into their "dead" forms, but also set that attack up with an element that triggers the spawning of an invisible, 0 HP (dies instantly) enemy which drops the money/experience/items you would get from that enemy at the same time?

Relying on spawning for the dead enemy sprites to show up could get messy pretty quick--like you mentioned, you could have enemies jumping into different positions on death (spawned enemies will go straight into the first empty slot, and a dying enemy's slot isn't emptied until it's completely faded off the screen) and stuff like that.

---

FYS:AHS -- Swapping out some step-on NPCs for zones + each step script
Puckamon -- Not until the reserve party is expanded.[/size]

Right, death sound effects don't play and rewards aren't given until after the death animation plays, but having an on-death bequest attack causes that to be delayed, and the transmogrification then prevents the death from happening at all.

One solution would be to always pay out rewards immediately on death before doing the on-death attack. Would that break anything? A less simple alternative is to add an option (to the enemy or to the attack?) to pay out the enemy reward when you transmogrify an enemy, rather than those reards being destroyed.



The death animation starts to play before it's cancelled by the on-death bequest attack? That sounds like an engine bug to me.

Hmm... I can imagine "instant rewards before on-death transmogrification" possibly causing problems if people want to set things up certain ways, though I can't think of any examples off the top of my head...

Maybe have it as a general bitset ("give rewards immediately on death" or something like that) so people who want/need that behavior can have it, and those who'd rather have enemies wait until their death animations have played fully before giving rewards can have that?

Speaking of that, having an option to make the death sound effect play immediately when the death animation starts (rather than waiting until it ends) would be a nice random little feature. I'm reminded of how most (all?) NES/SNES RPGs had their "death sound" play simultaneously with the animation.

---

FYS:AHS -- Swapping out some step-on NPCs for zones + each step script
Puckamon -- Not until the reserve party is expanded.[/size]

Hmm, that bitset might be a better idea than my suggestions. It could be called "Pay death rewards before on-death bequest attack". If it really is necessary to have a bitset at all. It's better not to add more confusing bitsets that only apply in corner cases, if possible.

You're right, the death sound should be played at the start of the animation (but still delayed until after the on-death attack).

If I get what you're saying right TMC, are you suggesting adding that as a bitset into a future nightly or stable release? If so that'd be awesome!

Also I'm on vacation this weekend but if you'd like me to send you an upload of my game's current state so you can see what it looks like (the enemy starting to play its death animation before transmogrifying), I can do that on Monday.

A use would be to have an on-death bequest attack conditionally wipe the rewards of an enemy (say, based on an tag).IF you wanted to do this, it would be a lot more direct to use the "Erase Rewards" attack bit rather than to do a transmogrification. And you could always do both. So I feel that on-death transmogrification wiping rewards is more of an unwanted side effect.

Theoretically it's possible for me to scan the game lists for games where changing this would make a difference, but it's far safer and less work to add a bitset, so that's what I'll do.

Thanks, a testcase for that would be great.