Just realized there is a limit to the number of system parameters😂

[newDINO]

My system that went wrong:

fn handle_input(
    mut commands: Commands,
    mut messages: MessageReader<BlockOperation>,
    mut block_changes: ResMut<BlockChanges>,
    mut large_objects: Query<&mut ChunksMap>,
    mut chunks: Query<&mut ChunkTypes>,
    mut small_objects: Query<(
        &mut SmallBlocksSize,
        &mut SmallBlocksTypes,
        &mut CornerOffset,
    )>,
    transforms: Query<&Transform>,
    body_handles: Query<&RigidBodyComponent>,
    special_block_entities: Query<&SpecialBlockEntities>,

    block_properties: Res<BlockProperties>,

    mut bodies: ResMut<RigidBodiesRes>,
    mut colliders: ResMut<ColliderSetRes>,
    mut islands: ResMut<IslandManagerRes>,
    mut impulse_joints: ResMut<ImpulseJointSetRes>,
    mut multibody_joints: ResMut<MultibodyJointSetRes>,
    broad_phase: Res<BroadPhaseRes>,
    narrow_phase: Res<NarrowPhaseRes>,
)

Maybe the limit of 16 is not enough ? But system parameters can be grouped. For example I can group the last few resources into one big physics system parameter structure.

[IceSentry]

You can wrap each group in tuples which can let you extend the limit to pretty much anything you need. Each tuple has a limit of 16 items but it can also have nested tuples

For example, here's what your code could look like:

fn handle_input(
    mut commands: Commands,
    mut messages: MessageReader<BlockOperation>,
    mut block_changes: ResMut<BlockChanges>,
    mut large_objects: Query<&mut ChunksMap>,
    mut chunks: Query<&mut ChunkTypes>,
    mut small_objects: Query<(
        &mut SmallBlocksSize,
        &mut SmallBlocksTypes,
        &mut CornerOffset,
    )>,
    transforms: Query<&Transform>,
    body_handles: Query<&RigidBodyComponent>,
    special_block_entities: Query<&SpecialBlockEntities>,
	
    block_properties: Res<BlockProperties>,

	(mut bodies, mut colliders, mut islands): (
		ResMut<RigibBodies>, 
		ResMut<ColliderSetRes>, 
		ResMut<IslandManagerRes>
	),
    mut impulse_joints: ResMut<ImpulseJointSetRes>,
    mut multibody_joints: ResMut<MultibodyJointSetRes>,
    broad_phase: Res<BroadPhaseRes>,
    narrow_phase: Res<NarrowPhaseRes>,
)

[newDINO]

Thanks for responding. Didn't know this solution before. So I defined a structure:

#[derive(SystemParam)]
pub struct AllPhysicsResMut<'w> {
    pub bodies: ResMut<'w, RigidBodiesRes>,
    pub colliders: ResMut<'w, ColliderSetRes>,
    pub integration_parameters: ResMut<'w, IntegrationParametersRes>,
    pub islands: ResMut<'w, IslandManagerRes>,
    pub broad_phase: ResMut<'w, BroadPhaseRes>,
    pub narrow_phase: ResMut<'w, NarrowPhaseRes>,
    pub impulse_joints: ResMut<'w, ImpulseJointSetRes>,
    pub multibody_joints: ResMut<'w, MultibodyJointSetRes>,
    pub ccd_solver: ResMut<'w, CCDSolverRes>,
}

to contain all physics resources (currently using rapier engine). Now I'll consider using tuples for more flexibility when needed.

[LikeLakers2]

While it is possible to use tuples to get effectively infinite parameters (as per IceSentry's answer), if you're using that many parameters, it may be worth considering if you should split the system into several smaller systems.

For example, your example is called handle_input, but calls for several physics- and voxel-related components. It's not unreasonable to use some of them during input-handling - especially for checking the validity of an input - but you might consider moving some of the physics-related logic to its own system.

[newDINO]

Indeed I need to consider breaking this system. Currently the game is in early development, so I usually just consider adding more features. Another choice to avoid too much parameters is using register_systems() and run_systems_with() so that I can call systems from other modules by only passing required information.