This should be functionally ready, but I haven't necessarily done my due diligence with the doc strings or self-review yet. I also need to add a new example demonstrating the use of the controller axes. I'll get to that tomorrow probably.

The PR ended up somewhat large, but the changes are pretty straight-forward.

• Now every event kind has a "value". This will be between -1.0 and 1.0.
• If you wanted to implement simple character bindings with an analog stick you could do this:

let input_map = InputMap::<PlayerAction>::new(vec![
    (
        PlayerAction::Right,
        GamepadAxisThreshold {
            axis: GamepadAxisType::LeftStickX,
            comparison: GamepadAxisComparison::Greater,
            threshold: 0.1,
        },
    ),
    (
        PlayerAction::Left,
        GamepadAxisThreshold {
            axis: GamepadAxisType::LeftStickX,
            comparison: GamepadAxisComparison::Less,
            threshold: -0.1,
        },
    ),
    (
        PlayerAction::Up,
        GamepadAxisThreshold {
            axis: GamepadAxisType::LeftStickY,
            comparison: GamepadAxisComparison::Greater,
            threshold: 0.1,
        },
    ),
    (
        PlayerAction::Down,
        GamepadAxisThreshold {
            axis: GamepadAxisType::LeftStickX,
            comparison: GamepadAxisComparison::Less,
            threshold: -0.1,
        },
    ),
]);

• In order to get the f32 threshold to fit inside of the Eq + Hash UserInput struct, I made use of the decorum crate, which has suitable Eq and Hash implementations for floats. Technically we can get rid of the dependency if you want to copy the to_canonical_bits function from the decorum crate.

We really just need a way to hash and compare floats and that would give us what we need.

• [x] I based this off of #151, so I'm going to wait for that to get merged, resolve any conflicts, and then take this out of "draft" status. At that point the diff will become much, much smaller.
• [x] Also, I still need to go over this again and see if I missed any documentation or examples that need to be updated.
• [x] @alice-i-cecile QUESTION: #151 itself seems to be branched off of the dev branch. Should I change the merge target to the dev branch instead of the main branch? (Yes, done)

Resolves #155

Version

9a07bb13f7d77cf6efa4bf78a64d87a6aac1af53

Operating system & version

macOs 12.4

What you did

cargo build

(I was actually trying to run examples but it's easy to reproduce with just cargo build)

What you expected to happen

a successful build 😄

What you think should've happened if everything was working properly.

a successful build 😄

What actually happened

> $ cargo build                                                                                   ⬡ system [±main ✓]
error: no matching package found
searched package name: `leafwing_input_manager_macros`
perhaps you meant:      leafwing-input-manager-macros
location searched: /Users/user/workspace/leafwing-input-manager/macros
required by package `leafwing-input-manager v0.4.0 (/Users/user/leafwing-input-manager)`

Additional information

Hello! 👋

I could definitely be doing something wrong this morning 😅 But it looks like this was missed in the last commit on master. I'm raising this as an issue instead of a PR because it looks like dev is using _ and I'm not exactly sure what the flow is for bugs on main vs things that should be in PR'd to dev.

Thanks!

This makes sure that SingleAxis inputs will report a value of 0.0 if the axis value is not withing the triggering zone. This makes it possible to create a virtual gamepad made up of multiple single-axis inputs on the same stick.

I ran into a scenario where in my game input mapping screen I want to map inputs to player actions such as move up, move down, etc., in a table like most game input screens are laid out. This scenario meant that it's easier to structure the input binding as a virtual DPad, even when the player is inputting analog stick directions, and they could technically put in different axes for different directions.

This commit makes the Virtual DPad output a proper axis pair data even when it contains single axis inputs for some or all of the directions. Before this commit you would end up getting a value of -2.0 when you would move left or down on the stick, and a value of 0.0 when moving the stick right or up, because the input_value() function was returning a value for both left and right stick movement, even though only one of them should be triggering at a time.

Version

0.3.0 Bevy 0.7.0

Operating system & version

Windows 10

What you did

I tried running the press_duration example.

What you expected to happen

From my understating, the player object should "leap" when the left/right key is released, with the leap distance dependent on the length of the keypress.

What actually happened

The player object didn't move at all.

Additional information

I've narrowed down the problem to the previous_duration and the current_duration functions always returning zero.

A minimal example of the issue (edited minimal example)

use bevy::prelude::*;
use leafwing_input_manager::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugin(InputManagerPlugin::<Action>::default())
        .add_startup_system(spawn_player)
        .add_system(jump)
        .run();
}

#[derive(Actionlike, PartialEq, Eq, Clone, Copy, Hash, Debug)]
enum Action {
    Run,
    Jump,
}

#[derive(Component)]
struct Player;

fn spawn_player(mut commands: Commands) {
    commands
        .spawn()
        .insert(Player)
        .insert_bundle(InputManagerBundle::<Action> {
            action_state: ActionState::default(),
            input_map: InputMap::new([(Action::Jump, KeyCode::Space)]),
        });
}
fn jump(query: Query<&ActionState<Action>, With<Player>>) {
    let action_state = query.single();
    if action_state.just_released(Action::Jump) {
        info!("End jump time: {:?}", action_state.previous_duration(Action::Jump));
    }
    if action_state.pressed(Action::Jump) {
        info!("Current jump time: {:?}", action_state.current_duration(Action::Jump));
    }
    if action_state.just_pressed(Action::Jump) {
        info!("Started jump!");
    }
}

What problem does this solve?

In my game I have a camera or a menu, and I want any gamepad to be able to control the menu/camera, but I can only specify one gamepad to be bound to the input map.

What solution would you like?

I would like to be able to specify multiple gamepads that are allowed to send inputs to the InputMap. Something like InputMap::new().set_gamepads(&[GamePad(0), Gamepad(1)]).

[Optional] How could this be implemented?

We could probably switch the associated gamepad on InputMap to be a PetitSet of gamepads instead of an Option and then we would just need to loop through all gamepads when testing inputs.

[Optional] What alternatives have you considered?

~~I could get around this~~ I tried to get around this by adding input maps to a different entity than my camera, adding an input map for each of the gamepads, and then looping through those entities to collect camera movement input, instead of reading from a component on my camera itself.

This issue with this approach is that inputs are detected multiple times if they come from the keyboard, because each ActionState will register the keyboard button as pressed independently, making it impractical to just loop over multiple entities with event handlers for each remote.

Related work

None yet!

I didn't know if the dev branch was scheduled to be merged with the main branch when bevy updates to 0.8. So I forked from main. Let if know if it should be otherwise.

Dependencies should of course be updated when bevy gets updated.

Currently using this pr branch to update bevy_dolly with main and cart:camera-viewports

There are three main use patterns for this:

1. Partition the analog space into digital buttons
   • Handle with a mapping API that sets thresholds/boundaries for the values
2. Map analog values into actions, but still use the raw analog value for something (like smoothly changing walk/run on an analog stick)
   • Actually a special case of 1: You map onto an action, but then get back the analog value that generated that action
     • This can be done with reverse mapping, or with forward propagation
   • Destructuring this value ain't gonna happen
   • But we can return out the values from the virtual button if we store it
   • We actually don't need to return the value itself, just the user input that triggered it (since then the caller can look up the correct value themselves)
   • Requires #76
3. Mapping analog values to an action simply does not make sense (flight stick tilt)
   • Not our problem- can add helper features to bevy_input if necessary
     • In particular, "get a Vec2 from a particular axis" is an extremely common operation that is unnecessarily painful

Eventually this should support:

• all gamepad axes
• touch emulated joysticks
• mouse emulated joysticks

Closes #201.

Note that this doesn't run the examples, but I think running clippy on them gives the best ROI.

Actually running may have several disadvantages:

• It's hard to set up, you'd probably need to get a list of all examples somehow.
• It could reduce CI times substantially, depending on the timeout.
• It is flaky, sometimes it might catch an error and sometimes not.

Also note that this way of setting up CI has the disadvantage that it's not run in parallel. This might not scale well, especially with the examples now.

This incorporates a monomorphizable resource that operates the same as the input component. This allows for input handling not attached to an entity.

Example:

#[derive(Actionlike, Copy, Clone, Debug, Ord, PartialOrd, Eq, PartialEq, Hash)]
pub enum DebugAction {
    ToggleConsole,
    ToggleOverlay,
    TogglePathing,
}

impl DebugAction {
    pub fn input_resource() -> InputResource<Self> {
        let mut res = InputResource::default();
        res.input_map
            .insert(DebugAction::ToggleConsole, KeyCode::F1);
        res.input_map
            .insert(DebugAction::ToggleOverlay, KeyCode::F2);
        res.input_map
            .insert(DebugAction::TogglePathing, KeyCode::F3);
        res
    }
}

#[derive(Debug, Default)]
pub struct DebugState {
    text_overlay: Option<TextOverlay>,
}

#[derive(Debug)]
struct TextOverlay {
    position: Entity,
    clock: Entity,
}

/// Should be called once to setup Gameplay Mode
pub fn handle_input(
    mut commands: Commands,
    mut debug_state: ResMut<DebugState>,
    mut asset_server: ResMut<AssetServer>,
    mut input_resource: Res<InputResource<DebugAction>>,
) {
    if input_resource
        .action_state
        .just_pressed(&DebugAction::ToggleOverlay)
    {
        if let Some(text_overlay) = &mut debug_state.text_overlay {
            trace!("Disable Debug Overlay");
            commands.entity(text_overlay.position).despawn();
            commands.entity(text_overlay.clock).despawn();
            debug_state.text_overlay = None;
        } else {
            trace!("Enable Debug Overlay");
            debug_state.text_overlay = Some(TextOverlay {
                position: commands
                    .spawn_bundle(TextBundle {
                        text: Text::with_section(
                            String::from("Position"),
                            TextStyle {
                                font: asset_server.load("fonts/spacemono.ttf"),
                                font_size: 30.0,
                                color: Color::WHITE,
                            },
                            TextAlignment {
                                vertical: VerticalAlign::Top,
                                horizontal: HorizontalAlign::Left,
                            },
                        ),
                        ..Default::default()
                    })
                    .id(),
                clock: commands
                    .spawn_bundle(TextBundle {
                        text: Text::with_section(
                            String::from("Clock"),
                            TextStyle {
                                font: asset_server.load("fonts/spacemono.ttf"),
                                font_size: 30.0,
                                color: Color::WHITE,
                            },
                            TextAlignment {
                                vertical: VerticalAlign::Bottom,
                                horizontal: HorizontalAlign::Right,
                            },
                        ),
                        ..Default::default()
                    })
                    .id(),
            });
        }
    }
}

This release is planned to center around:

• ~~handling game stick inputs~~
• assorted usability improvements
• clash handling

Issues

• Closes #73

Critical questions

• [x] if we gather axis data into an AxisPair struct, where is it stored?
  • Store as Res<AxisPairs<Gamepad>>, with the ability to extend to other simulated axes
• [x] how are axis-like inputs used to set ActionState?
  • new UserInput variant based on direction partition clamping
  • set value of variant based on AxisPair direction / vec2 / rotation
• [x] if we want to store data in actionlike variants, how do we generate a variant-only Hash impl?
  • This isn't feasible: see #60. We also no longer need Hash 😄
• [x] do we care, at all, about non-enum Actionlike types? If yes, how do we refactor to support this?
  • Nope! See below.

Updates the requirements on xshell to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Version

#284

What you did

Run the mouse_motion example.

What actually happened

The console is flooded with messages:

2022-11-13T19:35:54.363800Z WARN bevy_ecs::event: Missed 345 bevy_input::mouse::MouseMotion events. Consider reading from the EventReader more often (generally the best solution) or calling Events::update() less frequently (normally this is called once per frame). This problem is most likely due to run criteria/fixed timesteps or consuming events conditionally. See the Events documentation for more information.

Workaround

Silence these notifications by replacing your DefaultPlugins with:

DefaultPlugins.build().set(LogPlugin {
  filter: "wgpu=error,bevy_ecs::event=error".to_string(),
  ..default()
})

Huge thanks to Martin for nailing this down: https://discordapp.com/channels/691052431525675048/1034547742262951966/1043564180306919514.

Additional information

This is due to https://github.com/bevyengine/bevy/pull/5730, as discussed in https://github.com/bevyengine/bevy/issues/6589.

I suspect we're also double-counting events.

Hi,

I am not sure if this is a bug/limitation of the current implementation but I encounter some issues with the Actionlike macro being used with "complex" enums: it seems to construct them by default, thus loosing the information.

#[derive(PartialEq, Default, Eq, Clone, Debug, Hash, Copy)]
enum ActionBars { #[default] AB0, AB1 }

#[derive(Actionlike, PartialEq, Eq, Clone, Debug, Copy)]
enum GameAction { Jump, ActionBar(ActionBars), Test(i32) }

First I was "forced" to add the Default trait to my ActionBars enum, but when running, it seems that everytime an ActionBar or the Test variant of the enum was triggered, it was reset to default when passed to the ActionState.

Code that spawns the bundle

commands.spawn_bundle(PlayerInputBundle{
        player: Player,
        input_map: InputMap::new([
            (KeyCode::Key1, GameAction::ActionBar(ActionBars::AB0)),
            (KeyCode::Key2, GameAction::ActionBar(ActionBars::AB1)),
            (KeyCode::E, GameAction::Test(42)),
            (KeyCode::Space, GameAction::Jump)
        ]).build(),
        ability_action_state: ActionState::default(),
        actionbar_map: actionbars_mapping
    });

Actually reading the action:

fn print_abilities(query: Query<(&ActionState<GameAction>, &ActionBarsMap)>) {
    for (ability_state, mapping) in query.iter() {
        for ability in ability_state.get_just_pressed() {
            if let GameAction::ActionBar(ab) = ability {
                dbg!(ab);
                let spell_id = mapping.get(&ab);
                dbg!(spell_id);
            } else {
                dbg!(ability);
            }
        }
    }
}

And in the case of subtypes, it always prints either ActionBars(AB0) or Test(0), even when it should have printed ActionBars(AB1) or Test(42).

Is this a limitation or did I miss something to make this work?

If it is a limitation, I would like to have this as an enhancement if possible.

Thank you

Version

0.5.2 and HEAD

Operating system & version

Win11

What you did

Change examples/mouse_motion.rs:

- .insert(DualAxis::mouse_motion(), CameraMovement::Pan)
+ .insert_chord(
+     [
+         InputKind::Mouse(MouseButton::Left),
+         InputKind::DualAxis(DualAxis::mouse_motion()),
+     ],
+     CameraMovement::Pan,
+ )

and to prevent unwrap() from panicking:

- let camera_pan_vector = action_state.axis_pair(CameraMovement::Pan).unwrap();
-
- // Because we're moving the camera, not the object, we want to pan in the opposite direction
- camera_transform.translation.x -= CAMERA_PAN_RATE * camera_pan_vector.x();
- camera_transform.translation.y -= CAMERA_PAN_RATE * camera_pan_vector.y();
+ if let Some(camera_pan_vector) = action_state.axis_pair(CameraMovement::Pan) {
+     // Because we're moving the camera, not the object, we want to pan in the opposite direction
+     camera_transform.translation.x -= CAMERA_PAN_RATE * camera_pan_vector.x();
+     camera_transform.translation.y -= CAMERA_PAN_RATE * camera_pan_vector.y();
+ }

then cargo run --example mouse_motion.

What you expected to happen

Can pan with Left mouse button.

What actually happened

Nothing.

Which code could be improved?

This API is subtly different: for example, InputStreams::pressed does not exist, while MutableInputStreams::pressed does.

How should this be changed?

We could either verify this manually or introduce a common trait.