MoxEmerald

Now I understand. I highly doubt it. I believe LexManos likes to say that if there's a perfectly good hard way to do something then do it the hard way. If you want to compare your code to something someone more official wrote you can check the addItemStackToInventory method inside InventoryPlayer.class.

From ContainerAmethystOven.java this.addSlotToContainer(new Slot(par2TileEntityAmethystOven, 0, 56, 17)); this.addSlotToContainer(new Slot(par2TileEntityAmethystOven, 1, 56, 53)); this.addSlotToContainer(new SlotAmethystOven(par1InventoryPlayer.player, par2TileEntityAmethystOven, 2, 116, 35)); this.addSlotToContainer(new Slot(par2TileEntityAmethystOven, 4, 26, 17)); this.addSlotToContainer(new Slot(par2TileEntityAmethystOven, 4, 26, 53)); this.addSlotToContainer(new SlotAmethystOven(par1InventoryPlayer.player, par2TileEntityAmethystOven, 5, 141, 35)); Add slots with ids 0, 1, 4 and 4 for the tileentity? And I don't know about this custom slot business but you also appear to have slot ids 2 and 5. 3 is jealous of 4 dude. Don't disrespect 3 like that.

But it does work for itemstacks you create? I thought an itemstack was an itemstack, but if not... you could instantiate a new itemstack using data retrieved from the entityitem's itemstack. But I feel like I misunderstood the question. Does it work if you pass in any itemstack? If not throw in some println debugging. I usually start with confirming that each if statement really did return true at some point. Then I root out any nulls.

Kind of like a furnace? Go check out the furnace code a little. When it's placed by a player it sets metadata to indicate which direction it (or the player if you prefer) is facing (at that time). There is a method: public IIcon getIcon(int side, int meta) that will pass you the metadata as well as the side minecraft wants the texture for. You pass back the icon you want it to use for that side if it's facing a certain direction.

To CarbonBasedGhost's point- it would usually be easier just to recreate the mod from scratch. Unless you can get your hands on the source code before it was obfuscated, but you'd still have your work cut out for you.

Havvy's Tutorials appear to be attempting to teach both 1.6.x and 1.7.2- in other words it's okay to be slightly confused if those are the only things you've read. Having said that there are other tutorials you could cross reference, although many may well have the same problem. I'm going to assume you're using 1.7.2. In eclipse there should be a package at the top called "src/main/java"; this package is for your code. The package "src/main/resources" is for your resources. I'm only spelling this out for you since most tutorials can't get over minecraft 1.6.x. If you can't get it to work make sure you have setup gradle properly and maybe go learn eclipse/java with something more trivial than a minecraft mod before you jump in. You can also look up video tutorials for 1.7 so that you can see the words on the screen when they click on stuff. It can be hard at times to associate parts of a wall of text with parts of a program like eclipse.

How did you even notice that it was running twice? Just from the System.out? What do the methods even do? It might just be that your other tilentities are running twice but you didn't notice. Without complete information I'm just throwing darts. Something that might be useful is to System.out the words "client" or "server" based on the outcome of world.isRemote.

Instead of using ids I would store your block as an itemstack. In your dropBlockAsItem method you should try simply adding whatever nbt data you need to the itemstack that is dropped. Don't call super.dropBlockAsItem() and spawn an itemstack in the world yourself. The only problem I can foresee is if something has already destroyed the tileentity when dropBlockAsItem is called.

@SideOnly won't do anything for you; only use it if you @Override a method that already uses it. Instead use world.isRemote in an if statement or some-such so that you can check if the method is just running once on the client side and once on the server side.

I don't see any constructors, but... When the game reloads it will call a constructor with no arguments and then call "readFromNBT(...)". If there is no empty constructor available it will give up. When this is the problem Eclipse throws a bunch of red text at me upon attempts to load the world. Pay attention to the red text.

@Override public boolean isOpaqueCube(){ return false; } in the block class should fix at least some of it. Now that I look closer you seem to have tried- public boolean isOpaqueCude(){ return false; } Which should encourage you to use that Override annotation.

For practice you could go and setup forge in a different location from scratch and try to compile and load the example mod that comes with it.

Normally you would use- public void randomDisplayTick(World world, int x, int y, int z, Random rand) Go and check out Minecraft's BlockFire.class, it spawns a particle at a psuedo-random location whenever the above method is called. But since you want it to spawn when the block is right-clicked, instead of randomly, spawn the particle in- public boolean onBlockActivated(World world, int x, int y, int z, EntityPlayer player, int side, float x1, float y1, float z1) (check if "world.isRemote" and note that this is in Block.class not TileEntity.class) To spawn a custom particle instead of one of the vanilla ones- Minecraft.getMinecraft().effectRenderer.addEffect(new CustomFX(args...)); stick some more coherent arguments in there and CustomFX will need to extend EntityFX. There aren't any handlers involved unless I'm just losing it. I would say that creating a custom particle can be somewhat non-trivial though. There are tutorials for it floating around somewhere.

Have you tried setting the "fence_oak" block's material to Material.wood? Seems silly, but I thought I'd ask.

@ForgeSubscribe to @SubscribeEvent

public ItemStack getSmeltingResult(Object ... input1) { Iterator iterator = this.smeltingList.entrySet().iterator(); Entry entry; do { if (!iterator.hasNext()) { return null; } entry = (Entry)iterator.next(); } while (!this.func_151397_a()); return (ItemStack)entry.getValue(); } private boolean func_151397_a() { return true; } So... retrieve the first recipe and set it to "entry". If func_151397_a returns false repeat until..., but func_151397_a always returns true so we never repeat. Now that we are no longer in the do... while loop we return entry.getValue(). Maybe you should compare the "entry" to that "input1" Object array you pass in? Or did I miss something vital in your code?

You should try changing modelnam = new ResourceLocation("financiacraft", "models/" + modelname); to modelnam = new ResourceLocation("financiacraft", "models/" + modelname + ".obj");

In a development environment running forge 10.12.0.1024 this happens every time I change a method from one of my blocks or items. Just in case you still wanted to trigger it intentionally it.

Sounds like the item is only being removed on the server side. If the client side thinks there is an item you'll still be able to retrieve it.

I use the implementation that @Glenn advises against, but have not noticed rendering errors. There may be something else at work there. It should be noted that the frivolous use of tile entities is discouraged, so I would try to make it work by instructing the Tessellator instance to "draw" and "startDrawingQuads" at the beginning and end of your method respectively. After doing this, most rendering errors can be dealt with on a case by case basis. Having said that, rendering your block programmatically would be better, like Glenn Suggested, if inconvenient to your artistry. Technical Reason [tek-ni-kuhl ree-zuh n] (noun): You probably can't be bothered. (Shame on you)