You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Registering custom input kinds with CentralInputStore seem impossible. It's documented to do so
/// This plugin is added by default by [`InputManagerPlugin`],
/// and will register all of the standard [`UserInput`]s.
///
/// To add more inputs, call [`CentralInputStore::register_input_kind`] during [`App`] setup.
pub struct CentralInputStorePlugin;
During App setup the CentralInputStore, once it's been created, will be inside a resource inside the world inside the app, but register_input_kind require a mutable reference to the app in order to add a system.
This is impossible because you need to hold a mutable reference to the App and to the CentralInputStore which is inside of it at the same time, exactly a situation the rust borrow checker is designed to prevent.
Expectation
How do you intuitively expect this to behave?
Instead provide a method that takes the App, the control kind, and the UpdatableInput type, finds the CentralInputStore from the App, mutates its state as necessary and then adds the system to the App (while no longer holding a mutable reference to the CentralInputStore at the same time).
The text was updated successfully, but these errors were encountered:
Which feature is frustrating to use or confusing?
Registering custom input kinds with
CentralInputStore
seem impossible. It's documented to do soDuring
App
setup theCentralInputStore
, once it's been created, will be inside a resource inside the world inside the app, butregister_input_kind
require a mutable reference to the app in order to add a system.leafwing-input-manager/src/user_input/updating.rs
Lines 43 to 46 in 54a361b
This is impossible because you need to hold a mutable reference to the
App
and to theCentralInputStore
which is inside of it at the same time, exactly a situation the rust borrow checker is designed to prevent.Expectation
How do you intuitively expect this to behave?
Instead provide a method that takes the
App
, the control kind, and theUpdatableInput
type, finds theCentralInputStore
from theApp
, mutates its state as necessary and then adds the system to theApp
(while no longer holding a mutable reference to theCentralInputStore
at the same time).The text was updated successfully, but these errors were encountered: