The only thing I would suggest is the ability for players to toggle between the new ui and the old ui. I can see other people struggling with the new ui, as I have been.
I don’t know if there’s a way to do so right now, but I think it’d be great for immersion if we could take out the controls entirely and only keep the Escape menu button/only show the Chat button. Some games aren’t made with a free mouse in mind. I really like this design though.
I think my favorite part of this entire thing is that we don’t have to guess where to put topbar buttons anymore. A most welcome change for me
Please revert these changes. I am now stuck with this UI on every device, even my 1366x768 laptop.
Just so everyone knows,
Using the following code in ReplicatedFirst, you can completely kill the CoreGui (you need to do some tinkering with PlayerScripts though)
game.Players.LocalPlayer:WaitForChild("PlayerScripts"):Destroy()
game:GetService("StarterGui"):SetCoreGuiEnabled(Enum.CoreGuiType.All, false)
This bug used to work as it does now but was nerfed to only working after teleports when the new loading screen was added (you needed a custom teleport screen so it didnt softlock the game)
guess what? this regression of a UI unpatched a bug that got patched 2 years ago! I disclosed this in January and it never got fixed!
Glad to see this issue finally being addressed. Constantly activating my microphone on accident due to its positioning above my avatar was such an annoyance.
please make the topbar customizable for devs, make us be able to toggle features, make the inset smaller, remove the circle around the roblox logo and so on
New experience controls are great and I’m looking forward to them going live, but I did notice one issue today with the Self View controls when I accidentally opened it during a Play Test of a project. Please see “Self View Issue Report” below for details.
P.S. I would have posted this in the bug report subforum but I don’t have permission to do so, so I hope that you’ll accept the following report here instead
Self View Issue Report
1. Issue
1.1. Summary
Opening self view controls causes a significant erroneous rise in memory usage which I presume is due to some memory leak in the new top bar.
UPDATE 1:
I take it back, it looks like this might be a C-side issue instead? The memory leak only occurs when Motion Tracking is enabled. Opening Self View with motion tracking disabled doesn’t result in the same behaviour and does not suffer the same memory leak.
Disabling motion tracking seems to suspend the memory leak but does not deallocate, and re-enabling motion tracking resumes the memory leak.
UPDATE 2:
Tested on an Mac Pro M2 running Sonoma 14.4.1 out of interest and could not reproduce the issue
1.2. Reproduction
Note: Closing the self view controls did not reverse and/or allow for the memory to be deallocated, RAM usage continued to climb regardless. However, the mem was slowly deallocated when the play session was closed which is why I’m presuming it’s due to the
new experience controls.
Please note that you should see UPDATE above for why this initial assumption was wrong!
-
Open a new studio session in a blank place and start a Play Test session
-
Enable live view through experience controls - ensure that the “Motion Tracking” option is enabled (seems to be enabled by default so you may not have to do this manually?)
-
Wait & watch as RAM usage skyrockets
-
Disable Motion Tracking and note that (1) no memory is freed and (2) that no new memory is allocated
-
Re-enable Motion Tracking and note that erroneous memory allocation resumes and the RAM usage will start to climb once again
-
Stop the Play Test session and note that the memory is slowly freed
1.3. Associated files
1.3.1. Video(s)
Youtube Link: https://youtu.be/YjEkccNF2bk - see the “See Video Timestamp breakdown” detail section below for a breakdown of what’s happening if you’d prefer to scrub the video
See Video Timestamp breakdown
-
Timestamp 00:00 → 00:04
- Starting Play Test session
-
Timestamp 00:05 → 00:07
- Self View opened with Motion Tracking enabled
-
Timestamp 00:08 → 00:16
- Memory leak shown, see RAM usage climb approx. 1GB
-
Timestamp 00:17 → 00:24
- Motion Tracking is disabled, note that memory does not increase whilst disabled but it is not deallocated
-
Timestamp 00:25 → 00:33
- Motion Tracking is enabled again, and we reach 5.2GB of mem usage
-
Timestamp 00:34 → 00:45
- Toggled Motion Tracking again to show that this is a repeatable step
-
Timestamp 00:46 → 00:50
- Self View is closed whilst Motion Tracking is enabled but mem usage continues to climb, we reach ~7GB of mem usage by this point; this does not seem to have an upperbound, the highest I reached was 20GB before I decided to force exit the app
-
Timestamp 00:51 → 01:02
- Closing Play Test session to show that mem is slowly deallocated
1.3.2. Image(s)
Task manager image:
1.3.3. Memory log file from Console
Note: See
CoreMemory->default
for the memory hungry offender
19-06-24__self_view_memoryleak.log.txt (45.9 KB)
1.3.4. Studio log file
I didn’t want to add it here since it contains host information and request traces but I have saved the Studio log file that was created during the attached video. I would be happy to send this to you if needed via DM, feel free let me know if you need it.
2. Background
2.1. Roblox Metadata
-
Channel:
zbeta
-
RBLX Studio Version:
0.629.0.6290609
- Any additional Fast Flags: None applied
2.2. Hardware information
Highly doubt it’s needed but:
- OS: Win 10 Pro Version 22H2 (OS Build 19045.4529)
- CPU: AMD 5950x
- GPU: Nvidia 3070
- RAM: 32gb DDR4 @ 3600Mhz
2.3. Motion tracking related hardware
- Webcam: I did not have my webcam connected to my device when Self View was accidentally opened, and it remained disconnected for all subsequent tests
Will developers still be able to hide all buttons (except the Roblox icon) if they choose to, like in the legacy UI? In the older version of the updated experience controls a few months ago, these buttons could not be hidden, even when StarterGui:SetCoreGuiEnabled(Enum.CoreGuiType.All,false)
was set. There are some times where I prefer nothing to be on the screen except for the Roblox icon. I also feel that having another button for reporting is redundant because it can already be accessed by clicking the roblox icon.
Way not
- make it smaller or add a api to choose properties like transparancy image and color maybe a service in the data model like what we can do with the chat like size from 40 to 36
- Do all in the ESC menu button like if you double click it opens the ESC menu or something but so we have only one button
Im busy with on the left side make some buttons to toggle the chat and between some other menus a map and some pannel I only should have the chat and emotes and voice into that if we can make it smaller it can fit with my size chat since it’s not conflict other menus
O and the pin items not save at first and if you rotate your screen it does remove one
@workbloxing Will this mean the VR bug with the new top bar insets gets resolved? Its been several months and VR breaks completely whenever playing live versions of the game using this improved notch system.
I cannot play without getting distracted by that new humongous size menu button…
I second this. We have almost no control over core gui rn and it’s pretty frustrating
For the last time - we do not want the topbar “reserved size” to be increased from its current size!
There is no rationale for this. OK, you can claim it’s better for mobile but this simultaneously results in a much worse desktop experience.
There’s also the fact that the new UI looks like an eyesore and can’t be disabled to the same extent as the current CoreGui (where everything bar the menu button can be turned off).
Please do not go ahead with this update in its current form.
I just wish Roblox would choose a top bar and make it consistent across all clients!!
We should not have to detect what topbar a client has and reactively match our game’s top bar to that.
Meanwhile, we are stuck with a mismatch if we don’t do that.
player joins game, do they have the humongous topbar or legacy topbar?, we don’t know, lets check… if humongous then give humongous custom game topbar icons, else, give smaller icons…
do they have the legacy topbar with right justified button, or new one with only left justified buttons… oh they have the old one, we can’t put a button in the top right corner then… hmmm
oof
not to mention that, this is their ‘good’ example? The game topbar and roblox topbar sizes don’t even match (not that they have to but this was a ‘good’ example):
I have a friend who got a layout that seems to include a screenshot section. It looks like this:
Does anyone know if there is a FFlag to enable it?
Thank you for the transparency!
I actually wasn’t aware of the TopbarSafeInserts API, so I was stressing over the back/forth switching between where to place my topbar icons. Needless to say this API is a far better way for me to manage that, so thanks for mentioning it.
I think a lot of us would appreciate a new StarterGui:SetCoreGuiEnabled() CoreGuiType to enable/disable the second button in the topbar. A lot of the features in there can be found in the menu, and any that can’t have no reason not to be found there, as far as I know.
As both a developer and a player there are times where I’d appreciate the ability to lessen how much of the CoreGui appears on my screen, for immersion purposes.
Other than that, would it be possible to allow developers to insert their own features inside of the in-experience controls (just in case I got the name wrong, the button to the right of the Roblox logo)? It would add a lot of customization to experiences. For example, I could let players access my keybind menu or volume settings inside of it rather than from buttons next to it. I believe this would result in a cleaner UI overall.
what? you’re expecting c-c-color from 2024 modern-day coorporate roblox? C’mon now