Tags
Creators
Details
1.1
Compatibility
Required content
Changes
Migrated to Official Mojang Mappings (Yarn 1.21.8 → Mojang 26.2)
This release replaces Yarn mappings with official Mojang mappings across the entire codebase. Every rename below was verified against the actual deobfuscated 26.2 jars using javap/CFR — nothing here is guessed or carried over from changelogs/diffs, so symbol names should be accurate to the real classes.
This is primarily an internal/API change. No gameplay behavior should be different, but if you depend on this mod's classes, mixins, or access widener, read the breaking changes below.
Type & Member Renames
~45 net.minecraft.* types renamed mod-wide, plus the method/field renames the compiler surfaced once Mojang names resolved. Highlights:
| Yarn | Mojang |
|---|---|
MinecraftClient |
Minecraft |
ClientPlayerEntity |
LocalPlayer |
ClientPlayNetworkHandler |
ClientPacketListener |
Text |
Component |
Vec3d |
Vec3 |
MathHelper |
Mth |
World |
Level |
GameMode |
GameType |
PlayerPosition |
PositionMoveRotation |
Plus ~45 packet class renames, e.g.:
GameJoinS2CPacket→ClientboundLoginPacketEntityS2CPacket.RotateAndMoveRelative→ClientboundMoveEntityPacket.PosRot- Status ping packets moved into the
pingpackage
Method-level renames caught by the compiler:
player.sendMessage(text, false)→sendSystemMessage(text)getStatus()→getEventId()getReason()→getEvent()ChunkPos.toLong()→ChunkPos.pack()PlayerAbilities.unpack()→Abilities.apply()
Access Widener
Retargeted to the Mojang-mapped members:
Connection.channelPacketDecoder/PacketEncoder.protocolInfo(formerlyDecoderHandler.state)ClientboundLoginPacket.commonPlayerSpawnInfoCommonPlayerSpawnInfo.gameType
Breaking: Network Pipeline Mixin Rework
ClientConnectionMixin is now @Mixin(Connection.class). This needed real rework, not just a rename — 26.2's Connection no longer has addHandlers.
- Static pipeline injector retargeted to
configureSerialization, matching its actual(ChannelPipeline, PacketFlow, boolean, BandwidthDebugMonitor)signature. @Shadowtarget switched fromsidetoreceiving.accepts(...)→shouldHandleMessage(...).- Fixed the
send(...)method descriptor to match the new signature.
Breaking: Spectator Server Network Handler Rebuilt
SpectatorServerNetworkHandler's manual protocol state machine has been rebuilt on top of Mojang's ProtocolInfo / UnconfiguredPipelineHandler system:
NetworkStateTransitions→setupInboundProtocol/setupOutboundProtocol, now returning configuration tasks instead of mutating state directly.PacketBundler/PacketUnbundler→PacketBundlePacker/PacketBundleUnpacker.- Yarn's state factories replaced with Mojang's
HandshakeProtocols,StatusProtocols,ConfigurationProtocols,LoginProtocols, andGameProtocols. - Protocol templates are now bound via
RegistryFriendlyByteBuf.decorator, including the creative-modeGameProtocols.Context.
Fixes (surfaced by the migration, not mapping-related)
- Cloth Config:
getConfigScreenmoved fromAutoConfigtoAutoConfigClientin the pinned 26.2-compatible version — updated call sites accordingly. - Client command tree: the deeply nested command tree was failing generic inference through Brigadier's raw static helpers once names resolved. Added local
FabricClientCommandSource-typedliteral/argumentfactories (filling the roleClientCommandManagerwould play, which isn't present in this Fabric build) soSinfers correctly.
Notes for Downstream Mods / Contributors
If you reference this mod's mixins, access-widened members, or any of the renamed classes directly, those references need updating to the Mojang-mapped names above — particularly anything touching Connection, the pipeline configuration mixin, or SpectatorServerNetworkHandler's protocol setup, since those changed shape rather than just name.
Known incompatibilities
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:GinQkjkB:6TJ33UQV"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:GinQkjkB:6TJ33UQV"
}

