Skip to content

feat: deletion restrictions - #1611

Draft
aronwk-aaron wants to merge 1 commit into
mainfrom
issue-960
Draft

aronwk-aaron wants to merge 1 commit into
mainfrom
issue-960

Conversation

@aronwk-aaron

@aronwk-aaron aronwk-aaron commented Jun 7, 2024 •

Copy link
Copy Markdown
Member

On behalf of @aronwk-aaron (written by Claude).

Deleting an item now follows the item's DeletionRestrictions row (ItemComponent.delResIndex), as the client's LWOInventoryComponent_Common::CanRemoveFromInventory (0x00ce0d20) and CheckDeletionRestrictionIndex (0x00c94c20) do. This is what keeps a player from deleting their last rocket and getting stranded.

  • An item the player is driving or riding can't be deleted; an operator (GM 9) can delete anything.
  • Otherwise the row decides:
    • LOTS_INCLUDED: only while the player has another item of any of the LOTs (rows 1-3: the rocket and its parts)
    • LOTS_EXCLUDED: only while the player has other items of all of the LOTs
    • ANY_RESTRICTION / ALL_RESTRICTIONS: any / all of the listed rows allow it (a row that names itself again allows it)
    • ZONE: only in the listed zones
    • ALWAYS_RESTRICTED: never
  • A missing, unrestricted or bad row (no valid ids, unknown check type) allows it.
  • The client checks first and shows the row's failure reason; HandleRemoveItemFromInventory checks again and ignores a client's forceDeletion.

Tests cover each check type, row combinations, a self-referencing row and bad rows.

Refs issue 960

🤖 Generated with Claude Code

Comment thread dDatabase/CDClientDatabase/CDClientTables/CDDeletionRestrictionsTable.cpp Outdated
Comment thread dDatabase/CDClientDatabase/CDClientTables/CDDeletionRestrictionsTable.cpp Outdated
Comment thread dDatabase/CDClientDatabase/CDClientTables/CDDeletionRestrictionsTable.cpp Outdated
Comment thread dGame/dInventory/Item.cpp Outdated
Comment thread dDatabase/CDClientDatabase/CDClientTables/CDDeletionRestrictionsTable.cpp Outdated
void LoadValuesFromDatabase();
const CDDeletionRestriction& GetByID(uint32_t id);

static CDDeletionRestriction Default;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great if this could be not public, and instead use a getter which returns a const reference to a default struct so this cannot be modified accidentally, alongside removing a static variable in place for a static function and an unnamed namespace member.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tell that to itemComponentTable

@EmosewaMC

Copy link
Copy Markdown
Collaborator

thank you for adding the new table! Let's try and clean it up a bit since I know our table reading in other places is quite messy and tends to spider web to other tables. Some extra feedback was left on the logic for the check as well :)

Deleting an item now follows the item's DeletionRestrictions row (ItemComponent.delResIndex), as the client's LWOInventoryComponent_Common::CanRemoveFromInventory (0x00ce0d20) and CheckDeletionRestrictionIndex (0x00c94c20) do: an item the player is driving or riding can't be deleted, an operator can delete anything, and otherwise the row decides:
- LOTS_INCLUDED: only while the player has another item of any of the LOTs (the last rocket can't be deleted)
- LOTS_EXCLUDED: only while the player has other items of all of the LOTs
- ANY_RESTRICTION / ALL_RESTRICTIONS: any / all of the listed rows allow it (a row that names itself again allows it)
- ZONE: only in the listed zones
- ALWAYS_RESTRICTED: never
A missing, unrestricted or bad row (no valid ids, unknown check type) allows it. The client checks first and shows the row's failure reason; the server checks again and ignores a client's forceDeletion.

Refs issue 960

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants