[FEATURE] Trait dependencies

[thoechsmann]

New exclusion rule that allows to setup dependencies between traits.
Use it when one trait will require a specific other trait. For those cases it is much shorter to define compared to the exclusion rules. You can also set an option to fix the dependency instead of rejecting those configurations. This can speed up generation dramatically when many dependency rules are set.

[thepeanutgalleryandco]

@thoechsmann just thinking about this feature a bit, how would you handle it if someone configures multiple dependency traits for a single trait?

For example: I have a dependency trait for Background: Cyan , to only include Eyes: White. Then I have a second dependency trait for Background: Cyan , to only include Eyes: Red. Which one will hold true or should both hold true?

This is why I sort of see the feature as an inclusion rule, meaning that only if these traits combinations are available, then the NFT should be created. Otherwise, the NFT that got created should be rejected. Basically the opposite of the exclusion rule.

I experienced how long the exclusion list can become while helping another user, where the developer had 20 layer items in a layer, and the developer only wanted a combination with a single item in that layer. The developer had to exclude the 19 items instead of simply stating the item that he wanted to combine and only allow that combination.

[thoechsmann]

All dependencies must be fulfilled. In your example all will be rejected. The problem with many dependencies is that the likelihood of a valid dna get very small quickly. That why I also add an option to fix the dna instead of rejecting it. In your example that would mean that each rule will get fixed after each other. So the last rule in that example would win.

…

Am 05.03.2022 um 12:37 schrieb Rohan de Jongh ***@***.***>:  @thoechsmann just thinking about this feature a bit, how would you handle it if someone configures multiple dependency traits for a single trait? For example: I have a dependency trait for Background: Cyan , to only include Eyes: White. Then I have a second dependency trait for Background: Cyan , to only include Eyes: Red. Which one will hold true or should both hold true? This is why I sort of see the feature as an inclusion rule, meaning that only if these traits combinations are available, then the NFT should be created. Otherwise, the NFT that got created should be rejected. Basically the opposite of the exclusion rule. I experienced how long the exclusion list can become while helping another user, where the developer had 20 layer items in a layer, and the developer only wanted a combination with a single item in that layer. The developer had to exclude the 19 items instead of simply stating the item that he wanted to combine and only allow that combination. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.

[thepeanutgalleryandco]

I see that you are fixing the DNA within the filter, but are you also changing it in the main method to the correct image layer items for creating the actual image for the specific JSON file? I am not too keen on a DNA fix within the filter file itself

I would like to see an inclusion rule / trait dependency rule in the code base that could work in the following way. I am happy to work on it and do the conversion from exclusions to filters as well, so that we can also build on top of that going forward.

My thinking was the following:

compatibleTraits: {
"Eye color/Cyan": [
"Eyeball/Red",
],
"Iris/Large": [
"Bottom lid/High",
"Top lid/High",
],
"Background/Orange": [
"Bottom lid/High",
"Bottom lid/Low",
"Top lid/High",
]
}

The way this would then work is as follow:

1. Layer item "Eye Color/Cyan" must have a layer item "Eyeball/Red", otherwise the NFT will be rejected.
2. Layer item "Iris/Large" must have layer items "Bottom lid/High" and "Top lid/High", otherwise the NFT will be rejected.
3. Layer item "Background/Orange" must have layer items "Bottom lid/High" OR "Bottom lid/Low" and also have "Top lid/High", otherwise the NFT will be rejected.

[thoechsmann]

Looks good.

And yes, fixing in the filter is not very nice, but I need fixing as otherwise generating valid DNAs will get very unlikely in my use case, where we have one trait that is using 4 layers.

if there are compatible traits that have more than one option, should we also take into account potential trait probabilities?

The cleanest implementation would be to take filters already into account when the layers for the DNA get selected in the 1st place.

[thepeanutgalleryandco]

And yes, fixing in the filter is not very nice, but I need fixing as otherwise generating valid DNAs will get very unlikely in my use case, where we have one trait that is using 4 layers. - So you would like the fixing / change of DNA so that it ignores the wrong DNAs, like in the last point? I think if we handle this incrementally with main functionality going in first, and then later do the clean implementation of the filters at the point of layer selection, then this will be easier chunks to manage.

if there are compatible traits that have more than one option, should we also take into account potential trait probabilities? - Can you elaborate on this? I was thinking of keeping it as simple as possible

The cleanest implementation would be to take filters already into account when the layers for the DNA get selected in the 1st place. - I agree, perhaps we can keep this as part of a re-work, and just build the initial compatible functionality in.

Keen to hear your thoughts and thanks for the collaboration and bouncing of ideas!

[thepeanutgalleryandco]

Added a new configuration option on the layerConfigurations array object in the src/config.js file.

dependentTraits: {
      "Eye color/Cyan": [
        "Eyeball/White",
      ],
      "Background/Blue": [
        "Eyeball/Red",
        "Top lid/low"
      ],
}

This will check and ensure that if the layer item Cyan is select for Eye color, then the layer item White should be selected for the Eyeball layer, otherwise it will reject the edition. If the layer item Blue is selected for the Background layer, then Red should be selected for Eyeball, while low should be selected for Top lid layer, otherwise the edition will be rejected. If the edition contains both Cyan for the Eye color and Blue for the Background, then all three of the dependencies need to be selected for the edition, otherwise the edition will be rejected.

A new error will be shown to the user when the filtration rule rejects an edition:
Combination of traits filtered because of dependent traits filtration rule! Only 2/3 dependent layers were found.

The 2/3 will be dynamic, depending on how many traits were missing based on the dependency rules.

With filtration rules in place, users need to ensure that they have enough layers available to reach their specific NFT collection's growth size, or alternatively, reduce the filtration rules.

[thoechsmann]

nice. Will check it out.

[cesar4design]

I have a folder with two subfolders.
How to make a layer compatible with all traits from only one subfolder.

I thought

etc

"Body/Black":
[ "Right Hand/Black/*",

etc