Stripper:Source Guide (Advanced)

<- (Previous) Stripper:Source Guide - Basics | Hammer Editor Guide (Next) ->

Contents

Preface

This guide will cover the uses of Stripper in more depth, explain how various entities and mapping elements work and where to use them, practical applications of using Stripper to modify maps, advanced techniques, and how to resolve potential problems or work around Stripper's limitations.

It is highly recommended to read Stripper:Source Guide - Basics first to familiarize yourself with the fundamentals of Stripper, its structure, and its terminology.

Knowledge of Source engine and its entities, and Hammer Editor will also be useful, though not required when starting out.

Ideally, the decompiled versions of Valve's maps should be used for reference and to author your changes before transferring them into Stripper, as for more advanced modifications, relying entirely on Stripper dumps and in-game coordinates/entity placement will not be enough.

Standard Entity Properties

Entities in the Source engine share a standard set of properties that define key information about each individual instances of the entity.

Almost all entities have these properties, though for some they do not support every property, or it is not relevant to some specific entities. Many entities have their own unique properites which will be covered in later sections.

As mentioned in the basics guide, each property in Stripper is defined by a pair of strings, the key and the value. The key is the name of the property, and must be exact (though case is ignored), and the value can be any valid type of value for that key.

The Valve Developer Wiki is the best resource for finding these properties, along with accurate explainations of what they do and what values they accept. This information is also available in the Hammer Editor.

It can also be useful to look in Stripper dumps for the properties of specific entities, to see exactly what they use in-game.

Standard Properties

classname

Type of entity that the object is, examples include: func_brush, prop_dynamic, env_physics_blocker

targetname

Name of the entity, it is not required for the entity to exist, but must be present for the entity to be used in the Input/Output system. targetname does not have to be unique, and can be shared by other entities.
More info on targetname can be found here.

parentname

Name of the entity's parent. The parentname should be the targetname of the desired parent entity. A parented object is called a child. The entity is attached to the parent entity and moves with it relative to its origin. If the parent is killed (removed from the game), the child entity is killed too.

hammerid

Unique ID of each entity. This is selected on creation (when the map is compiled) and cannot be changed or manually selected, and is not exposed directly in-game or in Hammer. It is most often used for selecting entities without a unique targetname. Entities added after map compile time do not have a hammerid.

origin

Cardinal position of the entity on the map. Coordinates are separated by a single space in the format:

"origin" "X Y Z"
// X = East  / West  axis
// Y = North / South axis
// Z = Up    / Down  axis, i.e. vertical position

More info can be found here.

angles

Rotation of the entity about its origin. Angles are separated by a single space in the format:

"angles" "Y Z X"
// OR
"angles" "Pitch Yaw Roll"
// Y / Pitch = +Down  / -Up    (Y-axis rotation)
// Z / Yaw   = +Left  / -Right (Z-axis rotation)
// X / Roll  = +Right / -Left  (X-axis rotation)

Confusingly, none of these align with the coordinates in the origin and are listed as Y Z X in Hammer, as such it may require some experimentation to get the exact angles desired. However, copying the angle directly from the entity properties in Hammer WILL be correct.
A rotation in the 2D views in Hammer will change the angle along the axis of the plane that is not represented in that 2D view (e.g. X/Y view rotates the Z-axis).
More info can be found here, and useful diagrams here.

spawnflags

The value of spawnflags is a number that represents which flags are enabled, flags set an entity's properties on creation. Each entity has a set of boolean spawnflags, enabling one of the flags increases the value of the spawnflags property by a unique amount. This is known as a bitwise operation. The value each flag is represented by can be found on the wiki or by setting the desired flags in Hammer and comparing the values.

Bitwise operations are better understood by demonstration, if you want more explaination then see this wiki page to understand how it works and how to apply it to spawnflags.

model

Model has two distinctly different values. One is the file path of a model, used to select the model for a prop_ entity. The second is a precached brush model for brush entities (e.g. trigger_once), this is an * followed by a number (e.g. *51)

solid

Sets the collision type of props, 6 for VPhysics collision (default), 2 for bounding box collsion (it is never recommended to use this), and 0 for no collision.

StartDisabled

Determines if the entity exists in the map when it loads, can be used for props that only need to exist after a sequence is triggered.

disableshadows

Controls visibility of shadows on props. Shadows on dynamic props look very bad and stand out very clearly, so they should be disabled.

rendercolor

Sets the RGB color value for props.

Entity Inputs & Outputs

All non-static entities are capable of receiving inputs from other entities, and sending outputs to other entities. I/O is a shorthand way of referring to Inputs/Outputs.

The inputs and outputs of each entity varies depending on its type, though there is a standard set that all entities share. There are many I/Os that are also shared between many standard and L4D2-exclusive entities.

This input and output system how entities interact with each other in maps. It is the main method for scripting events and actions in Source engine maps, in L4D2 it is used heavily for things players interact with directly, and things that happen around them in the background. It is a very powerful system that has many possible uses beyond the scope of Stripper's three main functions.

The system works by having one entity send an output upon specific events, another entity can then receive that input and perform an action. For example, when a door is opened, it has an output to make a light entity turn on. An input is just another entity's output.

For a more detailed explaination of how this system works, read this article on the Valve Developer Wiki. A full overview of the system can be found on I/O System category page.

I/O Syntax

The I/O system has two parts, the event, or Output Name, which causes the output to fire, and the actual parameter that defines what the output does.

The event types that can be used depend on the entity the output is fired by, these events can occur through players interacting with the game, or by other entities firing outputs.

For example, a prop_door_rotating can use OnOpen as an output event. This could fire when a player manually opens a door, or when the door receives an Open input from another entity.

The output parameter defines what an output does. Technically, these are multiple separate values, but for Stripper's purposes they are all in a single string, separated by commas.

NOTE: In Stripper dumps, this will be the unicode escape character u001b instead, which depending on the text editor used may not be displayed. It can be replaced by a comma without issue. It is recommended to use a source code editor such as Notepad++ for Stripper.

The values defined in the parameter are:

• Target Entities Named - Name of the entities to apply the output to. This can be either the targetname or the classname, and it will apply to all entities that match. An entity CAN target itself with an output. Special entity names can be used too, as seen here.
• Via This Input / Input Name - Name of the input to fire on the selected entity. The inputs available will depend on the type of entity targeted. The input selected will cause the entity to change that property or perform an action, such as changing color.
• Parameter Override - Specifies additional arguments for the input, meaning different values can be given for an input if applicable.
• Delay This Input - Delay in seconds before this input is fired by the target entity, from when the output is triggered. Can be a non-integer value.
• Fire Only Once - Number of times the output can be fired. -1 is infinite (no limit), and is the default.

More information on these parameters can be found here.

Usually, an entity will have an output type for any input that can be fired for it, so when an input is fired it can be followed up with an output by that entity. Though this is not the case for all inputs on all entities.

Together, the event and the parameter will create a single key-value pair like this:

; // Event                               Parameter String                            
"[Output Name]" "[Target],[Input Name],[Parameter Override],[Delay],[Fire Only Once]"

; // Example of I/O system in use on an entity
add:
{
	"classname" "func_button"
	"origin" "2048 5706 2884.89"
	"model" "*5"
	; // When button is pressed, wait 3 seconds, then tell director to spawn a panic event horde
	"OnPressed" "director,ForcePanicEvent,,3,-1"
}

Useful Entities

Generally only a handful of entity types are used when making changes for Stripper configs. You can find the set of standard entities and parameters used in this rework here, and you can find more entities on the Valve Developer Wiki.

env_physics_blocker

Blocks player movement using a VPhysics box, completely replacing env_player_blocker. The mins and maxs parameters determine the negative and positive dimensions of the box from the origin. The BlockType parameter determines which types of players or entities to block:

0 = Everyone (Players)
1 = Survivors
2 = Infected (Players)
3 = Infected (Players & AI)
4 = Everyone & Physics Objects

Physics blockers can also be rotated like any prop by specifying the angles paramater. This requires 2 additional parameters to be added: boxmins and boxmaxs, their values should be the same as mins and maxs.
Instructions on how to view physics blockers can be in-game can be found here.

prop_dynamic

Adds new props to the map. The model parameter determines the model of the entity. Dynamic props do not behave exactly the same as static props, but they are the best entity available for adding new props.

prop_physics

Adds new physics props to the map, primarily used for adding hittables. Does not require any different parameters from dynamic props to function correctly.

weapon_ammo_spawn

Adds new ammo piles to the map. Setting the spawnflags parameter to 2 ensures that the ammo pile always spawns.

weapon_spawn

Adds new weapon spawns to the map. The weapon_selection parameter is used to determine the types of weapons it can spawn, the values of which can be found here. Setting spawnflags to 2 and spawn_without_director to 1 ensures that the weapon always spawns.
Single pickup weapons can be added using the classnames found here.

weapon_melee_spawn

Adds new melee weapons to the map, same as weapon_spawn except melee_weapon determines the types of weapons it can spawn, the values of which can be found here.

weapon_item_spawn

Adds new item spawns to the map. spawnflags value of 2 means the item will always spawn, 8 means the item is infinite. The itemX paramerers determine which types of item could potentially spawn:

item1 = Ammo Pile
item2 = First Aid Kit
item3 = Molotov
item4 = Pills
item5 = Pipebomb
item6 = Oxygen Tank
item7 = Propane Tank
item8 = Gas Can
item11 = Adrenaline
item12 = Defib
item13 = Bile
item16 = Chainsaw
item17 = Grenade Launcher
item18 = M60

Alternatively, weapon_pain_pills_spawn can be used to just add pill spawns.

func_simpleladder

Creates a new ladder entity on the map, however the ladder must be "cloned" from an existing ladder to function correctly. More information can be found here.

logic_auto

Fires outputs when a map loads, instead of waiting for inputs like other entities.

logic_relay

Used to fire many outputs from just one input, useful to organize more complicated events or fire outputs for entities with many instances in the map.

func_brush

A generic brush entity with various features. While new func_brush entities can be created, textures cannot be added to created brushes. However cloned brushes will retain their textures. func_brush entities can have different solidity per team, can be moved, broken, enabled or disabled. They also can be used to invisibily block line of sight and allow non-solid entities to be solid.
More information can be found here.

Useful Methods

Stripper can be applied as a solution to many of the issues that L4D2's maps create for competitive play. While many small fixes and improvements are simple; using a env_physics_blocker to block an exploit, or changing a single property of an entity for example, there are more complicated problems that require some less obvious methods to solve them.

Creating Custom Brushes

It is possible to create brand new brushes, such as trigger volumes and func_brush entities. Though this technique is not without its limitations: not all created brush entity types work, brushes cannot be rotated, textures cannot be added, and collision with solid brushes causes noticable "screen lag`.

To create a custom brush, a logic_auto entity along with the desired brush entity must be created with the following properties:

add:
{
	"classname" "logic_auto"
	"OnMapSpawn" "[brush name],AddOutput,mins [-x -y -z],0,-1"
	"OnMapSpawn" "[brush name],AddOutput,maxs [x y z],0,-1"
	"OnMapSpawn" "[brush name],AddOutput,solid 2,0,-1"
}
{
	"classname" "[brush type]"
	"origin" "[x y z]"
	"targetname" "[brush name]"
}

The logic_auto will fire the AddOutput outputs when the map loads, by specifying the mins and maxs in exactly the same way we do for env_physics_blocker entities, we can create a box of the desired size for brush entity. The solid property is required for the brush to function, as it defines the collision checking method used (2 = bounding box collsion).

From here, any additional properties the entity uses can be specified, for example trigger_teleport could specify a teleport destination and an input for teleporting players that touch it. If the brush is not behaving as expected, make sure to specify the spawnflags property, as not all brushes have sensible defaults. If certain properties are not functioning at all, they may need to be specified through an AddOutput method.

Cloning Brush Entities

The brushes created with this technique are not actually "cloned", they are new entities that use the brush model of an existing brush entity, which can give the appearance of cloning. This technique is most commonly used for creating new ladders, as the custom brush method above does not work for ladders.

This method is useful as it allows brushes with a visible texture or any special requirements (e.g. ladder entities) to be created, the brushes can be rotated, and the brushes can be unique shapes that cannot be created with only cubes. The limitation is that the desired brush shape must exist somewhere on the map, its shape and appearance cannot be modified, and some brush entities cannot be used as a clone source.

Cloned ladders have some additional complications, methods for cloning ladders will be covered here.

First, the brush entity you want to clone must be located, either in-game or in Hammer, then you must find the entity in the stripper dump for that map. The property you need from the entity is the model, for example:

{
"model" "*3"
"origin" "-4064 7114.5 352.75"
"classname" "trigger_multiple"
"hammerid" "5384"
}

This model property is the brush model for that entity, which is created as a pre-cached model when the map is compiled. We can use this in an entity we create like this:

add:
{
	"classname" "trigger_once"
	"origin" "-2974 1708 385"
	"model" "*3"
	"StartDisabled" "0"
	"spawnflags" "1"
	"filtername" "survivor_filter"
	"targetname" "coaster_button_block_trigger"
	"OnStartTouch" "coaster_button_block,Kill,,0,-1"
}

Here we've create a new trigger of a different type, in the position specified by the origin, using the brush model from the other entity. The other properties are an example of how this brush could be used (this example is a trigger to remove a blocker on the coaster).

It's important to note that the origin is NOT always the center point of the actual brush model, the origin of some brush entities is a separately defined property, some brushes will be offset from the origin. For our cloned brushes, we cannot modify this offset, the model will be the same distance away from the origin we specify as the original brush was from its origin. The origin is represented as a blue sphere when the brush is selected in Hammer.

Brushes cloned from entities with the trigger texture should be viewable by using the command showtriggers_toggle.

Model Glows / Outline

Rendermode Property

The rendermode property of prop_ entities can be used to change how the model is rendered. Most notably, props can be made invisible, which was a previous method of blocking line of sight.