Draco18s

This: new BasicMetadataBlockMF("clayWall", Material.wood, ItemClayWall.class, 4) Calls this: public BasicMetadataBlockMF(String name, Material material, Class itemBlock, int number) { super(name, material, null); NUMBER = number; NAME = name; } Notice that the itemblock paramter goes unused.

Ah! So that's how the event handlers work. I always wondered about that.

You should be passing the TileEntity itself. The reason this isn't working is because your block doesn't HAVE a tile entity and the Container/GuiContainer are expecting an object of type moriumWorkbench (which, by the way, you should capitalize and prepend with "Block", BlockMoriumWorkbench ) You don't have a TileEntity to pass, so the TileEntity tileEntity = world.getTileEntity(x, y, z); is going to return null anyway and fail the instanceof check. If you want to do this with just the block, you're going to have some trouble. In fact, I already see some problems in your other classes. ContainerModTileEntity has this line: for(int y = 0; y < 3; ++y) { for(int x = 0; x < 3; ++x) { this.addSlotToContainer(new Slot(inventory, x + y * 9 + 9, 8 + x * 18, 84 + y * 18)); } } That's supposed to be adding a 3x3 grid for the crafting, but the inventory you told the slot that it is a part of is the player's inventory! Then there's this: public boolean canInteractWith(EntityPlayer player) { return ((IInventory) this.te).isUseableByPlayer(player); } te in this context is a moriumWorkbench , which as established above is a Block which does not extend IInventory! This line will throw a null pointer exception when run, as will likely your transferStackInSlot method; I'm not entirely sure what'll happen. Long story short, you've followed a tutorial for how to add a gui interface for a TileEntity and have even named your classes with "TileEntity" even though you do not have one.

hehehehe Figures Forge would do that. What I don't know is why runtime class creation is preferable over a standard compiled class. That is: I can't think of a use-case where it would be necessary. Then again, the only example I saw was just that: an example to show that it could be done. And no, I have no idea what that Forge one does. It's still stupid complex even if you know what you're doing, because of how many things you have to keep in your head at one time in order to write a single line of code. You have to know what's on the stack, what operation you need to do next, how it will affect the stack, and so on. So I wouldn't say it's easy, more like doable.

Oh. Try putting the @instance annotation above this line: public static TutorialMod instance;

I was going to take a guess at isSideSolid, earlier, but I would have thought that BlockWall did that already.

I don't see anything wrong with your read/write NBT methods, but holy hell your class names are a mess. ModBlockTileEntity.java isn't the tile entity class as I first expected, then neither was ContainerModTileEntity.java The "best" naming convention will be one that everyone working on Minecraft is familiar with: BlockWhatever , TileEntityThingamajig , ContainerWhatThing , etc. Also, Class.java ? Seriously?

You have @SideOnly on these methods, why? https://github.com/NovaViper/TetraCraft/blob/f8c2adc9221004eed999621d2c95a2c922fc1605/src-1.8/main/java/novaviper/tetracraft/client/proxy/ClientProxy.java#L105-L133

Show your Reference class. I cannot tell if you have typoed the package name for your client proxy because you hid that value away inside another class.

You checked if source was an instance of EntityDamageSource, but you didn't cast it. ((EntityDamageSource)source).getEntity()

Isn't the JVM amazing? (There's also a reason that I call coremodding / ASM an abyss that looks back. Javacode can modify javacode at runtime. Hell, you can create new class types at runtime, entirely through the bytecode manipulation features if you really want to.)

import lines, by the way, aren't actually compiled. You can import all the packages you want, it doesn't matter. What imports do is tell the compiler where to find a given class that is being used (and those references are compiled). Imports are essentially syntactic sugar. You only have to type import System; Object somevar; , but what actually gets compiled is System.Object somevar; . So import some.package.not.being.used; gets stripped. So what happens when a class is loaded by the JVM is that the JVM needs to verify that every other class reference made by the loaded one can be retrieved and loaded as well, as it needs to insure that every call being made by the class being loaded is a valid action. This is why if you do any coremodding and alter a class, but make it try to reference a class or object that doesn't exist (e.g. a typo) the game will crash: it attempted to validate the modified class and was unable to locate the reference (I did this on accident once). (As an aside, the throws declaration isn't compiled at all and the JVM doesn't care until the error is actually thrown and nothing in the call stack handles it.)

You should be taking the player's rotation, getting the sin and cos, and adding that to the player's position. I don't know why the circle would be small, unless the offset isn't being multiplied by a large enough value (the double distance = this.SpecialBulletLogicOffsetFromFiringEntity; line dictates how far away from the player the chicken will be).

It used to, but it now returns a ResourceLocation under the new registry system. Ah, interesting.

...there's a 1.9.2 version of Forge? Srsly, the changes necessary for 1.9.0 aren't done yet.

What do you mean it "didn't work"?

You removed the public static field tile_entity_gui . You still need that, or can replace it with a 0 (but doing so violates the advice given upthead, but to follow it you'd need to check id == tile_entity_gui instead of id == 0 ). ((Also, tile_entity_gui is a terrible name))

myItem.setRegistryName("myItemIsCool"); GameRegistry.register(myItem); Also, getRegistryName() already returns a string, you don't need to .ToString() it.

You should really move the rendering stuff to a client proxy.

Splitting it out like that had a huge potential for introducing more errors. If you'd managed to screw something up and got the items out of order the second time around, you'd never have noticed. If you plan for this to be extendable, it'd be worth creating a "helper" class that lets you create the results and their message strings like a recipe. [cope]public class RandomWhatever { public ItemStack theStack; public string message; //create these once, store somewhere, reference later public RandomWhatever(ItemStack stack, string msg) { theStack = stack; message = msg; } } Then you can store them in an array, randomly select one, clone the item stack and alert the player with the string, no weird lookups, equivalence checks, if-else blocks, or switch stack.

And we don't have time to have you ignore what we tell you three times. You know, like this bit: That was pointed out to you at least twice, this is not a surprise revelation.

Your update function still bypasses the change that doesn't get tracked on the client, on the client.

You might be able to squeeze a new property into the last metadata bit (that BlockCrops doesn't use) so that the AGE property in BlockCrops is used and evaluated as the game expects, but you can do a secondary detection for "AGE=7" and set your extra bool flag and set AGE back to 0. That would make the game thing Everything is Fine, but let you have the full 16 states for age.

This should be done in the rendering side of things. You manually check what blocks are next to the one being drawn in order to decide how to draw it. Look at how the fence rendering code works. (Also: update to 1.9)

Items in a player's hand don't do anything special to stay in their hand as the player rotates. That's all handled by the GL calls. Namely, GL rotates the context, then draws the player and their equipment. All of the trig is hidden away from you. *Digs out some code from a project he's currently working on.* You'll have to convert some stuff, but the math is here. //SpecialBulletLogic is an XML based parameterized system that drive various aspects, should be apparent what things do public void MeleeShot_UpdatePosition() { double distance = this.SpecialBulletLogicOffsetFromFiringEntity; //how far from parent's center; double angle = 0; if(this.SpecialBulletLogic.RotatesAroundFiringEntity) { //you want this angle = MathHelper.SafeAngleAddRadians(angle, this.SpecialBulletLogic.ParentBullet.CurrentAngleRadians); //add parent's angle } Vector2 effectiveOffset = Vector2.zero; if(distance != 0) { //calculate rotated offsets effectiveOffset.x = (float)(distance * Math.Cos(angle)); effectiveOffset.y = (float)(distance * Math.Sin(angle)); } Vector2 newLocation = this.SpecialBulletLogic.ParentBullet.WorldLocation; newLocation.x += effectiveOffset.x; newLocation.y += effectiveOffset.y; this.SetWorldLocation(newLocation); }