Desbordamiento de evento de red confiable en FiveM: encuentra el script y arréglalo

Un jugador es expulsado del servidor, o todo el servidor comienza a agotar el tiempo, con un mensaje como este:

Reliable network event overflow

FiveM mantiene una cola limitada de eventos de red confiables para cada conexión. Cuando un script la llena más rápido de lo que la conexión puede enviar, el jugador es expulsado. La causa es casi siempre un recurso. Aquí está cómo encontrarlo y arreglarlo.

#Qué sucede

Cada TriggerClientEvent y TriggerServerEvent es un mensaje confiable: debe llegar, en orden. Si envías muchos de ellos, o muy grandes, la cola para ese jugador crece. Cuando se desborda, la conexión se corta.

Los patrones habituales:

• Una tabla grande enviada en un evento: una lista completa de vehículos, elementos, jugadores, o una configuración completa.
• Un bucle que activa un evento en cada tick o cada pocos milisegundos.
• Un evento enviado a todos (-1) muchas veces por segundo.
• Un script que envía los mismos datos una y otra vez, cuando no cambiaron.

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

#Encuentra el recurso

El mensaje de error no nombra el script, así que tienes que medir.

1. Mira la consola del servidor alrededor de la hora de las expulsiones. Muchos nombres de eventos idénticos, o un recurso que comenzó justo antes de los problemas, es una pista.
2. Usa el perfilador. El perfilador integrado registra una sesión corta y te permite abrirla en un visor. En la consola del servidor:

profiler record 500
profiler view

Comprueba los comandos exactos para tu compilación de servidor, ya que pueden cambiar entre versiones. El registro muestra qué recursos y eventos toman tiempo, y te ayuda a identificar el pesado.

3. Detén recursos uno a la vez en un servidor de prueba. Si las expulsiones se detienen después de detener un recurso, lo encontraste.
4. Busca en el código TriggerClientEvent y TriggerServerEvent dentro de bucles, y eventos enviados con -1.

Consejo: el problema a menudo comienza después de que añades un nuevo script, o después de una actualización de script. Comprueba qué cambió primero.

#Solución 1: envía payloads más pequeños

Envía solo lo que cambió, no todo el conjunto de datos.

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

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

Elimina campos que el cliente no necesita, envía ids en lugar de objetos completos, y deja que el cliente solicite detalles cuando los necesite.

#Solución 2: envía menos a menudo

Activa eventos cuando algo sucede, no en un temporizador. Si necesitas un temporizador, hazlo más lento y omítelo cuando nada cambió.

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)

Envía a los jugadores que lo necesitan, no a -1, cuando solo algunos jugadores se importan.

#Solución 3: eventos latentes para grandes datos

Cuando realmente debe enviar muchos datos, como una configuración grande o una imagen, usa un evento latente. Envía los datos en el fondo a una velocidad que estableces, en bytes por segundo, en lugar de llenar la cola normal.

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

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

El evento llega más tarde, así que úsalo solo para datos que no son críticos en tiempo. Elige una velocidad que no sature la conexión del jugador.

#Solución 4: bolsas de estado para estado compartido

Si los datos son estado de una entidad o un jugador (una bandera, un valor, un estado), una bolsa de estado es a menudo mejor que eventos. FiveM replica cambios para ti, y solo envía lo que cambió.

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

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

Las bolsas de estado son para valores pequeños, no para tablas grandes. Lee bolsas de estado de FiveM explicadas para cómo funcionan, y eventos de cliente y servidor en FiveM para lo básico de eventos.

#Si no puedes editar el script

Si el script es un recurso pagado o protegido, no puedes cambiar su código. Reporta el problema al autor con el resultado del perfilador y la hora de las expulsiones. Sabrán qué evento es demasiado grande. Hasta entonces, detener el recurso o bajar su tasa de actualización en su configuración, si la tiene, es el único workaround.

#Lista de verificación