Gamepad 8Directions

Problem Description

When you set the gamepad axis to simulate controls for the 8direction behavior, the result is that the player can only move diagonally.

I used the "gamepad 0 axis Y < 0 = simulate up" thing for up, down, left and right.

Attach a Capx

[attachment=0:3h8xnvnz][/attachment:3h8xnvnz]

Description of Capx

Very simpe Capx, just a sprite with the 8direction behavior, and a gamepad, that is set to handle controls on the event sheet.

Steps to Reproduce Bug

• Step 1: run the game
• Step 2: activate gamepad by pressing any button and try to move vertically or horizontally..
• Step 3: fail to do so, and instead move only in diagonals.

Observed Result

the sprite can only move in diagonals, for some reason it can't move just up, or just left, it is always both axis at the same time, even with the deadzone to over 90. If you disable half the events, however, you can move up or down, or left and right. but with all 4 lines active. only diagonals for some reason.

Expected Result

to be able to move in at least 8 directions.

Affected Browsers

• Chrome: YES
• FireFox: don't know
• Internet Explorer: it doesn't even detect the gamepad...

Operating System and Service Pack

Windows 8.1 x64 latest updates.

video card up to date as well.

Construct 2 Version ID

Release 198 (64 bits) checked.

This is not a bug. it is an issue with how you handle the directions. It is nearly impossible to get a joystick pointed to exactly 0 degrees on any axis when a player is using the controls. Using the values you are to define the direction will almost always result in 2 directions being selected. What you need to do is set your test value to something other than 0. If you test the Y-Axis between say -10 to 10 then if the player is trying to move to the left or right but the joystick is slightly above or below the X-Axis (which is almost a guarantee) it will not register the Y-Axis. The farther from 0 the less likely the joystick has to accidentally register an undesired axis. You will want to play with this value until you find an acceptable value. Be aware though that this also means the user has to move the joystick farther before the desired direction is registered as well.

— and that is why the gamepad object has a deadzone parameter. And in this case, even with the deadzone at 99, the problem still occurs.

If you use not a Xbox 360 controller then it could be this the reason. I have the same problem with my old analog gamepad.

I'm using an original xbox 360 controller...

I used a similar code for one of my games:

http://gamejolt.com/games/adventure/arc ... ndy/31814/

And it works as intended...

Edit: my bad, I took a look at the code and instead of checking "gamepad 0 left analog Y axis > 0: move down" I'm using "gamepad 0 left analog Y > 20: move down". I think I had a similar problem so instead of using the gamepad object's deadzone I change the 0 to 20. Up would be "gamepad 0 left analog Y < -20" for instance...

I also tried (long before posting this bug report) to change the value inside the line instead of using the deadzone parameter, and no luck there either.

btw, i'm not stuck or anything because of this problem, i used a workaround that works like this should work.

I'm setting the player angle to the stick angle / 8 , and the speed using vector X and Y in the 8direction behavior based on the stick axis value.

However, i'm still pretty sure this is an actual problem with either the plugin in chrome, or the plugin in C2.

Closing as not a bug. The gamepad plugin uses a radial deadzone, not an axial deadzone. So when you push the stick a radius of 90 in any direction away from the center (since you specify an analog deadzone of 90 in the given .capx), then you "unlock" the full precision of both the X and Y axes. For example moving it upwards as carefully as you can will eventually exceed the dead radius of 90, and then return a position something like (-0.01, -90.01) since it is nearly impossible to position the stick so that it measures exactly zero. Since you simply test positive or negative values, in this case the error on the X axis registers horizontal movement and makes them move diagonally.

The workaround is really simple: change your events to have an axial deadzone. Just compare < -25, > 25, etc. instead of comparing to 0.