SanAndreaP

The entity.boundingBox is final, but you can alter it in your constructor. As a standard, it's initialized with an AABB with "no box" (look at Entity.java, line 253) So if you don't alter it, you can just override getCollisionBorderSize() and return anything you wish.

Starting programming with modding Minecraft is usually bad, just saying. Anyway, change this: EnumToolMaterial.RTIRON to this: mod_refinedtools.RTIRON Do this for the other 2.

Can we still get the log? normally that shouldn't happen...

Um, Lex? Please don't flame me, but... javac doesn't accept memory arguments, only the runtime does. That's true, but IIRC, there are compiler-specific options available for -Xms and -Xmx called-J-Xms and -J-Xmx: -J-Xms1G -J-Xmx1G

That would require either mixing my sound files directly with my class files, and that would be very messy and hard to work with. Is there no way to get around this limit? (And why does it even exist)? You know the Sound Folder and the Sound Prefix you're defining are two different things!? Also the limit exists because of the size of the packet which must be send when playing a sound.

The EnumHelper doesn't add the variable to the EnumToolMaterial enum class, instead it adds it's values, makes it recognize them. You need to reference to your own variables in your mod_ class instead in the EnumToolMaterial.

Can we see the crash log?

delete your lib folder and let Forge redownload it. if it's still crashing, go to the EAQ, download the fmllibs15.zip and extract its content into the lib folder and replace the files.

Shorten your sound prefix.

It's clearly not Minecraft 1.5.2. You should do a force update and get a new minecraft.jar.

I'm not talking about your PathProxy, lol. I'm talking about the ModLoader class.

read the EAQ.

Actually you need to return -1 in the idDropped method if you don't want to drop anything. BUT my method would work (right?). It is harder, slower, and less logical, but you should get the same result. Unless the random variables are identically seeded in which case it would fail catastrophically. Just return -1. Yes, this works perfectly fine. You could make it a switch-case block instead of several if statements, though, but it's not necessary.

You know that this "PathProxy" is client-sided? Meaning it will likely not work on a dedicated server. Also what if the Forge devs drop the ModLoader compatibility? Or if ModLoader changes something about this method and Forge adapts those changes after a couple releases? You are better off with using the Forge methods, trust me.

Actually you need to return -1 in the idDropped method if you don't want to drop anything.

Oh yeah, it's not different there. What i noticed though is you don't actually call the right method for registering your renderers: tutorial.generic: proxy.registerRenderers(); ClientProxy: public void registerRenderThings() {

Your ModelNutcracker class is outdated (I see it's generated through Techne), it doesn't override any method from the super class, namely the render(...) method. You should look at it, that's most likely your problem! I seem to be confused...do you mean the super.render method that is in the ModelNutcracker class? No I meant your own render method. It should override the super classes' render method. Look at this model file from one of my mods and look at your class in comparison (especially the render method): https://github.com/SanAndreasP/TurretModv3/blob/master/sanandreasp/mods/TurretMod3/client/model/Model_MobileBase.java#L130-L152

You can either look further down to the point where the var21 is actually used, or look at my source: https://github.com/SanAndreasP/TurretModv3/blob/master/sanandreasp/mods/TurretMod3/client/packet/PacketRecvSpawnParticle.java You probably see that you only do it client-side, meaning if you want to spawn a particle through server logic (for example in a method which only gets called server-side), then send a packet. Else I strongly suggest to do it directly w/o sending packets and check if worldObj.isRemote == true.

Well, to be fair, some of us don't use Twitter. Thanks for the clarification, though. That's why I linked to it

Your ModelNutcracker class is outdated (I see it's generated through Techne), it doesn't override any method from the super class, namely the render(...) method. You should look at it, that's most likely your problem!

There's no "mod file", there's a mods folder in your .minecraft directory. You should read the install instructions of the specific mods first before blindly copying stuff into that folder, though.

You should look at this tweet from cpw:

Read the EAQ.

The item classes are, like the block classes, only instanciated once, meaning if you set a variable in the item class, it will be changed for all loaded "items" in the world and even across worlds. What you want to achieve is saved into an ItemStack. It's instanciated for each "item", making it unique. There you can store the damage value and even NBT data. I suggest you look at it, for your specific problem you should use itemStackInstance.setItemDamage(damageValue)

Rei's Minimap is not for servers.