Also, feel free to focus on the feature implementation, I'm happy to take care of the docstrings and doc site update.

2 issues currently:

1. When the host jumps, the state is immediately rolled back to Idle can_enter as it's testing whether it's still on the ground. For the client, this isn't an issue. Removing the can_enter logic resolves the issue.

[INF][@787][#1][netfox.extras::NetworkedStateMachine] [Fresh: true] [Rollback: true] Transitioned from state Idle into Jump
[INF][@788][#1][netfox.extras::NetworkedStateMachine] [Fresh: true] [Rollback: true] Transitioned from state Jump into Idle
[INF][@788][#1][netfox.extras::NetworkedStateMachine] [Fresh: true] [Rollback: true] Transitioned from state Idle into Jump
[INF][@789][#1][netfox.extras::NetworkedStateMachine] [Fresh: true] [Rollback: true] Transitioned from state Jump into Idle
[INF][@787][#553236475][netfox.extras::NetworkedStateMachine] [Fresh: true] [Rollback: true] Transitioned from state Idle into Jump
[INF][@789][#553236475][netfox.extras::NetworkedStateMachine] [Fresh: true] [Rollback: true] Transitioned from state Jump into Idle

2. When the client jumps, it works fine until the client lands. Then it ping pongs between the Jump and Idle states.

This now seems to be resolved. The issue was can_enter is much more important than I thought. It must guard the state perfectly. We need some mental model to clearly explain how to use this.

Something like...

In a networked state machine, can_enter acts as a crucial "guard rail," ensuring that every transition into a state is intentional and meets all necessary conditions. Networked environments introduce unpredictability, like desyncs and rollbacks, so we can't fully trust that every state entry is happening under ideal circumstances. This makes can_enter essential for confirming all preconditions are met before a state change occurs, preventing unwanted behaviors, glitches, or "ping-ponging" between states.

By setting can_enter to verify key requirements—such as input presence, environmental conditions (like being on the ground), or timing constraints - you create a stable foundation for each state. This validation enforces continuity and predictability, regardless of how or when a state transition is triggered.

Feature itself seems stable, I've updated the PR description with some tasks for myself.

great!