Draco18s

Apologies, I checked the timestamps and missed the date part.

These are different fields, they don't refer to the same ones at all. Whatever you think you've done with these fields you have in fact, not done. Your problem though is the fact that you never initialize burnTimeInitial to anything. You helpfully check to see if it's not null and print "yep, it's not null!" but it is null, so the program crashes.

If you don't want skeletons to burn during daylight, you need to subscribe to the right event and replace the entity spawned with your own custom one.

1) Don't bump your thread after only an hour. 2) Don't put block rendering registration in common code: it will crash the dedicated server 3) Take a look at my client proxy.

You can also do it as an anonymous class. RenderingRegistry.registerEntityRenderingHandler(Entity.class, new IRenderFactory<CustomModEntity> { @Override public Render<? super CustomModENtity> createRenderFor(RenderManager manager) { return null; } });

The forge marker makes it use the Forge model loader, which does variants much more nicely than vanilla.

FWIW, a mod build on 1.9.4 will run on 1.10.2 and vice versa, unless it uses a feature introduced to Forge more recently. 99.99% of all mods work on both, so build your mod on 1.10.2

I doubt that's even a valid version set string. It's supposed to be "[earliest],[latest]" and you have, not only 3 values there (instead of 2) but you're missing a [ on one of them.

Modeling programs can't be 100% sure which parent model you want to use. The reason it "breaks" using a different parent is that Mojang made the "north" direction (the default "front" side) pointing up-left (and thus not visible) and then special-cased the rotation for the orientable blocks. It's "better" now with the parent system because the "block/orientable" includes the special-case rotation, but it's still annoying.

for(Item weapon_ : ItemRegistry.buffPairs.keySet()) { weapon = weapon_; armor = ItemRegistry.buffPairs.get(weapon); if(player.getHeldItemMainhand().getItem() == weapon) { Uh. Why are you setting the active weapon to the weapon_ keyvalue before checking if the player is actually wielding it?

You can't because OpenGL isn't baked.

By the way, this line: private static final VDraw_furnace_smelting VDraw_furnace_smelting = new VDraw_furnace_smelting(); Can you please change that to: private static final VDraw_furnace_smelting instance = new VDraw_furnace_smelting(); Having the instance name and the class name match, including case, is a recipe for disaster.

By the way you can also get a logger from the FML events: logger = event.getModLog();

Using metadata for related blocks is fine. Vanilla stone (diorite, etc.) and wool (red, blue, green...) are both perfect examples of using metadata for defining the "variants." The point is, even if the end user considers them different blocks, you as a coder give no fucks.

Note that this also means that in multiplayer if one player does "the thing" then every player gets the benefit.

Fire is just an animated texture, any icon can be animated, just google how to create them.

Create a class. Put a private, static, HashMap<ItemStack,ItemStack> in it Create a public method to insert into this map and a public method to retrieve from it. Go look at what Furnace Recipes does.

Mcrayfish doesn't limit the texture size no but it does treat all textures as if they were 16x16. If you import a 32x32 texture and want and odd number of pixels, you're SOL.

Basically: if the equipped slot changes if the item (ItemStack#getItem) in the slot changes or if the item metadata changes (most likely you still want this) The base implementation checks all of those and if any NBT changes were made (you're wanting to ignore this).

Your problem lies in the fact that your main mod class names are the same and the @Instance annotation is not supplied with a string value of the mod ID: @Instance public static Main instance = new Main(); @Instance public static Main instance = new Main(); Forge doesn't know which one of these is which. Use @Instance(value = MODIDELEC) and @Instance(value = MODIDCOWCORE2) By the way do not instantiate your own main class: that's what the @Instance annotation is for.

Which part are you having trouble with? Making a block? Making a TE? Or making the class that saves all the recipes and gets their results?

Couple things I'm seeing that aren't related to your problem, but you should change anyway: 1) Use of Minecraft.getMinecraft() in common code (this will crash the dedicated server). This is why the proxy system exists. 2) Use of getItemModelMesher() you should be using ModelLoader.setCustomModelResourceLocation() instead (called during preInit only!) 3) Use removedByPlayer() instead of breakBlock(). removedByPlayer() is called before the block is actually set to air, avoiding problems of trying to get a blockstate from air (actually it is set to air by the base implementation of removedByPlayer(), so remember to call super). 4) Do not implement ITileEntityProvider, the methods it "supplies" are already part of the Block class (the interface is not used anymore) JSON changes: 5) You don't want parent:"block/cube_all" if you're going to specify sides. Use parent:"block/cube". cube_all is to specify a single texture to use for all six sides + particle (e.g. stone, wool, planks). 6) You can simplify your blockstate variants, specifying the model once (you can put textures here too, this way the variant overrides the default and different variants can supply different and possibly combinatorial differences): { "defaults": { "model": "arborcraft:cardboard_box" } "variants": { "normal" : { }, "inventory" : { } } }

This is a "bug" in Eclipse. Simply click on anything in the Project Explorer again and it'll be fine. Alternatively you can edit your project's run directory to be a hardlinked rather than a programatic one. It's annoying as fuck and only occurs because of the bug and how Forge's setup points Eclipse at the run directory. Go to the Run Configurations window, find the "Arguments" tab and at the bottom, change the working directory from ${project_loc} to ${workspace_loc:MDKExample}\run

That's because it's specified in the blockstate file, not the model. Eg: { "forge_marker": 1, "defaults": { "textures": { "particle": "blocks/planks_oak" }, "model": "harderores:sifter", "uvlock": false }, "variants": { "normal": [{ }], "inventory": [{ }] } }

public int getCheckSum() { return "0xF239AFB520983D20978C290FC9"; //hax }