DavidM

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.

You would need to learn Java before making a mod. Fortunately Java is a pretty easy language, and an example of a Java tutorial is: https://www.tutorialspoint.com/java/index.htm. You might want to Google around for a more suitable tutorial if you don't find that specific tutorial helpful.

Post the new log.

If your tree is not a tree (as in data structure; in your case it resembles a graph), then there is no need to separate the parent and child. Instead of keeping track of parent and children, create a set for all other connect nodes (given that direction does not matter in your skill graph).

OP wants to use the registry system for skill tree nodes so that he can manage the skill categories easier later on as well as allow other mods to add theirs. The nodes only manages how the tree is displayed; OP uses the registry system for the skill categories, not the actual icon (which can be stored in the registry entry for simplicity given that there is a one-to-one mapping for all of the categories).

I personally define the read/write NBT myself in ICapabilitySerializable, as I find it more flexible (have more control over how stuff is stored, as well as being able to store types such as int array). This would force you to manage string keys though. However it is really up to you. I would suggest adhering to the single responsibility principle and make sure that your capability class is meant for data storage only; this will make it easier to debug as well as more readable.

1. Use item property overrides in your model. 2. Your texture has a very high resolution. This is not going to work well in many places of Minecraft. 3. MCreator probably screwed up the rendering. To fix your problems, you need to stop using MCreator and learn modding properly (via Java).

Please post your code.

1.12.2 is no longer supported on these forums due to its age. Please update to a modern version of Minecraft (1.14+) to receive support.

Yes.

What render layer is your block on? Please also post your code, preferably as a GitHub repo.

You should check out block state properties as well as multipart models. Check out the vanilla fence or chorus plant blocks for examples.

Few things to add: 1. You might want to check out SpriteUploader. 2. Check out AbstractGui::blit. It is the built-in method of rendering sprites with UV coords. 3. You won't need to check on for the rendering thread if you are rendering in the Screen code (in the appropriate method). On an irrelevant note, almost everything in BufferBuilder as well as AtlasTexture (and a few other mentioned classes) has been deobfuscated on recent MCP mappings. You should consider updating your mappings if you find them obfuscated on your setup.

You could specify the position of the node as part of its data, which should be part of the instance you use as the registry entry, and draw each node according to its position data. This allows you (as well as other mods that use your mod) to have more control over where the newly added nodes should appear. This also circumvents the "dynamically position the node and draw line between" problem. Directly using OpenGL should be the easier approach, as it has more flexibility (and Screen uses OpenGL anyways). Create a texture of a line and scale/rotate it to point it to other nodes. Some trigonometry will be needed.

I haven't been modding much after 1.15, so I guess I'm quite a noob now. @Turtledove I'm not sure what some of the data meant, but it seems that you are storing the data that is meant to be the same in two places: the int array and the data manager (corresponding to the 9 integer data parameter). You should keep them in one place instead (I would suggest the data manager instead of the array). bindedArtes[0] = ArteHandler.ARTES.QUICK_SLASH.ordinal(); bindedArtes[1] = ArteHandler.ARTES.QUICK_SLASH.ordinal(); bindedArtes[2] = ArteHandler.ARTES.QUICK_SLASH.ordinal(); bindedArtes[3] = ArteHandler.ARTES.SCATTERING_SLASH.ordinal(); bindedArtes[4] = ArteHandler.ARTES.SCATTERING_SLASH.ordinal(); bindedArtes[5] = ArteHandler.ARTES.SCATTERING_SLASH.ordinal(); bindedArtes[6] = ArteHandler.ARTES.DEMON_FANG.ordinal(); bindedArtes[7] = ArteHandler.ARTES.DEMON_FANG.ordinal(); bindedArtes[8] = ArteHandler.ARTES.DEMON_FANG.ordinal(); //... privateData.register(R0C0,0); privateData.register(R1C0,0); privateData.register(R2C0,0); privateData.register(R0C1,0); privateData.register(R1C1,0); privateData.register(R2C1,0); privateData.register(R0C2,0); privateData.register(R1C2,0); privateData.register(R2C2,0); As you can see there are parts like this, in which the values in the two places are de-synced with each other. My best guess is that during the reading/writing, this happened. You also seem to be using the capability as a non-direct handler for certain events, which I would not suggest. Capability is only meant to be a method of storing data, and routines that use the data should be in their corresponding places instead of the capability class. This will make debugging easier.

You have to post the code for us to see the problem. I don't think there is anything different with int arrays (at least the lat time I used them), and it is more likely to be caused by your code.

Oh oops. I thought they would use the constants in the Blocks class (since the access time is constant anyways) instead of caching. What is the reason for doing so on Mojang's side?