Jump to content

Shadzari

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by Shadzari

  1. Using version 1021 of Forge and Juno SR2 of Eclipse (20130225-0426). There is no launchwrapper-1.9.jar anywhere in my Forge directory, and for that matter, there is no such file anywhere on my entire C:\ drive. I've run the entire setup process at least five times by now to address various other issues, and have had zero errors on any of the processes. Still can't run the client from within Eclipse. It's obviously not a problem with an outdated version of Eclipse if the file does not even exist. Suggestions?
  2. Thank you. That I can totally understand and I can totally get on that boat. This is the kind of answer that I was hoping for. I'd like to see this list elaborated on somewhere for those who have the same concern/question but I realize that 1) you're a busy guy and 2) it isn't really your job anyhow, is it? Anyway, thank you for taking the time to answer, and I apologize for any arguments started by the thread. Shad
  3. I'm sorry if I seem a downer - or if I am going off-topic - but I'm failing to understand something, and if someone can offer me some enlightenment, I'd really appreciate it. Why has Gradle/ForgeGradle been implemented? I haven't been messing with mods or Java long - only for about seven months - but I've been coding for MC since day one of that, have gone through setting up Forge for every significant build since then, and I honestly don't see what ForgeGradle is offering in the bigger picture. Taken at face value, the installation of the Forge src is complicated now and totally non-intuitive, and updating src builds within the installed framework doesn't seem to be much more friendly. The older style of Forge src installation, including mod src backup and migration, could be easily automated with a custom .bat and a few mouse clicks, but this is just... I don't know. Taking Gradle as a project automation tool, I can imagine that it might be useful if someone has coded a huge mod that for some reason Eclipse can't handle - but I can't visualize the likelihood or mechanics of that because Eclipse, to me, is just a coding environment with highlighting and F3 go-to-code backtracking, and all the recompiling and deobfuscating being handled through two nifty little .bats on my desktop. (If I didn't need the go-to-code in Eclipse, I'd probably still be using CrimsonEdit, to be honest.) I'll be honest - I like things simple. I need things simple, actually, due to a lovely heaping dose of adhd. (No, I'm not trying to invoke sympathy, I'm just sayin' that it does have an effect, and that I have had to find alternative ways to be efficient with this stuff.) Anyway, I'm starting to derail myself, so... point is, I don't understand how Gradle/ForgeGradle is making enough of a positive change to overcome the additional pain that installation at this point looks like. If someone who's in the know can enlighten me, I'd love ya. If there's some benefit or future need I'm not seeing, I'd love to either be able to utilize that benefit or be prepared for that change. Thanks Shad
  4. This is part of your issue, I think. The setup doesn't like it when you phrase stuff like this, in my experience. Instead: let's say you init your TomatoSeeds.itemID in your core mod file (AdenMod.java/.class); you'll want to put it down as return AdenMod.TomatoSeeds.itemID For a practical example, here's part of one of mine. I register and init all my crop stuff in my CropReg file. (I have no clue what the difference is between your public and my protected, btw.) protected int getSeedItem() { return CropReg.ItemSeedAtigana.itemID; } protected int getCropItem() { return CropReg.BerryAtigana.itemID; } As for removing the seed drop on harvest, try this instead of what you have (remove ": this.getSeedItem()"); as I'm not fiddling with the code at this exact moment, I can't tell you if it will error. If it does, remake the constructor so that it removes the "int par3". (Sorry if I'm wrong, coding in any language is not my forte.) /** * Returns the ID of the items to drop on destruction. */ public int idDropped(int par1, Random par2Random, int par3) { return par1 == 7 ? this.getCropItem(); } Oh, and many thanks to you for posting your code - I think that you may have given me the solution for why my eight stage crop only grows to stage 4 and at that point is harvestable.
  5. My apologies. Full file paths, for my setup; first set is with the .class files after recompilation, second set is with the .java files before recompilation: C:\Files\forge\mcp\eclipse\Minecraft\bin\mods\minehack\textures\items\name.png C:\Files\forge\mcp\eclipse\Minecraft\bin\mods\minehack\textures\blocks\name.png C:\Files\forge\mcp\src\minecraft\mods\minehack\textures\items\name.png C:\Files\forge\mcp\src\minecraft\mods\minehack\textures\blocks\name.png I mean both. It was a random idea; on mouseover in live, the blocks have 'tile.Antigonite.name' for instance, so I figured it was worth checking to see if might have been changed to \tiles\ instead of \blocks\. Not so, sadly.
  6. As for locations, here is what's working for me at the moment: 1) Within Eclipse/Forge/MCP: - Keep setup the same: {modid}\textures\{items/blocks}\name.png 2) After recompiling & obfuscation, ready for live play: \assets\{modid}\textures\items\name.png Unfortunately, blocks does not seem to be playing by the same rule for me *despite* the following: 3) After opening the 1.6.1 jar in .minecraft/versions/, this is what I'm finding: \assets\{modid}\textures\blocks\ \assets\{modid}\textures\items\ \assets\{modid}\textures\entities\{mobtype}\name.png GUI, paintings, items, misc, and all that is in that \textures\(subfolder)\ as well. I'm wondering if the blocks' textures need to be coded differently, even though there's no apparent errors in Eclipse for my code.
  7. I second SanAndreasP. If you want to run a version 1.5.2 or earlier, get MultiMC. I've been using it for a few months now and I love it to pieces. It is easy to use, you can specify directories for the MultiMC instances, there does not seem to be any shared folders between MultiMC instances, and it's a tiny little uncomplicated program. I intend to keep using it, period. In regards to *having* to use Mojang's launcher, I assume that is meant in terms of using the new launcher for releases 1.6 and onwards, and is not going to be applied to older versions. (I don't know for certain, though, that's just my speculation.)
  8. ^ x2. I was messing around with it last night pre-installer because I'm impatient like that, and let me tell you - after an hour of futzing with things and still not getting them to work, being able to download the installer and just have it work like *snap* was SOOO NICE. Thank you, guys!!
  9. Thank you for the help! Just for clarification: I should have a separate file for both shaped and shapeless recipes? Your code looks like you've got a package for recipes, but a single file for each type. So, if that's the case, I should have two files in my Recipes package and in the @init in my coremod file I should have: ShapedRecipes.init(); ShapelessRecipes.init(); +karma for you, too
  10. I apologize if this has been asked and solved before, but I did search and couldn't find anything useful. I've got the basics of Java, but it's deep code that I'm not familiar with yet and I would like to ask for some help. What I would like to do is be able to take my code for creating new creative tabs and for registering new recipes out of my central mod file and place them in their own separate files. Will a simple 'Blah extends BlahBlah' in the separate files suffice, or will I need to put some code inside the central mod file to make load references to those separate files? (Maybe import the separate files in the central mod file?) Additionally, I do have a concern about the functionality of doing this with the creative tabs. Will my items and blocks be allocated to their correct tabs if all the code is in a separate file? Thanks for the help and the patience!
×
×
  • Create New...

Important Information

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