prop_static vs prop_dynamic vs prop_physics: diferencias y errores

Un prop_static se escribe en el BSP al compilar y en el juego deja de ser una entity: nunca se mueve, no acepta inputs y no ocupa ningún hueco en el presupuesto de entities. Un prop_dynamic es una entity de verdad que reproduce animaciones, se puede emparentar a otras entities y se controla mediante inputs. Un prop_physics es una entity simulada por el sistema de física, así que cae, rueda y se puede empujar. Qué tipos admite un modelo se decide al compilar el modelo, y eso es justo lo que comprueba VBSP cuando borra un prop_static de tu mapa.

Los tres tipos comparados

VBSP escribe los props estáticos en una sección propia del BSP y los quita de la lista de entities. En una prueba con el VBSP de GMod, tras compilar no quedaba ningún prop_static en el entity lump, mientras que todos los prop_dynamic y prop_physics seguían ahí. Las secciones de un BSP se describen en ¿Qué es un archivo BSP?.

Para un servidor, la última fila es la que más importa. Cada prop dinámico o físico ocupa uno de los huecos limitados para entities en red. Qué pasa cuando se agotan se explica en el artículo sobre el límite de edicts.

Iluminación, colisión y rendimiento

De los tres tipos, VRAD solo incluye prop_static en la iluminación. Proyecta sombras sobre los lightmaps y, con la opción de VRAD -StaticPropLighting, su luz se calcula por vértice. Los props dinámicos y físicos no afectan a los lightmaps. Se iluminan en un único punto y solo proyectan sombras dinámicas. Por eso una casa colocada como prop_dynamic no tiene sombra precalculada, y si su punto de muestreo queda a oscuras, todo el modelo se ve demasiado oscuro. Las opciones se explican en iluminación en Source Engine.

En cuanto a la colisión, el ajuste Use VPhysics usa el modelo de colisión del modelo. Si el modelo no tiene ninguno, el motor muestra una advertencia al cargar y el prop pasa a ser no sólido, según Valve Developer Community. Un prop_physics sin modelo de colisión no recibe ningún objeto físico. En el código estándar de Source Engine (Source SDK 2013), el juego informa entonces de ERROR!: Can't create physics object for [model] y deja el prop inmóvil y no sólido. La server.dll de Garry's Mod contiene el mismo mensaje.

Como orden de magnitud, Valve Developer Community cita miles de props estáticos por mapa, cientos de dinámicos y, según la complejidad, de decenas a cientos de props físicos. Un prop estático no tiene coste de red, mientras que un prop físico hay que simularlo y transmitirlo a cada jugador.

Qué impone el modelo y cómo verlo en Hammer

Dos datos del modelo deciden qué tipos están permitidos. El comando QC $staticprop elimina el esqueleto y las animaciones y es obligatorio para prop_static. Un bloque prop_data contiene los valores de física y de daño y marca el modelo como prop físico. El motivo que se da para esta separación es la coherencia: un barril que rueda en un mapa no debería estar atornillado al suelo en el siguiente.

Así compruebas un modelo:

1. En las propiedades del prop, abre el Model Browser desde la entrada World model.
2. Selecciona el modelo y cambia a la pestaña Info.
3. Lee las tres marcas de verificación physics, dynamic y static. Debajo aparece la masa.

Las variantes, en una frase cada una

• prop_dynamic_override: como prop_dynamic, pero acepta modelos pensados como props físicos. El FGD lo describe como una entity solo para prototipos.
• prop_physics_override: como prop_physics, pero pasa por encima de los datos guardados en el modelo y permite un valor de Health propio. El modelo sigue necesitando un modelo de colisión.
• prop_physics_multiplayer: como prop_physics, con colisiones simplificadas que evitan errores de predicción en la red y la propiedad adicional Physics Mode.
• prop_detail: un prop de detalle sin colisión que acaba en el BSP igual que prop_static. Rara vez se coloca a mano; normalmente VBSP genera los props de detalle a partir del material.
• prop_ragdoll: un prop físico con articulaciones. Simularlo sale caro y genera mucho tráfico de red.

Mensajes típicos y qué hacer con ellos

Estas líneas salen de una prueba con el VBSP de GMod:

Error! prop_static using model "models/props_c17/oildrum001.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted.
Error! To use model "models/props_c17/door01_left.mdl" with prop_static, it must be compiled with $staticprop!
Error loading studio model STATIC "models/props_does_not/exist.mdl"!
Static prop models/props_c17/fence01a.mdl outside the map (2000.00, 2000.00, 0.00)

• must be used on a dynamic entity: El modelo tiene prop_data sin allowstatic. Usa prop_physics, o prop_dynamic_override si debe quedarse quieto. En un modelo tuyo, añade allowstatic u omite prop_data. El VBSP de GMod tiene además la opción -allowdynamicpropsasstatic, que desactiva esta comprobación.
• must be compiled with $staticprop: El modelo se compiló sin $staticprop, normalmente porque tiene huesos o animaciones. Usa prop_dynamic o vuelve a compilar tu propio modelo con $staticprop.
• Error loading studio model por sí solo: Si la línea aparece en el log sin ninguna de las otras dos, VBSP no ha encontrado el archivo del modelo. Las causas se describen en Solucionar texturas que faltan y modelos ERROR.
• outside the map: El prop está fuera de la zona sellada o completamente dentro de un brush. Muévelo. En la prueba, el prop que estaba fuera de la zona sellada provocó además un leak (**** leaked ****), porque ahí VBSP lo trata como a cualquier otra entity. Un prop enterrado por completo en un brush solo produjo esta única línea.

VBSP sigue compilando en los cuatro casos. Simplemente, el prop falta en el juego, y solo el log revela por qué. Pégalo en el Map Scanner o busca el mensaje en la base de datos de errores. El resto de las líneas se tratan en cómo leer un compile log.

Con prop_dynamic y prop_physics, VBSP no comprueba nada. En el código estándar de Source Engine (Source SDK 2013), la comprobación la hace el juego al crear el prop: borra un prop que no encaja y, con developer 1 activado, escribe en la consola: prop_physics at [x] [y] [z] uses model [model], which has no propdata which means it must be used on a prop_static. DELETED. La server.dll de Garry's Mod no contiene ni este texto ni su equivalente para prop_dynamic. Solo sigue ahí el mensaje para un tipo de prop_data no válido. Esto apunta a que GMod no aplica la comprobación, y encajaría con que Sandbox cree cada prop spawneado como prop_physics, sea cual sea el modelo. No se ha probado con el juego en marcha, así que como mapper no te fíes de ello: si te guías por la pestaña Info, el mapa se comporta igual en todos los juegos de Source.

Tabla de decisión

Preguntas frecuentes

¿Pueden los jugadores mover los props de mi mapa con la Physics Gun?

Un prop_static nunca, porque no es una entity. En Sandbox, un prop_dynamic o un prop_physics del mapa se puede agarrar por defecto. Poner la propiedad Allow Physics Gun (gmod_allowphysgun) en No bloquea un prop concreto. Otros modos de juego y los addons de prop protection aplican sus propias reglas.

¿Puedo ocultar o destruir un prop_static en el juego?

No. No tiene nombre y no acepta inputs. Para eso usa un prop_dynamic, que tiene los inputs TurnOff y TurnOn. Cómo conectarlos se explica en inputs y outputs en Hammer.

¿Cuenta un prop_static para algún límite?

En tiempo de ejecución no, ni como entity ni como edict. Al compilar, en cambio, VBSP lo cuenta para su propio tope de entradas en el archivo del mapa. Tienes una visión general en límites de los mapas de Source Engine.