T-Dark_

That was it. Thanks a lot!

You mean like BlockState blockState1 = Blocks.OBSIDIAN.getDefaultState(); BlockState blockState2 = Blocks.OBSIDIAN.getDefaultState(); and then the two calls to renderBlock are identical except one gets blockState1 and the other gets blockState2? Isn't that the same blockstate anyway? (Even if it isn't, tried that, doesn't work. The problem remains)

I'm trying to render a fake block as a sort of "targeting preview" for using a certain item. The block should eventually be drawn at where the player is looking at (which can be really far), but for now I'm just trying to understand how rendering works on a basic level. To be entirely honest, I don't fully understand the code that I'm using yet. I've copy-pasted it from another question and am now messing around to see which things do what. That being said, I'm seeing a weird piece of behaviour and am stumped. I'm rendering two "fake" blocks, and they seem to work just fine. That is, until I place a block near one of them. Logically, the face that cannot be seen (there is a block in the way, after all), disappears. However, the same face disappears on the other fake block as well. My code is here: https://github.com/T-Dark0/modding-tutorial/blob/master/src/main/java/com/tdark/mymod/rendering/Rendering.java Why does this happen?

So there is a getTag method, which returns the tag without the share tag, and a getShareTag method, which still returns the whole tag, but this time with the share tag? And the way you use them is by overriding getShareTag to "serialize" your data (and return the entire nbt tag, not just the data you serialized), and overriding readShareTag to "deserialize" your data? Is the share tag a sub-compound inside the main tag (like forgeCaps), or can it be flattened into the main tag?

I did read the javadocs, and what I got is that if you get the share tag, set the stack's tag to what you just got, and get the share tag again, the two share tags must be equal. Did I misunderstand the requirement? Is getShareTag supposed to return the entire tag, including the share tag?

When I did that, I had a problem: I need to know the energy level of the item client-side to display it in a tooltip. That's why I ended up writing to the stack's standard nbt instead: that's synced to the client automatically. Am I supposed to use packets to do that?

I have an item which consumes some energy from its capability and teleports the player on right click. It works fine both in creative and in survival. Until I duplicate the item by middle-clicking in creative mode. After that, the capability data of every single existing itemstack, as well as the new one, is reset to its default value of "0 energy". I am aware that, in creative mode, the client tells the server what to sync, instead of the other way around. The strange part is that ALL itemstacks are affected, instead of just the copied one, as I would expect. Returning to survival mode doesn't fix the problem. While, restarting the game does. What could be causing this, and how do I fix it? I tried to take a look at get and read ShareTag, but they had no visible effect. They didn't even alter the nbt tag. Here is the problematic file, in the code's repo.

Based on the output of /data get entity @s Inventory[0] [11:34:29] [Render thread/INFO] [minecraft/NewChatGui]: [CHAT] Dev has the following entity data: {Slot: 0b, ForgeCaps: {Parent: {Energy: 200}}, id: "mymod:teleport_staff", Count: 1b} There is an nbt tag called "ForgeCaps". With that name, I assume that's where caps are saved. It increases by 100 whenever I use the staff, and it is reset to 0 whenever I reload the game

I updated my code. Now I only create the LazyOptional in the ICapabilityProvider constructor, and then always use the same. The other problem has changed, but it's still not correct. I implemented INBTSerializable, but the capability's energy is still reset whenever I load the game. The bright side is that the nbt is no longer out of sync: it is reset to 0 as well. What am I doing wrong? Why is the tag reset to 0, as opposed to remaining what it was when I last saved the game?

I'm trying to implement a basic teleportation staff. I managed to get the basic tp functionality working, and am now trying to make it require electricity. I'm overriding initCapabilities in the item's class, and I managed to get a capability provider working. The cap works perfectly fine, and it updates the itemstack's nbt data correctly, until I close the game and reload it. When I do that, the capability resets its energy to 0, without updating the NBT data. What I would like to get is an item that doesn't lose all of its energy because I closed the game. I already tried to set the cap's energy based on the nbt data of the itemstack, but that only exists on the server ("server thread"). On the client ("render thread"), it's null. Here is the code, on github. Can anyone fill me in as to what I'm missing?

I'm currently following McJty's 1.14 tutorial, trying to apply it to 1.15.2. I just got to the part where he creates a GUI for the first block, and my gui is functional. Thing is, it is drawn at the bottom of the screen, instead of where the block/inventory slots are actually placed. (see attachment) I'm assuming I need to somehow specify where the GUI should be drawn on the screen, but I'm not sure (and wouldn't know where to start). Here is the GUI code, (as well as the everything else: it's a github repo). Can anyone help me figure out what I did wrong?