jeffryfisher

In my rusty old Win-XP system, my Minecraft logs are in: C:\Documents and Settings\<user name>\Application Data\.minecraft\logs Did you check for mismatched capitalization? Try all lower-case.

I now recall a specific gotcha: In Eclipse, assets are accessed via the OS. Windoze is case-insensitive, so it will forgive case mismatches. In a Minecraft install, assets are accessed from within a jar file. Domains and possibly file names are case-sensitive. This is where mixed-case mismatches start to cause problems. I think that vanilla Minecraft also changes some strings to lower-case, so at least Mod names and domain names should be all lower-case everywhere. I'm not sure about folder- and file-names, but to be safe, it is best to keep them lower-case also. If I hit the nail on the head, please click the Thank-You!

You need to tell us which version you're using. It may also help to post a log file (not console output), because the log may show warnings not printed to the console. In fact, if you haven't already done so, read the client log in case it has something you can work from on your own steam.

If I understand his mod, he has made a new painting texture (one big collage that contains a whole set of paintings), and he has patterned it so that his paintings occupy the same tiles within the new painting file as vanilla paintings occupy within the vanilla painting file. He hopes that all of the vanilla machinery will then pick up his paintings when he manages to get his image file used in place of the vanilla file. In vanilla's entity painting code, the enum is chosen randomly (in a constructor) from among those that can fit where placed. When reloading from a save, an NBT tag gives a painting name which is then used to look up the corresponding enum (different constructor). NOTE: In late 1.7.10 and early 1.8 versions, vanilla has a bug that muffs the centering during that placement. I think the problem is coaxing the render manager to use the custom renderer. If the renderer is registered, then maybe vanilla has an annoying assumption built in somewhere that must be defeated. Find where vanilla decides what renderer to call.

Aha, that new default behavior frustrated one of my recent mods too. Your TE class needs to override a method: @Override public boolean shouldRefresh(World w, BlockPos pos, IBlockState oldState, IBlockState newState) { ... } Be sure that it returns true when a refresh is really in order, otherwise you could leave stale TE's in the world. Look at the super to see what I mean.

Should this be moved to the bug reports forum?

You didn't post code with an item mesher call, so I am assuming that you forgot it. Item textures in 1.8 need to be "meshed" in your client proxy's init method. Search for a tut on the mesher and add a proxy with a mesher call. Also, don't be so sure that you got no error message. Not all errors go to the console. Some only show in the log file, which you need to find in your project. That's why so many experts here specifically ask for logs, not console output. If you still have a problem, please post/link your "perfect" code and json files.

Oh lovely -- I recently wrote a mod using that list-box interface in Forge build 1450, so it will need to change when I move to the next recommended build (which I can now see at 1563). Thanks for the warning. I thought it an odd dependency at the time, so I like the change.

You're almost certainly calling the mesher at the wrong time/place. It is client-only and not available during pre-init, so put it in client proxy's init method. As a general rule, everything pertaining to graphic and sound rendering is client-only. Also, many null-pointer errors come from misplaced calls (trying to use something before it exists, or trying to use something from a pointer that was initialized before the object existed). Whenever asking for help with a null-pointer, always provide the stack trace inside a code or spoiler element in your OP, and always include enough source code that all relevant fields' initializations can be seen. Finally, search for problems like your own before posting. The site's own search produces haystacks, so try Google or your own favorite to search from outside. You'll find many examples of mesher null-pointers and d7's advice.

In getItemDropped, return new ItemStack(Blocks.sand,1,1).getItem(); ...Looks like it will drop a simple Blocks.sand. Your "new ItemStack" is wasted and does not need to be there. In damageDropped, your tier zero always drops damage zero (default sand). I think you need to teach it to drop damage 1 for red sand (and any other damage variant for any other base block having subtypes).

Aha, so we can declare a unique instance of a handler class and pass it to every bus that will accept it.

I suggest looking / posting in the bug reports forum. Give more details on the manner in which vanilla armor texture failed but had no error. I don't know what that means. How did you know it failed if you didn't see an error?

Have you stepped through the TileEntity's two NBT methods? See what it is writing and then reading.

You will need to show us your error message(s), your blockstates.json and your block's class (at least).

Even after figuring the data storage, you'll need to solve the placement problem. How will you control the secondary rotation? Perhaps right-clicks on an already-placed block can rotate it around its facing axis. It might actually be less work to make four different blocks.

Indeed there is at least one vanilla bug (I know of one client-side) that makes some calls to blocks during the breaking of a block but *after* the block has been replaced by air in the world. If any method in the resulting stack tries to get its block's properties (vanilla ones don't happen to do so), then an exception is raised. It is possible that the call to isAir() is trying to protect some other code from just this problem, and your override using state info raised the very exception that the caller was trying to avoid. As you found, you must preface the getProperties call with a check for actual air (instanceof) and then return true (or see what block is really there and call isAir on it if it's not yours). Several of us have had to do likewise in custom getHardness methods in blocks with subtypes having variable hardness.

If I understand your 24 states: 1) I can choose one of six faces to face me 2) I can then reach out, grip that face and dial it to choose one of its four adjacent faces to face UP. If I were holding a face with an arrow printed on it, I could point the arrow UP, RIGHT, DOWN or LEFT. If your game purpose really needs to retain all of that information, then you do indeed have more states than can be kept in metadata. You'll need a TE as d7 suggested. If game effect really only hinges on one face (or allows you to calculate some of your data from neighbors like walls and fences do), then you can avoid the TE. If calculable, getActualState is where you'd do so. What are you trying to do?

I don't think your proxy is being called from anywhere. Also, you don't appear to have a main mod class with the @Mod annotation, and I don't see a sided-proxy annotation anywhere either. Finally, when a server spawns a hanging entity in the world, it sends a message to the client, which then uses a different constructor to make its hanging entity client-side. You should walk that process in the debugger to see if there's a gotcha in vanilla's handling of the message. It might assume that it knows all possible types of hanging entities, so it might construct a vanilla painting client-side. It may turn out that you need a spawn callback to call the right constructor on the right class (implements Function<EntitySpawnMessage, Entity> ). In that case, add "implements IEntityAdditionalSpawnData" to your entity class.

All I see is a potential crash bug: If your hardness varies with state, then getHardness should test if the Block at pos is still your block trying to get properties. (There's a client-side bug in 1.8 that calls getHardness one more time while destroying a block -- *after* the block has been turned into air). It's possible that LexManos just fixed it in a recent build, but then you may be up against consequences of doing destroy block in a new order.

I don't see a client proxy with a (client side-only) renderer registration. You probably need something like this to bind your renderer to your entityPainting extended class: RenderingRegistry.registerEntityRenderingHandler (classAltEntityPainting.class, new classRenderAltPainting ()); Otherwise, MC will probably detect that it is an instance of EntityPainting and use the vanilla renderer. Have you set a break point and stepped through rendering in the debugger? Do you know if your renderer was ever called?

That, and one of my sounds extends the side-only PositionedSound class in order to create a repeatable, continuous sound (I was told to imitate the minecart). PositionedSound is essentially a renderer for sound. I'm glad I only needed to set a couple predefined fields. After taking a peek lower down, I hope I never feel a need to dive in. Someday, in a perfect future, the World class will have a method for starting a continuous sound by passing in its resource name and the TileEntity (containing position) to which it is anchored. Vanilla code and its messaging will take care of the rest.

That reflective class loading "crap" is only what @SidedProxy does in the background for common/client proxies. It was even crappier in an earlier version that had a BlockPos parameter in the constructor. I'll look into the distinction between "side" and "isRemote". I've seen it mentioned in many threads, so it must be a common cause of confusion. I'm already planning an upgrade to my abstract mod classes, so I'll see about adding a generalized method to start playing a custom PositionedSound.

Try my idea to override Item.getDamage() in your single-use item or tool class and let us know what happens.

OK, Eclipse's fiction (and error message) must have tricked me. Some time ago I tried to simply bracket my sided method calls so they'd only execute on the correct side, but their mere presence caused problems when loading. That means that the "world is remote" suggestion (someone else's) was not sufficient. That... sounds like a horrible "proxy setup" whatever that may be, if you cannot easily add to it... It's actually quite useful for giving me a great head start on each mod. The things needed in every mod are already written, so I can jump ahead to the "meat" of each mod. It's also not the source of my problem, so I won't belabor it. You actually hit the nail on the head by noticing that it was the client-side TE that wasn't registered. When I registered that class on the client using the same string used with the server class on the server side, the tile entities worked as intended. Thanks. This is what my TE handling ended up being: BlockBlower.createNewTileEntity: public class BlockBlower extends BlockDirectional implements ITileEntityProvider { <snip> @Override public TileEntity createNewTileEntity(World worldIn, int meta) { BlowerTE te; // TE needed to hold continuous (whirring) positioned sound // Consequently, TE's purpose is to emit *all* block sounds if (JRFmod.side.isServer ()) { // TE follows pattern of proxy common/client te = new BlowerTE (); } else { // client-side ClassLoader mcl = Loader.instance ().getModClassLoader (); try { // Reflection Class c = Class.forName (InventionsMod.MODID + ".BlowerTEClient", true, mcl); te = (BlowerTE) c.newInstance (); } catch (Exception e) { System.out.println ("BlockBlower failed to instantiate its Client TE because " + e.toString ()); throw new LoaderException (e); } } return te; } } Server (common) tile entity: public class BlowerTE extends TileEntity { protected static final String mod = InventionsMod.MODID; protected float speed = 0.0f; // float used as pitch // public BlowerTE() {} public void setPos(BlockPos pos) { // Vanilla calls immediately after construction super.setPos (pos); // Set TE pos this.pos.add (0.5f, 0.5f, 0.5f); // Our purpose is sound, so center the floats } protected void playSFX(World w, String sndName) { w.playSoundEffect (pos.getX (), pos.getY (), pos.getZ (), mod + ':' + sndName, 1.0f, this.speed); } public void setSpeed(int speed) { this.speed = speed; // Integer converts to float } public void pwrUp(World w, int speed) { this.setSpeed (speed); // First set speed playSFX (w, "fanPwrUp"); // Then play extra sound effect } public void pwrDn(World w) { playSFX (w, "fanPwrDn"); // Sound this.setSpeed (0); // then zero } public void choke(World w) { playSFX (w, "fanChoke"); // First play sound this.pwrDn (w); // Then power down } @Override public void writeToNBT(NBTTagCompound compound) { super.writeToNBT (compound); compound.setFloat ("speed", speed); } @Override public void readFromNBT(NBTTagCompound compound) { super.readFromNBT (compound); this.speed = compound.getFloat ("speed"); } } Client tile entity: @SideOnly(Side.CLIENT) public class BlowerTEClient extends BlowerTE { // protected WorldClient w; static final SoundHandler sh = Minecraft.getMinecraft ().getSoundHandler (); private final PositionedSoundFan snd; private boolean playing = false; public BlowerTEClient() { snd = new PositionedSoundFan (this); // Snd holds "this" to follow speed changes and eventual removal } public void setPos(BlockPos pos) { // Vanilla calls immediately after construction super.setPos (pos); // Set TE pos snd.setPos (); // Sound copies TE position if (!playing) { sh.playSound (snd); // Activate our tickable sound (at pos), which will update itself snd.update (); // Immediately adjust to fan speed playing = true; } } }

Ah yes... It is called if one uses drag-drop to pull an item off a result slot and drop it in an inventory slot. If one instead uses shift-click to teleport the item-stack, then the event gets bypassed (or it did last time I checked). I don't know if that's a Forge bug or a Minecraft "feature", but it has affected some of my mods' achievements enough to warrant comments in their descriptions at CurseForge. Try overriding Item.getDamage() to lie about how damaged the item is. If maxDamage is 1, then always return 2. That'll always put the amount of damage above max, destroying the item when checked (which is after hitting/breaking something). Then not even an unbreak enchantment will save it.