Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[SOLVED] Dedicated Server Gui Refresh Issue [1.15.2-31.2.0]

Recommended Posts

(I initially asked for help of Discord where Gigaherz referenced his transferStackInSlot method which I've tried, however I'm still having issue, so I'm posting here with more context)


I have a few machines with inventory slots and have implemented the whole transferStackInSlot with both my own and then Gigaherz version.

With an internal server moving items manually from the inventory to the input slot of the machine or via transferStackInSlot works fine. GUI updates immediately and there are no visual issues.


I've retested with a dedicated server and client and now things dont work so well.


There are a few issues

* delay between moving the item and the gui refreshing

* original itemstack remains attached to the cursor or with shift-click visually moves to another slot in the inventory


eg. manual version

Drag an item stack of 10 items into the machine slot

Machine starts processing

A few seconds later the destination slot renders the stack (handleSetSlot breakpoint not hit for about 4 seconds on the client)

Stack is still visually in the dragged state and I can place it in the inventory

Double clicking this fake stack makes it vanish.


eg. Shift-click version

Shift click item from toolbar to machine

Machine starts processing, destination slot is empty

A few seconds later the destination slot renders the stack (handleSetSlot breakpoint not hit for about 4 seconds on the client)

Stack visually moves to the player inventory

Double clicking this fake stack makes it vanish.


The 4 second delay to the handleSetSlot seems to line up with the time for the machine to process one item and therefore decrement the input stack size.


I would almost say that the slot numbering on the dedicated server and client are different.

There are no issues with a standalone client and internal server.


Container code https://github.com/Ipsis/Woot/blob/1.15.x/src/main/java/ipsis/woot/modules/squeezer/blocks/DyeSqueezerContainer.java

TileEntity code https://github.com/Ipsis/Woot/blob/1.15.x/src/main/java/ipsis/woot/modules/squeezer/blocks/DyeSqueezerTileEntity.java


I know I've overlooked something but I completely stumped as to what.

I had other issues related to dedicated server which I've fixed  when  registering of the containers.

So any pointers as to what might be going on here.




Edited by Ipsissimus418
Add handleSetSlot comments
Link to post
Share on other sites

Been doing some more debugging - including a completely fresh Intellj checkout.


Items being inserted via a hopper while the gui is open work correctly - probably because they modify the destination stack size.

You can correctly remove (manually or shift-click) an item from the machine inventory.

The issue is limited to items going into the single slot of the machine either via mouse drag or via shift-click on the item.


I've rewritten the container slot handling and the tlle entity inventory using other people's code as an example but nothing seems to fix it.


It looks very much like when the item is dragged into the machine slot via the gui, then the slot update packet is not being sent to the client. The update only happens when something else causes the machine inventory stack to change eg. item processed, that the client is refreshed. And even when that happens only the destination slot is refreshed, not the source slot or the dragged stack.

(And by that I mean that I've broken it in some way).


Link to post
Share on other sites

After a good day of debugging I have my answer.

Server was working perfectly.

It was the client that was failing.

When the client was processing the Container.slotClick it does the following



        Get a full stack and try to insert it into the IItemHandler

            calls isValidItemForSlot which on the client was returning false.


My isItemValidForSlot looks up the recipes loaded on startup to see if the item is a valid input. When running with an internal server, this input item list was being created by my code by the server part. However on a standalone client, it was always empty as the server code isn't there to fill it.

Therefore the client updated the gui with a an empty itemstack as the item wasn't valid.


My transferStackInSlot also used this input item validation code, which is why it didn't work.


By removing this input slot validation just now, then it all works. So back to adding some code to make the validation work on both sides.


I hadn't appreciated that the item validation was being performed by client code, but that seems to be because the client is refreshing the stacks to show the user in the gui. The server only corrects those stack if the client shows something that is out of sync with its knowledge.


Well that is my understanding of what is going on, so I go and fix my code and be more appreciative of the differences between the client and server operation.


Link to post
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.

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.

  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • sorry i will talk in english. there is the debug.log of server and the client debug.log debug.log
    • Aww thanks i guess... Makes sense now.
    • I showed you that code...    it was this, and your 'complained' about the deferred register name, then went on about Objectholder (which to be fair was only there because the ONLY other example of doing this wasn't exactly knowledgeable as to what was happening or why. I'm trying to figure out why the following works, and the example wasn't exactly updated, so i had to use IDE feedback to get it to work properly, and I used setRegistryName as a way to prevent it from using my own name space....    -- To be clear i'm not sure what i did that caused it to work..  but it does Just to be clear  This is sitting where the package says it's sitting.   -mine are sitting in com.dephoegon.reclaim....   package net.minecraft; import com.dephoegon.reclaim.aid.block.sand; import net.minecraft.block.AbstractBlock; import net.minecraft.block.Block; import net.minecraft.block.SoundType; import net.minecraft.block.material.Material; import net.minecraft.block.material.MaterialColor; import net.minecraft.item.BlockItem; import net.minecraft.item.Item; import net.minecraft.item.ItemGroup; import net.minecraftforge.common.ToolType; import net.minecraftforge.event.RegistryEvent; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.registries.ObjectHolder; @Mod.EventBusSubscriber(bus=Mod.EventBusSubscriber.Bus.MOD) public class blockoverrides { public static final Block SAND = new sand(14406560, AbstractBlock.Properties.create(Material.SAND, MaterialColor.SAND) .harvestTool(ToolType.SHOVEL).harvestLevel(0) .hardnessAndResistance(0.5F).sound(SoundType.SAND) , "", "", "", true).setRegistryName("minecraft", "sand"); @SubscribeEvent public static void onBlocksRegistry(final RegistryEvent.Register<Block> blockRegistryEvent) { blockRegistryEvent.getRegistry().registerAll ( SAND ); } public static final Item SAND_ITEM = new BlockItem(SAND, new Item.Properties().group(ItemGroup.BUILDING_BLOCKS)).setRegistryName("minecraft","sand"); @SubscribeEvent public static void registerItems(RegistryEvent.Register<Item> event) { event.getRegistry().registerAll ( SAND_ITEM ); } }  
    • From what I can .. gather, and I'm sure this is my confusion going on..        It has public Objects that are effectively the block registry calls. Wait?  Would it be possible to actually override a public object, and have it use it? ---      I'm not sure I understand,   though the only bit I can honestly gather from that is a string name key, & the block object calling a new instance of a block (sand, log, etc) with properties defined in those block classes, which are often calling abstractblocks for properties, and extending special classes (like fallingblock) which tend to fall onto blocks, then abstract blocks themselves.   perhaps I'm missing the forest for the trees (or missing the trees for the forest), but  I'm not getting how you meant that.
    • Oh hold on, I forgot about the refresh gradle option. I refreshed the project and it downloaded new jars. That's weird, the last time I opened the workspace and started the game, it was working fine. Sorry for wasting your time. 😓
  • Topics

  • Who's Online (See full list)

  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.