Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Elitriare/ByteNet-Max/llms.txt

Use this file to discover all available pages before exploring further.

ByteNet Max gives you direct control over how each packet is transmitted across the network. By setting the reliabilityType option on definePacket, you choose between guaranteed ordered delivery and lightweight best-effort delivery — letting you match the transport behaviour to the nature of your data.

​
The reliabilityType option

reliabilityType is an optional field on the props table passed to ByteNetMax.definePacket. It accepts two string values:
ValueDeliveryOrderingOverhead
"reliable"GuaranteedOrderedHigher
"unreliable"Best-effortUnorderedLower
reliabilityType defaults to "reliable" when omitted. Existing packets that do not set this field behave as reliable without any changes required.

​
Reliable packets

Reliable packets mirror the behaviour of Roblox RemoteEvent fired through the reliable channel. Every packet is acknowledged by the receiver, and the engine retransmits any that are lost in transit. Packets also arrive in the order they were sent. Use reliable delivery for:
  • Game state changes — inventory updates, health changes, quest completions
  • Player actions — ability activations, purchases, chat messages
  • Critical one-time events — round start/end, respawn signals, score submissions

​
Unreliable packets

Unreliable packets use Roblox’s UnreliableRemoteEvent channel. They are sent without acknowledgment: if a packet is lost it will not be retransmitted, and packets may arrive out of order or not at all. In exchange, unreliable packets add no retransmission overhead and impose no head-of-line blocking. Use unreliable delivery for:
  • Position and rotation updates — a missed frame is immediately superseded by the next
  • Animation hints — cosmetic events that the client can reconstruct from world state
  • Non-critical high-frequency data — anything where a missed send is tolerable
For positional data sent every heartbeat, unreliable is almost always the right choice. A stale position from two frames ago is useless once the next update arrives, so retransmitting it wastes bandwidth and can increase perceived latency.

​
Example: defining an unreliable packet

local ByteNetMax = require(path.to.ByteNetMax)

return ByteNetMax.defineNamespace("Movement", function()
    return {
        packets = {
            UpdatePosition = ByteNetMax.definePacket({
                value = ByteNetMax.struct({
                    x = ByteNetMax.float32,
                    y = ByteNetMax.float32,
                    z = ByteNetMax.float32,
                }),
                reliabilityType = "unreliable",
            }),
        },
    }
end)
The reliabilityType field is the only change needed — the send and listen API is identical for both modes.

​
Queries are always reliable

Queries (the ByteNet Max equivalent of RemoteFunction) do not expose a reliabilityType option. Because queries use a request/response pattern, every invocation must be acknowledged before the caller receives a result. Unreliable delivery would break that contract, so all queries use reliable transport unconditionally.

Build docs developers (and LLMs) love

Get started for freeTalk to us