-
Notifications
You must be signed in to change notification settings - Fork 10
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
Conversation
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).
from https://github.com/G7DAO/contracts And I got the tests working.
`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!
Unnecessary.
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.
... emission from `createSlot`.
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.
This is only one of the tests we need to write for this behavior
There was a problem hiding this 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) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
@@ -282,7 +234,14 @@ contract InventoryFacet is | |||
address itemAddress, | |||
uint256 itemPoolId, | |||
uint256 maxAmount | |||
) external onlyAdmin requireValidItemType(itemType) { | |||
) external onlyAdmin { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
) | ||
|
||
def test_player_cannot_unequip_erc20_tokens_from_persistent_slot_but_can_increase_amount(self): | ||
""" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lg
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:
game7ctl
CLI while all other contract interactions were done with the CLI in this repo.Resolves #319 and #322