I’ve tried using InputBegan/Ended/Changed and TouchStarted/Ended/Moved. Both of them have these problems:
If you start a touch by swiping the Begin state won’t fire but the Changed states will
When you release a touch there’s a chance that the End state will fire multiple times
If you alternate tapping with two fingers really fast, you can see that Begin will rarely fire but Ended seems to fire multiple times when you release.
Touch events are essential to the mobile controls in Tiny Tanks, we want the player to move with one finger and aim with another. This can’t happen if Touch events fire unreliably.
I’m testing on an iPad 2. The boxes are created on Begin, moved on Changed, and destroyed on End. You should see that when you begin a touch by swiping a box won’t be created because Begin doesn’t fire. To see the second problem in action press down with multiple fingers and release one by one, sometimes multiple boxes will go away because End fires multiple times.
Whenever End or Changed fires without an active box the script will print a warning, which should help you see when it happens.
Wow, so this post just sent me on a day long audit of our input code (in my mind a good thing!) I looked over your example code Ethan and while there is a better way to do what you want, there was a small threading bug in the input code in the engine that can cause some pretty bad inconsistencies (even in a better implementation).
I’ll post an update to your example tomorrow, but one neat thing about touch InputObjects is that it’s the same pointer throughout that touch’s lifetime (from finger down, move, and finger up). So you can compare touch InputObjects to see if it is the same pointer. From here you can see you can make a map with a Lua table that allows you to map a touch to a frame and easily track it’s lifetime. If you have ever programmed for iOS Touch events this is essentially the same concept.
If this isn’t mentioned anywhere in the wiki I’ll update this, or feel free to update as well I guess.