Hello, I was playing around with Studio Lite, a Roblox game that allows you to make games on mobile, and I have a slightly laggy script. For some reason it runs well in Studio Lite but the published version freezes. I made this topic in Platform Usage Support because I was thinking maybe it had to do with game settings or analytics.
1 Like
Hi BlueBloxBlast. The most likely cause of a published Studio Lite game freezing, but works ok in Studio Lite Play/test mode is a script that has a loop with no yield, missing a wait() or task.wait(). Studio Lite attempts to protect players from getting locked up by adding a small yield to loops during Play/test mode. But once it is published the protection is gone.
I tried your published game and it seems fine. Maybe you fixed it?
1 Like
Hello, can you provide videos/screenshots of what it looks like?
In studio lite, it keeps going until around 60 seconds before freezing. In the published game it goes 5 seconds.
What can I do to fix this?
Hi. I tried you published game again a couple of times. Seems to last around 2 or 3 minutes, then it disconnects with “Error 291: Player has been removed from Datamodel”. This could be a script that deletes the Player using :Destroy(), :Remove(), or :ClearAllChildren(). You might want to check your scripts for that, but I think it is more likely a memory leak.
To confirm it is a memory leak: While playing the game, chat /console. The Client memory looked ok when I check it. But only the creator/publisher is allowed to see the “Server” memory. If server memory is growing, your game will crash when it reaches around 6000MB (6GB).
A common cause of a memory leak is a loop that creates an instance over and over without checking to see if the instance was already created previously. Here is an example of someone with the same symptoms: Error 291 in my game... How do I fix this?
Hope that helps. Let me know how it goes.
Howdy. When I said freezes, I meant that the amount of blocks in the game stop duplicating. The Error 291, which takes two minutes, was made on purpose to kick the players to reset the server after the part was triggered. And plus it looks more worrisome than Kick(), which was the goal of the game. Making people scared.
Since a large amount of parts can lag the game, that’s probably what it is. Here is the script I used for the part:
script.Parent:Clone()
local part = script.Parent
_G.refresh = false
part.Touched:Connect(function(hit)
if _G.refresh then
return
end
_G.refresh = true
local clone = part:Clone()
clone.Anchored = false
clone.Parent = workspace
_G.refresh = false
task.wait(5)
clone.Anchored = true
end)
Is there anything I can modify this script to be able to do this part?
Hi. I think I see one problem. The first line in your script immediately clones the scripts parent, which includes another copy of the script which immediately clones another copy, etc. etc. It is cloning copies as fast as the server can go, consuming processor time and memory very quickly. The other odd thing about that first line is that the clones never get parented to anything. All of the clones created by that first line take up memory even if they are not parented to anything. If you delete that first line it will be a big improvement.
If your intention is to lag the server until it crashes, that could seem scary for that first player. But if a second player joins when the server is already close to crashing, they will not get much time to play. You can get the same error message (291) using :Destroy() on the player who reaches a certain goal and let the server keep running efficiently for other players to continue their adventure. Just a thought.
Hello, it definitely improved Studio Lite, but for the published version it had no improvement.
Also, my intention was for it to keep duplicating without freezing. The player:Destroy() was just a last touch to scare the player.