2.0 WIP

[shibatales]

BASIC? Lol

On Tue, Jun 22, 2021, 4:22 PM Yuri @.***> wrote:

@Yuripetusko commented on this pull request.

In standards/rmrk2.0.0/interactions/baseeq.md https://github.com/rmrk-team/rmrk-spec/pull/27#discussion_r656630635:

@@ -0,0 +1,65 @@ +# BASEEQ

why is it called EQ, not sure on semantic meaning of this, would prefer something more descriptive

In standards/rmrk2.0.0/interactions/baseeq.md https://github.com/rmrk-team/rmrk-spec/pull/27#discussion_r656632835:

+If we later want to add another collection into the mix, we issue: + +bash +rmrk::BASEEQ::2.0.0::kanaria-epic-birds::wing_slot_1::+0aff6865bed3a66b-FOO + + +This is submitted as: + +bash +0x726d726b3a3a4241534545513a3a322e302e303a3a6b616e617269612d657069632d62697264733a3a77696e675f736c6f745f313a3a306166663638363562656433613636622d444c4550 + + +When consolidated, the final result of the equippable field of this base is: + +```bash +"equippable": ["0aff6865bed3a66b-DLEP", "0aff6865bed3a66b-FOO"]

Good to add how it will look if * is passed

In standards/rmrk2.0.0/entities/base.md https://github.com/rmrk-team/rmrk-spec/pull/27#discussion_r656642182:

• "gem_5": {
• // ...
• },
• "wing_1_back": {
• "type": "fixed",
• "z": 1,
• "src": "ipfs://ipfs/hash"
• },
• "wing_1_front": {
• "type": "fixed",
• "z": 3,
• "src": "ipfs://ipfs/hash2"
• },
• "wing_1_slot": {
• "type": "slot",
• "equippable": ["id-of-genesis-legendaries", "id-of-genesis-rares", "id-of-genesis-epics", ...],

In this example you use both equippable and collections as array of allowed collections?

In standards/rmrk2.0.0/entities/base.md https://github.com/rmrk-team/rmrk-spec/pull/27#discussion_r656645771:

+ +The renderer will take the content behind the src value, and place it into the viewport at the Z +index defined. The renderer does not check that the viewport of all parts matches - this is up to +the designer (refer to the image above). + +Slot parts have a type of slot and no static resource src. They are meant to visually accept +other NFTs into them. They have an array of whitelisted equippable collections, and an optional +unequip value. + +The equippable value is a list of collections equippable into this slot. This value can also be a +wildcard * to allow any collection to be equippable into this slot without special approval from +the base owner. The whitelisting can be useful to prevent others from "hijacking" your project with +their own customizations, covering all your art and branding. + +The optional unequip value specifies what happens to an item once it's unequipped. This is useful +for one-off bonuses, NFTs that expire, and so on. The values can be inv for inventory and burn.

nice, but do you think we will need many different types here or we can simply say burnOnUnequip: boolean or perhaps multiuse: boolean

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rmrk-team/rmrk-spec/pull/27#pullrequestreview-690058497, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATZ7XK6OEDH73VMBJ3ZUIQLTUELMVANCNFSM47DOD3EA .

[Yuripetusko]

Is there a way to CONSUME a BASE?

[Swader]

Is there a way to CONSUME a BASE?

no

[Yuripetusko]

Let's make EMOTE resource uppercase

export enum EMOTE_NAMESPACES {
  RMRK1 = "RMRK1",
  RMRK2 = "RMRK2",
  PUBKEY = "PUBKEY",
}