The Problem.
Whether it be reducing console error spam or preventing players from perching inappropriately on tall props, as a map author you will need to control vertical player mobility utilising clever applications of prop vphysics settings and playerclip brushes.
Sometimes it is difficult to tell which props will require non-solid parameters and/or playercliping in order to keep players within appropriate map bounds vurses keeping realistic collisions. Whether it's because of balance issues (tall/high props are often exploited for ambush positions) or aesthetical reasons (props that can be perched on allow players further and greater visibility, often into areas you might not desire players to see; such as where holes in displacements and/or non-rendered faces are exposed behind other geometry). So, with it not always immediately visually apparent whether collisions will benefit gameplay or aesthetics or whether they will be detrimental, with a visual representation we can better simulate such gameplay in our mind and make appropriate modifications to your environment more immediately.
Usefulness.
As some of the more experienced users might be aware,
can be used to view prop collision meshes, but what it also allows you to see is whether a prop even has a collision mesh and whether it is turned on or off. Yellow means a collision mesh is on, purple means it is off, and an absent mesh means the prop has no valid collision mesh.
How can we use this feature to improve our maps/mapping efficiency?
Well, for starters, turning all props with absent meshes to non-solid clears our console of collision error spam. Some people might not be concerned with this as it has no real impact on gameplay besides perhaps increasing the map's initial load time; but more professional, methodical or OCD prone level designers will prefer to keep things as clean as possible. Including the rarely viewed console.
Secondly it allows us to spot potential exploitable positions and pre-emptively remove them before the chance arises for players to exploit and throw off map balance or immersion, potentially reducing the amount of alpha/beta releases you are required to publish.
Feature in action:
Here i have discovered a place that soldiers and/or demomen may exploit: I can choose to turn off the collision as the prop is so small, clipping will not be an issue. If the prop was wider and i didn't desire players to clip through it, i might be better off adding a player clip above/around it.
Whether it be reducing console error spam or preventing players from perching inappropriately on tall props, as a map author you will need to control vertical player mobility utilising clever applications of prop vphysics settings and playerclip brushes.
Sometimes it is difficult to tell which props will require non-solid parameters and/or playercliping in order to keep players within appropriate map bounds vurses keeping realistic collisions. Whether it's because of balance issues (tall/high props are often exploited for ambush positions) or aesthetical reasons (props that can be perched on allow players further and greater visibility, often into areas you might not desire players to see; such as where holes in displacements and/or non-rendered faces are exposed behind other geometry). So, with it not always immediately visually apparent whether collisions will benefit gameplay or aesthetics or whether they will be detrimental, with a visual representation we can better simulate such gameplay in our mind and make appropriate modifications to your environment more immediately.
Usefulness.
As some of the more experienced users might be aware,
can be used to view prop collision meshes, but what it also allows you to see is whether a prop even has a collision mesh and whether it is turned on or off. Yellow means a collision mesh is on, purple means it is off, and an absent mesh means the prop has no valid collision mesh.How can we use this feature to improve our maps/mapping efficiency?
Well, for starters, turning all props with absent meshes to non-solid clears our console of collision error spam. Some people might not be concerned with this as it has no real impact on gameplay besides perhaps increasing the map's initial load time; but more professional, methodical or OCD prone level designers will prefer to keep things as clean as possible. Including the rarely viewed console.
Secondly it allows us to spot potential exploitable positions and pre-emptively remove them before the chance arises for players to exploit and throw off map balance or immersion, potentially reducing the amount of alpha/beta releases you are required to publish.
Feature in action:
Here i have discovered a place that soldiers and/or demomen may exploit: I can choose to turn off the collision as the prop is so small, clipping will not be an issue. If the prop was wider and i didn't desire players to clip through it, i might be better off adding a player clip above/around it.
Last edited:
