You might remember the Manifest toolbar from the first time you opened Hammer. The guide you were following to get everything set up probably told you to close this stupid, worthless box. They might have said it was too complicated to bother with, or maybe that no one understood it, or possibly that it just wasn't useful for anything.
They were wrong.
Manifests can help you organize your map better and decrease the difficulty of working on your map. Thought instancing your large geometry was fun? Wait til you get a load of this. The best part is you can toggle areas of your map on and off like visgroups, and still retain the ability to toggle actual visgroups, giving you a fine grain of control over what appears in your grid. And it isn't hard, confusing, or complicated.
How?
Before we get started, note that fubar already wrote this up himself, but with more of a focus on version control and collaborative mapping. You do not have to worry about all that. This guide exists to simplify the process for people and tell them why it's worth using even alone. My guide will focus on getting you on the ground running in a basic way so you can more easily grasp what fubar is going on about.
I also have to tell you one other thing. Once you start using manifests, you will not be able to compile the vmm file like before. There's an easy workaround, but it takes some time to setup. Luckily, you only have to do it once per map.
Bear in mind: I'm trying to make this simple, but it's still a fairly advanced concept. You should already understand other advanced features, like instances, before trying this.
Let's get started!
---
The first thing you need to do is open your map. Then go to Instancing > Create Manifest. Hammer will ask if you really want to do this. Hell yes we do! After a moment, you'll notice your map is yellow.
What this has done is turned your old vmf into a vmm (your old vmf is still there, though). It's basically the same thing, but now your map has a folder, and within that folder, the "submaps" of your actual map. What are the submaps? Anything you want!
Note: If you have any instances in your map, you need to take the time to make sure that the file paths remain correct relative to the new directory. More on this at the end.
The next thing to do is to make sure you've got the Manifest bar somewhere. I docked mine on the side so it's out of the way.
Double click on the box that says "unnamed". This will be the name of the base layer of your map, so rename it to something sensible. Like fubar does in his guide, I will use main.
There are spaces for 3 icons next to the name of your main manifest and its submaps.
The top left is an eye. Think of this like the eye on the Layers window in Photoshop or GIMP. If you click the eye right now, your map will disappear. Click again and it's back!
The top right is probably showing a red X. The red X means that submap is write-protected, meaning you cannot edit it. This is mostly used along with the version control system that manifests are meant for, but this guide isn't about that.
The bottom right will sometimes show a little pencil. This means you have unsaved changes within that submap. Just go to that submap, hit Ctrl+S, and then click another submap to refresh the icon and the pencil should disappear. Needless to say, it is important to save.
OK. So now what?
First, double click anywhere in the 3D viewport if you haven't already. This will select whatever file you click--right now, there's just one, and that's "main". Save to get rid of the X if you haven't. Unless you use version control, I don't think there's a reason you'll ever see this again.
Next, right click on your base layer, and go to Insert > Empty Sub Map.
("Existing Sub Map" is used to import vmfs that already exist. It's mainly used in version control.)
Hammer will ask you to name your new submap. I don't believe anything should be too complex, so I make both names as simple as I can to avoid confusion. The friendly name displays in Hammer, and the filename should be self explanatory.
Right now, our bluspawn submap is empty. To add to it, let's select some stuff!
Then, right click the submap you want to move this to.
Now if you click that little eyeball...
Now, just continue dividing your map however you like and you can start making your life way, way easier.
When you're editing one of the submaps, only things in that submap are selectable. So you can still have other geometry around for guides, but won't have to worry about selecting it. Ever.
This is not really like instancing. You can't move these submaps around within your base map like you can with instances. In fact, if you take a look at the vmfs Hammer makes, you can see your geometry is exactly how it was in the original, but in a new vmf, alone, positioned relatively.
If you like, you can edit these vmfs by themselves, but I don't recommend it. Toggling them in the Manifest bar is the intended practice, and it really works quite well. It's a lot faster than switching files to edit large instances, doesn't take forever to load, can allow multiple people to work on the same map at once via Dropbox (though this might necessitate some version control), and really allows you to have a clean workspace in the editor.
OK. Remember when I said you can't compile the vmm? It's because Manifests aren't really finished. Compiling a vmm results in a broken skybox texture and some other errors; fubar submitted a bug report for vbsp about this to Valve, but who knows if it will get fixed. (Please don't comment there unless you have something useful to add.)
The workaround is to create a new vmf and instance all your map pieces. The easiest way I can think to accommodate this is to put each map project in its own dedicated folder.
For instance, I have all my cp_theory files in \tf\mapsrc\theory. I also put -dev at the end of my file names, so currently I'm working on cp_theory_a17-dev.vmm in Hammer. Here's what I mean, if you are having trouble picturing it:
The file with the same name as my vmm is the base layer--the map I started this manifest from.
For simplicity, I keep my instances in the \theory\ directory. Then, I changed each func_instance filename from (for example) insidelight001.vmf to ../insidelight.vmf using entity report. This tells Hammer to look up one directory before looking for those instances, and that way I don't have to worry about moving them between vmm folders. (If you do this, you'll notice entity report now only scans whatever submap you've selected, which can be super useful.)
When it comes time to compile, I need to create a new vmf and set it up. I'll name it cp_theory_a17 (since that's the filename I want to release as), save it in the directory with all the other vmfs, and then stick an entity at the origin and make it a func_instance. Then instance one of the vmfs that makes up your map.
See it there? The func_instance cube at the origin of this new vmf. This is instancing most of the map since I haven't cut it up too much yet.
Do this for each other vmf until your map is complete and then select them all and change the "Entity Name Fix Up" field to "none". Then compile as normal. When you want to increment a version number, just copy your old vmf for release to your new vmm folder, rename it, and make sure any new submaps are also added. It will update automatically, so you only need to do this once per map. (Make sure after collapsing your instances you don't save, or that you create a backup, so you don't have to go through the hassle of placing all your submaps as instances again.)
"But wait!" you say, "Don't displacements break in instances?" The short answer is yes, but not in this case. Phew!
The long answer is they never break--they work as intended, actually! But the intended way is to be stored as data points relative to the origin on the vmf. So for most maps, instancing displacements would be too difficult to bother with because they wouldn't be in the right place, but since these vmf files created by the manifest store your geometry relative to their respective origins anyway they'll work just fine.
Of course, how you choose to use Manifests is up to you--that's just the workflow I was already sort of using, and therefore makes sense for me. What you do is your choice.
---
I really hope this is simple to understand, and I also hope that you all begin to use manifests when working. I've only had this figured out for a few hours and already wish I hadn't been afraid of this years and years ago. Do yourself a favor and use manifests!
If anything is unclear or you have additional questions, let me know, and I will try to answer as best as I can.
They were wrong.
Manifests can help you organize your map better and decrease the difficulty of working on your map. Thought instancing your large geometry was fun? Wait til you get a load of this. The best part is you can toggle areas of your map on and off like visgroups, and still retain the ability to toggle actual visgroups, giving you a fine grain of control over what appears in your grid. And it isn't hard, confusing, or complicated.
How?
Before we get started, note that fubar already wrote this up himself, but with more of a focus on version control and collaborative mapping. You do not have to worry about all that. This guide exists to simplify the process for people and tell them why it's worth using even alone. My guide will focus on getting you on the ground running in a basic way so you can more easily grasp what fubar is going on about.
I also have to tell you one other thing. Once you start using manifests, you will not be able to compile the vmm file like before. There's an easy workaround, but it takes some time to setup. Luckily, you only have to do it once per map.
Bear in mind: I'm trying to make this simple, but it's still a fairly advanced concept. You should already understand other advanced features, like instances, before trying this.
Let's get started!
---
The first thing you need to do is open your map. Then go to Instancing > Create Manifest. Hammer will ask if you really want to do this. Hell yes we do! After a moment, you'll notice your map is yellow.
What this has done is turned your old vmf into a vmm (your old vmf is still there, though). It's basically the same thing, but now your map has a folder, and within that folder, the "submaps" of your actual map. What are the submaps? Anything you want!
Note: If you have any instances in your map, you need to take the time to make sure that the file paths remain correct relative to the new directory. More on this at the end.
The next thing to do is to make sure you've got the Manifest bar somewhere. I docked mine on the side so it's out of the way.
Double click on the box that says "unnamed". This will be the name of the base layer of your map, so rename it to something sensible. Like fubar does in his guide, I will use main.
There are spaces for 3 icons next to the name of your main manifest and its submaps.
The top left is an eye. Think of this like the eye on the Layers window in Photoshop or GIMP. If you click the eye right now, your map will disappear. Click again and it's back!
The top right is probably showing a red X. The red X means that submap is write-protected, meaning you cannot edit it. This is mostly used along with the version control system that manifests are meant for, but this guide isn't about that.
The bottom right will sometimes show a little pencil. This means you have unsaved changes within that submap. Just go to that submap, hit Ctrl+S, and then click another submap to refresh the icon and the pencil should disappear. Needless to say, it is important to save.
OK. So now what?
First, double click anywhere in the 3D viewport if you haven't already. This will select whatever file you click--right now, there's just one, and that's "main". Save to get rid of the X if you haven't. Unless you use version control, I don't think there's a reason you'll ever see this again.
Next, right click on your base layer, and go to Insert > Empty Sub Map.
("Existing Sub Map" is used to import vmfs that already exist. It's mainly used in version control.)
Hammer will ask you to name your new submap. I don't believe anything should be too complex, so I make both names as simple as I can to avoid confusion. The friendly name displays in Hammer, and the filename should be self explanatory.
Right now, our bluspawn submap is empty. To add to it, let's select some stuff!
Then, right click the submap you want to move this to.
Now if you click that little eyeball...
Now, just continue dividing your map however you like and you can start making your life way, way easier.
When you're editing one of the submaps, only things in that submap are selectable. So you can still have other geometry around for guides, but won't have to worry about selecting it. Ever.
This is not really like instancing. You can't move these submaps around within your base map like you can with instances. In fact, if you take a look at the vmfs Hammer makes, you can see your geometry is exactly how it was in the original, but in a new vmf, alone, positioned relatively.
If you like, you can edit these vmfs by themselves, but I don't recommend it. Toggling them in the Manifest bar is the intended practice, and it really works quite well. It's a lot faster than switching files to edit large instances, doesn't take forever to load, can allow multiple people to work on the same map at once via Dropbox (though this might necessitate some version control), and really allows you to have a clean workspace in the editor.
OK. Remember when I said you can't compile the vmm? It's because Manifests aren't really finished. Compiling a vmm results in a broken skybox texture and some other errors; fubar submitted a bug report for vbsp about this to Valve, but who knows if it will get fixed. (Please don't comment there unless you have something useful to add.)
The workaround is to create a new vmf and instance all your map pieces. The easiest way I can think to accommodate this is to put each map project in its own dedicated folder.
For instance, I have all my cp_theory files in \tf\mapsrc\theory. I also put -dev at the end of my file names, so currently I'm working on cp_theory_a17-dev.vmm in Hammer. Here's what I mean, if you are having trouble picturing it:
The file with the same name as my vmm is the base layer--the map I started this manifest from.
For simplicity, I keep my instances in the \theory\ directory. Then, I changed each func_instance filename from (for example) insidelight001.vmf to ../insidelight.vmf using entity report. This tells Hammer to look up one directory before looking for those instances, and that way I don't have to worry about moving them between vmm folders. (If you do this, you'll notice entity report now only scans whatever submap you've selected, which can be super useful.)
When it comes time to compile, I need to create a new vmf and set it up. I'll name it cp_theory_a17 (since that's the filename I want to release as), save it in the directory with all the other vmfs, and then stick an entity at the origin and make it a func_instance. Then instance one of the vmfs that makes up your map.
See it there? The func_instance cube at the origin of this new vmf. This is instancing most of the map since I haven't cut it up too much yet.
Do this for each other vmf until your map is complete and then select them all and change the "Entity Name Fix Up" field to "none". Then compile as normal. When you want to increment a version number, just copy your old vmf for release to your new vmm folder, rename it, and make sure any new submaps are also added. It will update automatically, so you only need to do this once per map. (Make sure after collapsing your instances you don't save, or that you create a backup, so you don't have to go through the hassle of placing all your submaps as instances again.)
"But wait!" you say, "Don't displacements break in instances?" The short answer is yes, but not in this case. Phew!
The long answer is they never break--they work as intended, actually! But the intended way is to be stored as data points relative to the origin on the vmf. So for most maps, instancing displacements would be too difficult to bother with because they wouldn't be in the right place, but since these vmf files created by the manifest store your geometry relative to their respective origins anyway they'll work just fine.
Of course, how you choose to use Manifests is up to you--that's just the workflow I was already sort of using, and therefore makes sense for me. What you do is your choice.
---
I really hope this is simple to understand, and I also hope that you all begin to use manifests when working. I've only had this figured out for a few hours and already wish I hadn't been afraid of this years and years ago. Do yourself a favor and use manifests!
If anything is unclear or you have additional questions, let me know, and I will try to answer as best as I can.
Last edited:
