Would you let people edit your maps? Risk having them stolen, or have theirs wind up
more popular than yours ever were? Or worse: expelled?
I know that some people like to protect their maps to stop others from accessing them. But
I’ve never liked this approach. I believe that being able to edit existing maps is kind
of important. I spent many happy hours back in CS:S, looking around existing maps to learn
how they were made. Making custom versions of these has been helpful for many of my own
videos, not to mention a great way of testing out cool ideas that you probably got while
playing on the originals. As for my own maps, I’m happy for people
to edit them. I like the idea that people would WANT to look at my stuff and to follow
in my digital footsteps. And if their version happens to more successful, yes, maybe I’d
feel like I deserved it more, but then maybe it would never have become popular without
what they did for it. For example, my Smash map never went anywhere until Paul built upon
it, started the popular SMASH gamemode. And I’m not alone- FMPone, maker of Cache, Season
and Subzero, also openly shares his editable map files.
As for Valve’s maps, while some are available in the Hammer Editor, many are not. Maybe
Valve doesn’t want us looking at them! In which case, I’m… sorry. But it could just
be that they don’t bother to include them. I mean, they’ve never cracked down on any
of the attempts people have made to edit them- though the process is admittedly getting harder
all the time, as new features and techniques slowly break the old methods of extracting
data. But I’m still doing it! I did it for each
and every map a couple of years ago, getting them all to a stage where they’re easy to
open up and modify. Makes more sense for one person to do it and to share it, than for
everybody to have to do it every time they need to. And I’ve just added the new Dust2
and Canals to the collection. The others are now a bit out of date, but they’re there.
Every time I do this to a map, I discover a bit more about how Valve makes them and
how their approach has changed over time. Let me talk about what I discovered with these
2 maps and the very different ways in which they were made.
To convert a map, first you get the map file and use a program like BSPSource to convert
it into a VMF file, which you can open using the Hammer Editor. This is a pretty quick
process. But if you open it up at this stage, it looks
like THIS! This is because newer Valve maps contain models that are embedded within the
map themselves. You can also get these by using BSPSource,
placing the materials and models folders into CSGO’s main directory.
Now we can see the map in Hammer. If we disable areaportals and occluders, we can then render
the map and play it right now. DONE! This is probably good enough for most purposes.
But I’m not happy with it, because there are problems.
First of all, it doesn’t understand how to group func_details together, so instead
clumps anything touching into one, often with HILARIOUS results! Func_details are hand-placed
blocks that you stick together to make details for your level. But you only want these rendered
if your character can see them from where they’re stood in-game. The general rule
is to clump all of the same ‘item’ together… unless that item is super big and complicated
and you can clump one half together that can be seen from places that the other part can’t.
It’s complicated! So I unclump them all and manually go through and group them into
more manageable chunks, normally whilst listening to music of some kind. There were almost 3000
of these in Canals and it took FOREVER. Oh, hello, secret symbol!
And this was where I discovered the first difference between the two maps: Dust2 has
hardly any! Func_details that is, not secret symbols. Though it doesn’t have any of them
either. What’s going on?! I noticed that the newer Valve’s maps, the
fewer func_details there were. It seems that Valve are slowly moving away from these and
towards proper models, which require more work to make but can be more detailed and
optimised and so on. I saw the shift away from func_details when comparing old and new
versions of Nuke and Inferno, but Dust2 takes it to a whole new level. And not only that-
every surface is a displacement. This is generally used for bumpy ground, but in Dust2 it remains
flat. I believe displacements are used for optimisation reasons as FMPone did the same
thing on Cache. Displacements also support blended textures, letting you can paint sand
onto a stony surface in a convincing manner and so on.
But Dust2’s special, isn’t it. Maybe they can justify making everything out of props
and displacements because they don’t intend to ever change the layout. In contrast to
this, Canals is new and experimental, so it makes sense to use func_details everywhere
since it’s easier to work around these should the map require large changes- some of which
it’s gone through already! This is when I discovered something else interesting.
Running about the map to see if anything was broken, I discovered this at bombsite B. The
pillars and arch have gaps between! This is very unusual because decompiling a map doesn’t
lead to problems like this. And then I remembered that this part of the map had recently been
changed! I covered it in my video here. And in the same video, near the end, I say how
nice it is that Valve has updated the editor so that we can scale models.
This is something that we’ve wanted for years. To be able to resize props to any size
we want to! It’s such a basic feature, yet it was missing from Source. Until now.
And now we know why: they couldn’t be bothered to remake THIS arch, so instead updated the
entire program to allow for model stretching! I’m a bit sad about this. Here I was, thinking
they had added it because the community wanted it, when actually they were doing it to fix
a problem that they had. So why hadn’t these already been resized
when I decompiled the map to make it editable in the first place? Simple: the decompiler
I used is older than this update, and didn’t know to resize the models itself! When fixing
the arch, I guessed the scales to make it look okay, but I don’t think I used the
exact same values as Valve did originally. And directly below bombsite B I found a weird,
see-through-y bug. I looked in the editor to see what was going on- turns out they were
‘nodraw’ blocks. These are invisible in-game. But why were they here? I was thinking of
just deleting them, but then I had an idea: maybe this is another feature that’s new
enough not to be recognised by the decompiler that I used. In-game, I used r_drawclipbrushes
1. Nothing. 2! Still nothing. 3… and the whole thing shone green. Success! But what
does this mean? A quick google search revealed that these
should have been grenade clip brushes. So that grenades bounce off them predictably.
…so I went around the map making any suspect nodraw textures into grenade clip brushes,
just to be sure. And then I noticed something else. The reflections
look RUBBISH! They’re not reflecting anything! Seems that props have an option to be ‘reflected
in the water’ and they’re all switched off by default, even though the original map
clearly had them enabled. …so I painstakingly went about the water,
manually enabling it for each and every prop you can see that’s reflected. I could enable
it on every prop in the whole world, but that kind of defeats the purpose of this option
in the first place. It’s here to improve performance and is something I suspect a poor
developer also had to do before Canalseses release. And they missed a few props- in the
official map, if you go to odd locations you can sometimes find something not reflected
that really should be. See! All this stuff you wouldn’t ever have
noticed were it not for this video, though now I’ve revealed it I know I’ll be spammed
with a thousand messages pointing out props that I missed.
Please don’t. And lastly, I need to fix the areaportals.
These things are also a form of optimisation, acting as a window, hiding anything beyond
it that you shouldn’t be seeing. But once again, the decompiler doesn’t do a good
job of these and it ends up breaking them all in surprisingly imaginative ways!
This one here leaves a tiny little gap. And although it may be small, it breaks THE ENTIRE
PLANET. If they’re not working properly then in-game,
parts of the map will look invisible until you visit them, upon which they’ll appear
but then another bit will probably turn invisible. Like a digital form of whack-a-mole. Removing
all area portals completely will solve this, but then your FPS will be lower since it won’t
have areaportals to help it know when something shouldn’t be drawn.
With the little hole one, it’s easiest just to delete and to remake it again.
Some seemed to be 3 or 4 in one for absolutely no reason, which made me paranoid, going about
deleting every areaportal I could find to see if another was hidden inside.
And lastly, it shifts them all by 1 unit, either to the side or up or down one, or sometimes
in a way that I can’t fix. This stage probably takes up half the time I spend on these maps,
making an adjustment, compiling the map and then testing to see if it’s worked in-game.
I managed a pretty good job with these 2 maps- better than I’ve ever managed before- but
unfortunately, some were too much trouble and I deleted a few, so the FPS may be a bit
less than with the original map. BUT NOT BY MUCH.
Another cool thing I discovered was here at CT spawn: look closely enough at the arch
in the distance and it’s solid WHITE. This is literally a huge white square that fades
away as you get closer or try to zoom in on it. But while it’s solid, the game doesn’t
have to draw any of the details behind it. I suspect that late in the development of
this map, Valve were having problems keeping the FPS high enough around CT spawn and resorted
to this as a desperate measure. This is an areaportal WINDOW, which has been used ever
since Half Life 2- this is why on the coast levels, you couldn’t see through the windows
of houses until you got close enough. And while we’re on the subject, please could
someone at Valve fix the optimisation issue on this bit of Coast 9? It’s been bugging
me for years. There’s also the occluders which are kind
of like the opposite of areaportals, hiding things that should be hidden behind solid
objects already. Sadly, these are so broken that I’ve given up and flicked them off
here. Enable them at your own risk! This is what it looks like if you do, just
so you don’t bother. …and there you have it. That’s currently
how hard it is to make a Valve map editable. My efforts are by no means perfect- but I
hope it will at least save other creators a bit of time. Sure, it’ll be obsolete the
moment these maps are updated. But what are you going to do about it? You’re going to
have to put up with my attempts, which I output at a rate roughly equal to Valvetime!
But maybe there are other options. Perhaps somebody else can be bothered to do
it. Or maybe Valve will one day provide the original files for all of us, and in their
perfect states. It’s not like editing maps is a secret, is it.
If you like knowing pointless and potentially annoying stuff about how unplayable CS:GO
is, I can recommend this video on stairs that I made a few years ago. Or how about a video
I made for Dell earlier this year where I reflect upon shiny surfaces and how CS:GO
is a bit dull.