Xbox360 triggers not working?

chainsawpenguin

New member
Installed a new instance in a new project, and the controller works fine for locomotion, free look, etc. For some reason, the triggers are not working (Fire1 and Fire2); I've double-checked that they're set up in the Inputs.
 
I have the same problem on a pc. They don't work when I hit play, but if I pause the game and then unpause, they work. Although I did notice that the hold jump force variable got forced on even if I just tapped the jump button.
 
I don't have a controller to test against but can you insert some debug statements within UnityInput.GetAxis to determine the axis value when the Fire1 trigger is down?
 
UPDATE: I've confirmed that as TimeStrafer said, if you Pause the game in the editor and then Unpause, the triggers both work. This would imply that something isn't being initialized correctly, right?

-----------

UnityInput does not have a GetAxis function, but PlayerInput.GetAxis is never called (or, at least, my debug logic never prints anything):

/// <summary>
/// Returns the value of the axis with the specified name.
/// </summary>
/// <param name="name">The name of the axis.</param>
/// <returns>The value of the axis.</returns>
public float GetAxis(string name)
{
Debug.Log("my name is " + name + " and my value is " + GetAxisInternal(name).ToString());
return GetAxisInternal(name);
}


/// <summary>
/// Internal method which returns the value of the axis with the specified name.
/// </summary>
/// <param name="name">The name of the axis.</param>
/// <returns>The value of the axis.</returns>
protected virtual float GetAxisInternal(string name) { return 0; }


/// <summary>
/// Returns the value of the raw axis with the specified name.
/// </summary>
/// <param name="name">The name of the axis.</param>
/// <returns>The value of the raw axis.</returns>
public float GetAxisRaw(string name) { return GetAxisRawInternal(name); }


/// <summary>
/// Returns the value of the raw axis with the specified name.
/// </summary>
/// <param name="name">The name of the axis.</param>
/// <returns>The value of the raw axis.</returns>
protected virtual float GetAxisRawInternal(string name) { return 0; }


In UnityInput, I added Debug messages to GetAxisInternal and GetAxisRawInternal. The first is never called, no matter what Axis is affected. The second is only called on Horizontal or Vertical input (the left joystick). It is not called at all when the left or right trigger is depressed (and, weirdly, it's also not called when using the right joystick for freelook).

I have Rewired, but the default integration setup prefab is not mapped to the default UCC mapping, so it effectively breaks MORE components of the controller (it disables the right joystick, disabling freelook).

If we can simplify the case to "make the right trigger (Axis 10) on the xbox controller fire the Assault Rifle when pressed", I can use THAT solution to dope out the rest of the problems. I just can't find where exactly that check happens.
 
Last edited:
Oops, GetAxis is within StandaloneInput, not UnityInput. This will be called by the Use ability when checking input.
 
Last edited:
GetAxis is never called.

GetAxisRaw is called, but not for Fire1 or Fire2. Just to be sure, I filtered out all of the things that ARE calling it:

public override float GetAxisRaw(string name)
{
#if UNITY_EDITOR
try
{
if (name != "Horizontal" && name != "Mouse ScrollWheel" && name != "Mouse X"
&& name != "Mouse Y" && name != "Lean" && name != "Vertical")
{
Debug.Log(name + " is " + UnityEngine.Input.GetAxis(name) + " at " + Time.time);
}
return UnityEngine.Input.GetAxisRaw(name);
} catch (UnityException /*e*/) {
Debug.LogError("Axis \"" + name + "\" is not setup. Please create an axis mapping within the Unity Input Manager.");
}
return 0;


GetAxisRAW is called by everything you'd expect (including Fire1 and Fire2) after Pausing and then Unpausing the Editor.

SUUUUUPER weird...

Any ideas?
 
GetAxisRAW is called by everything you'd expect (including Fire1 and Fire2) after Pausing and then Unpausing the Editor.

SUUUUUPER weird...
That is really strange. Does Ability.CanInputStartAbility get executed before being paused by the Use ability? The InputName will be Fire1 or Fire2.
 
UPDATE: After a build, the triggers do not work. HOWEVER, if you change the focus to a different window, and come back to the game, they DO.

It really looks like an initialization problem. I'm still digging around looking for the culprit.

----------------------------------------------------------------------

My original response to Justin's question:

----------------------------------------------------------------------

Yep! I can see that it's call before the Pause.

I expanded my Debug to see if the trigger was even altering the m_ButtonUp, and I can see that it is always true BEFORE the pause, even if the trigger is pressed, but it correctly cycles between true and false when the trigger is pressed AFTER the pause.

So somewhere upstream of this check, the trigger is just not being read in at all until the editor is paused.

Hmm... tell you what, I'm going to build the Demo and see if it works out of the box with the Xbox360 Controller, or if it also needs a "pause" for the controller to kick in.
 
Last edited:
So before the pause and it always returns true, can you step through the code to see why it is returning true when it shouldn't be? It may be related to the joystick down set that is updated within LateUpdate.
 
Okay, here's my theory (I'm still searching for where this happens, but I think this is it):

The Demo starts with asking the player to select a perspective. However, it REQUIRES that you do this with a mouse. Pausing and unpausing here doesn't do anything, and if the game is paused and unpaused with the perspective selection screen active, the controller is never properly recognized (meaning the Triggers don't work, and, tellingly, the help text says, "Press F1 for controls" rather than "Press back for controls".)

So this screen is enforcing that the keyboard+mouse, and ONLY the keyboard+mouse, are controlling the input. Once you're past this screen, if you don't pause, it never moves out of the keyboard+mouse mode.

If you pause, THEN the game does the check to see if a controller is connected, and switches to that model. Note that it never UNDOES the keyboard+mouse; both will work after pausing.

The reason for this, I'll bet, is that the triggers are AXIS controlled when a gamepad is connected, and BUTTON controlled when just a mouse is used. Since the game is asserting that you'll start off using the keyboard+mouse (because you have to for the perspective selection screen, because the mouse POINTER has to be active), it never bothers with the additional check for Fire1 and Fire2 as Input.GetAxis (or GetAxisRaw, I s'pose).

Since you can, in both modes, change perspective from third- to first-person on the fly (which is one of the highlights of this package), what we really need is a demo that just skips that perspective selection screen, drops you in as first-person, and then advises you on how to switch perspectives in-game. That way the game can run the "is there a controller attached" check on startup, rather than waiting until after the perspective is selected AND the editor (or game) are paused and then un-paused.

I don't have time tonight to plow through unwrapping everything that DemoManager sets up just to remove this screen, but I'll bet the problem is in there somewhere.
 
Tried both, and in both cases you still have nothing from the triggers until the game in the editor is paused.

Hmm... I'll keep fiddling with it. We're reeeeally close to sorting this out. There must be a routine somewhere that says, "Oh, you're using a controller!" and I just need that routine to fire during Awake in the first scene, rather than waiting until after the game is paused.
 
That did it! Added it to line 98 in PlayerInput.Awake, et voila!

protected override void Awake()
{
base.Awake();

CheckForController();


...<rest of the awake function>...
}


@TimeStrafer no idea, man. I only have a 360 controller.
 
Glad that worked! Thanks for helping to debug. @TimeStrafer - yes, this would affect any gamepad connected. This fix will be in the next version.
 
Top