extend feature of datapack (without breaking parity) - #243
Conversation
|
This pull request has conflicts with the base branch "master". Please resolve those so we can test out your changes. |
|
Conflicts have been resolved! 🎉 |
I have check and it match vanilla, will do a quick self review
|
|
This pull request has conflicts with the base branch "master". Please resolve those so we can test out your changes. |
|
Conflicts have been resolved! 🎉 |
|
This pull request has conflicts with the base branch "master". Please resolve those so we can test out your changes. |
|
will you continue this PR and finish it? |
|
Conflicts have been resolved! 🎉 |
|
I have update the branch, so will check file that I have modified and then I will make it non draft |
There was a problem hiding this comment.
I found that modification on this file are hacky, but it's in the continuity of what we already have, I think that a loot_table pr will fix that but would also require modify steel-core but don't want to do this work on this pr, so do I do something to cleaning up or it will be discarded anyway in a loot table pr so no need to make it clean ?
There was a problem hiding this comment.
at then just revert most modification on loot table to let another pr implement loot table properly
|
This pull request has conflicts with the base branch "master". Please resolve those so we can test out your changes. |
|
ok ready again |
… from datapack-overlay
|
Conflicts have been resolved! 🎉 |
4 participants
This pr add alias that datapack can (datapack can use minecraft:noise and noise for example), modify some type to better corespond to all types that field can accept (like for color using both string and number) and other adjustement.
Why doing this ?
While the vanilla datapack for now don't use all of this, it's possible value that the datapack can evolve to, so doing now avoid to doing later when they do the change. I also have another branch that this time allow to build steel with datapack (only json not mcfunction) coco875#2.