Port to Minecraft 26.2 (5.1.2)

[ThinkofRain1213]

Full migration of the 26.1.2 port to Minecraft 26.2 (Fabric). Fixes #2

• Migrate all mixins/APIs to 26.2: FeatureRenderDispatcher,
  ItemFeatureRenderer.prepareSubmit/Submit API, renamed hand rendering
  (submitHandsWithItems/submitArmWithItem), vertex builder reached via a
  new RenderTypeFeatureRenderer accessor mixin
• Replace removed HangingSignMixin with in-renderer damage-flash suppression
• Fix translucent item depth sorting (opaque-first/translucent-second quad
  submission) — bucket water no longer see-through
• Fix held beds rendering both halves via BED_PART (head at origin, matching
  the 26.2 item model)
• Restore hanging sign top chain bar via ATTACHED state
• Restore missing 3D item models (buckets/boats) with UV clamping and
  mcmeta animation fixes
• pack.mcmeta/respackopts updated for the 26.2 schema

Tested: Fabric Loom 1.16, loader 0.19.3, Fabric API 0.156.0, Java 25.
Developed with AI assistance (declared in README), reviewed and play-tested.

[ByteMe6]

@claude do code review

[claude]

Claude finished @ByteMe6's task in 3m 59s —— View job

---

Code Review

• Gather context (PR diff, repo structure)
• Review mixin/render changes (ItemRendererMixin, HeldItemRendererMixin, RenderTypeFeatureRendererAccessor, ItemRenderStateMixin, CameraMixin)
• Review particle/script wrapper changes
• Review resource/model JSON and mcmeta changes
• Review build config (gradle.properties, fabric.mod.json, mixins.json) and audit_mixins.py
• Post final review

Solid port overall — the API-rename mechanics (getMainCamera→mainCamera, getToastManager→gui.toastManager(), renderHandsWithItems→submitHandsWithItems, Vector3f→Vector3fc, particle pipeline BindGroupLayouts) all line up cleanly, and tools/audit_mixins.py's superclass walk is a nice addition for catching the RenderTypeFeatureRendererAccessor invoker case. Two things worth a look before merge:

1. Outline rendering now replaces main quads instead of overlaying them
mod/src/main/java/com/holdmylua/source/mixin/render/ItemRendererMixin.java:66-75 (hmi$prepareSubmit):

if (submit.outlineColor() != 0) {
   hmi$renderOutline(submit);
} else {
   hmi$renderMain(submit);
}

Pre-port, both submissions happened unconditionally per quad — the outline buffer got the quad only if outlineColor() != 0, but the normal/textured buffer always got it (see the removed code: bufferSource.getBuffer(renderType).putBakedQuad(...) ran outside any outline check). With this if/else, a held item that has an active outline color (e.g. the Glowing status effect, which vanilla applies to the whole render including the held item) will submit only the outline silhouette and skip the textured/colored geometry entirely — the item would appear to vanish except for its outline while glowing. Worth verifying with a Glowing potion/effect in first person.
Fix this →

2. pack.mcmeta format range is internally inconsistent, and doesn't match the README
mod/src/main/resources/resourcepacks/pack_test/pack.mcmeta:

"pack_format": 46,
"min_format": 46,
"max_format": 88,
"supported_formats": [46, 64]

max_format says 88 but supported_formats caps at 64 — these should presumably describe the same range. The README's new "Port notes" section also states "the bundled pack declares... pack_format: 88" (README.md:97), but the file still has pack_format: 46. One of these three fields (or the README line) looks like a leftover from an earlier edit.
Fix this →

Minor: HeldItemRendererMixin.java:536-538 sets BlockStateProperties.ATTACHED to true for any held block that has that property, to fix hanging-sign chains. ATTACHED isn't unique to hanging signs though — e.g. Blocks.TRIPWIRE (held as the string item) also has it — so this could unintentionally change the rendered state for other held items. Scoping the check to blockState.is(BlockTags.ALL_HANGING_SIGNS) (already used a few lines below) would be safer.

Also minor: README.md:24 still says "Java 25+ (required by Minecraft 26.1)" in the Requirements section that was otherwise updated to 26.2 in this PR.

Not flagged, but worth a self-check: hmi$renderFoil's GlobalsStorage.modelPartAnimator.clear() (ItemRendererMixin.java:88) only runs on the foil=true pass. This relies on prepareSubmit always being invoked twice per item (foil=false then foil=true) — the code's own FoilType.NONE early-return inside hmi$renderFoil suggests that's the intended vanilla structure (mirroring an internal check rather than the caller skipping the call), so this is likely fine, but couldn't be confirmed without the 26.2 mappings/decompiled source (not available in this sandboxed checkout).

Tooling note: I wasn't able to run ./gradlew build/audit_mixins.py or a JSON validator in this sandbox (network/interpreter access is restricted for this session), so the above is from static review of the diff only — the model JSON diffs (buckets, etc.) are large but appear to be pure reformatting (pretty-printing) plus the described UV-clamping tweaks, not structural changes.

[ByteMe6]

@ThinkofRain1213 thank you for this — it's a substantial piece of work, and documenting each API rename in the commit message made it genuinely easy to follow.

I ran a second pass over the diff with Claude. It was static review only — no mappings, no build, no game — so please read what follows as things to check rather than confirmed defects.

Only one of them I'd like resolved before merge:

Outline rendering in ItemRendererMixin.hmi$prepareSubmit. The new code branches:

if (submit.outlineColor() != 0) {
    hmi$renderOutline(submit);
} else {
    hmi$renderMain(submit);
}

Pre-port, as I read the removed code, the main buffer received the quad unconditionally and the outline was an additional submission on top. If that's right, a held item with an active outline color — Glowing effect, spectral arrow, /effect give @s glowing — would render as silhouette only, with the textured geometry skipped. I may well be misreading the old flow; you have 26.2 running and I don't, so if you can check it in first person under Glowing and it looks correct, say so and I'll drop this entirely.

The other three are minor and I'm happy to handle them myself after merge — no need for you to touch them unless you'd prefer to:

• HeldItemRendererMixin (~536) sets ATTACHED = true on any held block carrying that property. Tripwire, held as string, has it too, so BlockTags.ALL_HANGING_SIGNS (already used just below) would scope it more narrowly.
• pack_test/pack.mcmeta: max_format: 88 against supported_formats: [46, 64], and the README's Port notes describe the pack as pack_format: 88 while the file says 46.
• README.md:24 still says "required by Minecraft 26.1" under Requirements.

One question out of curiosity rather than a request: hmi$renderFoil clears modelPartAnimator only on the foil=true pass, which assumes prepareSubmit fires twice per item. Does that hold in 26.2, or can the caller skip the foil pass?

I've branched the current master as 26.1.2, so that port stays available for people who haven't updated — master will track 26.2 from here. Thanks again for putting this together.

[ThinkofRain1213]

This reply was written by an AI agent on behalf of the PR author:

Verified in-game (first person): with the Glowing effect applied (/effect give @s glowing), held items render normally — both the textured geometry and the outline display correctly, no "silhouette-only" issue.

Also confirmed at the source level (26.2 mojmap decompile), two points:

1. Vanilla ItemFeatureRenderer.prepareSubmit uses exactly this if/else structure (foil → prepareFoilSubmit; else outlineColor() != 0 → prepareOutlineSubmit; else prepareMainSubmit). The mixin mirrors vanilla precisely — submitting only the outline when glowing is stock 26.2 behavior, not a regression introduced by the port.

2. buildGroup unconditionally runs two passes over every submit (all foil=false first, then all foil=true); the caller cannot skip the second pass, so hmi$renderFoil's modelPartAnimator.clear() is guaranteed to run — the two-pass foil assumption holds in 26.2.

[ByteMe6]

@ThinkofRain1213 that settles it — thank you for checking both in-game and against the decompiled source. Confirming the vanilla prepareSubmit structure and the unconditional two-pass buildGroup is exactly what I couldn't do from my side, and it turns both of my questions into non-issues.

I want to say properly how much work this was. Porting a render-heavy mod across a version that removed MultiBufferSource/OutlineBufferSource, reshaped the whole submit pipeline, and deleted the hanging-sign special renderer is not a mechanical rename job — you rebuilt the quad path, worked out the depth-sorting fix for translucent items, tracked down the bed halves and the chain bar, and restored a set of 3D models that the 26.1.2 port had quietly lost. And you documented every step of it, which made reviewing a diff this size actually pleasant.

Merging now. The three leftovers — the ATTACHED scoping, pack.mcmeta/README format numbers, and the Java line in Requirements — I'll clean up on master myself; they're mine, not yours. Master tracks 26.2 from here, and 26.1.2 stays on its own branch.

Thank you for picking this up and carrying it all the way.