Hidable Topbar!

Updates Announcements
#64 
repeat until pcall(function() game.StarterGui:SetCore("TopbarEnabled", false) end) or not wait()
11 Likes
#65

Does not work?

edit: needed more wait than wait()

#66

There should be a flag added to indicate when SetCore can be used. Having to use arbitrary waits feels bad.

3 Likes
#67

It makes me feel naughty.

6 Likes
#68

If by this you mean:

SetCore(“TopbarEnabled”, false)
waiting…
CoreGui finished loading
topbar disabled

then that’d be wonderful.

1 Like
#69

The problem is that the SetCore methods are registered after some yields in the core scripts. The SetCore method has to look up the name in the registration map, and if it’s not found, you don’t know if it’s just not yet registered or if it’ll never be registered. That’s an actual problem since 99% of your errors would then be from typos that you might never find because it just yields infinitely. If you implemented a timeout, then you have to answer the question of how long the timeout should be.

#70

Instead of the corescripts telling the API which methods exist, if the API was the one who kept track of them and the corescripts were on the listening end, that problem wouldn’t exist.

Edit: Oh, if Corecii is correct in interpreting what you mean and the methods are already handled by the API, then what he said: the methods should be registered before SetCore yields for the corescripts.

1 Like
#71

Isn’t it possible to register the SetCore method prior to the yield(s) which saves the changes to be executed once the CoreScript is done loading?

1 Like
#72

It probably is. It’s something I’d like to look into if I ever get time, but VR is pretty fast-paced! Maybe @Garnold the Friendly Intern can do it.

To expand on what this would entail very quickly: all of the methods are handled in the core scripts. SetCore is kind of just a way to communicate with them from developer-level scripts. If we were to register them early, we have two real options:

  • Register them with a placeholder, and any call to it will recognize the placeholder and yield your script until the actual definition is written. SetCore isn’t supposed to be a yield function so this isn’t great.
  • Register them before any yields happen, and refactor the core scripts so that this is possible. It technically should be, but there’d be a lot of work in ensuring that all event listeners are also backed up with checks for existing state, since the code that reacts to a SetCore might actually need to happen after a yield.
2 Likes
#73

Can’t we just have those 2 things added?

  • GetCore("IsFeatureAvailable","TopbarFullTransparency")
    Returns whether a feature is (already) available
  • SetCore("OnFeatureAvailable",callback)
    callback = A BindableFunction which you set the OnInvoke for as event handler.
    (Same mechanic as the callback for ShowChatMessage)
    (which is required because functions can’t get passed trough contexts I think)
    (even if it can, it wouldn’t be allowed as that would allow context increasing hacks)
    Connects the callback to an internal event so it gets fired when a feature gets added.
#74

I’m willing to take a look into it.

7 Likes
#75

Sorry for the long wait, but I finally got around to this. As @baa_aaa suggested, I registered a placeholder setcore function for the topbar, which saves what state you set it to. And then once the actual function that sets the topbar enabled/disabled loads, it uses the state that was set in the placeholder function to determine whether or not to disable it.

tl;dr You wont have wrap setcore in a pcall loop anymore.

13 Likes
TopbarEnabled broken
#76

Any chance mouse clicks will work in the topbar area when the topbar it’s disabled?

4 Likes
#77

If you use UserInputService you can get mouse events through the topbar, though game processed event will be true.

uis.InputBegan:connect(function(iobj, gpe)
	if iobj.UserInputType == Enum.UserInputType.MouseButton1 then
		print("click down", gpe)
	end
end)```

If you meant gui buttons though, I don't believe that is planned.
1 Like
#78

Yes, that’s what I meant.

I was hoping that had changed, because for some reason it is/was intentionally blocked. Someone made a PR that fixed this issue and it was declined with the reason being GUIs not working in the space of a disabled topbar was intentional. Having to disable the rest of the ROBLOX CoreGui entirely to disable the topbar prevents anyone from disabling it just 'cause, so it’s a shame that the topbar was made intentionally buggy to be redundant.

1 Like
#79

I really need that extra space for my game. Those 36 pixels are important to me!

1 Like
#80

The extra 36 pixel shift, even when the top bar is disabled, really throws off my proportion-scaling UI. I literally have to edit sizing in play solo, cut it, stop play solo, and paste it in regular edit.

1 Like
#81

On phones (not tablets) I think this is a problem for UI design.

My controls are at the bottom of the screen, therefore I want to put my menu buttons at the top. I can’t do this nicely with the perfect location being occupied by an empty bar.

5 Likes
#82

That’s been my biggest problem with the top bar since day 1.

#83

Same. The topbar is a wonderful idea because games can rest easy knowing the ROBLOX CoreGui will never interfere with their interface, but if the game is never going to have any ROBLOX CoreGui to cause interference in the first place, it’s not needed, and we should be able to use that space without having to worry about intentionally introduced bugs stopping us.

3 Likes