Stripper CFGs Guide

Calig · August 7

Guide Sections :

Introduction
1. Reason for creating this guide
2. Entities
3. Stripper:Source plugin
Configuration file creation
1. Addition and deletion of entities
2. Modification of entities
3. Saving as CFG
4. Decompiling
5. Inputs and Outputs
Important links for reference
Notes

Introduction:

Reason for creating this guide:

Welcome to my guide on: how to create configuration files for the stripper plugin! The goal that I had in mind when I started creating this guide, was compiling a bunch of resources for GFL CS:GO ZE admins who are interested in the "technical" side of zombie escape. When I first started to get interested in these types of things, I noticed that there wasn't much discussion about it, so I had to go around different zombie escape communities in order to learn what I had wanted to learn. With the creation of this guide; and maybe more if I can keep learning lul, I hope that I'm able to help out any future people who are interested in learning more about the technical side of zombie escape, but are struggling to find resources for/assistance with it. Aside from this, making configuration files for the stripper plugin has many use cases. You can make use of the plugin to tweak values for mechanics in maps, block off areas, or even to fix certain entities which are causing undesirable behavior, etc.

Entities:

Before we get into the guide, you must first understand what an entity is, in the context of the Source Engine. According to the VALVE developer community wiki, an entity is defined as: "An object defined within the Source Engine as having characteristics which differentiate it from the world."

You can find a list of all available entities here:

(https://developer.valvesoftware.com/wiki/List_of_base_entities)

(https://developer.valvesoftware.com/wiki/List_of_Counter-Strike:_Global_Offensive_Entities)

Stripper:Source plugin:

BAILOPAN's stripper plugin is a utility for Source Engine servers which allows servers to mess around with Source Engine entities. Unlike most server plugins, this plugin actually runs on top of Metamod (what SourceMod runs on) instead of being a SourceMod plugin. This doesn't really mean anything to the layman, other than that you install it differently. Originally, plugin-users only had the ability to: permanently add entities to a map, and delete entities via usage of the filter directive. But in 2006 new syntax was added to the plugin, which allowed for more flexible entity modification. The new syntax allows plugin-users to: search and modify entities (Replace/insert/delete entity properties).

The plugin accepts two different types of main configuration files. The first type being a global configuration file (global_filters.cfg) which is run on every map change, and the second type being a map specific configuration file (<map name>.cfg ex: ze_journey_p.cfg) which is run ONLY when that specific map is played on the server.

As someone not managing a server, all configuration files that you make will be map specific configuration files, you will never find the need to conjure up a global configuration file.

Configuration file creation:

Addition and deletion of entities:

As mentioned before, this feature allows you at add and delete entities via the configuration file. The syntax for this feature is NOT flexible, so any configuration files created should follow the syntax in order to phase out the risk of the configuration file not working.

The first step to learning how to make use of this feature is to learn how to declare entities. You can declare an entity by using a block. The start and end of a block can be created with the '{' and '}' characters respectively. After the creation of the block, you can declare the properties of the entity being declared inside the block. 1 line in a block can host exactly 1 property of an entity. When declaring the property of an entity make use of the following syntax:

TWO QUOTED STRINGS PER LINE, SEPARATED BY A SPACE. FIRST STRING IS THE KEY, SECOND STRING IS THE VALUE.

You can find the specific properties for different entities by making use of the entity wiki page link that I will leave in the last section of the guide.

Entity declaration example:

{
	"origin" "50 921 0"
	"angles" "0 -100 0
	"damage" "155"
	"classname" "trigger_hurt"
}

Moving on, now that we know how to declare entities, we can make use of the different directives made available to us with this feature. There are two directives that this feature makes use of: "add:" directive, and "filter:" directive. The add directive allows us to use the entity addition feature, whereas the filter directive allows us to use the deletion via filter feature. The directives are placed at the top of a block in order to start using them.

Directive usage example:

add:
{
	"origin" "50 921 0"
	"angles" "0 -100 0
	"damage" "155"
	"classname" "trigger_hurt"
}

add:
{
	"origin" "100 300 -100"
	"angles" "0 0 0
	"damage" "1"
	"classname" "trigger_hurt"
}

filter:
{
	"classname" "trigger_hurt"
}

In the example above, we add two entities by making use of the add directive, and then delete all trigger_hurt entities in the map by using the filter directive. Another thing to note is that you can get quite specific with the targeting when trying to delete an entity, for example:

filter:
{
	"origin" "100 300 -100"
	"angles" "0 0 0
	"damage" "1"
	"classname" "trigger_hurt"
}

Modification of entities:

This powerful feature is your bread and butter. It is what you will want to use in order to modify the various properties of entities present in maps. The modification feature adds the following directive: "modify:" directive. Blocks which make use of the modify directive have access to the following sub-blocks: "match:" sub-block, "replace:" sub-block, "delete:" sub-block, "insert:" sub-block. Although they look like directives, they are specific to each instance of blocks under the modify directive, so we call them sub-blocks. Similar to what we did in the previous feature, you will want to keep 1 entity instance/type to 1 modify block. Lastly, it's IMPORTANT to note that without the modify directive, you will not be able to access the sub-blocks. The following example will aim to provide a look at how each sub-block functions in 1 example:

modify:
{
	match:
	{	
		"classname" "trigger_once"
		"targetname" "bosshp_add"
	}
	replace:
	{
		"classname" "trigger_multiple"
	}
	delete:
	{
		"filtername" "zombie"
	}
	insert:
	{
		"wait" "0"
	}
}

Here's what each sub-block will do when executed:

match: This sub-block will search for all entities which match all the specified properties inside the block. Using classname/targetname is generally standard convention, as seen in this example, however if an entity does not have a targetname or it isn't unique, you may see classname/hammerid or classname/origin instead. Classname is rarely required, however it helps to have it there to keep track of what entity class is being modified. In the end, the only thing that's required is that your keyvalue combinations only return the entities you want to modify.
replace: This sub-block will replace the keys of the entities which are returned from the match sub-block, with the keyvalues that you specify inside the replace sub-block. In the example, it will replace all matched entities classnames with "trigger_multiple".
delete: This sub-block will delete the specified properties from the matched entities. In the example, it will search for the exact property key and value "filtername" "zombie", and then delete it from an entity returned by the match sub-block if it's present.
insert: This sub-block will insert the specified value from the key value pair inside the sub-block. In the example, it inserts "wait" "0" which is a keyvalue for trigger_multiples that determines how fast it can be re-triggered.

Saving as CFG:

Now that you understand how the different aspects of the configuration files for the Stripper plugin work, you can create CFGs on your own! Open up a text editor of your choice, and create a new file. After filling it up with your desired contents, save the file as a CFG. It's important to set the file name to the name of the map that you are creating the CFG for. For example: ze_atix_panic_v1.cfg.

Decompiling:

Another extremely helpful process which will speed up the time you take to create configuration files for the stripper plugin is decompiling the map in order to take a look at the different entities and their key-value pairs that are available in the map for modification. Before we jump into this, first you should download the following program (http://www.riintouge.com/VIDE/). The reason that you should download it is because, VIDE (Valve Integrated Development Environment), offers an Entity Lump Editor feature. This specific feature will allow you to decompile the map and take a look at the entities and key-value pairs.

If you click on the file button, you will find the option to "Open" a file. Click on this and navigate to the map file of your choice (Navigate to your games map folder and choose a .BSP file). After doing this, it will list all the entities present in the map. Now that you have access to the different entities, you can easily go through the list / use the filter bar and find what you wish to modify.

Inputs and Outputs:

Before we start to mess around with I/Os, it's important that we first understand what they are. According to the VALVE developer wiki, I/Os are:

Quote

"the means by which entities communicate between each other in maps. Entities have two methods for communication: sending an output to another entity, or receiving an input from another entity. One entity may send an output when it is killed to another entity's input which causes it to change color. That same output could also be used to trigger another entity's spawning input. The outputs are matched to the inputs via a connection, which controls what extra data is relayed to the receiver, how much of a delay there is before the output is received, and whether the output should be allowed to be sent again later. Outputs can be linked to any input and vice versa. This allows complex and powerful interactions between entities."

Editing I/Os via the usage of the configuration file is basically the same as editing generic entity property values, but it will require more caution on your side. When editing the I/Os of an entity, make sure that you understand what the I/O is doing.

If you take a look at the picture above (PROGRAM: VIDE), you can see an example of what I/Os look like. If I were to edit an output, I would simply double click on the output that I want to edit, copy the selected value, and bring it over to the configuration file. Once in the configuration file I would then edit the values as I please.

modify:
{
	match:
	{
		"classname" "trigger_once"
		"targetname" "trigger_b_door"
	}
	delete:
	{
		"OnStartTouch" "consoleCommandsay *** DOOR OPENS IN 20 SECONDS ***01"
	}
	insert:
	{
	        "OnStartTouch" "consoleCommandsay *** DOOR OPENS IN 30 SECONDS ***01"
	}
}

In the code block above, I have tweaked the output to print out for 30 seconds, rather than 20. An interesting thing to take note of when editing I/Os is that you usually want to delete the I/O then insert it, rather than replace it. This is due to the fact that when dealing with I/O, the key (OnStartTouch in this case) is not unique like standard keys such as "origin" or "targetname" are.

Lastly, you will notice that there are weird characters present if working with CS:GO. The weird characters are used to separate outputs. When making use of VIDE to look at entities, you don't need to worry about reproducing that character as you can simply copy paste the exact syntax from the map via VIDE. You can also do the same when attempting to add an output. Other options for this are to make use of the ' , ' character. You can make use of the ' , ' character, when adding an output to a newly added entity in a configuration file, BUT you cannot use ' , ' when attempting to replace an output from an entity. When replacing an output, always copy the string straight from VIDE. For older Source engine games this is all irrelevant, commas are used exclusively in configs and in the actual games.

Adding entities which require brushwork:

A brush in the context of the Source Engine is defined as:

Quote

A Brush Entity is an entity type in the GoldSource and Source Engines, created by tying an entity to a BSP geometry brush in the map, giving the brush a specific affect or ability defined by the entity tied to it.

Sometimes you may find the need to add an entity which will require brush work of some sort. Examples of use cases for this are: adding buy zones, adding safe zones, adding trigger_hurt areas to maps. When this situation comes up you can simply make use of the "add:" directive and set the model number of the entity that you're adding as the model number of a suitable brush entity from inside the .vmf file.

An example of this can be seen below:

;Nuke safe zone fix.
add:
{
    "model" "*29"
    "classname" "trigger_hurt"
    "targetname" "Nuke"
    "StartDisabled" "1"
    "spawnflags" "3"
    "origin" "261.92 -253.52 -3422.77"
    "nodmgforce" "0"
    "damagetype" "0"
    "damagemodel" "0"
    "damagecap" "20"
    "damage" "9999999"
}

If you need higher precision, or are unable to find a suitable model number, there is another option that allows you to specify exact dimensions. This only works for triggers though, not entities like func_brush. Refer to the picture below for assistance in doing this.

Important links for reference :

Notes :

If you find any information in the guide that needs to be corrected, please don't hesitate to post here. Thanks for reading the guide!

NOTE: Guide copied from GFLClan.com, written by Vauff

Sign In

Stripper CFGs Guide

Recommended Posts

Calig

Link to comment

Create an account or sign in to comment

Create an account

Sign in

About Us

Links

Socials