FiveM OneSync, sloty pro hráče a culling

Bez OneSync je FiveM server omezený na 32 hráčů peer-to-peer síťováním samotného GTA V. S set onesync on se autoritou nad entitami stává server, strop se zvedne daleko nad to, co roleplay server dokáže reálně utáhnout, a hráči dostávají jen to, co je poblíž. Dvě čísla, která rozhodují o tvém skutečném počtu slotů, jsou jinde: úroveň slotů navázaná na tvůj klíč Cfx.re (volná úroveň se historicky zastavila na 48) a kolik času hlavního vlákna a sync vlákna ti tvé resources nechají. Tento článek popisuje, co OneSync mění, convary, které ho řídí, culling a routing buckets, entity lockdown a jak zvolit počet slotů, který udržíš.

Co OneSync skutečně mění#

Multiplayer GTA V byl postavený pro relace o pár desítkách hráčů, kde každý klient vlastní některé entity a přímo o nich říká ostatním. FiveM bez OneSync tento model drží: server přeposílá provoz, ale o tom, kdo o čem ví, rozhoduje vlastní sync hry, a limit 32 hráčů je jeho součástí.

OneSync to nahrazuje stavem na straně serveru. Každou síťovou entitu - hráče, vozidla, pedy, objekty - sleduje FXServer, který ví, kde je každá z nich a který klient ji právě vlastní. Klienti pořád simulují entity, které vlastní, ale server rozhoduje, kdo dostane aktualizace o čem. Z toho plynou čtyři praktické důsledky:

• Sloty nad 32 jsou možné. Strop enginu s OneSync je v řádu tisíců. Nikdo by ho neměl využívat.
• Server vidí všechno. Serverové skripty mohou číst peda a souřadnice kteréhokoli hráče pomocí GetPlayerPed(source) a GetEntityCoords, což bez OneSync fungovalo jen na klientu.
• Klienti vidí jen to, co je blízko. Hráči a entity za culling radiusem se klientu neposílají vůbec.
• Server může entity odmítnout. Protože je server autorita, může klientům zablokovat vytváření entit, což je nejužitečnější anticheatové nastavení, které FiveM má.

OneSync není pro moderní server volitelný. Současné frameworky, inventáře a většina resources z posledních let ho předpokládají a mnohé bez něj nebudou fungovat správně.

Convary#

set onesync onset onesync_population trueset onesync_forceMigration truesv_maxclients 48

legacy je původní implementace OneSync, ponechaná kvůli kompatibilitě. Má nižší strop a posílá každému klientovi víc; pro nový server není důvod ji volit. Velmi staré návody používají onesync_enabled 1 a onesync_enableInfinity 1. To jsou zastaralé podoby onesync on a když je najdeš, odstraň je.

Dvě věci o tom, jak se čtou. O OneSync se musí rozhodnout dřív, než server dokončí start, takže jeho změna vyžaduje úplný restart serveru - restart resource nedělá nic. A txAdmin má v těch verzích, které ho nabízejí, vlastní nastavení OneSync na stránce nastavení FXServeru, které předává přes příkazový řádek; pokud server.cfg říká něco jiného, jedno z nich vyhraje a nemusíš se dívat na to správné. Nastav to na jednom místě. Zbytek souboru pokrývá FiveM server.cfg vysvětleno.

sv_maxclients také vyžaduje úplný restart. Resource hardcap z výchozích dat serveru je to, co odmítá hráče, když je server plný; nech ho v seznamu ensure, pokud ho nenahradí resource s frontou.

Limity slotů: engine, licence a realita#

Na sobě leží tři limity a vyhrává ten nejnižší.

O licenční úroveň lidé zakopávají nejčastěji. Volný klíč už léta povoluje s OneSync až 48 slotů a vyšší počty vyžadovaly úroveň předplatného Cfx.re (prodávaného jako Element Club) navázanou na účet, který klíč vlastní. Cfx.re názvy a prahy těchto úrovní už dříve změnilo, takže aktuální čísla zkontroluj na portálu Cfx.re a nespoléhej na číslo z fóra - včetně tohoto. Pokud nastavíš sv_maxclients výš, než tvůj klíč dovoluje, server ti to při startu oznámí.

Limit reality je ten, na kterém záleží. Slot je příslib, že na serveru může být ještě jeden člověk, aniž by to zhoršilo zážitek ostatním. Na roleplay serveru s dvěma sty resources každý další hráč přidává práci každé smyčce přes hráče, každému eventu rozesílanému všem a každé entitě, kterou s sebou přináší. Server přijme 128 spojení dávno předtím, než je dokáže dobře obsloužit.

Začni níž, než si myslíš, sleduj graf ticků v txAdminu a varování o hitchích v konzoli ve špičce a počet zvyšuj, až když čísla říkají, že můžeš. Snižovat počet slotů poté, co si na něj komunita zvykla, je mnohem těžší než ho zvyšovat. Obecnou úvahu má kolik hráčů se vejde na server a jak číst data o ticích ukazuje výkon FiveM serveru.

Culling: co každý hráč vidí#

Se zapnutým OneSync dostává každý klient jen hráče a entity v culling radiusu od své pozice - ve výchozím stavu zhruba 424 jednotek. Za tímto poloměrem entita pro daného klienta neexistuje.

Právě proto OneSync vůbec škáluje, a právě proto se na něm mnoho starších klientských skriptů chová špatně:

• Seznamy hráčů na klientu jsou neúplné. GetActivePlayers() na klientu vrací jen hráče v dosahu. Žebříček postavený na něm ukáže na serveru se šedesáti hráči hrstku jmen. Seznamy hráčů sestavuj na serveru a pošli je dolů.
• Blipy vzdálených hráčů potřebují server. Klient nemůže dát blip na peda, který mu nebyl poslán. Resources s blipy policie a EMS, které na OneSync fungují, posílají souřadnice ze serveru podle časovače.
• Vyhledávání vzdálených entit na klientu selhává. NetworkGetEntityFromNetworkId na klientu nevrátí nic pro entitu mimo jeho dosah. Práci dělej na serveru nebo počkej, až bude entita v dosahu.

FXServer nabízí serverové nativy pro změnu poloměru - SetPlayerCullingRadius pro jednoho hráče a SetEntityDistanceCullingRadius pro jednu entitu. Mají své využití (adminovi, který sleduje, vrtulník, který má být vidět z větší dálky), ale jejich plošné zvyšování posílá víc dat každému klientovi a stojí čas synchronizace, takže je používej pro konkrétní případy, ne jako nastavení.

Routing buckets: oddělené světy na jednom serveru#

Routing bucket je samostatná instance světa. Hráči a entity v bucketu 3 nevidí nic z bucketu 0 a nemohou s ním interagovat, ani když stojí na stejném místě. Všichni začínají v bucketu 0.

-- server side: put a player and their vehicle into a private instanceSetPlayerRoutingBucket(source, 3)SetEntityRoutingBucket(vehicle, 3)-- an empty instance with no ambient traffic and no client-created entitiesSetRoutingBucketPopulationEnabled(3, false)SetRoutingBucketEntityLockdownMode(3, "strict")

Roleplay servery používají buckety pro výběr postavy, interiéry bytů, kde každý hráč dostane vlastní kopii, sledování adminů a akce, které by neměly rušit hlavní město. Jsou levné: prázdný bucket nestojí nic a hráči v různých bucketech se spolu nesynchronizují. Nezapomeň hráče vrátit do bucketu 0, když instanci opustí - hráč zapomenutý v bucketu vidí prázdné město a hlásí, že server je rozbitý. GetPlayerRoutingBucket(source) ti řekne, kde někdo je.

Populace a počty entit#

Okolní doprava a chodci jsou entity a na OneSync jsou to entity sledované serverem. Rušné město se šedesáti hráči jich může nést tisíce a každá stojí sync vlákno. Nastavení, která to řídí:

• `onesync_population false` úplně zastaví okolní populaci. Město je prázdné a server nese jen entity, které vytvářejí skripty. Několik seriózních roleplay serverů tak běží a dopravu spouští jen tam, kde záleží.
• Nativy hustoty na klientu. SetVehicleDensityMultiplierThisFrame, SetPedDensityMultiplierThisFrame a jim podobné populaci snižují, aniž by ji vypnuly. Musí se volat každý snímek, což je jedno z legitimních použití smyčky Wait(0).
• Populace podle bucketu. SetRoutingBucketPopulationEnabled vypíná populaci v konkrétních instancích.

Entity vytvářené skripty jsou druhá polovina. Vozidla spawnutá z garáží a nikdy nezrušená, rekvizity odhozené jobs a ponechané, pedi z misí, které nikdo nedokončil - všechno zůstává ve stavu serveru. Entitám vytvořeným serverem se dá říct, co mají dělat, když u nich nikdo není, pomocí SetEntityOrphanMode na buildech, které ho podporují; jinak je uklízej sám. Pokud varování o hitchích sync vlákna s uptime rostou, první podezřelé je hromadění entit a plánovaný restart je hrubé řešení, než najdeš zodpovědný resource. Časování popisují restarty podle plánu, které pomáhají.

I tady záleží na onesync_forceMigration true. Když se odpojí hráč, který vlastní entitu, server ji předá jinému hráči poblíž místo smazání. Bez toho může auto, které někdo řídil, zmizet ve chvíli, kdy ze hry vypadne.

Entity lockdown#

Protože je server pod OneSync autorita, může klientům odmítnout vytváření entit. To je sv_entityLockdown:

set sv_entityLockdown "relaxed"

Výchozí je inactive, což dovolí cheat menu spawnout jakékoli vozidlo, peda nebo rekvizitu. relaxed blokuje entity vytvořené klientskými skripty a okolní dopravu nechává fungovat; zastaví většinu spamu spawnů, který definuje návštěvu cheatera. strict blokuje všechno, takže se zastaví i okolní populace a každé vozidlo, které hráč dostane, musí vytvořit server.

Lockdown je také filtr tvých resources. Garáž, job nebo adminské menu, které spawnuje vozidla na klientu, se pod relaxed rozbije. Oprava je vytvořit entitu na serveru a klientu předat network ID:

-- server sidelocal veh = CreateVehicleServerSetter(model, "automobile", x, y, z, heading)local netId = NetworkGetNetworkIdFromEntity(veh)TriggerClientEvent("garage:vehicleReady", source, netId)

CreateVehicleServerSetter je novější serverový nativ pro vytváření a u vozidel se upřednostňuje před starším serverovým CreateVehicle; ověř, že ho tvůj build serveru podporuje. Většina současných frameworků a garáží takhle už funguje. Zapnout lockdown v testovací instanci, nebo po bucketech přes SetRoutingBucketEntityLockdownMode, je levný způsob, jak zjistit, které z tvých resources ne. Zbytek obranných nastavení je v možnostech anticheatu pro FiveM.

State bags#

OneSync také umožňuje state bags: data klíč-hodnota připojená k entitě, hráči nebo serveru jako celku, která se automaticky synchronizují klientům.

-- serverPlayer(source).state:set("job", "police", true)   -- true = replicated to clientsEntity(vehicle).state:set("fuel", 64.0, true)GlobalState.weather = "RAIN"-- clientlocal fuel = Entity(vehicle).state.fuel

Nahrazují spoustu ručně psaných eventů typu „pošli všem novou hodnotu“. Jsou ale levné jen tak, jak je používáš: state bag měněný každý snímek na stovce vozidel je sto aktualizací za snímek pro sync vlákno. Zapisuj při změně, ne podle časovače. A state bag, do kterého klient smí zapisovat, jsou data pod kontrolou klienta - serverové skripty nesmějí věřit hodnotám, které klienti smějí nastavit.

Řešení potíží#

`sv_maxclients` nad 32 se ignoruje. OneSync je vypnutý nebo nastavený na místě, které se neprojeví. Ověř onesync on ve výpisu při startu a restartuj celý server.

Server při startu odmítne počet slotů. Úroveň tvého klíče to nedovoluje. Sniž sv_maxclients nebo změň úroveň na účtu, který klíč vlastní.

Žebříček ukazuje jen pár hráčů. Je postavený na klientu přes GetActivePlayers(). Přesuň ho na server.

Garáže po zapnutí lockdownu přestaly spawnovat auta. Vytvářejí vozidla na klientu. Aktualizuj resource nebo ho přepni na vytváření na serveru.

Auta mizí, když se odpojí řidič. Zapni onesync_forceMigration.

Hitche sync vlákna se každou hodinu zhoršují. Hromadění entit. Spočítej, co skripty spawnují a nikdy nemažou, zvaž snížení okolní populace a restartuj podle plánu, než to opravíš.

FAQ#

Je OneSync Infinity pořád samostatné nastavení?

Ne. set onesync on je to, čemu se dřív říkalo Infinity. Starý convar onesync_enableInfinity je zastaralý a legacy existuje jen kvůli kompatibilitě se starými resources.

Kolik slotů může použít volný klíč FiveM?

Historicky 48 se zapnutým OneSync. Vyšší počty vyžadovaly úroveň předplatného Cfx.re na účtu, který klíč vlastní. Cfx.re tyto prahy už dříve měnilo, takže aktuální číslo zkontroluj na portálu.

Proč se hráči přes mapu navzájem nevidí?

To je OneSync culling, který funguje tak, jak má. Každý klient dostává jen entity v okruhu zhruba 424 jednotek. Cokoli, co potřebuje vzdálené hráče - blipy, žebříčky - se musí postavit na serveru.

Zpomalí server vyšší počet slotů?

Sám o sobě ne; prázdný slot nestojí nic. Stojí to hráči, kteří ty sloty zaplní, protože smyčky přes hráče, broadcastované eventy a entity, které si každý hráč přináší, přidávají práci hlavnímu i sync vláknu.

Mám vypnout okolní populaci?

Na vytíženém roleplay serveru stojí za vyzkoušení. Odstraní velký podíl entit a práce synchronizace za cenu prázdného města. Mnoho serverů místo toho snižuje hustotu klientskými nativy, což zachová trochu dopravy za zlomek ceny.