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.
2 Likes
Why would you have so much global variables anyways. _G is not recommended to be used. Just use a regular module script or local variables.
2 Likes
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.
2 Likes
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.
3 Likes
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.
1 Like
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.
2 Likes
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?
2 Likes
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?
2 Likes
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.
1 Like
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?
3 Likes
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.
1 Like
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?
1 Like
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.
- Save the file as a
.rbxlxplace file.
-
Open the new place file in a 3rd-party editor such as VSCode.
-
Search for
_G._Gin the file until you get to the source:
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.
1 Like
A fix for this issue has been deployed, please verify that you can now open your place files.
6 Likes
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).
1 Like
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.
1 Like
I’m not sure if the fix broke something but no one in our team can open Studio for a specific place, it just gives us this error:
. 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.
2 Likes
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?
2 Likes
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.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.