Jump to content

MrrGingerNinja

Members
  • Posts

    6
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MrrGingerNinja's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. Believe me, I would use Git to do this; I upload the majority of my code to BitBucket using Git as it is, but some of the other code authors don't know the first thing about using Git and this was an easy temporary solution. When I update my Forge version again, I will probably show them how to use Git properly. That makes sense; like I said, when I set up a new version of Forge, I may take a look at setting it up in the way the Gradle intended for it to be set up as a library; thanks so much for all the help
  2. I apologise if I seemed arrogant in that post; it's just that my setup seems to work okay and I didn't really want to have to change my entire workspace layout. Especially as the majority of my workspace is in a Dropbox folder on my PC, synced with a select few who help develop the mods I am working on. It's easier for us all if I kept the workspace as it is And I apologise for stating that this is the way Pahimar does it; I saw some tutorial videos where he sets up each mod in a different project, but that's all I knew... I assumed he was doing it the way I do. Sorry again. Thank you sooooooo much. I have finally got it working now, placing the 'deof' version in my 'libs' folder and then the actual version in the mods folder when running the mod outside of Eclipse. Thanks for all the help; I really appreciate it!
  3. [1.7.x] Modding with Forge #3b - An Empty Mod File (and Hard-Coding mcmod.info) Hello and welcome to part 2 of Modding with Forge #3. After receiving a few requests, I have decided to do a brief tutorial on creating an empty mod file for Forge for Minecraft 1.7.10 (although this works with 1.7.2, too). Before I launch into this tutorial, I would just like to highlight the new location of these tutorials; the MinecraftForge forums, as opposed to the MinecraftForums. The reason for this is purely aesthetic but I feel that the community would much rather read nicely formatted, nicely printed tutorials with associated code, hence the change. Enough babble, though; onto the actual tutorial. The first thing we are going to want to do is create a new class within the 'src/main/java' folder. I am going to call my class 'Tutorial' and put it in a package called 'tutorial'. By using Eclipse, we will now have a pre-generated class file: package tutorial; public class Tutorial { } Currently, our mod is not going to be recognised as one; to make sure that Forge loads our mod as that, we need to provide an annotation above our class declaration; @Mod, making sure to import it when you do: import cpw.mods.fml.common.Mod; @Mod() public class Tutorial { } You will be receiving an error on the @Mod annotation, currently, stating "The annotation @Mod must define the attribute modid". So, inside the parentheses, type the following: @Mod ( modid = "Tutorial" ) The main thing to remember about the 'modid' attribute is that it must be unique. Every single mod ever created for Minecraft using Minecraft Forge or Forge ModLoader has had to define a unique mod ID. For testing purposes, using the ID "Tutorial" will work, since you won't have any other mods in your workspace with this ID. However, make sure this is changed to a unique name before you release it for use outside of your workspace. If you take a look at the source code for the @Mod annotation, you will see that there are several other attributes that we could provide. We are going to add an additional four attributes at this point: @Mod ( modid = "Tutorial", name = "", version = "", dependencies = "", acceptedMinecraftVersions = "" ) As I said, we are going to add four more attributes, each shown above. The 'name' attribute, obviously, is the name of your mod. I will call my mod "Modding with Forge", to accompany the name of this series. Similarly, the 'version' attribute is the version of your mod; in my case, "Tutorial #3b". These two, along with 'name', are the typically used attributes; 'dependencies' and 'acceptedMinecraftVersions' are less commonly used but can be very useful with enforcing players use up-to-date versions of Minecraft or Forge (if new methods are introduced to Forge that you use, for example, that are not in older versions). The 'dependencies' attribute is also helpful if you are developing a mod that requires another mod to run (e.g. an IndustrialCraft2 addon), or you simply want your mod to load after other mods (GregTech loads after almost every mod imaginable to ensure it can f**k with each and every recipe). In this case, we aren't developing an addon for a mod, so our only dependency is Minecraft Forge itself. There are two 'types' of dependency; "required-after" and "after". In the case of GregTech, it's dependency includes a lot of 'after' cases; this means that a certain mod (e.g. Thermal Expansion) does not have to be installed, but, if it is, GregTech will load after it, giving GregTech access to all of Thermal Expansion's blocks, recipes, etc. In the case of, for example, Advanced Machines (an IndustrialCraft2 addon), IC2 is required, so the "required-after" case is used. Our mod relies on Minecraft Forge being installed, so we will use the "required-after" case: dependencies = "required-after:Forge" The above code will work absolutely fine, but it allows the mod user to have any version of Minecraft Forge installed (Minecraft Forge v2.0 would be accepted as a dependency) and we don't necessarily want this. In fact, we definitely don't want this; we want the mod user to have the version of Forge installed that we are using in our workspace. To do this, we need to specify the version: dependencies = "required-after:Forge@[10.13.1.1217]" The above code is better than the previous, but we are now forcing the mod user to use only Minecraft Forge version 10.13.1.1217. We don't want this; we simply want them to have at least version 10.13.1.1217 installed. To do this, we alter the final character of the string: dependencies = "required-after:Forge@[10.13.1.1217,)" This string used as the dependencies means that the mod user needs a minimum of Minecraft Forge 10.13.1.1217 installed, but any build later than that will still let the client run and satisfy the conditions of our mod's dependency. If we wanted to add another dependency (such as IndustrialCraft2), we would use a semi-colon: dependencies = "required-after:Forge@[10.13.1.1217,); required-after:...; after:..." We can do this for as many dependencies as we would like. We are going to stick with using just Minecraft Forge for now, though. The final attribute that we need to provide is 'acceptedMinecraftVersions'. As the name suggests, this is the versions of Minecraft that will run our mod. This is specified in a similar way to the 'dependencies' attribute above: acceptedMinecraftVersions = "[1.7.2]" This string would lock our mod to only be playable on Minecraft 1.7.2 (which would not be possible with the Minecraft Forge version we have installed, but you get the idea). To define multiple Minecraft versions, we, again, change the final character: acceptedMinecraftVersions = "[1.7.2,1.7.10,)" Our finalised @Mod annotation should now look something like this: @Mod ( modid = "Tutorial", name = "Modding with Forge", version = "Tutorial #3b", dependencies = "required-after:Forge@[10.13.1.1217,)", acceptedMinecraftVersions = "[1.7.2,1.7.10,)" ) If you run your client now, the text in the bottom corner of the screen should now say that there are 4 mods loaded and your mod should appear in the mod list. If you select it, there will be some text displayed on the right that says: Modding with Forge Version: Tutorial #3b Mod State: Available No mod information found Ask your mod author to provide a mod mcmod.info file So, let's quickly create an "mcmod.info" file and I will show you how to hard-code the values into the file. Inside your "src/main/resources" folder, create a new file called "mcmod.info". The first thing you are going to want to do in this file is create a pair of square brackets, followed by a set of braces: [ { } ] Inside of the braces, you will need to write the following: [ { "modid": "Tutorial", "name": "Modding with Forge" } ] You need to make sure that the values for both "modid" and "name" are identical to the values you set in the @Mod annotation for the 'modid' and 'name' attributes. If you launch your client, again, there will be a slightly different screen when you select your mod from the mod list. This time, it should read something like: Modding with Forge Version: (Tutorial #3b) Mod ID: 'Tutorial' Mod State: Available Authors: URL: No child mods for this mod You may also notice that two buttons have appeared on the bottom left of the screen; one is a disabled button called "Config" and the other is a button with red text that reads "Disable". I will explain the purpose of the "Config" button in more detail in the following tutorial, but the "Disable" button is added for client-only mods (e.g. mini-map mods, NotEnoughItems, etc). It essentially allows the mod user to disable the mod (obviously) from inside their client, rather than having to close Minecraft, remove the mod from their mod folder and relaunch the client. If you are planning on creating a client-only mod that supports in-game disabling, simply add the following line to your @Mod annotation: canBeDeactivated = true Most of the time, however, you will not want your mod to be disabled from in-game (any mod that adds any sort of content, such as a block or item), since this will cause syncing issues with the server and likely cause severe problems for your mod users. Back to the mcmod.info file. Now that Minecraft reads our basic mcmod.info file, it is time to hard-code some values into it. To do this, we are going to need to add some new methods to our Tutorial class. Well, we technically only need to add one method for now, but, still. The first thing you are going to want to do is create another annotation; this time, it will read @Mod.EventHandler. At the moment, you will now get an error on this annotation, stating "Syntax error, insert "EnumBody" to complete BlockStatement". To anybody who doesn't quite understand what this means (myself included), you need to add a "EnumBody" (i.e. a method) beneath it: @Mod.EventHandler public void preInit() { } Now, the reason for the annotation above the preInit() method is that Forge will know to call this method during it's loading stages. However, it does not know at what stage of loading it needs to call the preInit() method. To specify this, we are going to add a parameter to our method; FMLPreInitializationEvent: @Mod.EventHandler public void preInit (FMLPreInitializationEvent event) { } If you wanted to, you could add a simple "System.out.println()" command here and run your client; this will show that the preInit() method is now being loaded by Forge. Perfect! But, how do we hard-code our mcmod.info file's information? That is the point of this, after all. The first thing we are going to want to do is create a ModMetadata object. This needs to be created outside of the preInit() method, and remember that import: import cpw.mods.fml.common.ModMetadata; public static ModMetadata modMetadata; So, we now have access to a ModMetadata object. If you don't know what a ModMetadata object is, this is the class that gets modified by your mcmod.info file. What we're going here is acquiring our mod's instance of ModMetadata and then hard-coding some of the values in. So, inside your preInit() method, the first thing you want to do is acquire your mod's instance of ModMetadata: @Mod.EventHandler public void preInit (FMLPreInitializationEvent event) { modMetadata = event.getModMetadata(); } Our mod's unique ModMetadata class is now stored inside our static 'modMetadata' object that we created a moment ago. We can now modify this class to our desires: modMetadata.modId = "Tutorial"; // This is the ID of your mod (the 'modid' attribute from @Mod) modMetadata.name = "Modding with Forge"; // This is the name of your mod (the 'name' attribute from @Mod) modMetadata.version = "Tutorial #3b"; // This is the version of your mod (the 'version' attribute from @Mod) modMetadata.description = "A hard-coded mcmod.info file"; // This is the basic description of your mod modMetadata.url = "http://www.minecraftforum.net/users/MrrGingerNinja"; // A URL relating to the mod itself or the mod author modMetadata.updateUrl = "http://www.minecraftforum.net/users/MrrGingerNinja"; // Not quite sure of the difference between url and updateUrl, so I make them the same modMetadata.authorList = Arrays.asList (new String[] { "MrrGingerNinja" }); // A list of author names that worked on the mod modMetadata.credits = "To all those who use and credit these tutorials!"; // Any additional credits you want to provide modMetadata.logoFile = "/logo.png"; // The location of the logo file (relative to the location of the mcmod.info file) Just in case you weren't sure regarding imports, you need to import "java.util.Arrays" for the authorList. If you launch your client now and check out your mod details, it will look a little bit fancier (especially if you added a logo file): <LOGO FILE IF YOU SPECIFIED ONE> Modding with Forge Version: Tutorial #3b (Tutorial #3b) Mod ID: 'Tutorial' Mod State: Available Credits: To all those who use and credit these tutorials! Authors: MrrGingerNinja URL: http://www.minecraftforum.net/users/MrrGingerNinja No child mods for this mod A hard-coded mcmod.info file So, there you have it! A hard-coded mcmod.info file, and the basic setup for your mod. I hope you have enjoyed this tutorial; let me know if you did! In the next tutorial, we are going to take a look at creating a basic configuration file and how we can use the new 'guiFactory' attribute in @Mod to allow the user to alter the config file through that great little "Config" button we say in the mod screen earlier on. I'll see you in the next one. ~MrrGingerNinja View the last tutorial (Tutorial 3 - The Basics of 1.7.x Mod Creation) > http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2223722-1-7-x-modding-with-forge-3-the-basics-of-1-7-x View the next tutorial (Tutorial 4 - In-Game Configuration) > COMING SOON
  4. The setup I have regarding Forge works absolutely fine with any other mod that I have built with the build.gradle script. I have had no run ins with any other problems, so unless this is the cause for the problem, I am going to keep the structure I have? As for the library mod, I ran the build.gradle file for this, as if it was a mod being released. Was this not the way to handle this?
  5. Hi, forum dwellers! I recently started a post on the Minecraft Forums regarding a dependency issue I was facing with the build.gradle file when trying to build my mod for release. coolAlias on the forums helped me out with fixing this dependency issue, but I am now facing another problem that has left both him and I stumped. I have set my Eclipse workspace up in the "Pahimar style"; i.e. creating a new project for each mod and make the mod's project depend on the Forge project. The dependency issue I was facing was that my current mod also depends on an API project inside of Eclipse; to fix the issue, coolAlias told me to build the API (which works), then put the .jar file into a folder called 'libs' in my mod's project and add the following beneath the apply plugin: 'forge' line: dependencies { compile fileTree (dir: 'libs', include: ['*.jar']) } This works absolutely fine and I am grateful for that. However, I am now facing an issue where the build.gradle script fails at the ":compile" step due to the following error: "error: TileEntityChestIron is not abstract and does not override abstract method isItemValidForSlot(int, ItemStack) in IInventory". Now, Eclipse does not tell me this error; it is happy with my structure (which involves a LOT of abstraction, just as a heads up). TileEntityChestIron extends TileEntityChest (my own version). TileEntityChest is an abstract class that extends TileGUI (part of my API). TileGUI is another abstract class that extends TileInventory (another abstract class, part of my API, that implements most of the core IInventory methods, including isItemValidForSlot). I copied the isItemValidForSlot method from the TileInventory class and put it into TileEntityChestIron and, when running the build.gradle file, the script failed again, this time complaining about not overriding abstract method closeInventory(). Does anybody know why this is happening and if there is a way to fix this issue? I made the API project so that creating inventories or GUIs or whatever is easier on my watch and makes my code look WAY neater. But this is becoming a real annoyance for me. Thanks in advance; I appreciate any help anyone can give me
  6. The most obvious problem I saw by skim reading is that you are saving the itemstacks in the slots to "Items" and "Slots". The Vanilla furnace code uses these names and, since the Vanilla furnace has nothing in them, they are returning null. Try changing these names to make them unique (perhaps add your mod ID or just change the names).
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.