Data component cleanup - #1220
Conversation
| return UseAnim.BLOCK; | ||
| } | ||
|
|
||
| public record HexHolder(List<Iota> hex, FrozenPigment pigment) { |
There was a problem hiding this comment.
Would there be any value in making this a TreeList? I actually doubt it (I think it would need to be benchmarked) and converting on-use is going to be better than converting on-parse).
|
Wouldn't it be possible to make even alpha versions of items correctly readable by using Codecs? |
|
How would you do that? The current alpha version uses two separate components, and the new version in this PR uses one component with two fields. I know you can make a codec that accepts input in multiple formats, but that’s still just expecting multiple formats within one data component. Is there some way to make a codec that can decode two separate components into a single object? |
|
Right, sorry, that does sound like it might not be possible. What could be an option would be adding another datafixer, but I'll only be able to answer whether I think that's a good idea after I've finished doing it for the 1.20 -> 1.21 migration |
The
HEX_HOLDER_PATTERNSandPIGMENTcomponents, used for casting items, are both set when a hex is written into the item and both cleared when the item is erased. There is no situation in which the value or presence of one would change without the other also changing. Thus, there's no reason for them to be two separate components, so this PR combines them into a single component calledHEX_HOLDERthat stores both a list of iotas and a FrozenPigment.This will break any casting items that were created in 1.21 worlds before this change, but the 1.21 version is still in alpha so I think that's OK.
Along with combining the components as described above, this PR also:
ACTIONcomponent stores a ResourceKey rather than a ResourceLocationMEDIAandMAX_MEDIAcomponents using ItemMediaHolder.withMedia()