Rendimiento

Versión honesta: los scripts no son la parte pesada. El mapa sí.

El mapa

[the_apocalypse_project] es una conversión del mapa entero sobre Los Santos, con unos 166 ymaps y un MLO. Muchos de sus ymaps tienen extents de streaming de kilómetros, mucho mayores que los props que contienen. Así que el motor cree que la mitad del mapa está a la vista a la vez y todo se carga en el mismo momento alrededor de un jugador que aparece. De ahí viene la presión sobre los pools.

La solución real está en los mapas: ajustar los extents inflados en CodeWalker, con un margen seguro. Vale más que todas las líneas de pool de abajo.

Tamaños de pool

server.cfg aumenta algunos pools con increase_pool_size (la forma moderna, gameconfig.xml ya no se respeta):

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

Son modestos a propósito, no el máximo. Ponerlos al máximo cuesta memoria en cada cliente y Building muy por encima de ~500 causa sus propios problemas.

Mantén set onesync_population false. La población ambiental llena justo los pools que no puedes aumentar.

Zombis

Los límites de zombis ya bajan solos:

• si el tiempo de frame del servidor supera Zombies.Net.perfBudgetMs (70), recorta el límite, hasta perfMinFactor
• si el total de entidades está entre entitySoft y entityHard (1400 / 1900), lo recorta, y por encima de hard se van los caminantes más lejanos
• un jugador por debajo de fpsLow FPS recibe menos caminantes cerca

Ajusta perfBudgetMs según la media de frames que muestra /znet en un servidor inactivo. Si tu servidor es simplemente más lento, el valor por defecto recortará zombis todo el rato.

Del lado del cliente, Streaming.PoolGuard.clientPedLimit (180) frena nuevos peds de caminantes antes de que se llene el pool de peds, y una limpieza de emergencia elimina primero cadáveres y luego los caminantes más lejanos.

Medición

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

No existe /bsperf, los resources no llevan temporizadores internos. Usa resmon.

En octubre revisé todos los scripts del cliente. Casi todos los bucles por frame ya están controlados (duermen 250-1000 ms en reposo). Los pocos que siempre corren por frame son cosas que el motor necesita cada frame (ocultar partes del HUD, densidad de población, luces del apagón). Si ves alguno nuestro alto en resmon en reposo, es un bug, avísame.