Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 44 minutes and 27 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (112)
📝 WalkthroughWalkthroughAdds broad Minecraft 26.1+ compatibility via version-gated API branches, compiler scaffolding, and utilities; updates rendering entrypoints (GuiGraphics → GuiGraphicsExtractor and SubmitNodeCollector), adapts inventory/container and item/nbt APIs, introduces ChunkPos/interaction/container compat helpers, and adjusts build/stonecutter/loom configuration and access wideners. Changes
Sequence Diagram(s)sequenceDiagram
participant FrameGraph
participant FramePass
participant SubmitNodeStorage
participant Draw3D
FrameGraph->>FramePass: register "jsmacrosce_draw3d"
FramePass->>SubmitNodeStorage: capture storage (on enqueue)
FramePass->>Draw3D: execute(tickDelta, SubmitNodeStorage)
Draw3D->>SubmitNodeStorage: submit rendering nodes
Draw3D-->FramePass: completed
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120 minutes Possibly related PRs
✨ Finishing Touches✨ Simplify code
|
grepsedawk
force-pushed
the
feat/mc-26.1
branch
from
4747e6d to
eb11070
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (7)
fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinDebugHud.java (1)
21-24:⚠️ Potential issue | 🟠 MajorMissing implementation for MC 26.1.2 and newer versions.
The TODO comment indicates the mixin reference changed in 1.21.9/1.21.10, but there's no implementation for versions >1.21.8. This means the FHud.overlays rendering functionality on the debug screen is completely disabled for MC 26.1.2, resulting in a feature regression for the new version this PR is adding.
Would you like me to help identify the correct mixin target for MC 26.1.2? I can search for the updated DebugScreenOverlay method signature that replaced
drawGameInformation(GuiGraphics).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinDebugHud.java` around lines 21 - 24, The mixin currently only targets the old DebugScreenOverlay method (drawGameInformation(GuiGraphics)) and lacks support for MC 26.1.2+; update MixinDebugHud to detect versions >1.21.8 and add a second mixin target that matches the new DebugScreenOverlay render method signature used in MC 26.1.2 (the method that replaced drawGameInformation), then inject the same call to FHud.overlays(renderContext or GuiGraphics equivalent) from that new target so overlays are rendered on newer versions; reference MixinDebugHud, FHud.overlays, and the old drawGameInformation(GuiGraphics) to locate and mirror the existing injection logic when adding the new target.common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.java (1)
165-188:⚠️ Potential issue | 🟡 MinorConfirm
EditBox.setFilterremoval in 26.1 and document the behavior change in the Javadoc.The current Javadoc still reads as if the predicate is honored. Since on 26.1+ this is now a no-op, scripts that rely on rejection-based input filtering will silently accept all input (and only get a single one-shot warning per JVM). Worth noting in the public Javadoc so script authors aren't surprised.
Was EditBox.setFilter(Predicate<String>) removed in Minecraft 26.1, and is there any replacement on EditBox or via TextFormatter / StringUtil.filterText for user-configurable input rejection?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.java` around lines 165 - 188, Update the public Javadoc for TextFieldWidgetHelper.setTextPredicate and resetTextPredicate to state explicitly that EditBox.setFilter was removed in Minecraft 26.1 and these methods are no-ops on 26.1+ (they only emit a single JVM warning once per session), so scripts cannot rely on rejection-based input filtering; mention there is no upstream replacement on EditBox and suggest using alternative filtering before calling setText/setTextSilent or utility methods such as TextFormatter/StringUtil.filterText if applicable. Ensure the wording appears on both method docs (and class-level doc if present) and references the exact methods setTextPredicate and resetTextPredicate so callers know the changed behavior.common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinInGameHud.java (1)
20-32:⚠️ Potential issue | 🟡 MinorOverlays injected into
extractRenderStateon 26.1+ run during the state-extraction phase, not GPU render.The
IDraw2D.renderandDraw2D.rendermethods acceptGuiGraphicsExtractoron 26.1+, so the signature is compatible. However, the injection point timing differs: on 26.1+, overlays are rendered at TAIL ofextractRenderState(CPU state-extraction phase), whereas pre-26.1 renders them at TAIL ofrender(GPU phase). This could affect z-order: overlays may render before the HUD's own GPU render completes, potentially appearing underneath HUD elements if they were previously drawn on top. If overlays should always appear above HUD elements, verify thatextractRenderStateor another 26.1 injection point preserves that ordering.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinInGameHud.java` around lines 20 - 32, The injection currently renders FHud.overlays in MixinInGameHud at the TAIL of extractRenderState on 26.1+ (and at TAIL of render on older versions), which runs during the CPU state-extraction phase and can cause overlays to be drawn before the HUD's GPU render; change the 26.1+ injection to run during the GPU render phase (e.g., inject at the end of the existing render method or another post-GPU-render hook) so overlays consistently draw above HUD elements, keeping the method signature compatible with IDraw2D.render / Draw2D.render (GuiGraphicsExtractor for 26.1+) or adapt to call the GPU-phase GuiGraphics render path when switching injection points; update MixinInGameHud to use the GPU-phase injection while preserving FHud.overlays iteration and rendering logic.common/src/main/java/com/jsmacrosce/wagyourgui/elements/Button.java (1)
88-127:⚠️ Potential issue | 🟠 MajorFix visibility:
extractContentsmust bepublic, notprotected.The 26.1 override at line 105 declares
protected void extractContents(...), but Minecraft 26.1's AbstractButton defines it aspublic abstract void extractContents(...). This visibility mismatch prevents the override from compiling or functioning correctly. Update line 105 to:public void extractContents(GuiGraphicsExtractor drawContext, int mouseX, int mouseY, float delta) {The same issue exists in AnnotatedCheckBox.java and likely other sibling widgets using this pattern.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/wagyourgui/elements/Button.java` around lines 88 - 127, The override for extractContents in Button.java uses protected visibility but must be public to match the AbstractButton signature; change the method declaration for extractContents(GuiGraphicsExtractor drawContext, int mouseX, int mouseY, float delta) from protected to public so it correctly overrides; also verify the same visibility change for the alternative overloads/variants (renderContents/renderWidget) where you conditionally declare extractContents in AnnotatedCheckBox and any sibling widgets to ensure all overrides are declared public and match the abstract method signature.common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinChatHud.java (1)
47-65:⚠️ Potential issue | 🔴 CriticalFix commented-out
GuiMessageSourceimport for 26.1+ code pathLine 12 has the import
GuiMessageSourcecommented out (/*import ... */), but lines 48 and 61 referenceGuiMessageSource.SYSTEM_CLIENTin the uncommented 26.1+ code branches. This will cause a compilation error in Minecraft 26.1+ because the class is undefined. Uncomment the import on line 12 to resolve.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinChatHud.java` around lines 47 - 65, The 26.1+ code path uses GuiMessageSource.SYSTEM_CLIENT but the GuiMessageSource import is commented out, causing compilation errors; uncomment the GuiMessageSource import statement so GuiMessageSource is available, then ensure references in methods jsmacros_addMessageAtIndexBypass and the earlier addMessage call compile with addMessage(..., GuiMessageSource.SYSTEM_CLIENT, ...), keeping the ThreadLocal jsmacros$positionOverride usage unchanged.common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Rect.java (2)
50-68:⚠️ Potential issue | 🔴 CriticalThe 26.1 pipeline declaration uses non-existent classes and methods that will not compile.
DepthStencilState,CompareOp, and the methodRenderPipeline.Builder#withDepthStencilState()do not exist in Minecraft 26.1's public API. According to Mojang's deobfuscated mappings, depth control is handled via:
withDepthTestFunction(DepthTestFunction)— useDepthTestFunction.ALWAYSinstead ofCompareOp.ALWAYS_PASSwithDepthWrite(boolean)— to control depth write behaviorReplace the 26.1 block to use the correct methods.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Rect.java` around lines 50 - 68, The 26.1 RenderPipeline block uses non-existent DepthStencilState/CompareOp APIs; update the DEBUG_QUADS_SEE_THROUGH pipeline builder to use withDepthTestFunction(DepthTestFunction.ALWAYS) and withDepthWrite(false) (keep withCull(false) and the same location/name), then recreate DEBUG_QUADS_SEE_THROUGH_TYPE with RenderType.create(...) using RenderSetup.builder(DEBUG_QUADS_SEE_THROUGH).createRenderSetup(); ensure the code references RenderPipeline, RenderPipelines.DEBUG_FILLED_SNIPPET, DepthTestFunction, DEBUG_QUADS_SEE_THROUGH and DEBUG_QUADS_SEE_THROUGH_TYPE so it compiles against 26.1 APIs.
396-452:⚠️ Potential issue | 🟡 MinorUnused
SubmitNodeCollector collectorparameter in the>=26.1path should be either wired into the render logic or removed from the signature.The parameter appears in the method signature for 26.1 but is never referenced in the body. This same pattern exists in
Text.java,Image.java, andLine.java. WhileItem.javausesrenderState.submit(collector, ...), the simpler geometry components rely directly onconsumers.getBuffer(RenderTypes.debugQuads()). Clarify whether the collector should be threaded through these simple-geometry paths or whether the parameter is vestigial from an incomplete 26.1 port.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Rect.java` around lines 396 - 452, The method render3D has an unused SubmitNodeCollector collector in the >=26.1 signature; either remove the collector parameter from Rect.render3D (and the matching signatures in Text.java, Image.java, Line.java) if it's vestigial, or wire it into the render path like Item.java does by submitting the draw to the collector instead of calling consumers.getBuffer(...) directly: when enable the 26.1 path, obtain the correct RenderType (debug quads or see-through variant) and call the project’s submission API (e.g., the same renderState.submit(collector, ...) pattern used in Item.java) so the collector is used for batching; apply the same change to Text, Image, and Line to keep signatures consistent.
🧹 Nitpick comments (14)
common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/FakeServerCommandSource.java (1)
49-57: Nit: keep stonecutter directive whitespace consistent.Existing blocks in this file use
//? } else {///? }(with a space after//?), but the newly added blocks use*///?} else {///?}(no space). Both are accepted by Stonecutter, but mixed styles in the same file hurt grep/readability and make it easy to miss directives in future edits.♻️ Suggested normalization
- //? if >=26.1 { + //? if >=26.1 { /*public Collection<String> getCustomTabSuggestions() { return source.getCustomTabSuggestions(); } - *///?} else { + *///? } else { public Collection<String> getCustomTabSugggestions() { return source.getCustomTabSugggestions(); } - //?} + //? }- //? if >=26.1 { + //? if >=26.1 { /*Minecraft.getInstance().player.sendSystemMessage(feedbackSupplier.get()); - *///?} else { + *///? } else { Minecraft.getInstance().player.displayClientMessage(feedbackSupplier.get(), false); - //?} + //? }Also applies to: 101-105
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/FakeServerCommandSource.java` around lines 49 - 57, Normalize the Stonecutter directive spacing in FakeServerCommandSource by changing the inline comment markers to match the file's existing style (use "//? } else {" and "//? }" with a space after "//?") for the blocks around the getCustomTabSuggestions/getCustomTabSugggestions methods (and the other similar block at lines ~101-105); update the commented-out older-API variant so the closing markers read "//? } else {" and "//? }" (with a space) to keep grep/readability consistent.fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/api/classes/CommandBuilderFabric.java (1)
49-63: Argument-builder gating is consistent — minor DRY opportunity.The two
argument(...)overloads each repeat the same stonecutter>=26.1switch with only thetype.get()vstype.apply(e)difference. Functionally fine and the duplication is small, but if you'd like to reduce stonecutter surface area, consider extracting a single private helper such asbuildArgument(String, Function<CommandBuildContext, ArgumentType<?>>)that contains the lone gated call, and have both overloads delegate to it (theSupplierform viae -> type.get()). Defer if not worth the churn.♻️ Optional dedup sketch
`@Override` protected void argument(String name, Supplier<ArgumentType<?>> type) { - //? if >=26.1 { - /*pointer.push(new Pair<>(true, (e) -> ClientCommands.argument(name, type.get()))); - *///?} else { - pointer.push(new Pair<>(true, (e) -> ClientCommandManager.argument(name, type.get()))); - //?} + argument(name, (CommandBuildContext e) -> type.get()); } `@Override` protected void argument(String name, Function<CommandBuildContext, ArgumentType<?>> type) { + pushArgument(name, type); + } + + private void pushArgument(String name, Function<CommandBuildContext, ArgumentType<?>> type) { //? if >=26.1 { /*pointer.push(new Pair<>(true, (e) -> ClientCommands.argument(name, type.apply(e)))); *///?} else { pointer.push(new Pair<>(true, (e) -> ClientCommandManager.argument(name, type.apply(e)))); //?} }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/api/classes/CommandBuilderFabric.java` around lines 49 - 63, The two argument overloads in CommandBuilderFabric duplicate the gated stonecutter conditional; refactor by adding a private helper (e.g., buildArgument(String name, Function<CommandBuildContext, ArgumentType<?>> typeFn)) that contains the gated pointer.push call (using typeFn.apply(e)) and then have the existing protected argument(String, Supplier<ArgumentType<?>>) delegate by passing e -> type.get(), and the protected argument(String, Function<CommandBuildContext, ArgumentType<?>>) delegate directly to buildArgument; update references to pointer.push only inside the new buildArgument method so the gate logic is centralized.common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/BlockDataHelper.java (1)
9-19: Gate now-unused imports for the 26.1 target.On the
>=26.1branch, thefor (Entry<Property<?>, Comparable<?>> e : ...)loop is stripped, soimport java.util.Map.Entry;(line 19) andimport net.minecraft.world.level.block.state.properties.Property;(line 9) are no longer referenced in the 26.1 build and will surface as unused-import warnings (or errors under-Werror). Consider gating them with stonecutter the same waynet.minecraft.Utilis gated above, or moving the type to a local var inside the else-branch.Same API caveat as in
StateHelper.toMap():base.getValues().forEach(v -> ...)assumes the new return type is iterable/streamable withv.property()/v.value()accessors.HashMap.putinside a sequentialStream.forEachis fine; just confirmgetValues()isn't returning a parallel stream.♻️ Suggested import gating
import java.util.HashMap; import java.util.Map; -import java.util.Map.Entry; +//? if <26.1 { +import java.util.Map.Entry; +import net.minecraft.world.level.block.state.properties.Property; +//?}(and remove the unconditional
Propertyimport on line 9)Also applies to: 125-131
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/BlockDataHelper.java` around lines 9 - 19, The imports java.util.Map.Entry and net.minecraft.world.level.block.state.properties.Property are unused on the 26.1 target because the Property-typed for-loop is stripped; remove the unconditional imports and either (A) gate their use the same way net.minecraft.Util is gated (only reference Property/Entry inside the version-conditional branch), or (B) move the Property/Entry types out of the top-level imports and into the else-branch using fully-qualified type names or local vars so the compiler only sees them when that branch is compiled; also update the BlockDataHelper code that iterates base.getValues() to use the new iterable/stream accessors (v.property()/v.value()) and ensure the forEach on base.getValues() is executed sequentially (not a parallel stream) when calling HashMap.put.fabric/build.gradle.kts (1)
27-28: Prefer an explicit profile flag over a version prefix check.
minecraft_version.startsWith("26.")will break the moment another deobfuscated MC line ships (or, less likely, if any non-deobfuscated 26.x release lands). Driving this from a property inversions/<mc>/gradle.properties(e.g.mc_deobfuscated=true) keeps the loom-plugin selection declarative and mirrors howparchment_*andneoforge_*are already handled — set the flag per profile and read it viacommonMod.prop("mc_deobfuscated").toBoolean().♻️ Proposed refactor
-// MC 26.1 ships deobfuscated, so Loom 1.15+ skips the mappings layer and the -// remap step. The non-obfuscated plugin `net.fabricmc.fabric-loom` routes to -// `LoomNoRemapGradlePlugin`; the legacy `fabric-loom` alias still targets the -// obfuscated-MC plugin used for 1.21.x. Both IDs come from the same JAR and -// cannot be conditionalised inside the `plugins { }` block, so we apply the -// correct one here. -val isDeobfuscatedMc = minecraft_version.startsWith("26.") -apply(plugin = if (isDeobfuscatedMc) "net.fabricmc.fabric-loom" else "fabric-loom") +// Deobfuscated MC profiles set `mc_deobfuscated=true` in their version-specific +// gradle.properties; everything else uses the legacy obfuscated plugin. Both IDs +// resolve to the same JAR but route to different Loom plugin classes, and +// cannot be conditionalised inside the `plugins { }` block above. +val isDeobfuscatedMc = commonMod.prop("mc_deobfuscated").equals("true", ignoreCase = true) +apply(plugin = if (isDeobfuscatedMc) "net.fabricmc.fabric-loom" else "fabric-loom")And add
mc_deobfuscated=truetoversions/26.1.2/gradle.properties(defaultfalse/absent in the 1.21.x profiles).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fabric/build.gradle.kts` around lines 27 - 28, Replace the brittle runtime check that sets isDeobfuscatedMc from minecraft_version.startsWith("26.") with a declarative property read: use commonMod.prop("mc_deobfuscated").toString().toBoolean() (or commonMod.prop("mc_deobfuscated").toBoolean() if available) to determine the boolean used by the apply(plugin = ...) expression; update the code paths that reference isDeobfuscatedMc accordingly and document that versions/26.x/gradle.properties should include mc_deobfuscated=true (leave it absent/false in 1.21.x profiles).common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/RegistryHelper.java (1)
104-114: Align with ItemHelper and CommandContextHelper by usingcreateItemStack(1)instead of manual component handling.RegistryHelper uses
itemResult.item()anditemResult.components()on the 26.1 branch, while both ItemHelper and CommandContextHelper use the simplercreateItemStack(1)pattern for the same ItemInput type. The manual approach appears redundant sincecreateItemStack(1)already encapsulates component application.♻️ Optional refactor to align with sibling code
ItemParser reader = new ItemParser(Objects.requireNonNull(mc.getConnection()).registryAccess()); //? if >=26.1 { - /*ItemInput itemResult = reader.parse(new StringReader(parseNameSpace(id) + nbt)); - *///?} else { + /*ItemInput itemInput = reader.parse(new StringReader(parseNameSpace(id) + nbt)); + return new CreativeItemStackHelper(itemInput.createItemStack(1)); + *///?} else { ItemParser.ItemResult itemResult = reader.parse(new StringReader(parseNameSpace(id) + nbt)); //?} ItemStack stack = new ItemStack(itemResult.item()); stack.applyComponents(itemResult.components()); return new CreativeItemStackHelper(stack);This mirrors ItemHelper.getStackWithNbt and reduces reliance on ItemInput's internal accessors.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/RegistryHelper.java` around lines 104 - 114, Replace the manual ItemStack construction in RegistryHelper.getItemStack by invoking the ItemInput's createItemStack(1) helper instead of calling itemResult.item() and itemResult.components(); specifically, after parsing with ItemParser (ItemParser or ItemParser.ItemResult depending on branch), call itemResult.createItemStack(1) to obtain the stack and return new CreativeItemStackHelper(stack) so behavior aligns with ItemHelper.getStackWithNbt and CommandContextHelper.common/src/main/java/com/jsmacrosce/jsmacros/util/ContainerInputCompat.java (1)
44-46: Use a switch instead ofClickType.values()[action]for the older-MC path.The constants on Lines 12–18 happen to match the current
ClickTypeenum ordinals, but that contract is implicit — any future Mojang reordering (or removal/insertion of an entry on a future 1.21.x patch) silently flips actions to the wrong type. The>=26.1branch already uses an explicit switch, so mirroring that here keeps both paths symmetric, removes the per-callvalues()array allocation, and produces a clearIllegalArgumentExceptionfor unknown action ids instead ofArrayIndexOutOfBoundsException.♻️ Proposed switch-based mapping
- private static ClickType toAction(int action) { - return ClickType.values()[action]; - } + private static ClickType toAction(int action) { + return switch (action) { + case PICKUP -> ClickType.PICKUP; + case QUICK_MOVE -> ClickType.QUICK_MOVE; + case SWAP -> ClickType.SWAP; + case CLONE -> ClickType.CLONE; + case THROW -> ClickType.THROW; + case QUICK_CRAFT -> ClickType.QUICK_CRAFT; + case PICKUP_ALL -> ClickType.PICKUP_ALL; + default -> throw new IllegalArgumentException("Unknown click action: " + action); + }; + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/util/ContainerInputCompat.java` around lines 44 - 46, Replace the fragile ordinal-based mapping in the private static method toAction(int action) (which currently uses ClickType.values()[action]) with an explicit switch mapping that mirrors the >=26.1 branch's cases; map each known action id to the corresponding ClickType constant, throw an IllegalArgumentException for unknown ids, and remove the per-call values() access to avoid array allocation and out-of-bounds errors.common/src/main/java/com/jsmacrosce/jsmacros/util/ChunkPosUtil.java (1)
5-23: Optional: add a brief class-level Javadoc.A one-liner explaining that this util exists to bridge the
ChunkPos.x/pos.x()field-to-accessor migration would help future maintainers decide when the util can be retired (i.e., once the minimum supported version is>=26.1).📝 Proposed addition
package com.jsmacrosce.jsmacros.util; import net.minecraft.world.level.ChunkPos; +/** + * Cross-version accessor for {`@link` ChunkPos} coordinates. + * On Minecraft 26.1+ {`@code` x}/{`@code` z} are accessor methods; on earlier + * versions they are public fields. This util hides the difference so callers + * can avoid sprinkling stonecutter gates. + */ public final class ChunkPosUtil {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/util/ChunkPosUtil.java` around lines 5 - 23, Add a one-line Javadoc to the ChunkPosUtil class that explains this utility bridges the field-to-accessor migration for ChunkPos (providing x(ChunkPos) and z(ChunkPos) compatibility) and notes it can be removed once the minimum supported Minecraft version is >= 26.1; place the Javadoc immediately above the class declaration (public final class ChunkPosUtil) so future maintainers know the purpose and retirement condition for the x(ChunkPos) and z(ChunkPos) helper methods.common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/worldscanner/WorldScanner.java (1)
103-106: Optional: cachemc.player.chunkPosition()in a local.Same nit as
EntityHelper.getChunkPos()— call it once.Proposed nit
public List<Pos3D> scanAroundPlayer(int chunkRange) { if (mc.player == null) return new ArrayList<>(); - return scanChunkRange(ChunkPosUtil.x(mc.player.chunkPosition()), ChunkPosUtil.z(mc.player.chunkPosition()), chunkRange); + var pos = mc.player.chunkPosition(); + return scanChunkRange(ChunkPosUtil.x(pos), ChunkPosUtil.z(pos), chunkRange); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/worldscanner/WorldScanner.java` around lines 103 - 106, In WorldScanner.scanAroundPlayer, avoid calling mc.player.chunkPosition() twice; cache the result in a local variable (e.g., ChunkPos chunkPos = mc.player.chunkPosition()) and then pass ChunkPosUtil.x(chunkPos) and ChunkPosUtil.z(chunkPos) into scanChunkRange so you only invoke chunkPosition() once.common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.java (1)
153-158: Optional: gate the warn-once flags behind the same stonecutter conditional.
SET_TEXT_PREDICATE_WARNEDandRESET_TEXT_PREDICATE_WARNEDare only referenced from the>=26.1branch, so on older targets they are dead static state. Cheap, but easy to gate to keep the legacy artifact identical to pre-PR.Proposed gating
+ //? if >=26.1 { + /*private static final AtomicBoolean SET_TEXT_PREDICATE_WARNED = new AtomicBoolean(); + private static final AtomicBoolean RESET_TEXT_PREDICATE_WARNED = new AtomicBoolean(); + *///?} - private static final AtomicBoolean SET_TEXT_PREDICATE_WARNED = new AtomicBoolean(); - private static final AtomicBoolean RESET_TEXT_PREDICATE_WARNED = new AtomicBoolean();(If you take this, the
AtomicBooleanimport on line 15 should also be moved inside the same gate.)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.java` around lines 153 - 158, The two warn-once static flags SET_TEXT_PREDICATE_WARNED and RESET_TEXT_PREDICATE_WARNED (and the AtomicBoolean import) should be moved inside the same stonecutter conditional used for the ">=26.1" branch so they are only defined when that branch is compiled; update TextFieldWidgetHelper to declare these AtomicBoolean fields inside that conditional (and remove the top-level declarations/import) to avoid adding dead static state on older targets.common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/EntityHelper.java (1)
186-188: Optional: extractchunkPosition()to a local.Minor —
base.chunkPosition()is called twice; a local would also make the call site easier to step through.Proposed nit
public Pos2D getChunkPos() { - return new Pos2D(ChunkPosUtil.x(base.chunkPosition()), ChunkPosUtil.z(base.chunkPosition())); + var pos = base.chunkPosition(); + return new Pos2D(ChunkPosUtil.x(pos), ChunkPosUtil.z(pos)); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/EntityHelper.java` around lines 186 - 188, The method getChunkPos() calls base.chunkPosition() twice; assign the result to a local variable (e.g., var chunkPos = base.chunkPosition() or ChunkPos chunkPos) and then call ChunkPosUtil.x(chunkPos) and ChunkPosUtil.z(chunkPos) to construct the Pos2D, which reduces duplicate calls and makes stepping through getChunkPos() easier.common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinClientPlayerInteractionManager.java (1)
13-13: Gate theEntityHitResultimport behind>=26.1to match the rest of the file.The import is unconditional but only consumed in the
>=26.1(commented-out) branch, so on pre-26.1 builds it’s an unused import. Cosmetic, but consistent with how other imports (e.g.,GuiGraphicsExtractorin sibling files) are scoped.Proposed gating
-import net.minecraft.world.phys.BlockHitResult; -import net.minecraft.world.phys.EntityHitResult; +import net.minecraft.world.phys.BlockHitResult; +//? if >=26.1 { +/*import net.minecraft.world.phys.EntityHitResult; +*///?}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinClientPlayerInteractionManager.java` at line 13, The import for EntityHitResult in MixinClientPlayerInteractionManager is unconditionally added but only used in the >=26.1 branch; wrap/gate the import so it is only present for >=26.1 builds to avoid unused-imports on older targets. Locate the import line referencing EntityHitResult and conditionally include it following the same version-gating pattern used elsewhere in the codebase (mirror how GuiGraphicsExtractor is conditioned in sibling files) so the symbol EntityHitResult is only imported for the >=26.1 variant.common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/ClientPlayerEntityHelper.java (1)
737-776: Extract cooldown-key formatting to a static helper method to reduce duplication across two methods.Both
getItemCooldownsRemainingTicks()andgetTicksSinceCooldownsStart()carry identical version-specific logic for item key formatting. A static helper would localize the version gate and keep the methods DRY:♻️ Suggested extraction
private static String cooldownKey(Item item) { //? if >=26.1 { /*return net.minecraft.network.chat.Component.translatable(item.getDescriptionId()).getString(); *///?} else { return item.getName().getString(); //?} }Then apply:
- //? if >=26.1 { - /*return map.entrySet().stream().collect(Collectors.toMap(e -> Component.translatable(e.getKey().getDescriptionId()).getString(), e -> e.getValue().jsmacros_getEndTick() - tick)); - *///?} else { - return map.entrySet().stream().collect(Collectors.toMap(e -> e.getKey().getName().getString(), e -> e.getValue().jsmacros_getEndTick() - tick)); - //?} + return map.entrySet().stream().collect(Collectors.toMap(e -> cooldownKey(e.getKey()), e -> e.getValue().jsmacros_getEndTick() - tick));Both branches produce equivalent localized strings. The early-init scenario risk is negligible here since these methods access item cooldowns that only exist after client initialization.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/ClientPlayerEntityHelper.java` around lines 737 - 776, Extract the duplicated version-specific item-to-string logic into a private static helper method cooldownKey(Item item) that contains the existing conditional version gate (the //? if >=26.1 { ... } else { ... } block) and returns the localized String; then replace the lambda in getItemCooldownsRemainingTicks() and getTicksSinceCooldownsStart() with e -> cooldownKey(e.getKey()) so both methods call the new helper (keep the helper private static and returning String).common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Rect.java (1)
419-449: Stonecutter brace-straddling here is fragile.The
try {is opened only inside the<1.21.11else-branch (line 424), thevc.addVertex(...)calls live ungated (429–432), and the matching} catch / } finally { ... }is reopened by the inner<1.21.11gate at line 434–448. It compiles for both branches today, but any future edit (e.g., adding an unconditional statement between 432 and 434, or flipping a gate) will silently desync the braces between the two version variants and one of the build targets will break.Consider duplicating the two render bodies fully under their own gates, or extracting two private helpers (
renderSeeThrough_legacy/renderSeeThrough_modern) so each branch is syntactically self-contained.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Rect.java` around lines 419 - 449, The Stonecutter version-gated braces are fragile because the try/catch/finally is opened inside the <1.21.11 branch but the work (vc.addVertex(...)) and the matching catch/finally are outside/inside the other gate, risking mismatched braces; fix by making each branch syntactically self-contained — either duplicate the rendering body under each gate or extract two private helpers (e.g., renderSeeThroughLegacy(...) and renderSeeThroughModern(...)) and call the appropriate helper from each version-gate so that debugQuadsDepthTestFunction manipulation, the VertexConsumer vc creation (consumers.getBuffer(...)), the vc.addVertex(...) calls, and the try/catch/finally are all contained within the same gate and method (referencing debugQuadsDepthTestFunction, RenderPipelines.DEBUG_QUADS, consumers, MultiBufferSource.BufferSource, and the vc.addVertex calls to locate the code).common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Box.java (1)
205-279: UnusedSubmitNodeCollectorparameter in the 26.1 render signature is systematic across all render elements.The collector parameter is accepted in Box.render() for
>=26.1but not referenced within the method body. The same pattern appears across all RenderElement3D implementations (Line3D, TraceLine, Surface, etc.) and is even threaded through Surface's helper methods (renderElements3D, renderElement3D). This suggests intentional placeholder implementation matching the deferred "RenderElement3D consolidation" plan. However, confirm that the 26.1 rendering pipeline does not expect elements to submit to the collector — otherwise these elements may silently fail to render once the rest of the pipeline begins enforcing collector usage.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Box.java` around lines 205 - 279, The SubmitNodeCollector parameter in the 26.1 render signature (e.g., Box.render(PoseStack, MultiBufferSource, SubmitNodeCollector, float)) is currently unused across RenderElement3D implementations; explicitly mark it as intentionally unused to avoid warnings and clarify intent by adding a brief TODO comment about the pending "RenderElement3D consolidation" plan and a `@SuppressWarnings`("unused") (or a single-line reference like _collector = collector;) in each affected method (Box.render, Line3D.render, TraceLine.render, Surface.render, Surface.renderElements3D, Surface.renderElement3D, etc.) so the signature stays compatible while making the placeholder status clear for later pipeline changes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 32524666-33c2-455e-9a57-7eb2ab1efce6
📒 Files selected for processing (112)
common/build.gradle.ktscommon/src/main/java/com/jsmacrosce/jsmacros/client/access/IScreenInternal.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/FakeServerCommandSource.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/RegistryHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/TextBuilder.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/inventory/Inventory.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/inventory/LoomInventory.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/Draw2D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/Draw3D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/IDraw2D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/ScriptScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Draw2DElement.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Image.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Item.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Line.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Rect.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/RenderElement.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Text.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Box.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/EntityTraceLine.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Line3D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/RenderElement3D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Surface.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/TraceLine.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/worldscanner/WorldScanner.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/event/impl/EventRecvMessage.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/CommandContextHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/InteractionManagerHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/OptionsHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/PacketByteBufferHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/StyleHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/inventory/ItemHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/inventory/ItemStackHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/ChatHudLineHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/ClickableWidgetHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/BlockDataHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/ChunkHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/StateHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/ClientPlayerEntityHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/EntityHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/library/impl/FClient.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/library/impl/FWorld.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/MacroContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/MacroListTopbar.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/RunningContextContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/ServiceContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/ServiceListTopbar.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/AboutOverlay.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/EventChooser.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/FileChooser.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/TextOverlay.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/screens/CancelScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/screens/EditorScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/screens/MacroScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/CategoryTreeContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/SettingsOverlay.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingcontainer/AbstractMapSettingContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingcontainer/PrimitiveSettingGroup.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/BooleanField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/DoubleField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/FileField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/FloatField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/IntField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/LongField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/OptionsField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/StringField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinChatHud.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinHandledScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinInGameHud.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemRenderer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemStackRenderState.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemStackRenderStateLayer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinMinecraftClient.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinStyleSerializer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinChatHud.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinClientPlayNetworkHandler.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinClientPlayerInteractionManager.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinCreativeInventoryScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinHandledScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinMessageHandler.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinWorldRenderer.javacommon/src/main/java/com/jsmacrosce/jsmacros/util/ChunkPosUtil.javacommon/src/main/java/com/jsmacrosce/jsmacros/util/ContainerInputCompat.javacommon/src/main/java/com/jsmacrosce/jsmacros/util/InteractionCompat.javacommon/src/main/java/com/jsmacrosce/jsmacros/util/SlotClickEventHelper.javacommon/src/main/java/com/jsmacrosce/wagyourgui/BaseScreen.javacommon/src/main/java/com/jsmacrosce/wagyourgui/containers/CheckBoxContainer.javacommon/src/main/java/com/jsmacrosce/wagyourgui/containers/ListContainer.javacommon/src/main/java/com/jsmacrosce/wagyourgui/containers/MultiElementContainer.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/AnnotatedCheckBox.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/Button.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/Scrollbar.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/Slider.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/TextInput.javacommon/src/main/java/com/jsmacrosce/wagyourgui/overlays/ConfirmOverlay.javacommon/src/main/java/com/jsmacrosce/wagyourgui/overlays/OverlayContainer.javacommon/src/main/java/com/jsmacrosce/wagyourgui/overlays/SelectorDropdownOverlay.javacommon/src/main/java/com/jsmacrosce/wagyourgui/overlays/TextPrompt.javacommon/src/main/resources/accesswideners/26.1.2-jsmacrosce.accesswidenerfabric/build.gradle.ktsfabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/JsMacrosFabric.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/api/classes/CommandBuilderFabric.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/api/classes/CommandManagerFabric.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinDebugHud.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinGameRenderer.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinKeyboard.javagradle/wrapper/gradle-wrapper.propertiessettings.gradle.ktsstonecutter.gradle.ktsversions/26.1.2/gradle.properties
| //? if >=26.1 { | ||
| /*private static final RenderPipeline ENTITY_TRANSLUCENT_SEE_THROUGH = RenderPipeline.builder(RenderPipelines.ENTITY_SNIPPET) | ||
| .withLocation("pipeline/jsmacrosce/entity_translucent_see_through") | ||
| .withDepthStencilState(new DepthStencilState(CompareOp.ALWAYS_PASS, false)) | ||
| .withCull(false) | ||
| .build(); | ||
| private static final Map<ResourceLocation, RenderType> ENTITY_TRANSLUCENT_SEE_THROUGH_TYPES = new ConcurrentHashMap<>(); | ||
| *///?} else if >=1.21.11 { |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Look for any other use of CompareOp / DepthStencilState in the repo to cross-check naming
rg -nP -C2 '\bCompareOp\.' --type=java
rg -nP -C2 'DepthStencilState' --type=java
# And the previous-version equivalent on the older pipeline builder:
rg -nP -C2 'withDepthStencilState|withDepthTestFunction' --type=javaRepository: JsMacrosCE/JsMacros
Length of output: 7710
🌐 Web query:
Minecraft 26.1 com.mojang.blaze3d.platform.CompareOp enum constants
💡 Result:
No evidence found of a class named com.mojang.blaze3d.platform.CompareOp in Minecraft 26.1 or any recent versions. Mappings sites like mappings.dev and ithundxr.dev list enums in com.mojang.blaze3d.platform such as DepthTestFunction, LogicOp, DestFactor, SourceFactor, but no CompareOp. The class may not exist, be in a different package (possibly com.mojang.blaze3d.opengl), or be obfuscated without public Yarn mappings available for 26.1. Minecraft 26.1 exists as a release (March 2026), but specific decompiled source for this class is not surfaced in searches. Closest matches are GlStateManager$DepthState which handles depth testing, likely using standard OpenGL compare functions (NEVER, LESS, EQUAL, LEQUAL, GREATER, NOTEQUAL, GEQUAL, ALWAYS).
Citations:
- 1: https://mappings.dev/1.21.1/com/mojang/blaze3d/platform/index.html
- 2: https://www.minecraft.net/en-us/article/minecraft-java-edition-26-1
- 3: https://mappings.ithundxr.dev/25w31a/com/mojang/blaze3d/platform/index.html
- 4: https://mappings.dev/1.21.6/com/mojang/blaze3d/platform/index.html
- 5: https://mappings.dev/1.21.8/com/mojang/blaze3d/platform/LogicOp.html
- 6: https://mappings.dev/1.20.6/com/mojang/blaze3d/platform/index.html
CompareOp.ALWAYS_PASS is not a valid Minecraft enum constant; this will cause a compile error when the >=26.1 code path activates.
The web search found no evidence that com.mojang.blaze3d.platform.CompareOp exists in Minecraft 26.1 or recent versions. Public Yarn mappings for 26.1 list DepthTestFunction in that package but no CompareOp. Standard OpenGL enum names do not include ALWAYS_PASS; the correct constant is ALWAYS.
The >=26.1 code path here (and identically in Rect.java line 54) uses an entirely different API from the active version—withDepthStencilState(new DepthStencilState(CompareOp.ALWAYS_PASS, false)) instead of the current withDepthTestFunction(DepthTestFunction.NO_DEPTH_TEST). Since this code is commented out, the compile error was not caught. These compile-time failures will surface when 26.1 support becomes active.
Confirm the correct 26.1 API names against deobfuscated source or the latest Yarn mappings and correct both Image.java and Rect.java.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Image.java`
around lines 60 - 67, The commented 26.1 branch in Image.java (and the identical
case in Rect.java) uses the non-existent CompareOp.ALWAYS_PASS and the old
DepthStencilState API; update these to the 26.1 API by removing the
DepthStencilState usage and calling the new withDepthTestFunction(...) method
(e.g. withDepthTestFunction(DepthTestFunction.NO_DEPTH_TEST) or the exact
DepthTestFunction constant from Yarn), and ensure the
RenderPipeline/RenderPipelines setup (ENTITY_TRANSLUCENT_SEE_THROUGH and
ENTITY_TRANSLUCENT_SEE_THROUGH_TYPES) compiles; verify the exact enum/class
names (DepthTestFunction and its constants, and withDepthTestFunction signature)
against the deobfuscated 26.1/Yarn mappings and apply the same fix in Rect.java.
| public TextBuilder withShowItemHover(ItemStackHelper item) { | ||
| //? if >=26.1 { | ||
| /*if (!item.getRaw().isEmpty()) { | ||
| self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(ItemStackTemplate.fromNonEmptyStack(item.getRaw())))); | ||
| } | ||
| *///?} else { | ||
| self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(item.getRaw()))); | ||
| //?} | ||
| return this; | ||
| } |
There was a problem hiding this comment.
Cross-version behavior divergence for empty stacks.
On 26.1, an empty stack silently leaves the style without a hover event; on older versions, a ShowItem hover is still attached for AIR/empty stacks. Callers chaining .withShowItemHover(empty) will see different runtime behavior depending on the target version. Consider guarding both branches identically (or documenting the no-op) so the API contract stays stable.
🔧 Proposed alignment
public TextBuilder withShowItemHover(ItemStackHelper item) {
+ if (item.getRaw().isEmpty()) return this;
//? if >=26.1 {
- /*if (!item.getRaw().isEmpty()) {
- self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(ItemStackTemplate.fromNonEmptyStack(item.getRaw()))));
- }
+ /*self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(ItemStackTemplate.fromNonEmptyStack(item.getRaw()))));
*///?} else {
self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(item.getRaw())));
//?}
return this;
}📝 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.
| public TextBuilder withShowItemHover(ItemStackHelper item) { | |
| //? if >=26.1 { | |
| /*if (!item.getRaw().isEmpty()) { | |
| self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(ItemStackTemplate.fromNonEmptyStack(item.getRaw())))); | |
| } | |
| *///?} else { | |
| self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(item.getRaw()))); | |
| //?} | |
| return this; | |
| } | |
| public TextBuilder withShowItemHover(ItemStackHelper item) { | |
| if (item.getRaw().isEmpty()) return this; | |
| //? if >=26.1 { | |
| /*self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(ItemStackTemplate.fromNonEmptyStack(item.getRaw())))); | |
| *///?} else { | |
| self.withStyle(style -> style.withHoverEvent(new HoverEvent.ShowItem(item.getRaw()))); | |
| //?} | |
| return this; | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/TextBuilder.java`
around lines 157 - 166, The withShowItemHover method in TextBuilder currently
differs by Minecraft version: newer branch skips attaching a hover for empty
stacks but the older branch always attaches a ShowItem (including AIR), causing
inconsistent API behavior; update the method (TextBuilder.withShowItemHover) to
perform the same emptiness guard in both branches by checking
item.getRaw().isEmpty() (or ItemStackHelper.isEmpty) before calling
self.withStyle(...) and only attach HoverEvent.ShowItem (using
HoverEvent.ShowItem and ItemStackTemplate.fromNonEmptyStack where applicable)
when the stack is non-empty so both code paths are identical no-ops for empty
stacks.
| public static InteractionResult interact(MultiPlayerGameMode gameMode, LocalPlayer player, Entity entity, InteractionHand hand) { | ||
| //? if >=26.1 { | ||
| /*return gameMode.interact(player, entity, new EntityHitResult(entity), hand); | ||
| *///?} else { | ||
| return gameMode.interact(player, entity, hand); | ||
| //?} | ||
| } |
There was a problem hiding this comment.
Synthetic EntityHitResult(entity) may misrepresent the actual interaction hit location.
new EntityHitResult(entity) uses the entity's position as the hit location instead of the real crosshair raycast point. For interactions where the hit location is meaningful (e.g., placing armor stand items, sitting on boats, mobs that respond to where they were clicked), this can produce incorrect behavior compared to vanilla — vanilla typically passes the EntityHitResult produced by the picker, which carries the precise hit Vec3.
Consider accepting a hit-location parameter (or letting callers pass an EntityHitResult they obtained from Minecraft#hitResult when available), and falling back to new EntityHitResult(entity) only when no real hit is known.
Sketch
- public static InteractionResult interact(MultiPlayerGameMode gameMode, LocalPlayer player, Entity entity, InteractionHand hand) {
- //? if >=26.1 {
- /*return gameMode.interact(player, entity, new EntityHitResult(entity), hand);
- *///?} else {
- return gameMode.interact(player, entity, hand);
- //?}
- }
+ public static InteractionResult interact(MultiPlayerGameMode gameMode, LocalPlayer player, Entity entity, InteractionHand hand) {
+ //? if >=26.1 {
+ /*net.minecraft.world.phys.HitResult hr = net.minecraft.client.Minecraft.getInstance().hitResult;
+ EntityHitResult ehr = (hr instanceof EntityHitResult e && e.getEntity() == entity) ? e : new EntityHitResult(entity);
+ return gameMode.interact(player, entity, ehr, hand);
+ *///?} else {
+ return gameMode.interact(player, entity, hand);
+ //?}
+ }Minecraft 26.1 MultiPlayerGameMode interact EntityHitResult signature
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@common/src/main/java/com/jsmacrosce/jsmacros/util/InteractionCompat.java`
around lines 15 - 21, The current InteractionCompat.interact method constructs a
synthetic EntityHitResult(entity) which can misrepresent the true crosshair hit
location; change the API to accept an EntityHitResult (or an optional hit Vec3)
from callers (the value usually available from Minecraft#hitResult) and pass
that through to MultiPlayerGameMode.interact instead of always constructing new
EntityHitResult(entity), falling back to new EntityHitResult(entity) only when
the caller provides null/absent hit info; update the method signature/overload
for InteractionCompat.interact and all call sites so they supply the real hit
result when available so MultiPlayerGameMode.interact receives the precise hit
location.
| @Override | ||
| //? if >=26.1 { | ||
| /*public void extractWidgetRenderState(GuiGraphicsExtractor drawContext, int mouseX, int mouseY, float delta) { | ||
| *///?} else { | ||
| public void renderWidget(GuiGraphics drawContext, int mouseX, int mouseY, float delta) { | ||
| //?} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Cross-check overload spelling/visibility across the project's 26.1-gated render hooks.
rg -nP '\b(extractWidgetRenderState|extractRenderState|renderWidget)\s*\(' --type=java -C1Repository: JsMacrosCE/JsMacros
Length of output: 12238
Rename extractWidgetRenderState to extractRenderState and match visibility to Slider (use protected).
Two critical issues:
-
Method name mismatch: The declared method is
extractWidgetRenderState, butOverlayContainer.java:157callsextractRenderStateonAbstractWidgetinstances. If Scrollbar widgets are managed there, they'll ignore the call and silently fail to render on 26.1. The pattern across the codebase (CancelScreen, MacroScreen, EditorScreen, etc.) consistently usesextractRenderState, notextractWidgetRenderState. -
Visibility inconsistency: Scrollbar declares
publicwhile the sibling widgetSlider.java:113declaresprotected. Both use the same (likely incorrect) method name. Align toprotectedto matchSlider.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@common/src/main/java/com/jsmacrosce/wagyourgui/elements/Scrollbar.java`
around lines 117 - 122, The Scrollbar class currently declares a public method
named extractWidgetRenderState but the codebase (OverlayContainer calling
extractRenderState on AbstractWidget and other widgets like Slider) expects a
protected extractRenderState method; rename extractWidgetRenderState to
extractRenderState and change its visibility to protected so its signature and
access match Slider and the AbstractWidget usage, ensuring OverlayContainer will
dispatch rendering correctly.
| //? if >=26.1 { | ||
| /*@Redirect(method = "extractGui", at = @At(value = "INVOKE", target = "Lnet/minecraft/client/gui/screens/Screen;extractRenderStateWithTooltipAndSubtitles(Lnet/minecraft/client/gui/GuiGraphicsExtractor;IIF)V")) | ||
| private void onRender(Screen instance, GuiGraphicsExtractor drawContext, int mouseX, int mouseY, float delta) { | ||
| instance.extractRenderStateWithTooltipAndSubtitles(drawContext, mouseX, mouseY, delta); | ||
| if (!(minecraft.screen instanceof ScriptScreen)) { | ||
| ((IScreenInternal) instance).jsmacros_render(drawContext, mouseX, mouseY, delta); | ||
| } | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search the project for any references that imply the actual MC 26.1 method names, and confirm the mixin's
# target string is spelled consistently across the codebase (e.g., other gates referencing extractGui /
# extractRenderStateWithTooltipAndSubtitles).
rg -nP --type=java -C2 '\bextractGui\b|extractRenderStateWithTooltipAndSubtitles'
# Also surface any other GameRenderer mixins to ensure none have stale targets on 26.1.
fd -e java -i 'mixingamerenderer'Repository: JsMacrosCE/JsMacros
Length of output: 1449
🏁 Script executed:
cat -n fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinGameRenderer.javaRepository: JsMacrosCE/JsMacros
Length of output: 3629
Add require = 1 to the 26.1 @Redirect to prevent silent failures if method names change.
The 26.1 branch changes the redirect target from method = "render" to method = "extractGui" and the intercept from Screen.renderWithTooltipAndSubtitles to Screen.extractRenderStateWithTooltipAndSubtitles. The descriptor (Lnet/minecraft/client/gui/GuiGraphicsExtractor;IIF)V correctly encodes the parameter signature (int, int, float).
However, Mixin logs redirect mismatches only at debug level by default—a typo or API shift would silently make the @Redirect a no-op, leaving the IScreenInternal hook never firing. The existing code is consistent with the version evolution pattern (shown in the >1.21.8 and <1.21.8 branches), but adding require = 1 to the annotation will surface any future Mojang renames as a hard failure instead of a silent skip.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinGameRenderer.java`
around lines 30 - 37, The `@Redirect` in MixinGameRenderer's onRender targeting
Screen.extractRenderStateWithTooltipAndSubtitles should include require = 1 so
the mixin fails loudly if the target method signature/name changes; update the
`@Redirect` annotation on the onRender method (the Redirect that references
Screen.extractRenderStateWithTooltipAndSubtitles and the descriptor
(Lnet/minecraft/client/gui/GuiGraphicsExtractor;IIF)V) to add require = 1 to
ensure the IScreenInternal.jsmacros_render hook cannot be silently skipped.
| @WrapOperation(method = "charTyped", at = @At(value = "INVOKE", target = "Lnet/minecraft/client/gui/screens/Screen;charTyped(Lnet/minecraft/client/input/CharacterEvent;)Z")) | ||
| private boolean onCharTyped1(Screen instance, CharacterEvent characterEvent, Operation<Boolean> original) { | ||
| // 26.1's CharacterEvent is char-only by design — modifier bits only travel with KeyEvent now. | ||
| ((IScreenInternal) instance).jsmacros_charTyped((char) characterEvent.codepoint(), 0); | ||
| return original.call(instance, characterEvent); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify CharacterEvent shape in 26.1 across the codebase.
rg -nP --type=java -C2 '\bCharacterEvent\b'
rg -nP --type=java -C2 '\bcharacterEvent\.\w+'Repository: JsMacrosCE/JsMacros
Length of output: 8433
🌐 Web query:
Minecraft 26.1 CharacterEvent fields modifiers codepoint
💡 Result:
In Minecraft Java Edition 26.1 (and compatible mod loaders like NeoForge), CharacterEvent is a record class in net.minecraft.client.input with two fields: codepoint (private final int) representing the Unicode codepoint of the character, and modifiers (private final @net.minecraft.client.input.InputWithModifiers.Modifiers int) representing keyboard modifier keys (e.g., shift, control). Both fields have public accessor methods: codepoint and modifiers. The modifiers field uses the InputWithModifiers.Modifiers annotation/type.
Citations:
Replace hardcoded 0 with characterEvent.modifiers() to fix behavioral regression.
The code passes a hardcoded 0 for modifiers (line 30), but CharacterEvent in 26.1 actually does provide a modifiers() accessor. This breaks backward compatibility: any user script reading modifiers inside a CHAR_TYPED handler will silently lose Shift/Ctrl/Alt detection.
The older version (lines 40–44) correctly calls characterEvent.modifiers(). The 26.1 branch should do the same for consistency:
((IScreenInternal) instance).jsmacros_charTyped((char) characterEvent.codepoint(), characterEvent.modifiers());🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinKeyboard.java`
around lines 27 - 32, Replace the hardcoded modifier value in
MixinKeyboard.onCharTyped1: instead of passing 0 to
IScreenInternal.jsmacros_charTyped, call the CharacterEvent.modifiers() accessor
(i.e., use characterEvent.modifiers()) so jsmacros_charTyped receives the actual
modifier bits.
| fabric_version=0.146.1+26.1.2 | ||
| fabric_loader_version=0.19.2 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What are the current Fabric Loader and Fabric API versions for Minecraft 26.1.2 on fabricmc.net?
💡 Result:
The current Fabric Loader version recommended for Minecraft 26.1 (including 26.1.2) is the latest stable release, 0.19.1. Fabric Loader is largely version-independent and supports Minecraft 26.1 via the Fabric installer on fabricmc.net, which selects the latest compatible loader (latest release as of 2026-04-25 is 0.19.1 from GitHub releases). The official Fabric blog for Minecraft 26.1 mentions "latest stable version of Fabric Loader (currently 0.18.4)" but this is outdated (published March 2026); subsequent releases include 0.19.0 (April 7) and 0.19.1 (April 9). The current Fabric API version for Minecraft 26.1.2 is 0.146.1+26.1.2, as per the latest release on FabricMC/fabric-api GitHub (April 17, 2026). This is confirmed by GitHub release notes specifically tagged for 26.1.2. Fabric API is downloaded separately from mod sites like Modrinth/CurseForge or GitHub after installing Loader, and fabricmc.net links to these.
Citations:
- 1: https://fabricmc.net/2026/03/14/261.html
- 2: https://github.com/FabricMC/fabric-loader
- 3: https://github.com/FabricMC/fabric-loader/releases
- 4: https://github.com/FabricMC/fabric-api/releases/latest
- 5: https://skinmc.net/project/fabric-api
Fix incorrect Fabric Loader version: change 0.19.2 to 0.19.1.
fabric_loader_version=0.19.2 does not exist. The latest Fabric Loader version for MC 26.1.2 is 0.19.1 (released April 9, 2026). The fabric_version=0.146.1+26.1.2 coordinate is correct.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@versions/26.1.2/gradle.properties` around lines 16 - 17, Update the
fabric_loader_version property to the correct published version; change the
value of the fabric_loader_version variable from 0.19.2 to 0.19.1 in the
gradle.properties entry so it reads fabric_loader_version=0.19.1, leaving
fabric_version unchanged.
Reply to coderabbitai review (17 comments)Thanks for the detailed pass — going through each. Most of these flag stonecutter-gated
Net: 13 false positives (coderabbit misreading stonecutter Happy to take any of the trade-offs as follow-up PRs if maintainers feel strongly (TextBuilder hover-guard parity is the smallest one, ~2 lines). |
|
Also would be stoked to rip out 1.21.x but didn't want to do that without a discussion first. |
grepsedawk
force-pushed
the
feat/mc-26.1
branch
5 times, most recently
from
a75bbe6 to
d8fa56f
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinChatHud.java (1)
68-96:⚠️ Potential issue | 🟡 MinorThree-way
overrideMessagePosgate is correct; body duplication is unavoidable.The split between
>=26.1(multiplayer.chat.GuiMessage),>=1.21.11(client.GuiMessage withaddFirst), and the legacy@ModifyArg(add(I,Object)) path correctly reflects upstream changes:
- 1.21.11 introduced the
addFirstredirection (matches the active code path).- 26.1 only changed the
GuiMessagepackage, so the redirect body is identical apart from the descriptor.The method descriptor must be statically bound to each version's signature, so duplication between
>=26.1and>=1.21.11branches is unavoidable.
List.addFirstis indeed a Java 21 SequencedCollection method. Since the PR notes confirm FO 26.1.2 boots clean, the bytecode is correctly invokingList.addFirstat runtime and the redirect is firing as expected. If the redirect failed to bind (e.g., due to a direct method call on a concrete class), Mixin would raise an exception at load time.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinChatHud.java` around lines 68 - 96, Keep the three-way gated overrides as-is: the duplicate bodies of overrideMessagePos are required because the method descriptors differ across versions (the two `@Redirects` for addMessageToQueue with signatures "Lnet/minecraft/client/multiplayer/chat/GuiMessage;" and "Lnet/minecraft/client/GuiMessage;" must be present and statically bound), and the legacy `@ModifyArg` path (targeting List.add(I,Object)) is needed for older builds; do not merge them into one method—instead, add a brief clarifying comment above the overrideMessagePos definitions referencing jsmacros$positionOverride, the two `@Redirect` annotations and the `@ModifyArg` fallback so future readers understand the unavoidable duplication and version-specific descriptors.common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/RegistryHelper.java (1)
104-114:⚠️ Potential issue | 🔴 CriticalFix 26.1 branch: use
createItemStack(1)to align withItemHelperand avoid undefined method calls.The 26.1 branch attempts to call
itemResult.item()anditemResult.components()onItemInput, but this class does not expose these methods.ItemHelper.getStackWithNbt()andCommandContextHelperboth useItemInput.createItemStack(1)on 26.1, which internally handles both item and component construction. Update the 26.1 branch to match:/*ItemInput itemInput = reader.parse(new StringReader(parseNameSpace(id) + nbt)); return new CreativeItemStackHelper(itemInput.createItemStack(1)); *///?} else { ItemParser.ItemResult itemResult = reader.parse(new StringReader(parseNameSpace(id) + nbt)); ItemStack stack = new ItemStack(itemResult.item()); stack.applyComponents(itemResult.components()); return new CreativeItemStackHelper(stack); //?}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/RegistryHelper.java` around lines 104 - 114, In RegistryHelper.getItemStack, the 26.1 branch should use ItemInput.createItemStack(1) instead of calling item()/components() on ItemInput; update the branch that currently parses via ItemParser to declare ItemInput (e.g., ItemInput itemInput = reader.parse(new StringReader(parseNameSpace(id) + nbt))) and return new CreativeItemStackHelper(itemInput.createItemStack(1)), removing the manual ItemStack construction and applyComponents calls so behavior matches ItemHelper/CommandContextHelper.
🧹 Nitpick comments (5)
common/src/main/java/com/jsmacrosce/jsmacros/util/ContainerInputCompat.java (1)
44-46: Avoid relying onClickTypeordinal order; mirror the 26.1 explicit switch.
ClickType.values()[action]silently couples this compat layer to Mojang's enum declaration order. It happens to align with the localPICKUP..PICKUP_ALLconstants today, but a future reorder/insert inClickTypewould re-map every action to the wrong value with no compile- or runtime-time signal. It also throwsArrayIndexOutOfBoundsExceptionon bad input, whereas the 26.1 branch throwsIllegalArgumentException— two different error contracts for the same public API depending on which jar you're on. Allocating a freshvalues()array on every click is also avoidable.Suggest mirroring the 26.1 branch for symmetry and robustness:
♻️ Proposed refactor
- private static ClickType toAction(int action) { - return ClickType.values()[action]; - } + private static ClickType toAction(int action) { + return switch (action) { + case PICKUP -> ClickType.PICKUP; + case QUICK_MOVE -> ClickType.QUICK_MOVE; + case SWAP -> ClickType.SWAP; + case CLONE -> ClickType.CLONE; + case THROW -> ClickType.THROW; + case QUICK_CRAFT -> ClickType.QUICK_CRAFT; + case PICKUP_ALL -> ClickType.PICKUP_ALL; + default -> throw new IllegalArgumentException("Unknown click action: " + action); + }; + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/util/ContainerInputCompat.java` around lines 44 - 46, The toAction(int action) method currently uses ClickType.values()[action], which relies on enum ordinals, allocates a values array each call, and throws ArrayIndexOutOfBoundsException for bad input; replace it with an explicit switch over the int values mirroring the 26.1 branch mapping (map each integer case to the corresponding ClickType constant) and have the default case throw IllegalArgumentException with a clear message; update the method signature in ContainerInputCompat.toAction to use that switch so no values() allocation or ordinal-dependence remains.common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.java (1)
153-189: Reasonable handling of the upstreamEditBox.setFilterremoval.The stonecutter split keeps <26.1 behavior intact while making the 26.1+ regression observable via a once-per-JVM
LOGGER.warn(the/*…*///?}flip toggles the warn block into live code on 26.1+, so the warning is actually emitted — not dead). TheAtomicBoolean.compareAndSet(false, true)gate is correct for a one-shot warning, and the inline comment block (Lines 153-156) clearly documents the rationale and the deliberate gap. This matches the intentional-regression note in the PR description.One minor optional cleanup: the two static
AtomicBooleanfields and theJsMacros/AtomicBooleanimports are referenced only from the 26.1+ branch, so on <26.1 builds they end up as dead state / unused imports. If you want fully version-clean output you could wrap the field declarations (and optionally the imports) in a//? if >=26.1gate; entirely optional given the negligible footprint.♻️ Optional: gate the warn-once state to 26.1+
- private static final AtomicBoolean SET_TEXT_PREDICATE_WARNED = new AtomicBoolean(); - private static final AtomicBoolean RESET_TEXT_PREDICATE_WARNED = new AtomicBoolean(); + //? if >=26.1 { + /*private static final AtomicBoolean SET_TEXT_PREDICATE_WARNED = new AtomicBoolean(); + private static final AtomicBoolean RESET_TEXT_PREDICATE_WARNED = new AtomicBoolean(); + *///?}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.java` around lines 153 - 189, The code currently emits a one-shot warning for removed EditBox.setFilter on 26.1+ but leaves the two AtomicBoolean fields and their imports present on all builds; to avoid unused-field/import warnings on <26.1 you can gate them to only compile on 26.1+: move or wrap the static fields SET_TEXT_PREDICATE_WARNED and RESET_TEXT_PREDICATE_WARNED (and any related JsMacros/AtomicBoolean imports) inside a version gate such as //? if >=26.1 so they are only declared when the warning branch in TextFieldWidgetHelper.setTextPredicate and TextFieldWidgetHelper.resetTextPredicate is live. Ensure the gates match the existing commented warn blocks so behavior is unchanged on 26.1+ and dead on older builds.common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinChatHud.java (1)
118-140: Two HEAD injectors on the same overload — consider consolidating (optional).
onAddMessage1(lines 33-61) andonAddChatMessage(lines 118-140) both inject at@At("HEAD")withcancellable=trueon the sameaddMessageoverload. The split predates this PR (same pattern in the legacy branch), so it isn't a regression — but since you're already touching both for the 26.1 retarget, consolidating them into a single HEAD injector would halve the per-version gate maintenance and remove the implicit ordering assumption between the two cancels.Not a blocker; flagging only because it would simplify the next stonecutter port.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinChatHud.java` around lines 118 - 140, There are two HEAD injectors for the same addMessage overload (the methods onAddMessage1 and onAddChatMessage) — consolidate them into a single HEAD injector that handles both version gates instead of keeping duplicate injectors; merge the null-check/cancel logic from onAddMessage1 and onAddChatMessage into one injected method targeting the addMessage signature used in the diff (the appropriate Lnet/minecraft/... addMessage descriptor) and remove the redundant injector, preserving the version gating comments (the ?>=26.1 branch) so only one cancellable HEAD injection exists across versions.fabric/build.gradle.kts (1)
117-124: Minor:defaultRefmapNameis a no-op on the no-remap Loom variant.
mixin.defaultRefmapName.set(...)only matters when Loom generates a refmap duringremapJar. On 26.1 (deobfuscated, noremapJar), this setting is harmless but unused. Not a blocker — keeping it unconditional avoids an extra branch and the property exists onLoomGradleExtensionAPIfor both plugin variants — but consider a TODO comment so future readers don't assume refmaps are produced for 26.1 jars.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fabric/build.gradle.kts` around lines 117 - 124, The mixin.defaultRefmapName.set(...) call is a no-op for the no-remap Loom variant (used in 26.1 where remapJar isn't run); add a short TODO comment next to the mixin(Action { defaultRefmapName.set(...) }) line explaining that defaultRefmapName is only used when Loom performs remapJar and that on the no-remap/26.1 variant this setting is harmless but unused (reference LoomGradleExtensionAPI, mixin, defaultRefmapName, remapJar) so future readers don’t assume a refmap is produced for 26.1 jars.stonecutter.gradle.kts (1)
142-159: LGTM, one small consistency nit.The deobfuscated/remapping discriminator is duplicated as
mcVersion.startsWith("26.")here andminecraft_version.startsWith("26.")infabric/build.gradle.kts. If 26.2/27.x ever ships obfuscated again (or a different prefix is used), both call sites need to be updated in lockstep. Consider promoting this to a shared helper (e.g., agradle.extra["isDeobfuscatedMc"]predicate or abuildSrcutility) at follow-up cleanup time.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stonecutter.gradle.kts` around lines 142 - 159, The mcVersion.startsWith("26.") check used in fabricArtifactTask is duplicated elsewhere (minecraft_version.startsWith("26.") in fabric/build.gradle.kts); extract that logic into a single shared helper (either expose a predicate on gradle.extra like gradle.extra["isDeobfuscatedMc"] or add a small utility in buildSrc) and replace both call sites (fabricArtifactTask and the check in fabric/build.gradle.kts) to use the shared predicate to ensure one source of truth for the deobfuscated/remapping decision.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/ScriptScreen.java`:
- Around line 40-44: The onRender MethodWrapper in ScriptScreen must use the
renamed second-argument type for MC 26.1+: change the declaration of onRender
(MethodWrapper<Pos3D, GuiGraphics, Object, ?>) to MethodWrapper<Pos3D,
GuiGraphicsExtractor, Object, ?> when targeting 26.1 and keep GuiGraphics for
older targets; update the conditional block around the onRender field so the
correct type is compiled for each target and ensure any call sites that
construct or reference onRender (and scripts that type the second parameter) are
adjusted to the corresponding GuiGraphicsExtractor/GiGraphics type.
In
`@fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinGameRenderer.java`:
- Around line 56-63: The >=26.1 injection for pick is currently commented out so
InteractionProxy.Target.onUpdate never runs on 26.1+; locate the commented
`@Inject` block in MixinMinecraftClient that was intended to replace pick(F)V (the
stub around the method that mirrors MixinGameRenderer.onTargetUpdate) and either
uncomment and restore the injection so it calls
InteractionProxy.Target.onUpdate(float) and cancels via CallbackInfo when true,
or implement an equivalent hook for the new 26.1+ method signature (ensuring the
injected method name and signature match Minecraft's current pick method and
still calls InteractionProxy.Target.onUpdate and ci.cancel()). Ensure the
injection annotation, method name and parameters match the runtime target so the
override actually executes.
In `@settings.gradle.kts`:
- Around line 46-55: Update both fabric-loom plugin declarations to use the
latest 1.15.x release: change the version string on id("fabric-loom") and
id("net.fabricmc.fabric-loom") from "1.15.4" to "1.15.5" so both plugin entries
match the current stable 1.15.5 release.
---
Outside diff comments:
In
`@common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/RegistryHelper.java`:
- Around line 104-114: In RegistryHelper.getItemStack, the 26.1 branch should
use ItemInput.createItemStack(1) instead of calling item()/components() on
ItemInput; update the branch that currently parses via ItemParser to declare
ItemInput (e.g., ItemInput itemInput = reader.parse(new
StringReader(parseNameSpace(id) + nbt))) and return new
CreativeItemStackHelper(itemInput.createItemStack(1)), removing the manual
ItemStack construction and applyComponents calls so behavior matches
ItemHelper/CommandContextHelper.
In
`@common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinChatHud.java`:
- Around line 68-96: Keep the three-way gated overrides as-is: the duplicate
bodies of overrideMessagePos are required because the method descriptors differ
across versions (the two `@Redirects` for addMessageToQueue with signatures
"Lnet/minecraft/client/multiplayer/chat/GuiMessage;" and
"Lnet/minecraft/client/GuiMessage;" must be present and statically bound), and
the legacy `@ModifyArg` path (targeting List.add(I,Object)) is needed for older
builds; do not merge them into one method—instead, add a brief clarifying
comment above the overrideMessagePos definitions referencing
jsmacros$positionOverride, the two `@Redirect` annotations and the `@ModifyArg`
fallback so future readers understand the unavoidable duplication and
version-specific descriptors.
---
Nitpick comments:
In
`@common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.java`:
- Around line 153-189: The code currently emits a one-shot warning for removed
EditBox.setFilter on 26.1+ but leaves the two AtomicBoolean fields and their
imports present on all builds; to avoid unused-field/import warnings on <26.1
you can gate them to only compile on 26.1+: move or wrap the static fields
SET_TEXT_PREDICATE_WARNED and RESET_TEXT_PREDICATE_WARNED (and any related
JsMacros/AtomicBoolean imports) inside a version gate such as //? if >=26.1 so
they are only declared when the warning branch in
TextFieldWidgetHelper.setTextPredicate and
TextFieldWidgetHelper.resetTextPredicate is live. Ensure the gates match the
existing commented warn blocks so behavior is unchanged on 26.1+ and dead on
older builds.
In
`@common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinChatHud.java`:
- Around line 118-140: There are two HEAD injectors for the same addMessage
overload (the methods onAddMessage1 and onAddChatMessage) — consolidate them
into a single HEAD injector that handles both version gates instead of keeping
duplicate injectors; merge the null-check/cancel logic from onAddMessage1 and
onAddChatMessage into one injected method targeting the addMessage signature
used in the diff (the appropriate Lnet/minecraft/... addMessage descriptor) and
remove the redundant injector, preserving the version gating comments (the
?>=26.1 branch) so only one cancellable HEAD injection exists across versions.
In `@common/src/main/java/com/jsmacrosce/jsmacros/util/ContainerInputCompat.java`:
- Around line 44-46: The toAction(int action) method currently uses
ClickType.values()[action], which relies on enum ordinals, allocates a values
array each call, and throws ArrayIndexOutOfBoundsException for bad input;
replace it with an explicit switch over the int values mirroring the 26.1 branch
mapping (map each integer case to the corresponding ClickType constant) and have
the default case throw IllegalArgumentException with a clear message; update the
method signature in ContainerInputCompat.toAction to use that switch so no
values() allocation or ordinal-dependence remains.
In `@fabric/build.gradle.kts`:
- Around line 117-124: The mixin.defaultRefmapName.set(...) call is a no-op for
the no-remap Loom variant (used in 26.1 where remapJar isn't run); add a short
TODO comment next to the mixin(Action { defaultRefmapName.set(...) }) line
explaining that defaultRefmapName is only used when Loom performs remapJar and
that on the no-remap/26.1 variant this setting is harmless but unused (reference
LoomGradleExtensionAPI, mixin, defaultRefmapName, remapJar) so future readers
don’t assume a refmap is produced for 26.1 jars.
In `@stonecutter.gradle.kts`:
- Around line 142-159: The mcVersion.startsWith("26.") check used in
fabricArtifactTask is duplicated elsewhere (minecraft_version.startsWith("26.")
in fabric/build.gradle.kts); extract that logic into a single shared helper
(either expose a predicate on gradle.extra like gradle.extra["isDeobfuscatedMc"]
or add a small utility in buildSrc) and replace both call sites
(fabricArtifactTask and the check in fabric/build.gradle.kts) to use the shared
predicate to ensure one source of truth for the deobfuscated/remapping decision.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e923ba99-7a63-4a65-a66c-765e974632db
📒 Files selected for processing (112)
common/build.gradle.ktscommon/src/main/java/com/jsmacrosce/jsmacros/client/access/IScreenInternal.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/FakeServerCommandSource.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/RegistryHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/TextBuilder.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/inventory/Inventory.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/inventory/LoomInventory.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/Draw2D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/Draw3D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/IDraw2D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/ScriptScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Draw2DElement.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Image.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Item.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Line.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Rect.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/RenderElement.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Text.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Box.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/EntityTraceLine.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Line3D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/RenderElement3D.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Surface.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/TraceLine.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/worldscanner/WorldScanner.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/event/impl/EventRecvMessage.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/CommandContextHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/InteractionManagerHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/OptionsHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/PacketByteBufferHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/StyleHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/inventory/ItemHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/inventory/ItemStackHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/ChatHudLineHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/ClickableWidgetHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/TextFieldWidgetHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/BlockDataHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/ChunkHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/StateHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/ClientPlayerEntityHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/EntityHelper.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/library/impl/FClient.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/api/library/impl/FWorld.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/MacroContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/MacroListTopbar.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/RunningContextContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/ServiceContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/ServiceListTopbar.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/AboutOverlay.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/EventChooser.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/FileChooser.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/TextOverlay.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/screens/CancelScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/screens/EditorScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/screens/MacroScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/CategoryTreeContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/SettingsOverlay.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingcontainer/AbstractMapSettingContainer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingcontainer/PrimitiveSettingGroup.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/BooleanField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/DoubleField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/FileField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/FloatField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/IntField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/LongField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/OptionsField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/StringField.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinChatHud.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinHandledScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinInGameHud.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemRenderer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemStackRenderState.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemStackRenderStateLayer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinMinecraftClient.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinStyleSerializer.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinChatHud.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinClientPlayNetworkHandler.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinClientPlayerInteractionManager.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinCreativeInventoryScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinHandledScreen.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinMessageHandler.javacommon/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinWorldRenderer.javacommon/src/main/java/com/jsmacrosce/jsmacros/util/ChunkPosUtil.javacommon/src/main/java/com/jsmacrosce/jsmacros/util/ContainerInputCompat.javacommon/src/main/java/com/jsmacrosce/jsmacros/util/InteractionCompat.javacommon/src/main/java/com/jsmacrosce/jsmacros/util/SlotClickEventHelper.javacommon/src/main/java/com/jsmacrosce/wagyourgui/BaseScreen.javacommon/src/main/java/com/jsmacrosce/wagyourgui/containers/CheckBoxContainer.javacommon/src/main/java/com/jsmacrosce/wagyourgui/containers/ListContainer.javacommon/src/main/java/com/jsmacrosce/wagyourgui/containers/MultiElementContainer.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/AnnotatedCheckBox.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/Button.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/Scrollbar.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/Slider.javacommon/src/main/java/com/jsmacrosce/wagyourgui/elements/TextInput.javacommon/src/main/java/com/jsmacrosce/wagyourgui/overlays/ConfirmOverlay.javacommon/src/main/java/com/jsmacrosce/wagyourgui/overlays/OverlayContainer.javacommon/src/main/java/com/jsmacrosce/wagyourgui/overlays/SelectorDropdownOverlay.javacommon/src/main/java/com/jsmacrosce/wagyourgui/overlays/TextPrompt.javacommon/src/main/resources/accesswideners/26.1.2-jsmacrosce.accesswidenerfabric/build.gradle.ktsfabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/JsMacrosFabric.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/api/classes/CommandBuilderFabric.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/api/classes/CommandManagerFabric.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinDebugHud.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinGameRenderer.javafabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinKeyboard.javagradle/wrapper/gradle-wrapper.propertiessettings.gradle.ktsstonecutter.gradle.ktsversions/26.1.2/gradle.properties
✅ Files skipped from review due to trivial changes (16)
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/ChatHudLineHelper.java
- gradle/wrapper/gradle-wrapper.properties
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/event/impl/EventRecvMessage.java
- common/src/main/java/com/jsmacrosce/jsmacros/util/ChunkPosUtil.java
- fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinDebugHud.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinStyleSerializer.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemStackRenderStateLayer.java
- common/src/main/resources/accesswideners/26.1.2-jsmacrosce.accesswidener
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemStackRenderState.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinItemRenderer.java
- versions/26.1.2/gradle.properties
- common/src/main/java/com/jsmacrosce/wagyourgui/containers/CheckBoxContainer.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Draw2DElement.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/inventory/Inventory.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Image.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Item.java
🚧 Files skipped from review as they are similar to previous changes (40)
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/library/impl/FClient.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/StyleHelper.java
- fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/JsMacrosFabric.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/CommandContextHelper.java
- fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/api/classes/CommandManagerFabric.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinInGameHud.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinClientPlayerInteractionManager.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/entity/EntityHelper.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/FakeServerCommandSource.java
- common/src/main/java/com/jsmacrosce/wagyourgui/overlays/OverlayContainer.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinMinecraftClient.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/world/StateHelper.java
- common/src/main/java/com/jsmacrosce/wagyourgui/BaseScreen.java
- common/src/main/java/com/jsmacrosce/jsmacros/util/SlotClickEventHelper.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/TraceLine.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/gui/overlays/TextOverlay.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/BooleanField.java
- common/src/main/java/com/jsmacrosce/wagyourgui/elements/Button.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingfields/LongField.java
- common/src/main/java/com/jsmacrosce/wagyourgui/overlays/SelectorDropdownOverlay.java
- common/src/main/java/com/jsmacrosce/wagyourgui/containers/ListContainer.java
- common/src/main/java/com/jsmacrosce/wagyourgui/elements/Scrollbar.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/OptionsHelper.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/settingcontainer/PrimitiveSettingGroup.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/Draw2D.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/library/impl/FWorld.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/ServiceListTopbar.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/MacroContainer.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/EntityTraceLine.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/gui/settings/CategoryTreeContainer.java
- fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/api/classes/CommandBuilderFabric.java
- common/src/main/java/com/jsmacrosce/wagyourgui/overlays/TextPrompt.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components/Line.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/helper/screen/ClickableWidgetHelper.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Surface.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Box.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/api/classes/render/components3d/Line3D.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/events/MixinWorldRenderer.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/gui/containers/ServiceContainer.java
- common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinHandledScreen.java
| //? if <26.1 { | ||
| @Inject(at = @At("HEAD"), method = "pick(F)V", cancellable = true) | ||
| public void onTargetUpdate(float tickDelta, CallbackInfo ci) { | ||
| if (InteractionProxy.Target.onUpdate(tickDelta)) { | ||
| ci.cancel(); | ||
| } | ||
| } | ||
| //?} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Locate any >=26.1 mixin/inject that calls InteractionProxy.Target.onUpdate to confirm pick parity.
rg -nP --type=java -C3 'InteractionProxy\.Target\.onUpdate'
echo
echo "=== mixins targeting pick / pickProjectile / extractGui under fabric ==="
rg -nP --type=java -C3 'method\s*=\s*"(pick|pickProjectile|extractGui)"'Repository: JsMacrosCE/JsMacros
Length of output: 3245
The >=26.1 pick replacement is NOT wired in—it exists only as commented-out code.
The @Inject for pick(F)V in common/src/main/java/com/jsmacrosce/jsmacros/client/mixin/access/MixinMinecraftClient.java (lines 126–131) is commented out within the >=26.1 block. This means script-side raycast and interaction target overrides will silently no-op on 26.1. Either uncomment and activate the >=26.1 replacement, or provide an alternative implementation for Minecraft >=26.1.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@fabric/src/main/java/com/jsmacrosce/jsmacros/fabric/client/mixins/access/MixinGameRenderer.java`
around lines 56 - 63, The >=26.1 injection for pick is currently commented out
so InteractionProxy.Target.onUpdate never runs on 26.1+; locate the commented
`@Inject` block in MixinMinecraftClient that was intended to replace pick(F)V (the
stub around the method that mirrors MixinGameRenderer.onTargetUpdate) and either
uncomment and restore the injection so it calls
InteractionProxy.Target.onUpdate(float) and cancels via CallbackInfo when true,
or implement an equivalent hook for the new 26.1+ method signature (ensuring the
injected method name and signature match Minecraft's current pick method and
still calls InteractionProxy.Target.onUpdate and ci.cancel()). Ensure the
injection annotation, method name and parameters match the runtime target so the
override actually executes.
| // see https://fabricmc.net/develop/ for new versions. | ||
| // fabric-loom is the legacy alias (LoomGradlePlugin, requires mappings) used for 1.21.x. | ||
| // net.fabricmc.fabric-loom is the non-obfuscated plugin (LoomNoRemapGradlePlugin, skips | ||
| // mappings) required for MC 26.1+ which ships deobfuscated. Both IDs resolve to the same | ||
| // plugin JAR. | ||
| id("fabric-loom") version "1.15.4" apply false | ||
| id("net.fabricmc.fabric-loom") version "1.15.4" apply false | ||
| // see https://projects.neoforged.net/neoforged/moddevgradle for new versions | ||
| id("net.neoforged.moddev") version "2.0.139" apply false | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the latest stable version of fabric-loom 1.15.x as of April 2026?
💡 Result:
The latest stable version of fabric-loom 1.15.x as of April 2026 is 1.15.5.
Citations:
- 1: https://gitlab.com/fabricmc/fabric-loom/-/tags
- 2: https://maven.fabricmc.net/net/fabricmc/fabric-loom/1.15.5/
- 3: https://github.com/fabricmc/fabric-loom
Update fabric-loom to version 1.15.5.
The dual plugin declaration (fabric-loom for legacy 1.21.x, net.fabricmc.fabric-loom for the deobfuscated 26.1+ path) correctly matches Fabric's official porting guidance for 26.1, and the inline comment captures the rationale precisely. However, the latest stable version in the 1.15.x line is 1.15.5, not 1.15.4. Update both plugin declarations to version "1.15.5".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@settings.gradle.kts` around lines 46 - 55, Update both fabric-loom plugin
declarations to use the latest 1.15.x release: change the version string on
id("fabric-loom") and id("net.fabricmc.fabric-loom") from "1.15.4" to "1.15.5"
so both plugin entries match the current stable 1.15.5 release.
d8fa56f to
fee53ba
Compare
grepsedawk
force-pushed
the
feat/mc-26.1
branch
from
fee53ba to
f5e6ca5
Compare
1 participant
What this PR does
Adds Minecraft 26.1.2 support to JsMacrosCE alongside the existing 1.21.5/8/10/11 targets, coordinated via stonecutter. All five Fabric jars build green; 26.1 launches clean in Fabulously Optimized and connects through to civmc.net.
The 26.1 port is a real overhaul — MC 26.1 ships deobfuscated (Mojang stopped publishing
client_mappingsfrom 26.x onward), split the GUI render pipeline into CPU extract + GPU render phases, and renamed a long tail of core classes (GuiGraphics→GuiGraphicsExtractor,ClickType→ContainerInput,LightTexture→Brightness/LightCoordsUtil,ItemRenderer→ItemStackRenderState+ItemModelResolver, etc). 112 files changed, ~1640 insertions, nearly all behind//? if >=26.1 {stonecutter gates.Commit message has the full breakdown of source-level adaptations, mixin retargeting, dedup helpers, justified gaps, and deferred follow-ups.
Disclosure — Claude Opus 4.7 helped
Most of the mechanical rewrite surface here was produced with Claude Opus 4.7 (1M context): the per-file API-rename sweeps, mixin target rediscovery when MC 26.1 moved a hook (e.g.
Screen.render→extractGui/extractRenderStateWithTooltipAndSubtitles,handleSystemMessage→handleOverlay), stonecutter gate construction across ~60 common files + ~30 mixins + fabric build/settings plumbing, and a multi-pass/simplifyreview that landed the dedup wins in this branch (SlotClickEventHelper, gradle version-list extraction viagradle.extra,LOGGER.erroroverprintStackTrace, NeoForge dead-config cleanup). Architectural decisions (keeping 1.21.x, skipping NeoForge 26.1 for a follow-up, stubbing a few 26.1-removed APIs with rationale) were mine; the typing was mostly Claude.Calling this out because the diff size reflects that amplification — a human wouldn't have produced it in this shape without LLM help, and I'd rather be upfront than have it feel surprising during review.
Could be a lot cleaner if we drop 1.21.*
Roughly ~40% of the diff is stonecutter gates keeping the <26.1 versions building. Things like render-element collector-param forks, ClickType↔ContainerInput dispatch, LightTexture↔LightCoordsUtil splits, drift between
GuiGraphics/GuiGraphicsExtractoracross dozens of call sites — all of that evaporates if the branch targets 26.1 only. TheSubmitNodeCollectorconsolidation called out in the deferred follow-ups (unified default method onRenderElement3D) becomes much more tractable once you don't have to bridge the 5→6-arg render signature across two eras.Suggested strategy: land this as-is so 26.1 users aren't blocked, keep 1.21.x alive for a few releases so existing script users have runway, then drop the pre-26.1 branches in a follow-up. That follow-up becomes a 500-line cleanup PR instead of a 1500-line port, and the codebase gets much easier to reason about.
I also like the idea of just cutting hard to 26.1 and having 1.21.x users stay on older versions of JSMacros if that is feasible.
Related
Test plan
./gradlew :fabric:1.21.5:jar :fabric:1.21.8:jar :fabric:1.21.10:jar :fabric:1.21.11:jar :fabric:26.1.2:jar— all green