DavidM

In that case it is not called a container (ContainerScreen), but a Screen. Check out the Screen class. An examples of this is the DeathScreen class.

Where did you download Forge? The window you showed looks like an automatic mod installer, which is bad and shouldn’t be used.

That is unlikely to be the reason. Please read/post the crash log. Without the log you are just stabbing in the dark.

I see. I’ll switch to your method for performance. However I am not sure how to obtain the network given the position of a pipe in it. How would that be accomplished (without iterating through all of the existing network)? I am thinking of given all pipes a reference to its network, but there might be a better way.

Not exactly. Since each extracting/inserting pipe can have different channels (extracting pipe will only target inserting pipes with the same channel) and configurations (i.e. closest first, round robin, etc), the set of inserting pipes and the order of them might vary for each extracting pipe. I might have understood this wrongly, but I am not aware of other alternatives for this. If I understood correctly, my current approach and the approach you illustrated above both require the updating of a network if there are additions/deletions to the network.

Thanks for your replies. In my case, I am checking if an applicable inventory is placed next to a pipe via Block#updatePostPlacement, and add the pipe to tickables if there is one. The same goes for removing inventories. The TEs are responsible for storing whether the connection on a direction is disabled the player. My current approach is to path find every time the network of pipes is updated (i.e. removal/addition of pipe or inventory, changing of the configuration of a pipe, etc), and assign each extracting pipe to a set of inserting pipes (with matching configuration/channels). Every tick the extracting pipe sends items to the stored inserting pipes. There is no actual connections of the pipes is memory.

Please elaborate. I don't see how the master-slave pattern is applicable here.

Please read the EAQ and post the appropriate logs. There is a high chance that the 1 mod is broken/has problems.

Hello. I am creating a pipe block that can transfer items from one chest to another. This would require a tickable tile entity. However, since most of the pipes are not directly connected to a chest, but rather act as a connection between two pipes that have direct connection to chests, the majority of the pipes are not responsible for extracting items from inventories every tick. I am wondering whether it is a good idea to remove pipes that are not directly connected to a chest from the world's tickable tile entity list to avoid having unnecessary virtual invocations on ITickableTileEntity#tick, and re-add a pipe into the tickable list if a chest is placed near the pipe later on. Would this actually make the game perform better?

There are 3 parameters: 1. int amount: the amount of damage to be dealt to the ItemStack. 2. LivingEntity entityIn: The entity that damaged the ItemStack, i.e. pass the player if the damage is caused by the player's using the ItemStack. 3. Consumer onBroken: A consumer that takes in an LivingEntity, and called if the ItemStack broke (at 0 durability). If you don't want anything to happen, simply pass in the lambda player -> {}.

ItemStack#damageItem.

To be honest, those two YouTubers are notorious for creating low quality tutorials with bad coding practices. I would suggest ditching those tutorials to avoid writing problematic code. Some good quality tutorials are https://github.com/TheGreyGhost/MinecraftByExample and https://github.com/Cadiboo/Example-Mod.

You should also check whether you are on the server side via World#isRemote. Entities should only be spawned on the server.

Hello. I would like to sync the data of my tile entity on the server to the client. Previously, I used custom packets to sync my tile entities. However, I am interested in exploring the built-in way of syncing tile entities. As far as I can tell, TileEntity#getUpdatePacket is used to get the update packet of the tile entity (to be synced indepedently), while TileEntity#getUpdateTag is used to send the tile entity to the client as part of a chunk data packet. I am not sure how I should trigger a sending of the SUpdateTileEntityPacket though. The closest I can find is ServerPlayerEntity#sendTileEntityUpdate, but seeing that the method is private, I assume that there is a better way of doing so (using reflection and forcefully calling the method doesn't sound like a great idea). How do I sync the data of a tile entity to all tracking players using the built-in method?

Do not use Mineshafter. Buy the game.

Use reflection.

You can subscribe to PlayerTickEvent and manually change Entity::eyeHeight to fit your need. After that, simply simulate what Entity#recalculateSize does on the PlayerEntity.

You can; however, that is not what you want to do in this case. Why do you want to change the eye height every tick? What are you trying to achieve? AFAIK you only need to change the eye height when the event fires, as the event is used for all cases of determining an entity's eye height. I think there are a few exceptions such as ForgeInternalHandler.

What mods do you have? Please read the EAQ and post the appropriate log.

Items are singletons. You must store tankAir via NBT in an ItemStack. Use ItemStack#setTag.

Try using FontRenderer#drawString instead of FontRenderer#drawStringWithShadow.

Haven't tested whether non 2^n texture works in texture stitching, but as far as I know textures that are 2^n should both be easier to handle during mipmapping and look better after mipmapping (especially at high mipmap levels).

One important purpose of having texture atlas is to avoid binding a different texture every time a different texture is rendered (binding texture is expensive on OpenGL’s rendering). Therefore, it is a good idea to stitch mod textures onto existing (vanilla) texture atlases, as you won’t need to rebind to your own texture atlas every time you want to render something. In addition, modded block textures are by default stitched to the vanilla texture atlas IIRC, which wouldn’t been done if there is a “hijacking” issue of texture atlases (since texture atlas is only used in rendering, the addition of new textures to it wouldn’t cause any problem).

All loot should be added via loot table. This makes it data pack friendly, as the owner of a world save can alter the content. Modding has been increasingly datapack oriented (i.e. crafting recipes, block drops, mob drops, etc).

Define “no use”. Does it crash? Does your entity not appear?