For those of you who want to take full control of your games’ interface, you can now disable the topbar. Note that disabling the topbar with this method will also disable Chat, Backpack, and Playerlist. The GUI screenspace is not moved, and the menu button will still exist.
To disable the topbar, use the following code in a LocalScript under StarterPlayerScripts:
wait()
pcall(function()
local starterGui = game:GetService('StarterGui')
starterGui:SetCore("TopbarEnabled", false)
end)
Technical Details
A pcall is necessary because the feature is behind a flag. If we have to roll back, the SetCore call would error, but the pcall would allow your code to continue without halting.
GUI spaces’ origin is still at 0,36 from the viewport render.
The topmost 36 pixels of the game will not trigger gui events such as button presses.
Even when it’s invisible, it prevents mouse input from getting through to what’s below it. It’d be great if that didn’t happen when it was disabled. Other than that, everything’s looking stellar. Thanks!
There are some downsides to this but this is still awesome since it didn’t fit with any of my interface designs. For those complaining about other CoreGuis, you could just make your own, beautiful ones you know.
For now, you could use UserInputService.Input(Began/Ended) to read the coordinates of a mouse click even if it’s within the topbar’s area, and do X if the click is within a button’s coordinates. Mouse.X and Mouse.Y could also be used to detect hover-over.
Of course this is pretty hacky, so it would be nice to have GUI events triggered for stuff that’s underneath the topbar.
We have no input in the space of the ‘missing’ bar, so essentially the problem with top bar still stands.
It also makes absolutely no sense to me why all the core UI elements (backpack, chat, etc) are automatically disabled in order to make the top bar transparent. If the hamburger button can be left in the top corner, why not the other core UI elements? We should be allowed to choose which ones are disabled ourselves like we can when we don’t disable the top bar.
Although it’s nice to see you guys listened to our hate against top bar, I feel like this is merely an aesthetic change and doesn’t offer us much in the way of giving us back the space and functionality that top bar took from us.
So for example, if I want to put a list of buttons along the top of the screen, I am forced to put them down at least 36 pixels on the y-axis in order for them to be clickable. That’s not going to look nice for my UI.
I’m hoping you can address:
Why the topbar region has no input, and whether or not this will always be the case.
Why all the core UI elements are disabled for simply making the top bar transparent, and whether or not this will change in future.
Really this seems like something that should be a boolean under StarterGui rather than part of :SetCore(). Further I still wish that ScreenGuis would be given properties such as size that by default reflect the core gui. That way if we disable the top bar, a screen gui could still suitable use the entire screen without needing to know that it’s 36px (since if this were to change we’d run into issues)
Note that they can’t change the 36 pixels because it would break everyone’s assumption that the screen is offset by 36 pixels.
Also note that this would be very easily resolved if ScreenGuis had the same origin as the viewport (separating them was an awful idea and should just be fixed already).
When I was working on the PR, I actually first reset the offset to (0,0,0,0). (I also saw that for the TenFootInterface, it’s set to that anyway)
It was a bit too tricky to make the settingsbutton be visible in an easy way.
At the end, I just made it set the TopbarContainer’s Active property to false when needed.
Eh, maybe it’s better to get rid of the whole offset situation, athough people would need to get used to it. (Again, because in the beginning, there was no offset, except the 20(?) pixels at the bottom for the chatbar)
