Percentage attacks ignore elements, enemy types, etc.

[ohrrpgce-bugbot]

[bz#134]

Right now, attacks that set the target stat to some percentage of either its
current or maximum ignore elemental and enemy type bitsets. These should be
used the same as for any other attack. That is, the game should calculate
what damage would cause the stat to reach the given percentage, and then take
that damage and alter it according to its elements, etc.

From: msw188
Reported version: unknown
Operating system: Windows XP

[ohrrpgce-bugbot]

Comment author: @rversteegen

What do and don't we want to affect percentage attacks? Looking at inflict(),
the easy solution is the move the percentage select case block up above the
elementary modifiers, but that would bring alot of other logic.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I originally intended for percentage damage to ignore all other calculation (if
I had been ambitious enough I would have greyed-out other options in the editor
when it was on)

But I think allowing elemental and enemy-type modifiers to be applied after the
percentage is calculated is okay. I would not expect this to break existing
games, since why would you set an elemental effect on a percentage attack
anyway, unless you expected it to work?

The only thing I would think of is some special cases where people are using
elementals for something other than elementalsd (fake battlescripting?) Can
anyone envision a scenario where changing the percentage behaviour would break
existing games?

[ohrrpgce-bugbot]

Comment author: msw188

It's been a while, and no one has mentioned any possible break with existing
games. I can't think of any. I think that all logic should be included that
would be included for a 'pure damage' attack, except for taking a potential
damage of zero and converting it to one. It is also questionable whether the
attack should be affected by caps or not (increasing someone's defense beyond
their normal level, etc). These things may break existing games. It is
unfortunate, since we have bitsets that allow these things, which would allow
for maximum flexibility...

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

My suggestion for this one is to add a new attack bitset, which when turned on,
allows elemental modifiers to affect percentage damage. If turned off, the
percetages would remain as they are.

[ohrrpgce-bugbot]

Comment author: msw188

I was thinking about this one again the other night, and wondering what ought and ought not to affect the damage incurred. One thing I realized was that both the 'cure instead of harm' attack bitset and the 'harmed by cure' enemy bitset could cause some confusion with the damage algorithm. Then again, it would be nice to have 'harmed by cure' support for these attacks...

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I was thinking about this one again the other night, and wondering what ought
and ought not to affect the damage incurred. One thing I realized was that
both the 'cure instead of harm' attack bitset and the 'harmed by cure' enemy
bitset could cause some confusion with the damage algorithm. Then again, it
would be nice to have 'harmed by cure' support for these attacks...

The behavior ought to be documented.

1. If the attack's "Cure instead of harm" bit is one, the damage becomes negative
2. If the enemy has the "Harmed by cure" bit on, the damage is forced positive again

[ohrrpgce-bugbot]

Comment author: @rversteegen

Here's my opinion (implemented via the bug bz⁠#625 fix not affecting % setting attacks): that "set stat to % of current/maximum" attacks are special, and should be immune to bits like cure, which would have unexpected affects. You can do nearly everything you would want to with the "damage by % of current/maximum" type instead of manipulating this bitset, and for everything else, there ought to be battlescripting/better damage options instead. For example, to set and enemy to 0% hp and absorb that damage (like in bug bz⁠#108), use "damage 100% of current hp" rather than "set 0% of current hp"

I'll sneak in my opinion that the design of the battle system editors is flawed, because features should be implemented with dynamic self-documenting menu options, not bitsets.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I agree with the position that set to % is a special case to which cure, zombie, absorb should not apply. Anyone who is trying to use those bitsets with set % attacks is probably confused about how set % attack work, and they really want damage % attacks not set % attacks.

I'll sneak in my opinion that the design of the battle system editors is
flawed, because features should be implemented with dynamic self-documenting
menu options, not bitsets.

I concur. We could actually move things out of the bitset menu on a case-by-case basis wherever it makes sense to.

And the storage doesn't even need to change. We can just exclude a particular bitset from the bitset menu, and add a different interface to the same data bit in another part of the menu.

I have some long-term plans for an editor-interface-editor that I need to get up on the wiki...

[ohrrpgce-bugbot]

Comment author: @rversteegen

I agree with the position that set to % is a special case to which cure,
zombie, absorb should not apply. Anyone who is trying to use those bitsets with
set % attacks is probably confused about how set % attack work, and they really
want damage % attacks not set % attacks.

I'll sneak in my opinion that the design of the battle system editors is
flawed, because features should be implemented with dynamic self-documenting
menu options, not bitsets.

I concur. We could actually move things out of the bitset menu on a
case-by-case basis wherever it makes sense to.

And the storage doesn't even need to change. We can just exclude a particular
bitset from the bitset menu, and add a different interface to the same data bit
in another part of the menu.

Great.

I have some long-term plans for an editor-interface-editor that I need to get
up on the wiki...

Wow, I wasn't expecting that. How would this work, by generating binary data that can be embedded and interpreted inside Custom? Or BASIC code?

Also, where I said in comment 7

"to set and enemy to 0% hp and absorb that damage (like in bug bz⁠#108),
use "damage 100% of current hp" rather than "set 0% of current hp" "

I guess I meant elemental absorb bitsets, the absorb bitset is still OK (but might damage the attacker if you heal the target, just like absorb+cure does). Actually, using the absorb bitset and "set 0% of current hp" does as you would expect, you steal the HP - Yuriy just tested it.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I have some long-term plans for an editor-interface-editor that I need to get
up on the wiki...

Wow, I wasn't expecting that. How would this work, by generating binary data
that can be embedded and interpreted inside Custom? Or BASIC code?

It would be a separate executable (probably called editedit.exe) which would store information on menu layout and menu-to-data-mapping in a binary file (which would be checked in with the source, but not distributed with custom) and it would output basic code that would be #include'ed into whichever menu.

I envision the code that it outputs being similar to the flexmenu code (though perhaps better)

[ohrrpgce-bugbot]

Comment author: msw188

I'm sorry that I only partially understand what has been said. If I read this right, turning on the bitset "% attacks damage instead of cure" means that all other bitsets work too? But not using that bitset means that all other bitsets are ignored?

To make an attack that sets a stat to 75% of the max, but is less effective on certain enemies, you are saying I should do the following?

atk damage = 25% of max of stat
bitset: % attacks damage instead of set
bitset: reset stat to max before inflicting damage
bitset: effect elemental (and then make certain enemies resist the effect element)

[ohrrpgce-bugbot]

Comment author: @arperry

You can already do this, sort of. Suppose you have two attacks, one chaining to the other. They both do the same thing (say, set speed to 80%) but the second fails against earth resistance. Non-resistant targets would have their speed cut twice, resistant targets would be affected only once.

[ohrrpgce-bugbot]

Comment author: @rversteegen

I'm sorry that I only partially understand what has been said. If I read this
right, turning on the bitset "% attacks damage instead of cure" means that all
other bitsets work too? But not using that bitset means that all other bitsets
are ignored?

No, because this bug isn't fixed yet. However, "reset target stat to maximum before hit" does work. As far as I can tell, the differences between normal and % based attacks are that % based attacks ignore: atk and defense stats and formula, elemental+enemy type strong/weak/absorb (but not failure!), randomise damage, allow 0 damage, divide spread damage. Cure and harmed by cure affect 'damage instead of set' only.

Of these, which do we want to potentially affect % based ('damage instead of set') attacks? How about all of them: we could have "% of target's current " and "% of target's maximum " as new damage base stats (with preferably potentially different stats from the actual target stat!). That's a big difference though, it would be simplest and most logical to actually add a new Base ATK Stat. But then what do we do with the old bitset?

(Opps. Done to confusion, we made elemental absorption happen on % based damaging attacks. I'll fix that immediately.)

I envision the code that it outputs being similar to the flexmenu code (though
perhaps better)

But does flexmenu really allow presenting much abstraction from the data? I think we'd need things like data 84 = 3 and bitset X = off and data 84 = 3 and bitset X = on being two different options for some menu item.

[ohrrpgce-bugbot]

Comment author: @bob-the-hamster

I have been thinking about this, and I feel that % damage ignoring elementals is not a bug.

The bug is that the attack editor interface is confusing, and doesn't make the behavior very easy to guess.

Also (I haven't tested this yet but I am pretty sure that) elemental modifiers are applied when the bitset is turned on to damage by percentage instead of set by percentage.

[ohrrpgce-bugbot]

Comment author: @rversteegen

Also (I haven't tested this yet but I am pretty sure that) elemental modifiers
are applied when the bitset is turned on to damage by percentage instead of set
by percentage.

They aren't. In either case, elementals have no effect.

[ohrrpgce-bugbot]

Comment author: @rversteegen

I have been thinking about this, and I feel that % damage ignoring elementals
is not a bug.

The bug is that the attack editor interface is confusing, and doesn't make the
behavior very easy to guess.

Yes, and that interface is now fixed, making the rest of this a feature request.

we could have "% of target's current
" and "% of target's maximum " as new damage base stats (with
preferably potentially different stats from the actual target stat!).
That's a big difference though, it would be simplest and most logical to
actually add a new Base ATK Stat. But then what do we do with the old bitset?

This is the feature request. But we now have this as of Beelzebufo: you can select "target's max/current " as a base stat, and use "Extra damage" to get a certain percentage of that, with whatever other normal attack modifiers you want. So I think this can now be closed.