Hiya all, I’m currently designing a tablet interface for a bus where you can control route shifts. I have been testing this system and it works perfectly. This all until I started testing with bus spawning and despawning systems where it started to have a very big issue.
It all comes down to the SurfaceGUI of the tablet, which of course is inside StarterGui. On a normal situation (with the Adornee already pre-set), the button clicks work perfectly fine. All clicks are registered and does what is intended to do. However when I set up the spawn/despawn system, which basically sets the adornee and objectValues for the bus to interact with the GUI and vice-versa, I notice that all Text/Image buttons stop working completely. After various debug attempts I concluded that the issue is with the click detection.
This is the behaviour in the normal situation (without the spawn system, Adornee manually set):
And this is the behaviour when the spawn system is active (Adornee is set ingame):
Since this is an issue with the click detection itself (after debugging there is no output after click), I honestly have no idea how I could resolve this.
Could this be an intentional engine design? Or maybe I’m skipping/missing a step?
could you show your part of the code that get the gui and set its adornee?
you may also check your gui and the adornee in the explorer, if you see the adornee is set, right click and choose ‘go to referenced object’ to confirm if it is pointing to the correct one
About the Adornee part, I checked and it’s correctly set. Now the code for the Adornee setting, here it is:
A local script detects the change in the spawning folder and checks if it’s the correct bus (it will be one SurfaceGUI per bus since they will be organised by fleet number:
local buses = workspace.SpawnedBuses
local SAENumberStringed = {}
SAENumberStringed = string.split(script.Parent.Name, "E")
local SAENumber = SAENumberStringed[2]
buses.ChildAdded:Connect(function(child)
if child.Name == "B"..SAENumber then
print(script.Parent)
child.Chassis.Events.SetSAE:FireServer(script.Parent)
end
end)
A server script detects the Event call and changes the adornee:
change the ardonee in local script instead because every player see their own thing
and interactive gui is in their own gui folder, it is not a server thing
Hey, so sorry for the wait. I just got on to try and implement that fix but sadly that didn’t do anything, the adornee shows up like normal but the interactive part is still broken.
how many buses will there be? i am think of another implementation that you may try.
put 10 surface gui into StarterGui, then for each bus, assign one of the gui to the bus
i believe it should work. we then only need to manage which gui goes to which bus.
we could also spawn a surfacegui into LocalPlayer.PlayerGui in runtime for each new bus.
That’s what is currently in place, each SAE(SurfaceGui) has a number that corresponds to the fleet number of the bus. The issue is, ingame the buses will be spawnable by an operator, since this game is shift style. So the buses will be cloned from ServerStorage and then they will have the Adornee set. The adornee is also removed when they are despawned.
Try making sure that at runtime all buttons have their Active property set to true. I have found in the past that these values get disabled for some unknown reason and i have to reactivate all the buttons.
I managed to find the bug myself. The issue was in the buttons themselves, I just noticed now that it was trying to get the value right at the begining of the game, which couldn’t happen since the value is only set on spawn.
To fix this issue I simply moved the variable declaration to when the button is pressed (this script is inside one of the buttons):
script.Parent.Activated:Connect(function()
local bus = script.Parent.Parent.Parent.Parent.Parent.Bus.Value
local event = bus.Chassis.Body.Static.Tablet.LoginManager.AddDigit
print("Clicked")
event:FireServer(script.Parent.Name)
end)
Still, I thank all of you that tried to help with this issue, I will surely use the suggestions that y’all made for future projects .
.