Jump to content

Player Inventory Synchronization


Bedrock_Miner

Recommended Posts

Heyho Guys!

 

I have a small problem concerning the player's inventory:

When I use setInventorySlotContents(), or any other method that modifies the inventory, the client side inventory is only synchronized with the change if the slot which gets changed is the current selected slot. For any other slot, a change is not transmitted to the client.

How can I force synchronization for the whole inventory to commit the changes I made?

 

Thank you!

Link to comment
Share on other sites

Are you referring to vanilla inventory or your custom one? Vanilla should synchro it automatically :o

If you are using custom - implement IInventory and inside any method that manipulates slots in ANY way, you will need to manually send packet to players that require data.

 

http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-x-1-8-customizing-packet-handling-with

 

Edit - for direct help about custom IInventory provide code. If it's vanilla then I have no idea (not on IDE now, might check later).

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

Well, its kinda weird because I'm referring to the normal vanilla inventory.

I'm using onBlockActivated and inside this method I call

player.inventory.setInventorySlotContents(0, null);

I'm calling this only on server side (

world.isRemote == false

). I dont want to change this.

When you right click the block with the first slot selected, the item disappears.

If you have another slot selected it is still rendered inside the inventory, but it is not there anymore, if you try to use it it disappears.

If you have this "ghost item" and move it to another slot, it can be used again.

Link to comment
Share on other sites

That's because the vanilla hotbar inventory is usually changed by packet from the client, or the code is run on both sides.

 

When changing the inventory from the server side only, therefore, it is necessary to inform the client:

// get the actual inventory Slot:
Slot slot = player.openContainer.getSlotFromInventory(player.inventory, i);
// send S2FPacketSetSlot to the player with the new / changed stack (or null)
((EntityPlayerMP) player).playerNetServerHandler.sendPacket(new S2FPacketSetSlot(player.openContainer.windowId, slot.slotNumber, invStack));

Link to comment
Share on other sites

coolAlias is right in this, BUT what he didn't mentioned is some fact about game modes.

 

1. If you remove ItemStack from player.inventory on both sides, no matter what - both will loose the stack (and yeah, that's 100%).

2. If only on client - obviously you'll be out of sync and if you would swap that slot with other item, second one would appear (server will synchro you)

 

3. BUT now - what you are doing is setting only on server. Funny thing here is gamemode.

When in survival you client will go out of sync like in point 2. (and will most likely update with upcoming packet), but if you are in creative there is something like creative inventory - that's where magic happens, you see, when in creative server allows CLIENT to actually SEND ItemStacks - processes are not Server -> Client, but "reciprocal" (whetever this word means - doublt-sided/Bi-directional). You can edit anything you want, therefore if you would remove itemStack on server-side, but not on client, if you try to use removed-on-server item in this nulled slot, item will dissappear (server resynchronizes client when item is used) BUT if you would move this server-nulled item to other slot, then it's treated like one generated by creative inventory - and send from Client to Server. Server normally saves it to your server-side inventory.

 

I was doing some tests to see your described problem in real life and I remembered this thread:

http://www.minecraftforge.net/forum/index.php/topic,27073.msg138216.html#msg138216

Then tested gamemodes and theory become real. :)

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

The cause of this happening is the Player inventory is synced bidirectional, Server <--> Client.

(It also happens on Survival mode)

 

So when client changes the position of an item, it sends sync packet to Server.

then Server checks if it is valid change, and return the packet to the Client.

 

As the result, Minecraft would not send the packet automatically when Server side inventory changes.

 

I discovered this while developing my Inventory Machine mod, InvWorks, so I had to make change for each side.

I. Stellarium for Minecraft: Configurable Universe for Minecraft! (WIP)

II. Stellar Sky, Better Star Rendering&Sky Utility mod, had separated from Stellarium.

Link to comment
Share on other sites

How is that an answer... ContainerPlayer STILL checks every tick. On the server. Look at the code...

Oh I misremembered it.

 

This problem happens because Container#inventoryItemStacks does not synced with the inventory on some case.

I don't know why this only happens on Creative mode.. but there would be some reason.

(It was serious problem on my InvWorks mod, so I solved it by syncing it)

 

Maybe using methods of EntityPlayerMP would solve the problem.

I. Stellarium for Minecraft: Configurable Universe for Minecraft! (WIP)

II. Stellar Sky, Better Star Rendering&Sky Utility mod, had separated from Stellarium.

Link to comment
Share on other sites

Except it doesn't only happen in Creative Mode - this issue is not related to Game Mode at all; it happens because for whatever reason, the action bar is not continuously synced from the server despite the container being open, so when you run code only on the server side that affects the action bar, you have to send a packet as I described above, again regardless of what game mode you are in.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.