Current Item Tracking - Resolved through ASM Patches

[Crain-32]

Reason

In order for Multiworld to Properly work with the current implementation, the Client needs to know when it should remove Items, and when it should give Items. This helps handle the player getting other player's items.

Expected Implementation

The expectation is a Singleton Class (PlayerInventory? InventoryManager? just make it relevant) with the following functions.

server_received_item(item_id: int,) -> bool:

• Anytime the Client receives an Item from the Server, this function is called to verify if giving it to the player would result in a duplicate, AND if the player can receive it, then add it to the Player's tracked inventory.
• If it returns False, then the Client should not send the Item to the AbstractGameHandler, and instead raise a DuplicateItemWarning, otherwise it should give the item to the AbstractGameHandler

server_sent_item(item_id: int) -> bool:

• Before sending an Item out to the Server this function is called to verify if the Player's Item they received should be removed from their inventory or not.

• If it returns True, then the Client should tell the AbstractGameHandler to remove the given Item ID from the Player.

  found_item(item_id:int) -> None:

• If the Player finds an Item, but the Item is for the player, the AbstractGameHandler should call this function in order to add it to the tracked Inventory.

current_items() -> dict[str, int]:

• Returns all the items in a dictionary of the following format

  {
  "Item Name": "Amount",
  "Deku Leaf": 1,
  "DRC Small Key": 3,
  # ETC....
  }

  Example Situations

  World One finds a Deku Leaf for World 2. World One already has their Deku Leaf.

• World One's AbstractGameHandler doesn't call found_item, as this belongs to a different World ID.

• Before World One sends the Deku Leaf to the Server, it calls server_sent_item, which returns False, as World One doesn't need to lose it's Deku Leaf

  • World Two's Client receives the Deku Leaf, and calls server_received_item, which returns True, so World Two's AbstractGameHandler gets the Deku Leaf, and gives it to the Player.

  World Three finds a DRC Small Key for World One, but World One already has 4 Tracked DRC Small Keys, and World Three has 2 Tracked DRC Small Keys

• World Three's AbstractGameHandler doesn't call found_item, as this belongs to a different World ID.
• Before World Three sends the DRC Small Key to the Server, it calls server_sent_item, which returns True, and so World Three's AbstractGameHandler removes a DRC Small Key from the Player.
  • World One's Client gets the DRC Small Key and calls server_received_time, which returns False, so the Client raises a DuplicateItemWarning and doesn't give the DRC Small Key to the Player.

[jaysc]

FYI https://stackoverflow.com/questions/6760685/creating-a-singleton-in-python

[Crain-32]

FYI https://stackoverflow.com/questions/6760685/creating-a-singleton-in-python

I'm not exactly positive about how singletons are related to this Issue. I reread the issue and noticed I used the word singleton. That's my bad, it can just be a class, smh Crain.

I believe the only instance of one was for the Config, which you've already made a PR for.