[1.14.4] How to update the slots in the gui for the client?

[Cerandior]

So, I have been stuck on something for a while now.

I am trying to make a multi-block which detects any inventories connected to it, and then you can manage all these inventories in a main block. I have managed to do pretty much everything at this point. The multi-block detects all inventories connected to it, and I can view the items in the main block.

However, a problem arises in the GUI of the main block when I have more than 54 slots worth of inventory connected (Basically more than 2 normal chests or 1 double chest).
Because It would be stupid to make a humongous GUI to fit all the slots of all the inventories connected to the multi-block, instead the gui holds only 54 slots, and through a slider I can navigate through each of the inventories.

So okay, I did the slider. The way I am handling the "sliding mechanism" is by getting the position of the slider and scaling that to a number that tells me at which position I should start loading the slots. I hold a list of all the slots available in the multi-block. With all the empty slots being at the end, so I don't have random blank spaces showing up in the gui (just for aesthetic purposes). So by getting the offset from the slider, I simply clear the inventory slots of the container, and re-add the slots to the container but instead of starting from index 0 of the list of the slots, I start at the offset given by the slider. (There are also some shenanigans that make it so you scroll row by row and not slot by slot, but you get the idea).

The scrolling initially looks fine, however there is a problem. I checked (through some rather silly printlns) and it seems to me like the server has the correct slot data, however the client is completely clueless. Since the client is the one rendering the GUI, the slots that show up after scrolling are essentially useless. They are "copies" of previous slots with incorrect data and unusable to store anything else.

How can I give the client the correct slot information? Obviously, the first thing I thought of were packets, but what information should I be sending to the client exactly? If I send the whole container through the packet, then I would need to serialize and deserialize that into a byte array because I can't store it in any other way using the packet buffer. And after I get that container in the client, do I just execute the method that I use for updating the slots there?

I am not quite sure what I am supposed to do here, any help would be appreciated.

Thank you in advance.

Edited March 5, 2020 by Cerandior

[Cerandior]

Just now, diesieben07 said:

The order in which you add slots to a container is hugely important, as it determines their "slotNumber", which is used to sync their contents between client and server.

You must at all times have the exact same Slot configuration in server and client Container.

 

Because it is not feasible to transfer the scrolling action to the server, you should not scroll by adding and removing slots, but rather by changing their position on screen.

This is what I am currently doing (There are 2 separate lists for items and empty slots for troubleshooting reasons, there was initially one list):
https://gist.github.com/arjolpanci/5e1aa52909d8cb62494d08167e85d634

So instead you suggest adding all the slots in the beginning and then when I scroll I should change the slots xpos and ypos?

I also checked how it is done in the creative screen, however vanilla uses setInventorySlotContents which I don't think can be used for what I want to do right?

[Cerandior]

God damn, thanks man. I resumed my work on this 4 days ago, and although I haven't had too much time to experiment with stuff, it still took me way too long to find any problem with it.

Never would have guessed about the slotNumber being important, perhaps would have just given up on it if somebody didn't point that out. Would love to dive deeper into the source code sometime to try and get a better idea of what's going on, but unfortunately I have been too busy with uni stuff lately.