prop_static vs prop_dynamic vs prop_physics : différences et erreurs

Un prop_static est inscrit dans le BSP à la compilation et n’est plus une entité en jeu : il ne bouge jamais, n’accepte aucun input et n’occupe aucune place dans le budget d’entités. Un prop_dynamic est une vraie entité qui joue des animations, peut être parentée à d’autres entités et se contrôle par des inputs. Un prop_physics est une entité simulée par le système physique : il tombe, roule et peut être poussé. Les types qu’un modèle prend en charge sont fixés à la compilation du modèle, et c’est exactement ce que VBSP vérifie quand il supprime un prop_static de ta map.

Les trois types comparés

VBSP écrit les props statiques dans leur propre section du BSP et les retire de la liste des entités. Lors d’un test avec le VBSP de GMod, il ne restait aucun prop_static dans le lump d’entités après la compilation, alors que chaque prop_dynamic et chaque prop_physics y figurait. Les sections d’un BSP sont décrites dans Qu’est-ce qu’un fichier BSP ?.

Pour un serveur, c’est la dernière ligne qui compte le plus. Chaque prop dynamique ou physique occupe l’un des emplacements limités réservés aux entités en réseau. Ce qui se passe quand ils viennent à manquer est expliqué dans l’article sur la limite d’edicts.

Éclairage, collision et performances

Des trois types, VRAD n’intègre que prop_static à l’éclairage. Il projette des ombres sur les lightmaps et, avec l’option VRAD -StaticPropLighting, sa lumière est calculée par vertex. Les props dynamiques et physiques n’influencent pas les lightmaps. Ils sont éclairés en un seul point et ne projettent que des ombres dynamiques. Une maison placée en prop_dynamic n’a donc pas d’ombre précalculée, et si son point d’échantillonnage se trouve dans le noir, tout le modèle paraît trop sombre. Les options sont expliquées dans l’éclairage dans le Source Engine.

Pour la collision, le réglage Use VPhysics utilise le modèle de collision du modèle. Si le modèle n’en a pas, le moteur affiche un avertissement au chargement et le prop devient non solide, d’après la Valve Developer Community. Un prop_physics sans modèle de collision ne reçoit aucun objet physique. Dans le code standard du Source Engine (Source SDK 2013), le jeu signale alors ERROR!: Can't create physics object for [model] et laisse le prop immobile et non solide. La server.dll de Garry’s Mod contient le même message.

Comme ordre de grandeur, la Valve Developer Community cite des milliers de props statiques par map, des centaines de props dynamiques et, selon la complexité, des dizaines à des centaines de props physiques. Un prop statique n’a aucun coût réseau, alors qu’un prop physique doit être simulé et transmis à chaque joueur.

Ce que le modèle impose et comment le voir dans Hammer

Deux informations contenues dans le modèle décident des types autorisés. La commande QC $staticprop retire le squelette et les animations et est obligatoire pour prop_static. Un bloc prop_data contient les valeurs de physique et de dégâts et marque le modèle comme prop physique. La raison avancée pour cette séparation est la cohérence : un baril qui roule sur une map ne doit pas être boulonné au sol sur la suivante.

Voici comment vérifier un modèle :

1. Dans les propriétés du prop, ouvre le Model Browser depuis l’entrée World model.
2. Sélectionne le modèle et passe à l’onglet Info.
3. Lis les trois coches physics, dynamic et static. La masse est indiquée en dessous.

Les variantes, une phrase chacune

• prop_dynamic_override : comme prop_dynamic, mais accepte les modèles prévus comme props physiques. Le FGD le décrit comme une entité de prototypage uniquement.
• prop_physics_override : comme prop_physics, mais passe outre les données stockées dans le modèle et autorise une valeur Health personnalisée. Le modèle a quand même besoin d’un modèle de collision.
• prop_physics_multiplayer : comme prop_physics, avec des collisions simplifiées qui évitent les erreurs de prédiction sur le réseau et la propriété supplémentaire Physics Mode.
• prop_detail : un prop de détail sans collision qui finit dans le BSP comme prop_static. On le place rarement à la main ; en général, VBSP génère les props de détail à partir du matériau.
• prop_ragdoll : un prop physique avec des articulations. Il coûte cher à simuler et génère beaucoup de trafic réseau.

Messages typiques et ce qu’il faut faire

Ces lignes proviennent d’un test avec le 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 : Le modèle a un prop_data sans allowstatic. Utilise prop_physics, ou prop_dynamic_override s’il doit rester immobile. Pour un modèle à toi, ajoute allowstatic ou omets prop_data. Le VBSP de GMod a aussi l’option -allowdynamicpropsasstatic, qui désactive cette vérification.
• must be compiled with $staticprop : Le modèle a été compilé sans $staticprop, en général parce qu’il a des bones ou des animations. Utilise prop_dynamic ou recompile ton propre modèle avec $staticprop.
• Error loading studio model seul : Si la ligne apparaît dans le log sans l’une des deux autres, VBSP n’a pas trouvé le fichier du modèle. Les causes sont décrites dans Corriger les textures manquantes et les modèles ERROR.
• outside the map : Le prop se trouve en dehors de la zone étanche ou entièrement à l’intérieur d’un brush. Déplace-le. Dans le test, le prop situé hors de la zone étanche a en plus provoqué un leak (**** leaked ****), car VBSP l’y traite comme n’importe quelle autre entité. Un prop entièrement enfoui dans un brush n’a produit que cette seule ligne.

VBSP continue de compiler dans les quatre cas. Le prop est simplement absent en jeu, et seul le log révèle pourquoi. Colle-le dans le Map Scanner ou cherche le message dans la base d’erreurs. Les autres lignes sont traitées dans lire un compile log.

Pour prop_dynamic et prop_physics, VBSP ne vérifie rien. Dans le code standard du Source Engine (Source SDK 2013), c’est le jeu qui fait la vérification au moment où il crée le prop : il supprime un prop inadapté et, avec developer 1 activé, écrit dans la console : 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 ne contient ni ce texte ni son équivalent pour prop_dynamic. Seul le message pour un type de prop_data invalide y figure encore. Ça laisse penser que GMod n’applique pas cette vérification, et ça collerait avec le fait que Sandbox crée chaque prop spawné en tant que prop_physics, quel que soit le modèle. Ça n’a pas été testé dans le jeu en cours d’exécution, alors ne t’appuie pas là-dessus en tant que mappeur : si tu suis l’onglet Info, la map se comporte de la même façon dans tous les jeux Source.

Tableau de décision

Questions fréquentes

Les joueurs peuvent-ils déplacer les props de ma map avec le Physics Gun ?

Un prop_static, jamais, car ce n’est pas une entité. En Sandbox, un prop_dynamic ou un prop_physics de la map peut être attrapé par défaut. Régler la propriété Allow Physics Gun (gmod_allowphysgun) sur No verrouille un prop en particulier. Les autres modes de jeu et les addons de prop protection appliquent leurs propres règles.

Puis-je masquer ou détruire un prop_static en jeu ?

Non. Il n’a pas de nom et n’accepte aucun input. Utilise pour ça un prop_dynamic, qui dispose des inputs TurnOff et TurnOn. La façon de les câbler est expliquée dans inputs et outputs dans Hammer.

Un prop_static compte-t-il dans une limite quelconque ?

Pas à l’exécution, ni comme entité ni comme edict. À la compilation, en revanche, VBSP le compte dans son propre plafond d’entrées dans le fichier de map. Pour une vue d’ensemble, consulte les limites des maps du Source Engine.