[1.10] Synchronize Inventory Container

[Draco18s]

I'm doing crazy shit with a container, due to this crazy shit, I can only determine whether or not an item can be inserted into any given slot on the server.  I cannot in any way perform this calculation on the client without doing massive, massive hacks to the way the client handles worlds or completely subverting the suggested solution to the earlier problem (TEs with null worlds).  See this post for previous info.

 

How the hell do I handle this?

[Animefan8888]

I'm doing crazy shit with a container, due to this crazy shit, I can only determine whether or not an item can be inserted into any given slot on the server.  I cannot in any way perform this calculation on the client without doing massive, massive hacks to the way the client handles worlds or completely subverting the suggested solution to the earlier problem (TEs with null worlds).  See this post for previous info.

 

How the hell do I handle this?

Isn't "whether or not an item can be inserted into any given slot" handled server side anyways? Could you maybe provide more info ie code?

[Draco18s]

Isn't "whether or not an item can be inserted into any given slot" handled server side anyways? Could you maybe provide more info ie code?

 

The code is executed on both sides.  On the client side it's used to keep the GUI display accurate.  Go ahead and try it, make a basic container, then in the "can be inserted" logic of the slot, pass the info off to the TE, then have the TE discriminate based on worldObj.isRemote.  You'll see what I mean.

 

Idea: Try out every item in the player's inventory (not that many, right? ) and send a bitset for every one of those to the client telling it whether or not that item can be put in a given slot.

 

When?

 

Edit:

Also, there's the issue of the player picking up an item that was not previously in their inventory after the gui was opened (any item stack dropped by another player or a dispenser/dropper/other item transport).

[Draco18s]

As for how to detect changes...

Container

already does that every tick.

 

If the container is already detecting any changes to slots and sending those changes to any client, why do my slots not update until I close and reopen the inventory?

[Draco18s]

[me=Draco18s]starts writing the packet info to handle the data transmission only...[/me]

 

Aw fuck.

 

The filter rules can change while the inventory is open (that is how one alters them).  Which means that what items are valid for the standard inventory slots also changes.  There's no easy way to find all possible rule TileEntities and check every item against all of those TEs for insertion from every side.  Complexity comes out to... something in the neighborhood of O(kn²) where k is 3 times a subset of n (does that make it O(n²log_n) ?).

 

Heck the packet itself could contain upwards of 5kb(?) worth of data too. Each item would need to be paired with a minimum of 3 bits of information per TileEntity found within that list of 36 items, plus 1 bit for being allowed into the rules slots.  So 1 bit per item + 3 bits per item per item.

 

And each itemblock that has a TE could potentially need to check 16 possible states to insure validity, meaning as many as 576 setblock operations (average is probably closer to 18).

 

There's got to be an easier way.