V0idWa1k3r

You still have the same issue. Upon deserialization your EnergyManager from NBT you set the energy to 0 as the capacity is 0(as you initiate the container field to have 0 capacity in the parameterless constructor). Then after you are done setting the energy to capacity(which is 0) you read the capacity. The deserialization order is mixed.

Well, post your new code then. Your EnergyManager will set the energy to capacity shall the energy be less than capacity and capacity is 0 by default. You used to initialize the capacity in your constructor based on the parameters but you can't do that in the parameterless constructor as there are no parameters present, duh. You only need to serialize enough data to be able to successfully create an identical object upon deserialization. Yes, the block does. The TileEntity.create method that is responsible for re-creating your TE when the chunk is loaded from the disk doesn't. That's what you need the default(parameterless) constructor for.

You can get a current Map<Enchantment, Integer> of the enchantments on your desired item using EnchantmentHelper.getEnchantments. The key of the map is the enchantent, and the value is it's level. You can then remove the desired key-value pair from the map(enchantments are singletons) and re-apply the modified map to your item using EnchantmentHelper.setEnchantments. Alternatively you can manualy get the stack's NBTTagCompound(ItemStack::getTagCompound), get the NBTTagList with a key of ench and a type of NBTTagCompound(10) from it - that is the list of enchantments. Then you can iterate through it's NBTTagCompound tags to find and remove the one you desire. Those NBTTagCompound entries contain 2 tags - a short with a key if id being the numerical enchantment ID and a short with a key of lvl being the enchantment's level. You can't use fields like that in your Item class as items are singletons. This field's value will be shared through all items of DragonShield class. This won't do what you want it to do. NBTBase::getId returns the ID of the NBTBase, not the enchantment ID. => if (!isBlastProtected)

Don't write anything, and check if the key is present in your read method(NBTTagCompound::hasKey). Then if the key is not found you know the value was null upon serializing and you can work around that. Upon investigating your code I notice that you do not have a default(parameterless) constructor for your TE and I am pretty sure that MC invokes the parameterless one when reading TEs from the disk. I suspect that because of that it can't be invoked and an exception is thrown thus preventing your TE from deserializing and the new one is created on demand with it's energy storage being empty.

I think that you can register a custom renderer for a vanilla entity aswell, even if it already has a renderer in place. You would do that in the same way you are already doing it for your own entities.

That is exactly how it works in most cases. I remember that there is/was a way to get a read-only access on the client somehow, but I do not remember how exactly it is done. It is marked as nullable because it will return null for blocks that don't have a tile entity like a standart stone block for example, but if a block returns true at Block::hasTileEntity and there is not a tileentity currently in the chunk's tile map MC will create a new one.

Also I don't think that having more than 1 different non-nested public(aka top-level) class within 1 java file is even valid java. Or is this just the way you've formatted your post and not your actual code snippet?

Show your ModelRegistryEvent hander then. Annotating methods with SideOnly is not a very good way of doing anything, really. SideOnly is too unreliable. Proxies exist for a reason.

That message means that forge was unable to find an object with that registry name in a registry. Additionally you could try to change the type of the field from LightBlueStairs to Block. I am pretty sure that forge still figures out that your type is a subclass of Block and the registry for blocks is the one to search through though.

That should not be happening. Are you sure that the LightBlueStairs constructor sets the registry name of the block to "iv:light_blue_stairs"? Is there anything in the log(fml-*****-latest, not the log you see in your ide's output window) mentioning the ObjectHolder? If forge can't inject an object into a field annotated with ObjectHolder it will log a message.

You were still missing the final modifier on the field. If you are manually setting the field to something else than null then you are not using ObjectHolders correctly, or at all for that matter. In a ModelRegistryEvent handler.

Looks mostly correct, yes.

OP is setting the registry name of an ItemBlock and is getting the name from a Block. That is a perfectly fine way to do it. @OrangeVillager61 your methods that handle the events are static yet you are using an instance-based bus subscribing. If you are using Mod.EventBusSubscriber then the handler methods must be static, if you are using EventBus::register then they can't be static. Forge's documentation explains it here. The field you annotate with ObjectHolder must have the following signature and declaration: public static final TYPE NAME = null; You are missing the final modifier. Additionally there is no reason to declare a class that only contains static methods final. A final modifier on a class means that other classes can't extend from it.

Where? You have never shown your code with a ResourceLocation object instantinated. You have shown you passing null as that ResourceLocation, which won't work.

Yes, it requires a ResourceLocation object. Instantinating it is up to you.

This is just a registy name of your entity. You can put anything you want in there except for null.

The client proxy is for executing the code on the client-side only. Just call this method from your mod class or somewhere else where the code is executed on both the server and the client.

I'm sorry, I don't think I understand you here, What did you remove? If you mean the method you were not supposed to remove it, you were supposed to relocate the call to it to the code that gets executed on both server and the client(aka common code).

Additionally registering your entities in your client proxy makes zero sense - entities are common, the server must know about them.

you don't have a local/field named dragon, hence the error. This is basic java. Could you please clarify this? I do not think I understand you here. Post your code with this try and the crashreport then. You can't have a null registry name for anything, including entities.

It is used as a registry name for the EntityEntry(ForgeRegistries.ENTITIES) registry. It is simply a registry name just as the one your blocks/items/biomes/potions/whatever have, that's all. You can put anything you want in there, just as you do for your blocks/items/etc.

1.8 is very outdated and you should update. Generics are a feature of java and many other programming languages. Look it up in a java manual or use a search engine of your choice. I guess it won't apply to 1.8 as 1.8 still was not using generics for TileEntitySpecialRenderer(aka TESR). If you have moved the translate above your rotate call and it is still not working I would suggest using a debugger to find out if Your TESR's renderTileEntityAt is being called at all. The client is aware of the values of the fields.

Well, you should learn the language that you are using to create mods first then. At least it's basics. Block::onBlockActivated indeed gets called multiple times - 1 on the server and 1 on the client. Also I do not think that that signature is right - where is the EnumHand argument? What version of the game are you creating a mod for? You must translate the matrix first, then rotate it.

I suppose that would be because of these lines: A part of my testing framework that I use to debug code from people when I do not see an obvious issue. Well, I am at a loss here then as this identical code works for me. If you don't mind could you please setup a github repo of your project(or a minimal part of it that allows the issue to be reproduced reliably) that can be cloned and debugged locally. I could then debug it with your exact conditions to try to figure out what exactly is wrong. EDIT: even though you've fixed it I am still curious as to what the issue was exactly. Was it a texture issue?

Hm, interesting. Can you please elaborate on the word 'gone' in your scenario? I have debugged your code and had no issues with it - apart from the fact that it is rendered across the entire screen(I've got that fixed in my test) and the UVs point at a relatively small region of the image.