Why do event's get dropped when starting a server?

I’m currently using a bindable event on the server end to hide / show items and or buttons. It all worked fine until I tried using it when the server was starting leading into dropped events. Is there a way to fix this other than setting my transparency to 1 inside of the script itself?

-- Server end - Purchases
for _, button in pairs(buttons:GetChildren()) do
	-- loop trough every button and get every value except 0
	generateNametags(button)
	
	if button.Floor.Value ~= 0 then
		print("Hiding: "..button.Name)
		--displayManager:Fire("hideButton", nil, button) -- 20% of actually succeeding to run
		
		button.Transparency = 1
		button.CanCollide = true
		button.BillboardGui.Enabled = false
		print("Hid "..button.Name)
	end
	
	button.Touched:Connect(function(hit)
		onButtonTouch(hit, button)
	end)
end
-- Server end - DisplayManager
-- manages every piece of display and management happening (you could add a table for logging purposes)
displayManager.Event:Connect(function(action, item, button)
	if action == "ShowItem" then
		showItem(item)
		button.Transparency = 1
		button.CanCollide = false
	elseif action == "PoorItem" then
		button.BrickColor = BrickColor.Red()
		task.wait(3)
		button.BrickColor = BrickColor.new(0,255,0)
	elseif action == "hideButton" then
		button.Transparency = 1
		button.CanCollide = true
		button.BillboardGui.Enabled = false
	end
end)

If you’re running both at the server start (same time), then perhaps attempt to add a task.wait(2) (or a bit less, it just needs tolerance) before firing the event to guarantee that the connection has been made in the other script.

Yeah but what if a lag spike occours?
I’m rather safe than sorry.

I mean, just at the top of the script, the task.wait(2) doesn’t need to be every single time the event is fired, just at the top of the script for tolerance to the other script to file the connection beforehand.

About a ‘lag spike’ at the beginning, the task.wait(2) would only affect, if implemented just at the top (the very beginning of the script), just that thread, and not the whole game.

Go ahead, add a task.wait(2) at the top of the first script (or at the very top of the section you’ve shared) and let me know how that goes. Good luck.

If you’re afraid that your code will run 2 seconds late, you may try lowering the value to see what’s the minimum to guarantee the connection was done (it could be even just like a 0.3 second delay what’s needed, but it’s better to test in big numbers to see if that’s the problem or not in the first place).

Where are you triggering the events in your code? Could we see that bit?

It’s not great practice to just add waits to try and solve race conditions like this, because it’s still possible for the waiting to fail because it’s not event based (e.g. waiting for a required object to load vs waiting a few seconds and hoping it’s loaded by then).

2 Likes
displayManager:Fire("hideButton", nil, button)

This is the commented out part in my code that would’ve fired the function. I’m currently just using it hard coded instead of using the event and it’s working fine.

1 Like

Do you require the DisplayManager module inside the Purchases script?

If so, the DisplayManager’s code should run before the Purchases script’s, which should mean that the connection is created before the Purchases script fires.


Are you sure that events are being dropped? Is it possible that the response you’re looking for isn’t done immediately because of the changes from deferred events? (This causes events to be responded to after each heartbeat, instead of immediately.)

If you want immediate response, I would recommend using a function of a module instead.

1 Like

Thank you, will try using this instead

1 Like

Agreed, however, implementing a structure to wait for a single connection to load would be more complex as in just waiting some time until it has loaded (in some cases it’s necessary, however, in this case that’s just a runtime mismatch, then it’s not really needed since it’s almost guaranteed to run under a similar timeframe than from where it’s being called, in this case). That’s the reasoning behind my suggestion.

Glad OP found what they were looking for.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.