Elemental resistance, which the fold had no case for - #2307
Elemental resistance, which the fold had no case for#2307denislauri1999 wants to merge 3 commits into
Conversation
BCard type 13, "Changes elemental resistance": 561 declarations, 408 on items and 153 on cards, and the buff fold had no case for it. A resistance buff changed nothing. The four fields it feeds already exist on CombatStats and are already read in ComputeElementalDamage, as a percentage taken off the incoming elemental damage. Only the step that fills them was missing. Not to be confused with type 7 in the case below it: that is the attacker's element rate, this is the defender's resistance to it. "All elemental resistance" adds to each of the four rather than living in a fifth field. The damage step reads one resistance, chosen by the attacker's element, so a separate total would have to be remembered at every one of those reads. Unlike the types where the file repeats the same sentence in both slots, this one really does pair increase with decrease - "increased by %s" against "decreased by %s" - so X2 subtracts. Writing this on the buff fold rather than beside the equipment means the item half arrives with no further work: the worn pieces' BCards go through the same place. Two ways of getting it wrong were checked: "all" not reaching every element fails two tests, reading the decrease as an increase fails one.
|
Warning Review limit reachedNext included review available in 2 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
NosCoreIO#2305 inserisce il suo caso esattamente allo stesso punto di ancoraggio, e due inserimenti sulla stessa riga git non li sa fondere: chi li fonde entrambi si trova un conflitto su BattleStatsProvider senza che ci sia niente da decidere. Stesso codice, ancoraggio diverso. Nel file il caso resta accanto a Element, che e' dove ha senso leggerlo: uno e' il tasso elementale dell'attaccante, l'altro la resistenza di chi para.
Restavano la riga delle variabili locali e il blocco 'stats with': NosCoreIO#2305 aggiunge la sua riga esattamente dopo le stesse due, e git non fonde due inserimenti sullo stesso punto. Stesso codice, sopra invece che sotto. Le quattro resistenze finiscono anche in un posto piu' sensato del blocco, accanto alle altre difese.
|
Heads-up for whoever merges: this compiles on its own but not alongside another of my open PRs, and
I found it by merging all nine of today's branches onto a scratch branch: with those two lines fixed the lot builds at zero warnings and passes 983 tests. Pairwise |
1 participant
BCard type 13, "Changes elemental resistance" — 561 declarations, 408 on items and 153 on cards — and the buff fold had no case for it. A resistance buff changed nothing.
Almost everything needed was already there: the four fields exist on
CombatStatsand are already read inComputeElementalDamageas a percentage taken off the incoming elemental damage. Only the step that fills them was missing.Not to be confused with type 7 in the case just below it: that is the attacker's element rate, this is the defender's resistance to it.
Two notes:
Writing it on the buff fold rather than beside the equipment means the item half arrives with no further work, since the worn pieces' BCards go through the same place.
Checked by breaking it
"All" not reaching every element fails two tests; reading the decrease as an increase fails one.