netfox

netfox is a core addon for the Godot Engine designed to provide responsive multiplayer features. Its primary capabilities include:

• Synchronized time: Runs game logic at a fixed, configurable tickrate that is synchronized to the game host.
• State interpolation: Allows rendering a low-frequency tickrate (e.g., 24fps) at a higher, smoother frame rate (e.g., 60fps or more) using the TickInterpolator node.
• Lag compensation with CSP: Enables responsive player motion with minimal code by using the RollbackSynchronizer node for state synchronization.

The netfox.extras addon provides high-level, game-specific utilities that are useful for development but are not part of the core netfox library. Key features include:

• Networked weapons: Specialized implementations for handling weapon logic in a networked environment.
• Rollback-aware base class for input: A base class designed to work with rollback networking systems to handle player input correctly.

netfox is a set of addons for responsive online games in the Godot engine. It provides features like consistent timing, client-server architecture support, smooth motion interpolation, and lag compensation (Client-side Prediction and Server-side Reconciliation).

The project is divided into several specialized packages:

• netfox: The core package implementing timing, rollback, and other multiplayer features.
• netfox.noray: Integrates with [noray] to establish connections between players, essential for online play.
• netfox.extras: High-level, game-specific convenience features (e.g., base classes for input management or weapons).
• netfox.internals: Shared utilities used by other addons. This is a dependency and does not need to be installed separately.

The PacketHandshake is a singleton used to implement a handshake over UDP. Its primary purpose is to confirm a two-way connection between two parties, ensuring that both sides can both send and receive messages and receive acknowledgements.

Performing this handshake before actual gameplay is critical for NAT punchthrough. By sending traffic back and forth, both players' routers can be tricked into recognizing the incoming traffic as a legitimate response to an outgoing request, allowing the connection to pass through firewalls and routers that would otherwise block unsolicited incoming packets.

The PredictiveSynchronizer is a local-only version of the RollbackSynchronizer. It manages state properties during a rollback loop without any networking overhead.

Use cases:

• Short-lived scenarios.
• Highly deterministic scenarios where networking is unnecessary.
• Scenarios where RollbackSynchronizer is impractical due to its networking requirements.

Key differences from RollbackSynchronizer:

• No networking: It operates entirely locally.
• No input properties: It only manages state properties, not inputs.

Interpolating the rotation property directly can cause glitchy behavior (such as sudden spinning) when an object performs a full turn. This happens because rotation uses Euler angles, which can cause numerical interpolation issues between values like -180 and +180 degrees.

To ensure smooth rotation interpolation, use one of the following instead:

• Interpolate the entire transform property.
• Interpolate the quaternion property, which is mathematically better suited for smooth rotation interpolation.

In a rollback architecture, the system simulates multiple logical ticks during a single network tick. Since these extra ticks are purely logical simulations, no new hardware input arrives during them.

BaseNetInput solves this by providing a _gather() mechanism. Input is gathered once at the start of the network tick, and that same input state is then applied to all subsequent logical ticks simulated during that rollback span, ensuring consistency across the simulated timeline.

The NetworkTimeSynchronizer manages time synchronization between a client and a host remote using three distinct clock abstractions to ensure stability despite network latency:

1. Remote clock: The clock running on the host peer that the client is synchronizing to.
2. Reference clock: A local client clock that is continuously adjusted (nudged) to match the Remote clock. Warning: Do not use this clock for gameplay logic, as its regular adjustments can cause glitchy movement.
3. Simulation clock: A local client clock synchronized to the Reference clock. It is guaranteed to move forward monotonically and is used to drive the [Network tick loop]. This is the clock intended for gameplay and simulation logic.

For most use cases, you should interface with NetworkTime rather than interacting with NetworkTimeSynchronizer directly.

The StateSynchronizer node synchronizes state from a node's authority to other peers. It is tied to the netfox [network tick loop], making it compatible with TickInterpolator.

A common use case is synchronizing server-side logic, such as NPC states, where the server controls the entities and broadcasts their state to clients.

To maintain synchronization, all peers should ideally share the same tickrate. If a mismatch is detected between the local tickrate and a peer's tickrate, netfox can be configured to handle it via the Tickrate Mismatch Action setting.

Available actions:

• Warn: Emits a warning but continues (useful for development).
• Disconnect: The host disconnects clients with mismatching tickrates.
• Adjust: The client automatically adjusts its tickrate to match the host.
• Signal: Emits a signal so you can implement custom logic.