Skip to content

Data component cleanup - #1220

Open
Robotgiggle wants to merge 7 commits into
1.21from
component-scrunch
Open

Data component cleanup#1220
Robotgiggle wants to merge 7 commits into
1.21from
component-scrunch

Conversation

@Robotgiggle

@Robotgiggle Robotgiggle commented Jul 30, 2026

Copy link
Copy Markdown
Member

The HEX_HOLDER_PATTERNS and PIGMENT components, 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 called HEX_HOLDER that 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:

  • fixes Ancient Cyphers not having the Ancient Pigment baked in (I think this just got lost in the port somehow)
  • fixes the safety check on creative scrolls now that the ACTION component stores a ResourceKey rather than a ResourceLocation
  • fixes a typo when setting the MEDIA and MAX_MEDIA components using ItemMediaHolder.withMedia()
  • removes the now unused string constants that previously stored the names of the NBT tags used by casting items, media holders, and the media cube
  • adds comments to HexDataComponents explaining where each component is used
  • adds comments to ItemSpellbook to explain some of the more complicated if/else trees
  • updates the comments in ItemScroll to refer to components rather than tags

return UseAnim.BLOCK;
}

public record HexHolder(List<Iota> hex, FrozenPigment pigment) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

@Robotgiggle
Robotgiggle marked this pull request as draft July 30, 2026 06:42
@Robotgiggle
Robotgiggle marked this pull request as ready for review July 30, 2026 07:04
@Olfi01

Olfi01 commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Wouldn't it be possible to make even alpha versions of items correctly readable by using Codecs?

@Robotgiggle

Robotgiggle commented Jul 30, 2026

Copy link
Copy Markdown
Member Author

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?

@Olfi01

Olfi01 commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

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

@IridescentVoid IridescentVoid added optimization Improvement to existing features or performance (no new features or design work) 1.21 labels Jul 30, 2026
@Olfi01

Olfi01 commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

After getting into it a bit, I think a datafix for alpha items should definitely be possible, the only question I'm having is how to get it to run since the vanilla process appears to be tied to save file versions and I'm pretty sure that's the same between before and after this commit.
Edit: Looking at it again, it seems to be possible to create a subversion for the schema, I'll fiddle around with that a bit to see if it's a viable option
Edit 2: No, just using the subversion still runs into the same issue that the versions are defined by MC and haven't actually changed during this commit

@Olfi01 Olfi01 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me apart from the one @Nullable nitpick :D

Comment thread Common/src/main/java/at/petrak/hexcasting/common/items/magic/ItemPackagedHex.java Outdated
}

// I'm disabling this stuff rather than changing it to fit the merged components,
// because it doesn't seem to work anyway (tested fabric 1.20 -> 1.21, nothing got migrated)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you could even remove all the migrations, since they should be covered by #1226 anyway

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems like something to do in #1226 rather than here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

1.21 optimization Improvement to existing features or performance (no new features or design work)

Projects

Status: 📋 Backlog

Development

Successfully merging this pull request may close these issues.

4 participants