[BUGFIX] Fixed Super Fang interaction with Multi Lens

[Bertie690]

RIP funny math formula, you will be missed.

What are the changes the user will see?

Super Fang and company now deal correct damage with multi lens (ie 50%), split between the appropriate amount of hits linearly.
For an example of how it works: The 1st hit of super fang with 2 lenses does (target.hp/2)*0.5=0.25*hp damage, leaving the enemy down to 75% hp after the first hit. The remaining 2 multi lens hits each get half the difference between the leftover (75%) and the target (50%) amounts, for 12.5% damage each.

Parental Bond works similarly, but it changes the target damage amount to 0.25 instead (the hp% the target would have left after 2 halvings).

Why am I making these changes?

BECAUSE I COULD.

What are the changes from a developer perspective?

Adds a check in TargetHalfHpDamageAttr.apply() for subsequent repeated hits that splits the damage of hits after the first one linearly to make them add up to the desired amount. The first hit is unaffected as the following strikes are intended to adjust for it appropriately.
Also adds a check in pokemon.ts to skip multiplying the move damage for the subsequent hits of such moves because they're already pre computed and I really don't want to deal with reciprocals...

Screenshots/Videos

oh god please no I'm not spending another hour filming these just for someone to tell me to refactor them 12 hours later

How to test the changes?

npm run test multi_lens
Check the last few tests at the end.
Alternately use the following overrides:

const overrides = {
  MOVESET_OVERRIDE: Moves.SUPER_FANG,
  STARTING_LEVEL_OVERRIDE: 1000,
  STARTING_HELD_ITEMS_OVERRIDE: [{ name: "MULTI_LENS", count: 2 }],
  OPP_LEVEL_OVERRIDE: 100,
  OPP_SPECIES_OVERRIDE: Species.BLISSEY,
  OPP_MOVESET_OVERRIDE: Moves.SPLASH,
} satisfies Partial<InstanceType<typeof DefaultOverrides>>;

and start a new game with a Koffing and literally any other starter without PB.

Checklist

• I'm using beta as my base branch
• There is no overlap with another PR?
• The PR is self-contained and cannot be split into smaller PRs?
• Have I provided a clear explanation of the changes?
• Have I considered writing automated tests for the issue?
• If I have text, did I make it translatable and add a key in the English locale file(s)?
• Have I tested the changes (manually)?
  • Are all unit tests still passing? (npm run test)
• Are the changes visual?
• Have I provided screenshots/videos of the changes?

[DayKev]

Seems fine to me (code-wise), just some style comments.

[innerthunder]

I'm not a fan of hard-coding the fixed damage values like this. We just updated Multi-Lens to reduce its tech debt, and this change feels like we're going backwards on that. Also, the balance team has made comments implying that Multi-Lens' maximum stack count is subject to change, and this change could potentially get in the way of that.

Some options that wouldn't increase tech debt:

1. We leave the interaction as is. This ultimately makes Multi-Lens a nerf to Super Fang's damage output, but obviously it would be the easiest option for devs.
2. We revert the changes from [Balance] Multi Lens damage reduction on fixed-damage moves #4896. This would probably make fixed-damage moves too overpowered, but would definitely make the Super Fang interaction more stable.
3. We restrict Multi-Lens' effect on all fixed-damage moves. I don't think players would enjoy this change, at least in the short term, but this restriction has been in place before, and it wouldn't be difficult to add.
4. We restrict Multi-Lens' effect on Super Fang, Ruination, and Nature's Madness. This would "fix" the interaction while preserving the interactions of other fixed-damage moves, but it wouldn't be very intuitive to the player (I could see some "bug" reports come from this one)

[DayKev]

We restrict Multi-Lens' effect on Super Fang, Ruination, and Nature's Madness. This would "fix" the interaction while preserving the interactions of other fixed-damage moves, but it wouldn't be very intuitive to the player (I could see some "bug" reports come from this one)

This is what I prefer tbh.

We leave the interaction as is. This ultimately makes Multi-Lens a nerf to Super Fang's damage output, but obviously it would be the easiest option for devs.

This would be fine too.

[Tempo-anon]

Appreciate the math and work done on this but will also echo the sentiment that hardcoding it is not the way to go

[Bertie690]

Thanks for the feedback everyone.
I do get the message (hardcoding = not future proofed = bad), but at the same time, I do think these hard coded values serve a purpose - as a "stopgap" fix that fixes stuff now and can be cleaned up later.
I can work on a cleaner implementation of this stuff later (likely using some sort of "target" damage tracker like pigeon-bar suggested), but frankly that can be a task for next week's me, not today's me.
(I'm just sharing my opinion FYI - feel free to pick it apart.)

[innerthunder]

Thanks for the feedback everyone. I do get the message (hardcoding = not future proofed = bad), but at the same time, I do think these hard coded values serve a purpose - as a "stopgap" fix that fixes stuff now and can be cleaned up later. I can work on a cleaner implementation of this stuff later (likely using some sort of "target" damage tracker like pigeon-bar suggested), but frankly that can be a task for next week's me, not today's me. (I'm just sharing my opinion FYI - feel free to pick it apart.)

I think when it comes to an open-source project where development is largely based on "best effort," it's generally best to avoid stopgap fixes when possible. The cleanup for "temporary" fixes tends to fall into low priority, so it's likely that a stopgap sticks around until it ends up causing problems itself.

[Bertie690]

I'll get started on reworking it then.

[frutescens]

Screenshots/Videos

oh god please no I'm not spending another hour filming these just for someone to tell me to refactor them 12 hours later

Approving - however, I do want to emphasize that even though providing screenshots/video proof is annoying and time-consuming, it is important and good practice to do so. The burden of proof is on the PR's creator... so please remember this in the future.