longbowrocks

Yep, that works.

Damn. Between brainstorming and reading vanilla code , I forgot that I hadn't finished looking through the events provided by forge! Thank you diesieben07, I'll have to try that when I get home today. I managed to confirm that I can write the NBT to an ItemStack before I left, and I should be able to read the NBT with BlockEvent.PlaceEvent.

That sounds about right, but in this case that would be a core mod (I think so anyway. There appear to be multiple definitions for core mod spread across the net, so I can only assume "core mod" means "anything that modifies the vanilla Minecraft code instead of extending/adding to it")

I've written a mod that adds a Capability with persistent state to chest type TileEntities (TileEntityChest, TileEntityShulkerBox). I would like to pick up a chest and put it back down without losing my Capability state, but from what I've read in both code and forums, that doesn't seem possible without editing breakBlock() for the affected classes, or replacing the classes with my own (either way, that sounds like a core mod). If I want to do this, does it have to be a core mod, or have I missed something?

Alright, solved it: The problem I was having was not what I thought: Minecraft.getMinecraft() actually was in my classloader (probably, if I'm right this time). The issue was that running the jar gradle task under build doesn't reobfuscate the code (correctly? at all?), so you end up with a jar that doesn't work with you minecraft installation, because it looks up methods and other names in the wrong place. The correct way to do it is to run the build gradle task under build, and copy the jar that doesn't have any suffixes. The @SideOnly annotation is probably just there to keep certain classes from showing up on the physical server.

That was my initial thinking, until I started getting NoSuchMethodError: Minecraft.getMinecraft() which means I was getting this event in a server context. Additionally, if the name had any bearing on where the event was received, those other mods shouldn't need a @SideOnly decorator.

I've been running into java.lang.NoSuchMethodError: net.minecraft.client.Minecraft.getMinecraft() while creating a 1.11.2/1.12.2 mod, and finally (I think) figured out that it was occurring because TickEvent.ClientTickEvent is NOT restricted to the logical client, but rather to the physical client, which may include a logical server. I was satisfied with this answer until I looked at other mods to see how they checked for logical sidedness without calling Minecraft.getMinecraft().isRemote. From what I can see, most mods are just checking physical sidedness: Tinker's Construct: @SubscribeEvent @SideOnly(Side.CLIENT) public void playerJoinedWorld(TickEvent.ClientTickEvent event) { EntityPlayerSP player = Minecraft.getMinecraft().player; Astral Sorcery: @SubscribeEvent @SideOnly(Side.CLIENT) public void onTick(TickEvent.ClientTickEvent event) { if(event.phase == TickEvent.Phase.END && Minecraft.getMinecraft().player != null) { JustEnoughItems: @SubscribeEvent public void onClientTick(TickEvent.ClientTickEvent event) { if (event.side == Side.CLIENT && SessionData.hasJoinedWorld() && Minecraft.getMinecraft().player != null) { inventorytweaks (Actually works, but the above three should work too and they don't): @SubscribeEvent public void onTick(@NotNull TickEvent.ClientTickEvent tick) { if(tick.phase == TickEvent.Phase.START) { Minecraft mc = FMLClientHandler.instance().getClient(); My question is: Why aren't these mods receiving ClientTickEvents on the logical server? Have I misunderstood what my problem is? Is there some hocus-pocus that will allow me to do what they're doing (if I copy the code for the first three, I still get NoSuchMethodError)?

That's what I was looking for. Thanks! I tried that on the client and found it to be a ContainerLocalMenu, so I assumed that TileEntityChest::creatContainer was dead code. I never thought to check it on the server. Did you just try it on both sides and find that the server side had a different object type in EntityPlayer::openContainer.lowerChestInventory?

Damn. I was trying to modify the behaviour of vanilla chests. If there's no other solution, I guess the only option is for me to listen for right click events , and store a static reference to the right clicked block. May async events have mercy on my soul.

But that's the problem I originally stated. There are plenty of ways to get the relationship between TileEntityChest and BlockChest, and a few ways to get the relationship between GuiContainer and ContainerChest, but I've yet to draw a connection between one of those groups and the other, aside from perhaps BlockChest.getContainer(), which returns a brand new Container.

That's an interesting member, but it doesn't seem to solve the problem. The currently open Container appears to be in-memory-only, and won't be saved, so I need to use that to get a reference to a TileEntityChest or BlockChest, which will be saved.

Thanks for the tip on Chunk NBT. That's excellent because it's exactly the behaviour I'm hoping for. I was eventually going to start listening for chunk load/unload events so I knew when/where to load or save my cache of chest info. As for packets, I'm already sending plenty of packets, and I will indeed be attaching block<->gui mapping info to them once I find it, but that's not the problem. It appears that there's no logical relationship between GUI related classes (GuiContainer, ContainerChest), and Block related classes (TileEntityChest, BlockChest). That is to say, no GUI related class has a reference to a block related class, and no block related class has a reference to a GUI related class. In simple terms, if I can get a GuiContainer or ContainerChest on a server thread, and can print the associated TileEntityChest or BlockChest to the terminal, then I've gotten what I need.

While a TileEntity can create a minecraft.inventory.Container, it doesn't appear to store a reference to it. You may be thinking of the GuiContainer, which has a Container reference. That does appear to have a few members (windowId, transactionID) that map the Gui object on the client to an object on the server though, so thanks! I thought everything GUI related was client side only. However, Container objects aren't saved, so I still need to map these GUI objects to blocks on the server side. Any thoughts?

When a player has a chest inventory screen open, I'd like to allow them to press a button to store information about that chest in chunk NBT on the server, but there doesn't seem to be a clean way to do this. When a button is pressed, you can get the inventory of the active GUI through minecraft.currentScreen.inventorySlots, but there appears to be a logical rift between that and the classes that actually refer to a block in the world (BlockChest, TileEntityChest). Is my only option to capture right click events, and cache the last block a player right clicked? When I want to send information about a chest to the server, it seems the only identifier I can use is its block position, but that seems to me like it has problems. What if a piston pushes the chest right after I send the message? Wouldn't my data then be associated with whatever new block (possibly another chest) now occupies that space?