Salta ai contenuti

Prestazioni

Versione onesta: gli script non sono la parte pesante. La mappa sì.

[the_apocalypse_project] è una conversione dell’intera mappa sopra Los Santos, circa 166 ymap e un MLO. Molte delle sue ymap hanno extent di streaming di chilometri, molto più grandi dei prop che contengono. Così il motore pensa che metà della mappa sia in portata nello stesso momento e tutto viene caricato insieme attorno a un giocatore che fa spawn. Da lì viene la pressione sui pool.

La vera soluzione è nelle mappe: stringere gli extent gonfiati in CodeWalker, con un margine di sicurezza. Vale più di tutte le righe di pool qui sotto.

server.cfg alza alcuni pool con increase_pool_size (il modo moderno, gameconfig.xml non viene più rispettato):

increase_pool_size "Building" 500
increase_pool_size "StaticBounds" 2000
increase_pool_size "EntityDescPool" 5000
increase_pool_size "TxdStore" 8000
increase_pool_size "FragmentStore" 4000
increase_pool_size "fragInstGta" 800
increase_pool_size "Object" 800
# + interior/portal/occlusion, LightEntity, AttachmentExtension

Sono modesti di proposito, non al massimo. Il massimo costa memoria su ogni client e Building molto oltre ~500 causa problemi suoi.

Tieni set onesync_population false. La popolazione ambientale riempie esattamente i pool che non puoi alzare.

I limiti degli zombie si riducono già da soli:

  • il tempo di frame del server oltre Zombies.Net.perfBudgetMs (70) taglia il limite, fino a perfMinFactor
  • il totale di entità tra entitySoft e entityHard (1400 / 1900) lo taglia, e oltre hard spariscono i vaganti più lontani
  • un giocatore sotto fpsLow FPS ha meno vaganti vicino

Regola perfBudgetMs in base alla media dei frame che /znet mostra su un server inattivo. Se il tuo server è semplicemente più lento, il valore predefinito taglierà zombie in continuazione.

Lato client, Streaming.PoolGuard.clientPedLimit (180) ferma i nuovi ped dei vaganti prima che il pool dei ped si riempia, e una pulizia d’emergenza rimuove prima i cadaveri, poi i vaganti più lontani.

resmon 1 -- client, per resource ms
profiler record 500 -- then profiler view
/znet -- zombie caps and server frame
/pools -- client ped pool

Non esiste /bsperf, le resource non tengono timer interni. Usa resmon.

A ottobre ho passato in rassegna tutti gli script client. Quasi tutti i loop per frame sono già limitati (dormono 250-1000 ms da fermi). I pochi che girano sempre a ogni frame sono cose di cui il motore ha bisogno a ogni frame (nascondere parti dell’HUD, densità di popolazione, luci del blackout). Se vedi uno dei nostri alto in resmon da fermo, è un bug, dimmelo.