Events fired at the same time causes UI problems

I am making an Inventory system in my game and found some issues. I have a server side inventory table, which when updated, fires a remote event to player, which updates the inventory GUI. But when I add 2 items at the same time, all the items in the Inventory GUI are duplicated.

On update inventory event, the client deletes all item frames in the inventory GUI, then creates new ones for the changed inventory table.

-- Add an item to inventory.
UpdateInventoryEvent:FireClient(player, inventory)
-- Add some more items to inventory.
UpdateInventoryEvent:FireClient(player, inventory)

If I try to update inventory twice in a row with no delay, item frames in the inventory GUI are duplicated. First event is simply too slow to create new item frames, therefore the second event does not delete the item frames which the first event created, because they are still being created. How do I fix this problem?

Try: wait(0.05)
Its a delay for events firings

What if the player gets 2 items at the same time from different sources? For example, picking up item from the ground and crafting a new item at the same time. I can’t make a delay between two unrelated function calls.

Try replace remoteevent on remotefunction

That is very inefficient. You should almost never invoke a RemoteFunction from the server.

So the easiest method would probably be making all updates go through the same code in the server so you could queue them and add a delay. That’s not ideal though.

I would recommend making your code only update effected frames instead of deleting it every time. A bit trickier, but the best solution and is almost impossible for your current issue to appear. (It’s also best to only send changes from the server instead of the whole table every time if that’s what you are doing)

Deleting and adding new frames on every update can become performance intensive if you’re adding a lot.

But basically you are going to need to add a debounce and a variable that will tell it if it needs to update again after it finishes if you wish to continue with your current approach.

Considering you’re firing the client, they are probably referring to invoking the client, which is fine. You’re probably confusing that with invoking the server, which as you correctly stated is strongly advised against.

If you need a cool down then simply add a debounce.

Thanks for the advice, I already started reworking my inventory system to send CREATE/UPDATE/DELETE events to the client when items are changed, added or removed on the server. So far it works very well.

1 Like