V0idWa1k3r

You can see how minecraft does that in net.minecraftforge.client.GuiIngameForge#renderHealth. Basically the withered/poisoned hearts are a part of the hud texture and MC just changes the uvs when it detects a certain potion effect active. If you want to replicate that effect you would need to use a RenderGameOverlayEvent to cancel the default hearts rendering when you need it and render your hearts with a different texture.

If I recall correctly a sound name should be prefixed by your modid. "name": "ctm:records/disk_1" If the file can't be found the startup log will contain a message that a file at a given resource location could not be found.

Entity::rayTrace only looks for blocks as it reroutes to World::rayTraceBlocks. You will need a custom ray-tracing method. You can see an example at EntityArrow::findEntityOnPath.

https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ People on this forum(including me) have no idea how you are currently doing your data saving/loading/interaction so we can't know why the problem occurs as you've not posted any code. Please provide relevant pieces of your code or a link to your mod's git repository.

No, there isn't. You do it whenever you want. Since other mods might query oredict to enable some kind of compatibility I would suggest duing it during init(as mod compatibility should happen in post-init according to docs anyway) or in registry event directly as you've suggested. If it implements IForgeRegistryEntry(or extends IForgeRegistryEntry.Impl) then it has a registry event(well actually rather if it has a registry then there is an event but in vanilla there is a registry for evey IForgeRegistryEntry implementation). Just lookup the usages in your IDE.

Yes, that would be the best way as you can't get null with that method. Depends on the entity in question. Default implementation provided by Entity returns the same in both of these methods and the default implementation is the only one used by vanilla as far as I am aware. Entity::getUniqueID is used everywhere by vanilla and Entity::getPersistentID is only used by forge. Both of those methods can be overriden, so I can't tell how different mods use/override them.

EntityPlayer.getUUID(GameProfile) returns the UUID of the profile if present, otherwise reroutes to EntityPlayer.getOfflineUUID(String). EntityPlayer.getOfflineUUID(String) returns a UUID generated from a username provided prefixed with OfflinePlayer. Entity::getPersistentID and Entity::getUniqueID both return the same in case of EntityPlayer - and that would be the result of EntityPlayer.getUUID(GameProfile). GameProfile::getId returns the UUID of the profile, or null if it is not present(could not connect to Mojang's servers). So there are really 2 cases: The player is logged in and in that case return the UUID from Mojang's servers The player is not logged in and in that case return a UUID generated based on their name.

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).