Jump to content

Seigyoku

Members
  • Posts

    23
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    Erryday I'm Moddin'

Recent Profile Visitors

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

Seigyoku's Achievements

Tree Puncher

Tree Puncher (2/8)

25

Reputation

  1. Good, good! I was wondering why some aspects of Eclipse weren't behaving for you like they should have. Best of luck in your modding projects!
  2. Happy to help! Honestly, configuration files seem like an intermediate approach to stuff like this, so kudos to trying this sort of thing out. No suggestions from me right now, just good luck on your future projects!
  3. Ding ding, here's our problem, it looks like. I'll be editing this post as I try to traceback the process. As for you wondering why your Item IDs are so high, can we see your custom item class? This might actually solve why the config file is doing what it's doing. EDIT: Okay, we know now how the config file is messing things up, just not why. AmethystOre = new A_MTM_BlockCore(this.AmethystOreID, 23).setBlockName("AmethystOre"); Following that, and looking at what you wrote before: Since the value is already written into the config file and saved, disabling the code doesn't entirely help, you'll have to manually edit the value yourself in there too. See if it behaves changing the value from 31541 to 3307.
  4. Alright, I'm just trying to make sure for myself which of your block variables is giving you a headache. One more time to confirm, which one is being a pain, AmethystBlock or AmethystOre? I'm pretty clueless as to how Forge formats config files, but if the error is inside the file, it should be easy enough to spot. Just remember the number, 31541!
  5. That's okay! We all start off trying to figure out our hands from our feet in this sort of hobby. I'll use what you supplied for hopefully something easier in explaining what's going on: more or less means: Your textures come from the sprite sheet you supplied for your blocks. That you already figured out, I think, looking at your getTextureFile() method for that class. So you're initializing AmethystBlock: this.AmethystBlockID is the ID of your AmethystBlock 39 is the texture index you're using from your supplied sprite sheet So, there isn't anything wrong with your code so far, actually! But for some reason, your compiler thinks that AmethystBlockID has the value 31541, which is no good to us. Due to that, we have to keep looking: This seems to be the real culprit. You supplied a default just-in-case value of 3607, well within the bounds of the block ID array, so the config file should be the cause of your problems. There's a very good chance that there's confusion between item IDs with block IDs in there, as 31541 is suspiciously looking like an item ID. As for where the config file should be, look in \forge\mcp\jars\config\, is anything that looks like yours in there? Configuration files aren't really known to me yet, so I'm mainly going off of what I see in this link: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file EDIT: Okay, I checked out your error logs again, the older log marks line 453: while your newer error lists line 447: Both have the same marked issue though, 31541 as an arrayOutOfBoundsException. Why is your compiler spitting out the same problem at different lines of code each time you try to test it?
  6. I can explain this simply: When you initialize a block or item, the first parameter usually is the object's ID. The object gets shoved into net.minecraft.block.Block.blocksList[iD] and net.minecraft.item.Item.itemsList[iD] if it's a block, or into net.minecraft.item.Item.itemsList[iD+256] if it's just an item. This is a very important part of initialization, because: This can't be changed easily unless we alter the base code, or know how to tell Forge to change it for us. The constructor I showed earlier lets us know how the ID part of the block's initialization is handled: Because of this, calling an index outside of these arrays tend to lead to this kind of compile error. Some examples straight from Block's variables: So, we know that Stone Blocks are stored in blocksList[1], and Dirt Blocks are stored in blocksList[3]. Meanwhile, sprite sheet indexing is an entirely different matter, that's handled in a different part of initialization. That parameter in line 11 of A_MTM_BlockCore.java is your texture index parameter. See the difference? End lesson! Moving on: Your initialization of the block itself seems okay from the surface, but I'd like to see the constructor you're using with line 11 of A_MTM_BlockCore.java just in case. Is that alright? Meanwhile, the trail ends at your code attempting to pull an ID from your config file. Since you have an in-case ID for AmethystBlock to be 3607, the issue could be within the config file itself. Is there anything that looks like the number 31541 or a similar 5-digit number in there?
  7. I don't know what you're trying to accomplish, but your code is ending up calling index 31541 of net.minecraft.block.Block.blocksList[] for initializing one of your Block variables. As mentioned, the Minecraft base code by default doesn't allow blocksList[] indexes other than 0-4095. If you're getting confused with "Infinite terrain/sprite indexes", that has to do with the appearance of blocks/items and nothing to do with allocations in ID arrays. If however you're making use of a mod that tweaks the blocksList[] array bounds in the base code, it's not cooperating. This is where things are hanging up, in order: #1, line 324 of net.minecraft.block.Block: #2: Line 359 of net.minecraft.block.Block: #3 and #4 have to do with the code you're using for your mod. Mind showing us what line 11 of A_MTM_BlockCore.java and line 453 of A_MTM_CORE.java are, and the related methods where said lines are contained?
  8. Okay, that might actually be part of the problem... Europa is a 2007 release, meant for JRE 5. We can go two routes at this point: 1.) Scrap Europa and download a newer version of Eclipse, see if it does the same thing with the workspace 2.) Continue working with this, see if we can get anywhere with this, I doubt this compiler is going to be helpful though Assuming you want to continue on this, use Edit and there hopefully will be a "Browse..." button next to Linked Folder Location. Try to get it to match up with your intended directory if there is.
  9. *blinkblinks* ...Well, that explains the real problem. While this is going on, which Eclipse are you using? Let's tackle this another way then: -Right-click src back in the Project Explorer, Build Path, Configure Build Path (We're going back to Java Build Path, this is just another way to do it for what we want right now) -Because of what you showed before, the Source tab should be empty of any entries. Does "Add Folder..." and "Edit..." appear?
  10. Alternatively, when initializing the food, you can use This is actually what the rawChicken and rottenFlesh items in net.minecraft.item.Item do, since there isn't a class extended from ItemFood for them: Both effects last 30 seconds, and Raw Chicken has a 30% chance of the effect kicking in while Rotten Flesh has an 80% chance of this happening. This is much simpler than using onFoodEaten, but that method allows you to have multiple potion effects occur at once, so I'll go over that as well. Concerning ItemFood's onFoodEaten method, the example used within the code is actually handled within a method that onFoodEaten calls and extended classes can override: As for the method itself, also found in ItemFood: The method name is currently obfuscated, but can be seen overridden in examples like ItemAppleGold: This example allows for the Enchanted Golden Apple (checked via the "if (par1ItemStack.getItemDamage() > 0)" statement) to provide 30 seconds of Regeneration IV, 5 minutes of Resistance, and 5 minutes of Fire Resistance. Divide all values by 20 for parameter #2 of PotionEffect to figure out how many seconds an effect lasts doing this. This is different than how the setPotionEffect method works when initializing an item, so be careful not to mix this up! There are pros and cons to using either approach, use the one that better suits what you want to do.
  11. Good, half the problem is fixed! Now for the other half: -Right-click the src you have highlighted in your image, select Properties -What's the Location and Resolved Location looking like? It should be something like MCP_LOC\src\minecraft & C:\whatever\forge\mcp\src\minecraft respectively -Click the "Edit..." button next to Location -Verify that it's actually pointing to \forge\mcp\src\minecraft via "Folder..." Fingers crossed!
  12. No problem, this is an odd one. Here, try this out: -Right-click the project, select Properties -Go to Java Build Path, Libraries tab -Are any errors listed? Are the "missing" files there despite what it said earlier? -If the JARs aren't there, manually add them from \mcp\jars\bin and \mcp\lib. If they are though, first remove them and then re-add them. Let's see if this works out.
  13. Alright..so the directories got made.... how about \forge\mcp\jars\bin, what's all in there?
  14. Curiously, what does \forge\mcp\ look like when you go to the directory on your computer?
  15. I found this thread that might help shed some light on things: http://www.minecraftforge.net/forum/index.php/topic,3389.0.html I'm not sure how good the solved code is nowadays, but some things I noticed: -Since a Tile Entity is involved, it might be better to use a custom Tile Entity renderer, like they mention and write an example of later in the thread, rather than use the block rendering handlers. -BlockVelvetTable.java, which extends BlockContainer, uses the getTextureFile() method we're more familiar with. Maybe BlockMVBattery.java should do the same, since it also extends BlockContainer?
×
×
  • Create New...

Important Information

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