Jay Avery

All asset paths and filenames must be completely lowercase.

Do you have a model file at this location?

Oh, my mistake - I misread your initial post. No, it's not the tag that's null, (even if that was possible, it wouldn't be causing an NPE at that line). The source of the exception is that attachedEntity is null there. Think about it - when your entity is being loaded, nothing has set attachedEntity to be anything other than null, so there's nothing there to deserialize. I think you'll need to store the type of attached entity in your own NBT, then reconstruct it before calling deserializeNBT on it (something like storing the entity ID or name and then getting the class from the registry? not sure of the precise way to achieve that). Edit: actually, constructing the attached entity yourself isn't the solution either, because that will make a new instance while the original attached entity gets reloaded by the game itself, so I think it would cause duplication. Something like getting the attached entity by its UUID?

The error is now at a different line, one that isn't surrounded by a null check.

Do you mean it still gives you the exact same exception at the exact same line? Because that seems impossible.

I'd like to make a TESR with a model which can be varied depending on the TESR's state when the model is constructed. Not things like animation which change over time, but the actual model parts and boxes. Obviously I could just make multiple possible TE classes with their own corresponding TESRs, but I'd like to be able to create the variations in the code rather than manually. The trouble is, the TESR doesn't have a normal constructor (the sort of place where I could access a TE parameter and customise the model accordingly). The best thing I can think of is to store something like an 'isInitalised' boolean and then, on the first tick where it's not initialised, construct the model based on the TE parameter in renderTileEntityAt. But this seems kind of hacky and like it might cause other problems. I can't find any kind of initialisation method in the TESR, but I'm hopeful that I might be missing something. Or if I'm not, then does my above idea seem plausible, or terrible? For context, I'm working on falling trees. My current plan is to create an invisible TE when the tree is cut. This TE will check and store the size and shape of the tree, then the TESR's model would be based on that information, and be animated as if falling. So there are countless possible variations in tree shape, and I'd like to be able to make the model procedurally rather than manually - but once the model is made it doesn't change.

You can also use MathHelper.rgb, which takes the three colour values and converts them into a hex colour int.

Yes, all of that is possible! Item#showDurabilityBar checks whether the bar should display (you probably just want to override it to return true). Item#getDurabilityForDisplay defines how much of the bar should be full (as a double between 0 and 1) - this is where you can read your custom NBT and convert it into the proportion of the bar to fill. Item#getRGBDurabilityForDisplay defines the colour of the filled part of the bar (as an int representing an RGB hex colour) - this is where you can set the colour according to your custom NBT.

All asset names must be entirely lower case in 1.11+. So this registry name: testItem = new item_TestItem("testItem", CreativeTabs.MATERIALS); is probably the reason it can't find your item model. For the block model problem, show your blockstates and model json files, your registration and model code, and the complete console output.

I thought you already found that marking the item renderer class as @SideOnly(Side.CLIENT) gets rid of the error? I don't understand why it is still a problem.

Where do you call the genInit() method? Is your runGenerator method actually getting called?

What is SelfStack, where are you getting that from? If you want to add information based on the NBT of the stack in question, you need to get the NBT from the stack in question - the one the method gives you.

Explain the problem: how is the item supposed to look, and what exactly is wrong with it. Post updated code if it has changed since last time.

The door item is the thing that places both blocks of the door - so yes, you need it and it is the solution to your problem.

Well, I have an update... but it's not good news. The crash happened again today, but with a difference. When it crashed, I restarted the server (as I've done previously) but the crash happened again immediately on reconnecting. Repeated this again and the same thing happened again. But then, I tried connecting with a different client (Mac instead of Windows, if that could possibly be relevant??) and the crash didn't happen. Back to the first (Windows) client, and reconnecting triggered the crash again. I didn't know it was even possible for a client to cause a server to crash, but that is definitely what seems to be happening. I thought the whole point of the server-client relationship was that the server is in control and the client is basically just receiving information and presenting it to the player?! And I can't think of anything different between the two clients other than the operating system - exact same version of the mod, forge, etc. I used the debug profiling thing and got the following debug report when the server crashed. I don't really know how to interpret anything useful from this but if anyone has insight:

Your bow_of_kindred_pulling_0.json has a syntax error - you are missing a closing brace at the end of the file.

The Forge docs has an introduction to using block properties - link. The vanilla crops class has a block property with 8 age values. Since you want your crop to only have three age values, you need to create a new property and then override all references to the vanilla property in the code so that the crop ages in the way you want it to.

Look at the age property.

The act of checking KeyBinding#isPressed changes its state to be no longer pressed. So all you need to do is use the event to check for keyBindSwapHands, and then you are essentially overriding the vanilla logic for that key.

The player inventory is just a field in the player class, so you can just access EntityPlayer#inventory to do whatever you want.

If you're using an old version because you don't like a new feature, your version is going to become increasingly outdated and eventually unsupported. You'd be much better off modifying the feature you don't like and staying up to date. Post your code. I don't understand the question. What do you want to achieve?

It's nothing to do with the material. It's a method in Block which you need to override. It'll be probably called something with the words "render layer" or similar. (While we're at it, I'll just remind you that 1.8 is old and very nearly outdated, and you'd get much better help if you work on 1.11+)

You need to override in your Block class the method that gets the layer the model is rendered in. In 1.11 it's Block#getRenderLayer and returns one from the BlockRenderLayer enum, but I don't know if it's different in older versions. Look at the vanilla code for glass blocks to see what's done there.

You've got the right idea about the different possible approaches available - the choice of which to use is up to you, and the precise details of what you want to do. I'm working on a mod which changes a lot of vanilla behaviour and I've done a lot of creating new separate versions of things to replace the vanilla versions. It's good for enabling complete control over features, but the downside is the potential for compatibility issues - what happens if someone uses the vanilla version instead? In my case I've mostly made vanilla features unavailable in survival (by removing recipes etc), which is neat but comes with more of its own downsides too. But it sounds like you're already thinking about that, and access to the vanilla version won't necessarily be a problem for your case so it sounds like a good option.

So far, the crash has happened three times, and it's been the same stack trace each time. The AABB is the same size as a vanilla falling block entity (0.98x0.98), so nothing extreme. And again, if that was the problem - wouldn't the crash (or at least very severe lag) happen any time the entity is spawned or moved? I just tried to step through the method in the debugger but the server shut down because it thought it was crashed. Is there an easy workaround for that?