Huh, That is odd and I’ve never seen that happen and Studio doesn’t take that much memory so I’m highly suprised.
How much memory does your computer have?
My computer has around 15.8 gigs of usable memory
yes I restarted my PC (which is MORE than capable of running studio and most games at max settings) so no apps were running. I have a total of 4 hard drive and my operating is running off of my fastest SSD.
I’m not sure I want to go into my code yet and make changes like you suggest. Everything was workign just fine up until yesterday morning and I already rolled back any code I changed since that point and it still does it. So what I am saying is my code has been running fine for months, now suddenly studio take forever to close Play testing.
Well, I have spent the ENTIRE day on this!
I have disabled ALL code in my game, including modules being required.
There is no code running in my game whatsoever and it still take over 1 minute to end studio play test.
I really need help to understand what is going on with this. As it is, I spend over 10% of my workday waiting for studio play test to close while testing various parts of code. If use studio play test 30 times in one day, thats a full hour of my day waiting for it to close!
This happens consistently on several machines and for different people who are also working on the game. It does not happen to all places I own, but it happens to this one that I am actively working on. I have tried to publish the place into another place, and the issue persists.
As I said above, I have at one point disabled all running code in the game and this problem persists. I have rebooted my PC, made sure there are no other app running. I have re-installed studio. I have removed assets we don’t immediately need.
I question my ability to even finish my game at this point. Feeling stressed, need help! Thank you 
EDIT: on a positive note, I have been squeezing in a few sets of pushups while waiting for it to close!
1 Like
Thanks for the report! We’ve filed a ticket to our internal database and we’ll follow up when we have an update for you.
5 Likes
@Planet_Dad are you still experiencing this issue. Does this also happen on a new empty project?
1 Like
Yes I still experience this issue and I cannot use Play or Play Here to test my game for months now without having to wait a long time for close. While wait times to close the session used to be upwards of 5 minutes, they are now lower and sometimes happen in about 30-45 seconds, but sometimes longer.
It is far faster for me to your Studio Server Test, that starts up and closes much more reliably, the only issue is missing the Play Here so I can get places quickly.
It does not happen on all game I own, just a few of them.
1 Like
I have also been experiencing this issue for the last couple of days. I have tried uninstalling Studio multiple times and it does not seem to be helping. It would seem other players are having this same issue too.
2 Likes
Thanks again for the report. I found the ticket we filed internally and there are reproduction steps for what may be the same issue. According to the repro steps, this can happen if a plugin calls BindToClose() and then wait(). It’s unclear to me if this is the same issue you are experiencing or when we will get to fixing the issue we reproduced ourselves.
In the meantime:
I saw you tried disabling/uninstalling all plugins. Did you also delete the plugins in your local plugin folder?
I’d also suggest removing the contents of all your BindToClose calls and then, if this resolves the issue, incrementally add the content back in until you hit the delay to help identify which line of code is causing the slowdown (if it is indeed due to BIndToClose like you suspect).
3 Likes
I Am also having this issue, I disabled my Soft shutdown script but it still is occurring what’s going on?
1 Like
I get the same issue when I remove my scripts. May be a cache issue.
For the OP, I honestly don’t know what the problem could be, and game:BindToClose only checks if the game is shutting down or not, it’s weird that that function call would slow your game down.
1 Like
Yeah it still happens to me. I have tried so many things but as crazy as it sounds, I have come to accept that Studio is what it is. I no longer use Play or Play Here to test, I only use Studio Server testing and while it take longer to load and east up my time, that’s been my life for months now.
1 Like
I’ve been having this issue around the same time as you all, it consumes so much of development time and decreases productivity. I disabled all plugins and scripts to see if it would repeat and it sure did.
Still having this issue even at the time of writing, ROBLOX Support has been completely useless when it comes to assistance with this.
EDIT 1: While searching around DevForum I found out that people have been reporting that the FastCast module is causing such long loading/re-loading times (because it uses a lot of the advanced new Luau features). I just removed it and the issue has been fixed.
2 Likes
This has always happened to me, every computer I use
Started in early 2019
2 Likes
That’s interesting about FastCast, I had been experiencing this issue in some of my games but not all.
So I went in and found that the games having the issue did indeed have FastCast module so I removed that module and the issue is GONE!
@chippermonky I think this issue is related to the Luau type checking included in FastCast module, but while the owner of that module should indeed look into why it might be causing this, perhaps on Roblox’s end you guys could do a little looking into it as well.
@EtiTheSpirit You might want to look into this as well, it seems several of us have had this issue and when we removed FastCast, it resolves it for us.
2 Likes
This is something out of my jurisdiction completely, as far as the core concept of the script goes. It’s not impossible, however. It’s only a violation of the standards the script wants to follow.
If I want to completely nuke standards - and this is a solution you could implement yourself too - I could change the --!strict at the head of the script to --!nonstrict or even --!nocheck (though nonstrict should be more than enough) and it would likely fix the problem. I do not have the capability to test this right now, and unfortunately cannot relay any results to you. This is a known fix for other type checker related problems however, so I have some score of confidence that it will work.
I will be honest with you, I am not happy with FC in its current state and plan to rewrite the entire module from scratch in the coming weeks. This should address some of the foolish mistakes I’ve made (there are a couple) and fix some of the bloat the module has acquired over its lifetime.
3 Likes
Hey! By no means was I pointing a finger at you and the FastCast module. Though this is an issue that has impacted my productivity since February and has gone unresolved until now, my hope was that Roblox staff would be able to look at your module and discern why their engine was not liking it.
And while I am not versed in the totality and depth of FastCast, I had hoped/assume it was well enough written to not be the cause. Its quite popular and is used in notable production games.
I guess I would ask you, does type checking add more value than the cost? I personally haven’t had much cause to worry about types in my code design, especially not when using a module such as FastCast with an API. Perhaps the rewrite you propose could do away with type checking?
As a note, I’m not using FastCast right now, its amazing but is far more than I needed in my current case. Therefore it was easy to remove and I dont need any quick fixes right now. THANKS!
Mostly I use type checking as a thing of etiquette. It’s not even functional in the script itself, it’s exclusively for the editor.
1 Like
Thanks for the updates folks. This is very helpful. I’ve updated the new information in our internally filed ticket.
4 Likes