ruabmbua

I think, I am a little bit late with this reply but thanks for the help. As of now I translated everything in my mod to the new UUID system. I hope this will help me to port my mod faster to 1.8.

Sorry I just found out, that 1.7.2 does not fully support name changes. This would be 1.7.9. It is kind of strange, but in my mod UUID is working (to check, if they match and so on). I will keep my code, and wait for the eventual forge update.

Currently I have a small issue with porting my mod to 1.7 and upwards. Because of the new login system I managed to change every use of the user name from the player to his persistent UUID. With use I mean that I reference a player somehow(mostly NBT) by its name. I did this because of the new name changes, that will get launched soon(first supported in 1.7.2). So now my issue: When I have my UUID stored in NBT, I want to read it, and then render the name of the user on the screen. I solved this, by writing a method which iterates over all connected players, and returns the matching player or null. So this is the problem. I only get the name of players, which are online. I do not want to store my own list in the savegame, because I think minecraft manages its own list in the save game. The question: How to access this list, if it actually exists? Please help.

Currently I have the same thoughts. Well I think you should take a look on the code of some open source mods. I think buildcraft is pretty up to date, and contains some kind of "energy" system. After I took a look on the code of some mods, I discovered Universal Electricity. This is a mod / API, which helps modders(like us), to not create a system on their own, but integrate their mods into the Universal Electricity API. This will make as example the electricity generated by one of your generators usable with a furnace from another mod. I hope this will help you.

If it´s possible, would please someone clarify me about the announced changes in the code of vanilla minecraft. The last big change for me was the networking code, and the change influenced the way, how forge(and fore mods) works. So can you say, that the coming changes(the rewrite) in the minecraft UI system will make my experience in coding a GUI / a container better? I absolutely HATED the way, how you code a GUI in a forge mod for now. I am clear about that, if mojang makes a major change in their game, you guys have to adopt it, but I do not know how big the "UI rewrite" will be, and if this changes will influence the actual forge UI "API".

In the build.gradle file I can define some things about my mod(id, version...). I watched the code in the gradle file, and found out it is trying to replace ${version} in my mcmod.info file. I thought, if I change back the version in my mcmod.info file to ${version}, than gradle will place the correct version informations into it. I was right, but then I encountered a problem: Gradle replaces the major and minor version numbers, but places always a zero to the build number. What do I do wrong, or is this behaviour expected?

Of course I know, that the new *.exe installer is just a wrapper for the jar installer file. The only thing I mean was following. The new download link(installer-win) did not work for 4 persons I know, because of various antivirus/malware softwares. They came not on the idea, to download the jar installer, because they thought installer-win is the right selection. They failed installing forge, and so had to call me. So I think the *.exe wrapper did not make the forge installation process more user friendly, but caused more confusion and problems(because of uncertified exe files).

Hello people! A couple of days ago I noticed, that files.minecraftforge.net does provide new native windows applications, to setup minecraftforge. The reason, why I found it out was very sad. 4 people(relatives, friends) called me, that they have problems with installing mods for new minecraft 1.7. You must know, that they really do not know much about technical stuff, but I learned them to install mods(with the new launcher and the *.jar installer). The main problem of the installation was, that 3 of them had chosen the installer-win download, because they thought it is the right one(yes they actually know, that they run windows ). After the download their antivirus/malware programs deleted the installation files immediately after the download, or blocked the execution. Nobody came about the idea, to just download the old *.jar installer. The 4th persons problem was a little bit more funny. The antivirus browser plugin blocked the whole download page, because of the adfly links to the *.exe files. I uninstalled the plugin, because it was clearly only scareware. I hope you guys understand, why I am posting this(Pls Pls Pls move back to the old installation)! Maybe start a discussion about which way would be better to the end user?

How do you exported your mod? Did you recompile it? Or did you just copied the class files into a .jar archive? Just in case you did not know that: gradlew.bat build builds your mod, and places it relative to your workspace in build/libs.

Move forward to 1.7.2 and upwards. You will save you from a lot of anger, because ids are gone. (Of course minecraft uses ids in a lower level of the game) If you use forge with 1.7.2 items and blocks are referenced by object.

At first, what forge version do you use? If it´s 1.6 or greater(with the new gradle build system), you have to make a special setup. Instead of gradlew setupDevWorkspace you should use the command gradlew setupDecompWorkspace. This command provides you the decompiled minecraft classes. But please listen to me: I suggest you, to not edit any base class, because then forge does not make any sense. If you edit some minecraft internal classes your mod will be incompatible to other mods, which use this class. But do not give up there is another much better way! You can request forge, to implement your needed feature in their forge API. That would be also awesome for other players. Eventually the feature, which you search for is already in the API?

No! What The bin folder contains, are the deobfuscated Files of your mod. You have to run gradlew.bat build to get working obfuscated.class files. The process converts all fields, methods and types into obfuscated ones. If you run the command you get a working mod jar in build/libs.

How do you export your mod?

It does work with Item as key itself! It is because the hashCode() method implementation in java.lang.Object returns the address of the object mapped to an integer. equals() standard implementation uses the == operator. There is no need to reference items or blocks by old id numbers.

Well thanks for the answer, but I do not understand it at all. So should I use the Item as key in my Map? I do not think so, because Item is not implementing equals() and hashCode(). Or are the standard implementations in Object enough, because each Item does only exist one time in memory? BTW I am pretty new to forge at all and I am really confused, because I started modding minecraft right at the time, when the 1.7 forge update came out.