Frequently, when I finish playtesting the viewport will snap to my second monitor, and if I try to close it it will crash studio
Another things is whatever this is
Yeah keep an eye on it! We did initially release a couple quick fixes that could have temporarily resolved it but the most recent release we felt pretty good about.
It’s tricky with these issues that we have a hard time reproducing internally. We try to get our “best guess” fix out and then hope the Community gives us more information. In this case, we were able to get some additional logging in with the initial quick fixes which ultimately gave us the clues needed to do a more informed fix.
This is exactly the challenge with the docking corruption issues… except it is 10 times more complicated of a problem and even harder to reproduce. But progress is happening!
2 Likes
This is probably docking corruption which is a slightly different issue than the one we resolved last week. We are working on this one but it’s taking a while to fully diagnose. Try to Reset View for temporary relief (but it will probably come back).
1 Like
That seems to work temporarily, thank you
1 Like
Great! I apologize the issue is happening at all. We are doing as much as we can to permanently fix it.
1 Like
The viewport detatching after ending a test play session has been occurring at an incredibly frequent rate for me that it’s making studio practically unusable. I run two instances of studio open at once, one on each monitor. The second instance has about a 20% chance of popping out the viewport and completely breaking everything, requiring a studio restart. Is there any kind of log I can send to help fix this faster, or any way to just turn docking off entirely? I have used the Reset View and it comes back within an hour
2 Likes
Viewport detaching after ending a test play session is still occurring. It cannot be redocked and I have to close studio and ensure that I only re-open studio with only a single place open to prevent it from detaching. This at least, appears to be a good workaround. But it means I can open work in one place.
Cause (for me): Having 1 team-create place open and another place open. Play solo in the team create then stop the game. The viewport detaches. The second place I have open is usually a local place file.
Detaching of any panels is the docking corruption issue which we are actively working on as a priority. While it’s likely highly reproducible for you following those steps you described, it’s likely this is very specific to your machine configuration. Are you on Windows 10 by chance?
We are making progress on a full fix. In the meantime, you should be able to Reset View and work normally until the corruption happens again.
1 Like
I’d like to hop in and say I also experience the viewport detaching when I have two Studio windows open. I’m on the latest version of Windows 10 Pro N (media pack installed) and have two 4K monitors set to 125% scaling. Can add any other details if needed
1 Like
Yes I use Windows 10. Thanks for addressing this bug!
Now game dock is separate randomly when I enter studio
And it’s impossible to do anything at all.
edit: docks dont even reset (ctrl + p >reset view)
Am I the only one who sees the output dock like this?
This bug is really really annoying for me. and sometimes, studio says “there’s problem with docks and need to restart” and after restarting, the docks get reset…
It’s a serious bug and it’s been months already, but it needs to be fixed ASAP
2 Likes
My output just now started doing this today but it’s been a few days since I relaunched Roblox Studio so I’m not sure when the update initially caused this.
To clarify - the output window, when docked, is hidden behind the bottom of the window border.
This was an issue introduced with a Multi Cursor flag by the Scripting team. The flag has been disabled.
2 Likes
My viewport just disappeared just right now (and usually I fix it by minimizing and then restoring the window), I happenned to be switching places and when I opened another place I got the following qt errors via output, I’m posting them to see if the team working on Qt6 has a clue on the cause:
23:44:45.112 QT ERROR: External WM_DESTROY received for QWidgetWindow(0x1f9a9931480, name="Qtitan::DockDocumentLayoutPanelClassWindow") , parent: QWidgetWindow(0x1fa244dd350, name="Qtitan::DockSplitLayoutPanelClassWindow") , transient parent: QWindow(0x0)
23:44:45.112 QT ERROR: External WM_DESTROY received for QWidgetWindow(0x1f9a99313a0, name="Qtitan::DockSplitLayoutPanelClassWindow") , parent: QWidgetWindow(0x1f9a9931480, name="Qtitan::DockDocumentLayoutPanelClassWindow") , transient parent: QWindow(0x0)
23:44:45.112 QT ERROR: External WM_DESTROY received for QWidgetWindow(0x1f9a99307d0, name="Qtitan::DockDocumentTabbedLayoutPanelClassWindow") , parent: QWidgetWindow(0x1f9a99313a0, name="Qtitan::DockSplitLayoutPanelClassWindow") , transient parent: QWindow(0x0)
23:44:45.112 QT ERROR: External WM_DESTROY received for QWidgetWindow(0x1f9491655f0, name="startPageDocumentPanelWindow") , parent: QWidgetWindow(0x1f9a99307d0, name="Qtitan::DockDocumentTabbedLayoutPanelClassWindow") , transient parent: QWindow(0x0)
23:44:45.113 QT ERROR: External WM_DESTROY received for QWidgetWindow(0x1f948f6f3f0, name="QWindowContainerClassWindow") , parent: QWidgetWindow(0x1f9491655f0, name="startPageDocumentPanelWindow") , transient parent: QWindow(0x0)
23:44:45.113 QT ERROR: External WM_DESTROY received for QQuickView(0x1f9487c52e0) , parent: QWidgetWindow(0x1f948f6f3f0, name="QWindowContainerClassWindow") , transient parent: QWindow(0x0)
(I have show QT errors enabled, and I always enable them, there are also sometimes errors about a qt timer, will edit this post when I get that again)
Another info I don’t think I’ve seen, it also affects the 2d viewport on the start screen:
You can still get into a page using the File dropdown
23:54:28.812 ▼ QT ERROR: QWindowsBackingStore::flush: GetDC failed (Invalid window handle.) (x2)
23:54:28.813 QT ERROR: QWindowsBackingStore::flush: GetDC failed (Invalid window handle.)
23:54:29.802 QT ERROR: External WM_DESTROY received for QWidgetWindow(0x1f92b42aec0, name="Qtitan::DockDocumentLayoutPanelClassWindow") , parent: QWidgetWindow(0x1f98ba6c320, name="Qtitan::DockSplitLayoutPanelClassWindow") , transient parent: QWindow(0x0)
23:54:29.803 QT ERROR: External WM_DESTROY received for QWidgetWindow(0x1f92b429f00, name="Qtitan::DockSplitLayoutPanelClassWindow") , parent: QWidgetWindow(0x1f92b42aec0, name="Qtitan::DockDocumentLayoutPanelClassWindow") , transient parent: QWindow(0x0)
23:54:29.803 QT ERROR: External WM_DESTROY received for QWidgetWindow(0x1f92b42a4b0, name="Qtitan::DockDocumentTabbedLayoutPanelClassWindow") , parent: QWidgetWindow(0x1f92b429f00, name="Qtitan::DockSplitLayoutPanelClassWindow") , transient parent: QWindow(0x0)
1 Like
Hey there – can you take a look at your Studio version and share that back?
Unfortunately I can’t access my laptop right now, but I believe it is the latest version (since before I launched, Studio decided to update first, or well in my case, it decides to install itself again, I don’t know why Studio keeps reinstalling itself)
I’m still being forced to reset my widget dock layout occasionally:
We have a fix going out this week in v577 that we are feeling pretty good about. It will not force a reset but rather prevent the corruption from happening with hopefully no side effects. If all goes well it will be live at some point on Wednesday 05/24.
Please let me know if you see a difference.
4 Likes
The update accomplished nothing.
It still throws an error and forcefully reset the damn layout!
On restart, it reverts my app to windowed, layouts all messed up.
Now if I lay all my layouts again and go into fullscreen mode, it’ll be reverted on the next restart without any error. Plus the dock layout error is becoming more frequent…
Jokes on you, I never dock any of my windows, it’s all floating just how I like it.
This is frustrating…