[SOLVED] [1.7.2] Simple Block with Inventory

[mercrutio]

Hey, I'm having a heck of a time setting up a block that can hold items between sessions.  It's obviously a problem with Server/Client syncing, but I don't know how to approach it.  I feel like there should be a simple solution by extending and overriding the right classes/files, but I can't figure it out.

 

Assume, for simplicity, that I just want to make a 'custom' Furnace.  I have 1.) a Block implementing ITileEntityProvider, 2.) a TileEntity implementing IInventory, 3.) a Container, and 4.) a GuiContainer.  I also have a GuiHandler class that points to the container/guiContainer as appropriate.  I have registered the block and the tile entity with GameRegistry.

 

I can get the gui to render just fine, and I can even interact with it as a simple storage.  I haven't tried anything relating to burning.  The problem is encountered when logging out and back in:  any items placed in the tile entity go back to the player inventory.  I'll post some code, but is there anything I'm obviously not doing?

 

It seems that there aren't, in fact, any methods in place to handle the disparity between the Server and Client.  I have written a custom packet to inform the server every time an item is placed into the inventory clientside, but now the client doesn't seem to get the data from the server.  And it's a horribly messy way to be doing it.

 

Solution: There was a bug in Forge 10.12.0.998 (and probably below). It was fixed in build 999, and syncing the TileEntity is just as you would think.  If you're dealing with obfuscation, func_145844_m() is getDescriptionPacket(), and onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) is legible.  And yes, you do need to use S35PacketUpdateTileEntity.  Thanks to the guys here and around who told me about the bug, and thanks x100 to the powers that be (cpw, I'm pretty sure) for fixing this promptly.

[mercrutio]

Hey, I just found S35PacketUpdateTileEntity.  Lemme guess, it has to do with that?

[EdgarAllen]

If you feel like you've implemented everything properly and you are still getting sync issues, it may have to do with a FML bug that should be fixed in this commit https://github.com/MinecraftForge/FML/commit/80b00dc7966d96111e2ce8643db8e0f544c2bc89

 

[mercrutio]

Looking at it, I think that could be the problem.  Is there a way to get this commit into my build, or do I have to wait for the next Forge release?  I assume the latter, but I've never messed with it.  Thank you for pointing it out, either way!

[Draco18s]

Synching tile entities is super easy.

 

        public Packet getDescriptionPacket() {
                NBTTagCompound nbtTag = new NBTTagCompound();
                this.writeToNBT(nbtTag);
                return new Packet132TileEntityData(this.xCoord, this.yCoord, this.zCoord, 1, nbtTag);
        }

        public void onDataPacket(INetworkManager net, Packet132TileEntityData packet) {
                readFromNBT(packet.data);
        }

 

As long as your TE saves its inventory correctly in writeToNBT and reads it back in readFromNBT, that's all you need.

 

https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/entity/TileEntityDisplayPedestal.java

[mercrutio]

Draco18s, I appreciate the input.  The idea is sound, but it doesn't work correctly under 10.12.0.998, which is Forge-latest as of this writing.

 

After obfuscating and updating to deal with Netty, I got this:

 

public Packet func_145844_m() {
        NBTTagCompound nbtTag = new NBTTagCompound();
        this.func_145841_b(nbtTag);
        return new S35PacketUpdateTileEntity(this.field_145851_c, this.field_145848_d, this.field_145849_e, 1, nbtTag);
}

public void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) {
func_145839_a(packet.func_148857_g());
}

 

which works as described in the OP.

 

I can't be certain until I can test it, but I'm pretty sure it's exactly what EdgarAllen says.  Anyway, thank you, I was really excited for a second there.

[EdgarAllen]

Personally, I'm just waiting till forge pulls in the commit. I don't expect it to be more than a couple days. I know my gui code is correct. In the mean time I just did a mock that has it's inventory filled with random items so I can test things without having to open the gui.

 

[Draco18s]

  On 1/14/2014 at 4:53 PM, EdgarAllen said:

Personally, I'm just waiting till forge pulls in the commit.

 

Personally I'm waiting for more deobfuscation.

 

I can handle the occasional func_* and field_* but when 95% of what I'm using looks like that, the code is unreadable and very hard to work with.

[mercrutio]

Man, tell me about it.  I haven't been programming for fun in a while, and when I saw Forge had just come out for 1.7.2 I was all, "Sweet!"  Now the names have got my head spinning.  I'm learning a lot about Minecraft and Forge though, and it's satisfying as heck when things work.