Stripper:Source Guide (Advanced)

<- (Previous) Stripper:Source Guide - Basics | Hammer Editor Guide - Basics (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.