Routing buckets en FiveM: SetPlayerRoutingBucket, instancias y voz

El síntoma: dos grupos de jugadores comparten la misma ubicación y quieres separarlos, o los jugadores en un minijuego ven un mundo lleno de autos y peatones de otras personas.

Los routing buckets son la versión de FiveM de dimensiones o instancias. Las entidades y jugadores en diferentes buckets no se ven mutuamente. Son la herramienta detrás de apartamentos, minijuegos y pantallas de selección de carácter, y se manejan en el servidor. Este artículo cubre cada native y los errores a evitar.

#Qué es un routing bucket

Un bucket es un número. Cada jugador y cada entidad pertenece exactamente a un bucket, y el predeterminado es 0. Dos cosas en diferentes buckets son invisibles entre sí: los jugadores no ven a los jugadores, vehículos o props del otro bucket, y no interactúan. Aún así comparten el mismo mapa, así que las coordenadas permanecen igual.

Esto solo funciona en un servidor con OneSync, que los servidores actuales usan. Ver habilitando OneSync si no estás seguro.

#Las natives principales

Todas estas se ejecutan en el servidor:

-- put a player in a bucket, and read it back
SetPlayerRoutingBucket(source, 50)
local bucket = GetPlayerRoutingBucket(source)

-- put an entity (vehicle, ped, object) in a bucket
SetEntityRoutingBucket(vehicle, 50)
local entityBucket = GetEntityRoutingBucket(vehicle)

-- back to the default world
SetPlayerRoutingBucket(source, 0)

SetPlayerRoutingBucket toma la id del servidor del jugador y un número de bucket. SetEntityRoutingBucket toma el handle de la entidad. Las entidades que creas en el servidor después de que el jugador se movió comienzan en bucket 0 a menos que las muevas, así que establece el bucket justo después de crearlas:

local veh = CreateVehicle(`sultan`, 0.0, 0.0, 70.0, 0.0, true, true)
SetEntityRoutingBucket(veh, 50)

Elige números de bucket a propósito. Un hábito común es reservar rangos, por ejemplo un rango para casas, uno para minijuegos, así dos características nunca reutilizan un número por accidente.

Cuidado: estas natives son solo del servidor. Llamarlas desde un script del cliente no hace nada útil. Envía un evento al servidor y deja que el servidor mueva al jugador, después de que ha comprobado la solicitud.

#Población y bloqueo

Cada bucket puede tener sus propias reglas:

-- no ambient pedestrians or traffic in bucket 50
SetRoutingBucketPopulationEnabled(50, false)

-- who may create entities in bucket 50
SetRoutingBucketEntityLockdownMode(50, 'strict')

• SetRoutingBucketPopulationEnabled(bucket, false) apaga NPCs ambientes y tráfico en ese bucket. Es útil para instancias, porque un interior vacío o un minijuego no necesita autos conduciendo a través. El bucket 0 mantiene su población normal.
• SetRoutingBucketEntityLockdownMode(bucket, mode) controla la creación de entidades. Los modos son 'strict', 'relaxed' e 'inactive', e 'inactive' es el comportamiento normal, siendo 'strict' el más estricto. Comprueba la documentación de la native para la diferencia exacta antes de que confíes en uno.

Establecer las reglas de un nuevo bucket una vez, cuando se usa por primera vez, es suficiente. Permanecen por la vida del servidor.

#Casos de uso

• Apartamentos y casas: un bucket por propiedad, así los interiores idénticos no se superponen. El patrón completo está en vivienda e instancias.
• Minijuegos y eventos: pon a los participantes en un bucket privado con población apagada, así nada afuera interfiere.
• Selección y creación de carácter: pon al jugador en un bucket privado mientras elige un carácter, así no son visto de pie en el mundo, y muévelo a 0 cuando aparecen.
• Tutoriales y espacios de admin: un bucket tranquilo para explicar cosas sin el resto del servidor.
• Pruebas: prueba un script lejos de jugadores.

#Voz en buckets

Porque los jugadores en diferentes buckets no están cerca uno del otro desde el punto de vista del juego, la voz de proximidad generalmente sigue la misma separación. Los recursos de voz como pma-voice están construidos alrededor de OneSync y funcionan por bucket, así que los jugadores en una casa no escuchan la calle. Si quieres que personas en diferentes buckets hablen, usa las características de canal o llamada propias del recurso de voz en lugar de pelear con los buckets. Si la voz está silenciosa después de mover jugadores, ver pma-voice no funciona. Pruébalo con dos jugadores reales, no solo con uno.

#Un auxiliar de instancia reutilizable

Mantén la lógica del bucket en un lugar, así cada ruta de salida lo reinicia:

local instances = {}   -- [source] = bucket

function EnterInstance(src, bucket)
    instances[src] = bucket
    SetPlayerRoutingBucket(src, bucket)
end

function LeaveInstance(src)
    instances[src] = nil
    SetPlayerRoutingBucket(src, 0)
end

AddEventHandler('playerDropped', function()
    instances[source] = nil
end)

Llama LeaveInstance al salir, a la muerte, y cuando tu recurso se detiene:

AddEventHandler('onResourceStop', function(resource)
    if resource ~= GetCurrentResourceName() then return end
    for src in pairs(instances) do
        SetPlayerRoutingBucket(src, 0)
    end
end)

Sin ese último controlador, un reinicio de script deja jugadores solos en un bucket vacío.

#Problemas comunes

• Un jugador está atrapado solo: nunca fueron movidos de vuelta a 0. Reinicia en cada ruta de salida y al detener el recurso.
• Un vehículo falta para el pasajero: el jugador y el vehículo terminaron en buckets diferentes. Mueve ambos.
• Las entidades spawneadas aparecen en el mundo incorrecto: las entidades nuevas del lado del servidor comienzan en bucket 0.
• Diferentes características reutilizan el mismo número y los jugadores aterrizan en las instancias de otros: reserva rangos.
• Llamar a las natives en el cliente: pertenecen al servidor.

#Checklist