fix: not showing "void fissures" tab in navigation #521

Sainan · 2024-10-06T16:07:59-07:00

Sainan commented

2024-10-06 16:07:59 -07:00

No description provided.

coderabbitai[bot] commented

2024-10-06 16:08:05 -07:00

(Migrated from github.com)

Warning

Rate limit exceeded

@Sainan has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 19 minutes and 49 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Files that changed from the base of the PR and between 97bcf14685 and 564ad73090.

Walkthrough

The changes introduce a new boolean property, HasOwnedVoidProjectionsPreviously, to the inventoryResponse object in the inventoryController function, indicating the display of the "void fissures" tab. Additionally, the IInventoryResponse interface is updated to include this new property. Other modifications in the IInventoryDatabase interface include changing the types of several properties to use MongoDB's ObjectId and updating TrainingDate to a standard Date type. Expiry dates in the worldState.json file are also standardized to a realistic future timestamp.

Changes

File Path	Change Summary
src/controllers/api/inventoryController.ts	Added property `HasOwnedVoidProjectionsPreviously` to `inventoryResponse` object.
src/types/inventoryTypes/inventoryTypes.ts	Updated `IInventoryResponse` to include `HasOwnedVoidProjectionsPreviously?: boolean`.
src/types/inventoryTypes/inventoryTypes.ts	Updated `TrainingDate` from `IMongoDate` to `Date` in `IInventoryDatabase`.
src/types/inventoryTypes/inventoryTypes.ts	Changed `LoadOutPresets` and `Mailbox` from `ILoadOutPresets` and `IMailbox` to `Types.ObjectId`.
src/types/inventoryTypes/inventoryTypes.ts	Updated `GuildId` from `?IOid` to `?Types.ObjectId` in `IInventoryDatabase`.
static/fixed_responses/worldState.json	Updated `Expiry` dates across multiple entries to a realistic future timestamp of `2000000000000`.

Poem

In the realm of code, a change took flight,
A boolean added, bringing new light.
With ObjectId's grace, we shift and we sway,
Inventory's magic grows brighter each day.
Hooray for the updates, let joy take its stance,
In the dance of the data, we all take a chance! 🐇✨

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 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.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

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.

> [!WARNING] > ## Rate limit exceeded > > @Sainan has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait **19 minutes and 49 seconds** before requesting another review. > > <details> > <summary>⌛ How to resolve this issue?</summary> > > After the wait time has elapsed, a review can be triggered using the `@coderabbitai review` command as a PR comment. Alternatively, push new commits to this PR. > > We recommend that you space out your commits to avoid hitting the rate limit. > > </details> > > > <details> > <summary>🚦 How do rate limits work?</summary> > > CodeRabbit enforces hourly rate limits for each developer per organization. > > Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. > > Please see our [FAQ](https://coderabbit.ai/docs/faq) for further information. > > </details> > > <details> > <summary>📥 Commits</summary> > > Files that changed from the base of the PR and between 97bcf14685ed70ea3716a87ec646510fcc6d3e91 and 564ad73090b998e936a77fb92a646a2462016472. > > </details>  ## Walkthrough The changes introduce a new boolean property, `HasOwnedVoidProjectionsPreviously`, to the `inventoryResponse` object in the `inventoryController` function, indicating the display of the "void fissures" tab. Additionally, the `IInventoryResponse` interface is updated to include this new property. Other modifications in the `IInventoryDatabase` interface include changing the types of several properties to use MongoDB's `ObjectId` and updating `TrainingDate` to a standard `Date` type. Expiry dates in the `worldState.json` file are also standardized to a realistic future timestamp. ## Changes | File Path | Change Summary | |------------------------------------------------|---------------------------------------------------------------------------------------------------| | src/controllers/api/inventoryController.ts | Added property `HasOwnedVoidProjectionsPreviously` to `inventoryResponse` object. | | src/types/inventoryTypes/inventoryTypes.ts | Updated `IInventoryResponse` to include `HasOwnedVoidProjectionsPreviously?: boolean`. | | src/types/inventoryTypes/inventoryTypes.ts | Updated `TrainingDate` from `IMongoDate` to `Date` in `IInventoryDatabase`. | | src/types/inventoryTypes/inventoryTypes.ts | Changed `LoadOutPresets` and `Mailbox` from `ILoadOutPresets` and `IMailbox` to `Types.ObjectId`. | | src/types/inventoryTypes/inventoryTypes.ts | Updated `GuildId` from `?IOid` to `?Types.ObjectId` in `IInventoryDatabase`. | | static/fixed_responses/worldState.json | Updated `Expiry` dates across multiple entries to a realistic future timestamp of `2000000000000`. | ## Poem > In the realm of code, a change took flight, > A boolean added, bringing new light. > With ObjectId's grace, we shift and we sway, > Inventory's magic grows brighter each day. > Hooray for the updates, let joy take its stance, > In the dance of the data, we all take a chance! 🐇✨         --- 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 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. ### CodeRabbit Configuration File (`.coderabbit.yaml`) - You can programmatically configure CodeRabbit by adding a `.coderabbit.yaml` file to the root of your repository. - Please see the [configuration documentation](https://docs.coderabbit.ai/guides/configure-coderabbit) for more information. - If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: `# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json` ### Documentation and Community - Visit our [Documentation](https://coderabbit.ai/docs) 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 2024-10-06 16:11:11 -07:00

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

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (2)

src/controllers/api/inventoryController.ts (1)
153-155: LGTM! Consider making this configurable.

The addition of HasOwnedVoidProjectionsPreviously property with its explanatory comment is clear and doesn't interfere with existing logic. However, setting it to true unconditionally might not be suitable for all scenarios.

Consider making this configurable, either through the config object or based on user data:
inventoryResponse.HasOwnedVoidProjectionsPreviously = config.showVoidFissuresTab || inventoryJSON.hasOwnedVoidProjections;
This approach would provide more flexibility in controlling when the "void fissures" tab is displayed.
src/types/inventoryTypes/inventoryTypes.ts (1)

148-148: Consider adding a JSDoc comment to describe HasOwnedVoidProjectionsPreviously

Adding a JSDoc comment will help clarify the purpose and usage of the new property HasOwnedVoidProjectionsPreviously in IInventoryResponse.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between b7f381ba1d and 379bb54f87.

📒 Files selected for processing (2)

src/controllers/api/inventoryController.ts (1 hunks)
src/types/inventoryTypes/inventoryTypes.ts (1 hunks)

🧰 Additional context used

🔇 Additional comments (2)

src/controllers/api/inventoryController.ts (1)

153-155: Verify the impact on the client-side navigation.

The addition of HasOwnedVoidProjectionsPreviously successfully addresses the issue of not showing the "void fissures" tab in navigation. However, to ensure full compatibility:

Verify that the client-side code correctly interprets this new property to display the "void fissures" tab.

Consider adding a test case to verify the presence of this property in the response.

To check for any client-side changes related to this new property, run:

For future extensibility, consider implementing a more dynamic approach to determine tab visibility, possibly through a configuration service or based on user data.
src/types/inventoryTypes/inventoryTypes.ts (1)
Line range hint 24-27: Verify type changes for properties in IInventoryDatabase interface

The properties TrainingDate, LoadOutPresets, Mailbox, and GuildId have had their types changed. Ensure that all parts of the codebase that interact with these properties are updated to handle the new types to prevent runtime errors or type mismatches.

Run the following script to identify all usages of these properties:

✅ Verification successful

Type Changes Verified Successfully

All type updates for TrainingDate, LoadOutPresets, Mailbox, and GuildId in the IInventoryDatabase interface are correctly handled across the codebase. No instances of old types or improper type handling were found.
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: Find all references to the updated properties to verify they are correctly handled.

# Search for references to 'TrainingDate' property
rg --type js --type ts 'TrainingDate'

# Search for references to 'LoadOutPresets' property
rg --type js --type ts 'LoadOutPresets'

# Search for references to 'Mailbox' property
rg --type js --type ts 'Mailbox'

# Search for references to 'GuildId' property
rg --type js --type ts 'GuildId'
Length of output: 3937

Script:
#!/bin/bash
# Description: Verify assignments to the updated properties to ensure correct type handling.

# Check assignments to 'TrainingDate' to ensure it's assigned a Date object
rg --type js --type ts 'TrainingDate\s*='

# Check assignments to 'LoadOutPresets' to ensure correct type usage
rg --type js --type ts 'LoadOutPresets\s*='

# Check assignments to 'Mailbox' to ensure correct type usage
rg --type js --type ts 'Mailbox\s*='

# Check assignments to 'GuildId' to ensure correct type usage
rg --type js --type ts 'GuildId\s*='

# Description: Identify any type assertions or casts for the updated properties.

# Search for type assertions or casts for 'TrainingDate'
rg --type ts 'TrainingDate\s*as\s*'

# Search for type assertions or casts for 'LoadOutPresets'
rg --type ts 'LoadOutPresets\s*as\s*'

# Search for type assertions or casts for 'Mailbox'
rg --type ts 'Mailbox\s*as\s*'

# Search for type assertions or casts for 'GuildId'
rg --type ts 'GuildId\s*as\s*'

# Description: Check for any usage of old types related to the updated properties.

# Search for 'IMongoDate' usage with 'TrainingDate'
rg --type js --type ts 'IMongoDate.*TrainingDate'

# Search for 'ILoadOutPresets' usage with 'LoadOutPresets'
rg --type js --type ts 'ILoadOutPresets.*LoadOutPresets'

# Search for 'IMailbox' usage with 'Mailbox'
rg --type js --type ts 'IMailbox.*Mailbox'

# Search for 'IOid' usage with 'GuildId'
rg --type js --type ts 'IOid.*GuildId'
Length of output: 961

**Actionable comments posted: 0** <details> <summary>🧹 Outside diff range and nitpick comments (2)</summary><blockquote> <details> <summary>src/controllers/api/inventoryController.ts (1)</summary><blockquote> `153-155`: **LGTM! Consider making this configurable.** The addition of `HasOwnedVoidProjectionsPreviously` property with its explanatory comment is clear and doesn't interfere with existing logic. However, setting it to `true` unconditionally might not be suitable for all scenarios. Consider making this configurable, either through the `config` object or based on user data: ```typescript inventoryResponse.HasOwnedVoidProjectionsPreviously = config.showVoidFissuresTab || inventoryJSON.hasOwnedVoidProjections; ``` This approach would provide more flexibility in controlling when the "void fissures" tab is displayed. </blockquote></details> <details> <summary>src/types/inventoryTypes/inventoryTypes.ts (1)</summary><blockquote> `148-148`: **Consider adding a JSDoc comment to describe `HasOwnedVoidProjectionsPreviously`** Adding a JSDoc comment will help clarify the purpose and usage of the new property `HasOwnedVoidProjectionsPreviously` in `IInventoryResponse`. </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: CodeRabbit UI** **Review profile: CHILL** <details> <summary>📥 Commits</summary> Files that changed from the base of the PR and between b7f381ba1da1e736b8501be69c5c8a0eade25f0e and 379bb54f8764d667823fd160f3939909619a143c. </details> <details> <summary>📒 Files selected for processing (2)</summary> * src/controllers/api/inventoryController.ts (1 hunks) * src/types/inventoryTypes/inventoryTypes.ts (1 hunks) </details> <details> <summary>🧰 Additional context used</summary> </details> <details> <summary>🔇 Additional comments (2)</summary><blockquote> <details> <summary>src/controllers/api/inventoryController.ts (1)</summary><blockquote> `153-155`: **Verify the impact on the client-side navigation.** The addition of `HasOwnedVoidProjectionsPreviously` successfully addresses the issue of not showing the "void fissures" tab in navigation. However, to ensure full compatibility: 1. Verify that the client-side code correctly interprets this new property to display the "void fissures" tab. 2. Consider adding a test case to verify the presence of this property in the response. To check for any client-side changes related to this new property, run: For future extensibility, consider implementing a more dynamic approach to determine tab visibility, possibly through a configuration service or based on user data. </blockquote></details> <details> <summary>src/types/inventoryTypes/inventoryTypes.ts (1)</summary><blockquote> Line range hint `24-27`: **Verify type changes for properties in `IInventoryDatabase` interface** The properties `TrainingDate`, `LoadOutPresets`, `Mailbox`, and `GuildId` have had their types changed. Ensure that all parts of the codebase that interact with these properties are updated to handle the new types to prevent runtime errors or type mismatches. Run the following script to identify all usages of these properties: <details> <summary>✅ Verification successful</summary>  **Type Changes Verified Successfully** All type updates for `TrainingDate`, `LoadOutPresets`, `Mailbox`, and `GuildId` in the `IInventoryDatabase` interface are correctly handled across the codebase. No instances of old types or improper type handling were found. </details> <details> <summary>🏁 Scripts executed</summary> The following scripts were executed for the analysis: Script: ```shell #!/bin/bash # Description: Find all references to the updated properties to verify they are correctly handled. # Search for references to 'TrainingDate' property rg --type js --type ts 'TrainingDate' # Search for references to 'LoadOutPresets' property rg --type js --type ts 'LoadOutPresets' # Search for references to 'Mailbox' property rg --type js --type ts 'Mailbox' # Search for references to 'GuildId' property rg --type js --type ts 'GuildId' ``` Length of output: 3937 --- Script: ```shell #!/bin/bash # Description: Verify assignments to the updated properties to ensure correct type handling. # Check assignments to 'TrainingDate' to ensure it's assigned a Date object rg --type js --type ts 'TrainingDate\s*=' # Check assignments to 'LoadOutPresets' to ensure correct type usage rg --type js --type ts 'LoadOutPresets\s*=' # Check assignments to 'Mailbox' to ensure correct type usage rg --type js --type ts 'Mailbox\s*=' # Check assignments to 'GuildId' to ensure correct type usage rg --type js --type ts 'GuildId\s*=' # Description: Identify any type assertions or casts for the updated properties. # Search for type assertions or casts for 'TrainingDate' rg --type ts 'TrainingDate\s*as\s*' # Search for type assertions or casts for 'LoadOutPresets' rg --type ts 'LoadOutPresets\s*as\s*' # Search for type assertions or casts for 'Mailbox' rg --type ts 'Mailbox\s*as\s*' # Search for type assertions or casts for 'GuildId' rg --type ts 'GuildId\s*as\s*' # Description: Check for any usage of old types related to the updated properties. # Search for 'IMongoDate' usage with 'TrainingDate' rg --type js --type ts 'IMongoDate.*TrainingDate' # Search for 'ILoadOutPresets' usage with 'LoadOutPresets' rg --type js --type ts 'ILoadOutPresets.*LoadOutPresets' # Search for 'IMailbox' usage with 'Mailbox' rg --type js --type ts 'IMailbox.*Mailbox' # Search for 'IOid' usage with 'GuildId' rg --type js --type ts 'IOid.*GuildId' ``` Length of output: 961 </details> </blockquote></details> </blockquote></details> </details>

coderabbitai[bot] (Migrated from github.com) reviewed 2024-10-06 16:15:39 -07:00

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

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 379bb54f87 and 97bcf14685.

📒 Files selected for processing (1)

static/fixed_responses/worldState.json (40 hunks)

🧰 Additional context used

🔇 Additional comments (5)

static/fixed_responses/worldState.json (5)
705-705: Verify the impact of updated expiry date for VoidTraders

The expiry date for the VoidTraders entry has been updated from 9999999999999 to 2000000000000, consistent with changes in other sections. Consider the following:

How does this change affect the Void Trader's appearance and inventory rotation?

Are there any systems or player expectations that might be impacted by this change?

Is there a need to update any related documentation or player-facing information about Void Trader availability?

To ensure consistency and identify any potential issues, run the following verification:
#!/bin/bash
# Check the VoidTraders expiry date
jq '.VoidTraders[0].Expiry."$date"."$numberLong"' static/fixed_responses/worldState.json

# Verify if any other date fields in VoidTraders use the old value
jq '.VoidTraders[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json

# Compare Activation (if exists) and Expiry dates to ensure they're in the correct order
jq '.VoidTraders[] | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json
This script will help confirm the expiry date change, check for any remaining instances of the old date value, and ensure that the Activation date (if it exists) is before the Expiry date in the VoidTraders section.

Line range hint 498-674: Verify the impact of updated expiry dates for ActiveMissions

The expiry dates for all ActiveMissions have been updated from 9999999999999 to 2000000000000, consistent with the changes in SyndicateMissions. Consider the following:

How does this change affect the rotation or availability of active missions?

Are there any systems that depend on the previous "infinite" expiry date that might be impacted?

Is there a need to update any client-side logic that interprets these expiry dates?

To ensure consistency and identify any potential issues, run the following verification:
#!/bin/bash
# Check for any inconsistencies in ActiveMissions expiry dates
jq '.ActiveMissions[] | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json

# Verify if any other date fields in ActiveMissions use the old value
jq '.ActiveMissions[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json

# Compare Activation and Expiry dates to ensure they're in the correct order
jq '.ActiveMissions[] | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json
This script will help identify any inconsistencies in the expiry date changes, check for any remaining instances of the old date value, and ensure that the Activation dates are always before the Expiry dates in the ActiveMissions section.

902-937: Verify the impact of updated expiry dates for VoidStorms

The expiry dates for all VoidStorms have been updated from 9999999999999 to 2000000000000, consistent with changes in other sections. Consider the following:

How does this change affect the duration and rotation of Void Storms?

Are there any systems or player expectations that might be impacted by this change?

Is there a need to update any related documentation or player-facing information about Void Storm availability?

To ensure consistency and identify any potential issues, run the following verification:
#!/bin/bash
# Check for any inconsistencies in VoidStorms expiry dates
jq '.VoidStorms[] | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json

# Verify if any other date fields in VoidStorms use the old value
jq '.VoidStorms[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json

# Compare Activation and Expiry dates to ensure they're in the correct order
jq '.VoidStorms[] | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json
This script will help identify any inconsistencies in the expiry date changes, check for any remaining instances of the old date value, and ensure that the Activation dates are always before the Expiry dates in the VoidStorms section.

Line range hint 1-1176: Comprehensive review of expiry date changes across worldState.json

The primary change in this file is the standardization of expiry dates from 9999999999999 (essentially "never expires") to 2000000000000 (approximately year 2033) across multiple sections including SyndicateMissions, ActiveMissions, VoidTraders, VoidStorms, DailyDeals, PVPChallengeInstances, and SeasonInfo.

While this change is consistently applied, it represents a significant shift in how the game handles expiration of various elements. Consider the following:

Game Mechanics: How does this change affect the rotation, availability, and duration of missions, events, and other time-sensitive game elements?

Player Experience: Are there any player expectations or behaviors that might be impacted by this change?

Performance: Does this change have any implications for server performance or data management?

Future-proofing: Is the new expiry date (year 2033) sufficient for the game's projected lifespan?

To ensure a comprehensive review of these changes, please run the following verification:
#!/bin/bash
# Check for any remaining instances of the old expiry date
jq '.. | objects | select(has("Expiry")) | select(.Expiry."$date"."$numberLong" == "9999999999999")' static/fixed_responses/worldState.json

# Verify all Expiry dates are set to the new value
jq '.. | objects | select(has("Expiry")) | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json

# Check for any Activation dates that are after their corresponding Expiry dates
jq '.. | objects | select(has("Activation") and has("Expiry")) | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json

# List all unique date fields in the file to ensure no dates were missed
jq '[paths(scalars) | select(.[-1] | tostring | endswith("date"))] | unique' static/fixed_responses/worldState.json
This comprehensive check will help ensure that all necessary date fields have been updated consistently and that no unintended changes were introduced.

Given the scope of this change, would you like assistance in drafting documentation updates or player communications regarding these changes to expiration dates?

Line range hint 948-1171: Verify the impact of updated expiry dates for DailyDeals, PVPChallengeInstances, and SeasonInfo

The expiry dates for DailyDeals, PVPChallengeInstances, and SeasonInfo have been updated from 9999999999999 to 2000000000000, consistent with changes in other sections. Consider the following:

How do these changes affect the rotation and availability of daily deals, PVP challenges, and seasonal content?

Are there any systems or player expectations that might be impacted by these changes?

Is there a need to update any related documentation or player-facing information about these features?

To ensure consistency and identify any potential issues, run the following verification:
#!/bin/bash
# Check for any inconsistencies in expiry dates for the specified sections
jq '[.DailyDeals[], .PVPChallengeInstances[], .SeasonInfo] | .[] | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json

# Verify if any other date fields in these sections use the old value
jq '[.DailyDeals[], .PVPChallengeInstances[], .SeasonInfo] | .[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json

# Compare Activation and Expiry dates to ensure they're in the correct order
jq '[.DailyDeals[], .PVPChallengeInstances[], .SeasonInfo] | .[] | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json
This script will help identify any inconsistencies in the expiry date changes, check for any remaining instances of the old date value, and ensure that the Activation dates are always before the Expiry dates in these sections.

**Actionable comments posted: 1** <details> <summary>📜 Review details</summary> **Configuration used: CodeRabbit UI** **Review profile: CHILL** <details> <summary>📥 Commits</summary> Files that changed from the base of the PR and between 379bb54f8764d667823fd160f3939909619a143c and 97bcf14685ed70ea3716a87ec646510fcc6d3e91. </details> <details> <summary>📒 Files selected for processing (1)</summary> * static/fixed_responses/worldState.json (40 hunks) </details> <details> <summary>🧰 Additional context used</summary> </details> <details> <summary>🔇 Additional comments (5)</summary><blockquote> <details> <summary>static/fixed_responses/worldState.json (5)</summary><blockquote> `705-705`: **Verify the impact of updated expiry date for VoidTraders** The expiry date for the VoidTraders entry has been updated from 9999999999999 to 2000000000000, consistent with changes in other sections. Consider the following: 1. How does this change affect the Void Trader's appearance and inventory rotation? 2. Are there any systems or player expectations that might be impacted by this change? 3. Is there a need to update any related documentation or player-facing information about Void Trader availability? To ensure consistency and identify any potential issues, run the following verification: ```shell #!/bin/bash # Check the VoidTraders expiry date jq '.VoidTraders[0].Expiry."$date"."$numberLong"' static/fixed_responses/worldState.json # Verify if any other date fields in VoidTraders use the old value jq '.VoidTraders[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json # Compare Activation (if exists) and Expiry dates to ensure they're in the correct order jq '.VoidTraders[] | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json ``` This script will help confirm the expiry date change, check for any remaining instances of the old date value, and ensure that the Activation date (if it exists) is before the Expiry date in the VoidTraders section. --- Line range hint `498-674`: **Verify the impact of updated expiry dates for ActiveMissions** The expiry dates for all ActiveMissions have been updated from 9999999999999 to 2000000000000, consistent with the changes in SyndicateMissions. Consider the following: 1. How does this change affect the rotation or availability of active missions? 2. Are there any systems that depend on the previous "infinite" expiry date that might be impacted? 3. Is there a need to update any client-side logic that interprets these expiry dates? To ensure consistency and identify any potential issues, run the following verification: ```shell #!/bin/bash # Check for any inconsistencies in ActiveMissions expiry dates jq '.ActiveMissions[] | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json # Verify if any other date fields in ActiveMissions use the old value jq '.ActiveMissions[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json # Compare Activation and Expiry dates to ensure they're in the correct order jq '.ActiveMissions[] | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json ``` This script will help identify any inconsistencies in the expiry date changes, check for any remaining instances of the old date value, and ensure that the Activation dates are always before the Expiry dates in the ActiveMissions section. --- `902-937`: **Verify the impact of updated expiry dates for VoidStorms** The expiry dates for all VoidStorms have been updated from 9999999999999 to 2000000000000, consistent with changes in other sections. Consider the following: 1. How does this change affect the duration and rotation of Void Storms? 2. Are there any systems or player expectations that might be impacted by this change? 3. Is there a need to update any related documentation or player-facing information about Void Storm availability? To ensure consistency and identify any potential issues, run the following verification: ```shell #!/bin/bash # Check for any inconsistencies in VoidStorms expiry dates jq '.VoidStorms[] | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json # Verify if any other date fields in VoidStorms use the old value jq '.VoidStorms[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json # Compare Activation and Expiry dates to ensure they're in the correct order jq '.VoidStorms[] | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json ``` This script will help identify any inconsistencies in the expiry date changes, check for any remaining instances of the old date value, and ensure that the Activation dates are always before the Expiry dates in the VoidStorms section. --- Line range hint `1-1176`: **Comprehensive review of expiry date changes across worldState.json** The primary change in this file is the standardization of expiry dates from 9999999999999 (essentially "never expires") to 2000000000000 (approximately year 2033) across multiple sections including SyndicateMissions, ActiveMissions, VoidTraders, VoidStorms, DailyDeals, PVPChallengeInstances, and SeasonInfo. While this change is consistently applied, it represents a significant shift in how the game handles expiration of various elements. Consider the following: 1. Game Mechanics: How does this change affect the rotation, availability, and duration of missions, events, and other time-sensitive game elements? 2. Player Experience: Are there any player expectations or behaviors that might be impacted by this change? 3. Performance: Does this change have any implications for server performance or data management? 4. Future-proofing: Is the new expiry date (year 2033) sufficient for the game's projected lifespan? To ensure a comprehensive review of these changes, please run the following verification: ```shell #!/bin/bash # Check for any remaining instances of the old expiry date jq '.. | objects | select(has("Expiry")) | select(.Expiry."$date"."$numberLong" == "9999999999999")' static/fixed_responses/worldState.json # Verify all Expiry dates are set to the new value jq '.. | objects | select(has("Expiry")) | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json # Check for any Activation dates that are after their corresponding Expiry dates jq '.. | objects | select(has("Activation") and has("Expiry")) | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json # List all unique date fields in the file to ensure no dates were missed jq '[paths(scalars) | select(.[-1] | tostring | endswith("date"))] | unique' static/fixed_responses/worldState.json ``` This comprehensive check will help ensure that all necessary date fields have been updated consistently and that no unintended changes were introduced. Given the scope of this change, would you like assistance in drafting documentation updates or player communications regarding these changes to expiration dates? --- Line range hint `948-1171`: **Verify the impact of updated expiry dates for DailyDeals, PVPChallengeInstances, and SeasonInfo** The expiry dates for DailyDeals, PVPChallengeInstances, and SeasonInfo have been updated from 9999999999999 to 2000000000000, consistent with changes in other sections. Consider the following: 1. How do these changes affect the rotation and availability of daily deals, PVP challenges, and seasonal content? 2. Are there any systems or player expectations that might be impacted by these changes? 3. Is there a need to update any related documentation or player-facing information about these features? To ensure consistency and identify any potential issues, run the following verification: ```shell #!/bin/bash # Check for any inconsistencies in expiry dates for the specified sections jq '[.DailyDeals[], .PVPChallengeInstances[], .SeasonInfo] | .[] | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json # Verify if any other date fields in these sections use the old value jq '[.DailyDeals[], .PVPChallengeInstances[], .SeasonInfo] | .[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json # Compare Activation and Expiry dates to ensure they're in the correct order jq '[.DailyDeals[], .PVPChallengeInstances[], .SeasonInfo] | .[] | select(.Activation."$date"."$numberLong" >= .Expiry."$date"."$numberLong")' static/fixed_responses/worldState.json ``` This script will help identify any inconsistencies in the expiry date changes, check for any remaining instances of the old date value, and ensure that the Activation dates are always before the Expiry dates in these sections. </blockquote></details> </blockquote></details> </details>

static/fixed_responses/worldState.json

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

2024-10-06 16:15:39 -07:00

💡 Codebase verification

Inconsistent Expiry Dates Found in SyndicateMissions

Several SyndicateMissions entries have Expiry dates that were not updated to "2000000000000":

_id: "663a4c7d4d932c97c0a3acd7"
_id: "663819fd1cec9ebe9d83a06e"
_id: "631f8c4ac36af423770eaa97"

Please update these entries to ensure consistent Expiry dates across all SyndicateMissions.

🔗 Analysis chain

Verify the impact of updated expiry dates for SyndicateMissions

The expiry dates for all SyndicateMissions have been updated from 9999999999999 to 2000000000000. While this change is consistent, it's important to consider its implications:

Does this new date (approximately year 2033) align with the game's intended mechanics for mission rotation?
Are there any game systems that might be affected by this change, such as mission availability or player progression?
Is this change part of a larger update to standardize expiration dates across the game?

To ensure this change doesn't introduce any unintended consequences, please run the following verification:

This script will help identify any inconsistencies in the expiry date changes and check for any remaining instances of the old date value in the SyndicateMissions section.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any inconsistencies in SyndicateMissions expiry dates
jq '.SyndicateMissions[] | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json

# Verify if any other date fields in SyndicateMissions use the old value
jq '.SyndicateMissions[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json

Length of output: 21302

_:bulb: Codebase verification_ **Inconsistent Expiry Dates Found in SyndicateMissions** Several SyndicateMissions entries have Expiry dates that were not updated to "2000000000000": - **_id**: "663a4c7d4d932c97c0a3acd7" - **_id**: "663819fd1cec9ebe9d83a06e" - **_id**: "631f8c4ac36af423770eaa97" Please update these entries to ensure consistent Expiry dates across all SyndicateMissions. <details> <summary>🔗 Analysis chain</summary> **Verify the impact of updated expiry dates for SyndicateMissions** The expiry dates for all SyndicateMissions have been updated from 9999999999999 to 2000000000000. While this change is consistent, it's important to consider its implications: 1. Does this new date (approximately year 2033) align with the game's intended mechanics for mission rotation? 2. Are there any game systems that might be affected by this change, such as mission availability or player progression? 3. Is this change part of a larger update to standardize expiration dates across the game? To ensure this change doesn't introduce any unintended consequences, please run the following verification: This script will help identify any inconsistencies in the expiry date changes and check for any remaining instances of the old date value in the SyndicateMissions section. </details> <details> <summary>🏁 Scripts executed</summary> The following scripts were executed for the analysis: Script: ```shell #!/bin/bash # Check for any inconsistencies in SyndicateMissions expiry dates jq '.SyndicateMissions[] | select(.Expiry."$date"."$numberLong" != "2000000000000")' static/fixed_responses/worldState.json # Verify if any other date fields in SyndicateMissions use the old value jq '.SyndicateMissions[] | select(.. | strings | test("9999999999999"))' static/fixed_responses/worldState.json ``` Length of output: 21302 </details>

lonewolf0708 commented

2024-10-07 06:52:40 -07:00

(Migrated from github.com)

Most of the Stores, Market, Void Fissures, etc. are handled by the WorldState.php. Scroll down about half way and you'll see the Market items, Void Fissures, invasions, Syndicate missions and specials, Baro'Ki Teel's wares, MegaPrimeShop/Varzia,s wares, etc.

Most of the Stores, Market, Void Fissures, etc. are handled by the [WorldState.php.](https://content.warframe.com/dynamic/worldState.php) Scroll down about half way and you'll see the Market items, Void Fissures, invasions, Syndicate missions and specials, Baro'Ki Teel's wares, MegaPrimeShop/Varzia,s wares, etc.

Sainan commented

2024-10-07 06:54:06 -07:00

... ?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: OpenWF/SpaceNinjaServer#521