This is great, it was always a pain to test sometimes because of how my pc is on the lower-end.
Thanks roblox 
12 Likes
Good day, will the issue with closing place will be adressed?
The plugins have no way of detecting when you close the studio and they cannot make a cleanup.
That can mess some things up and it makes harder for the plugin developers to prevent this
10 Likes
Finally it’s being fixed, looking forward to it.
6 Likes
5 Likes
I have a map with nearly 300,000 parts that used to take 15 minutes to publish.
Now it only takes about 10 seconds.
THANKS SO MUCH!!!
6 Likes
Ever since the last studio update I’ve been experiencing a performance decrease when switching windows during a local server play test, I’m not sure if it’s directly related to this but I’m getting the launch UI for it.
Here’s a video
11 Likes
I just opened some places, did not expect them to load so fast, can’t even press the cancel button on smaller places now, you could add a cancel button which shows only when the game hasn’t fully loaded yet:
(if it’s possible)
3 Likes
kinda had a goofy bug where the first time i opened it after it getting updating with this feature it just kinda
froze
for a few days?? i couldnt close it either
3 Likes
Relatable, frame rate drops to around 15, pretty sure its intentional
edit* most likely to make it so it uses less resources
3 Likes
:
Got enrolled into this somewhat recently. For opening a root place, I think it makes sense in theory - albeit feels a bit slower.
However for multi-place publishing (e.g. universes with many subplaces) this adds WAY too much friction. Each subplace open takes way longer due to the new UI prompt, stealing mouse focus, and being unable to shift windows until the UI is gone.
Could this be turned off for places opened from within the Asset Manager widget? Conversely, could we get the “Publish Whole Game” flow back (publish all of a universe’s subplaces in one click)? Honestly the latter would be ideal as updating subplaces have a LOT of friction agnostic of this test.
3 Likes
Thanks for bringing this up. It’s a known issue that we are resolving. The two changes have an interaction with timing.
1 Like
Thanks for the heads up! We’re looking to fix this issue shortly.
2 Likes
Seems I’ve been enrolled into this and oh my God the improvement is night and day difference.
Before, I would need 5 minutes to open some of our internal testing places and now I barely get up from my desk and the place is already loaded. Thank you so much for this.
2 Likes
Would it make sense to not have this for local client testing? Unless I’m misunderstanding what this does - having the client half-loaded yet still responsive WRT user input is good for testing edge cases related to latency + loading.
1 Like
Getting the same issue but found a way to temporarily fix the fps drop
Open studio playtest and then go into the roblox menu and change the maximum frame rate from the default of 60 to 240 then it should fix itself (sort of)
It appears that roblox is throttling unfocused windows fps to 25% of the maximum frame rate set, so if the default is 60 then it’s set to 15 fps when unfocused. So if you set it to 240 then 25% of 240 is 60 and it doesn’t give you that 15 fps drop and instead just drops to 60 fps.
Hope this helped!
@MeshOfPaul @tnavarts @bg9
1 Like
That’s intentional, it’s done to avoid hogging system resources while running in the background.
1 Like
Could it just be made into a studio setting? It’s getting into the way of a couple of things like two player testing and using hoarcekat with roact/fusion in vscode because the low fps in studio doesn’t let me see the animations properly. It’s really annoying for people using external editors and a second monitor 
3 Likes
Yeah I agree with what Datasigh said, or at least make it a FFlag that we can disable. This is annoying when trying to record or test a feature that requires 2 players (specifically vfx related) because it makes everything seem laggy for the unfocused window.
3 Likes