Desempenho

Versão honesta: os scripts não são a parte pesada. O mapa é.

O mapa

O [the_apocalypse_project] é uma conversão do mapa inteiro por cima de Los Santos, com cerca de 166 ymaps e um MLO. Muitos dos seus ymaps têm extents de streaming de quilómetros, muito maiores do que os props lá dentro. Por isso o motor pensa que metade do mapa está ao alcance ao mesmo tempo e tudo faz streaming no mesmo instante à volta de um jogador que dá spawn. É daí que vem a pressão nas pools.

A solução verdadeira está nos mapas: apertar os extents inflacionados no CodeWalker, com uma margem segura. Vale mais do que todas as linhas de pool abaixo.

Tamanhos de pool

O server.cfg aumenta algumas pools com increase_pool_size (a forma moderna, o gameconfig.xml já não é respeitado):

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

Estes valores são modestos de propósito, não são o máximo. Pô-los no máximo custa memória em todos os clientes e Building muito acima de ~500 causa problemas próprios.

Mantém set onesync_population false. A população ambiente enche exatamente as pools que não consegues aumentar.

Zombies

Os limites de zombies já diminuem sozinhos:

• tempo de frame do servidor acima de Zombies.Net.perfBudgetMs (70) corta o limite, até perfMinFactor
• o total de entidades entre entitySoft e entityHard (1400 / 1900) corta-o, e acima do hard os caminhantes mais distantes desaparecem
• um jogador abaixo de fpsLow FPS tem menos caminhantes perto de si

Ajusta perfBudgetMs com base na média de frames que o /znet mostra num servidor parado. Se o teu servidor for simplesmente mais lento, o valor por defeito vai cortar zombies o tempo todo.

No cliente, Streaming.PoolGuard.clientPedLimit (180) impede novos peds de caminhantes antes de a pool de peds encher, e um corte de emergência remove primeiro os cadáveres, depois os caminhantes mais distantes.

Medição

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

Não existe /bsperf, os resources não guardam temporizadores internos. Usa o resmon.

Em outubro revi todos os scripts do cliente. Quase todos os loops por frame já estão controlados (dormem 250-1000 ms quando parados). Os poucos que correm sempre por frame são coisas de que o motor precisa a cada frame (esconder partes do HUD, densidade de população, luzes do apagão). Se vires algum dos nossos alto no resmon em repouso, é um bug, diz-me.