Bug? Gamepad input being received but not triggering actions.

Greetings! I'm new to Construct 3, and I've just been poking around my first little game experiment. I've abstracted the input scheme into boolean variables like Control_Left, Control_Right, etc. This way I can attach multiple events (using an OR block) to the setting of the boolean and be able to support different input types. I was specifically after allowing both Keyboard and Gamepad objects to control my little escape pod character.

What I'm seeing is this: the Keyboard object triggers the boolean change just fine. This, in turn, triggers the actual character movement. So far, so good, right? Well, the Gamepad object does NOT trigger the boolean change. Now, when I'm in the debug view, I can actually see that the Gamepad object itself is receiving input from the gamepad. Button values are being sent to the engine and are showing up as being pressed, but those button values do not trigger the boolean change. Thus, my little escape pod dude doesn't move.

I've posted a short video to YouTube demonstrating this. It's short (1:22) and has no sound. It shows the relevant part of the event sheet and then shows the debug view. I demonstrate the receipt of input values from the Gamepad object (it changes between receiving button values 14 and 15, which are left and right on the D-Pad), but no motion happens. Then I hit the left and right arrow keys, and the little escape pod putters left and right as it should. Here's the vid:

Also, here's a screenshot of my event sheet showing the section of abstracted logic. To note, while I'm only showing left and right logic, this same scheme is replicated for up, down, jump, and shoot, too. All inputs act the same: Keyboard triggers the action with no problem, but Gamepad does not"

Anyone have any insight as to what's going on? Thanks!

Further info: this worked earlier this week. I've kept the editor open over the past few days without performing any functional changes. When I went to demonstrate my progress to a friend, I noticed that the gamepad input was no longer working. Keyboard still worked, though!

You are using a mix of two different event types - for gamepad you have "On button pressed", and for keyboard "Is key down".

"On pressed" is a trigger, it fires only once when you press the key. "Is key down" is a continuous condition, it fires every tick while the key is down.

Normally for actions like character movement you need to use "Is down" events, and for actions like activating a button or firing a weapon you use "On pressed".

Thanks for the reply! But, I've actually tried to change the trigger between the two ("on down" versus "on pressed"), but it reacts the same, unfortunately. And, there's this part which I mentioned above to consider:

Further info: this worked earlier this week. I've kept the editor open over the past few days without performing any functional changes. When I went to demonstrate my progress to a friend, I noticed that the gamepad input was no longer working. Keyboard still worked, though!

The logic per above worked without issue a few days ago, with no actual change in the event structure.

For movement buttons you need to use "Is" conditions - Is Button Down and Is Key Down. Try this:

Gamepad Is Left button down
OR Keyboard Is Left key down
	Set Control_Left=true
ELSE
	Set Control_Left=false

For movement buttons you need to use "Is" conditions - Is Button Down and Is Key Down. Try this:

> Gamepad Is Left button down
OR Keyboard Is Left key down
	Set Control_Left=true
ELSE
	Set Control_Left=false

Please see my previous reply. I have tried that and it behaves the same as with the original, posted event sheet sample.

At this point, I'm more curious if this is a bug in Construct that I need to report on up, or if this is something that others have encountered that has a simpler fix.

I am not aware of such bug in C3, but there are definitely logical mistakes in the screenshot you posted. Can you share your project file, or an updated screenshot of events?

I was able to fix it!

I found the mention of the Github bug repository in one of the pinned posts, and I was preparing my bug report entry when I noticed the suggestion to strip down the project to something bare-bones. I did, and I still saw the behavior as indicated.

But then I rebuilt *just* the movement scheme from the ground up, and it worked. I narrowed it down to the OR block keyboard input, not the gamepad. When I have the Keyboard "OR"'ed in to the logic per my first screenshot, the gamepad buttons do not trigger the response. When I separated it out, it also didn't work, but that helped me catch the logic error: "Keyboard OR NOT <- is down" was overriding the entire thing. "If the Keyboard <- key isn't down, set the boolean to false". Basically, when this key isn't pressed, don't go anywhere. That ensured that *only* the keyboard input would work, which was my logical error in there.

I tried to switch the keyboard triggers to "Keyboard On <- released", but I didn't see that as an option. I only saw triggers to detect "on down" or "is pressed". I tried again and noticed that "on released" appears as an additional condition only some of the time. I was clicking / wasn't clicking somewhere, and the options weren't available to me because of whatever I was doing. I'm still not sure what I was doing wrong when I wasn't seeing "on released" as an option, but that just means I'll have to poke a bit more to see what was I was clicking / not clicking in those cases.

Regardless, with "on released" set for the keyboard, it works as intended.

Here's a screenshot of the functioning logic:

To note, while the screenshot doesn't show it, I'll probably be swapping over to "is down" for the Gamepad, per your suggestion. I want to maintain consistency. In my case, though, both "on pressed" and "is down" should (and do) work with the gamepad. On pressed should trigger the boolean to TRUE, and it should remain TRUE (and thus, keep the character moving) until the button is released, which then triggers the boolean to FALSE (which stops the player). However, I think I prefer the more explicit intentionality of "on down" instead.

Thanks for your suggestion!

...here's the screenshot? (it didn't seem to post in my previous reply)