DavidM

The "flatten the code" is meant for different blocks. Previously due to the ID limit, mod authors commonly associate different types of item to the same ID (i.e. different colored cobblestone, or vanilla's different colored wool). These should be flattened and separated into different block registry entries. However this is not the case in your case. Your two blocks are similar to the off and on state of redstone lamp, and your two blocks functions similarly (can be done with a single tile entity). It sounds like the only difference between the two blocks is the texture of the block, which would be easier to manage with block state properties.

Instead of swapping blocks, you should use block state properties.

What do you mean by “overriding something”?

Get the unit vector of the entity to the destination and scale that by the desired speed, then move the entity by that amount.

Depending on the game type of the server, it may be more up to how server plugins are written rather than the game itself (i.e. mini game servers rely heavily on the performance of the mini game plugins). As for optimizing the game itself, projects like Spigot provide tweaked server jars that might improve server performance.

Except that would break every world interaction as well as cause a ton of concurrency issues. Adding more threads doesn’t mean the game would be faster and better; threading is not a magical solution to all performance issues. Threading should only be used if the routine to be put on another thread makes sense to be on another thread (i.e. make the checking for update routine separate from the main game thread, or separate the render thread from the game logic thread (not Minecraft specific)). It is not as simple as totalTimeUsed / threadCount = actualTimeUsed.

You need to post more of your code. We can't know what the problem is just by looking at a single line of code.

With the SlotItemHandler it would be a bit different. Since SlotItemHandler checks whether the inserted item can be accepted into the item handler, there is no need to add checks to the slot. Instead, you only need to create another IItemHandler capability for the output slot that does not accept the inserting of items (the SlotItemHandler will respect the isItemValid check).

Yes, because displayItemActivation is client-specific code. You need to send a packet from server to client, and let the client do the render.

This depends on graphics settings as well as device. I wouldn't suggest anything larger than 64*64 pixels.

Out of curiosity, wouldn't this trigger the class loading of Minecraft since a method of Minecraft is being invoked?

Because they chose not to. Common reasons include player base not willing to move on, plugins not supporting newer versions, and switching to a newer version requiring more effort/time than the server owner is willing to commit. That is not what happened and, in fact, does not make much sense. You might want to look into what is multithreading and how it is implemented in games like Minecraft.

You should do both. The custom slot (smoothly) prevents the player from inserting into the slot in the container, while the custom item handler capability prevents other tile entities from inserting item into the slot.

1. Use a custom slot in your container and override Slot#isItemValid to return false. 2. Create another item handler for the output and override the methods to not allow inserting item into it.

You can't. The way models are rendered in Minecraft does not work well with quads that have tiny length on one dimension.