-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making Inputs Flexible #173
Comments
Hi! I absolutely love the idea and will happily accept a PR implementing this. Input mocking, diegetic UI sound like very good use-cases for this. I guess, for the latter #163 might also be relevant. |
Okay, great! Are there any inputs besides mouse movement and mouse clicks that might need to be remappable? Maybe if there are some hardcoded hotkeys, like copy and paste? |
I don't see a clear use case for keyboard input remapping yet, so I'd probably keep it simple until we have such a use case; but at the same time, I don't mind this functionality if it's not a significant effort to implement it. |
It's the same issue. If someone wants to trigger this event (let's say with the gamepad, for example), right now it is hardcoded. The goal here would be to tie all of these to some |
I would strongly prefer this feature. Bevy itself has a weak UI with weak functionality, so this plugin helps. |
Currently,
bevy_egui
uses bevy's input stream directly:bevy_egui/src/systems.rs
Line 73 in dc4ae68
This makes some assumptions that are difficult to work around. I'd like to request that intermediate events are used, so users can supply their own events, while not having to rewrite and maintain their own version of the
process_input_system
.The biggest limitations this would unlock are:
bevy_egui
.bevy_mod_picking
, however I need to be able to pass in cursor events relative to the virtual, raycasted pointer onto a screen in the world.The way I'd see this working is defining an event type for mouse movement and clicks, and reading this event stream in
process_input_system
.bevy_egui
would provide a small disable-able system to forward bevy events to keep the behavior identical to how it works now. Users could then disable this small event forwarding system, and send those events themselves if they need to. Using events would make this fast, and wouldn't have any of the issues associated with command sync points.If you see the merits in this design, I'd be happy to do the implementation!
The text was updated successfully, but these errors were encountered: