This document provides a detailed reference for the Network Sync API, which allows modders to add multiplayer functionality to Zelda 64: Recompiled mods.
Initializes the network play system. This must be called before using any other networking functions.
- Parameters: None
- Returns: None
- Usage: Call this once at the beginning of your mod's execution.
Establishes a connection to the network server.
- Parameters:
host: String containing the WebSocket URL of the server (e.g., "ws://localhost:9002")
- Returns:
1if connection was successful0if connection failed
- Usage: Call after initialization to connect to your network server.
Joins a multiplayer session on the server.
- Parameters:
session: String identifier for the session to join (e.g., "test-session")
- Returns:
1if joining was successful0if joining failed
- Usage: Players must join the same session to see and interact with each other.
Leaves the current multiplayer session.
- Parameters: None
- Returns:
1if leaving was successful0if leaving failed
- Usage: Call this when you want to disconnect from the current session.
Registers an actor for network synchronization.
- Parameters:
actor: Pointer to the Actor to be synchronizedplayerID: String identifier for this actor- if actor->id == 0, we use the server defined id (identifies players)
isOwnedLocally:1if this client should send updates for this actor0if this client should only receive updates
- Returns: None
- Usage: Call this to start synchronizing an actor across the network.
Gets the network identifier for a registered actor.
- Parameters:
actor: Pointer to the Actor to query
- Returns:
- String containing the network ID if the actor is registered
NULLif the actor is not registered for synchronization
- Usage: Use to retrieve the unique network identifier for an actor.
Gets a list of connected remote player IDs.
- Parameters:
maxPlayers: Maximum number of player IDs to retrieveidsBuffer: Buffer to store player IDs (should be at least maxPlayers * idBufferSize)idBufferSize: Size of each player ID string buffer
- Returns: Number of remote player IDs retrieved
- Usage: Call this to get a list of all other players in the session.
Retrieves the most recent data for a specific remote player.
- Parameters:
playerID: String identifier of the remote playerdataBuffer: Buffer to store the player's data (should be aPlayerSyncDatastruct)
- Returns:
1if data was successfully retrieved0if data could not be retrieved
- Usage: Call this to get the latest position, animation, and state data for a remote player.
Registers a callback function to handle custom messages of a specific type.
- Parameters:
messageId: String identifier for the message typepayloadSize: Size of the expected message payload in bytescallback: Function pointer to the callback that will handle messages of this type- Callback signature:
void (*callback)(void* data)
- Callback signature:
- Returns:
0if registration was successful1if registration failed
- Usage: Call during initialization to set up handlers for custom message types.
Sends a custom message to all other clients in the session.
- Parameters:
messageId: String identifier for the message type (must match a registered handler)data: Pointer to the message payload data
- Returns:
0if message was sent successfully1if sending failed
- Usage: Call to broadcast custom messages to other clients.
Structure containing synchronized data for players.
typedef struct {
Vec3s shapeRotation; // Actor shape rotation
Vec3f worldPosition; // Actor world position
// Player Actor properties
s8 currentBoots; // Current boots equipped by the player
s8 currentShield; // Current shield equipped by the player
u8 _padding[2]; // Padding for alignment
Vec3s jointTable[24]; // Animation joint positions
Vec3s upperLimbRot; // Upper body rotation
} PlayerSyncData;-
Call NS_Init() early: Initialize the network system before attempting to use other functions.
-
Error handling: Always check return values from connect/join functions.
-
Actor ownership: For each actor, only one client should set
isOwnedLocallyto 1. -
Remote player rendering: Create separate actor instances for remote players and update them with
NS_GetRemoteActorData(). -
Session design: Use meaningful session names to separate different multiplayer groups.