Mousebutton 0 is overriding simulated input on QTE

StephenSoundDesign

I've got a QTE running, and the player has two buttons he can push. Choose the right one and move on; choose the wrong one and see you later. I'm using an AC menu with menu buttons simulating the appropriate inputs. The buttons' click textures both respond to being clicked.

The problem I'm having is that the mouse click is being detected as an input before the button's simulated input has a chance to be. I've gotten half way to solving the problem by modifying the PlayerQTE.cs script with this:

else if (!Input.GetMouseButtonDown (0) && wrongKeyFails && Input.anyKey)  
                {
                    Lose ();
                    return;
                }

With this, clicking the correct button returns a win. However, clicking anywhere else on the screen returns a lose (which is what is returned 100% of the time without the modification).

Any ideas?  

ChrisIceBox

The "Wrong key fails" option is not intended to be simulated.  Try unchecking it, and then simply running your "Game Over" interaction manually when the user clicks on the wrong button.

StephenSoundDesign

By running that interaction manually, do you mean within the script? I'm having trouble figuring out how to get the other button recognized at all. What is the best way to test if the wrong button was the one pushed? 

 

StephenSoundDesign

I can run an "input: check" action for the other button, but clicking anywhere else on or off the menu registers as an attempted input in the QTE that has to be handled. If I could restrict the "clickable" surface to just the areas of the option buttons - problem solved. 

I suspect there's a much more obvious solution to this that I'm missing. It's my desire to keep it within the QTE framework that's complicating things. 

ChrisIceBox

By "manually", I meant just defining your Game Over interaction as what happens if you click on the wrong Button - nothing to do with script.  Change your "Fail" Button's Click type to Run ActionList, and you can define exactly what Actions are run when clicked.

StephenSoundDesign

I see what you're saying, and that does work, but I still have the issue of clicking anywhere on the screen being registered as an "input" to the QTE. My biggest issue is somehow convincing the QTE that a mouse button click is not in and of itself some kind of input attempt.

There may be other methods non-QTE that I can work with, which is my solution for now in the interest of not getting bogged down. I do greatly appreciate the help and quick responses - and I'm loving this tool.  

ChrisIceBox

My workaround was an alternative to the "Wrong key fails" option.  Now that you have the menu button set up, can you not uncheck that option?  I'm getting quite confused as to what exactly you're after, I'm afraid.

StephenSoundDesign

My goal is to run a QTE that uses two mouse-clickable buttons as the input. Through several rounds, it might be one or the other that needs to be pushed. That's why I went the simulated input route - it works when I use the keyboard, but using on-screen buttons has been problematic. It seems that it's registering the mouse click itself as an "answer." 

ChrisIceBox

I see.  I'll look into this - could just be that an adaptation of your code change is all that's needed.

ChrisIceBox

OK. Expect this seen to in v1.50.

StephenSoundDesign

That would be very cool. I appreciate it!