V0idWa1k3r

When comparing to null it is perfectly fine to use ==. Also NBTTagCompound#getCompoundTag can't be null. If there is no such key in the tag map it will return a new, empty NBTTagCompound. If there is something with that key in the map but it isn't an instance of NBTTagCompound it will also return a new empty NBTTagCompound. Otherwise it will return the NBTTagCompound stored in the map. Could you please update your github repository to the latest state so I can debug it locally?

What are you trying to do, exactly? Move the lightning? You will need to use the tick event to detect the lightning in the weather effects list and move it. Potentially you might also need to update the lightning's position on the clients with a custom packet, I am not sure whether the game keeps the lightning's position in sync or not.

Use the debugger, looks like the NBT data being deserialized doesn't have any tag by the inventory key. Did you add the inventory later after adding the TE to your world? In order to avoid these kind of errors don't use the raw getTag method, use the getter that corresponds to the type of the object you want to get. In your case NBTTagCompound#getCompoundTag. These getters will never return null. Now for the non-related issues: CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere else but your proxy. It makes even less sense in your case since you are using it as the event handler for whatever reason. And handling FML lifecycle events there. Handle the FML lifecycle events in your main mod class, and handle the other forge events in a separate handler. Don't use this overload that is marked as deprecated. Use the one that takes a ResourceLocation as it's second parameter. What on earth is a gui proxy? BaseBlock is anantipattern. There is already a BlockBase, it's called Block. Also: IHasModel is stupid. All items need models, no exception, and nothing about model registration requires access to private/protected data of the block/item. Register your models in the ModelRegistryEvent directly. And yes, this is just another variant of IHasModel, you just have a class instead of an interface. Don't ever use static initializers. Instantinate your things in the appropriate RegistryEvent directly. See above point. https://github.com/Sudwood/Cencial/blob/master/java/com/sudwood/cencial/blocks/BlockBasicPlinth.java#L98 You don't need all this awkward TE manipulations. Just override TileEntity#shouldRefresh.

I don't think so. Shaders might even disregard the lightmap completely seeing how the lightmap is minecraft's way of having, well, lighting. Shaders don't need it since they likely use the fragment shader to change the "brightness" aka color of the fragment based on the light sources of the scene.

No. The game will only display/handle your hitbox when you are directly looking at the block in question. While block hitboxes are raytraced it doesn't apply to hitboxes bigger than 1x1.5x1. If you need blocks bigger than that you will have to fill in the space with "phantom" blocks. Don't do stringly-typed code. Minecraft already has a class for directions, it's EnumFacing. Also you can't store variables in blocks like that. Blocks are singletons, there is only ever one instance per registry entry. If you need to store additional data per block then you need to use either blockstates or TileEntities. Don't compare strings like that, use equals. This only works because java has string pools and those can be disabled(I think) This doesn't even compile. What are you actually trying to do? have the bounding box be dependent on the block's rotation? You can get the IBlockState passed to you in the Block#getBoundingBox and compare against the value of the rotation property of that blockstate.

If only forge had a utility that allowed you to execute sided-only code based on what physical side you are on...

You can equip a sword aswell. And you can change the AI on the go if needed too, similar to how a skeleton adapts to having a sword instead of a bow in vanilla. But whatever, fine. You need to despawn your current entity using Entity#setDead, then create a new one of the type that you want(the other entity), place it in the same location as your first one(Entity#setPosition, Entity.posX/Y/Z) and do whatever else you want to do with it(if anything). Finally you only need to spawn it with World#spawnEntity. Make sure you check that you are only performing all of that on a server first.

Why not just make the entity wear the chestplate instead, like all vanilla entities do? There is no need to replace the entity with an another one here. This will never be true, that's not how OOP works. These are 2 different non-primitive objects thus they will never be equal to one another in a direct == comparason.

Chances are in a vanilla MC environment it does not change anything. However if there is another mod installed that leaks lightmap coordinates then you will certainly see the change if you are not changing the lightmap coordinates yourself. Your box might get darker, or brighter. Or it may even become very transparent and bright. Or might even not render at all, depends on what the other mod set the coordinates to.

The interpolation doesn't happen between "future" position. It happens between position at previous tick and position this tick. So it is indeed quite possible.

Well, I don't see any translation issues in the video, but I think I understand what you mean by it. It has to do with the interpolation of the entity's position. Basically each frame the entity's actual position is previousTickPosition + (currentTickPosition - previousTickPosition) * partialTicks. The BB is updated per tick, not per frame thus no interpolation is happening, so you need to do it yourself. As for other issues in the video: I don't really know why the box dissappears when you look away or move a bit away. It would dissappear if the player moves out of entity tracking distance, but that's not the case in the video so it has to be a rendering issue. There are a couple of rendering issues you have: QUADS will draw, well, a quad, not an outline - it basically will enclose the player in a box. Is that the desired effect here? I also think I see lightmap issues - so you need to specify the lightmap aswell either by having a vertex format that specifies it or by setting the coordinates manually with OpenGlHelper. Apart from that I would blame shaders. Does the code work fine without shaders?

What do you mean by "weren't updated in realtime"? RenderWorldLast fires once each frame. You are either not interpolating their position correctly, or messing up the translations.

Use something like RenderWorldLastEvent.

It can drop whatever you want, but you are telling the game to look for a lottable at minecraft:loot_tables/bone_drop, which is incorrect. Well, you are a programmer. You should be able to easily fix syntax errors. I can't tell what the issue is since you have neither provided enough code to determine the issue nor the error report.

But you are rendering exactly the same boundingbox F3+B would render This is equal to the collision BB for players. So define

This would register the loottable with the name of minecraft:bone_drop. I don't think your modid is minecraft. Also when are you calling this? Apart from that(and apart from the fact that you've blatanly copied my code - you even left the field names the same which makes no sense in your mod) sure, looks fine to me.

Also why did you quote @Animefan8888 who also told you not to use LivingDeathEvent?

There is a section in the official docs that explains how to add custom drops to a vanilla loottable. If you need an example you can have them here(json, registration, injection)

CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere else but your proxy. Hmm... didn't I tell you that already? Why yes, I did. This makes even less sense. A server proxy either supplies noop implementations for client-only methods or invokes server-side only code that would crash the client. Your common proxy can't be your server proxy because if it were it would crash the client. IHasModel is stupid. All items need models, no exceptions and nothing about model registration requires access to private/protected information of the item. Just register your models in the model regitry event directly. I told you this one earlier too. Don't ever use static initializers, instantinate your stuff directly in the appropriate registry event. And yet again, you were told to do this aswell. Same for the items. ItemBase is an antipattern. There is already an ItemBase - it's called Item. Same goes for BlockBase This is not how you specify max/min bounds logically. It only works in this case because min is 1(drops 1 - 3). If min was 2 it would drop 2-4. As for the issue - look at your random logic here: So, generate at minY + [0-deltaY]. Okay, what's deltaY? Unless min > max which makes no sense deltaY will always be negative. You can't pass a value less than 1 to a random method. In your case deltaY is -48.

Just learn how to use loottables, it's not that hard. Not only are data-driven methods prefferred over code-based ones, a lot of mods rely on loottables, like JEI Mob drops addon. You also won't have any issues as a side bonus.

RenderGameOverlayEvent is for rendering additional UI elements, not anything in the world. Why are you trying to do this exactly? You can already see bonding boxes of entities by pressing F3+B.

This has very little to do with capabilities. Again, in TileEntity#getCapability method you need to return a wrapper around your capability that doesn't allow inserting/extracting items based on the side. You can have one wrapper that does it all, or you can have one wrapper per side, it doesn't matter. Look at the javadocs of IItemHandler to see what you need to return in insert/extractItem to provide a "noop" implementation. Edit: well, sure, here is a small pseudo-code example:

Well, GUI button presses only occur on the client while the clock's logic occurs on the server. The server has no idea that the data was changed. You need to use packets to notify the server.

Well, you need to make sure that NBT data is synced to the client upon world load. The TileEntity#getUpdatePacket, TileEntity#getUpdateTag, TileEntity#onDataPacket and TileEntity#handleUpdateTag are the methods you need. You also need to make sure that your block actually constructs it's blockstate based on the data in the TE - use Block#getActualState for that.

That's what I was talking about. Look what the WorldServer actually does: int j = this.calculateSkylightSubtracted(1.0F); if (j != this.getSkylightSubtracted()) { this.setSkylightSubtracted(j); } it checks whether the cached value isn't equal to the actual value and if it isn't it sets the field to the new value. That's all it does. Everything else uses the value stored in that field. If you modify the field you give the modified value to everything that uses it. There is an issue though - WorldServer#updateBlocks is called after that but before forge's tick event. Which means that any block ticking(not a TileEntity! Just the Block#randomTick method being invoked) still has the old value. I don't know how critical that is. Everything else apart from blocks is ticked after the forge's event though. They happen on the same thread. There is very little multithreading in the game so you don't need to worry about that. I don't think the client is even aware of this value changing actually. It looks like the only time this value is changed is in WorldServer and I don't see it being synced anywhere. I guess the client doesn't need it at all. In java enums are just a fancy way to define a collection of objects. So reflection works much the same way as it would with any other object. The only difficulty might be the fact that values in enums are usually marked as final, but there is a dirty hack to get around that. Consider the following example: Field id = EnumDifficulty.class.getDeclaredField("difficultyId"); id.setAccessible(true); Field modifiers = Field.class.getDeclaredField("modifiers"); modifiers.setAccessible(true); modifiers.set(id, id.getModifiers() & ~Modifier.FINAL); id.setInt(EnumDifficulty.EASY, 10000); System.out.println(EnumDifficulty.EASY.getDifficultyId()); This outputs 10000, even though the initial value was 1.