Jump to content

Recommended Posts

Posted (edited)

In my mod I replace the player's survival mode inventory container. It works almost perfectly, but I've had a long-running issue that in a very small number of situations, it doesn't synchronise properly. So far, the only situations it definitely happens are:

  • Using the /give command
  • Using JEI recipe fill

What seems to happen is the client doesn't know the container has changed, so the slot still looks empty. But when the slot is actually clicked, the correct stack appears - items are never actually missing, just invisible.

I've tried stepping through the debugger in as many places as I can think of, but the syncing code is really confusing and it's particularly hard to keep track of what happens on the different threads. The main mysteries to me are a) it only happens in such specific situations (it never seems to be a problem when clicking or moving items manually in the inventory - but isn't this all controlled by ultimately the same code?), and b) it only happens in my replacement inventory container, not any of my other custom containers like crafting devices. Mystery b) particularly makes me suspect it's something to do with the way the container is created in the first place - it not being properly linked to the GUI or something? But if that's the case, surely it would never be properly synced, rather than working almost perfectly except for a handful of particular cases?

I'm really stuck on this, and it's frustrating because it's a comparatively minor issue that seems almost impossible to find or solve. Can anyone help?

All the code is on github. Probably-relevant parts:

 

Edited by Jay Avery
Posted

An update: I found that the server-side container didn't have the EntityPlayerMP as a listener. Adding this seems to have fixed the above problems but now another one has started. When loading a saved world, the client doubles the player's inventory contents. So if the world is saved with a stack of sticks in the inventory, then when the world is loaded there will be two stacks. But this is only client-side, and as soon as any slot is clicked the extra items disappear and the inventory resets to the correct contents. It seems like the inventory is somehow being sent to the client twice, but I can't figure out where or why this happens. It's hard to track inventory stuff in the code because there are several sub-inventories and also several wrappers and they're all public and accessed in lots of different places. Can anyone help me understand where and how the player inventory is synced to the client when a world is loaded? Or suggest what might be going wrong with this new bug?

Posted

Another update. I noticed that the client-side container was being replaced after the server-side one, and wondered if that was a problem. So I added a check to the PlayerTickEvent (where I replace the containers), and only set the client-side one there, then send a packet to tell the server to replace its own container so it happens afterwards. This seems to have eliminated the inventory-doubling problem without recreating the syncing problems I originally had. So, this seems to be solved, but I'm not happy about it because I still don't really understand what the problem was in the first place. If anyone can enlighten me, or even make a suggestion, I'd really appreciate it.

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.

Announcements



×
×
  • Create New...

Important Information

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