Jump to content

  • Curse Sites
Become a Premium Member! Help
Latest News Article

[1.6.2] Minecraft Forge Modding #8 - Configuration File and Mod Distribution

forge eclipse minecraft modding 1.6.2 tutorial mod distribution configuration guide

  • Please log in to reply
18 replies to this topic

#1

MrrGingerNinja
  • Location: United Kingdom
  • Minecraft: MrrGingerNinja1

Posted 24 July 2013 - 10:06 AM

[1.6.2] Minecraft Forge Modding #8 - Configuration File and Mod Distribution


Hey, guys, and welcome to Tutorial #8 of my Minecraft Forge modding series. In the last tutorial, I showed you how to make an omni-tool with the functionality of the four existing in-game tools.

In this tutorial, I am going to show you how to set up a Configuration file which will handle all our IDs, which will allow users of our mod to alter the IDs should we/they run into any ID conflicts with other mods. I will also be explaining to you how to package your mod into a distributable file, which can be run inside of the Minecraft client.

The first thing we are going to want to do is head into our Ids class file. There are currently three integers in this class; tutItem, tutTool and tutBlock. We are going to need to delete all three of these and start again. Each item is now going to have two integers related to it; a default value and an actual value. To do this, we need to make, obviously, two integers per ID:
package tutorial.lib;

public class Ids {
public static int tutItem_actual;
public static final int tutItem_default = 16000;
public static int tutTool_actual;
public static final int tutTool_default = 16001;
public static int tutBlock_actual;
public static final int tutBlock_default = 3000;
}

We will now get errors inside of our Items and Blocks class files. This is fine; we simply need to change their values ("tutBlock" needs to be renamed "tutBlock_actual" in the Blocks class and "tutItem" and "tutTool" need to be renamed "tutItem_actual" and "tutTool_actual" in the Items class).

Our Blocks class should now look like this:
package tutorial.blocks;

import cpw.mods.fml.common.registry.GameRegistry;
import cpw.mods.fml.common.registry.LanguageRegistry;
import net.minecraft.block.Block;
import tutorial.lib.Ids;
import tutorial.lib.Names;

public class Blocks {
public static Block block;

public static void init() {
block = new TutBlock(Ids.tutBlock_actual);
GameRegistry.registerBlock(block, Names.tutBlock_name);
}

public static void addNames() {
LanguageRegistry.addName(block, Names.tutBlock_name);
}
}

And our Items class should look like this:
package tutorial.items;

import net.minecraft.item.EnumToolMaterial;
import net.minecraft.item.Item;
import net.minecraftforge.common.MinecraftForge;
import tutorial.lib.Ids;
import tutorial.lib.Names;
import cpw.mods.fml.common.registry.LanguageRegistry;

public class Items {
public static Item item;
public static Item tool;

public static void init() {
item = new TutItem(Ids.tutItem_actual);
tool = new TutTool(Ids.tutTool_actual, EnumToolMaterial.EMERALD);
}

public static void addNames() {
LanguageRegistry.addName(item, Names.tutItem_name);
LanguageRegistry.addName(tool, Names.tutTool_name);
}
}

However, if we try to run the client now, we will get a crash because all three IDs are trying to use the same value. Why is this? Well, because we have not linked the actual value with the default value.

To do this, we are going to need to create a new class, which I am going to put inside my lib package, called "ConfigHandler". We are going to use our config handler to create a new ".cfg" file, which the mod user can use to alter the IDs of the blocks/items in your mod.

To do this, our init constructor inside of the ConfigHandler class is going to have to have a condition; a file:
package tutorial.lib;

import java.io.File;

public class ConfigHandler {
public static void init(File configFile) {

}
}

We are then going to have to call upon an existing class called "Configuration" which we are going to use to save and load any edited IDs (or initial IDs upon first use):
package tutorial.lib;

import java.io.File;

import net.minecraftforge.common.Configuration;

public class ConfigHandler {
public static void init(File configFile) {
Configuration config = new Configuration(configFile);
}
}

We can now use our "config" parameter to save and load the IDs:
config.load();

config.save();

This means that our ConfigHandler class should currently look like this:
package tutorial.lib;

import java.io.File;

import net.minecraftforge.common.Configuration;

public class ConfigHandler {
public static void init(File configFile) {
Configuration config = new Configuration(configFile);

config.load();

config.save();
}
}

Obviously, our ConfigHandler class is not registering any IDs yet, but it also will not be loaded as we have not added it to our main mod class (Tutorial). To do this, go to the Tutorial class file and, inside of the preInit constructor, we need to load the ConfigHandler:
@EventHandler
public static void preInit ( FMLPreInitializationEvent event ) {
ConfigHandler.init(event.getSuggestedConfigurationFile());
}

We are now calling our ConfigHandler class inside of our preInit constructor. When it creates our config file, it will create it as the "suggested configuration file", which means it can be found inside the "config" folder of your .minecraft (or inside the "jars" folder inside the "mcp" folder in the case of running it in Eclipse) and will be called "<ModInfo.ID>.cfg".

Now we can register our IDs with our ConfigHandler. All of the IDs that we want to register need to be put between the "config.load()" and "config.save()" methods. We can also load Strings and booleans inside of our ConfigHandler, but we are only interested in IDs since this is all we have created.

First, we are going to register our tutBlock's ID:
Ids.tutBlock_actual = config.getBlock(Names.tutBlock_name, Ids.tutBlock_default).getInt();

What the code is doing is getting an integer that connects the tutBlock_actual with another value (in this case, tutBlock_default). When you open the config file (after you have run the mod), you will see a line that will say:
I:"Tutorial Block"=3000

This means that the user can now alter the ID and avoid any ID conflicts with other mods. We are going to do a similar thing with the IDs for tutItem and tutTool:
Ids.tutItem_actual = config.getItem(Names.tutItem_name, Ids.tutItem_default).getInt() - 256;
Ids.tutTool_actual = config.getItem(Names.tutTool_name, Ids.tutTool_default).getInt() - 256;

The only difference between registering block IDs and item IDs is that item IDs are shifted by +256 (so, if you tell it an ID of 10000, it will actually use an ID of 10256). I'm not entirely sure why it does this, but it is a vanilla feature so cannot be stopped. To get around the problem, we simply reduce the integer that the ConfigHandler finds by 256 so that the ID we tell it is the ID that it uses.

Our finished ConfigHandler should now look like this:
package tutorial.lib;

import java.io.File;

import net.minecraftforge.common.Configuration;

public class ConfigHandler {
public static void init(File configFile) {
Configuration config = new Configuration(configFile);

config.load();

Ids.tutBlock_actual = config.getBlock(Names.tutBlock_name, Ids.tutBlock_default).getInt();

Ids.tutItem_actual = config.getItem(Names.tutItem_name, Ids.tutItem_default).getInt() - 256;
Ids.tutTool_actual = config.getItem(Names.tutTool_name, Ids.tutTool_default).getInt() - 256;

config.save();
}
}

If you now run the client, the game will run normally and you can find the configuration file in "mcp/jars/config".

The final thing that I am going to show you how to do in this tutorial is package your mod for release to the general public. For this, we are going to need to leave the Eclipse workspace (you do not need to close Eclipse) and head on over to the "mcp" folder.

Inside of the "mcp" folder, there are a variety of Windows Batch Files and SH Files. Windows users should, obviously, use the Batch Files, whereas Mac users should use the SH Files.

The first file we are going to want to run is called "recompile". This will, as the name suggests, recompile the source code (which are .java file) into .class
files.

This will take a few moments to run and recompile the code. Ignore the warning that says "!! Can not find server sources, try decompiling !!" and close the window.


Once the code has been recompiled, we will then need to run the file called "reobfuscate". The "reobfuscate" file will search through the newly recompiled Minecraft source code and identify any .class files that are new (i.e. not in the vanilla Minecraft source code). It will then extract these .class files and put them inside the folder called "reobf".

Once the "reobfuscate" file has completed, open the "reobf" folder inside the "mcp" folder. There will be another folder called "minecraft"; you should open this too. Inside of the "minecraft" folder, there will be a folder with the first part of our mod's package name (for example, "tutorial"). If you open the "tutorial" folder, you will find all of our packages and .class files.

Copy this "tutorial" folder to a separate location. We are going to need to add this folder to a .zip or .jar file. We then need to go back to our "mcp" folder and head into the "src" folder. Go into the "minecraft" folder and then copy the folder called "assets". The "assets" folder also needs to be added to the .zip/.jar file.

Your mod is now ready for public release. The user simply needs to drop the .zip/.jar file into their "mods" folder and they can use your mod.

End of Tutorial


This is the end of Minecraft Forge Modding #8 - Configuration File and Mod Distribution. In this tutorial, we have made a configuration file that allows mod users to change the IDs of our blocks and items if they encounter an ID conflict (or feel like changing the ID for fun). We have also packaged our mod into a .zip/.jar file ready for distribution to the Minecraft audience.

The next few tutorials are going to be utility-related (for example, adding an mcmod.info file and using a LogHelper to print messages to the console). This is because I am starting to begin writing some advanced tutorials using TileEntities, Containers and GUIs to create a custom chest and a custom furnace. Feel free to head on over to the "Advanced Tutorials" page of my website (link can be found here) to follow along with them; however, be warned, they are going to be long multi-part tutorials that will take a while for me to write and upload, so please be patient with them.

I hope this tutorial has been useful and, as always, I'll see you in the next one.

~MrrGingerNinja

View the previous tutorial (Tutorial #7 - Creating an Omni-Tool) here
View the next tutorial (Tutorial #9a - Utility Part 1: mcmod.info) here
Keep up to date with the latest Forge tutorials by visiting mgstudios.weebly.com/minecraft-modding
Follow me on Twitter - @MrrGingerNinja - and subscribe on YouTube (new account 26 Mar '14 :3)
Grateful for my work? Feel free to donate <3

Register or log in to remove.

#2

Mozzi3
    Mozzi3

    Tree Puncher

  • Curse Premium
  • Curse Premium
  • 30 posts
  • Minecraft: M0ZZ13

Posted 24 July 2013 - 02:09 PM

Loving the tutorials, keep it up. Could you possibly do a custom explosive, dimension and a mob tutorial in the future. If so that would be great help!

#3

Toxic_Herobrine

Posted 24 July 2013 - 09:08 PM

View PostMrrGingerNinja, on 24 July 2013 - 10:06 AM, said:

[1.6.2] Minecraft Forge Modding #8 - Configuration File and Mod Distribution


Hey, guys, and welcome to Tutorial #8 of my Minecraft Forge modding series. In the last tutorial, I showed you how to make an omni-tool with the functionality of the four existing in-game tools.

In this tutorial, I am going to show you how to set up a Configuration file which will handle all our IDs, which will allow users of our mod to alter the IDs should we/they run into any ID conflicts with other mods. I will also be explaining to you how to package your mod into a distributable file, which can be run inside of the Minecraft client.

The first thing we are going to want to do is head into our Ids class file. There are currently three integers in this class; tutItem, tutTool and tutBlock. We are going to need to delete all three of these and start again. Each item is now going to have two integers related to it; a default value and an actual value. To do this, we need to make, obviously, two integers per ID:
package tutorial.lib;

public class Ids {
public static int tutItem_actual;
public static final int tutItem_default = 16000;
public static int tutTool_actual;
public static final int tutTool_default = 16001;
public static int tutBlock_actual;
public static final int tutBlock_default = 3000;
}

We will now get errors inside of our Items and Blocks class files. This is fine; we simply need to change their values ("tutBlock" needs to be renamed "tutBlock_actual" in the Blocks class and "tutItem" and "tutTool" need to be renamed "tutItem_actual" and "tutTool_actual" in the Items class).

Our Blocks class should now look like this:
package tutorial.blocks;

import cpw.mods.fml.common.registry.GameRegistry;
import cpw.mods.fml.common.registry.LanguageRegistry;
import net.minecraft.block.Block;
import tutorial.lib.Ids;
import tutorial.lib.Names;

public class Blocks {
public static Block block;

public static void init() {
block = new TutBlock(Ids.tutBlock_actual);
GameRegistry.registerBlock(block, Names.tutBlock_name);
}

public static void addNames() {
LanguageRegistry.addName(block, Names.tutBlock_name);
}
}

And our Items class should look like this:
package tutorial.items;

import net.minecraft.item.EnumToolMaterial;
import net.minecraft.item.Item;
import net.minecraftforge.common.MinecraftForge;
import tutorial.lib.Ids;
import tutorial.lib.Names;
import cpw.mods.fml.common.registry.LanguageRegistry;

public class Items {
public static Item item;
public static Item tool;

public static void init() {
item = new TutItem(Ids.tutItem_actual);
tool = new TutTool(Ids.tutTool_actual, EnumToolMaterial.EMERALD);
}

public static void addNames() {
LanguageRegistry.addName(item, Names.tutItem_name);
LanguageRegistry.addName(tool, Names.tutTool_name);
}
}

However, if we try to run the client now, we will get a crash because all three IDs are trying to use the same value. Why is this? Well, because we have not linked the actual value with the default value.

To do this, we are going to need to create a new class, which I am going to put inside my lib package, called "ConfigHandler". We are going to use our config handler to create a new ".cfg" file, which the mod user can use to alter the IDs of the blocks/items in your mod.

To do this, our init constructor inside of the ConfigHandler class is going to have to have a condition; a file:
package tutorial.lib;

import java.io.File;

public class ConfigHandler {
public static void init(File configFile) {

}
}

We are then going to have to call upon an existing class called "Configuration" which we are going to use to save and load any edited IDs (or initial IDs upon first use):
package tutorial.lib;

import java.io.File;

import net.minecraftforge.common.Configuration;

public class ConfigHandler {
public static void init(File configFile) {
Configuration config = new Configuration(configFile);
}
}

We can now use our "config" parameter to save and load the IDs:
config.load();

config.save();

This means that our ConfigHandler class should currently look like this:
package tutorial.lib;

import java.io.File;

import net.minecraftforge.common.Configuration;

public class ConfigHandler {
public static void init(File configFile) {
Configuration config = new Configuration(configFile);

config.load();

config.save();
}
}

Obviously, our ConfigHandler class is not registering any IDs yet, but it also will not be loaded as we have not added it to our main mod class (Tutorial). To do this, go to the Tutorial class file and, inside of the preInit constructor, we need to load the ConfigHandler:
@EventHandler
public static void preInit ( FMLPreInitializationEvent event ) {
ConfigHandler.init(event.getSuggestedConfigurationFile());
}

We are now calling our ConfigHandler class inside of our preInit constructor. When it creates our config file, it will create it as the "suggested configuration file", which means it can be found inside the "config" folder of your .minecraft (or inside the "jars" folder inside the "mcp" folder in the case of running it in Eclipse) and will be called "<ModInfo.ID>.cfg".

Now we can register our IDs with our ConfigHandler. All of the IDs that we want to register need to be put between the "config.load()" and "config.save()" methods. We can also load Strings and booleans inside of our ConfigHandler, but we are only interested in IDs since this is all we have created.

First, we are going to register our tutBlock's ID:
Ids.tutBlock_actual = config.getBlock(Names.tutBlock_name, Ids.tutBlock_default).getInt();

What the code is doing is getting an integer that connects the tutBlock_actual with another value (in this case, tutBlock_default). When you open the config file (after you have run the mod), you will see a line that will say:
I:"Tutorial Block"=3000

This means that the user can now alter the ID and avoid any ID conflicts with other mods. We are going to do a similar thing with the IDs for tutItem and tutTool:
Ids.tutItem_actual = config.getItem(Names.tutItem_name, Ids.tutItem_default).getInt() - 256;
Ids.tutTool_actual = config.getItem(Names.tutTool_name, Ids.tutTool_default).getInt() - 256;

The only difference between registering block IDs and item IDs is that item IDs are shifted by +256 (so, if you tell it an ID of 10000, it will actually use an ID of 10256). I'm not entirely sure why it does this, but it is a vanilla feature so cannot be stopped. To get around the problem, we simply reduce the integer that the ConfigHandler finds by 256 so that the ID we tell it is the ID that it uses.

Our finished ConfigHandler should now look like this:
package tutorial.lib;

import java.io.File;

import net.minecraftforge.common.Configuration;

public class ConfigHandler {
public static void init(File configFile) {
Configuration config = new Configuration(configFile);

config.load();

Ids.tutBlock_actual = config.getBlock(Names.tutBlock_name, Ids.tutBlock_default).getInt();

Ids.tutItem_actual = config.getItem(Names.tutItem_name, Ids.tutItem_default).getInt() - 256;
Ids.tutTool_actual = config.getItem(Names.tutTool_name, Ids.tutTool_default).getInt() - 256;

config.save();
}
}

If you now run the client, the game will run normally and you can find the configuration file in "mcp/jars/config".

The final thing that I am going to show you how to do in this tutorial is package your mod for release to the general public. For this, we are going to need to leave the Eclipse workspace (you do not need to close Eclipse) and head on over to the "mcp" folder.

Inside of the "mcp" folder, there are a variety of Windows Batch Files and SH Files. Windows users should, obviously, use the Batch Files, whereas Mac users should use the SH Files.

The first file we are going to want to run is called "recompile". This will, as the name suggests, recompile the source code (which are .java file) into .class
files.

This will take a few moments to run and recompile the code. Ignore the warning that says "!! Can not find server sources, try decompiling !!" and close the window.


Once the code has been recompiled, we will then need to run the file called "reobfuscate". The "reobfuscate" file will search through the newly recompiled Minecraft source code and identify any .class files that are new (i.e. not in the vanilla Minecraft source code). It will then extract these .class files and put them inside the folder called "reobf".

Once the "reobfuscate" file has completed, open the "reobf" folder inside the "mcp" folder. There will be another folder called "minecraft"; you should open this too. Inside of the "minecraft" folder, there will be a folder with the first part of our mod's package name (for example, "tutorial"). If you open the "tutorial" folder, you will find all of our packages and .class files.

Copy this "tutorial" folder to a separate location. We are going to need to add this folder to a .zip or .jar file. We then need to go back to our "mcp" folder and head into the "src" folder. Go into the "minecraft" folder and then copy the folder called "assets". The "assets" folder also needs to be added to the .zip/.jar file.

Your mod is now ready for public release. The user simply needs to drop the .zip/.jar file into their "mods" folder and they can use your mod.

End of Tutorial


This is the end of Minecraft Forge Modding #8 - Configuration File and Mod Distribution. In this tutorial, we have made a configuration file that allows mod users to change the IDs of our blocks and items if they encounter an ID conflict (or feel like changing the ID for fun). We have also packaged our mod into a .zip/.jar file ready for distribution to the Minecraft audience.

The next few tutorials are going to be utility-related (for example, adding an mcmod.info file and using a LogHelper to print messages to the console). This is because I am starting to begin writing some advanced tutorials using TileEntities, Containers and GUIs to create a custom chest and a custom furnace. Feel free to head on over to the "Advanced Tutorials" page of my website (link can be found here) to follow along with them; however, be warned, they are going to be long multi-part tutorials that will take a while for me to write and upload, so please be patient with them.

I hope this tutorial has been useful and, as always, I'll see you in the next one.

~MrrGingerNinja

View the previous tutorial (Tutorial #7 - Creating an Omni-Tool) here
View the next tutorial (Tutorial #9a - Utility Part 1: mcmod.info) here

Hello When I Install a Mod Where Do I Put The Asset's Folder? For Sound

#4

ArtaxiasTheWise
  • Minecraft: ArtaxiasTheWise

Posted 24 July 2013 - 10:52 PM

View PostMozzi3, on 24 July 2013 - 02:09 PM, said:

Loving the tutorials, keep it up. Could you possibly do a custom explosive, dimension and a mob tutorial in the future. If so that would be great help!

I don't need to learn about custom explosives and dimensions right now, but perhaps others do so that might be a good idea. However, a tutorial on mobs would be great and incredibly helpful, and perhaps briefly go over making a water mob if their coding differs. I hope a mob tutorial is coming up, thanks for all the ones you have posted!
Posted Image

#5

MrrGingerNinja
  • Location: United Kingdom
  • Minecraft: MrrGingerNinja1

Posted 25 July 2013 - 07:15 AM

View PostToxic_Herobrine, on 24 July 2013 - 09:08 PM, said:

Hello When I Install a Mod Where Do I Put The Asset's Folder? For Sound

1) Did you really need to quote the entire OP?
2) If you're doing this for modding, go to the "src" folder in "mcp", then into "minecraft". Make the "assets" folder and, inside this, make the <ModInfo.ID.toLowerCase()> folder (e.g. "tutorial"). Inside this, we have the "textures" folder. If you want to load sounds, make a new folder called "sound".
Keep up to date with the latest Forge tutorials by visiting mgstudios.weebly.com/minecraft-modding
Follow me on Twitter - @MrrGingerNinja - and subscribe on YouTube (new account 26 Mar '14 :3)
Grateful for my work? Feel free to donate <3

#6

Sinhika
    Sinhika

    Zombie Killer

  • Members
  • 179 posts

Posted 25 July 2013 - 02:56 PM

*facepalm* Why do you unshift the shifted item IDs?  That is a bad idea. Since not everyone does that, users cannot now guarantee that they will be free of slot conflicts by making sure all the different mod configs use different item & block ID numbers.

I suspect that Minecraft upshifts the item ID numbers so that there is no possibility of an item ID interfering with terrain generation blocks & vanilla items (0-255).  (Or it is an artifact of when everything was in one array and blocks were the ones with IDs of 255 or less...)

#7

MrrGingerNinja
  • Location: United Kingdom
  • Minecraft: MrrGingerNinja1

Posted 25 July 2013 - 04:12 PM

View PostSinhika, on 25 July 2013 - 02:56 PM, said:

*facepalm* Why do you unshift the shifted item IDs?  That is a bad idea. Since not everyone does that, users cannot now guarantee that they will be free of slot conflicts by making sure all the different mod configs use different item & block ID numbers.

I suspect that Minecraft upshifts the item ID numbers so that there is no possibility of an item ID interfering with terrain generation blocks & vanilla items (0-255).  (Or it is an artifact of when everything was in one array and blocks were the ones with IDs of 255 or less...)

I'm afraid it depends on the coder. Some modders do unshift the item IDs, whereas other modders don't. You don't have to unshift the IDs but if your user runs the mod, gets a conflict with it at say, slot 1256, they then won't be able to find the conflicting ID because they won't realise it has been shifted up (meaning they are actually looking for ID 1000).
Keep up to date with the latest Forge tutorials by visiting mgstudios.weebly.com/minecraft-modding
Follow me on Twitter - @MrrGingerNinja - and subscribe on YouTube (new account 26 Mar '14 :3)
Grateful for my work? Feel free to donate <3

#8

Sinhika
    Sinhika

    Zombie Killer

  • Members
  • 179 posts

Posted 25 July 2013 - 09:26 PM

View PostMrrGingerNinja, on 25 July 2013 - 04:12 PM, said:

I'm afraid it depends on the coder. Some modders do unshift the item IDs, whereas other modders don't. You don't have to unshift the IDs but if your user runs the mod, gets a conflict with it at say, slot 1256, they then won't be able to find the conflicting ID because they won't realise it has been shifted up (meaning they are actually looking for ID 1000).

Problem: the logging code in Minecraft unshifts the id when it writes a conflict message to the console / logfile. So you're double-unshifting it. Here's the relevant code, the Item constructor:

public Item(int par1)
	{
		this.itemID = 256 + par1;
		if (itemsList[256 + par1] != null)
		{
			System.out.println("CONFLICT @ " + par1 + " item slot already occupied by " + itemsList[256 + par1] + " while adding " + this);
		}
		itemsList[256 + par1] = this;
		GameData.newItemAdded(this);
	}

Note the log message uses the original, unshifted value.

#9

ntzrmtthihu777
  • Location: ザ・ワイヤード
  • Minecraft: The_NetZ
  • Xbox:Screw microsoft
  • PSN:Broke

Posted 26 July 2013 - 06:37 AM

Very nice tutorial, twill be useful distributing my mod when finished. Do you think you could do a tutorial on how to make a cfg file that enables/disables various parts of the mod?

Phuck_Yu_Too, on 09 July 2013 - 09:16 PM, said:

You managed to decompile and continue without me giving source code? O_O Bro, you are a god. Of course do whatever the phuck you want!!!! Good luck on it :D
CreepyPastaCraft | SecureCraftProtect

#10

ChuckSaidMine

Posted 28 July 2013 - 12:56 PM

Thank you GingerNinja!

I tried many different tutorials but none with results. Untill yours.
I was able to make my own mod with a lot of new blocks and recipes. (Adding more than 1 recipe was hard dough :)
After a few days I'm learning a lot about java coding. Thanks, again.

#11

SackCastellon
  • Location: Castellón, Spain
  • Minecraft: SackCastellon
  • PSN:SackCastellon

Posted 28 July 2013 - 05:23 PM

I've followed all the steps in your tutorial but when run Minecraft the item a created don't have the ID i assigned to him, and the Console shows:

2013-07-28 18:57:33 [INFO] [ForgeModLoader] Registering Forge Packet Handler
2013-07-28 18:57:33 [INFO] [ForgeModLoader] Succeeded registering Forge Packet Handler
2013-07-28 18:57:33 [INFO] [ForgeModLoader] Configured a dormant chunk cache size of 0
2013-07-28 18:57:33 [INFO] [STDOUT] CONFLICT @ 0 item slot already occupied by net.minecraft.item.ItemSpade@6089e94a while adding SackCastellon.craftablehorsearmor.common.item.ItemKnot@7e332ac9
2013-07-28 18:57:33 [INFO] [fml.ItemTracker] The mod SKC-CraftableHorseArmor is overwriting existing item at 256 (net.minecraft.item.ItemSpade from Minecraft) with SackCastellon.craftablehorsearmor.common.item.ItemKnot

And this is all i've Written...

Main class

@EventHandler
public void preInit(FMLPreInitializationEvent event) {

Items.init();

ConfigHandler.init(event.getSuggestedConfigurationFile());
}

@EventHandler
public void load(FMLInitializationEvent event) {
proxy.registerRenderers();
		
Items.addNames();

Recipes.init();
}


IDs class

package SackCastellon.craftablehorsearmor.lib;
public class IDs {

public static int Knot_actualID;
public static final int Knot_defaultID = 4000;
}


ConfigHandler class

package SackCastellon.craftablehorsearmor.lib;
import java.io.File;
import SackCastellon.craftablehorsearmor.common.item.ItemKnot;
import net.minecraftforge.common.Configuration;
public class ConfigHandler {

public static void init(File configFile) {
Configuration config = new Configuration(configFile);

config.load();

IDs.Knot_actualID = config.getItem(Names.Item_Knot_name, IDs.Knot_defaultID, "Test2").getInt() - 256;

config.save();

}
}


Names class

package SackCastellon.craftablehorsearmor.lib;
public class Names {

public static final String Item_Knot_unlocalizedName = "Knot";
public static final String Item_Knot_name = "Knot";
}


Items class

package SackCastellon.craftablehorsearmor.common.item;
import cpw.mods.fml.common.registry.LanguageRegistry;
import SackCastellon.craftablehorsearmor.lib.IDs;
import SackCastellon.craftablehorsearmor.lib.Names;
import net.minecraft.item.Item;
public class Items {

public static Item Knot;
public static void init() {

Knot = new ItemKnot(IDs.Knot_actualID);
}
public static void addNames() {

LanguageRegistry.addName(Knot, Names.Item_Knot_name);



Can you tell me why happen this and how can i fix it, please?

Thanks

Check out all my Mods

SKC Core - Better Wood - Craftable Horse Armor - Hardcore Craftable Horse Armor - Camouflage Mod


Posted Image


#12

ChuckSaidMine

Posted 28 July 2013 - 06:01 PM

View PostChuckSaidMine, on 28 July 2013 - 12:56 PM, said:

Thank you GingerNinja!

I tried many different tutorials but none with results. Untill yours.
I was able to make my own mod with a lot of new blocks and recipes. (Adding more than 1 recipe was hard dough Posted Image
After a few days I'm learning a lot about java coding. Thanks, again.

Hey, as thankfull as I am :), still I have some tutorial requests.
- fences (or maybe a code for crafting fences with other blocks - other textures)
- doors
- glass

I've been googling and trying, but there aren't many 1.6.2 tutorials. Thanks
You're allready a hero!

Cheers

#13

Kwow
    Kwow

    Coal Miner

  • Members
  • 100 posts
  • Location: Australia
  • Minecraft: Kwow

Posted 01 August 2013 - 11:25 AM

Great tutorial! However, the custom IDs don't seem to work for me, and they just get set to zero (or 256 in the case of items). Here is my ID code:
package ausAnimals.lib;

public class IDs
{
public static int emuEgg_actual;
public static final int emuEgg_default = 16000;
public static int echidnaSpineBundle_actual;
public static final int echidnaSpineBundle_default = 16010;

public static final int emuEggBlock_default = 2000;
public static int emuEggBlock_actual;
public static final int echidnaSpineTrapBlock_default = 2001;
public static int echidnaSpineTrapBlock_actual;
}
and here is my ConfigHandler code:
package ausAnimals.lib;

import java.io.File;

import net.minecraftforge.common.Configuration;

public class ConfigHandler
{
public static void init(File configFile)
{
Configuration config = new Configuration(configFile);

config.load();

IDs.emuEggBlock_actual = config.getBlock(Names.emuEggBlock_name, IDs.emuEggBlock_default).getInt();
IDs.echidnaSpineTrapBlock_actual = config.getBlock(Names.echidnaSpineTrapBlock_name, IDs.echidnaSpineTrapBlock_default).getInt();

IDs.emuEgg_actual = config.getItem(Names.emuEgg_name, IDs.emuEgg_default).getInt() - 256;
IDs.echidnaSpineBundle_actual = config.getItem(Names.echidnaSpineBundle_name, IDs.echidnaSpineBundle_default).getInt() - 256;

config.save();
}
}
Do you know what I'm doing wrong?
Posted Image
(note: the Australian animals mod does not include any biome additions/changes.)

#14

MrrGingerNinja
  • Location: United Kingdom
  • Minecraft: MrrGingerNinja1

Posted 02 August 2013 - 05:01 PM

Sounds stupid but are you initializing the confighandler in your preInit method for your main mod file?

View PostSackCastellon, on 28 July 2013 - 05:23 PM, said:

I've followed all the steps in your tutorial but when run Minecraft the item a created don't have the ID i assigned to him, and the Console shows:

2013-07-28 18:57:33 [INFO] [ForgeModLoader] Registering Forge Packet Handler
2013-07-28 18:57:33 [INFO] [ForgeModLoader] Succeeded registering Forge Packet Handler
2013-07-28 18:57:33 [INFO] [ForgeModLoader] Configured a dormant chunk cache size of 0
2013-07-28 18:57:33 [INFO] [STDOUT] CONFLICT @ 0 item slot already occupied by net.minecraft.item.ItemSpade@6089e94a while adding SackCastellon.craftablehorsearmor.common.item.ItemKnot@7e332ac9
2013-07-28 18:57:33 [INFO] [fml.ItemTracker] The mod SKC-CraftableHorseArmor is overwriting existing item at 256 (net.minecraft.item.ItemSpade from Minecraft) with SackCastellon.craftablehorsearmor.common.item.ItemKnot

And this is all i've Written...

Main class

@EventHandler
public void preInit(FMLPreInitializationEvent event) {

Items.init();

ConfigHandler.init(event.getSuggestedConfigurationFile());
}

@EventHandler
public void load(FMLInitializationEvent event) {
proxy.registerRenderers();
		
Items.addNames();

Recipes.init();
}


IDs class

package SackCastellon.craftablehorsearmor.lib;
public class IDs {

public static int Knot_actualID;
public static final int Knot_defaultID = 4000;
}


ConfigHandler class

package SackCastellon.craftablehorsearmor.lib;
import java.io.File;
import SackCastellon.craftablehorsearmor.common.item.ItemKnot;
import net.minecraftforge.common.Configuration;
public class ConfigHandler {

public static void init(File configFile) {
Configuration config = new Configuration(configFile);

config.load();

IDs.Knot_actualID = config.getItem(Names.Item_Knot_name, IDs.Knot_defaultID, "Test2").getInt() - 256;

config.save();

}
}


Names class

package SackCastellon.craftablehorsearmor.lib;
public class Names {

public static final String Item_Knot_unlocalizedName = "Knot";
public static final String Item_Knot_name = "Knot";
}


Items class

package SackCastellon.craftablehorsearmor.common.item;
import cpw.mods.fml.common.registry.LanguageRegistry;
import SackCastellon.craftablehorsearmor.lib.IDs;
import SackCastellon.craftablehorsearmor.lib.Names;
import net.minecraft.item.Item;
public class Items {

public static Item Knot;
public static void init() {

Knot = new ItemKnot(IDs.Knot_actualID);
}
public static void addNames() {

LanguageRegistry.addName(Knot, Names.Item_Knot_name);



Can you tell me why happen this and how can i fix it, please?

Thanks

You've initialized your item ID before your config (in the preInit). Switch them round and this should fix the problem :)
Keep up to date with the latest Forge tutorials by visiting mgstudios.weebly.com/minecraft-modding
Follow me on Twitter - @MrrGingerNinja - and subscribe on YouTube (new account 26 Mar '14 :3)
Grateful for my work? Feel free to donate <3

#15

Kwow
    Kwow

    Coal Miner

  • Members
  • 100 posts
  • Location: Australia
  • Minecraft: Kwow

Posted 03 August 2013 - 12:39 AM

View PostMrrGingerNinja, on 02 August 2013 - 05:01 PM, said:

Sounds stupid but are you initializing the confighandler in your preInit method for your main mod file?



You've initialized your item ID before your config (in the preInit). Switch them round and this should fix the problem Posted Image
Yes, it seems as though I was...
I had no idea where exactly to put the confighandler init, so I just put it at the bottom, assuming it wouldn't make a difference. However, now that you mention it, it does seem stupid. :)

In any case, your suggestion worked, thankyou very much!
Posted Image
(note: the Australian animals mod does not include any biome additions/changes.)

#16

Ralyx
    Ralyx

    Out of the Water

  • Members
  • 2 posts

Posted 29 September 2013 - 03:12 AM

So far all of your tutorials have focused on extending the basic Minecraft functionality with new items or blocks, but I'm interested in what one would have to do differently to edit existing functionality - say, if you wanted to change something about the way swimming or hunger works.

#17

Eyenstein
  • Location: My computer...UK
  • Minecraft: Eyenstein

Posted 08 October 2013 - 06:17 PM

Whenever, I run Minecraft from Eclipse, it works. However, when I run it with Forge on Minecraft, it stops working. Why is this?

Spoiler: Click to see my error code


#18

GateArgon
  • Location: USA,Pennsylvania

Posted 16 March 2014 - 03:32 AM

Do you have a youtube channel? If not you should make one your tutorials would help alot of people out,but of course I mean just an idea I am not trying to push ya just saying I like this tutorial and those who are brand new and not used to interpreting text would love a video edition but of course I thank you enough at least for this I am trying to be polite just having a hard time because I am so new at the forums kinda thing
Posted Image
Posted Image

#19

thedoctor3141

Posted 08 April 2014 - 12:52 AM

View PostChuckSaidMine, on 28 July 2013 - 06:01 PM, said:

Hey, as thankfull as I am Posted Image, still I have some tutorial requests.
- fences (or maybe a code for crafting fences with other blocks - other textures)
- doors
- glass

I've been googling and trying, but there aren't many 1.6.2 tutorials. Thanks
You're allready a hero!

Cheers
If you want to make your own custom fence, just do "extends BlockFence" instead of "extends Block" then if you want to make your own gate, then do "extends BlockFenceGate" If you want to have your fence connect to your gate, then go into the BlockFence.java, copy the "canconnectto" method, ot something like that, paste it into your fence class, and change the "Block.woodenFenceGate" to your own fencename, in my case "vanillaoverhaul.spruceGate" Sorry I didn't paste the code here, just too lazy.