How can I prevent the KeyboardInput event being consumed by keyboard_input_system

[rowanfr]

I'm currently trying to test inputs at low tick rate systems and as one might assume a lot of my inputs are dropping. I believe this is because the KeyboardInput events themselves are being consumed by keyboard_input_system introduced by the InputPlugin to fill the Input resource. To my understanding the default cleanup strategy is to clear events every frame, but with double buffering, so that events from the previous frame update stay available. This makes it to where large tick periods in fixed time systems lead to dropped inputs as they are cleared before they can be used. So the overall question is how can I remove or override keyboard_input_system to where I can manage the keyboard events separately. I understand that at a large enough frame rate or large enough tick period this would cause a great deal of memory to be consumed but I will focus on solutions to that later.

I understand that I could circumvent this issue by creating another system which follows the systems refresh rate for inputs and then just copy the dominant inputs over to the fixed tick rate, but I feel like that ends up being wasteful as we have the inputs I just want to handle them manually. The other solution I could think of was rewrite a similar event which works how I would like as the underlying conversion logic has already been implemented so I don't think it would be hard to incorperate. The last solution is the one I'm leaning toward but I want to make certain there isn't a major problem in what I want that I'm missing or an easier way before I focus on it.

To test what I'm talking about I have slightly modified the fixed time step example given by bevy (Original Here) and written this script based off it:

use bevy::prelude::*;
use bevy::input::keyboard::KeyboardInput;
use bevy::input::ButtonState;


const FIXED_TIMESTEP: f32 = 1.0/2.0;
fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .insert_resource(TickCount(0))
        .insert_resource(AvgRun([FIXED_TIMESTEP;100]))
        // add our system to the fixed timestep schedule
        .add_system(fixed_update.in_schedule(CoreSchedule::FixedUpdate))
        // configure our fixed timestep schedule to run twice a second
        .insert_resource(FixedTime::new_from_secs(FIXED_TIMESTEP))
        .run();
}

#[derive(Resource)]
struct TickCount (u32);


#[derive(Resource)]
struct AvgRun ([f32;100]);

fn fixed_update(
    mut last_time: Local<f32>, 
    time: Res<Time>, 
    fixed_time: Res<FixedTime>, 
    mut frame_count: ResMut<TickCount>, 
    mut run_avg: ResMut<AvgRun>,
    mut keyboard: EventReader<KeyboardInput>) {
    frame_count.0 = frame_count.0 + 1u32;
    let time_since_last_update = time.raw_elapsed_seconds() - *last_time;
    println!("Tick number: {}",frame_count.0);
    println!("time since last frame_update: {}",
    time_since_last_update);

    run_avg.0[frame_count.0 as usize % 100usize] = time_since_last_update;

    println!("Past 100 time running AVG time since last frame_update: {}",
    run_avg.0.iter().sum::<f32>()/100.0);

    println!("fixed timestep: {}\n", FIXED_TIMESTEP);
    println!(
        "time accrued toward next fixed_update: {}\n",
        fixed_time.accumulated().as_secs_f32()
    );
    *last_time = time.raw_elapsed_seconds();

    for ev in keyboard.iter() {
        match ev.state {
            ButtonState::Pressed => {
                println!("Key press: {:?} ({})", ev.key_code, ev.scan_code);
            },
            ButtonState::Released => {
                println!("Key release: {:?} ({})", ev.key_code, ev.scan_code);
            }
        }
    }
}

This code shows the trailing consistency of the fixed time step the current time step counting upward by 1 and allows for the reading of KeyboardInput Events. This demonstrates the consistency of input reading from this system based on the FIXED_TIMESTEP provided. At a tick rate of 0.5 the overwhelming majority of your inputs will drop whereas the closer you get to the frame rate of the blank application that appears the more inputs will be read up until you are 1:1.

[WooterTheTroubleshooter]

I think you could manually clear the input events in a system that runs at the end of the frame?