Quick thing to try: turn off the Faster Play Solo Beta and see if that clears it up for you.
I do in fact have Faster Play Solo enabled. I just tested it with Faster Play Solo enabled and disabled, and it only happens when itās enabled.
So from my testing, it seems to go perfectly back and forth. i.e. My layout is back ā Layout reset ā My layout is back ā Layout reset. I tried this like 15 times and it always went back and forth.
Hereās a video of it:
Ignore the weird flashing, thatās a side effect of using Roblox Studio on Linux with Wine (Vinegar). Honestly, Iām not even sure if the plugin bug happens on Windows but at least itās easily reproducible.
Worth mentioning that I have around 55 plugins.
That seems to clear up the problem. So I guess the plugin widget docking issue is tied to that beta feature.
Thanks
Sorry to hear you guys have been wrestling with this issue for so long! In hopes that it might help further things along, Iād like to give my input on some options (in no particular order);
A) Hold hotkey to show/hide placement guides
This option could work however it comes along with a few issues, such as the problem of conveying the existence of a hotkey to the player as you mentioned. Usually hotkey activations are not the sole method of performing an action so Iām not sure this solution would be ideal. Still worth considering, especially alongside other solutions. To convey the hotkey, Iād assume keeping it simple such as āHold āCTRLā to hide guidesā being displayed as transparent text in the middle would be enough (though youād need to localizeā¦)
B) Edit Layout mode
The idea of being able to save and switch between multiple presets is very exciting and the fact that this would contribute toward that gives it an edge-up in my opinion.
Considering you canāt save or load layouts right now, it doesnāt surprise me that most developers donāt currently use multiple lol. That being said, Iād be curious to see how this interacts with plugin windows opening/closing. Iām sure it wouldnāt be ideal for players who like to work with dynamic layouts such as those who toggle plugin windows often. If possible Iād like to preserve the on-the-fly nature of docking windows otherwise this would be my preffered option.
C1) Overlay empty regions instead of opening blank windows
My own frustration with the new docking system comes mostly from having to adjust to where everything is once all the empty regions are open since I usually have an idea of where I want to move a window and I lose track of it once the viewport suddenly becomes very cluttered. I think overlaying the regions rather than expanding them might help lessen this friction; Iāve made an example graphic:
With the windows expanded as well itās hard to get a good idea of what your layout will look like with the new addition, often leading to cases where you drag, place, drag again, place again and so-forth until the result is how you like. Depending on the implementation, overlays could help reduce the amount of steps here.
C2) Overlay a docking graphic widget separated from the actual regionsā locations
Similar to the existing widget that shows when you drag over a region to place it on a sub-section of that region, a widget that overlays the regions all in the center of the screen would be my ideal solution. Hereās another example graphic!
In my opinion, this option is the least invasive and produces the least unwanted results but doesnāt have the benefit of being an exact representation like the others do. Since the docking regions are predetermined and donāt change, I think a representation like this might be more consistent than the others since all regions are shown and you can dim regions that arenāt valid.
I know you guys are working with a ton of limitations so I donāt expect any of these to be the be-all and end-all solutions but I hope that your team(s) can get some ideas from these suggestions and figure out something that works for everyone! Cheers.
Yeah that new Beta feature disables plugins to speed up Play Solo start time (by quite a large amount, actually!). But the intended behavior is your panels stay in place but any disabled plugins go blank. Something has regressed there ā remains to be seen if thatās on the docking or faster play solo side but weāll get it resolved regardless.
i think its supposed to prevent corrupion of windows but it just makes it worse but atleast after a while i will get used to it though i would still like for them to bring back old docking
oh also it breaks with roblox studio mod manager (so does playtesting but playtesting errors and exits instead of breaking text) so i have to use the normal bootstraper
Good stuff! Thank you.
We did consider an overlay briefly but itās tricky with the other docking ācharmsā that appear to show you the docking split/tab options. But definitely worth revisiting the idea.
The multiple layouts thing is purely an idea at the moment but I think the way it would work is it would become a snapshot state. So if you saved your layout and then further modified it, you could revert back to the last saved layout or save the updated changes. This might work slightly differently if the āEdit Layout Modeā was also a thing. Switching between different saved layouts would properly hide/show panels as they were when you saved them.
Okay, so I am pretty sure I was enrolled in the Beta (I forgot it was in Beta) for a year. I had my layout, it was perfect. Today I logged in and everything was reset and whatever changes were made have broken docking. Please revert the changes.
I used to be able to dock my output window underneath my properties & explorer windows. The way I would do this is dock the output underneath Explorer and then dock properties to the left. This is no longer possible. Please fix this.
To be honest the best move is probably to just rollback this update and let use hang out until the studio refresh comes out. I dont know if the new UI is a completely separate framework but if it is then this whole docking shenanigans could be fix, resolved and make everyone happy instead of fighting this mess of old code and unreliable changes.
I am no professional so Iām not going to act like my take here is genius but it does seem like a better option.
The full release of this docking update is actively hindering my work. The empty docking layout is disorienting and confusing, docking things sometimes completely crashes studio (no error message) and the layout resets every single time I open a new place without fail even with the āFaster Solo Playā beta disabled. I donāt enjoy having to set up my entire docking layout every single time I open a new place. I do not like posting on the DevForum, but this is a serious mess and has just made using studio extremely difficult for no reason.
Can you DM logs when you experience a crash while docking?
Automatic layout resets should not be happening at all so if you launch Studio and your layout has been reset, logs might be helpful there too. We are finding people are thinking they are experiencing resets due to the Faster Play Solo Beta (which you acknowledged) unloading plugins.
BTW there is some control over the Faster Play Solo behavior:
I would encourage you showing available docking areas without necessarily moving other UI around (or at least not as much UI). Perhaps highlighting edges where space is available, or showing making the āplaceholderā docking areas much smaller.
I personally quite liked the system below (which I can see you still have to some extent, of course)
It showed clearly where I can place windows, gave a specific spot to drag my windows to, etc.
Iām sure there was a problem with that solution that caused you guys to keep working on it.
I think that before you consider making further big changes, you should consider (at least temporarily) solving the (IMO) largest issue with this update: the refusal of studio to properly save layouts. I donāt know why this is, but it makes it feel as if studio is actively working against me. I can deal with the funky windows popping up if I only have to do it once. But I have to do it every other time I open studio, which is frustrating.
The new UI is independent of the docking system, unfortunately.
Those are the ācharmsā that appear within each region but unfortunately thereās not one like that for the overall layout. But maybe we can do something similar.
We have found in all of our testing the saving of layouts to be very stable so Iām actively trying to understand this issue that multiple people are reporting. Yesterday everyone I worked with directly it turns out they thought their layout was getting reset but in reality the Faster Play Solo Beta was disabling plugins at Play Time. Have you disabled Faster Play Solo to see if this resolves your issues with saving?
If you are still experiencing lost layouts with the Faster Play Solo off, the best data we could get would be a confirmed case that you had your layout set, restart studio, and observe the layout is not the way you left it. If thatās happening then log files of that restart session could be helpful.
Thanks to your help, the team has found a Mac specific optimization that would explain the lag and why you started seeing it again. They are going to flip a flag shortly that should improve performance (but could introduce rendering artifacts if you undock the Viewport)
What exact actions trigger a āsaveā of the state? Only upon studio closing? Intermittently? If it occurs again I will find log files.
When I asked our engineering team they said actual save to disk happens on Studio close (otherwise itās gets hairy with multiple instances of Studio open)
My usecase will often have several open studio instances, where occasionally I will resize things on the non-primary studio instance. I wonder if a part of my issue is the order in which I close those instances.
I know Iām probably dreaming, but I wish there was an option in studio settings to disable auto saving and to trigger a manual save for āpowerusers.ā Or something like āsaved layoutsā, similar to Premiere Pro (where they have layouts for importing, editing, and so on).
Having the ability to consistently open studio to a layout I specifically chose would be amazing.
Yeah thatās why Iām kicking around this āEdit Layout Modeā idea. Then you potentially have the best of both worlds: a locked in layout with explicit control over when a layout change is saved. It feels like the right direction in the long run but it will take some time to design and implement.
Having to swap to Edit Layout Mode each time I want to drag around a bit of UI sounds cumbersome. I move small bits of UI (e.g. plugins) around all the time, same w/ resizing things.
I really do think youād get 95% of the way there with the whole manual save workflow for those that actually need it, and leaving the current system for those that donāt.