FiveM routing bucket: SetPlayerRoutingBucket, istanze e voce

Il sintomo: due gruppi di giocatori condividono la stessa posizione e vuoi che siano separati, o i giocatori in una minigame vedono un mondo pieno di auto e pedoni di altre persone.

I routing bucket sono la versione di FiveM di dimensioni o istanze. Entità e giocatori in bucket diversi non si vedono l'un l'altro. Sono lo strumento dietro appartamenti, minigame e schermate di selezione dei personaggi, e vengono gestiti sul server. Questo articolo copre ogni nativo e gli errori da evitare.

#Cos'è un routing bucket

Un bucket è un numero. Ogni giocatore e ogni entità appartiene esattamente a un bucket, e il valore predefinito è 0. Due cose in bucket diversi sono invisibili l'una all'altra: i giocatori non vedono i giocatori, i veicoli o i prop dell'altro bucket, e non interagiscono. Condividono comunque la stessa mappa, quindi le coordinate rimangono uguali.

Questo funziona solo su un server con OneSync, che i server attuali utilizzano. Vedi abilitazione di OneSync se non sei sicuro.

#I nativi principali

Tutti questi vengono eseguiti sul server:

-- 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 prende l'id del server del giocatore e un numero di bucket. SetEntityRoutingBucket prende l'handle dell'entità. Le entità che crei sul server dopo che il giocatore si è spostato iniziano nel bucket 0 a meno che non li sposti, quindi imposta il bucket subito dopo crearli:

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

Scegli i numeri dei bucket di proposito. Un'abitudine comune è riservare intervalli, ad esempio un intervallo per le case, uno per le minigame, quindi due funzioni mai riutilizzano un numero per incidente.

Attenzione: questi nativi sono solo lato server. Chiamarli da uno script client non fa nulla di utile. Invia un evento al server e lascia che il server sposti il giocatore, dopo che ha controllato la richiesta.

#Popolazione e blocco

Ogni bucket può avere le sue regole:

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

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

• SetRoutingBucketPopulationEnabled(bucket, false) disattiva gli NPC e il traffico ambientale in quel bucket. È utile per le istanze, perché un interno vuoto o una minigame non ha bisogno di auto che lo attraversano. Il bucket 0 mantiene la sua popolazione normale.
• SetRoutingBucketEntityLockdownMode(bucket, mode) controlla la creazione di entità. Le modalità sono 'strict', 'relaxed' e 'inactive', e 'inactive' è il comportamento normale, con 'strict' che è il più stretto. Controlla la documentazione nativa per la differenza esatta prima di fare affidamento su una.

Impostare le regole di un nuovo bucket una volta, quando viene usato per la prima volta, è sufficiente. Rimangono per la vita del server.

#Casi d'uso

• Appartamenti e case: un bucket per proprietà, quindi gli interni identici non si sovrappongono. Il modello completo è in alloggi e istanze.
• Minigame e eventi: metti i partecipanti in un bucket privato con popolazione spenta, in modo che nulla dall'esterno interferisca.
• Selezione e creazione dei personaggi: metti il giocatore in un bucket privato mentre sceglie un personaggio, in modo che non sia visto in piedi nel mondo, e spostalo su 0 quando appare.
• Tutorial e spazi admin: un bucket tranquillo per spiegare le cose senza il resto del server.
• Test: prova uno script lontano dai giocatori.

#Voce nei bucket

Poiché i giocatori in bucket diversi non sono vicini l'uno all'altro dal punto di vista del gioco, la voce di prossimità generalmente segue la stessa separazione. Le risorse vocali come pma-voice sono costruite attorno a OneSync e funzionano per bucket, quindi i giocatori in una casa non sentono la strada. Se vuoi che le persone in bucket diversi parlino, usa i canali o le funzioni di chiamata della risorsa vocale stessa invece di combattere i bucket. Se la voce è silenziosa dopo aver spostato i giocatori, vedi pma-voice non funziona. Testalo con due veri giocatori, non solo uno.

#Un helper di istanza riutilizzabile

Mantieni la logica del bucket in un posto, in modo che ogni percorso di uscita lo ripristini:

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)

Chiama LeaveInstance all'uscita, alla morte e quando la tua risorsa si ferma:

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

Senza quell'ultimo handler, un riavvio dello script lascia i giocatori soli in un bucket vuoto.

#Problemi comuni

• Un giocatore è bloccato da solo: non è mai stato ricondotto a 0. Ripristina ad ogni percorso di uscita e all'arresto della risorsa.
• Un veicolo manca per il passeggero: il giocatore e il veicolo hanno finito in bucket diversi. Spostali entrambi.
• Le entità spawned appaiono nel mondo sbagliato: le nuove entità lato server iniziano nel bucket 0.
• Diverse funzioni riutilizzano lo stesso numero e i giocatori finiscono nell'istanza di qualcun altro: riserva intervalli.
• Chiamare i nativi sul client: appartengono al server.

#Elenco di controllo