Update to Minecraft 26.3

[rubensworks]

Updates all three loaders to Minecraft 26.3. ./gradlew build and ./gradlew runGameTestServer both pass locally for Fabric, NeoForge and Forge, and a dev client was driven on 26.3 with clientdevbridge to check the rendering changes.

CommonCapabilitiesAPI submodule

The submodule moves to eac103d, the current master-26, picking up two fixes:

• SlotDisplay$TagSlotDisplay now carries a HolderSet<Item> instead of a TagKey<Item> (Update to Minecraft 26.3 CommonCapabilitiesAPI#9).
• The API had drifted into referencing the CommonCapabilities mod's DataComparator and this repo's IModHelpersNeoForge, neither of which the api source set can see, so master-26 did not compile here at all. Make the API self-contained again CommonCapabilitiesAPI#10 extracts IDataComparator and drops the loader-specific helper, and adds a CI check in that repo that resolves every org.cyclops reference against CyclopsCore's loader-common so the same drift cannot land again.

The matching CommonCapabilities change is CyclopsMC/CommonCapabilities#50.

Tooling

• Gradle wrapper 9.5.0 → 9.7.1. Fabric Loom 1.18 requires it, and Loom also requires the build JVM itself to be Java 25 (CI already provisions Java 25).
• Fabric Loom 1.17-SNAPSHOT → 1.18.2, NeoForge ModDev 2.0.141 → 2.0.147.
• NeoForge 26.3.0.7-beta, Forge 26.3-66.0.2, Fabric API 0.161.0+26.3, Fabric Loader 0.19.5, NeoForm 26.3-1, Forge Config API Port 26.3.0, Curios 16.0.0+26.2.

Common

• ContextAwarePredicate was removed; criterion triggers now hold Optional<Holder<LootItemCondition>> and serialize via LootItemCondition.CODEC.
• NumberProvider split into ContextFloatProvider and ContextIntProvider. LootNumberProviderConfigCommon is replaced by LootContextFloatProviderConfigCommon and LootContextIntProviderConfigCommon, with matching ConfigurableTypeCommon entries.
• Feature, ConfiguredFeature and FeatureConfiguration were merged into one Feature interface. WorldFeatureConfigCommon now registers a MapCodec<F> into BuiltInRegistries.FEATURE_TYPE.
• Render pipeline classes moved from com.mojang.blaze3d.pipeline to com.mojang.renderpearl.api.pipeline, in ParticleBlur as well as in the access transformer and access widener.
• HolderOwner#canSerializeIn → canSerialize.
• Util.getPlatform().openUri → Blaze3D.openUri.
• WorldLoader.DataLoadContext#datapackWorldgen → datapackWorldRegistries.
• Player#drop takes a Prediction.
• TestData gained a dimension parameter.

Shaders

cyclopscore:core/particle_blur no longer compiled, which killed the whole cyclopscore:pipeline/translucent_particle_blur pipeline at resource load. GLSL now goes through Shaderc to SPIR-V:

• #moj_import → #include, plus an explicit #extension GL_ARB_separate_shader_objects : require
• every in/out needs an explicit layout(location = …), matching what vanilla's core/particle.vsh writes
• the fog colour goes through a calculateFinalColor helper mirroring vanilla's core/particle.fsh, so the shader also holds up under OIT
• the unused Sampler2 uniform is dropped, as in vanilla

This was caught by running a dev client, not by the build: nothing about it fails compilation. After the fix the pipeline compiles and cyclopscore:blur draws its soft additive glow again, verified by spawning particles in a 26.3 client and screenshotting them.

NeoForge

• LootModifier conditions are now Optional<Holder<LootItemCondition>>.
• DisplayInfo is a record, so getTitle/getDescription/getIcon became accessors.
• BlockState#blocksMotion was removed; ParticleDropBlockComponent uses isSolidRender instead.
• BlockItem#updateCustomBlockEntityTag became static, so ItemBlockNBT hooks into placeBlock instead. Vanilla block entity data still wins, since place calls placeBlock before updateCustomBlockEntityTag.
• BakedQuad.MaterialInfo gained item glint render types and takes a nullable shade Direction instead of a shade boolean. DynamicBaseModel passes Direction.UP, whose cardinal lighting factor is 1.0, to keep the previous unshaded look.
• PoseStack#mulPose(Quaternionf) replaced by rotateDegrees(Axis, float).

Curios

NeoForge removed net.neoforged.neoforge.items in 26.3 and Curios has no 26.3 release, so ICuriosItemHandler#getEquippedCurios — which returns IItemHandlerModifiable — is unusable. Curios 16.0.0+26.2 does however expose CuriosCapability.ITEM_HANDLER as an EntityCapability<ResourceHandler<ItemResource>, Void>, which touches none of the removed package, so the integration is kept and moved onto that:

• InventoryModifiableResourceHandlerNeoForge replaces InventoryModifiableContainerNeoForge and adapts a ResourceHandler<ItemResource> to IInventoryCommonModifiable.
• The transfer API has no slot setter, so setStackInSlot empties and refills the slot in one transaction. Unlike the old direct setter it respects the handler's own slot validation, and rolls back rather than dropping items when a slot refuses the stack.

Compile-verified only: Curios 16.0.0+26.2 itself cannot load on 26.3, so this cannot actually run until Curios releases for it. The compileOnly dependency means nothing ships either way, and the compat only initialises when the curios mod is present.

Not verified

DynamicBaseModel, RenderBlockEntityModel and ScreenInfoBook are compile-checked only; the particle pipeline is the only rendering path that was exercised in a running client. The Curios integration is compile-checked only, as above.

Also note: .gitignore gained an entry for .clientdevbridge/ session state, which the tooling appends on first use.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V35MFZ7JSgoLe79J4d1uxf

[coveralls]

coverage: 31.278% (-0.06%) from 31.34% — claude/minecraft-26-3-update-xr1cny into master-26

[rubensworks]

Heads-up on merge order: the API submodule now points at d9a3254, which lives on the branch of CyclopsMC/CommonCapabilitiesAPI#10 (the commit that makes the API compile without the CommonCapabilities mod and without IModHelpersNeoForge).

Please merge that PR first. If it is squashed, the pin here becomes an orphan commit, so I will move it to the resulting master-26 commit right after and push again.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud