I'm looking for some tutorial on how to use this

 

  "version": "${version}",

  "mcversion": "${mcversion}",

 

on the mcmod.info files. I always see this come already with the placeholder mod created when installing forge, but actually never knew how to use it.

 

Thanks a lot.

Your build.gradle file comes with a script by default that will automatically replace these placeholders with the version you set for the mod and the version of Minecraft it is for.

Your build.gradle file comes with a script by default that will automatically replace these placeholders with the version you set for the mod and the version of Minecraft it is for.

 

Ohhh so I change it only on the build.gradle and when I "build" the mod it will place it there for me? Nice, didn't know that was how it works...

 

Do I still need to change it by hand on my code itself, for example in Info.java or whatever we use?

 

public static final String VERSION = "1.8.9-0.0.1";

 

Or is there a way to set up everything so we only need to change it in 1 place?

Gradle has a replace method/option.

I use it for my mod versions, but I can't get at my code atm to provide an example.

Gradle has a replace method/option.

I use it for my mod versions, but I can't get at my code atm to provide an example.

 

No worries man, but whenever you can that would be interesting I think it's a cool think to learn so we dont forget to change the version on any place, right now I got used to have to change it by hand 3 times in 3 different places, but knowing it can be automated makes me want to try that

You can take a look at my code here..

This is how my I have my build file setup:

http://chopapp.com/#twsikl32

 

The config file:

http://chopapp.com/#28z0zdke

 

The Main mod file:

http://chopapp.com/#rdakrkug

 

Feel free to comment on it or on my file on github here:

https://github.com/KaminoCoding/FriendNamer

I handle multiple sub-projects (core library + child mods) so here's how I've handled things.  It's litterally all in my gradle file, does a bit more than what you want, but here it is:

 

def releaseVersion  = "12"
def majorVersion    = "20"
def minorVersion    = "0"
//bugpatch or testing versions
def libVersion      = "a"
def oresVersion     = "c"
def hazardsVersion  = "a"
def wildlifeVersion = "a"
def industryVersion = "b"
def prePend = "1.7.10-"
def packageVersion  = releaseVersion+"."+majorVersion+"."+minorVersion+libVersion+oresVersion+hazardsVersion+wildlifeVersion+industryVersion

libVersion = releaseVersion+"."+majorVersion+"."+minorVersion+libVersion
oresVersion = releaseVersion+"."+majorVersion+"."+minorVersion+oresVersion
hazardsVersion = releaseVersion+"."+majorVersion+"."+minorVersion+hazardsVersion
wildlifeVersion = releaseVersion+"."+majorVersion+"."+minorVersion+wildlifeVersion
industryVersion = releaseVersion+"."+majorVersion+"."+minorVersion+industryVersion

version = ""
group= "com.draco18s.harderores" // http://maven.apache.org/guides/mini/guide-naming-conventions.html
archivesBaseName = "1.7.10-HardStuff"+packageVersion

minecraft {
    version = "1.7.10-10.13.2.1291"
    runDir = "eclipse"
    assetDir = "eclipse/assets"
    replace "{@version:lib}":libVersion,"{@version:ore}":oresVersion,"{@version:haz}":hazardsVersion,"{@version:wld}":wildlifeVersion,"{@version:ind}":industryVersion,"required-after:HardLib""required-after:HardLib@["+releaseVersion+"."+majorVersion+",]"),"/*{uncomment}":"","{uncomment}*/":""
}

 

The "replace" directive looks for each "search" string and replaces it with the string specified after the :

 

So"{@version:lib}":libVersion means "find '{@version:lib}' and replace it with (the value stored in the variable) libVersion.  Each is comma separated.  I've got a few extras that just version numbers, for instance, I have a "require-after" marker that inserts the core library version number required (which only uses the "a.b" portion of the "a.b.cx" version number) as well as chunks of code that I literally cannot run in dev (Intellisense says its OK, but the linked jars don't actually work in a deobf environment) so they're just commented out with a {uncomment} marker to enable them during the build process.

 

(If anyone cares, it was for Reika's API, which I actually don't use any more because he can't be arsed to make his API backwards compatible when he updates it and the bug reports come to me because it crashes with a "MethodNotFoundException").