Roblox Studio will always close when you create a localscript and make it have a bunch of global variables in it and it’ll now crash if you exceed the recursion depth. You will have to copy paste this for a while, but soon it’ll literally make studios close instantly (if it gets near the recursion depth) or crash if it exceeds recursion depth.
This happens only in Studio.
This started happening on May 5/24/21 - Monday, after a new update, this issue NEVER happened to me before that time and it’s only affecting me, I basically have this one inactive localscript with a ton of globals and I can’t open any game of mine, I’m literally locked out basically not even able to make any crash reports.
Repro
With a localscript simply do the following:
Create a localscript
Copy paste _G._G = _G._G or _G._G and _G._G or _G._G and _G._G --and so on continuing this…
After a few minutes of many copy pastes, Studio will instantly close when it gets close to recursion depth … if you copy paste too much of it too fast…and you exceed the recursion depth by a lot…then studios will simply freeze and you’ll see the error of (exceeding recursion depth). So just make sure you copy paste close to the recursion depth and that’ll cause instant closure.
This basically will close studios 100% of the time.
So, below in StarterCharacter, I prepared a game for you, simply copy paste spam or _G._G and _G._G --for about 20 seconds on that localscript and itll eventually instantly close.
Any idea on how you’d access a game’s contents when it instantly closes studios, I imagine I’m not the only possible one experiencing this, but it’d be nice to just have Studios work like how it did a few days ago… What else can you do to recover all the other important code in your game when your game is now closing instantly even though it worked fine for months.
It’s not a question about why. But, if you must know, this method prevents all forms of scriptviewing. Now, we don’t need to get into securing remotes and server-sided yes, those are the priority. I just like to have one localscript script-hidden so that if the game’s decompiled…the main script is unrecoverable.
So, with your response though, does this mean I just give up on all games I formerly worked on with this in them…and just that’s it? I did something out-of-the-ordinary and I’m just supposed to be unable to open games now?
I want to know why this recent update caused this to happen for no reason. I want to recover my code at least.
Honestly I think that you should find another way to do what you are trying to do. I don’t think _G is the way to go. People have had performance and bug issues when using it anyways.
This is not an issue with having too many global variables. The issue is most likely caused by how many binary operations you have nested together. In your reproduction, you should get the same effect by replacing _G._G with any other expression.
While it shouldn’t crash, it should raise an error.
Okay sure, that’s good to know before Studios decides to close instantly upon opening it though. I’ll simply remove it if I can just at least open up Studios. I know there’s others who do this too, it’s not just only me. This is a new issue that started yesterday so, what gives?
Well, how is it that studios was fine with it earlier, it was a perfect way to protect a localscript from scriptviewing…how is it that just yesterday Studios decided to be incapable of opening with that, when for many months it was fine? What am I to do now?
There has always certain limit on how deep an expression can be nested before the compiler throws an overflow error in Luau. This recently might have been lowered, or something else might have been changed that caused this new behavior (I’m assuming something was changed since before there would be a compiler error rather than Studio crashing).
Also I would not recommend this as a way to prevent people from viewing your scripts, as it won’t work if someone decides to open the script in an editor outside of Roblox.
Sure, I seen the limit, but as of recently, it causes studios to close instantly. That wasn’t an issue as of several days ago.
The thing is, why are we diverting away from the main topic? How do you open up the studios game if it’s now stuck like this? Why are we talking about the feasibility of the method and just accepting that there’s 0 solution and I’m permanently screwed from here onwards?
The instant closing appears to be due to some beta features, after I disabled some beta features I had enabled before it opened fine. The amount of globals has nothing to do with it, if you replace _G._G with something else (e.g. a local variable name) the issue still happens.
I disabled my plugins and this one terrain beta feature and still cant open the game…am I just screwed and give up? What answers are there as to why this is going on? You seen the clip I shared right?
After testing, Studio doesn’t close until opening the script in the editor. This opens a potential solution if you have another editor like VSCode installed.
Once you reach the source you can remove the line that crashes and save the place file. You should then be able to open the script in Studio without crashing.
You’re right! Outstanding, I gotta get your direct contact, the solution works! Whatever it was, it was probably just an accidental bug that impaired Studios’ ability to handle massive recursion depth in localscripts, from the recent update. So this issue is resolved as of 5/26/21, (Wednesday’s update).
So, after editing the file to remove those variables and you save it as a .rbxl, then theoretically, the game should be good. Okay, that’s a good back-up if in the future an update causes this issue again.
. At first it wouldn’t even show up in “Places” tab of the main place but after i reloaded it displayed the place. I would file a bug report but i don’t have access and i thought this might be the reason for it not working.
Do you have any localscripts or serverscripts in that game that are overly packed or what might be causing it? Can you guys open a regular new baseplate or an old game?
I was informed by a co-developer for our game that they implemented a similar method with many nested statements in a localscript from your post as a method to deter exploits. The odd thing is that while this post is pertaining to an issue that arose from the 5/24/21 update, this issue only started occurring to us on 5/26/21, and not after the 5/24 update, which may make it unrelated.
