When running the game in studio, GuiService:GetGuiInset() is {0,0}{0,0} when called in StarterPlayerScripts:
GuiService GetGuiInset test.rbxl (53.9 KB)
It’s correct in-game though:
4 Likes
The same thing happens with GuiService.TopbarInset. A workaround could be to do something like this:
while (guiService.TopbarInset.Height == 0) do
guiService:GetPropertyChangedSignal("TopbarInset"):Wait()
end
local topbarInset = guiService.TopbarInset.Height
2 Likes
Hey! I’ve reported this issue a while ago:
3 Likes
I had a similar workaround in one of my games, but it prevented Xbox players from being able to play because the Topbar height on Xbox is 0? (I was only checking the Topbar height to determine when it loaded)
Yes, Xbox doesn’t have a top-bar in-favor of the controller menu button being used to open top-bar related features.
TopbarInset is supposed to be dynamic, and you’re not supposed to cache the value on game-start and instead rely on GetPropertyChangedSignal to dynamically update your UI based on it, so this shouldn’t be a detrimental issue for that property. In fact, updating this behaviour would likely require an update announcement as it would probably break a few games expecting GetPropertyChangedSignal to fire on initialisation. In-fact, it would break the example code in the documentation for the function.
For the GetGuiInset function, it is certainly problematic, though, since there is no way to query the value when and only when, it is initialised. Assuming the CoreGui is taking up the top-bar space (and it isn’t literally telling the truth with the empty area return), it’d be nice to see the TopbarInset property fixed too. Although GetGuiInset should be fixed regardless of whether that is the case.
The width is supposed to be dynamic, not the height. I get the height right away to determine whether I should work with the new version of the topbar or not, since I think it’s still possible to use the old topbar with FFlags.
If height > 36, then use the new topbar button style and also connect to GetPropertyChangedSignal on the width.
1 Like
The documentation code sample itself seemingly relies on the behaviour of GetPropertyChangedSignal firing on initialisation since they don’t set any position or size properties outside of the GetPropertyChangedSignal connection.
As for the height never changing, as far as I know, yes, that is the case right now. However, other CoreGui features in the future could presumably make it larger since there isn’t any guarantee on the height to my knowledge. And while I hope that never happens, it is technically a possibility to happen and something to keep in mind. Plus, I was also just mainly commenting on caching the value in general rather than specifically the height to guess the old topbar vs. the new one.
Also already reported here:
1 Like
Thanks for letting me know. I should’ve checked first! Not sure how to delete/lock this post though
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.