We have been working on it as a priority. It’s not a simple fix we’ve been ignoring — it’s taken a very long time to reproduce and root cause the actual problem. There is a small update:
Late last week we had a breakthrough and we have a pretty good confirmed idea of the actual issue (no surprise it depends quite a bit on the machine config Studio is running on which is why we’ve had a such a tough time reproducing and also why only certain people experience it frequently)
I’m working with the team today on what it will take to get a validated, permanent fix out ASAP.
Thanks for sharing the video. Yes we are continuing to work on the docking issues and we are aware they can affect the Start View as well. The team has made progress on identifying the root cause(s) and reproducing the issue. This remains a top priority to make a permanent and robust fix — we have dedicated folks working on it.
If you’ve been following or reading along, you would know that they simply had no issue when releasing. The question you should be asking is why they didn’t revert it when problems were discovered, especially as serious as they are. But that has been asked plenty already and they’re saying they’re working on it fixing it. So I guess there’s nothing to do but keep waiting for the fix. And the answer to the poor decision making will forever be a mystery.
The IDE keeps glitching out as well, the text shifts weird, blinks, or disappears for short moments.
The behaviour feels a bit similar to the general docking issues, but it feels as if it has only gotten worse more lately, notable after the copilot feature.
I wonder if you guys know if this issue ties with the docking problem, or completely unrelated.
If you can record a video, I could try to give you more information.
Currently we are actively tracking and working quite hard on these issues:
Docking corruption. This doesn’t happen for everyone and how often it happens depends entirely on the local machine. This was not a regression so it wasn’t a simple bug that could be just rolled back. Our QA and internal teams never had the issue when docking was introduced. Lately we have had more success reproducing internally and now making good progress on isolating the true root cause(s). Temporary fix is to “Reset View” to clear out layout data.
Blank 3D View. This mostly happens when Play/Test is started. This was also not caused by a code change, as far as we can find. It has also been hard to reproduce internally but it’s been easier than docking. Somehow the 3D View thinks it is no longer visible and stops updating. We believe it’s a race condition… a lot of things happen when a play session is started. Temporary fix is to resize the Main Window which will force a refresh. We pushed more fixes for this late yesterday to force visibility and refreshing (while we still try to figure out how the visibility state gets changed)
I understand it’s frustrating when Studio is “glitchy” and difficult to get your work done. It can be easy to assume that’s it’s just a few people tinkering on Studio that don’t care. But I assure you it’s quite the opposite. There are several teams that release functionality into Studio on a constant basis. There’s a team that works on Script Editor, another that works on Explorer, another that works on Ribbon, etc.
It’s no excuse for poor stability or quality and we are serious about improving here. Keep letting us know about your experience and hold us accountable! But hopefully it’s helpful for you to understand why things aren’t resolved as quickly as any of us would like.
Usually what happens is that a plugin dock widget fails to dock (that is no big deal because it can be fixed by clicking “X” on the undocked widget and then rezising the broken docked widget) \/ (In this screenshot I have already fixed the bug)
However sometimes what happens is that the main 3D view undocks completely making it unusable. \/ This usually tends to happen if I have multiple places open (and sometimes happens when I click the play test button). This is a much worse bug because it cannot be fixed unless I close studio
What tends to happen (at least for me) is that the 3D view undocks to a different window and it cannot be brought back. The issue doesn’t appear to be that there is no rendering, but that the 3D view renders in a different window.
Ie. the not rendering bug only seems to be a side effect of docking corruption.
I suspect a potential cause for this bug is plugin widgets (and that plugin widgets appear later when the plugins load instead of immediatly when the studio starts).
I could be wrong though, but I’ve only been been able to reproduce this bug when the 3D text plugin widget opens.
What is curious about when this bug happens is that I already have closed this 3D text widget (and studio should remember that as a preference for other studio sessions) but when the bug happens it does not tend to remember that I have closed the ThreeDText widget previously in another studio sessions and opens the widget instead.
Yeah I think you’re mostly right. We know that the 3D View is being told it is invisible when it is not. We have a fix pending for tomorrow that should prevent the 3D View from ever being marked invisible but the root cause is likely coming from deep within the docking logic.
Since the docking corruption is a very big priority for us, the team is doing a lot of work to understand all these subtle changes that happen when the layout gets changed (which happens in many different ways through a normal usage session)
I am getting this issue a lot, the 3D window turns into a black screen and you become unable to interact or switch tabs. Happens a lot when I have two studio instances open. Is there any temporary fix to disable this seemingly random corruption?
We just released a fix today for blank 3D View when running a Play/Test session. Please let us know if you still see this issue after verifying you are on Studio v573.
My issue isn’t with the grey screen on test but with the docking choosing to malfunction randomly after hitting Stop on a Play/Test session. It will undock the 3d window and blackscreen, requiring an entire studio restart. The issue is the same one illustrated in Noble_Draconian’s video above. It occurs incredibly frequently if I have two instances of studio open
By the way, we deployed a fix for this last Thursday (5/27/2023) and we have gotten very little confirmation from the Community that this issue has been resolved. Our internal reproductions were solved by this fix but we didn’t have a high number of people getting this problem to begin with.
I understand people usually only post when they have problems or complaints but it’s nice to hear if things are working better too.
One issue that has been slightly bothering me is DockWidgetPluginGuis doesn’t seem to have the issue of “windows moving upwards every time studio reloads the last position”, and only seems to be affected by the Explorer, Properties and Output displays.
I’m using 2 monitors for my workspace.
By the way, is DockWidgetPluginGuis not allowed to snap? Windows 10 has the ability to snap windows when you drag them into borders or corners of any monitors, but for some reason roblox doesn’t seem to allow windowed DockWidgetPluginGuis to do so…
Hi, I have just started encountering this issue for the past 2 days now. It’s happening every single time I do a play test and it’s getting pretty annoying now
Not entirely sure how to reproduce it as it seems pretty random. I am unable to scale them in anyway once they get stuck in that position. I left studio with them in normal form, and came back to this.
Is this still a problem for you today? Most people with this issue say it has gone away with v574 of Studio.
If the 3D Viewport is black or rendering outside of Studio, this is docking corruption and we are working on that. Your only temporary fix is to Reset View. Some seem to think it’s related to having multiple monitors and multiple Studio instances running.
