You could do something like this:
local inset, _ = guiService:GetGuiInset()
if (inset.Y > 36) then
--new UI
end
You could do something like this:
local inset, _ = guiService:GetGuiInset()
if (inset.Y > 36) then
--new UI
end
The only way that you can decipher the different topbar version is by looking at the height value from the TopbarInset Property.
If the height is equal to 36 pixels, then itās the current topbar. If itās any different, itās the new topbar.
So I tinkered around, with what @xyrafrost has said earlier, so the workaround for offset UI is to use this as the new y-position:
ExistingYCoordinate+(GuiService.TopbarInset.Height-36))
, where ExistingYCoordinate
is the offset aspect of the UI elementās y-component of its position, and 36
is the current pixel height. Use if the UIās height is greater than 36. Assuming Roblox goes through with this change with no further amendments, this should be a sufficient workaround to update existing UI in which positioning is important.
yes. it makes navigating my game impossible
Why is the hover different on each of these buttons please have some parity, pleaseeee
On a side note tho, converted my old UI to match with this new style. Looks clean, Iām a fan
You should just change the mouse cursor icon instead because
ā¢ It will save (a tiny bit of) performance
ā¢ Itās good practice to change the mouse icon instead of moving a GUI frame to the mouse
ā¢ Itās easier
And if, for some reason, you want the mouse cursor hovering above it, just layer it into the image
I agree that the cube makes more sense but I think I know what Roblox was thinking: the Augmented Reality cube looks cool and hamburger menus are used when the menu is vertical (their menu is horizontal)
they should use a āÆ symbol instead of either one
It seems like another Roblox attempt to force devs to conform their design to their branding instead of allowing creators to have individual branding and UI styles
You should be able to use ScreenInsets None, it removes all insets. What are you using to get the mouse position? Some of the functions are offset for compatibility.
I think, you are using abadoned 2020 UI menu. Just replace a latest menu UI to resolve
PLEASE add some way to disable the second button. Having one permanent button on the screen is enough, especially when the second one just opens a menu full of buttons that can be disabled (excluding the redundant ones that open menus that are found in the esc menuā¦). It makes no sense at all to force the second button to be visible at all times.
it fixed itself a day after lol
EDIT:
tested it out with the V2 version of the menu and yeah seems like it was the root of the issue
really interesting for sure
Iām using a GUI because I want to tween the color of the icon to indicate hits, kills, and other actions. In addition, itās supplementary with some other bars that are featured for gameplay (dash-stamina bar), and Iām currently content with keeping it that way.
So your cursor will be sort of complicated, like an FPS crosshair? I wouldnāt be able to figure out how to do that with mouse icons, unless you make a lot of them
Can we please have the option to choose which side the second button is? Also why canāt we have the option to also make chat separate and whyās the respawn option there instead of a report button?
How would you script TopbarInset? I tried topbarPlusGui.ScreenInsets = TopbarInset
for TopBarPlus but TopbarInset isnāt recognized. Iām not exactly sure how this works, sorry
There is an issue, the topbar buttons are at different positions depending on the screen size which I believe shouldnāt happen. It makes customization and possibly adding own buttons nearly impossible:
(compared with a very large and very small screen)
Not impossible, you just have to use the topbar inset APIs to dynamically adjust your UI.
It doesnāt seem to support the height properly, it is different on smaller screens but the topbarinset is the same as on larger screens.