Draco18s

Yup, that's definitely a neat idea. Mine was just a kind of "survival, but limited creative" where I needed certain stuff just be readily available. So mine can only have the item it's printing changed (added, removed) if the player is in creative mode. Then it duplicates that stack every two and a half minutes or so into the output stack (which is a standard output slot). It still has some bugs, but it's not intended for distribution.

Also, that looks fantastic. When I did a quickpass on a 3D printer block* I just rendered the item it printed if it had any in its output slot using RenderEntityItem and having a vaguely printerish Tile Entity. It didn't look like a 3D printer, at least not as we know them, but it worked for what I was doing and didn't want to spend a lot of time making it look fancy. Not visible well in this, but it was a silly thing I did because I was feeling silly.

I know it's possible. iChun's morphmod manages it (with a coremod fallback). Problem is when I tried to duplicate it, I couldn't get it to work at all.

You....need a custom block renderer to even make this possible, which you don't have yet.

Unfortunately, just because you have the same problem doesn't mean you have the same code.

Yes. You're not saving your textures anywhere and are constantly creating new ones.

Not easily. You'd probably have to write your own renderer. Just swap your pngs and it'll work.

Yes. But my point is that the "overlay" layer needs to be transparent.

Ahhh. Ok.

EntityList.addMapping(EntityClayGolem.class, "Clay Golem", 3, 13347172, 7033635); Those last two ints are the decimal representation of the egg colors. The first one, IIRC is the base color, the second is the spots.

Is there a reason you're not using Packet250CustomPayload? It's super easy.

It is. Minecraft is weird like that sometimes. Like diamond picks using ToolMaterial.EMERALD. Anyway, I have no idea.... Actually wait. I do. Your PNGs. Do you have a regular and an overlay texture? I assume so. The regular is the one that gets colorized. The overlay is then rendered after with no color adjustment. I think that might be your problem. And yes, it's a total nuisance. But that's how the armor renderer was written.

Or move those calls into the constructor: public class BlockClass extends Block { public BlockClass() { super(Material.gourd); this.setCreativeTab(mod_myMod.tabMyMod); setStepSound(Block.soundTypeWood); setHardness(1.0F); setBlockTextureName("mymod:myblock"); setBlockName("myblock"); } }

ItemStack.getItem() Also, new ItemStack(Blocks.sapling, 1, 1) for metadata.

https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/client/ItemRenderSpikes.java https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/client/SpikesRenderer.java

You'd need to override the getColor() function. Not sure if there's one that passes the world object to it or not.

That function, yes, and another. public void onDataPacket(INetworkManager net, S35PacketUpdateTileEntity packet) { readFromNBT(packet.data); } (alert: this code was for 1.6.4, I just updating the packet class type, there MAY be other differences for 1.7) They're both called automatically.

Define "GUI." Do you mean something like the player's health? Or do you mean like a furnace inventory?

Probably because the server doesn't know WTF a texture is. Also, ModLoader != Forge. You should look to see how Forge handles the same thing and do it that way. ("But," you say, "Forge comes with all of these ModLoader classes." No, that's FML aka Forge ModLoader. It translates ModLoader calls into Forge calls so that ModLoader mods and Forge mods are compatible with each other).

You (the programmer) don't have to. That's the point of overriding existing functions: they're called by Minecraft's internals automagically.

Yes, it would. But it's also a hell of a lot easier than trying to implement your own efficient power network yourself. Plus we're up to like four major, different, power systems at this point aren't we?

The most complicated thing in it is the camouflage code (getTexture). And that's not even relevant here.

You might want to take a look at http://minecraft.gamepedia.com/TNT#Explosive_force http://minecraft.gamepedia.com/Explosions#Model_of_block_destruction

There's also a collide function in the Block class that will detect entities, IIRC. Look at the hopper.

Item#getTextureName()? Then pass that to new ResourceLocation()