Static Prop Combine in Counter-Strike: Global Offensive
A step by step guide thanks to @untor
What is Static Prop Combine?
Static prop combine, or informally speaking "autocombine", is a new feature in CS:GO's VBSP.
It allows VBSP to merge together multiple static props into a single static prop, either automatically or with user-defined rules.
What is static prop combine good for? Static prop combine is another feature to optimize your maps. Most people might think that "the less geometry rendered the better". So if you use small props, it's easier to hide what is not visible.
That's not wrong. But there is a problem:
In Source, there is one draw call per model per material. And these draw calls are very performance-hungry.
That's where static prop combine comes into play:
By combining models sharing the same materials, less draw calls are performed, which greatly helps optimization.
Valve has stated that Nuke runs 40% faster after they implemented static prop combine.
How do I use static prop combine? The static prop combine feature was added in 2016 with the release of the reworked de_nuke. But since then it was not (?) used by community mappers, there are no (?) guides on the Internet except this documentation. @untor helped me to make static prop combine feature do its job. So we decided that it's time to publish a step by step guide how to use static prop combine.
We presuppose that you are already familiar with the creation of props
0. Backup your CS:GO folder (optional) We do not take responsibility for any damage done to your files. So it's time to backup your game files now if you have not already. In general we recommend to duplicate your "Counter-Strike Global Offensive" folder, so you can use a separate installation of CS:GO for mapping while keeping the other one clean for playing.
1. Source files You must have the source files of the models you want to be combined. Usually 3 files for each prop:
reference mesh (supported formats are *.smd, *.dmx and *.fbx)
So if you want to combine props made by you, you should already have these files.
If you want to combine props made by Valve, you will need to decompile them first. And then change the names - otherwise, the version of the prop that is packed in the VPK would overwrite your version.
In this guide we will use two different pipe props:
You can download the example files here (contains the *.qc and *.smd files) :
Browse to "...\Steam\steamapps\common\content\csgo\"
Create a folder "models". In our example we have another subfolder "example". Save the model source files there:
These are our QCs:
Restrictions for the *.qc:
Only the first $body is recognized.
$model is not recognized.
$appendsource and $addconvexsrc are not recognized.
You can only use $upaxis Z or Y.
2. Compile your props Your models have to be compiled from this directory now:
Open your model compile tool (I use Crowbar) Then browse to "...\Steam\steamapps\common\content\csgo\models\example\" and compile the QCs.
The compiled model files should be in "...\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\models\props\example\" now.
3. spcombinerules.txt Browse to "...\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\scripts\hammer\spcombinerules\"
There you will find "spcombinerules.txt". In this file the combine rules for Valves props are defined. It is a standard KeyValues-formatted text file. Each entry follows the format below.
Rename it to "spcombinerules_valve.txt" (or whatever you want) and create a new text file "spcombinerules.txt".
Then copy and paste the following into "spcombinerules.txt" and save it.
4. Stub QCs Stub QCs are QCs which contain a base template for the QCs which static prop combine generates. Generally, they should only include:
Any $texturegroups used by the models.
Browse to "...\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\scripts\hammer\spcombinerules\qc_templates\".
In our example we create a new subfolder "example", open it and then create a text file and rename it to "pipe_combine.qc":
Copy and paste the following into "pipe_combine.qc" and save it:
5. Compile your map Add some of our example props to your map in Hammer and compile the map.
In our example we use the following compile parameters for VBSP
Compile parameters (full list here) :
-StaticPropCombine: Merges static props together according to the rules defined in scripts/hammer/spcombinerules/spcombinerules.txt. This lowers the number of draw calls, increasing performance. It can also be used to lower the number of static props present in a map.
-StaticPropCombine_AutoCombine: Automatically generate static prop combine rules for props that VBSP deems should be combined. Note: This does not write to spcombinerules.txt.
-StaticPropCombine_ConsiderVis: Instead of using the distance limit, combine all props in the group that share visclusters.
-StaticPropCombine_SuggestRules: Lists models sharing the same material that should be added to spcombinerules.txt.
-StaticPropCombine_MinInstances <int>: Set the minimum number of props in a combine group required to create a combined prop. Tip:Valve had this set to 3 for the new Dust 2.
-StaticPropCombine_PrintCombineRules: Confirm: Prints the combine rules?
-StaticPropCombine_ColorInstances: Instances of combined props get colored.
-KeepSources: Don't delete the autogenerated QCs and unpacked model files after finishing.
-CombineIgnore_FastReflection: Combine props, even if they have differing Render in Fast Reflections settings.
-CombineIgnore_Normals: Combine props, even if they have differing Ignore Normals settings.
-CombineIgnore_NoShadow: Combine props, even if they have differing Disable Shadows settings.
-CombineIgnore_NoVertexLighting: Combine props, even if they have differing Disable Vertex lighting settings.
-CombineIgnore_NoFlashlight: Combine props, even if they have differing Disable flashlight settings.
-CombineIgnore_NoSelfShadowing: Combine props, even if they have differing Disable Self-Shadowing settings.
-CombineIgnore_DisableShadowDepth: Combine props, even if they have differing Disable ShadowDepth settings.
6. Success? The combined props look exactly like the single props. So how can you be sure that the static prop combine process was successful?
- Once the map is compiled, the combined props will be packed into your *.bsp automatically.
- If you add -keepsources to the compile parameters, you can also find the combined props in "...\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\models\props\autocombine\*name of your map*\"
and their QCs in "...\Steam\steamapps\common\content\csgo\models\props\autocombine\*name of your map*\".
- If you add -StaticPropCombine_ColorInstances to the compile parameters, instances of combined props are colored in CS:GO.
7. Additional notes
- You can manually disable static prop combine for individual props with the "Disable Prop Combine" keyvalue.
- Prop scaling (Uniform Scale Override) is not supported yet (?)
- If the original props don't have a collision model, you will have to set collisions to "Not Solid" in the properties. Otherwise the combined prop will be solid (automatically generated collision mesh; causes problems).
- If the props differ in specific keyvalues, in most cases the default (e.g. Alpha) or the higher value will be used (e.g. fade distances)
- Props that differ in the below keyvalues will NOT be combined, unless manually overridden with the appropriate VBSP option:
Render in Fast Reflections (-combineignore_fastreflection)
Ignore Normals (-combineignore_normals)
Disable Shadows (-combineignore_noshadows)
Disable Vertex lighting (-combineignore_novertexlighting)
Disable Flashlight (-combineignore_noflashlight)
Disable Self-Shadowing (-combineignore_noselfshadowing)
Disable ShadowDepth (-combineignore_disableshadowdepth)
- Props that differ in the below keyvalues will NOT be combined:
some fps tests with an actual map!
which gives better results: " -StaticPropCombine_ConsiderVis" or prop combining based on distances?
Is there a console command to display the number of performed draw calls/props?
______________________________________________________________________ Sources: https://developer.valvesoftware.com/wiki/Static_Prop_Combine https://developer.valvesoftware.com/wiki/QC https://developer.valvesoftware.com/wiki/VBSP
This level design article is about the past and the present of the hostage rescue mode in Counter-Strike. Showcasing the inherent issues that accompanied the scenario allowing the bomb/defuse mode to gain traction and popularity. This article will also present what can be done, level design wise, to remedy some of the shortfalls and allow the scenario to be viable.
A historical background
Counter-Strike officially started life in June 1999 with the release of beta 1, and it shipped with four maps, that’s right, four whole maps. They were all hostage rescue maps and the prefix used for these maps was cs_ as opposed to the standard deathmatch maps starting with dm_. This prefix was an abbreviation of the game’s name (Counter-Strike) which hints to this hostage-rescue scenario being the only one in the minds of Gooseman and Cliffe, the creators of CS, at the time of launch.
Fast forward a couple of months, beta 4 rolled out in November 1999 bringing to the table a new scenario, bomb defuse. The new maps carried the prefix de_ and while one would think that the hostage rescue maps would be switched to hr_ prefix, they kept the same prefix which started to be referred to as the “Classic Scenario”. Counter-Strike was built on hostage rescue scenario.
I started playing CS in beta 2 in August 1999 (I totally missed beta 1, screw me) and maps like Assault and Siege were all the rage at LAN parties. The nearest LAN/internet café was a 5-minute drive from my place, and LAN parties with friends used to be a blast full of shouting, cursing, bluffing, noob-trashing; the standard menu for a CS session. Good times.
Siege, the oldest CS map (beta 1), and Assault (beta 1.1) were the epitome of the game. You had to dive in as a CT deep into the T stronghold to rescue the hostages and bring them back to safety. These maps were the most played on LANs and embodied the style of early CS gameplay. At the LAN place where I used to wage my virtual battles, Assault equaled CS, literally. A fun fact is that when Dust came out, I started a LAN session with this map and everyone in the room shouted at me: "What the hell is this? We wanna play CS!" For my friends, Assault was CS.
However, those rosy days for hostage rescue began to turn into grim grey when folks started playing bomb defuse scenario and realized how…fun it was. A map like Dust almost single-handedly pushed the scenario into higher ground with its bright environment/textures, clear/wide paths and its ease of use and noob-friendliness. A year later, around Summer 2000, Counter-Strike was now equivalent to Dust for my friends.
How did this happen? What went wrong?
Inherent flaws of hostage rescue
Hostage rescue is a very delicate and tough scenario for law enforcement operators in the real world. It puts the assailing team at a great disadvantage against heavily-armed barricaded hostage-takers who are probably using civilian hostages as human shields and as a bargaining chip for a later escape.
As you can deduce, transferring this scenario as realistically as possible into the game will not fare well, and this disadvantage will carry on for the CT team. The problem is only exacerbated when you add the more or less “flawed” game mechanics to the scenario. This is exactly what went wrong with hostage rescue scenario in case you are still wondering about the rhetoric questions at the end of the historical background introduction. The popularity of cs_ scenario started dwindling and the rise of the bomb/defuse scenario only made things worse.
Almost all the early cs_ maps featured a relatively tiny hostage zone/room having one entryway usually sealed with closed doors that the CT must open to get access inside. This room was typically located behind T spawn which made the area a camping ground and made camping that zone an obvious and rewarding tactic for Ts. The doors having to be manually opened with a loudening sound made things worse and negated any surprise or sneaky rush towards the hostages. A classic example is the hostage area and T spawn in cs_assault.
I dare not think of how many Ts are camping behind those doors
Another equally important camp fest occurred in the hostage rescue zone. Early designs made the rescue zone relatively small with one or two access paths that can be defended from one location. If the CT team manages to reach the hostages and rescue them, the Ts could easily fall back to the rescue zone to camp and patiently wait for the CTs to show up. The hostage rescue zone in cs_italy is a nice example to showcase how one T could camp in the southernmost spot in the zone allowing him to monitor both entryways, from market and from wine cellar, within the same field of view. CT slaughter was almost a guaranteed thing to happen.
A CT will show up any second now; imminent slaughter commencing in ...3, 2, 1
A third flaw was the hostages themselves. They were difficult to escort and protect and were easily stuck or left behind in various parts of the maps between their initial hostage zone and the final rescue zone. I lost count of how many times I rescued the hostages and ran as fast as I could to the rescue zone, reaching it with a big grin on my face only to turn around and find out that only one or two of the four hostages actually followed me; the others were randomly stuck on a ladder, door frame, window ledge, vent, chair, table…I could go on but my blood is starting to boil just thinking of this.
To add insult to injury, hostages could also be killed or “stolen” for ultimate trolling. When Ts were stacked on money, they could easily kill all the hostages, basically turning the round to a frustrating terrorist hunt for CTs. In early CS versions, a CT teammate could press the “use” key on a hostage that you were already escorting to steal it. This would leave you helplessly wondering where the hell did the 4th hostage go in case you did not catch the teammate performing the action.
Lastly, maps themselves contributed to the issues that were piling up against hostage rescue scenario. If you are a CS veteran and you were around the early betas in 1999, you would most certainly remember how quickly hostage rescue maps were pruned from one beta to another; some maps even had a life span of 1 week before being discarded out of the official roster. Most of these early cs maps featured dark, nightly environments that were unfriendly to both newcomers and established players. Other maps had a confusing-as-hell labyrinthine layout that confused even the most great-sense-of-direction players, and made remembering paths nigh impossible. Some of these maps had narrow twisted paths and choke points, vents, and ladders that not only frustrated players (especially CTs) but also made rescuing and escorting the hostages more of wishful thinking. The icing on the cake was the different gimmicks introduced in some maps that made a frustrating gameplay/layout even more annoying: some maps had a machine gun nest in T spawn allowing Ts to master and perfect the art of CT slaughtering while other maps had flammable drums that could be shot and blasted for the ultimate carnage right next to the hostage zone. Good example maps include cs_prison, cs_bunker, cs_iraq, cs_hideout, cs_facility, cs_desert, among many others.
Meanwhile, bomb/defuse scenario was gaining grounds at an increased rate and before too long, hostage rescue was relegated to a distant second place in terms of popularity among players and level designers alike.
As a small experiment, I tallied the number of custom hostage and defuse maps submitted on Gamebanana for Counter-Strike Source and Global Offensive. For CS:GO, there are 761 de_ maps against 157 hostage maps while for CS:S, the figures are 4060 de_ for 1244 cs_ maps. The disparity is rather meaningful as the ratio in CS:GO is 4.85:1 while for CS:S the number is 3.26:1. This means that for each hostage map in CS:GO there are almost five maps of bomb/defuse whereas this number drops slightly to almost three maps for CS:S. With CS:GO putting extra focus on competitive gameplay, this ratio is bound to further grow widening the rift between bomb/defuse and hostage rescue maps.
That’s it? Is it done for cs_ maps? Shall we prepare the obituary or is there a magical solution to breathe some fire and life in them?
Solutions for viability
There is a magical solution that involves you transferring a large sum of cash to my bank account, then my “guys” will contact your “guys” to deliver the “solution”. The drop point will be at the…apparently, there has been a mix-up, this is for another “deal” …nervous chuckle.
Seriously though, while there is no magical solution that will lift hostage rescue onto the rainbow, there are a couple of things that level designers can do to start injecting some momentum to the scenario. Luckily for us, Valve has already paved the way (so these “Volvo pls fix pls” do work after all?). In March 2013, Valve introduced a major CS:GO update that completely overhauled the hostage rescue scenario mechanics and introduced cs_militia as well. The update was a game changer and a much needed tweak towards a better hostage rescue gamemode.
We now have two hostages instead of four, and the CTs only need to rescue one of them to win the round. Moreover, the hostage does not stupidly follow the CT but instead is carried on the CT’s shoulders. Obviously the movement speed of the CT carrying the hostage is decreased but this “inconvenience” is countered with added bonus round time and the fact that the CT doesn’t have to glance over his shoulders every five seconds to make sure the hostages are still following him (this kind of distraction can prove fatal to the CT escorting the hostages). The hostages’ spawn location is randomized and can be controlled by the level designer. A nice change is that hostages don’t die anymore thus cutting any chance of Ts trolling (you still lose money when you shoot a hostage – shooting a hostage is pretty pointless now akin to shooting yourself in the foot).
This is all good news if you ask me; hostage rescue is on the right path to become popular and viable again. With Valve doing the first half of the change, level designers have the duty to continue with the second half.
As a first suggested solution, let us start treating hostage rescue as bomb defuse. Let’s be honest, bomb defuse works really well, so why not transfer this “experience” into hostage rescue. What we can do is to have a hostage rescue map’s layout mimic one of bomb defuse – that is have two hostage zones that are similarly placed as two bomb sites. We need to start treating a hostage zone like a bomb site with all accompanying techniques of rushing, pushing, faking, peeking, holding, smoking, flashing, etc. The good thing about this is that whatever knowledge, skill, and layout awareness that players have acquired from defuse scenarios will transfer effortlessly to the hostage rescue scenario; you do not need to learn new tactics and strategies. The roles will be inversed: instead of Ts rushing bomb sites and CTs defending, CTs will push hostage zones and Ts will defend and rotate.
Sounds logical, right? Some people might argue that having 2 separate hostage zones is not “realistic” and my answer is Counter-Strike was never about realism (carrying and running around with a 7 kg (15.5 lb), 1.2 m (47.2 inch) AWP sniper rifle with 25x telescopic sight, quickscoping and headshotting opponents is the epitome of “realism”). If you want a realistic hostage rescue scenario, then you are better off playing the original Rainbow Six Rogue Spear and SWAT 3 from 1999, or the more recent ARMA and Insurgency for a realistic military setting. I practice what I preach and I already implemented this technique in my last map “cs_calm”. The map was a remake of my CS 1.5 map from 2003 and obviously I made the “mistake” at that time to follow the trend set by official maps of having one hostage zone right behind T spawn. A playtest on Reddit CS:GO servers back in March 2015 confirmed that this setup won’t work well as Ts will inevitably abuse the hostage zone.
I made some radical layout changes towards T spawn and hostage zone and created two new hostage zones on the upper and lower levels of the map that are connected by a back hallway to allow quick rotations (in addition to the one through T spawn). Obviously, there is no direct line of sight between hostage zones to prevent 1-zone camping. Ts have absolutely no incentive to camp one zone as CTs can reach the other one, rescue the hostage and head back to the rescue zone without being spotted from the other zone. CTs actually have a chance of winning the round by rescuing the hostages. I like to believe the new layout worked well. Only time and more hostage rescue maps will tell.
Layout of the map "cs_calm"
Rescue zone anti-camping
We have remedied the hostage zone camping but we still need to tend to the rescue zone camping issue. A solution to this is to have two rescue zones in a similar setup to what is nicely done in cs_office. While Ts can still camp one zone, they risk a big chance of having CTs reach the other rescue zone. Again, CTs will have a viable option to save the hostages without being shredded by camping Ts. If the layout does not allow or facilitate having two rescue zones, then one big rescue zone with multiple entrances (three is a good number) should work fine. The trick here is to have the entrances not easily covered within the same field of view to prevent camping.
Into the zone
Just as we established that we should treat hostage zones like bomb sites, it goes without saying that each hostage zone should have at least 2 to 3 entry points. It’s pretty pointless to have only one entrance as this totally defeats the purpose of spreading hostages into two zones. The different entryways should also not be covered within the same field of view of one T; if a T decides to camp the zone, then he should be able to cover two entrances from one point leaving the third one more or less at a dead angle and viable for a CT rush or stealth/sneak surprise.
Showcase of Hostage Zone A on the map "cs_calm"
The above screenshot showcases “Hostage Zone A” in cs_calm. A terrorist will typically camp near the hostage covering the two encircled entrances. The third entrance from upper level denoted by the arrow is not in the direct FOV, and is prone to a surprise attack by CTs that could catch the camping T off guard. If possible, try to spread the entrances on different vertical levels to spice things up and keep Ts on their toes. Lastly, it is a good idea to have a connector between hostage zones to allow fast rotations but without having a direct line of sight between hostage zones. We want to make the scenario fairer to CTs but not at the expense of Ts, inadvertently making it unfair for them.
Hostage rescue is a fun scenario if you ask me. It had many inherited and added flaws that contributed to its waning but it’s nothing that can’t be reversed. We, as level designers, need to push some changes to put the scenario back on track. What I just showcased in this article might not be the only viable solutions but they certainly are a step in the right direction. Level designers are intimidated by players who shun away from cs_ maps, and this turns into a vicious circle where players avoid hostage rescue maps and mappers in return avoid designing them. We need to break this cycle and designers need to bravely embrace the solutions I presented here or come up with their own solutions. The more cs_ maps that come out and get tested, the more we could validate these solutions as viable.
In either case, we need to get proactive towards hostage rescue scenario; after all, this is the cornerstone that Counter-Strike was built upon.