We have fixed a known issue with the ModalEnabled property and it will function correctly in the next update.
The fix was turned on today, June 3rd.
Key notes on these changes:
Before this fix, the TRUE value did not work - the controls would always be seen as FALSE
If you have set this property to TRUE in the past and left it in that state, you will need to check your experience to make sure it will work as expected when the fix goes live
If you notice that your mobile controls have disappeared, you will want to check this property
If you have forked your PlayerScripts, you will need to merge the latest changes to use this
This property will eventually be deprecated in favor of a more intuitive/user friendly method, but the old property will still work after deprecation. We will send out additional information and update the relevant documentation to reflect the move to the new property when the updated solution goes live.
For those of you who have posted about this previously on the forums, thanks for your patience as we reviewed the best path forward to support this functionality.
One question: Will this “more intuitive/user friendly method” break the workaround I’ve been using to get around ModalEnabled not working (destroying the touch input UI in the player’s PlayerGui)?
When you turn Modal on in a GUI Property, it makes it so when you’re in first person and if the GUI is visible, you can move your mouse freely whilst it’s still visible.
I’m hoping the new method comes out soon, as ModalEnabled is already hard to work with. Possibly a simple :ModifyModal(args) but instead of it being just mobile commands, it’s everything. (Reset button, leaderboard, emotes, etc)
The current way of disabling all controls is difficult for no reason.
I would really, really like it if Roblox introduced some API that allowed developers to get the actual screen gui object that contains the mobile controls and just set its enabled property to false. We can get them right now just by indexing the player gui. That would also allow devs to set the images of the image buttons that are used on the default buttons.
That would be a nightmare, as a game dev I don’t want to keep editing the exact path / properties I need to touch to achieve this as Roblox updates the core UI.
A future-proof abstraction is definitely preferred here.
I see what you’re saying and might actually agree with you in most cases, but for a lot of people who fork the player module (as I have in all of my major games), it would absolutely be easier this way.
Perhaps creating attributes on the UI’s screen gui object would be a good way to meet in the middle. Bloating API with extra services and properties would be annoying and hard to keep track of, but if the commonly changed properties of the touch UI (button size, Image color, certain properties) were condensed down to attributes, then the Roblox modal could reference those and update the touch buttons as they change, while still maintaining the full control and access devs get when they can reference the gui object itself. I feel like implementing things like TouchEnabled as service properties when the controller itself is written in Lua is just more useless api bloat.
In my opinion, yes. ResetButtonCallback being disabled too early can cause it not to get disabled at all and SetCoreGuiEnabled doesn’t apply to mobile controls. It’d be nicer if it was all under one function with multiple arguments and proper documentation on what they all mean.
What about GuiButton.Modal (?)
It has been broken for days already and doesn’t follow the same fix as ModalEnabled
EDIT: This issue HAS BEEN FIXED… 90% at least- If your TextButton is in any corner of your screen (and it isn’t big enough), the Modal will not work when toggled. Not only that, the Modal toggle doesn’t work on the Dev Console either, And for that i don’t know why- But the Dev Console no longer unlocks your Mouse when you’re in first person
There are certain cases where I’ll check the devforum for solutions on an issue and find it’s a bug that has existed for 3+ years with no fixes. This is one of those cases where I can happily use ModalEnabled as intended thanks to y’alls work fixing it. Thanks for working on this!
Oh hi- While the issue WAS fixed, it didn’t comply with my game’s settings when the update was released, which means that it made no difference.
People here seemed to think it was fixed but not for me??
I already seemed to explain how this can happen but is it still an issue?
Yeah, it is still an issue, you can try it yourself right now and you’ll be the second person to know I’m not crazy lolo
I’m assuming this also has something to do with the Dev Console while you’re in first person, because your mouse still seems to get stuck
In fact, it has been deprecated and I don’t see a convenient replacement.
The current solution is to set the DevTouchMovementMode to Enum.DevTouchMovementMode.Scriptable, but that does not hide the jump button, and it can only be set on the server (setting from the client results in permission error, where the documentation example does it in a localscript)