Looking good, Luke!
1 Like
I’m so excited. We deserve our 36 pixels!
14 Likes
#36PixelsMatter
This has been a really great month for updates and it’s not even halfway over. Looking forward to the next two weeks!
11 Likes
I honestly thought this would never happen.
I’m very happy about this 
5 Likes
Then turn top bar back on 
3 Likes
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.
Thanks.
30 Likes
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)
4 Likes
cough
/endcough
8 Likes
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).
9 Likes
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)
1 Like
Fixing the offset situation is objectively better.
ScreenGui.AbsolutePosition would normally be the correct way to get the offset, but it’s always set to (0,0). This makes it impossible to get the offset in a future-proof way. The only solutions are to put a (0,36) constant somewhere in your code and hope the inner (upper/left) offset is never changed, or you can compare ScreenGui.AbsoluteSize with Camera.ViewportSize, and once again hope the outer (bottom/right) offset is never changed.
If we assume that the outer offset will remain unchanged, then you can make sure your games won’t break right now by getting the offset in the following way:
ScreenGuiOffset = Camera.ViewportSize - ScreenGui.AbsoluteSize
Then, if the fix goes through, you can transition to using ScreenGui.AbsolutePosition without any problems.
1 Like
Can you guys not disable the chat/backpack on PC/Mac? We have key binds to activate things, and we shouldn’t necessarily need to implement our own custom UI for this.
5 Likes
I don’t know about anyone else but…
I think this was probably the most wanted change of the year and I couldn’t be happier. It enables us to use more precious mobile screen space if we decide to make our games mobile compatible and properly immerse players to our own game with our own UI colours.
hamburger icon at last <3
22 Likes
So all it does is change the transparency? It doesn’t really seem different. Things that should be at the top of the screen are still placed below the transparent topbar that is still there.
You can use a negative pixel offset of 36 pixels on your GUIs to make it seem like the transparent topbar isn’t there at all.
5 Likes
So you can click the guis you place offset, or does it not click? i remember making it offset with topbar, it would not let you click buttons etc.
The Topbar just has BackgroundTransparency 1, but it’s still “visible”.
Since it’s Active property is set to true, it doesn’t let clicks through.
And because PlayerGuis render under CoreGui, this means your buttons won’t be clickable.
2 Likes
That’s really sad though, i wish we were let to use the space.
4 Likes
There is a work around for this though. You can use UIS to get the location of any mouse clicks and compare that location with any buttons you have placed under the top bar. Doing this you can make the GUIs look like they are normal clickable GUIs, it’s just a bit more difficult.
1 Like
Why should we have to work around this by recreating GUI mouse events from scratch? Staff should merge in einsteinK’s PR: https://github.com/ROBLOX/Core-Scripts/compare/master...einsteinK:patch-1
8 Likes