Hello i was trying my game, some buttons use the MouseEnter Event to fire a tween animation to get bigger, then i discovered from my mobile device and the studio Emulator option, that the tween animations wasn’t working.
The bug is that the mouseEnter Event is not working for mobile devices.
I tested this script
The output should print on the mobile Emulator the “Mouse Enter” message. But it only prints the “MouseLeave”
This happened just this afternoon. at the morning every button was working fine. I know that its not just my script, because i just tested the script that script
Mobile devices don’t have a mouse. So technically you can’t hover in them. Some events work on all devices even ones they’re not built for. The MouseLeave works on mobile however the MouseEnter was not designed to work on mobile as it does not have a mouse.
Mobile devices support Bluetooth mouses and keyboards alongside game controllers, therefore, it is expected that the mouse events will work correctly across all platforms.
But it was always working. i know that the touch devices, doesn’t own a cursor icon, but the touch works as a mouse when you tap, when the touch moves, etc.
Its just like when you do the player:GetMouse() on touch, it gives returns you a mouse object, so it have it, and roblox made that because its helpful to port pc games to mobile devices.
This may be working correctly, consider that when you’re selecting a button on mobile, users don’t drag their finger across the screen to select a UI. In addition, touch screen devices have no other input when it’s not being touched, so there can be no “Entered”. With that being said, I’m pretty sure that when you are hovering your mouse over the emulator, it’s not actually simulating the user touching the screen until you actually click. Try clicking and holding as you drag your mouse across the screen to simulate the effect of someone tapping and dragging, then the event may fire.
From my knowledge, when those devices are connected, the game naturally processes the input differently because it’s a different type of device. It’s a device input type rather than a platform enabled feature. It’s like how if you have a controller and a keyboard plugged in, the InputBegan result is completely different depending on what device you’re pressing keys on. Both are still processed, just differently.
That’s because the mobile emulator also emulates touch input, that’s why your cursor looks different. It’s being treated like a finger rather than a cursor so this is expected.
The problem with MouseEnter/MouseLeave occurring for mobile touches is that these events can conflict with other mobile specific interaction methods. MouseEnter and MouseLeave aren’t typically useful when using touch input because there isn’t really a hover state like there is on PC, typically users just press a button rather than drag their fingers around. There is also the fact
Here is an example of MouseEnter/MouseLeave events occuring for touches making implementing a good touch UI more difficult. In this case the poster wanted to use TouchSwipe events to pull out the menu items rather hovering but the MouseLeave event erroneously occuring made this more difficult by causing the menu items to close unexpectedly.
Is there a reason you needed to use this instead of using InputBegan/InputEnded events? Can you post a little of your code to show us what you were doing?
It was because a custom camera required gameprocessed to be used in order to prevent interference from the player movement thumbstick with camera movements.
For the thumbstick in that used MouseEntered, it was designed to allow movement of that stick to influence movement of the camera without the player movement thumbstick (left) to influence it; but if trying to find a solution where one can influence camera movement while the other cannot it would result in problems.
For example if the player was moving with the left thumbstick (normal movement one), then using the other that is supposed to allow for camera movement (which was set to disable the gameprocessed in the camera) both thumbsticks would begin to influence the position of the camera (specifically the movement one).
Basically, what the script did was create an image which pretended to be a button and then when moved that script would act as if the player is panning around the display in the background - allowing camera movement without influence from the movement thumbstick on the left.
To further clarify; the new thumbstick I’ve made is a “weapon fire” one, kind of like the one in fortnite on mobile. So you can move the thumbstick which also moves the camera while firing the weapon instead of the usual tap the screen. - which works much better for automatic weapons.
My game has a weapon thumbstick that sits next to the jump button on the right side of the screen. The other side has a movement stick which is provided by roblox by default.
The game also has a Custom Camera, which is used in order to provide angles that roblox does not have; with this camera in order to work on mobile I must use a GameProcessed to make sure that when you move the roblox default movement stick it does not influence the dragged position of the camera.
The weapon thumbstick is designed so that when you click the ImageLabel it will attach to your mouse X and Y, and allow you to drag it around the screen space. This is done so that it also acts as dragging around the display for movement, if a button is used in this instance or InputBegan it will fire that already existing GameProcessed event in the camera and not allow the screen to be dragged around.
I previously tried to send an event that disables the GameProcessed in the event that you are using the weapon thumbstick; but doing so causes interference if you are trying to move and shoot at the same time.
So, essentially the ImageLabel is using MouseEntered in order to pretend that its a button; the mouse being inside of the label is important because its how the game knows that its “a button” when it really isn’t so that when moved a GameProcessed event is not processed for its movement - but still remains to process for the player movement.
Is there a chance this change will be reverted or was this intended behavior?
If there is a possibility of this being reverted I would like to focus my attention elsewhere, but if not, I’ll make this a top priority of things to fix in my game.
We will revert this change this later today. We will probably stop MouseEnter and MouseLeave from firing on mobile devices in the future as we believe this stops a bunch of unintended behaviour. We will make an announcement before we do that or it will be part of an option to opt in to a bunch of input processing changes.
