Is there a default dual-axis deadzone?

[ndarilek]

I think my upgrade to 0.15 is mostly complete, but I'm hitting one small issue. I use actions for navigation from other systems. I have a dual-axis Translate action used from my pathfinding systems that needs to pass very small values (E.g. (0.02, 0.01).)

To avoid updating my transform unnecessarily, I skip processing the Translate option if its value is Vec2::ZERO. Unfortunately it always is, even though the action isn't disabled, and even though I'm explicitly setting its value.

I do reset actions at places on my end, so it's possible I'm still doing something wrong, but all I can think of is that there's a default deadzone being applied somewhere, particularly since my non-translate actions seem to work fine. Is that the case, or should I keep digging? I've searched a bit for "default deadzone" and didn't find anything obvious.

Thanks.

[alice-i-cecile]

Are you sure your Translate action is a DualAxislike? Getting the value of an incorrect InputControlKind will always return the 0 / default value (in order to avoid returning results in these super common APIs).

[alice-i-cecile]

I think your copy-paste failed there :)

[ndarilek]

Here's my action implementation:

#[derive(PartialEq, Eq, Clone, Copy, Hash, Debug, Reflect)]
pub enum NavigationAction {
    Move,
    Translate,
    Rotate,
    SetLinearVelocity,
    SetAngularVelocity,
    SnapLeft,
    SnapRight,
    SnapCardinal,
    SnapReverse,
}

impl Actionlike for NavigationAction {
    fn input_control_kind(&self) -> InputControlKind {
        match &self {
            NavigationAction::Move
            | NavigationAction::Translate
            | NavigationAction::SetLinearVelocity => InputControlKind::DualAxis,
            NavigationAction::Rotate | NavigationAction::SetAngularVelocity => {
                InputControlKind::Axis
            }
            NavigationAction::SnapLeft
            | NavigationAction::SnapRight
            | NavigationAction::SnapCardinal
            | NavigationAction::SnapReverse => InputControlKind::Button,
        }
    }
}

Is there something more I need? I see there are assertions checking that I'm inserting the correct kind--when should I see these trigger if violated?

Thanks.

[alice-i-cecile]

Hmm, that seems correct: you're mapping to a InputControlKind::DualAxis. The panics should occur on input binding, Actionlike::set_axis_pair and Actionlike::axis_pair. It looks like the problem is somewhere else 🤔 It doesn't appear that GamepadStick in gamepad.rs has any default dead zone, so it shouldn't be that either.

[Shute052]

Can you paste your InputMap so we can take a look and see what the problem is?

[ndarilek]

There's no map here. This is for an NPC so it just has the default ActionState, and I manually trigger actions where needed (E.g. pathfinding triggers NavigationAction::Translate which does some sanity checks and updates the transform.)

[Shute052]

If the InputMap is missing, LWIM won't modify the ActionState. So you can debug to see if the ActionState you modified manually was actually changed

One possible issue is that ActionState's methods like button/axis/dual_axis_data_mut won't work when there's not a corresponding Action stored in the internal HashMap. So if you're using them, try replacing them with *_data_mut_or_default variants and see if it works

[Shute052]

See

leafwing-input-manager/src/action_state/mod.rs

Lines 353 to 390 in 15a893a

	/// To insert a default [`AxisData`] if it doesn't exist,
	/// use [`axis_data_mut_or_default`](Self::axis_data_mut_or_default) method.
	///
	/// # Returns
	///
	/// - `Some(AxisData)` if it exists.
	/// - `None` if the `action` has never been triggered (pressed, clicked, etc.).
	#[inline]
	#[must_use]
	pub fn axis_data_mut(&mut self, action: &A) -> Option<&mut AxisData> {
	match self.action_data_mut(action) {
	Some(action_data) => match &mut action_data.kind_data {
	ActionKindData::Axis(ref mut axis_data) => Some(axis_data),
	_ => None,
	},
	None => None,
	}
	}
	/// A mutable reference of the [`AxisData`] corresponding to the `action`, initializing it if needed..
	///
	/// If the `action` has no data yet (because the `action` has not been triggered),
	/// this method will create and insert a default [`AxisData`] for you,
	/// avoiding potential errors from unwrapping [`None`].
	///
	/// Generally, it'll be clearer to call `pressed` or so on directly on the [`ActionState`].
	/// However, accessing the raw data directly allows you to examine detailed metadata holistically.
	#[inline]
	#[must_use]
	pub fn axis_data_mut_or_default(&mut self, action: &A) -> &mut AxisData {
	debug_assert_eq!(action.input_control_kind(), InputControlKind::Axis);
	let action_data = self.action_data_mut_or_default(action);
	let ActionKindData::Axis(ref mut axis_data) = action_data.kind_data else {
	panic!("{action:?} is not an Axis");
	};
	axis_data
	}

[ndarilek]

OK, made a discovery. If I edit the crate source and print the data directly on retrieval I see this:

Some(DualAxisData { pair: Vec2(0.0, 0.0), update_pair: Vec2(0.0, 0.0), fixed_update_pair: Vec2(-0.009882118, 0.029646352) })

That fixed_update_pair is what I need.

I've been migrating gameplay systems to fixed schedules but maybe I'm doing this a bit too zealously? Should I be running systems that manage actions in the non-fixed schedules instead?

Thanks.

[alice-i-cecile]

Nope, that should be fine. The logic added in #522 by @cBournhonesque should handle this, but there's a chance that we have a bug there. Did you add InputManagerPlugin for your action type?

Regardless, you should be able to access the fixed_update_pair data directly via ActionState::dual_axis_data(my_action).unwrap().fixed_update_pair as a workaround.

[ndarilek]

I have .add_plugins(InputManagerPlugin::<NavigationAction>::default()) in my NavigationPlugin so it's there.

I moved all the code back out of the fixed schedules and it seems to be working now. Guessing I probably shouldn't handle input in fixed schedules anyway so I think I'll go with this route.

Thanks for helping me figure this out.