Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Fix for Minecraft client seeing changes to mcmod.info file when started from IDE

Cosmic Cleric

Recommended Posts

I tried fixing this issue via a pull request, but it was denied, so figured I would at least make a post about the fix, so each of you could implement it locally.


In a nutshell, if you follow these instructions, it tells you to create a mcmod.info file into the /resources folder.  However, when you run the Minecraft client from within the IDE, it will not pick up any changes that you do to the mcmod.info file, as it doesn't see the file at all at runtime.


If you modify your module's main build.gradle file, by adding the following lines to the end of the file (after the 'processResources' section), then you can run the client from within your IDE and it will see your changes to the mcmod.info file the next time you start the client up ...


task deleteMcmodInfoFile(type: Delete) {
    doLast {
        // We need to delete the duplicate mcmod.info file, which is
        // created when the Gradle task 'copyMcmodInfoFile' (see below)
        // executes, for when we run the client from inside of the
        // IDE, before the jar file is created, or else Gradle will
        // throw a ZipException ('duplicate entry: mcmod.info').
        // delete "$buildDir/classes/main/mcmod.info" <-- DOES NOT WORK!
task copyMcmodInfoFile() {
    doLast {
        // Copy the in-memory/modified mcmod.info file (see above Gradle
        // task 'processResources') into the root folder that the
        // net.minecraftforge.fml.common.discovery.DirectoryDiscoverer
        // class will search in, when running the client from the IDE.
        copy { // A 'type: Copy' task will not run its 'doLast' block!
            from("$buildDir/resources/main") {
                include 'mcmod.info'
            into "$buildDir/classes/main"
// Need to hook our before/after tasks up to the 'jar' task ...
jar.dependsOn deleteMcmodInfoFile
jar.finalizedBy copyMcmodInfoFile


I've only tested this with IntelliJ, but I use the Gradle $buildDir variable value, so it should work with Eclipse as well.


Happy New Year all!


Link to comment
Share on other sites

Just a follow up to my post (to clarify, based on some comments made in the pull request), all this fix does is the following ...


  • Copies mcmod.info into the $buildDir/classes/main directory, after the mod jar has been created.  This allows the Minecraft Client launched from the IDE to see the file.
  • Deletes the previously copied mcmod.info file in the $buildDir/classes/main directory, just before the jar file is created.  This is done to avoid the 'duplicate files in a jar' exception.

This fix does not modify the original mcmod.info file, in the $buildDir/resources/main directory in any way.

This fix does not affect what is put in the completed mod jar file in any way.


Its a simple copy of a single file, and a single deletion of the same previously copied single file, implemented via two Gradle tasks.


Edited by Cosmic Cleric
Link to comment
Share on other sites

You can also just go to Build > Clean / Recompile Project IIRC

About Me


My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Link to comment
Share on other sites

On 1/4/2019 at 2:09 AM, Cadiboo said:

You can also just go to Build > Clean / Recompile Project IIRC

No, that won't copy the file over to the specific location that the forge loader is looking at.  That'll copy the file over for the jaring process, which is a different directory under the 'build' parent directory.


This fix is just so that you can see inside of the Minecraft mods screen the settings you put into mcmod.info, when running Minecraft from within the IDE.  Without my fix, the information will still appear correctly from the Minecraft mods screen, when you run it from outside of the IDE, and had previously moved your built jar file into the 'mods' subdir under the '.minecraft' dir.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • Minecraft Version: 1.16.5 Forge Version: 36.2.0 Description of issue: A loaded mod containing data pack tag registries, which creates new tags and references the new tags to further register the items in existing tags fails to register anything in the existing tags. Example: Tinkers Construct v3.1.2.265 contains Json files to register: forge:ingots/cobalt as a new tag containing cobalt_ingot and add to previously registered tag forge:ingots. In the file for forge:ingots, values of "tconstruct:seared_brick", "tconstruct:scorched_brick", "#forge:ingots/copper", "#forge:ingots/cobalt", etc. are indicated. In-game, none of the items listed as values are tagged under forge:ingots, however the new tags including forge:ingots/cobalt include the items tagged in those files. Further, copying the json file for forge:ingots and placing in a later applied datapack, such as Kubejs, and reloading, properly registers the forge:ingots tags. This would appear to be an issue with timing of registering the new tags. Before copying the json file to a datapack, the existing tag (forge:ingots) appears to be handled first, which containing references to new tags that are not yet processed (forge:ingots/cobalt) fails and does not register any of the appended values. But in the second instance because the copied json file is processed after the mod jar file as a whole, the new tags exist and the appending of the new values succeeds. While I have given Tinkers construct as an example I have viewed the same issue with multiple mods, each of which uses references to new tags in an appending of an existing tag. Likewise, mods that do not exhibit this behavior use explicit item listings rather than referencing a new tag. I looked through the log files and did not identify any error or other message relating to the registration of tags in general or specifically these exemplar tags.
    • Debug.log here: https://gist.github.com/DexTGS/4f33065cbe2ad844b76ed1b1890fd069 . Game crashing once I die.
    • I'm making a mob like zombified piglin except instead of all the mobs getting mad at you I want to make it do they all go into a panic. How can I do this?
    • What. Just register your events in your mod constructor or use the class annotation.
    • How could I bake obj models without wrapping them in blocks or items? I'm guessing I have to use ModelBakeEvent and ModelRegistryEvent, but I'd appreciate a little more clarification.
  • Topics

  • Who's Online (See full list)

  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.