Draco18s

Is it reasonably possible to have a single Item class that would allow for variable weapon strength (using NBT tags) without having to go through the enchantment system (i.e. Sharpness)? As far as I can tell, item damage is handled via getItemAttributeModifiers(), which does not pass an ItemStack (so no NBT data). Resorting to the Sharpness enchantment isn't out of the question, just less than ideal, as I'd like to handle that independently.

Food is correctly referred to as "shanks."

I don't think this is possible, TBH. I don't think it would be able to perform adequate pathfinding, even if it was non-solid and allowed to pass through walls; it would never try. If it is though, that would be really cool.

And what string is needed? "ironTool" OR "Material.iron" or"EnumToolMaterial.iron" And I guess level needs a float. But would you kindly provide an example? I have oly worked with modloader before. "tool" is the string for the tool name. Vanilla uses "shovel" "pickaxe" and "axe." Swords are handled by the web and leaf blocks respectively. However this string can also be any other custom tool, though there are additional registrations that have to be handled regarding the tool (and is not something I've messed with).

Ohsitdude, you don't need custom renderers or TileEntities for this. Here's some code from a block of mine. It was called CamoPhaseStone (mod thread) Now, it would only grab textures in an orthogonal line from its position, but this was done to prevent infinite loops where one block would ask another block what it's texture was, and that block would ask the first block.

You didn't set the block's hardness. Just because it's made of iron doesn't mean it will take a certain number of swings or a certain tool level. To enforce the iron pick you need to also set its harvest level. block.setHardness(5.0F); MinecraftForge.setBlockHarvestLevel(block, "tool", level);

Galicraft replaces the player class with their own, avoiding the issue (and also getting thing things like low gravity).

Having actually messed with this: From EntityLiving (or EntityLivingBase, if you're new enough): if (this.isEntityAlive() && this.isInsideOfMaterial(Material.water)) { if (!this.canBreatheUnderwater() && !this.isPotionActive(Potion.waterBreathing.id) && !flag) { this.setAir(this.decreaseAirSupply(this.getAir())); if (this.getAir() == -20) { this.setAir(0); for (int i = 0; i < 8; ++i) { float f = this.rand.nextFloat() - this.rand.nextFloat(); float f1 = this.rand.nextFloat() - this.rand.nextFloat(); float f2 = this.rand.nextFloat() - this.rand.nextFloat(); this.worldObj.spawnParticle("bubble", this.posX + (double)f, this.posY + (double)f1, this.posZ + (double)f2, this.motionX, this.motionY, this.motionZ); } this.attackEntityFrom(DamageSource.drown, 2.0F); } } this.extinguish(); if (!this.worldObj.isRemote && this.isRiding() && ridingEntity!=null && ridingEntity.shouldDismountInWater(this)) { this.mountEntity((Entity)null); } } else { this.setAir(300); } If the entity is inside a block of material type water, they drown. Otherwise they get full air (that's what's resetting it). Problem is, Material.Water is also what allows for swimming.

Thanks Lex. Apparently I can't read the documentation. Still annoying that it wouldn't reply when I tried to reference the class. And yes, I plan on fixing the javadoc, but I had to get MCPbot to behave (read: supply correct input) before I could update the docs. Edit: Gah. Can't rename already renamed methods. I had this problem once before, but I don't remember how to override that in order to change the description.

I realize this is not a Forge thing but an MCPBot thing, but here's the issue: /** * Adds a sounds with the name from the file. Args: name, file */ public void addSound(String par1Str) { this.soundPoolSounds.addSound(par1Str); } Javadoc is clearly out of date, as the function no longer takes a file reference. MCPBot conversation: func_77372_a is the function name I pulled out of the decompiled source of someone else's mod (in an attempt to try and figure out how they did sounds) and discovered that the way they'd done it for their latest release...isn't how it's done currently (on the plus side, the new way is easier, but the javadocs are out of date). Yeah, I dunno what to do now.

@ForgeSubscribe public void onSoundLoad(SoundLoadEvent event) { event.manager.addSound("MODID:SOUND1.ogg"); event.manager.addSound("MODID:SOUND2.ogg"); } world.playSoundAtEntity(entityplayer, "MODID:SOUND", 1F, 1F); Then your sounds go into a folder called "sound" inside your mod's asset directory. Voila, now you can use sounds like textures!

Close enough. At least I finally stopped trying to add an L to it.

By moving the resource directory to where it needs to be. If you're using the Pahmir* setup, you'll have to import it the same way you would anything else. *I forget how to spell his name and don't care to actually look it up

Essentially you'd be requesting Forge to add hooks for what you need. Reflections. Google it. You won't be able to pull this off at your skill level though. No, you'd simply be replacing a variable with a new value. You wouldn't be altering the code itself.

Oh my god, are you not listening! You're the one who used "override inside a method" first and also complained that doing so "threw an error" and never said what this error was. Previous mention of @Override? and Neither one of which mention putting override INSIDE a method. YOU did that. You were then informed that that was doing it wrong, provided an example of doing it right, and you started bitching again about us not understanding you. We're not telepathetic, like you appear to be, get it through your head: WE CANNOT READ YOUR MIND, NOR YOUR CODE unless you post it in a clear, concise, manner. Oh, and yes. I'm a dick. Get over it.

TBH I might even be wrong. The best part is, Minecraft will print an error of the correct location when the load fails.

Same place as every other texture thread: mcp/src/minecraft/assets/MODID/textures/entities/FILE.PNG

It's Forge\mcp\src\Minecraft\assets\ alright, but you have a /mods folder which you don't need. (/mods became /assets)

move naming() to the preInit function

You shouldn't need to refactor your CLASS names. I was only referring to all texture files and all folders in which those textures reside.

ResourceLocation is a class that functions similarly to loadTexture.

Worth checking. It felt obvious, but I'm not actually surprised that it didn't work (rendering does that: seemingly meaningful changes do nothing and seemingly meaningless ones cause LSD).

Try putting the disable lighting call above the render call..?

My pet peeve is people saying "X isn't working!" without posting the error or code (or worse, neither). My response is to add more cheese.

That has nothing to do with texture scale. You need a custom renderer. Which is not a copy/paste job, because of the way items are rendered (the faux extruded 2D). You're kind of on your own.