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.
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).
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.
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.
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.