Sorting winners from losers

by | February 27th, 2012 | Tutorials | 3 Comments »

In my TF2 king of the hill map koth_skylab, I wanted an ending sequence that would use a trigger to set the losing team on fire.

The usual way of distinguishing between teams in a trigger is to use a filter_activator_tfteam. It has a Team property which can be set to the red team or blue team. Spawn room doors are a typical use of this filter, to allow only Red players into the Red spawn room, and only Blue players into the Blu spawn room.

Opening a spawn room door

An alternative property, Associated Control Point, allows the filter to allow only playersfrom whichver team owns a particular control point. A trigger using this filter, connected to a door, would only open the door for Red players if Red had captured the control point, and similarly for Blue if Blue owned the point. If the control point was neutral, the door would open for nobody.

Opening a door for the control point holders

Finding the winners

In a king of the hill map, there is a single control point. Each team must try to hold the point for as long as possible. A team wins when they have held the control point cumulatively for a certain time; e.g. three minutes. Consequently, you can identify the winning team as the team that owns the control point when the round finishes. The winning team then gets ten seconds or so—the “humiliation period”—in which to slaughter the losers.

When the Red team wins a round, the tf_gamerules entity sends the OnWonByTeam1 output; when Blue wins, it sends the OnWonByTeam2 output. If you have a trigger, filtered by the control point, that is initially disabled, and then enable it when either team wins, only the winning players will activate the trigger.

I don’t really want to set the winners on fire—it would be a strange reward for winning—but I’ll add the logic here so you can see how it works. When the trigger gets an OnStartTouch input, it sends the IgnitePlayer output to !activator, which is the special identifier for “the entity that sent the input”, which in this case will be any player matching the filter. Hammer may not recognise these options, and will display them in red, but they will work just fine in the game.

Setting the winning team on fire

Finding the losers?

Finding the losers should be easy. The third property on filter_activator_tfteam is Filter Mode. Set this to Disallow, and instead of allowing the matching team to activate the trigger, the filter will disallow them, and allow every other player to activate it. The team-filtered door in the second example above would open for both teams when nobody owned the point, for the Red team when Blue owned the point, and for the Blue team when Red owned the point. For pyromaniacs, the trigger shown below will set the entire losing team in the trigger area on fire.

Setting the losing team on fire - with a bug

However, there is a catch. If you enable this trigger during the round, it will work exactly as expected: the team that owns the point will be unaffected, and the team that doesn’t own it will burn. But if the trigger is enabled in the humiliation period after the round ends, both teams catch fire.

It turns out that for the duration of the humiliation period, all team-based filters will always match the winning team. This is so that the winning Blu team can open the spawn room doors of the losing Red team (or vice-versa), to slaughter any cowardly players trying to hide in it—a worthy cause, indeed.

But it causes me a little problem: although I can identify the winners, those-who-own-the-control-point, the inverted logic those-who-don’t-own-the-control-point that should identify the losers also matches the winners. It’s incredibly funny when both teams catch fire, but it’s not quite what I want.

All is not lost

I can still identify the losers, and only the losers, but those-who-don’t-own-the-control-point isn’t good enough because of the peculiar behaviour of filter_activator_tfteam after the round. What I need is to take the effect of the winning team filter (which still only matches the winners after the round ends) and invert its logic in some other way.

There’s another filter entity in Source, filter_multi, which allows you to create complex filters by performing logical operations on several other filters that you specify. If you set its Logic Type property to AND, it will pass only if all the other filters pass; set it to OR, and it will pass if any one of the other filters pass. I don’t need that capability here, but filter_multi also has a Negate Outcome property, which turns what would be a pass into a fail, and vice-versa.

What this means is that the output of the filter_multi is not affected by team logic or humiliation periods at all, but only by the outputs of the other filters it specifies. So although the Filter Mode property of the filter_activator_tfteam turned out to be unsuitable, if I use a winning team filter and send its output through a negated filter_multi, it will match only the losing team.

Setting only the losing team on fire

Final notes

There’s one small issue remaining with our trigger and filter set up: the filter_activator_tfteam matches all players on the winning team, and so the filter_multi, being negated, matches everything else. Not just players, but all other entities. The fix for this is easy: just ensure the trigger flags are set to just Clients.

Increasing bounce lighting with $reflectivity

by | February 14th, 2011 | Articles | 33 Comments »

So you’re putting in lights and you find the perfect settings to light the room, but there’s a problem: the ceiling is almost pitch black! A surprisingly common problem, so what do you do? increase the light’s brightness and suffer a blinding floor? Nope.

Default reflectivity values, the ceiling is way too dark but the ground is a nice brightness.

All too common, the light level in the room is enough to illuminate the floor and lower walls but the ceiling is far too dark, all the effort you put into detailing it is going to waste!

Just edit the $reflectivity value in the .vmt for your floor material.

Read more…

Sun Spread Angles

by | January 11th, 2011 | Articles | 9 Comments »

Just a quick one today to clear up something that possibly isn’t experimented with much when considering lighting, the spread angle from the light_environment. The entity itself recommends a value of 5 degrees to start with however, as my attention was drawn recently to, this is actually quite a large angle. You’ll see on a sunny day, the shadow from a tall building is incredibly crisp. The angular size of the sun, a non-point light source, is about 32 arcminutes in the sky, which is just over half a degree. So picking a sun spread angle smaller than 5 degrees is a good idea if there is little to no cloud cover in your skybox.

The images after the jump are examples of sun spread angles 0, 1, 3, 5, 10 and 20 degrees.

Read more…

In Defense of Turbine

by | December 27th, 2010 | Articles | 3 Comments »


To the Team Fortress 2 mapping community, Turbine has become an icon of hatred. Everything mappers don’t like about Valve’s selection of maps, summarized in one single BSP file. It’s “too simple”. It isn’t “well-detailed”. The complaints against it are numerous. This is unfortunate, because Turbine is a map that should be carefully looked at and analyzed. It’s obviously a successful map, Valve picked it up because of its popularity. And what makes it a popular map? That is what I’d like to dive into.

Read more…

Lighting Compile Options

by | December 2nd, 2010 | Tutorials | 11 Comments »

Today I’m going to discuss the lighting conventions of source. Source has been evolving steadily since Half Life 2, with the introduction of HDR with Episode 1 and then per-vertex lighting for static props and shadowing textures with the Orange Box. These new methods for calculating lighting at compile time have become the standard for source, everything produced since the Orange Box uses them.

Unfortunately the improved lighting introduced with the Orange Box was not added to hammer’s default compile settings, even as options, so we must add them ourselves. That means we need to know what they are and what they do. There are three options that we’re going to look at today, texture shadows, per vertex lighting for static props, and exact outline shadow casting for static props. So what exactly do they do?

Read more…

A look at the detail of TF2 Part 5: Viaduct

by | September 29th, 2010 | Articles | 3 Comments »

It came up when people were asking and it’s a map I admire myself so koth_viaduct is the subject of my final part of this series.  The best way to end a re-run is with something entirely new too, so with that in mind let’s press on and see what Viaduct has to offer.

Straight after spawning I take a look around and instantly see two awesome things:

Read more…

A look at the detail of TF2 Part 4: 2Fort

by | September 18th, 2010 | Articles | 8 Comments »

Last of the re-writes here, the most infamous Team Fortress map, 2Fort.

Touching on a previous topic here, clustering details around doors.

Read more…

A look at the detail of TF2 Part 3: Dustbowl

by | September 14th, 2010 | Articles | 5 Comments »

One of the first six maps for Team Fortress 2, Dustbowl remains favourite for many, I’ve seen it criticized as under detailed and bland but I feel that it’s right at the pinnacle of TF2. One of my favourites for both gameplay and aesthetic value, definitely.

Let’s pick it apart and see what we can learn!

Read more…

A look at the detail of TF2 Part 2: Goldrush

by | August 25th, 2010 | Articles | 7 Comments »

Here is the second part in the series. I was looking to Goldrush a lot whilst making Hoodoo, it was the first official map I spent any length of time actually studying so a lot of the techniques I use are similar. You’re gunna get a pretty picture before the read more tag this time, aren’t you lucky? Well, not really.

What’s the focus of this picture?

Read more…

A look at the detail of TF2 Part 1: Badlands

by | August 22nd, 2010 | Articles | 5 Comments »

I’m going to be moving all of my articles from over to Nodraw in the next few weeks. I’ll keep most of the original information but I’ll be updating a lot of it. Starting off with Badlands, I’ll take a look at how Valve have used various techniques to detail their maps.

Once more into the breach, dear friends

Read more…