Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimal EIP2535 implementation of Inventory #324

Merged
merged 31 commits into from
Aug 1, 2023
Merged

Minimal EIP2535 implementation of Inventory #324

merged 31 commits into from
Aug 1, 2023

Conversation

zomglings
Copy link
Collaborator

This PR introduces a minimal EIP2535 implementation of an inventory into this repository. This implementation is adapted from the original implementation at https://github.com/G7DAO/contracts.

We have added this implementation here for two reasons:

  1. Having an implementation in this repository makes our operations much simpler as we can access all our contracts using a single CLI. Previously, we were interacting with the inventory with the game7ctl CLI while all other contract interactions were done with the CLI in this repo.
  2. We have made several simplifications to the Inventory contract that might break Game7's deployment pipelines. This is less painful for all involved.

Resolves #319 and #322

zomglings and others added 25 commits July 26, 2023 21:02
These were just there to generate the Python scripts, which will need to
be updated to support the new Inventory anyway.
That file was only there to generate the CLI before.

CLI will need to be updated, as will the setup-inventory script.
And organized it to be flatter (file structure).
As a part of this, I also added:

1. The ability to specify existing facets for diamond_gogogo and for
   inventory_gogogo. This lays the foundation to eventually resolve
   #315

2. A fix for #323
`g7dao` -> `moonstreamdao`
It complicates scope and was only being used twice.
And made comments more accurate
The slot types are implicitly defined by the items that can be equipped
in those slots.

Having an explicit notion of slot type with no conceivable way to enforce
it creates two sources of truth about what a slot does - it's type and
the set of items equippable in that slot. This makes the system more
complex and difficult to work with, with no additional benefit.
This required a negation in contract `_unequip` logic.

I also changed the signature of `setSlotPersistent`.

There are currently  no tests for `setSlotPersistent`.
TODO(zomglings): Write them!
No need to index the slot itself - that will only be emitted once.

We are now indexing the persistence.
Also, unindexed `persistent` from `SlotCreated` event.
Removed `persistent` argument from the `SlotCreated` event - it is
duplicated in the `NewSlotPersistence` emission.
class method in `InventoryTestCase`. This will make it easier to test
other Inventory implementations in the future.
Also added `NewSlotPersistence` event emission from that method.
Copy link
Contributor

@kellan-simiotics kellan-simiotics left a comment

Choose a reason for hiding this comment

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

I'm not sure if there is anything critical missing, but the contract is rather difficult to use if you can ask a slot for all of its equippable options. Ran into this difficulty during CG testing.

slot.SlotURI = newSlotURI;
istore.SlotData[slotId] = slot;
emit NewSlotURI(slotId);
}

function slotIsUnequippable(uint256 slotId) external view returns (bool) {
function slotIsPersistent(uint256 slotId) external view returns (bool) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we attached to this name? I don't like IsUnequippable, but I don't like IsPersistent much better. Maybe we could pick a name with the same polarity... IsChangeable?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This name was suggested by Diniz from OP Games. He subclassed InventoryFacet for their usage.

It is also a name that people have responded well to.

I suggest we merge this PR in with Persistent as the name, and we can change it later based on research and feedback.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1

contracts/inventory/IInventory.sol Show resolved Hide resolved
@@ -282,7 +234,14 @@ contract InventoryFacet is
address itemAddress,
uint256 itemPoolId,
uint256 maxAmount
) external onlyAdmin requireValidItemType(itemType) {
) external onlyAdmin {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we need a way to see all of the equippable items for a slot. Am I missing a way we are exposing this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I don't even know how to expose this on-chain without adding an enumeration.

That can be an extension of the base interface (see IERC721Enumerable, which is an extension of IERC721). I personally prefer to get that information from events. I don't think it's necessary to the system.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, but contract administrators won't always have easy access to the events. Can't we just dump the SlotEligibleItems object?

cli/web3cli/test_inventory.py Outdated Show resolved Hide resolved
cli/web3cli/test_inventory.py Outdated Show resolved Hide resolved
)

def test_player_cannot_unequip_erc20_tokens_from_persistent_slot_but_can_increase_amount(self):
"""
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should change the test name to indicate the test is broken or just comment out the whole test for now. I read through equip / _unequip methods a couple times before I noticed the comment that noted this test was unfinished as the functionality was missing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I renamed the test to test_player_cannot_unequip_erc20_tokens_from_persistent_slot.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It's still a useful test as it tests persistence of slots.

Neeraj Kashyap added 3 commits August 1, 2023 13:55
I was using an ERC20 token to test ERC721 behavior in the inventory.

The tests asserted a `VirtualMachineError`, which could have been
triggered by the incorrect use of an ERC20 token as an ERC721 token.
Copy link
Contributor

@kellan-simiotics kellan-simiotics left a comment

Choose a reason for hiding this comment

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

lg

@zomglings zomglings merged commit 5d12e3e into main Aug 1, 2023
@zomglings zomglings deleted the inventory branch August 1, 2023 23:43
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.

Definition of minimal Inventory interface
2 participants