Draco18s

BoundingBox != CollisionBox getCollisionBoundingBoxFromPool is the function you need to prevent the player from walking through it.

In your GUI code there's some X and Y coordinates. THAT'S what's offset.

I'll have to dig it up later this evening. Don't have a copy right now.

If the model is bigger than 16x16x16 you should probably use a tile entity. As for the icon, you'll need to specify how to do item rendering. There's a function for it, but I don't recall what it's name is.

I'm just saying that my code likely won't help I have "takes everything slots" (like a chest) then two custom slots with don't accept input (like furnace output).

You mean my incomplete and non-selective code that uses tile entities? (That is, it lets anything get placed into it, like a chest) Don't think it'll help you much.

Also: if(id == FoodExItems.backpack.itemID) { return true; } If that code was working, that will only allow a backpack to be placed inside your item's inventory.

mcmod.info files are really simple. https://github.com/MinecraftForge/FML/wiki/FML-mod-information-file Just copy the example one and change it as needed.

Just looks like your "active" textury bit is just sitting in the wrong place.

http://techne.wikkii.com/wiki/Main_Page

Of course.

InventoryBasic might not have that functionality. Open up that class in Eclipse and dig through it to see what's available.

Problem is, I don't think particles have collision boxes. Ninjusk: You could try using normal blocks. They'd be solid (and have code that detects collisions, like the cactus) but when the...creator of them dies (should be possible to detect) you trigger one of the blocks (doesn't matter which one) to set its metadata to a specific value, then on its next update, replace itself with air. Then you can use that change in state to set the rest of them to do the same thing (think redstone, but without the signal decay). I use similar code in my phase blocks mod, which is open source.

I've been doing both 1.5.1 and some backporting of my code to 1.4.7, as I'm doing a plugin for Mystcraft, which hasn't updated for 1.5.2 yet, and one person is still using 1.4.7 for a Youtube series (for several reasons, one is because Custom Ore Generation hasn't updated yet). But yeah, generally a good idea to update.

When that function is called its because one of its neighbors changed (think BUD). When that happens, you can look at the neighboring blocks to try and see if the current block needs to change as well.

Sweet. You might even think about making an Energy API. Not like Universal Energy, but rather a core that other mod developers can take and use in order to create their own mods like IC2, etc. without having to make their own power network. They just have to create blocks and implement IPowered or IGenerator (or whatever) and have it done for them.

Also remember setBlockBoundsForItemRender() or the items in inventory slots will change as you point your cursor around the world.

Don't run decompile, that requires having no source code (running cleanup will delete everything in /src including your code). The error you got when compiling is expected. Forge is Universal, so your mod will also be universal* so not having the server source isn't a problem. Anyway, you DID successfully recompile. Go into /reobf/minecraft and you'll find a folder with your main package name. Add that to a zip file and distribute. (Also add your textures, which will still be in the src directory, and add an mcmod.info file if you desire) *Some exceptions

Honestly haven't messed with it in 1.47

A better question is: What, exactly, are you trying to do?

1.4.7 uses setItemName(...) for items and setBlockName(...) for blocks.

Armor I haven't messed with. I believe they work differently from everything else GUIs don't do the registerIcon stuff. They use mc.renderEngine.bindTexture("full/path/to/texture.png") where the full path starts after "src/minecraft/" so if you want to put those textures in a gui folder next to your blocks and items, then you'd use: mc.renderEngine.bindTexture("/mods/MODNAME/textures/gui/GUI.png");

getUnlocalizedName()

public boolean isStackValidForSlot(int i, ItemStack itemstack) { return true; }

I second this. Just because MC uses multiple IDs for something does not mean that is the only way to do it; frankly, Mojang is rather lazy when it comes to metadata use. The problem was not that "can you make multiple states without using more block IDs" but rather getting the light illumination level based on metadata. Doable, but it wasn't strait forward. See this thread for a working example.