feat: add weapon bag input schema. #855

KingDarBoja · 2025-11-30T15:17:18Z

This fixes the wrongly DPS chart because we were missing the correct accessor for weapon bag props.

Summary by CodeRabbit

Refactor
- Reworked weapon data mapping for stricter typing and normalized range/scatter field shapes.
Chores
- Added comprehensive type definitions and re-exported them for broader availability; removed two now-obsolete exported constants.
Impact
- Stronger data validation, more consistent weapon configuration shapes, and more predictable behavior when reading weapon data.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

coderabbitai · 2025-11-30T15:17:29Z

Walkthrough

Added a comprehensive TypeScript weapon schema, refactored mapping to use those types and adjusted weapon range/scatter field paths and typings, and re-exported the new types from the unitStats entry.

Changes

Cohort / File(s)	Summary
New type definitions `src/unitStats/types.ts`	Added a comprehensive TypeScript definitions module exporting `WeaponClass` and `WeaponCategory` plus 40+ related types (e.g., `WeaponBagSchema`, `WeaponBag`, `Accuracy`, `Range`, `Scatter`, `Damage`, `Tracking`, etc.) modeling weapon/unit JSON schemas.
Mapping refactor `src/unitStats/mappingWeapon.ts`	Removed in-file taxonomy constants; imported `WeaponBagSchema`, `WeaponCategory`, `WeaponClass`. Tightened `weapon_bag` type to `WeaponBagSchema["weapon_bag"]`. Removed `weapon_class` fallback. Renamed `distance_scatter_object_min_hit` → `distance_scatter_obj_hit_min`. Mapped range fields from `weapon_bag.range.{...}` to `weapon_bag.range.distance.{near,mid,far}` and adjusted fallbacks.
Public re-export `src/unitStats/index.ts`	Added `export * from "./types"` to re-export the new types module from the package entry.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Verify updated paths: distance_scatter_obj_hit_min and range.distance.{near,mid,far} are consistent with incoming JSON and other modules.
Confirm callers handle absence of the previous weapon_class empty-string fallback.
Ensure the stricter WeaponBagSchema["weapon_bag"] typing doesn't break uses expecting looser shapes or optional fields.
Scan types.ts for any naming or optional/required mismatches that could affect runtime mapping.

Poem

🐰 I nibbled at types and stitched each line,
Ranges tucked in nests, enums feeling fine,
Scatter renamed, tidy paths in sight,
I hopped away happy in the soft moonlight,
Code carrots gathered — a small rabbit's delight 🥕

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat: add weapon bag input schema' accurately captures the main change—introducing a comprehensive TypeScript type definitions module for weapon bag schemas—though it understates the refactoring scope of mappingWeapon.ts.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch weapon-bag-type

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 80571c7 and e94cd09.

📒 Files selected for processing (1)

src/unitStats/mappingWeapon.ts (5 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

src/unitStats/mappingWeapon.ts (1)

src/unitStats/types.ts (1)

WeaponBagSchema (46-50)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

GitHub Check: Deploy Web Preview
GitHub Check: Build and run prettier

🔇 Additional comments (6)

src/unitStats/mappingWeapon.ts (6)

4-4: LGTM! Type imports improve maintainability.

Importing WeaponBagSchema, WeaponCategory, and WeaponClass from a central types file improves type safety and eliminates duplication.

162-162: LGTM! Strong typing replaces any.

Typing weapon_bag as WeaponBagSchema["weapon_bag"] enables compile-time checks and better IDE support.

164-180: Good fix: Normalization now happens before weaponData construction.

Moving the range normalization logic before building the weaponData object ensures that the normalized values are correctly reflected in the exported stats. This addresses the issue raised in the previous review.

293-305: LGTM! Range values consistently use normalized data.

All range-related fields now derive from the pre-computed rangeDistance object, ensuring consistency throughout the weapon stats.

322-322: The scatter field name is correct.

Line 322 correctly maps to weapon_bag.scatter?.distance_scatter_obj_hit_min, which is confirmed in the schema as a valid field. No issues found.

191-191: Verify that weapon_class is guaranteed to be present in WeaponBagSchema.

Line 191 assigns weapon_bag.weapon_class without a fallback. Confirm that the WeaponBagSchema type definition makes this field required (non-optional). If weapon_class can be undefined, add a fallback value.

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.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/unitStats/mappingWeapon.ts (1)

155-178: node: any type bypasses runtime validation—property access failures are possible with malformed JSON.

While typing const weapon_bag: WeaponBagSchema["weapon_bag"] = node.weapon_bag; provides editor support, the node parameter remains any. The isWeaponBagContainer predicate only checks that the first key is "weapon_bag" but does not validate the structure. If weapon.json contains malformed entries, accessing unguarded properties like weapon_bag.ui_name (line 167), weapon_bag.weapon_class (line 173), or weapon_bag.icon_name (line 168) will fail at runtime. Note the inconsistent use of optional chaining (e.g., weapon_bag.accuracy?.near vs. direct access to weapon_bag.ui_name).

Consider:

Narrowing the node type signature in the traversal callback, or

Adding lightweight schema validation before extraction (e.g., checking required fields exist and have expected types).

🧹 Nitpick comments (3)

src/unitStats/types.ts (1)

45-116: Schema wiring between WeaponBag, Range, and Scatter looks consistent; consider tightening a few loose ends later.

The new schema lines up cleanly with how mappingWeapon.ts consumes it (e.g., weapon_bag.range.distance.* and weapon_bag.scatter.distance_scatter_obj_hit_min). Using WeaponClass / WeaponCategory as as const arrays for string unions is a solid choice.

If you want to incrementally harden the model later, two low-risk options would be:

Narrow frequently boolean‑ish strings (e.g. "True"/"False") to string unions instead of bare string.

Replace some any[] fields that you actively consume (target_type_table, conditional_table, weapon_tags) with minimal shaped types once those structures stabilize.

These are non‑blocking and can be deferred.

Also applies to: 425-432, 443-464
src/unitStats/mappingWeapon.ts (2)
4-4: Good move centralizing weapon taxonomy in types.ts.

Importing WeaponBagSchema, WeaponCategory, and WeaponClass from a shared types module keeps the weapon model consistent across the codebase and avoids duplicate enum definitions.

316-329: Potential singular/plural typo in target_type_table path.

In this block you read from:

target_types.target_unit_type_multipliers?.unit_type

target_types.target_unit_type_multipliers?.base_damage_modifier

target_types.target_unit_type_multipliers?.weapon_multiplier?.*

but for damage_multiplier you switch to:

target_types.target_unit_type_multiplier?.weapon_multipliers?.damage_multiplier

Note the singular vs plural difference in both target_unit_type_multiplier and weapon_multipliers. If the underlying JSON only has the plural form (target_unit_type_multipliers.weapon_multipliers), damage_multiplier here will always fall back to 1.

Please double‑check the JSON structure and align this path; e.g., it might need to be:
damage_multiplier:
  target_types.target_unit_type_multipliers?.weapon_multipliers?.damage_multiplier || 1,
If you want to verify this across your current data, you could grep the raw JSON for both key shapes to confirm which one is actually present.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4b18c49 and 7e37b9a.

📒 Files selected for processing (2)

src/unitStats/mappingWeapon.ts (4 hunks)
src/unitStats/types.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

src/unitStats/mappingWeapon.ts (1)

src/unitStats/types.ts (1)

WeaponBagSchema (46-50)

🔇 Additional comments (1)

src/unitStats/mappingWeapon.ts (1)

300-305: Scatter distance mapping now matches the schema.

Using weapon_bag.scatter?.distance_scatter_obj_hit_min for scatter_distance_object_min aligns with the new Scatter type and should fix the missing accessor for that field.

coderabbitai · 2025-11-30T15:22:32Z

src/unitStats/mappingWeapon.ts

+  if (weapon_bag.range.distance.near === -1)
+    weapon_bag.range.distance.near = weapon_bag.range.min;
+  if (weapon_bag.range.distance.mid === -1)
+    weapon_bag.range.distance.mid = (weapon_bag.range.max - weapon_bag.range.min) / 2;
+  if (weapon_bag.range.distance.far === -1) weapon_bag.range.distance.far = weapon_bag.range.max;


⚠️ Potential issue | 🟠 Major

Move the range normalization block before constructing weaponData to ensure normalized values are reflected in exported stats.

The normalization code at lines 310-314 currently executes after weaponData is built (lines 265-277). Since numeric values are primitives copied by value in JavaScript, the already-constructed weaponData object retains the original values (which may be -1) and never sees the normalized values set later. This makes the normalization block ineffective for the DPS chart and other consumers of mapWeaponData.

Move the normalization block before the weaponData object literal, or compute effective distances into locals and use those in the assignment. Additionally, update the optional chaining (?.) calls to direct access after normalization, or maintain fallback logic explicitly if you expect entries to sometimes lack range data.

For the mid-range formula (weapon_bag.range.max - weapon_bag.range.min) / 2, confirm whether this represents the half-distance of the range span or should be min + (max - min) / 2 (the midpoint between min and max). This distinction affects DPS bucket placement.

🤖 Prompt for AI Agents

In src/unitStats/mappingWeapon.ts around lines 310-314 and the earlier weaponData construction (around lines 265-277), the range normalization currently runs after weaponData is built so normalized values never make it into the exported object; move the normalization block to before constructing weaponData (or compute effective distance locals like effectiveNear/effectiveMid/effectiveFar and use those in the weaponData assignment), replace optional chaining with direct property access after normalization (or keep explicit fallbacks if range may be missing), and if you intend the midpoint use min + (max - min) / 2 rather than just (max - min) / 2.

@KingDarBoja this seems like it makes sense right? We are changing weapon bag after we assign it to the weaponData, this code block should be before that ?

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

github-actions · 2025-11-30T15:27:17Z

🌐 Branch deployed as preview to:
https://coh3-stats-ih0fsayhk-cohstats.vercel.app

feat: add weapon bag input schema.

7e37b9a

KingDarBoja requested a review from petrvecera November 30, 2025 15:17

KingDarBoja self-assigned this Nov 30, 2025

KingDarBoja had a problem deploying to preview November 30, 2025 15:17 — with GitHub Actions Failure

missed exporting the types.

80571c7

KingDarBoja temporarily deployed to preview November 30, 2025 15:20 — with GitHub Actions Inactive

coderabbitai bot reviewed Nov 30, 2025

View reviewed changes

improvements to range distance

e94cd09

KingDarBoja temporarily deployed to preview November 30, 2025 16:56 — with GitHub Actions Inactive

petrvecera approved these changes Nov 30, 2025

View reviewed changes

petrvecera merged commit ddca47e into master Nov 30, 2025
6 checks passed

KingDarBoja deleted the weapon-bag-type branch November 30, 2025 17:15

coderabbitai bot mentioned this pull request Dec 9, 2025

fix: weapon dps for AT guns #860

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

feat: add weapon bag input schema. #855

feat: add weapon bag input schema. #855

Uh oh!

KingDarBoja commented Nov 30, 2025 •

edited by coderabbitai bot

Loading

Uh oh!

coderabbitai bot commented Nov 30, 2025 •

edited

Loading

Uh oh!

coderabbitai bot left a comment

Uh oh!

coderabbitai bot Nov 30, 2025 •

edited

Loading

Uh oh!

petrvecera Nov 30, 2025

Uh oh!

coderabbitai bot Nov 30, 2025

Uh oh!

github-actions bot commented Nov 30, 2025 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

feat: add weapon bag input schema. #855

feat: add weapon bag input schema. #855

Uh oh!

Conversation

KingDarBoja commented Nov 30, 2025 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

coderabbitai bot commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

Poem

Pre-merge checks and finishing touches

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrvecera Nov 30, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Nov 30, 2025

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

KingDarBoja commented Nov 30, 2025 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Nov 30, 2025 •

edited

Loading

coderabbitai bot Nov 30, 2025 •

edited

Loading

github-actions bot commented Nov 30, 2025 •

edited

Loading