Add Fabric 26.1+ class templates (Mojmap) - #2639
Conversation
…ions in "NAME (1.21.11-).java.xyza", enchantment 26.1+ template is not changed yet for my information miss
…chantment.java.ft but both are not functionals in newer versions, also renamed FabricStatusEffect (26.1+).java.xyza to FabricMobEffect (26.1+).java.xyza for coherence
…on in FabricModule.kt
|
The mappings is good, but I think your AI might have hallucinated a bit on the enchantment stuff because enchantments are entirely data-driven (JSON) in 1.21+, so extending the Java class doesn't actually work anymore In file FabricEnchantment (26.1+).java.ft here: |
|
@TrygveK i know, i commented that doesn't work, but i don't remove that because its a feature made by others and i can't delete direcly without asking, (and i not used AI, i copied the neoforge template) |
Makes zero sense, last time I checked when GitHub says an + icon beside the file it meant YOU made it |
|
My apologies, you're right — that part of the PR description was an AI hallucination. I was aware the enchantment template doesn't work under 1.21+'s data-driven system; I left it as I found it and only translated it to Mojmap, without actually fixing the underlying issue. What I meant about "someone else's work" was different from how it sounded: even though I wrote that file, it's a Mojmap translation of an existing template, not something I designed from scratch — I wasn't trying to say I copied it from someone else's PR, and that file is the old file renamed Either way, I should have flagged this clearly instead of leaving it silently broken. Sorry for the confusion. (This response is ai translated in english, may contains allucinations) |
|
Translation tools don't usually hallucinate but anyway, since you agree that the file is broken for 1.21+, please just fix that Java template from this. And since you didn't probably actually test it then a bunch of things is probably broken |
|
ok, tomorrow i'll fix |
|
I just ran this branch locally in the sandbox to see what it generates, and it doesn't generate anything it completely crashes the IDE plugin when you click New > Minecraft Class . The FabricModule.computeVersion() method you added throws a NumberFormatException because it's trying to parse an empty string as an integer when checking the version: There is no way this was 'tested locally' like the PR description claimed. The version logic is fundamentally broken, and the Java enchantment template is dead for 1.21+ |
|
weird, i tested it and it works, can you describe exactly what you do to meet the exception? |
|
Run ./gradlew runIde to start the sandbox. Create a new Fabric project targeting Minecraft 26.2. Wait for the project's Gradle sync to finish completely. Right-click the main Java package (src/main/java/...). Click New > Minecraft Class. The IDE throws the NumberFormatException and the plugin crashes |
|
what's the depends -> minecraft value in fabric.mod.json |
|
It says "minecraft": "${minecraft_version}". Your computeVersion method is trying to parse the raw Gradle placeholder string instead of an actual version number. When it fails to find a number, it passes "" to the integer parser and crashes so the plugin needs to gracefully handle unresolved variables |
|
ok understood, tomorrow i'll fix |
|
after hardcoding the loader version and minecraft ver it generates and your AI even said "//Not functional for MC 1.20.3+" so like why you trying to put this into an modern Fabric 26.2 |
TrygveK
left a comment
There was a problem hiding this comment.
Tested this branch locally in the sandbox. Before this can be merged, several critical issues need to be addressed:
- Version Parsing Crash (NumberFormatException):
When generating on a standard project using Gradle variables ("minecraft": "${minecraft_version}"), the version parser fails to handle the placeholder and throws a fatal exception, completely crashing the IDE plugin:
java.lang.NumberFormatException: For input string: ""
at com.demonwav.mcdev.util.SemanticVersion$Companion.parse(SemanticVersion.kt:191)
at com.demonwav.mcdev.platform.fabric.FabricModule.computeVersion(FabricModule.kt:92)
The version logic needs to safely handle unresolved template variables instead of crashing.
-
Obsolete Template Logic:
Once the version is hardcoded to bypass the crash, the generated Java code explicitly confesses that it is broken: //Not functional for MC 1.20.3+. -
Modern Compatibility Errors:
Attempting to use this template on a modern Fabric project (like 26.2) fails immediately with compilation errors because enchantments are now data-driven JSON files rather than legacy Java classes:
Cannot resolve symbol 'EnchantmentCategory'
Cannot resolve symbol 'Rarity'
Cannot inherit from record 'net.minecraft.world.item.enchantment.Enchantment'
Cannot resolve symbol 'EnchantmentCategory'
Expected 4 arguments but found 3
Please fix the version parser to prevent the IDE crash, and update/replace the enchantment template so it actually aligns with modern 1.21+ data-driven systems instead of generating dead code.
… remove enchantment template in 1.21+
|
I think that i fix that, but i'm not sure because my hardware's limits cannot test me very well |
TrygveK
left a comment
There was a problem hiding this comment.
While the NumberFormatException crash is fixed, simply removing the Enchantment option for 1.21+ doesn't actually solve the core issue this PR was trying to address. Modern 1.21+ enchantments are now data-driven JSON files rather than Java classes and instead of disabling the feature, can you update the template to generate the correct JSON data structure for 1.21+ enchantments so the feature is actually supported in modern versions?
instead of unfunctional java classes with a new action for minecraft resources creation containing for now only enchantments templates (in a future pr i think that i'll expand it, changing from Minecraft Enchantment to Minecraft Json and adding blockstates, models, etc. templates)
| <add-to-group relative-to-action="EditorPopupMenu2" anchor="after" group-id="EditorPopupMenu"/> | ||
| </action> | ||
| <action class="com.demonwav.mcdev.insight.generation.MinecraftClassCreateAction" id="CreateMinecraftClass" | ||
| text="Minecraft Class" description="Create skeleton classes used in Minecraft Mods"> |
There was a problem hiding this comment.
I didn't copy that from ChatGPT, and the line you commented on wasn't something I modified in this PR — so I'm not sure what you'd like me to change there. Could you clarify which part you mean, why isn't necessary and what i supposed to do?
Also, just to explain the design: I kept Class creation and Json creation as two separate actions because isAvailable runs before the user picks a kind (Block/Item/Enchantment/etc.), so I can't conditionally show the Json action only when they're about to pick Enchantment. And merging them into one action would mean mixing Java source-root and resource-root logic under the same isAvailable, which felt wrong since they're fundamentally different targets. Happy to reconsider if you see a cleaner way to do this.
resource root's modid now detected scanning the path instead of choosing ever the first modid in project modids
|
ehm so? I can't see anymore the last changes comment |
| <add-to-group group-id="NewGroup" anchor="before" relative-to-action="NewFile"/> | ||
| </action> | ||
| <action class="com.demonwav.mcdev.insight.generation.MinecraftResourceCreateAction" id="CreateMinecraftJson" | ||
| text="Minecraft Class" description="Create skeleton jsons used in Minecraft Mods and datapacks"> |
There was a problem hiding this comment.
| text="Minecraft Class" description="Create skeleton jsons used in Minecraft Mods and datapacks"> | |
It's going to be confusing having it twice
There was a problem hiding this comment.
and what i have to do instead? they are different action inheritors from different classes, if you consider that a new class is wasted for a single use i already made an expansion to her in my other branch for another PR
There was a problem hiding this comment.
if the problem was the <text field, i done
|
This is for the old project creator, which will probably be removed soon anyway. The new one is what most people use, and I believe that's been fixed for 26.1+ already. |
|
this isn't for any project creator @Earthcomputer |
There was a problem hiding this comment.
You need to start co-operating with the reviewers, or else I will have to close the PR and let someone else pick it up. We've told you need to debug it yourself but you refused to do it.
Maybe it is true you didn't use AI, but either way this PR spends a lot of effort reimplementing something that we already have implemented better (Minecraft version detection), which is something that AI tends to do, hence the prior assumption. Regardless of the use of AI, this problem needs to be fixed as well as other irrelevant code changes.
|
i'm trying to collaborate with revievewrs, and my minecraft version detection change was done because original mcVersion in current MinecraftClassCreateAction resulted me null, so i supposed, it's was only for forge, also because that was only use of that variable. |
|
It shouldn't be null, if it is you should try to work out why. On Fabric it's assigned here so you should try to work out why that isn't being assigned properly for you. |
Remove unused fabricMinecraftVersion property.
|
Now it works without manual detection. Probably my machine was just slow to finish the Gradle sync, so the version wasn't populated in time for my earlier test. |
Earthcomputer
left a comment
There was a problem hiding this comment.
This is looking much better now, thank you for improving it. Can you remove the now unused imports that appeared as a result of removing some code?
And, can you remove the json enchantment template? It can always be added later if people want it, but ideally you generate enchantments using datagen rather than writing json files manually.
|
For the unused imports, I'll do it as soon as I can. As for removing the JSON enchantment template, I get the concern about a dedicated button for a niche feature, that's fair, and it's actually part of why I was planning a follow-up PR to expand this action with more templates and JSON structures, so it wouldn't stay a single-purpose button. That said, I want to be upfront that this specific part was added at TrygveK's explicit request, to replace the old pre-1.21 class-based generation I had removed, and I worked on it specifically for that purpose. Having it reverted now, from a different reviewer with the opposite request, is a bit frustrating. |
|
I get that it's frustrating, but that's just how it is sometimes. TrygveK is not a maintainer, they are just someone who decided to review the PR, and to be fair they did overall a good job. Reviews from maintainers should usually take precedence. |
|
so in short I have to throw away a day of work and my entire other branch? |
|
If something is going to take you an entire day to implement, it's good to check with the maintainers if it's something that is actually wanted, to avoid wasting time on something that isn't wanted. I'm sorry that you wasted time, but I can't be held responsible for someone else's review. |
|
ok, i'll remove it, can you tell me if in a separated pr that, with block, items, json structures and singular files like blockstates, and similar things can be conceptually accepted? |
|
These files should really be created with data generation, even for relatively small mods, so I'm inclined to say no. |
|
okok, also considering that data generation is not instantaneous to setup and that for small/medium sized mods it is not worth it? |
|
It's part of the mod generator on the Fabric site |
|
ok, i give up |
Earthcomputer
left a comment
There was a problem hiding this comment.
Still some unrelated formatting changes
| import net.minecraft.world.item.enchantment.Enchantment; | ||
| import net.minecraft.world.item.enchantment.EnchantmentCategory; | ||
|
|
||
| public class ${NAME} extends Enchantment { |
There was a problem hiding this comment.
Please don't delete this blank line
| generate.class.caption=Minecraft Class | ||
| generate.class.description=Class generation for modders | ||
|
|
||
|
|
| } | ||
|
|
||
| private class ClassInputValidator( | ||
| class ClassInputValidator( |
There was a problem hiding this comment.
Is there a reason anymore for this change?
There was a problem hiding this comment.
No, I probably didn't realize I had changed it.
|
Thanks for the approval and for your patience! Is anything else needed before the merge takes place, or is it just a matter of timing? |
|
I'm going to test it and then merge it |
|
ok |

Added new FreeMarker templates (.ft) for Fabric 26.1+, using Mojmap instead of Yarn, since recent Minecraft versions ship deobfuscated and Yarn mappings are no longer used. Registered them in MinecraftTemplates.kt.
Added FabricModule.computeVersion(), which reads the Minecraft version from depends.minecraft in fabric.mod.json (handles both the single-string and array forms allowed by the Fabric spec), since minecraftVersion from McpModuleType only applies to Forge. MinecraftClassCreateAction uses this to pick the correct Fabric templates based on the module's actual Minecraft version.
Tested locally on a Fabric 26.2 mod project — new templates are generated correctly.