BSPReveal - Compile tool for improved in-game visualization

[fubarFX]

BSPReveal
There are too many invisible things that go into making maps.​

BSPReveal is a map compile tool that adds in-game functionality to your map. Some features are upgrades for existing console commands, others are new commands driven by map logic. No client-side mod required, ~just BSP magic~.

Improved visualization allows for better debugging but note that BSPReveal is also relevant for your released maps. Players can now provide better feedback with more powerful screenshots and learn about various invisible elements to increase their mastery of your map.

BSPReveal can be integrated into CompilePal or into Hammer's expert compile window. Just follow the simple install instructions included.

Download Link

Feature Showcase

Using `r_drawclipbrushes 2`

Spoiler: How this works

In BSP, brush solidity is expressed with a list of booleans for each brush. Think of them as a series of checkboxes. They are:

0x1 CONTENTS_SOLID
0x2 CONTENTS_WINDOW
0x3 CONTENTS_AUX
0x4 CONTENTS_GRATE
0x5 CONTENTS_SLIME
0x6 CONTENTS_WATER
0x7 CONTENTS_BLOCKLOS
0x8 CONTENTS_OPAQUE
0x9 CONTENTS_TESTFOGVOLUME
0xa CONTENTS_UNUSED
0xb CONTENTS_UNUSED6
0xc CONTENTS_TEAM1
0xd CONTENTS_TEAM2
0xe CONTENTS_IGNORE_NODRAW_OPAQUE
0xf CONTENTS_MOVEABLE
0x10 CONTENTS_AREAPORTAL
0x11 CONTENTS_PLAYERCLIP
0x12 CONTENTS_MONSTERCLIP
0x13 CONTENTS_CURRENT_0
0x14 CONTENTS_CURRENT_90
0x15 CONTENTS_CURRENT_180
0x16 CONTENTS_CURRENT_270
0x17 CONTENTS_CURRENT_UP
0x18 CONTENTS_CURRENT_DOWN
0x19 CONTENTS_ORIGIN
0x1a CONTENTS_MONSTER

r_drawclipbrushes will only render brushes that feature CONTENTS_PLAYERCLIP or CONTENTS_MONSTERCLIP. Playerclip renders fuchsia, Monsterclip (tools/npcclip) renders purple. tools/clip has both monsterclip and playerclip solidity, which renders red.

For the most part, TF2 makes no distinctions between clip and playerclip so we can merge those by removing monsterclip from clip. No side effects. All clips are now fuchsia.

Blockbullet is CONTENTS_SOLID. No material will ever get vbsp.exe to create a brush that is both CONTENTS_SOLID and CONTENTS_MONSTERCLIP (contents_monsterclip is redundant with contents_solid anyway). But we're clever so we can patch it in and the game client doesn't mind at all. Adding CONTENTS_MONSTERCLIP to blockbullet brushes doesn't affect its physics properties and we've successfully tricked r_drawclipbrushes into rendering blockbullet as tools/npcclip.

For the special grate materials that allow splash damage through, it's more or less the same process. They start out as CONTENTS_GRATE. But we can add CONTENTS_MONSTERCLIP and CONTENTS_PLAYERCLIP without changing its physics properties. Which, you guessed it, tricked r_drawclipbrushes into rendering grate materials as tools/clip.

This does not affect the size of your map, we're just having fun flipping preexisting ones and zeros.

Using `ent_fire vis_disp toggle`

Spoiler: How this works

If bsp says that one of its dynamic lights is affecting a surface across the map that it couldn't possibly hit, the game client fully trusts that to be the case. We're able to highlight certain faces by inserting a dynamic light into the map which is tied to alternative lightmaps. Toggling the light activates the colored lightmaps.

This modifies your map somewhat. Two entities are added to your map to make this work. And alternative lightmaps are generated for displacements that feature a modified solidity.

Using `map_showspawnpoints`

Spoiler: How this works

This one is simplistic, we simply offset spawnpoint entities on the Z axis in the order that they appear in the list of entities. This doesn't affect how the spawns function as players are snapped to the ground upon spawning. The offset is calculated according to the spawn's "group" which is a unique set of these properties: teamnum, controlpoint, round_redspawn, round_bluespawn.

This may affect the size of your map depending on the string representation of the Z value (but only by a few bytes tops).
Note: you should make sure your spawnpoints don't get embedded into your ceiling. Take a minute to verify your console for obstructed spawnpoints.

Using showtriggers_toggle

Spoiler: How this works

This one is also somewhat straightforward, the faces are being edited to have their textures reassigned according to the entity they are tied to. This injects a few textures in you pak file without needing you to manage assets (these textures can add up to 20kb but those you need will be injected).
The supported trigger entities are: trigger_hurt, trigger_multiple, trigger_capture_area, func_nobuild, func_nogrenades, func_regenerate, func_respawnroom

Note: If you are already using your own fancy materials for your trigger brushes, they will be unaffected.

 

[Yrr]

This is cool! I'd consider doing this to Bagel for comp people but Bagel has some more esoteric forms of clipping in some places it wouldn't catch

 

[fubarFX]

This is cool! I'd consider doing this to Bagel for comp people but Bagel has some more esoteric forms of clipping in some places it wouldn't catch

Currently, product and process_f9 have adopted it, so yeah eventually it might become a comp standard. And yeah, stuff like invisible displacements might not have a solution, but I'm thinking about it.

 

[theatreTECHIE]

Found strange behaviour when trying to use this for rapids_a9 - Red has 4 groups of 16 spawn points, with all 16 spawn points within a group having the same name. (Only the first starts enabled, then as points are capped, each group is enabled/disabled)

The first three groups worked as expected, but the final group was never enabled, couldn't be enabled using ent_fire in game, yet still came up with ent_dump. Compiling without bspreveal resulted in the expected behaviour of the final group being enabled when expected.

EDIT: Just realised that this might be caused by the spawn points being raised so much that they end up in the ceiling. Is there a way to make bspreveal separate groups of spawnpoints manually? Or alternatively, is there a way to adjust the offset amount that bspreveal adds to each spawnpoint?

 

[fubarFX]

Found strange behaviour when trying to use this for rapids_a9 - Red has 4 groups of 16 spawn points, with all 16 spawn points within a group having the same name. (Only the first starts enabled, then as points are capped, each group is enabled/disabled)

The first three groups worked as expected, but the final group was never enabled, couldn't be enabled using ent_fire in game, yet still came up with ent_dump. Compiling without bspreveal resulted in the expected behaviour of the final group being enabled when expected.

EDIT: Just realised that this might be caused by the spawn points being raised so much that they end up in the ceiling. Is there a way to make bspreveal separate groups of spawnpoints manually? Or alternatively, is there a way to adjust the offset amount that bspreveal adds to each spawnpoint?

Would grouping by targetname work for your use case? I don't think I'd bother with grouping by I/O but targetname is realistic.
I might make a configurable offset otherwise.

 

[theatreTECHIE]

Would grouping by targetname work for your use case? I don't think I'd bother with grouping by I/O but targetname is realistic.
I might make a configurable offset otherwise.

An option for grouping by targetname would work for sure.

 

[fubarFX]

An option for grouping by targetname would work for sure.

Version 1.2.0 is out, it will take targetname into account when determining how to group spawnpoints. This is now part of the default behavior, doesn't even need to be an option.

https://github.com/The-Orange-Toolbox/BSPReveal/releases/tag/v1.2.0