local char = script.Parent
local plr = game.Players:WaitForChild(char.Name)
local buildMess = plr.PlayerGui:WaitForChild("BuildMessage")
buildMess:Fire("You cannot build in that location, red outline shows this.")
Client code meant to detect the event and create said message:
bind.Event:Connect(function(mess) --client access to messaging
print("Recieved an Event")
if dDebounce then
print("Doing the message!")
message(mess)
end
end)
Issue:
Nothing happens, I don’t even receive “Received an Event”
Not even when I do this:
I would include more code, but whenever I Ctrl+C and Ctrl+V into the reply box, I always get weird extra separating lines and quotes are replaced with (& quot ; ) Ignore spaces
Here is what I mean
local char = script.Parent
local hum = char:WaitForChild("Humanoid")
local buildComs = game.ReplicatedStorage.Build
local plr = game.Players:WaitForChild(char.Name)
local buildMess = plr.PlayerGui:WaitForChild("BuildMessage")
local mouse = game:GetService("Players").LocalPlayer:GetMouse() --i need to know where he is going to build
local ingame = plr.stats.isInGame
local isBuilding = plr.PlayerGui.FlatUI.BuildMode.LocalScript.Building --from the gui
local camera = workspace.CurrentCamera --so i can store our outline and make it client based
local buildrange = 45
local cost = 5
local wood = plr.stats.ShopValues.Wood
local woodHP = plr.stats.Attributes.WoodHP
local rot = 0;
local canBuild = false; --for the terrainlimitations
local terrainLimit
local debounce = true;
I don’t really know where else to put it. Would you put it in replicated storage? And I wanted it to be more organized…
Is there more in the event receiving script that we can’t see? You could create a pastebin with the script or save the game as a .rbxl and then upload it here instead of trying to paste it in. There’s little help we can do without seeing any more of the script.
Rather than adding prints inside your event, try adding them outside. The way you’ve connected the BindableEvent doesn’t have any issue at all, so I suspect the primary issue is that some piece of code is obstructing the event from being hooked. Add a print above and below both the bindable fire statement and the event connection.
local char = script.Parent
local plr = game.Players:WaitForChild(char.Name)
local buildMess = plr.PlayerGui:WaitForChild("BuildMessage")
print("Preparing fire")
buildMess:Fire("You cannot build in that location, red outline shows this.")
print("Fired")
and
print("Connecting event")
bind.Event:Connect(function(mess) --client access to messaging
print("Recieved an Event")
if dDebounce then
print("Doing the message!")
message(mess)
end
end)
print("Connected")
You may want to post a bug report regarding this if you have a confirmation that this is the case. That being said, BindableEvents should and do work in PlayerGui perfectly fine. In fact, I created a quick repro to test and the event was being received. It strings back to my original concern that it’s a part of your implementation and not the utilities themselves.
Well, the only thing I changed in my scripts was the location of the Bindable Event. After that it worked smoothly. So unless there was too much clutter in the PlayerGui folder for the bindable event to fire, I dunno what’s going on…
And before you comment, I had checked profusely in the original script (before I moved the event to PlayerScripts) that the location I was specifying was correct.
Things don’t magically work if you change the location, aside from if the location is the very reason causing obstruction (such as putting an item in the wrong part of the hierarchy, like ServerStorage and trying to use a LocalScript on the object). There’s definitely an implementation problem that’s not being addressed. The root problem still exists, moving an object to another container isn’t a magical solution.
“Clutter” doesn’t prevent an event from being connected or firing. Checking is not enough, intensive debugging and rewriting at times is also required. There’s an implementation problem because BindableEvents are not incapable of working in PlayerGui.
Well, you can see the code and the massive amount of pictures I left. If you think there was an implementation problem, or still is, you can check.
If you want me to create a #development-support:requests-for-code-feedback post then I will, but I don’t really know how it could be an implementation issue when all I did was change locations of the event, change the location in the scripts and then it started working again.
What could the root problem be? The different container did end up being my magic solution, none of the code has been changed other than variables containing the event’s location (Now in “PlayerScripts”).
There is no such thing as magical solutions. I am almost certain that your code did not suddenly start working simply because you changed containers, there’s an underlying problem that I can’t determine and will probably need a physical file to play around with.
It would probably help for you to post a code feedback thread for code improvements so that the system actually does work, whether it’s direct improvements to the code or changing the implementation pattern.
Perhaps in the intended implementation, placing it in StarterPlayerScripts is fine, however what specifically I don’t agree with is
A. Saying that BindableEvents don’t work in StarterGui.
B. That something magically started working because of a container change. The problem is the code, not the location of an object. It’s just an object, the code is what gives it “life”.
