Skip to content

Resolve advancement icons lazily to avoid an intermittent RegisterEvent boot crash - #10534

Open
Jus144tice wants to merge 1 commit into
Creators-of-Create:mc1.21.1/devfrom
Jus144tice:fix/lazy-advancement-icon
Open

Resolve advancement icons lazily to avoid an intermittent RegisterEvent boot crash#10534
Jus144tice wants to merge 1 commit into
Creators-of-Create:mc1.21.1/devfrom
Jus144tice:fix/lazy-advancement-icon

Conversation

@Jus144tice

Copy link
Copy Markdown

Problem

AllAdvancements' static initializer builds every CreateAdvancement during the TRIGGER_TYPES RegisterEvent phase. CreateAdvancement.Builder#icon(ItemProviderEntry) eagerly resolved the icon ItemStack from a Create item entry (asStack()) at that point.

On large modpacks, mod-load order can leave a Create item still unbound when this runs, throwing:

Trying to access unbound value: ResourceKey[minecraft:item / create:...]

and failing the boot. Observed on create:schedule, create:chocolate_bucket, and others depending on the pack's load order — it's intermittent because it's order-sensitive.

Fix

Minimal and defensive — no behavior change at datagen:

  • icon(ItemProviderEntry) now defers resolution to save() (where registries are frozen) via the existing func path, instead of resolving asStack() at build time.
  • whenIconCollected() no longer reads the not-yet-resolved icon at build time; it flags the builder so the real InventoryChangeTrigger criterion is appended in save() once the icon resolves.

Icons and the icon-collected criteria resolve at datagen time exactly as before, so generated advancement JSON is unchanged. Verified by building and running on a large NeoForge 1.21.1 pack that previously hit the unbound-value crash — it now boots cleanly.

…nt boot crash

AllAdvancements' static initializer builds every CreateAdvancement during the
TRIGGER_TYPES RegisterEvent phase, and CreateAdvancement.Builder#icon eagerly
resolved the icon ItemStack from a Create item entry (asStack()) at that point.
On large modpacks, mod-load order can leave a Create item unbound when this runs,
throwing 'Trying to access unbound value: ResourceKey[minecraft:item / create:...]'
and failing the boot (seen on create:schedule, create:chocolate_bucket, etc.).

Defer icon resolution to save() (datagen, registries frozen) via the existing
'func' path, and likewise defer whenIconCollected()'s criterion so it no longer
reads the not-yet-resolved icon at build time. No datagen output changes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant