Draco18s

Movement is calculated both client side and server side, provided that the mobs are making the same decisions. Why? Because the server is in control, but the update frequency and packet delay results in laggy, disjointed movement. So it's calculated on the client too for interpolation.

No clue.

Look at the furnace.

Have you tried just dealing the player 1000 unresistable damage instead? (check the DamageSource class for types that will fit your needs, or make a new one!)

Yeah, if you look at the OreDictionary class you can find out what recipes from Vanilla have been dict'd. There's a few cobblestone items last I checked that weren't as well (cobblestone wall, cobblestone stairs).

I don't see how the changes enacted upon 1.8 and 1.9 have changed how Multiblock structures are detected and formed. Nor why getBlockLayer and getRenderType are relevant.

Thought so. http://www.minecraftforge.net/forum/index.php/topic,39374.msg207312.html#msg207312

Registering an ore like that means that your item "counts as" whatever oredict name you used. Let's say "ingotIron" Now all mods that use Shaped/ShapelessOreRecipes that use ingots of iron in them will work with your item. Vanilla recipes should also work because Forge should be replacing the vanilla recipes for the more common ingredients itself (that is: "stone" "planks" "iron" and "gold"; that's what was going on when I peeked into the OreDict last). However, I am not 100% on this because of what Lex said. You'll have to figure that out for yourself. What I think he was referring to was a system that let people go "find me recipes that use/result in [item] so I can replace them with oredict recipes." And people were fucking with other modder's recipes that way.

setRegistryName take in a NAME not a resource location.

You are going to have a lot of problems making this work, sadly.

Post the loot table JSON

GameRegistry.addRecipe(new ShapedOreRecipe(new ItemStack(blockSifter), true, new Object[] {"PBP","PbP", 'b', Items.bucket, 'P', "plankWood", 'B', Blocks.iron_bars})); (Huh, even I know that new Object[]{} isn't actually needed due to the syntatic sugar of varargs... and I still ended up with it in my own code in a few places. Lets clean that up...) GameRegistry.addRecipe(new ShapedOreRecipe(new ItemStack(blockSifter), true, "PiP","PbP", 'b', Items.bucket, 'P', "plankWood", 'i', Blocks.iron_bars)); Notice how the planks are a string while the other two are specific item/block references. Here's another, no specific items. GameRegistry.addRecipe(new ShapedOreRecipe(new ItemStack(blockMill,9), true, "SSS","SWS","SSS", 'S', "stone", 'W', "logWood")); Do note that the output must be a specific item. You can't have an oredict result (e.g. new ShapedOreRecipe("stone",...) ). Best bet in that case (say, you're crafting bronze ingots) is to just use your own mod's version and make sure that it's been registered with the ore dictionary.

It's the same flag list as world.setBlock You generally want flag 3 (combination of flags 1 and 2, but not 4)

Capabilities and stuff like this: https://github.com/Draco18s/Artifacts/tree/master/main/java/com/draco18s/artifacts/components

Sorta. Looking Glass works across dimensions, too, which isn't possible with just a basic stand in (the client only knows about 1 World).

http://www.minecraftskins.com/

Fix it first.

You have two event handlers that interact with one another. That's actually crucial to keep in the same handler class. I could probably split mine up into a couple of classes. But I've got...actually quite a few events in that class that all deal with the same data. TickEvent.ClientTickEvent and TickEvent.WorldTickEvent are the two big ones. SpecialBlockEvent.BlockUpdateEvent actually splits into three different methods (depending on what type of block fired it) all of which then again refer to the same data that the tick events handle. So that'd be one split. Then the EntityJoinWorldEvent, EntityEvent.EntityConstructing, LivingUpdateEvent, LivingDropsEvent, EntityAnimalInteractEvent.AnimalLoveEvent, and EntityAnimalInteractEvent.CowMilkEvent all deal with living entities and various interactions therein. Second split. Then I've got ChunkDataEvent.Load, ChunkEvent.Unload, CogOreGenEvent, ChunkDataEvent.Save that all then invoke another static class (same one). Only event left after that is ItemExpireEvent, which is kind of related to what the chunk events do. So third split. *Shrugs* Eclipse's outline view makes it easy to find stuff though, so I'm not bothered by it.

Its amazing what your IDE can do. Try hovering over those methods and clicking on the tooltips.

You might want to take a look at what Looking Glass does https://github.com/XCompWiz/LookingGlass

Only if you knew when to stop applying the damage.

Don't check every tick. Only check when your block gets a neighborChanged update

Make a class that implements IRecipe. Let your IDE auto-implement stub methods for the interface. Look at the name of each stub and its return type. Write those methods to do what you want them to.

Put both events in the same class. Which, by the way, is badly named. What you have is an event handler class, not an event class. You can have as many event handler methods in the same class as you want. Some of my handler classes are huge.

Everything. Registry name is how the block/item is keyed into the block or item registry Registry name is how the block/item's renderer is keyed into the rendering registry Registry name is used to set the unlocalized name Registry name never changes Registry name is used to reference textures Registry name is models