feat(bcard): name the seven negated halves the client describes - #2372
feat(bcard): name the seven negated halves the client describes#2372denislauri1999 wants to merge 0 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. WalkthroughThe change adds seven negated ChangesBCardEffect negations
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This change only names seven existing card effects and updates their documentation; it does not alter runtime behavior or accepted values. No actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
421e33a to
31a8fad
Compare
BCard.datdeclares 24 (type, subtype) pairs thatBCardEffectdoes not name. Seven of themcan be read; this adds those seven and leaves the other seventeen alone.
Why these seven and not the rest. A pair's text lives in
LISTn-1/LISTn-2, where thesecond number is the high or the low half. For these seven the HIGH half has a client text and
the LOW half has none - so the low half is the negation of a sentence that is written down, not
a mechanic that has to be guessed. For the other seventeen the high half is mute too, and a name
there would be invented.
Why
Negatedand notIncrease/Decrease. Both conventions are already in the enum, andwhich one applies is decided by the text: where the client says "increased / reduced" the names
say Increase/Decrease (176 pairs), and where there is one sentence for both halves the low one
is
X+Negated(186 of 194, 96%). All seven high halves describe a CAPABILITY - "Allows youto use Full Moon skills", "Reveals hidden enemies within %s spaces" - and a capability is not
reduced, it is negated. The one pair in this shape that already has a name,
88/22Type88DecreaseDamageVsHiden, is Increase/Decrease because its high half names a magnitude("%s additional damage") - the same rule, applied to the one case that has one.
documentation/dat/BCard.dat.mdis updated in the same commit, soEveryEffectIsInTheVocabularyandEveryNamedRowMatchesItsEffectstay in step.What was tested, and how.
dotnet test test/NosCore.Parser.Tests --filter "FullyQualifiedName~BCardVocabularyTests&TestCategory!=OPTIONAL-TEST"- the two mandatoryvocabulary tests pass. The opt-in
EveryDeclaredEffectIsNamed, which the CI filter excludes,goes from 24 unnamed pairs to 17.
What was NOT tested. Nothing was played. These are enum members and a documentation table:
no code reads them yet, and this PR deliberately does not wire any behaviour to them. Whether
any of the seven should also DO something is a separate question.
Summary by CodeRabbit
New Features
Documentation