feat: all server-side metamorphosis levels #716

Sainan · 2025-01-04T21:19:08-08:00

Sainan commented

2025-01-04 21:19:08 -08:00

#288

coderabbitai[bot] commented

2025-01-04 21:19:13 -08:00

(Migrated from github.com)

Walkthrough

The pull request introduces modifications to the infestedFoundryController in the Infested Foundry system, focusing on experience points (XP) handling and recipe management. The primary changes involve updating the addInfestedFoundryXP function to return an array of ITypeCount objects, which represent recipe changes triggered by XP thresholds.

The controller now supports more comprehensive tracking of recipe changes across different modes: consuming items, subsuming warframes, rushing subsume, and invigorations. The modifications enhance the API's ability to communicate recipe unlocks and changes that occur as XP is accumulated.

A new method handleSubsumeCompletion has been added to the controller, which manages recipe changes related to warframe subsumation. Additionally, changes in the upgradesController enhance inventory management during upgrade operations, while the inventoryService refines error handling and validation. The purchaseTypes file has been updated to include the new InfestedFoundry type within inventory changes, further expanding the data structure capabilities.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Generate unit testing code for this file.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai generate unit testing code for this file.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and generate unit testing code.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

## Walkthrough The pull request introduces modifications to the `infestedFoundryController` in the Infested Foundry system, focusing on experience points (XP) handling and recipe management. The primary changes involve updating the `addInfestedFoundryXP` function to return an array of `ITypeCount` objects, which represent recipe changes triggered by XP thresholds. The controller now supports more comprehensive tracking of recipe changes across different modes: consuming items, subsuming warframes, rushing subsume, and invigorations. The modifications enhance the API's ability to communicate recipe unlocks and changes that occur as XP is accumulated. A new method `handleSubsumeCompletion` has been added to the controller, which manages recipe changes related to warframe subsumation. Additionally, changes in the `upgradesController` enhance inventory management during upgrade operations, while the `inventoryService` refines error handling and validation. The `purchaseTypes` file has been updated to include the new `InfestedFoundry` type within inventory changes, further expanding the data structure capabilities.      --- Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? <details> <summary>❤️ Share</summary> - [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai) - [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai) - [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai) - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code) </details> <details> <summary>🪧 Tips</summary> ### Chat There are 3 ways to chat with [CodeRabbit](https://coderabbit.ai): - Review comments: Directly reply to a review comment made by CodeRabbit. Example: - `I pushed a fix in commit <commit_id>, please review it.` - `Generate unit testing code for this file.` - `Open a follow-up GitHub issue for this discussion.` - Files and specific lines of code (under the "Files changed" tab): Tag `@coderabbitai` in a new review comment at the desired location with your query. Examples: - `@coderabbitai generate unit testing code for this file.` - `@coderabbitai modularize this function.` - PR comments: Tag `@coderabbitai` in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples: - `@coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.` - `@coderabbitai read src/utils.ts and generate unit testing code.` - `@coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.` - `@coderabbitai help me debug CodeRabbit configuration file.` Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. ### CodeRabbit Commands (Invoked using PR comments) - `@coderabbitai pause` to pause the reviews on a PR. - `@coderabbitai resume` to resume the paused reviews. - `@coderabbitai review` to trigger an incremental review. This is useful when automatic reviews are disabled for the repository. - `@coderabbitai full review` to do a full review from scratch and review all the files again. - `@coderabbitai summary` to regenerate the summary of the PR. - `@coderabbitai generate docstrings` to [generate docstrings](https://docs.coderabbit.ai/finishing-touches/docstrings) for this PR. ([Beta](https://docs.coderabbit.ai/early-access#beta)) - `@coderabbitai resolve` resolve all the CodeRabbit review comments. - `@coderabbitai configuration` to show the current CodeRabbit configuration for the repository. - `@coderabbitai help` to get help. ### Other keywords and placeholders - Add `@coderabbitai ignore` anywhere in the PR description to prevent this PR from being reviewed. - Add `@coderabbitai summary` to generate the high-level summary at a specific location in the PR description. - Add `@coderabbitai` anywhere in the PR title to generate the title automatically. ### Documentation and Community - Visit our [Documentation](https://docs.coderabbit.ai) for detailed information on how to use CodeRabbit. - Join our [Discord Community](http://discord.gg/coderabbit) to get help, request features, and share feedback. - Follow us on [X/Twitter](https://twitter.com/coderabbitai) for updates and announcements. </details>

coderabbitai[bot] (Migrated from github.com) reviewed 2025-01-04 21:22:14 -08:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 2

🧹 Nitpick comments (3)

src/controllers/api/infestedFoundryController.ts (3)

94-95: Consider extracting the magic multiplier into a constant or configuration.
The hard-coded value 666 might be unclear to future maintainers. Using a well-named constant will improve readability and make adjustments easier.

158-159: Consistent approach to XP-based recipes.
Using the same approach of calling addInfestedFoundryXP and then addRecipes aligns with other modes. Make sure you confirm the 1600_00 XP increment is correct for this “subsume warframe” scenario.

Also applies to: 163-163

273-335: Consider storing XP thresholds in a data structure.
Hard-coding numerous thresholds leads to verbose code. A data-driven approach (e.g., iterating over a list of “XP thresholds → actions” pairs) might improve clarity, maintainability, and future extensibility.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 506e77db6c and 0291b56592.

📒 Files selected for processing (1)

src/controllers/api/infestedFoundryController.ts (5 hunks)

🔇 Additional comments (3)

src/controllers/api/infestedFoundryController.ts (3)

101-108: Good addition of Recipes to the JSON response.
Including Recipes in the response ensures the front-end can promptly reflect recipe changes. This maintains consistency with other modes adding Recipes as well.

204-205: Maintain uniform XP increments and response consistency.
Similar to the “c” and “a” cases, the “u” case now includes recipe changes in the response. Ensure the 4800_00 XP increment is intentional and reflect it in your test coverage.

Also applies to: 219-219

264-265: Excellent approach to returning granular recipeChanges.
Returning ITypeCount[] directly from addInfestedFoundryXP cleanly indicates which new recipes were unlocked.

**Actionable comments posted: 2** <details> <summary>🧹 Nitpick comments (3)</summary><blockquote> <details> <summary>src/controllers/api/infestedFoundryController.ts (3)</summary><blockquote> `94-95`: **Consider extracting the magic multiplier into a constant or configuration.** The hard-coded value `666` might be unclear to future maintainers. Using a well-named constant will improve readability and make adjustments easier. --- `158-159`: **Consistent approach to XP-based recipes.** Using the same approach of calling `addInfestedFoundryXP` and then `addRecipes` aligns with other modes. Make sure you confirm the `1600_00` XP increment is correct for this “subsume warframe” scenario. Also applies to: 163-163 --- `273-335`: **Consider storing XP thresholds in a data structure.** Hard-coding numerous thresholds leads to verbose code. A data-driven approach (e.g., iterating over a list of “XP thresholds → actions” pairs) might improve clarity, maintainability, and future extensibility. </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** **Plan: Pro** <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 506e77db6cab79ba9a33dc428d6bf9bda59cced2 and 0291b56592a9f2ce373df30b546bf99e4429723d. </details> <details> <summary>📒 Files selected for processing (1)</summary> * `src/controllers/api/infestedFoundryController.ts` (5 hunks) </details> <details> <summary>🔇 Additional comments (3)</summary><blockquote> <details> <summary>src/controllers/api/infestedFoundryController.ts (3)</summary> `101-108`: **Good addition of `Recipes` to the JSON response.** Including `Recipes` in the response ensures the front-end can promptly reflect recipe changes. This maintains consistency with other modes adding `Recipes` as well. --- `204-205`: **Maintain uniform XP increments and response consistency.** Similar to the “c” and “a” cases, the “u” case now includes recipe changes in the response. Ensure the `4800_00` XP increment is intentional and reflect it in your test coverage. Also applies to: 219-219 --- `264-265`: **Excellent approach to returning granular `recipeChanges`.** Returning `ITypeCount[]` directly from `addInfestedFoundryXP` cleanly indicates which new recipes were unlocked. </details> </blockquote></details> </details>

src/controllers/api/infestedFoundryController.ts

coderabbitai[bot] (Migrated from github.com) commented

2025-01-04 21:22:14 -08:00

💡 Codebase verification

Add null check and initialization validation for InfestedFoundry.Slots

Based on the code analysis:

Slots is defined as an optional number property in IInfestedFoundry interface
There's an initialization setting Slots = 1 in the controller
The current code uses double non-null assertions (!) which could be unsafe

To prevent runtime errors, you should:

Add a null check before decrementing
Ensure the value doesn't go below 0
Initialize if undefined

if (inventory.InfestedFoundry?.Slots === undefined) {
    inventory.InfestedFoundry.Slots = 1;
} else if (inventory.InfestedFoundry.Slots > 0) {
    inventory.InfestedFoundry.Slots--;
}

🔗 Analysis chain

Validate that Slots is initialized before decrementing.
If Slots is uninitialized, inventory.InfestedFoundry!.Slots!--; may produce unexpected results. Safeguard against negative slot counts or uninitialized values.

Let me gather more information about the initialization of InfestedFoundry and Slots.

Let me try a different approach to find the initialization and type information.

Let me try one final search to find where Slots is initialized.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for `Slots` usage across the code to confirm a default is always set.
rg "InfestedFoundry.*Slots" -A 5

Length of output: 1158

Script:

#!/bin/bash
# Check for InfestedFoundry initialization and Slots assignment
ast-grep --pattern 'InfestedFoundry = {
  $$$
}'

# Also check for any model/type definitions
fd "InfestedFoundry" --exec cat {}

Length of output: 87

Script:

#!/bin/bash
# Search for InfestedFoundry type/interface definitions and initialization
rg "interface.*InfestedFoundry|type.*InfestedFoundry|new InfestedFoundry" -A 5

# Search for any assignment to InfestedFoundry.Slots
rg "\.Slots\s*=\s*" --type typescript

Length of output: 579

Script:

#!/bin/bash
# Search for any Slots assignments or initializations in typescript files
rg "\.Slots\s*=" 

# Look for InfestedFoundry creation or initialization
rg "InfestedFoundry.*=.*{" -A 5

Length of output: 242

_:bulb: Codebase verification_ **Add null check and initialization validation for InfestedFoundry.Slots** Based on the code analysis: 1. `Slots` is defined as an optional number property in `IInfestedFoundry` interface 2. There's an initialization setting `Slots = 1` in the controller 3. The current code uses double non-null assertions (`!`) which could be unsafe To prevent runtime errors, you should: - Add a null check before decrementing - Ensure the value doesn't go below 0 - Initialize if undefined ```typescript if (inventory.InfestedFoundry?.Slots === undefined) { inventory.InfestedFoundry.Slots = 1; } else if (inventory.InfestedFoundry.Slots > 0) { inventory.InfestedFoundry.Slots--; } ``` <details> <summary>🔗 Analysis chain</summary> **Validate that `Slots` is initialized before decrementing.** If `Slots` is uninitialized, `inventory.InfestedFoundry!.Slots!--;` may produce unexpected results. Safeguard against negative slot counts or uninitialized values. --- Let me gather more information about the initialization of InfestedFoundry and Slots. --- Let me try a different approach to find the initialization and type information. --- Let me try one final search to find where Slots is initialized. </details> <details> <summary>🏁 Scripts executed</summary> The following scripts were executed for the analysis: Script: ```shell #!/bin/bash # Description: Check for `Slots` usage across the code to confirm a default is always set. rg "InfestedFoundry.*Slots" -A 5 ``` Length of output: 1158 --- Script: ```shell #!/bin/bash # Check for InfestedFoundry initialization and Slots assignment ast-grep --pattern 'InfestedFoundry = { $$$ }' # Also check for any model/type definitions fd "InfestedFoundry" --exec cat {} ``` Length of output: 87 --- Script: ```shell #!/bin/bash # Search for InfestedFoundry type/interface definitions and initialization rg "interface.*InfestedFoundry|type.*InfestedFoundry|new InfestedFoundry" -A 5 # Search for any assignment to InfestedFoundry.Slots rg "\.Slots\s*=\s*" --type typescript ``` Length of output: 579 --- Script: ```shell #!/bin/bash # Search for any Slots assignments or initializations in typescript files rg "\.Slots\s*=" # Look for InfestedFoundry creation or initialization rg "InfestedFoundry.*=.*{" -A 5 ``` Length of output: 242 </details>

src/controllers/api/infestedFoundryController.ts

coderabbitai[bot] (Migrated from github.com) commented

2025-01-04 21:22:14 -08:00

⚠️ Potential issue

Fix the mismatch in numeric literals for the 73,125 XP threshold.
The condition checks prevXP < 73125_00 but compares infestedFoundry.XP >= 73125 (missing _00). This likely leads to unintended behavior at that threshold.

-if (prevXP < 73125_00 && infestedFoundry.XP >= 73125) {
+if (prevXP < 73125_00 && infestedFoundry.XP >= 73125_00) {
     infestedFoundry.Slots = 1;
 }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

    if (prevXP < 73125_00 && infestedFoundry.XP >= 73125_00) {
        infestedFoundry.Slots = 1;
    }

_:warning: Potential issue_ **Fix the mismatch in numeric literals for the 73,125 XP threshold.** The condition checks `prevXP < 73125_00` but compares `infestedFoundry.XP >= 73125` (missing `_00`). This likely leads to unintended behavior at that threshold. ```diff -if (prevXP < 73125_00 && infestedFoundry.XP >= 73125) { +if (prevXP < 73125_00 && infestedFoundry.XP >= 73125_00) { infestedFoundry.Slots = 1; } ```  <details> <summary>📝 Committable suggestion</summary> > ‼️ **IMPORTANT** > Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements. `````suggestion if (prevXP < 73125_00 && infestedFoundry.XP >= 73125_00) { infestedFoundry.Slots = 1; } ````` </details>

coderabbitai[bot] (Migrated from github.com) reviewed 2025-01-04 21:42:27 -08:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 0

🧹 Nitpick comments (11)

src/types/purchaseTypes.ts (1)

30-33: Consider narrowing the union type.
The union IBinChanges | number | object[] | IInfestedFoundry is very broad. If these fields require more structured data or type checks, consider using narrower or discriminated types to improve type-safety and readability.

src/services/inventoryService.ts (1)

82-82: Revisit usage of console.assert for merging.
This assertion (key != "InfestedFoundry") silently fails when in production builds where console.assert is typically a no-op. If it’s critical that we never treat InfestedFoundry as a bin, consider throwing an error or handling it explicitly rather than asserting.

src/controllers/api/infestedFoundryController.ts (9)

81-81: Use clearer naming for stored resource counts.
Storing “Count” as an integer that is 1000 times the fractional percentage can be unintuitive. A short comment or rename (e.g., FractionalCount) might prevent confusion.

158-159: Consistent approach to awarding XP.
Adding 1600_00 XP ensures large increments for warframe subsumption. Just confirm that it aligns with your game progression design and expected thresholds.

273-278: Leverage DRY for repeated blueprint additions.
Repeated push of blueprint recipes is correct. However, you might consider a helper function for adding ability override blueprint recipes to reduce duplication and centralize logic.

286-291: Add inline docs for each ability override threshold.
Adding a quick comment explaining each new unlocked blueprint would clarify future maintenance and keep code consistent.

292-294: Standardize evaluations with consistent bracket usage.
Make sure to keep consistent code style (e.g., braces and spacing) across the threshold checks for readability.

299-301: Use consistent naming for blueprint items.
HelminthStatusBlueprint fits the pattern, but ensure any newly added recipes follow your naming conventions (e.g., HelminthSomethingBlueprint).

305-310: Document slot expansions.
When the XP threshold triggers large slot increments, mention precisely why numbers like +20 or resetting to 1 are chosen to help future maintainers.

317-322: Consider grouping threshold-based logic.
These conditional checks repeat a pattern of awarding “slot expansions” or “recipes.” A single consolidated function (e.g., awardsForThreshold) might reduce duplication.

323-328: Add comments for awarding HelminthMaxStatusBlueprint.
As above, clarifying these expansions ensures better discoverability and future maintenance.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0291b56592 and 08da860cb0.

📒 Files selected for processing (4)

src/controllers/api/infestedFoundryController.ts (6 hunks)
src/controllers/api/upgradesController.ts (5 hunks)
src/services/inventoryService.ts (1 hunks)
src/types/purchaseTypes.ts (2 hunks)

🔇 Additional comments (19)

src/types/purchaseTypes.ts (1)

1-1: Import looks good.
No issues detected. This import statement broadens the usage of IInfestedFoundry, which aligns with the subsequent changes referencing InfestedFoundry in the union type.

src/services/inventoryService.ts (1)

84-84: Confirm type correctness when merging bins.
Here, const right = delta[key] as IBinChanges; assumes that the code path applies only when dealing with bin changes and not InfestedFoundry or unrelated objects. If key accidentally references something else, this cast could hide bugs. Consider validated type-guards to avoid runtime errors.

src/controllers/api/upgradesController.ts (7)

11-11: Expanded imports are consistent with new usage.
These imports, including addRecipes and updateCurrency, indicate usage for more complex inventory updates. No issues found.

13-14: Correct approach to referencing updated types/functions.
The introduced imports for IInventoryChanges and addInfestedFoundryXP are coherent with your changes. Good job maintaining consistency.

20-20: Initialize inventoryChanges object early.
Declaring const inventoryChanges: IInventoryChanges = {}; is a clear approach to accumulating changes. No concerns here.

41-41: Variable naming is clear.
The name totalPercentagePointsConsumed is self-explanatory and helps maintain code readability. Good job.

50-50: Double-check the unit for percentage calculation.
This expression ingredient.ItemCount / 10 implies 1/10th scaling. Verify that this logic matches your design for ability override cost or synergy with your XP system to avoid off-by-one or scaling errors.

61-65: Ensure consistency in InfestedFoundry merges.
You set both inventoryChanges.Recipes and inventoryChanges.InfestedFoundry immediately after calling addInfestedFoundryXP. This is consistent, but confirm that any subsequent modifications to InfestedFoundry in this scope also reflect in inventoryChanges if needed.

160-160: Properly returning all inventory changes.
Returning inventoryChanges helps the client see the relevant updates from the entire operation. This is good practice.

src/controllers/api/infestedFoundryController.ts (10)

74-74: Multiplying snack gain by 100 is correct but double-check alignment with other calculation sites.
Converting a 0.3 gain to 30 percentage points is logical. Make sure to remain consistent anywhere else that processes or expects these numeric values.

94-94: Check XP scaling factor.
You're applying 666 * totalPercentagePointsGained. This is an unusual constant. If it's deliberate, consider adding a meaningful comment to clarify its significance.

101-108: Carefully handle partial responses for InfestedFoundry.
You're returning XP, Resources, Slots, and MiscItems. Confirm that the client expects only these fields or if more fields should be included (like Name or other properties).

149-151: Initialize Slots before decrementing
If inventory.InfestedFoundry!.Slots is uninitialized (or zero), decrementing can produce undesirable values or runtime surprises. A safer approach is to ensure it’s set to at least 0 before this code.

163-163: Returning all relevant inventory changes.
Including Recipes, RemovedIdItems, SuitBin, and InfestedFoundry fosters clear client feedback. Nicely done.

264-265: Good shift to returning ITypeCount[].
Returning recipe changes from addInfestedFoundryXP fosters modular design and streamlines usage in multiple contexts like feeding, subsuming, etc.

279-281: Ensure synergy within thresholds.
Each threshold checks prevXP < X && infestedFoundry.XP >= X. Verify that other XP thresholds or expansions won't skip levels if large XP jumps occur in a single update.

302-304: Nice fix for the mismatch in numeric literals.
You’re now consistently checking 73125_00. This corrects the earlier threshold mismatch concern.

311-316: Confirm functionality for HelminthProcBlockBlueprint.
This threshold-based blueprint is newly introduced. Verify that the game logic or client code properly interprets and uses it.

329-334: Re-check increment logic.
When awarding the HelminthTreasureBlueprint, ensure it doesn’t conflict with other awarding logic if multiple thresholds are passed simultaneously.

**Actionable comments posted: 0** <details> <summary>🧹 Nitpick comments (11)</summary><blockquote> <details> <summary>src/types/purchaseTypes.ts (1)</summary><blockquote> `30-33`: **Consider narrowing the union type.** The union `IBinChanges | number | object[] | IInfestedFoundry` is very broad. If these fields require more structured data or type checks, consider using narrower or discriminated types to improve type-safety and readability. </blockquote></details> <details> <summary>src/services/inventoryService.ts (1)</summary><blockquote> `82-82`: **Revisit usage of `console.assert` for merging.** This assertion (`key != "InfestedFoundry"`) silently fails when in production builds where `console.assert` is typically a no-op. If it’s critical that we never treat InfestedFoundry as a bin, consider throwing an error or handling it explicitly rather than asserting. </blockquote></details> <details> <summary>src/controllers/api/infestedFoundryController.ts (9)</summary><blockquote> `81-81`: **Use clearer naming for stored resource counts.** Storing “Count” as an integer that is 1000 times the fractional percentage can be unintuitive. A short comment or rename (e.g., `FractionalCount`) might prevent confusion. --- `158-159`: **Consistent approach to awarding XP.** Adding 1600_00 XP ensures large increments for warframe subsumption. Just confirm that it aligns with your game progression design and expected thresholds. --- `273-278`: **Leverage DRY for repeated blueprint additions.** Repeated push of blueprint recipes is correct. However, you might consider a helper function for adding ability override blueprint recipes to reduce duplication and centralize logic. --- `286-291`: **Add inline docs for each ability override threshold.** Adding a quick comment explaining each new unlocked blueprint would clarify future maintenance and keep code consistent. --- `292-294`: **Standardize evaluations with consistent bracket usage.** Make sure to keep consistent code style (e.g., braces and spacing) across the threshold checks for readability. --- `299-301`: **Use consistent naming for blueprint items.** `HelminthStatusBlueprint` fits the pattern, but ensure any newly added recipes follow your naming conventions (e.g., HelminthSomethingBlueprint). --- `305-310`: **Document slot expansions.** When the XP threshold triggers large slot increments, mention precisely why numbers like +20 or resetting to 1 are chosen to help future maintainers. --- `317-322`: **Consider grouping threshold-based logic.** These conditional checks repeat a pattern of awarding “slot expansions” or “recipes.” A single consolidated function (e.g., `awardsForThreshold`) might reduce duplication. --- `323-328`: **Add comments for awarding HelminthMaxStatusBlueprint.** As above, clarifying these expansions ensures better discoverability and future maintenance. </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** **Plan: Pro** <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 0291b56592a9f2ce373df30b546bf99e4429723d and 08da860cb0eaf1aeab6e71ea89d6e15d45f3554a. </details> <details> <summary>📒 Files selected for processing (4)</summary> * `src/controllers/api/infestedFoundryController.ts` (6 hunks) * `src/controllers/api/upgradesController.ts` (5 hunks) * `src/services/inventoryService.ts` (1 hunks) * `src/types/purchaseTypes.ts` (2 hunks) </details> <details> <summary>🔇 Additional comments (19)</summary><blockquote> <details> <summary>src/types/purchaseTypes.ts (1)</summary> `1-1`: **Import looks good.** No issues detected. This import statement broadens the usage of `IInfestedFoundry`, which aligns with the subsequent changes referencing InfestedFoundry in the union type. </details> <details> <summary>src/services/inventoryService.ts (1)</summary> `84-84`: **Confirm type correctness when merging bins.** Here, `const right = delta[key] as IBinChanges;` assumes that the code path applies only when dealing with bin changes and not InfestedFoundry or unrelated objects. If `key` accidentally references something else, this cast could hide bugs. Consider validated type-guards to avoid runtime errors. </details> <details> <summary>src/controllers/api/upgradesController.ts (7)</summary> `11-11`: **Expanded imports are consistent with new usage.** These imports, including `addRecipes` and `updateCurrency`, indicate usage for more complex inventory updates. No issues found. --- `13-14`: **Correct approach to referencing updated types/functions.** The introduced imports for `IInventoryChanges` and `addInfestedFoundryXP` are coherent with your changes. Good job maintaining consistency. --- `20-20`: **Initialize `inventoryChanges` object early.** Declaring `const inventoryChanges: IInventoryChanges = {};` is a clear approach to accumulating changes. No concerns here. --- `41-41`: **Variable naming is clear.** The name `totalPercentagePointsConsumed` is self-explanatory and helps maintain code readability. Good job. --- `50-50`: **Double-check the unit for percentage calculation.** This expression `ingredient.ItemCount / 10` implies 1/10th scaling. Verify that this logic matches your design for ability override cost or synergy with your XP system to avoid off-by-one or scaling errors. --- `61-65`: **Ensure consistency in InfestedFoundry merges.** You set both `inventoryChanges.Recipes` and `inventoryChanges.InfestedFoundry` immediately after calling `addInfestedFoundryXP`. This is consistent, but confirm that any subsequent modifications to `InfestedFoundry` in this scope also reflect in `inventoryChanges` if needed. --- `160-160`: **Properly returning all inventory changes.** Returning `inventoryChanges` helps the client see the relevant updates from the entire operation. This is good practice. </details> <details> <summary>src/controllers/api/infestedFoundryController.ts (10)</summary> `74-74`: **Multiplying snack gain by 100 is correct but double-check alignment with other calculation sites.** Converting a 0.3 gain to 30 percentage points is logical. Make sure to remain consistent anywhere else that processes or expects these numeric values. --- `94-94`: **Check XP scaling factor.** You're applying `666 * totalPercentagePointsGained`. This is an unusual constant. If it's deliberate, consider adding a meaningful comment to clarify its significance. --- `101-108`: **Carefully handle partial responses for InfestedFoundry.** You're returning `XP`, `Resources`, `Slots`, and `MiscItems`. Confirm that the client expects only these fields or if more fields should be included (like `Name` or other properties). --- `149-151`: **Initialize `Slots` before decrementing** If `inventory.InfestedFoundry!.Slots` is uninitialized (or zero), decrementing can produce undesirable values or runtime surprises. A safer approach is to ensure it’s set to at least 0 before this code. --- `163-163`: **Returning all relevant inventory changes.** Including `Recipes`, `RemovedIdItems`, `SuitBin`, and `InfestedFoundry` fosters clear client feedback. Nicely done. --- `264-265`: **Good shift to returning `ITypeCount[]`.** Returning recipe changes from `addInfestedFoundryXP` fosters modular design and streamlines usage in multiple contexts like feeding, subsuming, etc. --- `279-281`: **Ensure synergy within thresholds.** Each threshold checks `prevXP < X && infestedFoundry.XP >= X`. Verify that other XP thresholds or expansions won't skip levels if large XP jumps occur in a single update. --- `302-304`: **Nice fix for the mismatch in numeric literals.** You’re now consistently checking `73125_00`. This corrects the earlier threshold mismatch concern. --- `311-316`: **Confirm functionality for HelminthProcBlockBlueprint.** This threshold-based blueprint is newly introduced. Verify that the game logic or client code properly interprets and uses it. --- `329-334`: **Re-check increment logic.** When awarding the `HelminthTreasureBlueprint`, ensure it doesn’t conflict with other awarding logic if multiple thresholds are passed simultaneously. </details> </blockquote></details> </details>

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: OpenWF/SpaceNinjaServer#716