Docking Updates [Full Release]

Quick thing to try: turn off the Faster Play Solo Beta and see if that clears it up for you.

1 Like

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.

4 Likes

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.

4 Likes

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.

1 Like

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.

2 Likes

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.

1 Like

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.

1 Like

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:

1 Like

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)

screenshot 2024-05-02 at 12.15.15

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.

1 Like

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.

1 Like

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.