Performances

Version honnête : les scripts ne sont pas la partie lourde. C’est la map.

La map

[the_apocalypse_project] est une conversion de toute la carte par-dessus Los Santos, environ 166 ymaps et un MLO. Beaucoup de ses ymaps ont des extents de streaming de plusieurs kilomètres, bien plus grands que les props qu’ils contiennent. Le moteur croit donc que la moitié de la map est à portée en même temps, et tout se charge au même moment autour d’un joueur qui spawn. C’est de là que vient la pression sur les pools.

La vraie solution est dans les maps : resserrer les extents gonflés dans CodeWalker, avec une marge de sécurité. Ça vaut plus que toutes les lignes de pool ci-dessous.

Tailles de pool

server.cfg augmente certains pools avec increase_pool_size (la méthode moderne, gameconfig.xml n’est plus pris en compte) :

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

Elles sont modestes volontairement, pas au maximum. Les mettre au max coûte de la mémoire sur chaque client et Building bien au-dessus de ~500 pose ses propres problèmes.

Garde set onesync_population false. La population ambiante remplit exactement les pools que tu ne peux pas augmenter.

Zombies

Les limites de zombies baissent déjà toutes seules :

• un temps de frame serveur au-dessus de Zombies.Net.perfBudgetMs (70) réduit la limite, jusqu’à perfMinFactor
• un total d’entités entre entitySoft et entityHard (1400 / 1900) la réduit, et au-delà de hard les rôdeurs les plus éloignés disparaissent
• un joueur sous fpsLow FPS a moins de rôdeurs autour de lui

Règle perfBudgetMs d’après la moyenne de frames que /znet affiche sur un serveur au repos. Si ton serveur est simplement plus lent, la valeur par défaut coupera des zombies en permanence.

Côté client, Streaming.PoolGuard.clientPedLimit (180) bloque les nouveaux peds de rôdeurs avant que le pool de peds soit plein, et un nettoyage d’urgence retire d’abord les cadavres, puis les rôdeurs les plus éloignés.

Mesure

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

Il n’y a pas de /bsperf, les resources ne gardent pas de chronomètres internes. Utilise resmon.

En octobre, j’ai passé en revue tous les scripts client. Presque toutes les boucles par frame sont déjà limitées (elles dorment 250-1000 ms au repos). Les rares qui tournent toujours à chaque frame sont des choses dont le moteur a besoin à chaque frame (masquer des parties du HUD, densité de population, lumières du blackout). Si tu vois une des nôtres haute dans resmon au repos, c’est un bug, dis-le-moi.