1.21.11 #589
1.21.11 #589
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughAdds Minecraft 1.21.11 support by bumping version strings and introducing version-guarded import/signature and accessor changes across mixins, renderer code, keybinding construction, configuration UI, and localization. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
src/main/java/dev/tr7zw/firstperson/mixins/PlayerRendererMixin.java (1)
3-21: Imports: watch for possiblePlayerModelambiguity and drop duplicate renderer importWith both
dev.tr7zw.transition.mc.*and (for ≥1.21.11)net.minecraft.client.model.player.*imported, the unqualifiedPlayerModelin the constructor could become ambiguous if the transition package ever defines aPlayerModelclass. If that package already contains such a class, this file will not compile; in that case, you should either narrow the imports or fully qualify one of thePlayerModeltypes.Also,
net.minecraft.client.renderer.entity.*is imported twice; you can safely remove one of those lines to avoid redundant imports.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
settings.json(1 hunks)src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java(1 hunks)src/main/java/dev/tr7zw/firstperson/LogicHandler.java(1 hunks)src/main/java/dev/tr7zw/firstperson/config/ConfigScreenProvider.java(6 hunks)src/main/java/dev/tr7zw/firstperson/mixins/HeldItemFeatureRendererMixin.java(2 hunks)src/main/java/dev/tr7zw/firstperson/mixins/HeldItemRendererMixin.java(1 hunks)src/main/java/dev/tr7zw/firstperson/mixins/PlayerModelMixin.java(1 hunks)src/main/java/dev/tr7zw/firstperson/mixins/PlayerRendererMixin.java(1 hunks)src/main/java/dev/tr7zw/firstperson/mixins/WorldRendererMixin.java(1 hunks)versions/mainProject(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (3)
src/main/java/dev/tr7zw/firstperson/mixins/WorldRendererMixin.java (1)
src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java (1)
FirstPersonModelCore(15-136)
src/main/java/dev/tr7zw/firstperson/config/ConfigScreenProvider.java (1)
src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java (1)
FirstPersonModelCore(15-136)
src/main/java/dev/tr7zw/firstperson/mixins/PlayerRendererMixin.java (3)
src/main/java/dev/tr7zw/firstperson/mixins/HumanoidModelMixin.java (1)
Mixin(13-47)src/main/java/dev/tr7zw/firstperson/mixins/LivingEntityRendererMixin.java (1)
Mixin(27-213)src/main/java/dev/tr7zw/firstperson/mixins/LivingEntityRenderStateMixin.java (1)
Mixin(8-71)
🔇 Additional comments (9)
settings.json (1)
38-39: LGTM!The version entry is correctly added to the array with proper JSON formatting.
versions/mainProject (1)
1-1: LGTM!Version bump is consistent with the broader PR objective.
src/main/java/dev/tr7zw/firstperson/config/ConfigScreenProvider.java (1)
76-135: LGTM!The refactoring to use a centralized
getStringItemhelper is well-executed and ensures consistent item identification across all UI components (sorting, tooltips, filtering, and state management).src/main/java/dev/tr7zw/firstperson/mixins/WorldRendererMixin.java (1)
83-83: LGTM!The rendering logic is preserved correctly with only the accessor method name updated for API compatibility.
src/main/java/dev/tr7zw/firstperson/mixins/HeldItemRendererMixin.java (1)
102-102: Based on my web search for Minecraft 1.21.11 documentation and LocalPlayer method information, I could not find authoritative confirmation of the method namegetItemSwapScalein official Minecraft documentation or mod migration guides. The Minecraft 1.21.11 release notes focus on content changes (spears, nautilus armor) but do not document this specific LocalPlayer method rename. Without access to deobfuscated Minecraft source code or official API documentation explicitly confirming this method name, the injection target cannot be definitively verified.Verify that
getItemSwapScaleis the correct method name for Minecraft 1.21.11's LocalPlayer class.The method name change from
getAttackStrengthScaletogetItemSwapScalefor version 1.21.11+ requires confirmation against the actual Minecraft source code or official deobfuscated mappings, as public documentation does not currently confirm this method exists or that this rename occurred.src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java (1)
23-23: Based on my verification using web searches, I found critical API differences:For vanilla Minecraft (used with NeoForged): KeyMapping.Category is created with ResourceLocation and registered via RegisterKeyMappingsEvent#registerCategory.
For Fabric (1.21.9+): KeyBinding.Category is created using KeyBinding.Category.create(Identifier.of(...)), and on versions older than 1.21.9, you would substitute a translation key instead.
The code snippet shows
new KeyMapping.Category(Identifier.fromNamespaceAndPath(...)), which suggests direct constructor usage withIdentifiertype. However, the official documentation indicates:
- NeoForged uses
ResourceLocationwith the constructor- Fabric 1.21.9+ uses a factory method
KeyBinding.Category.create()withIdentifierTo provide a definitive answer, I need to see the complete file context to determine which API path this code is following.
src/main/java/dev/tr7zw/firstperson/mixins/HeldItemFeatureRendererMixin.java (1)
41-78: 1.21.11submitArmWithIteminjection and extended signature look consistentThe updated handler signature for
submitArmWithItem(adding theItemStackparameter while keepingArmedEntityRenderState/ItemStackRenderStateandCallbackInfoat the tail) looks structurally correct, and the cancellation logic viaLivingEntityRenderStateAccessis unchanged, so behavior should remain the same for hiding arms in first person.Because this targets a newly changed Minecraft method, please double‑check the exact descriptor for
submitArmWithItemin 1.21.11 (argument order and types) to ensure the mixin applies cleanly at runtime and doesn’t trip anInvalidInjectionException.src/main/java/dev/tr7zw/firstperson/mixins/PlayerRendererMixin.java (2)
34-83: AvatarextractRenderStatemixin logic aligns withLivingEntityRenderStateAccessusageTargeting
AvatarRendererwith anextractRenderState(Avatar, AvatarRenderState, float, CallbackInfo)injection atTAILand then casting the state toLivingEntityRenderStateAccessmatches the pattern used elsewhere in the project. Gating all of the arm/body adjustments behindaccess.isCameraEntity()keeps non‑camera avatars unaffected, and the dynamic‑hands branch (arm offset + per‑hand hiding, plus cape/body tweaks when swimming) is consistent with whatHumanoidModelMixinexpects to read from the render state.The version guard around
avatarRenderState.hitboxesRenderState = null;for<1.21.11also avoids touching a field that may have been removed or reworked in newer versions.Given this depends on the exact 1.21.11
extractRenderStatedescriptor forAvatarRenderer, please ensure the method signature string in the@Injectmatches the mapped signature in your target environment so the mixin continues to apply correctly.
52-106: Render-layer bookkeeping (removedLayers) remains sound for first‑person hidingThe
getRenderLayers/updatePartsListpair still follow a clear pattern: restore any previously removed layers, clear theremovedLayerslist, and in non‑third‑person mode filterthis.layersagainst the configuredhiddenLayers, moving matches intoremovedLayersand removing them from active rendering. This keeps the base renderer’slayerslist authoritative while allowing reversible first‑person customization and avoids mutating the collection while iterating it.No functional issues here; the behavior should match prior versions while staying compatible with the updated Avatar/Player renderer setup.
| private static @NotNull String getStringItem(Entry<ResourceKey<Item>, Item> a) { | ||
| return a.getKey()/*? >= 1.21.11 {*/.identifier() /*?} else {*//* .location() *//*?}*/.toString(); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the ResourceKey accessor method for Minecraft 1.21.11.
The helper method uses .identifier() instead of .location() for version 1.21.11+. Please confirm that ResourceKey<Item> provides an identifier() method in the target Minecraft version and that it returns the expected identifier format.
🌐 Web query:
Minecraft 1.21.11 fabric ResourceKey identifier method
💡 Result:
Use ResourceKey#location() to get its ResourceLocation, then call ResourceLocation#toString() (or getNamespace()/getPath()).
Example (Mojang mappings / Fabric):
java
ResourceKey key = ...;
ResourceLocation id = key.location(); // ResourceLocation
String full = id.toString(); // "modid:name"
String ns = id.getNamespace(); // "modid"
String path = id.getPath(); // "name"
Sources: mappings.dev (ResourceKey & ResourceLocation docs) and NeoForged ResourceKey doc. [1][2]
Use .location() instead of .identifier() on ResourceKey; verify against actual Minecraft mappings for version 1.21.11.
The documented ResourceKey API uses .location() to get its ResourceLocation, not .identifier(). The code currently calls .identifier() for version 1.21.11+, which does not match the documented API. Verify against the actual Minecraft Fabric mappings artifact for version 1.21.11 to confirm the correct accessor method, or update the code to use .location() as shown in the documentation.
🤖 Prompt for AI Agents
In src/main/java/dev/tr7zw/firstperson/config/ConfigScreenProvider.java around
lines 210 to 212, the code calls ResourceKey.identifier() which does not match
the documented/mapped API for Minecraft 1.21.11 — use ResourceKey.location()
instead; update the method to call .location().toString() (or adjust to whatever
mapping exposes the ResourceLocation), recompile against the 1.21.11 Fabric
mappings to confirm the accessor name, and run the build to ensure no other
compilation errors from the change.
| //? if >=1.21.11 { | ||
| import net.minecraft.world.entity.vehicle.minecart.*; | ||
| import net.minecraft.world.entity.vehicle.boat.*; | ||
| //?} else { | ||
| /*import net.minecraft.world.entity.vehicle.*;*/ | ||
| //?} |
There was a problem hiding this comment.
🧩 Analysis chain
Verify that the vehicle package structure matches Minecraft 1.21.11.
The imports are conditionally updated to use more specific packages for Minecart and Boat classes in version 1.21.11+. Please confirm that these package paths are correct for the target Minecraft version.
🌐 Web query:
Minecraft 1.21.11 fabric vehicle package structure for Minecart and Boat classes
💡 Result:
For Fabric (Yarn) mappings around Minecraft 1.21.x (including the 1.21.11 snapshots) the vehicle classes are in the net.minecraft.world.entity.vehicle package:
- Minecart: net.minecraft.world.entity.vehicle.Minecart. [1]
- Boat: net.minecraft.world.entity.vehicle.Boat (and related BoatEntity/ChestBoatEntity under the same vehicle package). [2]
Sources: mappings.dev (Minecart) [1], xhyrom / Yarn docs (Boat / BoatEntity) [2].
Based on the web search result, there appears to be a potential issue with the import paths. The search indicates that for Minecraft 1.21.11, the vehicle classes (Minecart, Boat, BoatEntity, etc.) are located directly in net.minecraft.world.entity.vehicle, not in subpackages.
However, the code imports from:
net.minecraft.world.entity.vehicle.minecart.*net.minecraft.world.entity.vehicle.boat.*
This suggests either these subpackages don't exist (making the imports invalid) or the web search result is incomplete. I need to search more specifically for the actual Minecraft 1.21.11 package structure to confirm.
</web_search]
🌐 Web query:
Minecraft 1.21.11 net.minecraft.world.entity.vehicle package structure subpackages
💡 Result:
For Minecraft 1.21.11 (mappings 1.21) the package net.minecraft.world.entity.vehicle contains the following types (no further subpackages):
Classes:
- AbstractMinecart
- AbstractMinecartContainer
- Boat
- ChestBoat
- ContainerEntity$1
- DismountHelper
- Minecart
- MinecartChest
- MinecartCommandBlock
- MinecartCommandBlock$MinecartCommandBase
- MinecartFurnace
- MinecartHopper
- MinecartSpawner
- MinecartSpawner$1
- MinecartTNT
- VehicleEntity
Interface:
- ContainerEntity
Enums:
- AbstractMinecart$Type
- Boat$Status
- Boat$Type
Source: mappings.dev package index for net.minecraft.world.entity.vehicle. [1]
References
[1] mappings.dev — net.minecraft.world.entity.vehicle (1.21). (mappings.dev)
Citations:
Fix incorrect import paths for Minecraft 1.21.11.
The package net.minecraft.world.entity.vehicle contains all vehicle classes directly with no subpackages. The imports referencing net.minecraft.world.entity.vehicle.minecart.* and net.minecraft.world.entity.vehicle.boat.* do not exist and will fail to compile.
Update the imports to:
import net.minecraft.world.entity.vehicle.*;
Or use specific class imports like import net.minecraft.world.entity.vehicle.Minecart; and import net.minecraft.world.entity.vehicle.Boat;
🤖 Prompt for AI Agents
In src/main/java/dev/tr7zw/firstperson/LogicHandler.java around lines 15 to 20,
the conditional imports reference non-existent subpackages
(net.minecraft.world.entity.vehicle.minecart.* and .boat.*) for MC 1.21.11;
replace them with the correct package imports by importing the base vehicle
package (net.minecraft.world.entity.vehicle.*) or import the specific classes
(e.g., net.minecraft.world.entity.vehicle.Minecart and
net.minecraft.world.entity.vehicle.Boat) so the compiler can find the classes.
| //? if >=1.21.11 { | ||
| import net.minecraft.client.model.player.*; | ||
| //?} else { | ||
| /*import net.minecraft.client.model.*; | ||
| *///?} |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the PlayerModel package location in Minecraft 1.21.11.
The import has been updated to use a more specific package path (net.minecraft.client.model.player.*) for version 1.21.11+. Please confirm this package restructuring is correct for the target Minecraft version.
🌐 Web query:
Minecraft 1.21.11 fabric PlayerModel class package location
💡 Result:
In Fabric (1.21.x) the player model classes are:
- PlayerModel: net.minecraft.client.model.PlayerModel. [1]
- PlayerEntityModel (used for entity rendering / GUI): net.minecraft.client.render.entity.model.PlayerEntityModel. [2]
Sources: mappings/dev and Fabric/Yarn API docs. [1] https://mappings.dev/1.21/net/minecraft/client/model/index.html [2] https://maven.fabricmc.net/docs/yarn-1.21%2Bbuild.7/net/minecraft/client/render/entity/model/PlayerEntityModel.html
Incorrect import package path detected for Minecraft 1.21.11.
The import uses net.minecraft.client.model.player.*, but in Fabric 1.21.x, the PlayerModel class is located at net.minecraft.client.model.PlayerModel. Update the import to use the correct package path: net.minecraft.client.model.* or import the specific class directly.
🤖 Prompt for AI Agents
In src/main/java/dev/tr7zw/firstperson/mixins/PlayerModelMixin.java around lines
4 to 8 the import block uses net.minecraft.client.model.player.* which is
incorrect for Fabric/Minecraft 1.21.11; replace that import with the correct
package (either import net.minecraft.client.model.PlayerModel; or import
net.minecraft.client.model.*;) and remove the
net.minecraft.client.model.player.* import branch so the PlayerModel reference
resolves to net.minecraft.client.model.PlayerModel.
| return; | ||
| } | ||
| Vec3 vec3d = camera.getPosition(); | ||
| Vec3 vec3d = /*? if >=1.21.11 {*/ camera.position() /*?} else {*//*camera.getPosition()*//*?}*/; |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the Camera accessor methods for Minecraft 1.21.11.
The accessor has been updated from camera.getPosition() to camera.position() for version 1.21.11+. Please confirm that the Camera class uses this accessor name in the target Minecraft version.
🌐 Web query:
Minecraft 1.21.11 fabric Camera position and entity accessor methods
💡 Result:
Short answer — use the Camera and Entity methods from the Yarn/Fabric mappings:
-
Camera (client, net.minecraft.client.render.Camera)
- getPos(): returns camera position as Vec3d. [1]
- setPos(double x, double y, double z) / setPos(Vec3d): set camera position. [1]
- getFocusedEntity(): returns focused Entity. [1]
- getYaw(), getPitch(), getRotation(): get orientation. [1]
- update(...), updateEyeHeight(), isThirdPerson(), etc. for updating/queries. [1]
-
Entity (net.minecraft.entity.Entity)
- getPos(): returns entity position as Vec3d. [2]
- getSyncedPos(): position synced to clients. [2]
- setPos(double x, double y, double z): set entity position. [2]
- getBlockPos()/getChunkPos() and related helpers for integer positions. [2]
- Other useful entity fields/methods (id/UUID, lastRenderX/Y/Z) available on the class. [2]
References:
- Camera (Yarn/Fabric docs). [Camera class methods].
- Entity (Yarn/Fabric docs). [Entity position/accessor methods].
Incorrect accessor method name: use camera.getPos() instead of camera.position() for Minecraft 1.21.11 fabric.
The Camera class in Minecraft 1.21.11 Fabric uses getPos() to return camera position as Vec3d, not camera.position(). Update line 78 to use the correct accessor method.
🤖 Prompt for AI Agents
In src/main/java/dev/tr7zw/firstperson/mixins/WorldRendererMixin.java around
line 78, the Camera position accessor is wrong for MC 1.21.11; replace
camera.position() with camera.getPos() (or the appropriate conditional branch)
so the code uses camera.getPos() to obtain the Vec3/Vec3d position for that
Minecraft version, preserving existing version-guarding comments/flow.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
src/main/java/dev/tr7zw/firstperson/config/ConfigScreenProvider.java (1)
206-208: Incorrect method name: use.location()instead of.identifier()on ResourceKey.As flagged in the previous review,
ResourceKey<Item>does not provide an.identifier()method. The documented API uses.location()to obtain the ResourceLocation. This version-guarded code for 1.21.11+ will fail to compile.Apply this diff to fix the method call:
private static @NotNull String getStringItem(Entry<ResourceKey<Item>, Item> a) { - return a.getKey()/*? >= 1.21.11 {*/.identifier() /*?} else {*//* .location() *//*?}*/.toString(); + return a.getKey().location().toString(); }If there was an actual API change in Minecraft 1.21.11 that requires a different accessor, please verify against the Fabric mappings artifact for that version and update accordingly. Otherwise,
.location()should work consistently across all versions.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java(1 hunks)src/main/java/dev/tr7zw/firstperson/config/ConfigScreenProvider.java(6 hunks)src/main/java/dev/tr7zw/firstperson/mixins/PlayerRendererMixin.java(2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/main/java/dev/tr7zw/firstperson/config/ConfigScreenProvider.java (1)
src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java (1)
FirstPersonModelCore(15-137)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (3)
src/main/java/dev/tr7zw/firstperson/config/ConfigScreenProvider.java (1)
76-76: Good refactoring to centralize item string representation.Replacing all direct calls to
s.getKey().location().toString()with thegetStringItem(s)helper method follows the DRY principle and improves maintainability. All usages across sorting, tooltips, toggles, and filters are consistently updated.Also applies to: 81-81, 84-84, 87-87, 89-89, 101-101, 111-111, 114-114, 117-117, 119-119, 131-131
src/main/java/dev/tr7zw/firstperson/mixins/PlayerRendererMixin.java (2)
81-82: No issues found. The hitboxesRenderState assignment guard is correct.Minecraft 1.21.11 introduced new HitboxesRenderState, HitboxRenderState, and ServerHitboxesRenderState records, and EntityRenderState now exposes hitboxesRenderState and serverHitboxesRenderState components/fields. The guard correctly disables the assignment for versions >= 1.21.11, as the new rendering pipeline now handles hitbox state through EntityRenderState accessors rather than AvatarRenderState. This is a safe, intentional API migration.
7-11: The version guard design is correct—no inconsistency exists.The code properly handles two separate API changes at different version thresholds:
- 1.21.9: The
@Mixinannotation switches toAvatarRendererbecause version 1.21.9 introduced the render state refactoring system.- 1.21.11: The imports switch to
net.minecraft.client.model.player.*because version 1.21.11 reorganized the model package structure.For versions 1.21.9–1.21.10, the code correctly targets
AvatarRendererwith the pre-1.21.11 import path (net.minecraft.client.model.*), wherePlayerModelexists in the Yarn mappings for those versions. This is intentional and consistent with other 1.21.11 API changes throughout the codebase (method renames, class renames, etc.), which all use the same 1.21.11 threshold.Likely an incorrect or invalid review comment.
| private KeyMapping keyBinding = new KeyMapping("key.firstperson.toggle", 295, | ||
| //? if >= 1.21.9 { | ||
| new KeyMapping.Category(ResourceLocation.fromNamespaceAndPath("firstperson", "keybind"))); | ||
| new KeyMapping.Category(/*? if >=1.21.11 {*/ Identifier |
There was a problem hiding this comment.
Verify preprocessor syntax consistency.
There's a spacing inconsistency in the conditional comment syntax. Line 22 uses >= 1.21.9 (with space), while line 23 uses >=1.21.11 (without space between operator and version). If your preprocessor is strict about formatting, this could cause parsing issues.
Consider applying consistent spacing:
- new KeyMapping.Category(/*? if >=1.21.11 {*/ Identifier
+ new KeyMapping.Category(/*? if >= 1.21.11 {*/ Identifier📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| new KeyMapping.Category(/*? if >=1.21.11 {*/ Identifier | |
| new KeyMapping.Category(/*? if >= 1.21.11 {*/ Identifier |
🤖 Prompt for AI Agents
In src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java around lines 22
to 23, the preprocessor conditional comments use inconsistent spacing (">=
1.21.9" on line 22 vs ">=1.21.11" on line 23); make them consistent by adding a
space after the comparison operator on line 23 so it reads ">= 1.21.11" (or
alternatively normalize both lines to the same spacing style) to avoid potential
preprocessor parsing issues.
| new KeyMapping.Category(/*? if >=1.21.11 {*/ Identifier | ||
| /*?} else {*//*ResourceLocation*//*?}*/.fromNamespaceAndPath("firstperson", "keybind"))); |
There was a problem hiding this comment.
🧩 Analysis chain
Verify that Identifier is available in Minecraft 1.21.11+.
The change from ResourceLocation to Identifier for version 1.21.11+ should be verified against the Minecraft API to ensure:
Identifierclass exists innet.minecraft.resourcespackage (or is available via the existing wildcard import on line 13)- The
fromNamespaceAndPathmethod has the same signature
🌐 Web query:
Minecraft 1.21.11 Identifier class net.minecraft.resources package
💡 Result:
Short answer: In the official/Mojang mappings for the 1.21 series the class is ResourceLocation in package net.minecraft.resources; in community Yarn mappings it's named Identifier (usually in net.minecraft.util). [1][2]
Sources:
- net.minecraft.resources.ResourceLocation (Mojang/official mappings pages). [1]
- net.minecraft.util.Identifier (Yarn/documentation). [2]
---
🏁 Script executed:
```shell
#!/bin/bash
# Examine the file to check import statements and mapping system
cat src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java | head -30
Length of output: 1074
---
🌐 Web query:
```web
Minecraft 1.21.11 official mappings ResourceLocation renamed Identifier
💡 Result:
Yes — Mojang's official mappings used in 1.21.11 replace the old ResourceLocation name with Identifier (net.minecraft.util.Identifier). See the 1.21.x mappings view and Fabric API's 1.21.11 note about migrating to Mojang mappings. [1][2]
Sources:
[1] mappings.dev (1.21 / ResourceLocation ↔ Identifier).
[2] Fabric API 0.138.2+1.21.11 changelog — "Migrate to Mojang mappings".
Add import for net.minecraft.util.Identifier to support 1.21.11+.
The verification confirms that Minecraft 1.21.11 official mappings replace ResourceLocation with Identifier in net.minecraft.util. However, line 13 only imports from net.minecraft.resources.*, so Identifier will not be resolved at compile time for the 1.21.11+ code path. Add import net.minecraft.util.Identifier; to make the class available.
🤖 Prompt for AI Agents
In src/main/java/dev/tr7zw/firstperson/FirstPersonModelCore.java around lines
23-24, the 1.21.11+ code path uses net.minecraft.util.Identifier but there is no
import for it (only net.minecraft.resources.* is imported), causing a compile
error; add the import statement "import net.minecraft.util.Identifier;" at the
top of the file alongside the other imports so the Identifier type is resolved
for the 1.21.11+ build.
|
2 participants
No description provided.