iOS Keyboard in HTML5 Web Preview causes "sticky" conditions.

entersimon

Has anyone else noticed an issue when using the iOS keyboard during a web preview or inside a browser where the touch/mouse button conditions don't release properly?

For example:

Say you have created an actor to be used as a button that once pressed will activate the keyboard behavior. Well, if you're using the touch "pressed" condition then once you come out of the keyboard screen, the game acts like you never released the mouse. It's still "pressing". Same goes for the mouse button up and down. Whichever is the condition used to activate your rules will "stick" until you click again somewhere else on the screen when you come back.

Touch "release" seems to work ok as a slight fix except if you have a mouse position condition being used as well. If this is the case then as soon as you hover over the button after the "release" has been "stuck", the rule will activate.

It seems to be a timing issue inside the actual html because it acts differently in the regular preview in Viewer.

I've tried many, many creative avenues to fix this issue via workaround, but I haven't found anything super solid.

Has anyone else come across this issue?

tenrdrmer

I have never tried it in web preview but honestly Im not sure they thought about web games when setting up the keyboard so that could be screwing things up for you right there. Everyone wanted Device keyboard access. So that behavior prob is not intended for anything else.

entersimon

I get the feeling they did intend it for use in HTML5 games simply because it actually works, and that wouldn't be a straight-forward transposition from Objective C to HTML5. It's just this darn "sticking" thing that's been a problem so far.

I forgot to mention that using input from the actual keyboard (like pressing your space bar for example) as a condition also has the same issue. The game acts as though you're holding the space bar down when you come out of the keyboard screen until you press it again to essentially reset the proper up or down action of the key.

I fear there aren't really many people utilizing the iOS keyboard as a major feature in their games yet, so my voice may end up being a lone one. The game I'm working on will show what's possible with this behavior though. I've been working very hard on it since the day we received iOS keyboard as a feature in GS.

scitunes

I have an educational game as an HTML5 game with quiz question that popup using the pause behavior. Here's how it works: You are driving a red blood cell through the circulatory system (top down racing style) and when you hit a power up it brings the quiz popup. If answered correctly your red blood cell goes faster (raises max speed value). I was going crazy trying to figure out why the game would cause a second quiz pop up immediately after the 1st. It took hours of trial and error but I finally got it to work with some majorly weird work arounds. I thought it was due to the pause behavior, but after reading this I am assuming that it has to do with the keyboard behavior that I put it in to allow players to answer the quiz questions.

So it seems that it is not just user input, but anything that triggered the keyboard event. In my case it was the red blood cell actor overlapping with the power up that then triggered a boolean that triggered the pause scene. Even though I set that boolean back to false and moved the power up out of the scene it still re-triggered the quiz popup.

Hmm... Interesting...

entersimon

scitunes said:
So it seems that it is not just user input, but anything that triggered the keyboard event. In my case it was the red blood cell actor overlapping with the power up that then triggered a boolean that triggered the pause scene. Even though I set that boolean back to false and moved the power up out of the scene it still re-triggered the quiz popup.

Right, and using timers to offset the issue after you come back from the keyboard scene doesn't seem to do the trick either. It doesn't matter what you do with your logic, the conditions become stuck until the user interfaces with the game again to reset the condition input.

This issue isn't present when working on projects dealing with iOS devices, just HTML5. I'm really glad to hear that someone else has encountered this. I've created a workaround for myself that's adequate for what my project calls for, but this isn't the type of issue that can have a single fix for all situations. The fact of the matter is that logic can be correct, but the behavior doesn't respond properly to that logic.

AKA, it's a bug.

It's a bug that's going to cause major problems for newer users if they encounter it. It took me dozens of experiments to find a decent workaround and to find out where the issue actually resided. I tested this issue many ways before bringing it up on the forum because I wanted to make sure it wasn't my own logic that was creating the problem. I'm confident that this isn't the case here.

I'll be submitting a detailed bug report within a couple of days for the GS team to check out.