Overflow di evento di rete affidabile in FiveM: trova lo script e correggilo

Un giocatore viene buttato fuori dal server, o l'intero server inizia a fare timeout, con un messaggio come questo:

Reliable network event overflow

FiveM mantiene una coda limitata di eventi di rete affidabili per ogni connessione. Quando uno script la riempie più velocemente di quanto la connessione possa inviare, il giocatore viene abbandonato. La causa è quasi sempre una risorsa. Ecco come trovarla e correggerla.

#Cosa succede

Ogni TriggerClientEvent e TriggerServerEvent è un messaggio affidabile: deve arrivare, in ordine. Se ne invii molti, o molto grandi, la coda per quel giocatore cresce. Quando trabocca, la connessione viene tagliata.

I soliti modelli:

• Una grande tabella inviata in un evento: un elenco completo di veicoli, articoli, giocatori, o un'intera config.
• Un loop che attiva un evento ogni tick o ogni pochi millisecondi.
• Un evento inviato a tutti (-1) molte volte al secondo.
• Uno script che invia i dati uguali ancora e ancora, quando non sono cambiati.

-- bad: sends everything, to everyone, every 100 ms
CreateThread(function()
    while true do
        Wait(100)
        TriggerClientEvent('myscript:update', -1, GetAllData())
    end
end)

#Trova la risorsa

Il messaggio di errore non nomina lo script, quindi devi misurare.

1. Guarda la console del server intorno al momento dei calci. Molti nomi di evento identici, o una risorsa che è iniziata appena prima dei problemi, è un suggerimento.
2. Usa il profiler. Il profiler built-in registra una breve sessione e ti permette di aprirla in un visualizzatore. Nella console del server:

profiler record 500
profiler view

Controlla i comandi esatti per la build del tuo server, poiché possono cambiare tra le versioni. La registrazione mostra quali risorse ed eventi richiedono tempo, e ti aiuta a individuare quello pesante.

3. Ferma le risorse una per una su un server di test. Se i calci si fermano dopo che fermi una risorsa, l'hai trovato.
4. Cerca nel codice TriggerClientEvent e TriggerServerEvent dentro loop, e per eventi inviati con -1.

Suggerimento: il problema spesso inizia dopo che aggiungi uno nuovo script, o dopo un aggiornamento dello script. Controlla prima cosa è cambiato.

#Soluzione 1: invia payload più piccoli

Invia solo quello che è cambiato, non l'intero set di dati.

-- bad: the whole table
TriggerClientEvent('shop:sync', src, allShops)

-- better: only the changed entry
TriggerClientEvent('shop:updateOne', src, shopId, shops[shopId])

Rimuovi i campi che il client non ha bisogno, invia id invece di interi oggetti, e lascia che il client richieda i dettagli quando ha bisogno.

#Soluzione 2: invia meno spesso

Attiva gli eventi quando succede qualcosa, non su un timer. Se hai bisogno di un timer, rendilo più lento e saltalo quando nulla è cambiato.

local last = nil

CreateThread(function()
    while true do
        Wait(2000)
        local data = GetData()
        if data ~= last then
            last = data
            TriggerClientEvent('myscript:update', -1, data)
        end
    end
end)

Invia ai giocatori che ne hanno bisogno, non a -1, quando solo alcuni giocatori si preoccupano.

#Soluzione 3: eventi latenti per grandi dati

Quando davvero devi inviare molti dati, come una grande config o un'immagine, usa un evento latente. Invia i dati in background a una velocità che imposti, in byte al secondo, invece di riempire la coda normale.

-- server -> client, 50 KB/s
TriggerLatentClientEvent('myscript:bigData', src, 50000, bigTable)

-- client -> server
TriggerLatentServerEvent('myscript:bigData', 50000, bigTable)

L'evento arriva dopo, quindi usalo solo per dati che non sono critica di tempo. Scegli una velocità che non satura la connessione del giocatore.

#Soluzione 4: state bag per stato condiviso

Se i dati sono stato di un'entità o un giocatore (un flag, un valore, uno stato), una state bag è spesso meglio che gli eventi. FiveM replica i cambiamenti per te, e invia solo quello che è cambiato.

-- server
Player(src).state:set('isCuffed', true, true)

-- client, anywhere
local cuffed = LocalPlayer.state.isCuffed

Le state bag sono per piccoli valori, non per grandi tabelle. Leggi FiveM state bag spiegato per come funzionano, e Client e server event in FiveM per le basi dei event.

#Se non puoi modificare lo script

Se lo script è una risorsa protetta o a pagamento, non puoi cambiare il suo codice. Segnala il problema all'autore con il risultato del profiler e l'ora dei calci. Sapranno quale evento è troppo grande. Fino ad allora, fermare la risorsa o abbassare il suo refresh rate nella sua config, se ne ha uno, è l'unica soluzione alternativa.

#Checklist