Validate consumed tool item types#13
Conversation
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughItem schema gains item type and prefab metadata plus three def_index classification helpers (key, name tag, StatTrak swap tools). Inventory operations (UnlockCrate, ApplySticker, NameItem, NameBaseItem, PerformCounterSwap) use these helpers to replace assertion-based failures with logged validation, and CounterSwapStatus gains new failure enum values. ChangesSchema-backed inventory validation
Sequence Diagram(s)sequenceDiagram
participant Client
participant Inventory
participant ItemSchema
Client->>Inventory: PerformCounterSwap(toolId, weaponA, weaponB)
Inventory->>Inventory: Look up tool item
alt tool missing
Inventory-->>Client: ToolMissing
else tool found
Inventory->>ItemSchema: IsStatTrakSwapToolDefIndex(defIndex)
alt invalid tool
Inventory-->>Client: InvalidTool
else valid tool
Inventory->>Inventory: Check both weapons QualityStrange
alt not Strange
Inventory-->>Client: InvalidWeaponState
else Strange
Inventory->>Inventory: Check AttributeKillEaterScoreType == 0 for both weapons
alt missing counters
Inventory-->>Client: CounterAttributeAbsent
else score type mismatch
Inventory-->>Client: InvalidWeaponState
else valid
Inventory->>Inventory: Swap KillEater attribute values
Inventory-->>Client: Completed
end
end
end
end
Compact metadata: 4 files changed (+225/-17 lines), no public API removals; Related issues: None referenced in provided summaries. Related PRs: None referenced in provided summaries. Suggested labels: enhancement, validation, inventory Suggested reviewers: Maintainers familiar with Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
csgo_gc/inventory.cpp (1)
1761-1797: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate counter-detection logic for weaponA/weaponB.
The
AttributeKillEaterlookup and theAttributeKillEaterScoreType == 0lookup are each written twice (once per weapon), as two separate loops over the same attribute list. Consider extracting a helper, e.g.FindKillEaterAttribute(CSOEconItem &weapon, CSOEconItemAttribute *&attr, bool &hasScoreTypeZero), called once per weapon to combine both scans into a single pass and remove the duplication.♻️ Sketch of consolidated helper
+static bool FindKillEaterCounter(const CSOEconItem &weapon, const ItemSchema &schema, + CSOEconItemAttribute **outAttr) +{ + bool scoreTypeOk = false; + *outAttr = nullptr; + for (int i = 0; i < weapon.attribute_size(); ++i) + { + const auto &attr = weapon.attribute(i); + if (attr.def_index() == ItemSchema::AttributeKillEater) + *outAttr = const_cast<CSOEconItemAttribute *>(&attr); + else if (attr.def_index() == ItemSchema::AttributeKillEaterScoreType + && schema.AttributeUint32(&attr) == 0) + scoreTypeOk = true; + } + return scoreTypeOk; +}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@csgo_gc/inventory.cpp` around lines 1761 - 1797, The KillEater attribute lookup logic is duplicated for weaponA and weaponB, with separate passes over each weapon’s attributes for `AttributeKillEater` and `AttributeKillEaterScoreType == 0`. Refactor the repeated scanning in `inventory.cpp` into a shared helper around the existing `weaponA`, `weaponB`, `attrA`, `attrB`, `weaponAScoreType`, and `weaponBScoreType` logic so each weapon is processed once and both checks happen in a single loop. Call that helper for each weapon instead of keeping two near-identical blocks.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@csgo_gc/item_schema.cpp`:
- Around line 1341-1393: The key-tool check in ItemSchema::IsKeyToolDefIndex is
too broad because ItemInfoContains matches any substring containing “key”,
including unrelated prefabs like keychains. Update ItemInfoContains or
IsKeyToolDefIndex to use an exact match against the key tool’s prefab/type/name
identifier instead of substring matching, and keep the existing
ItemInfoByDefIndex lookup flow unchanged.
---
Nitpick comments:
In `@csgo_gc/inventory.cpp`:
- Around line 1761-1797: The KillEater attribute lookup logic is duplicated for
weaponA and weaponB, with separate passes over each weapon’s attributes for
`AttributeKillEater` and `AttributeKillEaterScoreType == 0`. Refactor the
repeated scanning in `inventory.cpp` into a shared helper around the existing
`weaponA`, `weaponB`, `attrA`, `attrB`, `weaponAScoreType`, and
`weaponBScoreType` logic so each weapon is processed once and both checks happen
in a single loop. Call that helper for each weapon instead of keeping two
near-identical blocks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 801cb8c4-210c-42e1-96a8-22b6d698ed10
📒 Files selected for processing (4)
csgo_gc/inventory.cppcsgo_gc/inventory.hcsgo_gc/item_schema.cppcsgo_gc/item_schema.h
1 participant
Summary
Validation
Summary by CodeRabbit