I get how this can be understood as a bug but this is probably a good lesson as to why you should not be using mouse events to register mobile touch input. There are specific events and input data relating to mobile devices that should’ve been used instead; almost an equivalent situation to picking TweenSize(And)Position over TweenService for tween work now (preference for the latter).
Ideally and understandably virtual cursors should still pass this input though since they’re intended to emulate mouse input, not sure if Roblox does that for mobile devices.
This in itself is obviously a bug as of now because it’s unexpected behaviour. Unless they’ve announced a breaking change in advance about how activation input is managed (i.e. this is intentional), it’s an unexpected behaviour and therefore a bug. I get that but that’s not the implication I’m making.
What I am saying is that running into issues like this is a good demonstration of why you should handle input explicitly and properly rather than just using a mouse event to blanket handle all button activation input across devices whether or not they have a mouse input device. Anecdotally, I’ve never had to worry about mouse events suddenly breaking by explicitly acting based on passed input.
I don’t see a problem. If what he’s using now works just fine, then there’s no reason to change it. Have you heard of the saying “If it ain’t broke, don’t fix it.”?
There isn’t a problem. It’s encouraging good practice when handling code.
You are replying in a bug report, so it’s broken. Even then, that saying is honestly moot and complacent. It may work initially but it’s bound to encounter issues like this because non-PC devices don’t actually pass mouse input. It’s better for your growth to take up good practice. Handling mobile input with mouse events is not good practice. “If it isn’t broken don’t fix it” is dismissive.
I’ve been programming for 10 years. How long we’ve been been programming for is irrelevant to the context of the situation, so let’s not start bringing up levels/time programming please.
The point I’ve been making - please read my posts carefully before responding - isn’t implying that there’s a problem, but that it’s bad practice to just assume all devices pass mouse input and use mouse events to handle buttons. There are dedicated events and input types for handling input from other devices that I am recommending instead to circumvent problems like in the OP.
I did not say this wasn’t a bug, it is. I am simply offering advice for better code. Take it or leave it, but don’t provide dismissive responses to it. Constructive replies are welcome though!
The only parts where i use mouse events for buttons is on the events of the button itself, for anything else like input began i use touched, touchtap etc.
The issue right now is that the buttons in the middle somehow do not print mousebutton1 or mousebutton2 on windows 10.
Alright, thanks for the information. I just dived into the repro - probably would’ve been a good idea to do so. I’ve got to make it a habit to check the repro first for a user issue when replying to bugs, lol.
Like initially mentioned the buttons do not trigger InputBegan but part of the problem is actually your own code. Would recommend taking up issues via Scripting Support, if you haven’t, to see if there’s a code-related problem. You can then file a bug report if none is found.
So what’s actually happening here is that the InputBegan events are getting connected to the frame. Since the TextButton overlays the frame, users who tap on the buttons aren’t actually tapping on the frame and thus InputBegan is not getting triggered. If you adjust your code slightly so that InputBegan is getting connected to the TextButtons instead of the Frames:
for i,h in pairs(script.Parent.Buttons:GetChildren()) do
h.Button.InputBegan:Connect(function(typo)
print(typo.UserInputType)
end)
end
script.Parent.LockButtons.InputBegan:Connect(function(typo)
print(typo.UserInputType)
end)
The mouse button events work as intended.
Below are diffs for the changes I made:
for i,h in pairs(script.Parent.Buttons:GetChildren()) do
- h.InputBegan:Connect(function(typo)
+ h.Button.InputBegan:Connect(function(typo)
print(typo.UserInputType)
end)
end
script.Parent.LockButtons.InputBegan:Connect(function(typo)
print(typo.UserInputType)
end)
Specific line change:
h.Button.InputBegan
tl;dr Not a bug, it’s an issue with your code. Makes sense if the lock button still triggers inputs but your other buttons do not. Will not move out of the bugs category, just mark it if this resolves your circumstances.
Hold on, in that case i might have done my research wrong, but there definitely is an issue on the mobile side in my game i am 100% certain of that.
I have never edited anything about the mobile code or even changed anything about the game in the past 12 days, yet somehow this still completely broke.
I will research a bit more on what is causing this and edit this post with the new information.
It might have to do with input.changed
Do you think that maybe the root issue is that you may have been relying on an edge case or unintended behaviour in the engine and that your code to begin with was improper rather than a breaking internal change being made between then and now? Just a thought.
It’s not always the case that when a game is unchanged that it suddenly breaks, rather the edge case the game has been relying on has been resolved and thus breaks the code - that might be something you want to fix if so. Input events seem fine as of now so this could be specific to your code and environment, unless others have experienced the same issue - you’d expect there’d be a lot of noise on the thread if so. Right now it seems pretty clear.
Definitely do some investigating into your circumstances and if you can, provide a more accurate repro. If not, then try changing some things around in your codebase and element design.
