Draco18s

Actually it would be: }, "variants": { "variant": { "oak": { "model": "oak_planks" "textures": { "texture": "blocks/planks_oak" } }, The variant name (in this case "variant" because of the string passed to PropertyEnum.<BlockPlanks.EnumType>create("variant", BlockPlanks.EnumType.class); ) creates a block, inside which you list all the variants associated with it. Notice how "mossy" had a top-level block that contained both "true" and "false." Of course, you should give your variant a better than than "variant" such as "wood_type." I've got a two-property example here: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderores/blockstates/axel.json Though my enums are set up differently. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/blockproperties/Props.java#L70 IMetaLookup being a custom interface to supply cleaner meta->enum and enum->meta conversions (there is no need for a META_LOOKUP array: Enum.values() already exists, as well as Enum#ordinal()

Aaah, that's what that is. Alright. I do agree that it's cleaner alright! Didn't work for me cause I'm on Java 7 still, not 8, so it doesn't have that feature (ditto lambdas).

Step 1: Extend EntityMinecart Step 2: Register it as normal Step 3: Register a renderer for it as normal

Does not appear that your workspace was set up correctly.

Or a lambda. Or a method reference (which gives the cleanest code I think). How does the method reference version look? I had a devil of a time constructing the anonymous class correctly (and then felt like an idiot afterwards).

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.