jeffryfisher

I'm using 1.7.10, not 1.8, so getCombinedLight and BlockPos aren't defined. What's the equivalent call in 1.7.10? Ooops, sorry I forgot about version difference. Hold my suggestion for when you make your v1.8 edition of your mod. Glad you found your execution order bug and could fix it.

You're not the only one. You can go a long way by reading past threads in this forum. I find that Google will turn up relevant threads more often than the site's own search. I recommend at least 16 hours of reading before posting new threads. Someday the items might break jsons into itemstates and models the same way that blocks already have blockstates and models. For now though, blocks are organized differently. The blockstates file tells which block model file to use for each combination of states. Therefore, a single block type can have several models (e.g. walls changing shape depending on attachments). Therefore, your question about whether something should be set inside model/block may be a nonsequitur. The vanilla rules for blockstates required an exhaustive Cartesian product of all values of all states. Fortunately, Forge offers us mortals an advanced blockstates format. For cowards like me who simply put new skins on existing models, it is sometimes possible to put all of my mod info into my blockstates file and not even have model files (I can get away with referring to vanilla ones).

You appear to be getting only sky light. My renderer has this in its fixLightLevel method: int l = this.renderManager.worldObj.getCombinedLight (new BlockPos (i, j, k), 0); int i1 = l % 65536; int j1 = l / 65536; OpenGlHelper.setLightmapTextureCoords (OpenGlHelper.lightmapTexUnit, (float) i1, (float) j1); GL11.glColor3f (1.0F, 1.0F, 1.0F); "Combined" light works for me.

Have you tried to override ItemTool.getStrVsBlock()?

In other words, the empty method should be in common, and the register call should be in client's override. Another note: I'd discourage you from naming a class as "Items" (or "Blocks" for that matter). If you duplicate class names from vanilla Minecraft, then your code could be confusing, and referring to the vanilla class someday (e.g. when you write recipes) would be awkward.

No need for a crash report. I ran into this one myself last week. Vanilla Minecraft has a bug on the client side that calls getHardness *after* breaking a block (it's doing some stat calculation the wrong way). By that time, the block has already been replaced by air. Therefore, whenever *anyone* wants a block's effective mining hardness to vary according to metadata, the getHardness function must test for air and give the default hardness if that's so. Proceed with fetching metadata only if your own block type is still at pos. Here's my Override: @Override public float getBlockHardness (World w, BlockPos pos) { float default_h = super.blockHardness; IBlockState bs = w.getBlockState (pos); // Vanilla code has a client side bug boolean alreadyBroken = (bs.getBlock () == Blocks.air); if (alreadyBroken) return default_h; // Check for vanilla code bug and escape before... switch (this.getMetaFromState (bs)) { // This would crash client-side after player breaks the wall case 8: return 5.0F; // Iron wall case 9: // Red Sandstone case 10: // Chiseled Red Sandstone case 11: // Glass case 12: // Glowstone case 13: // Sea-lantern return 1.0F; case 14: case 15: return 3.0F; // diamond & emerald default: return default_h; } } PS: I tried to report the bug to Mojang, but because none of the vanilla block types fall into the trap (yet), Mojang deleted the report instead of leaving a note to fix it when convenient. They'll suffer later, probably when it's *not* convenient.

If your only purpose is to generate a visual effect like particles (ooh, pretty), then the server does not even need to do the calculation. As for combined light level: public interface IBlockAccess { <snip> @SideOnly(Side.CLIENT) int getCombinedLight(BlockPos pos, int p_175626_2_); Class world implements this interface, so your worldObj probably offers it, but only on the client side where you probably need it. BTW, There's also an "isDaytime()" method based on light that can actually return false during a heavy thunderstorm (that's when I turned to modulus of time rather than relying on light).

Since all of my recipes are registered in my init method, not preinit, my guess is that preinit is too early in some cases. Of course, it would help if you told us what pointer was null at what line of what file.

Code from 1.7 needs major overhauling before you have something that will work in 1.8. There are many threads here that already answer the issues you're displaying. However, they can be difficult to find using the site's own search (it tends to turn up massive logs). Try to Google as much as you can about: Minecraft Forge "1.8"... 1) + blockstates 2) + tesselator 3) + mesher And be ready to do the common and client proxies... they're now essential to all mods with items (including nearly all blocks, because they can drop or appear in inventory as items. Finally, read about Forge's advanced blockstate format.

You might try to capture a mining event: import net.minecraftforge.event.entity.player.PlayerEvent.BreakSpeed; import net.minecraftforge.fml.common.eventhandler.SubscribeEvent; <snip> @SubscribeEvent public void onHitting(BreakSpeed e) { <snip> e.newSpeed = 0.0F; }

Your OP is too vague, and you give too little info. Show us your source code. Tell us what steps you used to exercise it. When you say "it didn't appear at all", do you mean it's not in the creative menu, or did you try to craft the item and fail that too? I recommend that you add some print statements to your code to better inform you, and then walk your critical paths in the debugger. Post again (with source code) when you get stuck again and can tell us more.

If you dropped a block with an undefined damage value, then there should have been at least a warning in your log, something about being unable to find the model or texture for that block type and variant. I'm actually surprised that you didn't start getting mossy cobble. How it managed to stack with normal cobble is a mystery. Glad you found bug. If you walked the execution in the debugger, it dragged you right through that problem method. That's one of the nice things about debuggers. They take you from the method you're thinking about to the other methods you didn't know you should think about.

Are you sure that the 2nd variant is actually calling that method? I am suspecting that your problem is elsewhere in your code. I recommend setting a breakpoint in that method and running in the debugger to see what it's really doing when you smash variant 2.

Another factor in copyright: Distribution 1) If you don't distribute your mod, then you'd just be playing your own (supposedly) licensed music to yourself. There shouldn't be any violation there unless you crack some digital security to extract it (a separate issue). 2) How hard would it be for someone to download your mod's jar file and then insert his/her own mp3 files into it? If the instructions are not too difficult, then you could distribute your mod with no music included. You'd just need to explain in the installation instructions how a player could copy (supposedly legal) mp3 files into the right locations (with the right file names) within the jar file in order to be picked up by your mod. You'd probably also want your mod to handle missing files gracefully (or carry public-domain place-holder mp3s that an end user would replace).

Since the cfg environment is slightly hostile toward normal recipe formulation, you'll just need to impose a restriction on recipes entered this way. Set aside one character to be translated into a space internally, and tell users to never use that character to represent an ingredient. Zero is a good place-holder. See if numeral '0' (zero) will work.

What happens if you use quotes (single or double) to demarcate your recipe strings inside the cfg file?

Indeed... Inside the ItemSeedRod constructor, after setting unlocalized name. Where the register function needs an item, pass in "this", the constructor's way of referring to it's own new instance.

You might instead test for instanceof BlockLiquid, but see what that does with ice. Checking instanceof might help your mod work with other mods that introduce their own liquids.

If you hold off the array assignment until inside your preInit method, then you can have the seedRod constructor do its own registration for each instance. It's the style I use for my items and blocks, but it's a matter of taste (other people love initializers). YMMV.

Just fire up the game, use creative mode to put your suspect items into a crafting table, and viola! The result will appear in the result slot. If nothing appears, then it's safe to incorporate that recipe into your mod (until some other mod collides with yours). Or were you asking a different question?

Have you passed all of your json code through an analyzer? I use a website called jsonlint.

If you're willing to let something be shaped like a vanilla object, then you often don't even need to copy its model. See if it uses a parent independent of texture. If so, then you can refer to the same and put your own texture(s) on it.

Aha... 1.9 is a major mod that probably won't treat existing worlds too kindly, and since Mojang probably won't backport the fix into a 1.8.9 patch, I decided that a work-around for 1.8 was needed. I came up with this simple hangingPosition dodge, which overrides onValidSurface but still calls super: public class classAltPainting extends EntityPainting { protected static final boolean MCVERSION_IS_1_8 = Loader.instance ().getMCVersionString ().contains ("1.8"); static final int[] tilesOff = { -1, 0, 0, 1, 1, 2 }; // Number of rows/cols left or below target // (precalculate based on tile width or height, with invalid value at zero) <snip> /** * There's a bug in vanilla MC version 1.8. EntityHanging.onValidSurface() scans up and right from hanging position, * forgetting that the pos is supposed to be the *center*. Thus the bounding box and checked surface diverge * * Fortunately, our bounding box has already been calculated correctly before entering this method. Therefore, we * can workaround the bug by temporarily setting hangingPosition to the LL corner (telling a lie), then calling super, * and then finally setting hangingPosition back to its canonical value. * * Called both by Entity.onUpdate (every 100 ticks) and by classItemAltPainting.onItemUse */ @Override public boolean onValidSurface() { // TODO: Remove in 1.9 BlockPos pos = this.hangingPosition; // The real pos boolean result; if (MCVERSION_IS_1_ { this.hangingPosition = pos.offset (this.field_174860_b.rotateY (), tilesOff[canvas.sizeX / 16]) // Tile-cols left of placement .offset (EnumFacing.DOWN, tilesOff[canvas.sizeY / 16]); // Tile-rows below placement } else { System.out.println ("TODO: Delete classAltPainting.onValidSurface method for MC-1.9"); } result = super.onValidSurface (); if (MCVERSION_IS_1_ { this.hangingPosition = pos; // Restore correct pos } return result; }

I don't think your shapeless recipe is quite right. Your output stack doesn't have a '2' quantity. Am I missing where the itemm input is not consumed? Also see this earlier thread about recipes to change damage instead of consuming an input.

One model file has this: "parent": "mymodname:model/treasure_block" Maybe the word "model" doesn't belong there? Maybe the word "block" does? Also, a failure to load referenced content can mean that your directory structure is off. Your model file should be in ...assets\mymodname\models\block It's easy to get pluralization wrong (model vs models, block vs blocks), so look carefully.