I have a setup like
Lighting=>ScreenGui=>LocalScript
Then I :Clone() it from there to PlayerGui to display it, in response to a keypress from userinputservice event.
Disabling the script, then enabling it sometime AFTER parenting the screengui to playergui, still causes studio to freeze when it is enabled. So it is specifically caused by the script starting to execute, whenever it does, wherever it does. Cant find fix by parenting/cloning/waiting, it always freezes, so the circumstances are not very specific…
This freezes the play solo window.
The script contains no code (First I had code, then I commented it, then I tried an empty script, all have same issue)
I tried changing the name, and replacing it with a new script instance.
Disabling the script prevents freeze (which is strange, given that theres no issues when its disabled, hopefully helps find the cause). But again, only until it is enabled.
The issue is not present on online server, ONLY studio.
If someone knows a simple temporary fix for this that would be nice.
edit: TO REPRODUCE:
Make function that listens for user input (i used userinputservice)
Put localscript in workspace or anywhere else in studio (this HAS to be manual, instancing one thru script doesnt reproduce!)
game.Lighting.LocalScript:Clone().Parent=player.PlayerGui in the event callback
Trigger the input event to execute that oneliner above in play solo
Can you try moving the ScreenGui to ReplicatedStorage instead of Lighting? It was created for the purpose of storing stuff, so might as well use it for that. Tell me if it fixes the bug or not, although I can’t do much to help you.
Did that (as its something I shouldve done anyways), didnt fix the issue as expected (as the issue doesnt begin until the GUI has been cloned into playergui)
Im currently testing my game online as that works fine and doesnt freeze…
game:GetService(“UserInputService”).InputBegan:connect(function(input, gameProcessed)
if input.UserInputType == Enum.UserInputType.Keyboard then
print(input.KeyCode)
game.Lighting.LocalScript:Clone().Parent = game.Players.LocalPlayer.PlayerGui
end
end)
Starting play solo and hitting any key causes dozens of local scripts to appear inside the PlayerGui, which causes extreme amounts of lag if you hold down the key (it’s generating about 60 scripts per second and running them, which in turn causes more to be created etc. etc.). If your script is similar to the one I have above, that’s the problem.
Putting the script into anything like Workspace, Lighting, etc. causes nothing to happen, which is expected since those services don’t run local scripts.
This should only trigger the event once, no matter how long you hold the key down, no?
That looks similar to what I had (I had a ton of other code in the event handler too, but it shouldnt matter).
I dont know if its somehow spawning multiple scripts (which would be a bug, not expected behavior, because its only creating 1), because studio freezes instantly and ill never know.
That’s correct, you have to hit the button more than once. Try adding a debounce to yours to make sure it’s only happening once. If it’s still causing problems afterwords, let me know.
I have other functionality that works the exact same way, and those only trigger once, so that cant be it… (and it would be a bug anyways if the event triggered more than once because it shouldnt) Are you saying that when you press the button once, you experience no freezes?
If so, I might try reproducing this in separate place later today to make sure I didnt miss something.
Issue doesnt happen if script instanced instead of cloned from existing one (even if both are empty). So there is some difference between cloning an empty script, and instancing a new empty script, that triggers the bug.
There is only one script created
The freeze happens the moment the script is allowed to execute, even if delayed by disabling it
The freeze does not happen in a new place, so there is some external factor to it (increased time/memory spent processing scripts and other such things?)
The freeze only happens in play solo (not online, not run server), so its either a studio bug, or the above mentioned external factor exists on the server side (and thus only effective when server and client are merged)
Input handling is NOT related (I just tested this, it happens even if I just clone and parent the script directly)
So all it takes is for me to add this one line: game.Lighting.LocalScript:Clone().Parent=player.PlayerGui
in my main localscript (I only have one…), and it freezes.
If you have some magic tool to download friends-only places, its this one:
To reproduce you would add that oneliner in the Main script in startercharacterscripts (I added it above the main while loop close to the bottom, the second to last one). Or press ‘E’ to open the inventory. In play solo.
It appears that pressing E does not result in Studio freezing, only heavy lag (During which Studio appears to be frozen), after which the inventory opens correctly. Is this what happens for you as well?
Oh you are right, it takes 10+ seconds so I didnt notice (I remember a few times it appeared as if it unfroze for a split second JUST when the window closed)
I did some testing, it appears the length of the freeze has a dependency on how many buildings I spawned in the BuildingGen script when generating the map. It could just be less time left for stuff other than rendering (which would somehow lengthen the freeze…?), or some weird dependency on number of instances, but the former seems more likely.
I initially tried double the buildings, but then it didnt unfreeze in over a minute (so the relationship isnt linear). So I added just a few and that was enough to make the freeze like twice longer.
Theyre spawned/filled on-demand, so its more practical to make a copy every time one is needed (these are pop ups / menus), rather than toggle visibility or position. Some are templates so a single instance wouldnt be enough anyways.
I might just add a toggle for whether the localscripts in the GUIs are enabled/disabled (fortunately the script is just there to set the appearance (colors), not functionality, so turning them off while testing is perfectly fine)