mcmod.info not working right [1.12.2, latest]

[boredherobrine13]

Hi, I am using Forge 1.12.2 - 14.23.5.2807 (latest), and still get the issue with mcmod.info being "missing" despite the fact that the syntax seems correct, it is in the right folder (src/main/resources), and my modid is all lowercase. My build.gradle seems configured correctly as far as I can tell, and eclipse has been refreshed. I even tried deleting and re-inserting the file to see if that solved the issue, but it did not. I tried compiling the mod. The mcmod.info file was correct and inside the jar in the root of the archive, yet when I loaded the jar it still said the file was missing. Any ideas what could be causing this?

 

mcmod.info:

[
{
  "modid": "vinium",
  "name": "Vinium",
  "description": "It's aboutta get lit in here.",
  "version": "${version}",
  "mcversion": "${mcversion}",
  "url": "",
  "updateUrl": "",
  "authorList": ["Noah Martino"],
  "credits": "",
  "logoFile": "v-logo.png",
  "screenshots": [],
  "dependencies": []
}
]

Main.class:

package com.bored.vinum;

import net.minecraft.init.Blocks;
import net.minecraftforge.fml.common.Mod;
import net.minecraftforge.fml.common.Mod.EventHandler;
import net.minecraftforge.fml.common.SidedProxy;
import net.minecraftforge.fml.common.event.FMLInitializationEvent;
import net.minecraftforge.fml.common.event.FMLPostInitializationEvent;
import net.minecraftforge.fml.common.event.FMLPreInitializationEvent;
import org.apache.logging.log4j.Logger;

import com.bored.vinum.proxy.CommonProxy;
import com.bored.vinum.ui.VinumTab;

@Mod(modid = Vinum.modid, name = Vinum.name, version = Vinum.version, acceptedMinecraftVersions = "[1.12, 1.12.2]")
public class Vinum
{
    public static final String modid = "vinum";
    public static final String name = "Vinium";
    public static final String version = "0.0.1";
    
    @Mod.Instance(modid)
    public static Vinum instance;
    
    @SidedProxy(serverSide = "com.bored.vinum.proxy.CommonProxy", clientSide = "com.bored.vinum.proxy.ClientProxy")
    public static CommonProxy proxy;
    
    private static Logger logger;

    @EventHandler
    public void preInit(FMLPreInitializationEvent event)
    {
    	System.out.println(name + " " + version + " " + "is loading!");
        logger = event.getModLog();
    }

    @EventHandler
    public void init(FMLInitializationEvent event)
    {
        // some example code
        logger.info("DIRT BLOCK >> {}", Blocks.DIRT.getRegistryName());
    }
    
    @EventHandler
    public void postInit(FMLPostInitializationEvent event)
    {
    	
    }
    
    public static final VinumTab creativeTab = new VinumTab();
}

build.gradle:

buildscript {
    repositories {
        jcenter()
        maven { url = "https://files.minecraftforge.net/maven" }
    }
    dependencies {
        classpath 'net.minecraftforge.gradle:ForgeGradle:2.3-SNAPSHOT'
    }
}
apply plugin: 'net.minecraftforge.gradle.forge'
//Only edit below this line, the above code adds and enables the necessary things for Forge to be setup.


version = "0.0.1"
group = "com.bored.vinium" // http://maven.apache.org/guides/mini/guide-naming-conventions.html
archivesBaseName = "vinium"

sourceCompatibility = targetCompatibility = '1.8' // Need this here so eclipse task generates correctly.
compileJava {
    sourceCompatibility = targetCompatibility = '1.8'
}

minecraft {
    version = "1.12.2-14.23.5.2807"
    runDir = "run"
    
    // the mappings can be changed at any time, and must be in the following format.
    // snapshot_YYYYMMDD   snapshot are built nightly.
    // stable_#            stables are built at the discretion of the MCP team.
    // Use non-default mappings at your own risk. they may not always work.
    // simply re-run your setup task after changing the mappings to update your workspace.
    mappings = "snapshot_20171003"
    // makeObfSourceJar = false // an Srg named sources jar is made by default. uncomment this to disable.
}

dependencies {
    // you may put jars on which you depend on in ./libs
    // or you may define them like so..
    //compile "some.group:artifact:version:classifier"
    //compile "some.group:artifact:version"
      
    // real examples
    //compile 'com.mod-buildcraft:buildcraft:6.0.8:dev'  // adds buildcraft to the dev env
    //compile 'com.googlecode.efficient-java-matrix-library:ejml:0.24' // adds ejml to the dev env

    // the 'provided' configuration is for optional dependencies that exist at compile-time but might not at runtime.
    //provided 'com.mod-buildcraft:buildcraft:6.0.8:dev'

    // the deobf configurations:  'deobfCompile' and 'deobfProvided' are the same as the normal compile and provided,
    // except that these dependencies get remapped to your current MCP mappings
    //deobfCompile 'com.mod-buildcraft:buildcraft:6.0.8:dev'
    //deobfProvided 'com.mod-buildcraft:buildcraft:6.0.8:dev'

    // for more info...
    // http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html
    // http://www.gradle.org/docs/current/userguide/dependency_management.html

}

processResources {
    // this will ensure that this task is redone when the versions change.
    inputs.property "version", project.version
    inputs.property "mcversion", project.minecraft.version

    // replace stuff in mcmod.info, nothing else
    from(sourceSets.main.resources.srcDirs) {
        include 'mcmod.info'
                
        // replace version and mcversion
        expand 'version':project.version, 'mcversion':project.minecraft.version
    }
        
    // copy everything else except the mcmod.info
    from(sourceSets.main.resources.srcDirs) {
        exclude 'mcmod.info'
    }
}

 

[Legenes]

Is v-logo.png included in the mcmod.info's folder?

Edited January 18, 2019 by Legenes
Grammar

[Cadiboo]

25 minutes ago, boredherobrine13 said:

"[1.12, 1.12.2]")

This is not how version ranges work (they aren’t an array), see https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

 

Does your mod info work in a built copy of the mod? Is the mcmod.info inside the /bin/ folder generated by eclipse?

 

29 minutes ago, boredherobrine13 said:

group = "com.bored.vinium"

I highly doubt you own bored.com

[boredherobrine13]

8 minutes ago, Cadiboo said:

This is not how version ranges work (they aren’t an array), see https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

 

Does your mod info work in a built copy of the mod? Is the mcmod.info inside the /bin/ folder generated by eclipse?

 

I highly doubt you own bored.com

Erm, if i'm understanding this correctly, according to the link you sent me:

[1.0,2.0]

1.0 <= x <= 2.0

what I have would basically mean that it accepts 1.12.0 <= x <=1.12.2, which is my desired effect. The mod should work on forge 1.12.0, 1.12.1, and 1.12.2 (at least that's how my other mod works)

 

And no, the mcmod.info does not work in a built copy of the mod. It is also in the /bin/ folder (I extracted the built jar as well, mcmod.info is present in the root of the jar)

 

Lastly, no, I don't own "bored.com", but a lot of developers don't actually own their package names as far as I can tell from a quick hunt of really popular massive mods, so I think I'm in good enough company. Shrugs. Does forge own examplemod.com?

Edited January 18, 2019 by boredherobrine13

[boredherobrine13]

18 minutes ago, Legenes said:

Is v-logo.png included in the mcmod.info's folder?

Yes it is, but the issue I am having is not just the logo now showing up as expected. Nothing does

 

 

[Cadiboo]

7 minutes ago, boredherobrine13 said:

Does forge own examplemod.com?

No, they own minecraftforge.net, and their packaging and maven grouping reflect that. If you don’t own a website using the group & package mod.whatever (usually mod.yourName.modId) is acceptable

 

I use io.github.cadiboo.modid, but if I didn’t have a website I would use mod.cadiboo.modid

Edited January 18, 2019 by Cadiboo

[Cadiboo]

You appear to have some weird characters in your mcmod file (they might  have been added by the forums), 3 ones after “description and 1 at the end of the file

[boredherobrine13]

13 minutes ago, Cadiboo said:

No, they own minecraftforge.net, and their packaging and maven grouping reflect that. If you don’t own a website using the group & package mod.whatever (usually mod.yourName.modId) is acceptable

 

I use io.github.cadiboo.modid, but if I didn’t have a website I would use mod.cadiboo.modid

I'll change it in this and my other mods to reflect the proper conventions (I wasn't aware of them, I've never had a formal coding class yet. I'm self-taught).

10 minutes ago, Cadiboo said:

You appear to have some weird characters in your mcmod file (they might  have been added by the forums), 3 ones after “description and 1 at the end of the file

Unsure of what characters you are referring to. I suspect the forum may have added them. all I see is "description": "It's aboutta get lit in here.", I attached the actual file so you can double check. Couldn't find anything weird at the end. 

"description": "It's aboutta get lit in here.",

mcmod.info

 

Edit: Is it possible this has anything to do with that weird pack.mcmeta thing that I never touch because I'm rather unsure of what it does.

Edited January 18, 2019 by boredherobrine13

[Cadiboo]

5 minutes ago, boredherobrine13 said:

Edit: Is it possible this has anything to do with that weird pack.mcmeta thing that I never touch because I'm rather unsure of what it does.

I doubt it, AFAIK all pack.mcmeta deals with currently is .lang file naming

 

6 minutes ago, boredherobrine13 said:

Unsure of what characters you are referring to. I suspect the forum may have added them. all I see is "description": "It's aboutta get lit in here.", I attached the actual file so you can double check. Couldn't find anything weird at the end. 

Not by my computer so I can’t check the actual file, but copy/pasting what you put on the forums into json lint showed some invisible characters. Does using the default mcmod file fix the issue?

[boredherobrine13]

23 minutes ago, Cadiboo said:

I doubt it, AFAIK all pack.mcmeta deals with currently is .lang file naming

 

Not by my computer so I can’t check the actual file, but copy/pasting what you put on the forums into json lint showed some invisible characters. Does using the default mcmod file fix the issue? 

I just found it out. In one place I had set the modid to "Vinium". A small typo which eclipse didn't catch and I missed. I feel stupid now, but at least I learned I was naming my packages wrongly from all this.

Edited January 18, 2019 by boredherobrine13

[boredherobrine13]

23 minutes ago, Cadiboo said:

I doubt it, AFAIK all pack.mcmeta deals with currently is .lang file naming

 

Not by my computer so I can’t check the actual file, but copy/pasting what you put on the forums into json lint showed some invisible characters. Does using the default mcmod file fix the issue?

Don't suppose you'd know how to get color to work for lines in the mcmod.info file. It appears the § character doesn't work anymore, and neither does \u00A

[Cadiboo]

I would say look at the TextFormatting class, specifically the toString method and see how they are applied

[boredherobrine13]

12 minutes ago, Cadiboo said:

I would say look at the TextFormatting class, specifically the toString method and see how they are applied

Looks like § does the trick these days.

[boredherobrine13]

4 hours ago, diesieben07 said:

This sounds like your character encoding is borked. mcmod.info must be encoded in UTF-8.

Sure enough, eclipse was encoding it as "Cp1252", whatever that is. Fixed it and it went back to the normal  §  character.

[Cadiboo]

Everything should be UTF-8 or UTF-16 now, any other format is legacy and causes unnecessary problems