-
Notifications
You must be signed in to change notification settings - Fork 44
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
[FEATURE] Trait dependencies #29
Comments
@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. |
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.
|
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: { The way this would then work is as follow:
|
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. |
Keen to hear your thoughts and thanks for the collaboration and bouncing of ideas! |
Added a new configuration option on the layerConfigurations array object in the
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: The 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. |
nice. Will check it out. |
I have a folder with two subfolders. I thought etc "Body/Black": etc |
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.
The text was updated successfully, but these errors were encountered: