OpenWF/SpaceNinjaServer
28
29
Fork 34
Code Issues 25 Pull Requests 2 Actions Packages Projects Releases Activity

feat: loc-pin saving #485

Closed
AMelonInsideLemon wants to merge 2 commits from AMelonInsideLemon/custom-markers into main
pull from: AMelonInsideLemon/custom-markers
merge into: OpenWF:main
Conversation 5 Commits 2 Files Changed 4 +86 -8
AMelonInsideLemon commented 2024-07-22 01:10:54 -07:00 (Migrated from github.com)
Copy Link

Closes #404

Closes #404
coderabbitai[bot] commented 2024-10-17 09:07:06 -07:00 (Migrated from github.com)
Copy Link

Walkthrough

The pull request introduces significant changes to the inventory management system, primarily through the addition of new schemas and types related to custom markers. In the inventoryModel.ts file, three new schemas—markerSchema, markerInfoSchema, and CustomMarkersSchema—are defined to represent individual markers and their associated information. The inventorySchema is updated to include a new field, CustomMarkers, which allows for the storage of custom marker data within the inventory model.

In inventoryService.ts, the missionInventoryUpdate function is enhanced to accommodate new properties such as AffiliationChanges, EvolutionProgress, LastRegionPlayed, and CustomMarkers, streamlining the inventory update process. The inventoryTypes.ts file sees changes in the IInventoryDatabase interface, with specific properties updated to use MongoDB ObjectId types. Additionally, new interfaces for custom markers are introduced. Finally, the requestTypes.ts file is modified to include the new CustomMarkers property in the IMissionInventoryUpdateRequest interface. These changes collectively enhance the structure and functionality of the inventory system.

Assessment against linked issues

Objective Addressed Explanation
CustomMarkers saving functionality (#404) ✅

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.

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.
<!-- This is an auto-generated comment: summarize by coderabbit.ai --> <!-- walkthrough_start --> ## Walkthrough The pull request introduces significant changes to the inventory management system, primarily through the addition of new schemas and types related to custom markers. In the `inventoryModel.ts` file, three new schemas—`markerSchema`, `markerInfoSchema`, and `CustomMarkersSchema`—are defined to represent individual markers and their associated information. The `inventorySchema` is updated to include a new field, `CustomMarkers`, which allows for the storage of custom marker data within the inventory model. In `inventoryService.ts`, the `missionInventoryUpdate` function is enhanced to accommodate new properties such as `AffiliationChanges`, `EvolutionProgress`, `LastRegionPlayed`, and `CustomMarkers`, streamlining the inventory update process. The `inventoryTypes.ts` file sees changes in the `IInventoryDatabase` interface, with specific properties updated to use MongoDB ObjectId types. Additionally, new interfaces for custom markers are introduced. Finally, the `requestTypes.ts` file is modified to include the new `CustomMarkers` property in the `IMissionInventoryUpdateRequest` interface. These changes collectively enhance the structure and functionality of the inventory system. ## Assessment against linked issues | Objective | Addressed | Explanation | |---------------------------------------------|-----------|--------------------------------------------| | CustomMarkers saving functionality (#404) | ✅ | | <!-- walkthrough_end --><!-- This is an auto-generated comment: raw summary by coderabbit.ai --> <!-- ``` src/models/inventoryModels/inventoryModel.ts: ## AI-generated summary of changes The diff introduces significant modifications to the `inventoryModel.ts` file, primarily by adding new schemas and types related to custom markers. Three new schemas are defined: `markerSchema`, `markerInfoSchema`, and `CustomMarkersSchema`. The `markerSchema` includes fields for `anchorName`, `color`, `label`, `x`, `y`, `z`, and `showInHud`, which represent individual markers. The `markerInfoSchema` contains an `icon` field and an array of `markerSchema` instances. The `CustomMarkersSchema` encapsulates a `tag` and an array of `markerInfoSchema` instances. Additionally, the `inventorySchema` is updated to include a new field, `CustomMarkers`, which is an array of `CustomMarkersSchema`. This allows for the storage of custom marker data within the inventory model. The existing `IEvolutionProgress` type is retained, and the overall structure of the inventory schema remains intact, with the new fields integrated into the existing model. The import statements are also updated to include the new types `ICustomMarkers`, `IMarkerInfo`, and `IMarker`, reflecting the new schemas added to the file. ## Alterations to the declarations of exported or public entities - New method added: `const markerSchema = new Schema<IMarker>(...)` - New method added: `const markerInfoSchema = new Schema<IMarkerInfo>(...)` - New method added: `const CustomMarkersSchema = new Schema<ICustomMarkers>(...)` - Field added: `CustomMarkers: { type: [CustomMarkersSchema], default: undefined }` in `inventorySchema` --- src/services/inventoryService.ts: ## AI-generated summary of changes The diff introduces significant modifications to the `missionInventoryUpdate` function within the `inventoryService.ts` file, enhancing its capability to process additional data related to inventory updates. Notably, four new properties—`AffiliationChanges`, `EvolutionProgress`, `LastRegionPlayed`, and `CustomMarkers`—have been added to the `data` parameter. The handling of these properties has been refined to improve the logic for updating the inventory. The `AffiliationChanges` property is now processed directly, allowing for streamlined updates to the `Affiliations` array within the inventory. The logic for updating `EvolutionProgress` has been adjusted to ensure that the progress and rank are correctly assigned to existing entries or added as new ones. The `LastRegionPlayed` property is now directly assigned to the inventory without referencing the `data` object. Additionally, the `CustomMarkers` property has been introduced, enabling the addition or updating of custom markers in the inventory. The code now checks for existing markers and updates them accordingly, or adds new markers if they do not exist. Overall, these changes enhance the functionality of the `missionInventoryUpdate` function, allowing it to handle more complex inventory updates while maintaining the integrity of existing data structures. ## Alterations to the declarations of exported or public entities - Method signature updated: `export const missionInventoryUpdate(data: IMissionInventoryUpdateRequest, accountId: string)` → `export const missionInventoryUpdate(data: IMissionInventoryUpdateRequest & { AffiliationChanges?: any; EvolutionProgress?: any; LastRegionPlayed?: any; CustomMarkers?: any; }, accountId: string)` --- src/types/inventoryTypes/inventoryTypes.ts: ## AI-generated summary of changes The diff introduces several modifications to the `IInventoryDatabase` interface and related types in the `src/types/inventoryTypes/inventoryTypes.ts` file. Key changes include the alteration of types for specific properties within the `IInventoryDatabase` interface. The `TrainingDate` property has been changed from `IMongoDate` to `Date`. The `LoadOutPresets` and `Mailbox` properties have been updated from `ILoadOutPresets` and `IMailbox` to `Types.ObjectId`, indicating a shift towards using MongoDB ObjectId types for these fields. The `GuildId` property has also been modified from an optional `IOid` to an optional `Types.ObjectId`. Additionally, new interfaces `ICustomMarkers`, `IMarkerInfo`, and `IMarker` have been added, which define the structure of custom markers and their related properties. ## Alterations to the declarations of exported or public entities - Property type updated: `TrainingDate: IMongoDate` → `TrainingDate: Date` - Property type updated: `LoadOutPresets: ILoadOutPresets` → `LoadOutPresets: Types.ObjectId` - Property type updated: `Mailbox: IMailbox` → `Mailbox: Types.ObjectId` - Property type updated: `GuildId?: IOid` → `GuildId?: Types.ObjectId` - Interface added: `export interface ICustomMarkers` - Interface added: `export interface IMarkerInfo` - Interface added: `export interface IMarker` --- src/types/requestTypes.ts: ## AI-generated summary of changes The diff introduces a new interface `ICustomMarkers` to the `src/types/requestTypes.ts` file, which is imported from the `inventoryTypes/inventoryTypes` module. This addition is reflected in the `IMissionInventoryUpdateRequest` interface, where a new optional property `CustomMarkers` of type `ICustomMarkers[]` is included. The previous declaration of `FusionTreasures` remains unchanged, but the new property expands the structure of `IMissionInventoryUpdateRequest` to accommodate additional data related to custom markers. ## Alterations to the declarations of exported or public entities - Interface updated: `IMissionInventoryUpdateRequest` now includes `CustomMarkers?: ICustomMarkers[]` ``` --> <!-- end of auto-generated comment: raw summary by coderabbit.ai --><!-- This is an auto-generated comment: pr objectives by coderabbit.ai --> <!-- ## PR Summary The pull request titled "fix: loc-pin saving" was submitted by the user AMelonInsideLemon and is identified by the number 485. The primary purpose of this pull request is to address an issue related to the saving functionality of loc-pins, specifically for CustomMarkers. The description indicates that this pull request closes issue #404, which pertains to the same topic. The pull request can be accessed through the provided URL: [PR #485](https://github.com/spaceninjaserver/SpaceNinjaServer/pull/485). ## Objectives from Linked Issues The linked issue #404 is titled "Loc-Pin (CustomMarkers) saving." The objective of this issue is to resolve problems associated with the saving mechanism for loc-pins, which are a type of CustomMarker used within the application. The issue highlights the need for improvements in how these markers are stored, ensuring that user-defined loc-pins are saved correctly and persistently. The visual representation included in the issue description illustrates the context of the loc-pins, emphasizing their importance in the application's functionality. The resolution of this issue is critical for enhancing user experience by ensuring that custom markers are reliably saved and can be accessed in future sessions. --> <!-- end of auto-generated comment: pr objectives by coderabbit.ai --><!-- commit_ids_reviewed_start --> <!-- b543392f34b38f4b813fd5044e6574eb1d9aaaec --> <!-- 7fc60e70f2b7fd6d4bb64beede885d4b69ae34d4 --> <!-- commit_ids_reviewed_end --><!-- tips_start --> --- 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. ### 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> <!-- tips_end -->
coderabbitai[bot] (Migrated from github.com) reviewed 2024-10-17 09:12:22 -07:00
coderabbitai[bot] (Migrated from github.com) left a comment
Copy Link

Actionable comments posted: 4

🧹 Outside diff range and nitpick comments (7)
src/types/requestTypes.ts (1)

74-74: LGTM: CustomMarkers property added to IMissionInventoryUpdateRequest.

The addition of the CustomMarkers property to the IMissionInventoryUpdateRequest interface directly addresses the PR objective of fixing loc-pin saving for CustomMarkers. The optional nature of the property ensures backward compatibility.

Consider adding a brief comment above this line to explain the purpose of the CustomMarkers property, e.g.:

// CustomMarkers represent user-defined loc-pins that need to be saved
CustomMarkers?: ICustomMarkers[];

This would enhance code readability and provide context for future developers.

src/types/inventoryTypes/inventoryTypes.ts (4)

Line range hint 12-20: Review changes in property types in IInventoryDatabase

The properties TrainingDate, LoadOutPresets, Mailbox, and GuildId have been updated to new types (Date and Types.ObjectId). Ensure that all code interacting with these properties is updated accordingly. For instance:

  • Changing TrainingDate from IMongoDate to Date might affect date handling and formatting.
  • Replacing interfaces (ILoadOutPresets, IMailbox) with Types.ObjectId requires updating Mongoose population logic to retrieve the actual documents.

280-280: Consider making CustomMarkers optional

If the CustomMarkers property may not always be present, consider making it optional in the IInventoryResponse interface:

-CustomMarkers: ICustomMarkers[];
+CustomMarkers?: ICustomMarkers[];

This will help prevent potential undefined errors when accessing this property.

921-924: Rename markerInfos to markerInfo for correct pluralization

In the ICustomMarkers interface, consider renaming the markerInfos property to markerInfo. Since "information" is an uncountable noun, "info" is typically used in the singular form.

-export interface ICustomMarkers {
-    tag: string;
-    markerInfos: IMarkerInfo[];
+export interface ICustomMarkers {
+    tag: string;
+    markerInfo: IMarkerInfo[];

932-934: Clarify the type of the color property in IMarker

The color property is currently typed as number. If this represents a color in a specific format (e.g., RGB, HEX, or a color code), consider using a more descriptive type or adding documentation to clarify the expected value format.

src/services/inventoryService.ts (2)

Line range hint 749-759: Call inventory.markModified('Affiliations') after updating nested properties

When modifying nested properties in a Mongoose document, such as updating syndicate.Standing and syndicate.Title, it's important to inform Mongoose of these changes to ensure they are persisted.

Apply this diff to ensure changes are tracked:

         if (syndicate !== undefined) {
             syndicate.Standing =
                 syndicate.Standing === undefined ? affiliation.Standing : syndicate.Standing + affiliation.Standing;
             syndicate.Title = syndicate.Title === undefined ? affiliation.Title : syndicate.Title + affiliation.Title;
+            inventory.markModified('Affiliations');
         } else {
             inventory.Affiliations.push({
                 Standing: affiliation.Standing,
                 Title: affiliation.Title,
                 Tag: affiliation.Tag,
                 FreeFavorsEarned: [],
                 FreeFavorsUsed: []
             });
+            inventory.markModified('Affiliations');
         }

Line range hint 770-779: Call inventory.markModified('EvolutionProgress') after updating nested properties

To ensure changes to nested properties like entry.Progress and entry.Rank are saved, inform Mongoose of the modifications.

Apply this diff:

     if (entry) {
         entry.Progress = evoProgress.Progress;
         entry.Rank = evoProgress.Rank;
+        inventory.markModified('EvolutionProgress');
     } else {
         inventory.EvolutionProgress ??= [];
         inventory.EvolutionProgress.push(evoProgress);
+        inventory.markModified('EvolutionProgress');
     }
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 76964585eb and b543392f34.

📒 Files selected for processing (4)
  • src/models/inventoryModels/inventoryModel.ts (3 hunks)
  • src/services/inventoryService.ts (4 hunks)
  • src/types/inventoryTypes/inventoryTypes.ts (2 hunks)
  • src/types/requestTypes.ts (2 hunks)
🧰 Additional context used
🔇 Additional comments (7)
src/types/requestTypes.ts (2)

16-17: LGTM: Import statements updated correctly.

The addition of IFusionTreasure and ICustomMarkers imports aligns with the PR objective of addressing loc-pin saving for CustomMarkers. These imports prepare the file for the upcoming changes in the IMissionInventoryUpdateRequest interface.

Line range hint 1-74: Verify usage of CustomMarkers in related components.

The changes made to this file effectively address the PR objective of fixing loc-pin saving for CustomMarkers. The modifications are minimal and focused, which is good for maintainability.

To ensure full implementation:

  1. Verify that components or services responsible for handling mission inventory updates are updated to include CustomMarkers when necessary.
  2. Check if any existing tests need to be updated or new tests added to cover the CustomMarkers functionality.

Run the following script to check for potential usage of the updated interface:

This will help identify areas of the codebase that might need updates to fully utilize the new CustomMarkers property.

src/models/inventoryModels/inventoryModel.ts (3)

39-42: Imports for new types added appropriately

The types ICustomMarkers, IMarkerInfo, and IMarker are correctly imported for use in the schemas.

597-603: Definition of 'markerInfoSchema' is appropriate

The markerInfoSchema is correctly defined with fields icon and markers, matching the expected structure.

605-611: Definition of 'CustomMarkersSchema' is appropriate

The CustomMarkersSchema is properly defined with fields tag and markerInfos, encapsulating the custom marker data effectively.

src/services/inventoryService.ts (2)

734-738: Destructuring new properties from data looks good

The additional properties FusionTreasures, AffiliationChanges, EvolutionProgress, LastRegionPlayed, and CustomMarkers are appropriately destructured from the data object.

786-788: Updating inventory.LastRegionPlayed is implemented correctly

The assignment of LastRegionPlayed to inventory.LastRegionPlayed is straightforward and correct.

**Actionable comments posted: 4** <details> <summary>🧹 Outside diff range and nitpick comments (7)</summary><blockquote> <details> <summary>src/types/requestTypes.ts (1)</summary><blockquote> `74-74`: **LGTM: CustomMarkers property added to IMissionInventoryUpdateRequest.** The addition of the `CustomMarkers` property to the `IMissionInventoryUpdateRequest` interface directly addresses the PR objective of fixing loc-pin saving for CustomMarkers. The optional nature of the property ensures backward compatibility. Consider adding a brief comment above this line to explain the purpose of the CustomMarkers property, e.g.: ```typescript // CustomMarkers represent user-defined loc-pins that need to be saved CustomMarkers?: ICustomMarkers[]; ``` This would enhance code readability and provide context for future developers. </blockquote></details> <details> <summary>src/types/inventoryTypes/inventoryTypes.ts (4)</summary><blockquote> Line range hint `12-20`: **Review changes in property types in `IInventoryDatabase`** The properties `TrainingDate`, `LoadOutPresets`, `Mailbox`, and `GuildId` have been updated to new types (`Date` and `Types.ObjectId`). Ensure that all code interacting with these properties is updated accordingly. For instance: - Changing `TrainingDate` from `IMongoDate` to `Date` might affect date handling and formatting. - Replacing interfaces (`ILoadOutPresets`, `IMailbox`) with `Types.ObjectId` requires updating Mongoose population logic to retrieve the actual documents. --- `280-280`: **Consider making `CustomMarkers` optional** If the `CustomMarkers` property may not always be present, consider making it optional in the `IInventoryResponse` interface: ```diff -CustomMarkers: ICustomMarkers[]; +CustomMarkers?: ICustomMarkers[]; ``` This will help prevent potential `undefined` errors when accessing this property. --- `921-924`: **Rename `markerInfos` to `markerInfo` for correct pluralization** In the `ICustomMarkers` interface, consider renaming the `markerInfos` property to `markerInfo`. Since "information" is an uncountable noun, "info" is typically used in the singular form. ```diff -export interface ICustomMarkers { - tag: string; - markerInfos: IMarkerInfo[]; +export interface ICustomMarkers { + tag: string; + markerInfo: IMarkerInfo[]; ``` --- `932-934`: **Clarify the type of the `color` property in `IMarker`** The `color` property is currently typed as `number`. If this represents a color in a specific format (e.g., RGB, HEX, or a color code), consider using a more descriptive type or adding documentation to clarify the expected value format. </blockquote></details> <details> <summary>src/services/inventoryService.ts (2)</summary><blockquote> Line range hint `749-759`: **Call `inventory.markModified('Affiliations')` after updating nested properties** When modifying nested properties in a Mongoose document, such as updating `syndicate.Standing` and `syndicate.Title`, it's important to inform Mongoose of these changes to ensure they are persisted. Apply this diff to ensure changes are tracked: ```diff if (syndicate !== undefined) { syndicate.Standing = syndicate.Standing === undefined ? affiliation.Standing : syndicate.Standing + affiliation.Standing; syndicate.Title = syndicate.Title === undefined ? affiliation.Title : syndicate.Title + affiliation.Title; + inventory.markModified('Affiliations'); } else { inventory.Affiliations.push({ Standing: affiliation.Standing, Title: affiliation.Title, Tag: affiliation.Tag, FreeFavorsEarned: [], FreeFavorsUsed: [] }); + inventory.markModified('Affiliations'); } ``` --- Line range hint `770-779`: **Call `inventory.markModified('EvolutionProgress')` after updating nested properties** To ensure changes to nested properties like `entry.Progress` and `entry.Rank` are saved, inform Mongoose of the modifications. Apply this diff: ```diff if (entry) { entry.Progress = evoProgress.Progress; entry.Rank = evoProgress.Rank; + inventory.markModified('EvolutionProgress'); } else { inventory.EvolutionProgress ??= []; inventory.EvolutionProgress.push(evoProgress); + inventory.markModified('EvolutionProgress'); } ``` </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** <details> <summary>📥 Commits</summary> Files that changed from the base of the PR and between 76964585ebd5145dc8c86bdd1075c40d23e48859 and b543392f34b38f4b813fd5044e6574eb1d9aaaec. </details> <details> <summary>📒 Files selected for processing (4)</summary> * src/models/inventoryModels/inventoryModel.ts (3 hunks) * src/services/inventoryService.ts (4 hunks) * src/types/inventoryTypes/inventoryTypes.ts (2 hunks) * src/types/requestTypes.ts (2 hunks) </details> <details> <summary>🧰 Additional context used</summary> </details> <details> <summary>🔇 Additional comments (7)</summary><blockquote> <details> <summary>src/types/requestTypes.ts (2)</summary><blockquote> `16-17`: **LGTM: Import statements updated correctly.** The addition of `IFusionTreasure` and `ICustomMarkers` imports aligns with the PR objective of addressing loc-pin saving for CustomMarkers. These imports prepare the file for the upcoming changes in the `IMissionInventoryUpdateRequest` interface. --- Line range hint `1-74`: **Verify usage of CustomMarkers in related components.** The changes made to this file effectively address the PR objective of fixing loc-pin saving for CustomMarkers. The modifications are minimal and focused, which is good for maintainability. To ensure full implementation: 1. Verify that components or services responsible for handling mission inventory updates are updated to include CustomMarkers when necessary. 2. Check if any existing tests need to be updated or new tests added to cover the CustomMarkers functionality. Run the following script to check for potential usage of the updated interface: This will help identify areas of the codebase that might need updates to fully utilize the new CustomMarkers property. </blockquote></details> <details> <summary>src/models/inventoryModels/inventoryModel.ts (3)</summary><blockquote> `39-42`: **Imports for new types added appropriately** The types `ICustomMarkers`, `IMarkerInfo`, and `IMarker` are correctly imported for use in the schemas. --- `597-603`: **Definition of 'markerInfoSchema' is appropriate** The `markerInfoSchema` is correctly defined with fields `icon` and `markers`, matching the expected structure. --- `605-611`: **Definition of 'CustomMarkersSchema' is appropriate** The `CustomMarkersSchema` is properly defined with fields `tag` and `markerInfos`, encapsulating the custom marker data effectively. </blockquote></details> <details> <summary>src/services/inventoryService.ts (2)</summary><blockquote> `734-738`: **Destructuring new properties from `data` looks good** The additional properties `FusionTreasures`, `AffiliationChanges`, `EvolutionProgress`, `LastRegionPlayed`, and `CustomMarkers` are appropriately destructured from the `data` object. --- `786-788`: **Updating `inventory.LastRegionPlayed` is implemented correctly** The assignment of `LastRegionPlayed` to `inventory.LastRegionPlayed` is straightforward and correct. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
src/models/inventoryModels/inventoryModel.ts
@ -581,0 +604,4 @@
const CustomMarkersSchema = new Schema<ICustomMarkers>(
{
tag: String,
coderabbitai[bot] (Migrated from github.com) commented 2024-10-17 09:12:22 -07:00
Copy Link

⚠️ Potential issue

Consider the data type for the 'color' field in 'markerSchema'

The color field in markerSchema is defined as Number. If color represents a hexadecimal color code or a string value, it might be more appropriate to use String. Alternatively, if it represents RGB values, consider defining it as an object with r, g, and b components for clarity.

Apply this diff to update the color field:

         anchorName: String,
-        color: Number,
+        color: String,
         label: String,

Or, if using RGB components:

         anchorName: String,
-        color: Number,
+        color: {
+            r: Number,
+            g: Number,
+            b: Number
+        },
         label: String,

Committable suggestion was skipped due to low confidence.

_:warning: Potential issue_ **Consider the data type for the 'color' field in 'markerSchema'** The `color` field in `markerSchema` is defined as `Number`. If `color` represents a hexadecimal color code or a string value, it might be more appropriate to use `String`. Alternatively, if it represents RGB values, consider defining it as an object with `r`, `g`, and `b` components for clarity. Apply this diff to update the `color` field: ```diff anchorName: String, - color: Number, + color: String, label: String, ``` Or, if using RGB components: ```diff anchorName: String, - color: Number, + color: { + r: Number, + g: Number, + b: Number + }, label: String, ``` > Committable suggestion was skipped due to low confidence. <!-- This is an auto-generated comment by CodeRabbit -->
src/models/inventoryModels/inventoryModel.ts
coderabbitai[bot] (Migrated from github.com) commented 2024-10-17 09:12:22 -07:00
Copy Link

⚠️ Potential issue

Set a default value for 'CustomMarkers' in 'inventorySchema'

The CustomMarkers field in inventorySchema is defined without a default value. To prevent potential issues with undefined values and ensure consistency, consider setting a default value.

Apply this diff to set a default value:

     //https://warframe.fandom.com/wiki/Loc-Pin
-    CustomMarkers: [CustomMarkersSchema],
+    CustomMarkers: { type: [CustomMarkersSchema], default: undefined },

Committable suggestion was skipped due to low confidence.

_:warning: Potential issue_ **Set a default value for 'CustomMarkers' in 'inventorySchema'** The `CustomMarkers` field in `inventorySchema` is defined without a default value. To prevent potential issues with undefined values and ensure consistency, consider setting a default value. Apply this diff to set a default value: ```diff //https://warframe.fandom.com/wiki/Loc-Pin - CustomMarkers: [CustomMarkersSchema], + CustomMarkers: { type: [CustomMarkersSchema], default: undefined }, ``` > Committable suggestion was skipped due to low confidence. <!-- This is an auto-generated comment by CodeRabbit -->
src/services/inventoryService.ts
coderabbitai[bot] (Migrated from github.com) commented 2024-10-17 09:12:22 -07:00
Copy Link

⚠️ Potential issue

Call inventory.markModified('CustomMarkers') after updating nested properties

When modifying nested properties such as map.markerInfos, it's necessary to notify Mongoose to ensure the changes are persisted.

Apply this diff:

         if (map) {
             map.markerInfos = markers.markerInfos;
+            inventory.markModified('CustomMarkers');
         } else {
             inventory.CustomMarkers ??= [];
             inventory.CustomMarkers.push(markers);
+            inventory.markModified('CustomMarkers');
         }
📝 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 (CustomMarkers) {
        CustomMarkers.forEach(markers => {
            const map = inventory.CustomMarkers
                ? inventory.CustomMarkers.find(entry => entry.tag == markers.tag)
                : undefined;
            if (map) {
                map.markerInfos = markers.markerInfos;
                inventory.markModified('CustomMarkers');
            } else {
                inventory.CustomMarkers ??= [];
                inventory.CustomMarkers.push(markers);
                inventory.markModified('CustomMarkers');
            }
        });
_:warning: Potential issue_ **Call `inventory.markModified('CustomMarkers')` after updating nested properties** When modifying nested properties such as `map.markerInfos`, it's necessary to notify Mongoose to ensure the changes are persisted. Apply this diff: ```diff if (map) { map.markerInfos = markers.markerInfos; + inventory.markModified('CustomMarkers'); } else { inventory.CustomMarkers ??= []; inventory.CustomMarkers.push(markers); + inventory.markModified('CustomMarkers'); } ``` <!-- suggestion_start --> <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 (CustomMarkers) { CustomMarkers.forEach(markers => { const map = inventory.CustomMarkers ? inventory.CustomMarkers.find(entry => entry.tag == markers.tag) : undefined; if (map) { map.markerInfos = markers.markerInfos; inventory.markModified('CustomMarkers'); } else { inventory.CustomMarkers ??= []; inventory.CustomMarkers.push(markers); inventory.markModified('CustomMarkers'); } }); ````` </details> <!-- suggestion_end --> <!-- This is an auto-generated comment by CodeRabbit -->
src/types/inventoryTypes/inventoryTypes.ts
@ -919,0 +932,4 @@
anchorName: string;
color: number;
label?: string;
x: number;
coderabbitai[bot] (Migrated from github.com) commented 2024-10-17 09:12:21 -07:00
Copy Link

🛠️ Refactor suggestion

Define a specific type for the icon property in IMarkerInfo

The icon property is typed as string. If the icons are selected from a predefined set, consider using a string literal union type or an enum to enforce valid values and improve code reliability.

_:hammer_and_wrench: Refactor suggestion_ **Define a specific type for the `icon` property in `IMarkerInfo`** The `icon` property is typed as `string`. If the icons are selected from a predefined set, consider using a string literal union type or an enum to enforce valid values and improve code reliability. <!-- This is an auto-generated comment by CodeRabbit -->
coderabbitai[bot] (Migrated from github.com) reviewed 2024-10-17 09:28:19 -07:00
coderabbitai[bot] (Migrated from github.com) left a comment
Copy Link

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (5)
src/models/inventoryModels/inventoryModel.ts (1)

935-937: Set a default value for 'CustomMarkers' in 'inventorySchema'

The CustomMarkers field in inventorySchema is defined without a default value. To prevent potential issues with undefined values and ensure consistency, consider setting a default value.

Apply this diff to set a default value:

     //https://warframe.fandom.com/wiki/Loc-Pin
-    CustomMarkers: { type: [CustomMarkersSchema], default: undefined },
+    CustomMarkers: { type: [CustomMarkersSchema], default: [] },
src/services/inventoryService.ts (4)

Line range hint 752-755: Simplify syndicate updates using nullish coalescing operator

You can simplify the assignments of syndicate.Standing and syndicate.Title by using the nullish coalescing operator ?? for better readability.

Apply the following diff to simplify the code:

             if (syndicate !== undefined) {
-                syndicate.Standing =
-                    syndicate.Standing === undefined ? affiliation.Standing : syndicate.Standing + affiliation.Standing;
-                syndicate.Title = syndicate.Title === undefined ? affiliation.Title : syndicate.Title + affiliation.Title;
+                syndicate.Standing = (syndicate.Standing ?? 0) + affiliation.Standing;
+                syndicate.Title = (syndicate.Title ?? 0) + affiliation.Title;
             } else {
                 inventory.Affiliations.push({

Line range hint 752-755: Ensure Mongoose tracks changes to nested 'Affiliations'

When modifying nested properties like syndicate.Standing and syndicate.Title, you need to inform Mongoose to persist these changes.

Apply this diff to mark the field as modified:

             if (syndicate !== undefined) {
                 syndicate.Standing = (syndicate.Standing ?? 0) + affiliation.Standing;
                 syndicate.Title = (syndicate.Title ?? 0) + affiliation.Title;
+                inventory.markModified('Affiliations');
             } else {
                 inventory.Affiliations.push({

Line range hint 776-777: Mark 'EvolutionProgress' as modified after updates

When updating properties within entry, such as Progress and Rank, ensure that you call inventory.markModified('EvolutionProgress') to persist the changes.

Apply the following diff:

                if (entry) {
                    entry.Progress = evoProgress.Progress;
                    entry.Rank = evoProgress.Rank;
+                   inventory.markModified('EvolutionProgress');
                } else {
                    inventory.EvolutionProgress ??= [];

Line range hint 749-804: Consider refactoring 'missionInventoryUpdate' for better maintainability

The missionInventoryUpdate function has grown significantly and now handles multiple responsibilities. To improve maintainability and readability, consider refactoring the function by extracting each major update section (e.g., AffiliationChanges, EvolutionProgress, CustomMarkers) into separate helper functions.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between b543392f34 and 7fc60e70f2.

📒 Files selected for processing (2)
  • src/models/inventoryModels/inventoryModel.ts (3 hunks)
  • src/services/inventoryService.ts (4 hunks)
🧰 Additional context used
🔇 Additional comments (6)
src/models/inventoryModels/inventoryModel.ts (4)

597-603: LGTM: markerInfoSchema looks good

The markerInfoSchema is well-structured and correctly references the markerSchema for the markers field.

605-611: LGTM: CustomMarkersSchema looks good

The CustomMarkersSchema is well-defined and correctly references the markerInfoSchema for the markerInfos field.

Line range hint 584-937: Summary of changes: Custom Markers implementation

The implementation of Custom Markers (Loc-Pins) has been successfully added to the inventory model. This includes:

  1. New schemas: markerSchema, markerInfoSchema, and CustomMarkersSchema.
  2. Integration of CustomMarkers into the inventorySchema.

These changes align well with the PR objectives to address the saving functionality of loc-pins for CustomMarkers. The structure allows for efficient storage and retrieval of custom marker data within the inventory model.

A few minor improvements have been suggested:

  1. Reconsidering the data type for the color field in markerSchema.
  2. Setting a default value for the CustomMarkers field in inventorySchema.

Overall, the implementation looks solid and should effectively resolve the issues mentioned in the linked issue #404.

584-595: ⚠️ Potential issue

Consider the data type for the 'color' field in 'markerSchema'

The color field in markerSchema is defined as Number. If color represents a hexadecimal color code or a string value, it might be more appropriate to use String. Alternatively, if it represents RGB values, consider defining it as an object with r, g, and b components for clarity.

Apply this diff to update the color field:

         anchorName: String,
-        color: Number,
+        color: String,
         label: String,

Or, if using RGB components:

         anchorName: String,
-        color: Number,
+        color: {
+            r: Number,
+            g: Number,
+            b: Number
+        },
         label: String,

Likely invalid or redundant comment.

src/services/inventoryService.ts (2)

790-803: Great job handling 'CustomMarkers' updates

You've correctly updated CustomMarkers and called inventory.markModified("CustomMarkers") after modifying nested properties, ensuring Mongoose will persist the changes.

734-738: Verify that IMissionInventoryUpdateRequest includes new properties

The missionInventoryUpdate function now destructures additional properties: AffiliationChanges, EvolutionProgress, LastRegionPlayed, and CustomMarkers from data. Ensure that the IMissionInventoryUpdateRequest interface includes these new properties or appropriately extends the interface to accommodate them.

Run the following script to verify the interface definition:

✅ Verification successful

Verified: IMissionInventoryUpdateRequest includes all the new properties (AffiliationChanges, EvolutionProgress, LastRegionPlayed, and CustomMarkers) as required.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if IMissionInventoryUpdateRequest includes the new properties

# Test: Search for the definition of IMissionInventoryUpdateRequest.
ast-grep --lang typescript --pattern $'interface IMissionInventoryUpdateRequest {
  $$$
}' src/types/requestTypes.ts

Length of output: 2306

**Actionable comments posted: 0** <details> <summary>🧹 Outside diff range and nitpick comments (5)</summary><blockquote> <details> <summary>src/models/inventoryModels/inventoryModel.ts (1)</summary><blockquote> `935-937`: **Set a default value for 'CustomMarkers' in 'inventorySchema'** The `CustomMarkers` field in `inventorySchema` is defined without a default value. To prevent potential issues with undefined values and ensure consistency, consider setting a default value. Apply this diff to set a default value: ```diff //https://warframe.fandom.com/wiki/Loc-Pin - CustomMarkers: { type: [CustomMarkersSchema], default: undefined }, + CustomMarkers: { type: [CustomMarkersSchema], default: [] }, ``` </blockquote></details> <details> <summary>src/services/inventoryService.ts (4)</summary><blockquote> Line range hint `752-755`: **Simplify syndicate updates using nullish coalescing operator** You can simplify the assignments of `syndicate.Standing` and `syndicate.Title` by using the nullish coalescing operator `??` for better readability. Apply the following diff to simplify the code: ```diff if (syndicate !== undefined) { - syndicate.Standing = - syndicate.Standing === undefined ? affiliation.Standing : syndicate.Standing + affiliation.Standing; - syndicate.Title = syndicate.Title === undefined ? affiliation.Title : syndicate.Title + affiliation.Title; + syndicate.Standing = (syndicate.Standing ?? 0) + affiliation.Standing; + syndicate.Title = (syndicate.Title ?? 0) + affiliation.Title; } else { inventory.Affiliations.push({ ``` --- Line range hint `752-755`: **Ensure Mongoose tracks changes to nested 'Affiliations'** When modifying nested properties like `syndicate.Standing` and `syndicate.Title`, you need to inform Mongoose to persist these changes. Apply this diff to mark the field as modified: ```diff if (syndicate !== undefined) { syndicate.Standing = (syndicate.Standing ?? 0) + affiliation.Standing; syndicate.Title = (syndicate.Title ?? 0) + affiliation.Title; + inventory.markModified('Affiliations'); } else { inventory.Affiliations.push({ ``` --- Line range hint `776-777`: **Mark 'EvolutionProgress' as modified after updates** When updating properties within `entry`, such as `Progress` and `Rank`, ensure that you call `inventory.markModified('EvolutionProgress')` to persist the changes. Apply the following diff: ```diff if (entry) { entry.Progress = evoProgress.Progress; entry.Rank = evoProgress.Rank; + inventory.markModified('EvolutionProgress'); } else { inventory.EvolutionProgress ??= []; ``` --- Line range hint `749-804`: **Consider refactoring 'missionInventoryUpdate' for better maintainability** The `missionInventoryUpdate` function has grown significantly and now handles multiple responsibilities. To improve maintainability and readability, consider refactoring the function by extracting each major update section (e.g., `AffiliationChanges`, `EvolutionProgress`, `CustomMarkers`) into separate helper functions. </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used: .coderabbit.yaml** **Review profile: CHILL** <details> <summary>📥 Commits</summary> Files that changed from the base of the PR and between b543392f34b38f4b813fd5044e6574eb1d9aaaec and 7fc60e70f2b7fd6d4bb64beede885d4b69ae34d4. </details> <details> <summary>📒 Files selected for processing (2)</summary> * src/models/inventoryModels/inventoryModel.ts (3 hunks) * src/services/inventoryService.ts (4 hunks) </details> <details> <summary>🧰 Additional context used</summary> </details> <details> <summary>🔇 Additional comments (6)</summary><blockquote> <details> <summary>src/models/inventoryModels/inventoryModel.ts (4)</summary><blockquote> `597-603`: **LGTM: markerInfoSchema looks good** The `markerInfoSchema` is well-structured and correctly references the `markerSchema` for the `markers` field. --- `605-611`: **LGTM: CustomMarkersSchema looks good** The `CustomMarkersSchema` is well-defined and correctly references the `markerInfoSchema` for the `markerInfos` field. --- Line range hint `584-937`: **Summary of changes: Custom Markers implementation** The implementation of Custom Markers (Loc-Pins) has been successfully added to the inventory model. This includes: 1. New schemas: `markerSchema`, `markerInfoSchema`, and `CustomMarkersSchema`. 2. Integration of `CustomMarkers` into the `inventorySchema`. These changes align well with the PR objectives to address the saving functionality of loc-pins for CustomMarkers. The structure allows for efficient storage and retrieval of custom marker data within the inventory model. A few minor improvements have been suggested: 1. Reconsidering the data type for the `color` field in `markerSchema`. 2. Setting a default value for the `CustomMarkers` field in `inventorySchema`. Overall, the implementation looks solid and should effectively resolve the issues mentioned in the linked issue #404. --- `584-595`: _:warning: Potential issue_ **Consider the data type for the 'color' field in 'markerSchema'** The `color` field in `markerSchema` is defined as `Number`. If `color` represents a hexadecimal color code or a string value, it might be more appropriate to use `String`. Alternatively, if it represents RGB values, consider defining it as an object with `r`, `g`, and `b` components for clarity. Apply this diff to update the `color` field: ```diff anchorName: String, - color: Number, + color: String, label: String, ``` Or, if using RGB components: ```diff anchorName: String, - color: Number, + color: { + r: Number, + g: Number, + b: Number + }, label: String, ``` > Likely invalid or redundant comment. </blockquote></details> <details> <summary>src/services/inventoryService.ts (2)</summary><blockquote> `790-803`: **Great job handling 'CustomMarkers' updates** You've correctly updated `CustomMarkers` and called `inventory.markModified("CustomMarkers")` after modifying nested properties, ensuring Mongoose will persist the changes. --- `734-738`: **Verify that `IMissionInventoryUpdateRequest` includes new properties** The `missionInventoryUpdate` function now destructures additional properties: `AffiliationChanges`, `EvolutionProgress`, `LastRegionPlayed`, and `CustomMarkers` from `data`. Ensure that the `IMissionInventoryUpdateRequest` interface includes these new properties or appropriately extends the interface to accommodate them. Run the following script to verify the interface definition: <details> <summary>✅ Verification successful</summary> <!-- [monologue] [task verify_interface_1/1] [observations] - The shell script executed `ast-grep` to locate the `IMissionInventoryUpdateRequest` interface within `src/types/requestTypes.ts`. - The output lists the interface definition spanning lines 45 to 77. - Specifically, the properties `AffiliationChanges`, `EvolutionProgress`, `LastRegionPlayed`, and `CustomMarkers` are present at lines 48, 72, 73, and 74 respectively. [analysis] - The presence of all four properties in the `IMissionInventoryUpdateRequest` interface confirms that it includes the newly introduced properties. - No discrepancies or omissions were found in the interface definition concerning the review comment. [actions] - Conclude that the verification is successful. - Generate the final response indicating that the interface includes the required properties. --> **Verified**: `IMissionInventoryUpdateRequest` includes all the new properties (`AffiliationChanges`, `EvolutionProgress`, `LastRegionPlayed`, and `CustomMarkers`) as required. </details> <details> <summary>🏁 Scripts executed</summary> The following scripts were executed for the analysis: Script: ```shell #!/bin/bash # Description: Check if IMissionInventoryUpdateRequest includes the new properties # Test: Search for the definition of IMissionInventoryUpdateRequest. ast-grep --lang typescript --pattern $'interface IMissionInventoryUpdateRequest { $$$ }' src/types/requestTypes.ts ``` Length of output: 2306 </details> </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
Sainan commented 2025-01-31 08:04:01 -08:00
Copy Link

This PR has a few merge conflicts due to the introduction of quests. Would you be willing and able to rebase it?

This PR has a few merge conflicts due to the introduction of quests. Would you be willing and able to rebase it?
Sainan commented 2025-02-01 07:29:25 -08:00
Copy Link

Superseded by #879

Superseded by #879
Sainan closed this pull request 2025-02-01 07:29:26 -08:00
Sainan deleted branch AMelonInsideLemon/custom-markers 2025-02-01 07:29:39 -08:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
bug
An existing implemention is incorrect
dependencies
Pull requests that update a dependency file
documentation
Improvements or additions to documentation
enhancement
New feature or request specific to the emulator
help wanted
Extra attention is needed
improvement
missing data
part of more major rehaul
Can't be worked on right now without merge conflicts later
pr'd for
Soon™
question
Further information is requested
unimplemented
you can do this
Considered easy enough for someone's first PR.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: OpenWF/SpaceNinjaServer#485
No description provided.
Delete Branch "AMelonInsideLemon/custom-markers"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?