[TUTORIAL] Map Checklist - Double Check You Have All of This Before Going Alpha!

[English Mobster]

This is sort of a "Mapper's Checklist," a list of common problems in A1 maps that should be fixed to prevent issues in the first alpha. For beginners, a small walkthrough has been added in fixing these common issues.

• Is your map's name in all lowercase?

  • Linux servers distinguishes capitals as separate letters from lowercase (Windows machines do not). If the redirect file is in all lowercase letters (say ctf_coolmap_a1), and the Linux server is trying to find a map with capitals in it (ctf_COOLmap_a1) you will be left with a missing map error and no one can download the map from the server. It won't crash though.
    If the redirect file and server file have the exact same formatting and name it will work. But it's recommended you stay to lowercase only, as that will cause less problems for server operators across all platforms.

• Is your map scaled correctly?
  • A common mistake for a first alpha is to have a gameplay area that is too large or too small. 1024x1024 Hammer Units (HUs) is a good size for a capture-zone area; you have a pull of perhaps 500 units in either direction beyond that, but after that you begin getting either overscaled or underscaled.
  • You should also avoid having ledges that are above 256 Hammer Units in vertical height; although you can have taller ceilings, you should try and avoid making anything above a straight 256 Hammer Unit drop to the ground. Taller walls is a warning sign of overscaling.
  • You should NEVER have a single line that can be drawn in over 3000 Hammer Units in any direction. That is the longest sightline in a Valve map, and even that is pushing it. Try to limit your sightlines to a little over 2000 units or you risk overscaling.
  • Make your skyboxes high and your playerclip higher! Use brushes covered in the "tools/toolsplayerclip" texture to seal off roofs you don't want Soldiers or Demomen to run around on (chances are, they CAN get up there if you don't). Make your skybox 1500 units high MINIMUM to allow Demomen to do their sticky jumps around the map without hitting their heads on the clouds.

• Is your game logic set up?

1. Without any logic, you won't have a game! Copy and paste the gametype of which you seek from ABS' pack. Open "ABS_GametypeLibrary_*Version Number*.vmf" from your mapsrc folder.
2. On the side, find "Visgroups," then click on the "User" tab and uncheck all the gametypes but the one you want.
3. Click on "Auto," then uncheck "World Geometry." Copy what's left and paste it into your map for a fully-working stock gametype!

• Do you have at least 32 spawn points enabled initially?
  • While this isn't gamebreaking, it's a good habit to get into to make sure you have at least 16 initial spawn points for each team. Many servers nowadays run 32 man servers, and it's nice when you don't spawn inside of people. To clone a spawn point, click on the ones included in Boojum's kit and shift + drag them next to one another. This creates a copy; repeat until you have 16 spawns per team.

• Do you have func_respawnrooms and func_respawnroomvisualizers?
  • A func_respawnroom tells the game where you can change classes without dying. Make sure it covers the entirety of your spawns or you'll have people dying when they change classes! It should be covered in the "tools/toolstrigger" texture.
  • A func_respawnroomvisualizer is what keeps the enemy team OUT of the spawn, the circle with a line through it that appears as you near an enemy respawnroom. Link it to the proper func_respawnroom and cover all sides BUT the one facing the enemy team in the "tools/toolsnodraw" texture. For the side facing the enemy team, make that face "overlays/no_entry" and hit the "Fit" button under "Justify" on the Face Edit Sheet (the square below the all-white square).

• Do your main spawns have resupply cabinets in them?
  • ABS's pack has a quick resupply cabinet prefab as well. To place it, click on your entity tool, then on the right, click on the dropdown next to where it says "Categories" and select "ABS TF2 - General." Below that, where it says "Objects," select the appropriate Resupply Locker inside of the spawn.

• Have you placed your team filters?
  • This is how TF2 knows who is on RED and who is on BLU (or rather how our map can have things work based on what team they're on). ABS' pack has a prefab for these, too, simply follow the steps above and place "Generic Team Filters" instead of the Resupply Cabinet.

• Is everything the player can't see coated in "tools/toolsnodraw"?
  • While the game tries to guess this as best it can, sometimes it renders stuff it doesn't need to, which is bad for people with poor computers. Make sure ANYTHING that the player will not see without a spectator camera is coated in this texture; you WILL miss some, so be extra-vigilant when possible.

• Is your map free of leaks?
  • A leak is something that happens when an entity in your map is touching the "void," causing lighting and performance errors. To illustrate what is wrong with this, imagine your map is literally in space and the skybox is full of air. If the map somehow were to have a hole, all of the air contained would rush out into the vacuum of space. To protect against this, everything has to be sealed completely to keep the "air" in.

1. To check, first save your map, then go to File -> Run Map (F9). A box will come up with 3 categories of 3 options each, with a checkbox below. If you don't see this, hit the "Normal" button on the bottom left. Select "Normal" for RunBSP and "No" for the other 2 options, then check "Don't run the game after compiling." This will skip all the long stuff and just check for any major errors. If you get a message near the top of the compile log saying that something leaked, you have a leak!
2. The compile log will spit out coordinates; copy these, for you will need them shortly. Go to "Map -> Load Pointfile," which loads the path the air (or in our case, an entity) took on its way into space. Moving the entity won't stop it from getting into the void; you have to follow where it went using the red line until you get to the hole.
3. To find where the entity is, click on "View -> Go to Coordinates," then paste the coordinates you copied earlier. Follow the line to seal the hole, then start over from step 1 until all leaks are filled. Don't be ashamed if this is your first map and you have lots of leaks; everyone does their first time.

• Do you have lighting?
  • By default, if you have not placed lights, TF2 uses the console command mat_fullbright to light up your map for you. The problem with this is that it's ugly and it lingers even after the server has changed the map! By not including lights in your compile, you now remove everyone else's lighting as well, which just isn't fair. So place a light_env and copy some of these values into it to make it look nice and pretty and get rid of the mat_fullbright. It'll help the WIP thread not make fun of you for it as well.
  • A VERY useful resource is Ravidge's Lighting Library. You will need to make some tweaks, get rid of the collisions on the overhead lamps, reduce the lighting from 255 255 255 to something more along the lines of 200 200 200 (or even lower) to make it less completely white. But just copy and paste light sources from there and you're set!
  • If you want to compile with HDR (not recommended for early alphas), make sure you adjust the BrightnessScaleHDR flag to around .75 or lower. HDR adds bloom and brightness to your lighting; it looks pretty but gets VERY bright and shiny if left at 1. HDR is a lot of time and work for a tiny detail; Valve doesn't even support it outside of Gravel Pit, to my knowledge. It's best to leave out the HDR until you know what your doing or have reached beta (after you do what they call an "artpass," getting rid of all the developer textures and adding details to areas).
• Do your doors work?
  • Each door must be unique (except setup doors). Ordinarily, they're a pain to set up, but ABS's pack is nice enough to have a bunch of prefabs for everything from Setup doors to Well's doors to regular old doors.
  • Use the prefabs everywhere you need a door for easy placing. Just select a door and follow the same setup you do for your Resupply Cabinets. Make sure you're set to "Groups" mode (upper right hand side) before you try to move or rotate the door so you don't just move the trigger or the prop around.
  • As each door must be unique (except setup doors), you can't shift-drag them from place to place. If you see a trigger or func_door with a bold name, then you have a duplicate, which will cause both doors to open and close randomly. Find and replace any duplicates to fix this, and don't copy and paste or shift + click doors to prevent it altogether.
• Have you placed signs?
  • YOU may know where everything is, but your players do not. Place LOTS of arrows pointing towards the objective. Make everything as CLEARLY marked as possible. Map like you're trying to tell a 3-year-old where to go; a quick look at Valve maps will tell you that you can never have enough signs.

• Do you have Health and Ammo and the patches underneath them?
  • Make sure to place some "item_healthpack_*" or "item_ammopack_*" entities in your map. Again, make these obvious where you will find them, as if the game was being played by 3-year-olds.
  • If you look at the Valve maps, they have patches underneath the health and ammo packs. Make sure to do this yourself so that players know where health and ammo will respawn if it happens to be gone. Place a patch by typing "patch" in the material browser and placing an overlay under the health/ammo pack.

• Are your displacements power 2 or 3?

  • If the displacement power is too high in a small area [creating a high vertex density], any physics object interacting with that displacement will cause the server to crash (most notably Demoman grenades).

  • There is no difference between 4 power 3 displacements (Each 512x512) in an area [versus] 1 1024x1024 power 4 displacement when it comes to optimization or stability of your map.

  • It's better to be safe than sorry. Cut up your displacements where you can and stick to powers of 2 or 3 to avoid any areas of high vertex density and thus crashes.

• Are all the props that should be solid solid?
  • A lot of Valve's props have no collision models. Whenever you place a prop you've never used before, double-check to make sure it has a collision model by checking the "Collision Model" flag in the Model Browser. Common props that have no collision model are the Payload tracks and the Hydro substations. If they have no collision model, make sure the "Collisions" field is set to "Not Solid" (if you don't see this, turn on SmartEdit by clicking the SmartEdit button in the upper right) or you will get red text in your console.

• Are the collision models on your props smooth?
  • This is more for later alphas and early betas, but now is also the time to be proactive and make sure everything on the props feels smooth (you'll probably need to run ingame a few times to test this). Anything that bumps you should have a brush next to it textured in "tools/toolsplayerclip" that smooths it out. You're aiming for something that feels smooth when you run against it, but still hugs the props tightly and lets you go into places where it looks like you should go.
  • NOTE: With the exception of "tools/toolsnodraw" and "tools/toolsblack" (or their ilk) NO TOOL TEXTURES SHOULD BE FUNC_DETAILED. This includes player clips and skybox textures! Player clips already function as invisible func_details in themselves and need to support from an entity unless you'd like to toggle them on or off with a func_brush.

• Are you func_detailing anything that doesn't impair visibility too much?
  • This will save you time and headache by reducing VVIS, the longest part of a compile, down to almost nothing. The Source engine likes squares; if you have tiny little things butting into a large, rectangular room, you can func_detail them to save yourself and the game some headache. Do this for everything you possibly can, from stairs to large structures like Gravel Pit's C or B, both of which are entirely func_detail.
  • Keep in mind that the game throws away func_detail after it is done with VVIS; they'll be treated like a normal part of the map after that, although they won't seal a leak. Players and objects still bounce off of func_details and treat them like normal geometry; if you want a player to move THROUGH something, use a func_brush with the "Solidity" field set to "Never Solid".
• Have you pressed Alt + P in Hammer to make sure your map doesn't have any problems?
  • This checks for problems or errors with your map. This will find entities with broken Inputs or Outputs, Invalid Solids, and a host of other issues with your maps (it will NOT find leaks or anything else that comes up during compile).
  • There is an auto-fix button, but be wary as sometimes this can completely delete things that you don't want to delete, such as Overlays that have lost their assigned faces due to the brush being cut with a slice tool. It's generally safer to fix anything you can "see" as being truly broken and to double-check anything that Hammer says is broken but isn't in actuality. It also has a tendency to mark anything that is hidden as broken by default; uncheck the "Check Visible Parts of the Map Only" flag and tread carefully.
  • There will be one error message that will always be there, even in a fresh map: "There is no player start." This is not referring to TF2; it is referring to Half-Life 2 spawnpoints. Because this is a TF2 map, you don't need HL2 spawns, although you can place one if you truly like and it'll make the message go away.

• Have you placed and built cubemaps?
  • TF2 uses these to determine reflections, but it doesn't do it on its own. You will need to do this every time you compile for a release if you don't want purple and black checkerboards everywhere. This is for non-HDR compiles (the way you should for an alpha; simply leave the "HDR" flag unchecked when compiling your map). If you're using HDR, follow steps 1 and 2 below and then see this post.
  1. Every few hundred Hammer Units or so, place a env_cubemap. These should be sprinkled liberally, but not too liberally.
  2. Once you have placed all of your cubemaps, go to "Map -> Entity Report." Select ALL of your cubemaps at once and raise them up about 64 HU off the ground. Now compile the map.
  3. Ingame, open up your console with the ~ key. Type, one line at a time:

[CENTER] sv_cheats 1
mat_specular 0
buildcubemaps
mat_specular 1
disconnect
mat_reloadallmaterials
sv_cheats 0[/CENTER]

• NOTE: There IS a better way to do this, but my way works. I can't seem to find a link to the better way; can someone help me out here?

• Are your VVIS and VRAD set to "Normal"?
  • When compiling your map, make sure everything's set to "Normal" for an alpha 1. You won't see this option if you're in the "Expert" section of the run map dialog, so use the "Normal" section with everything set to "Normal" unless you know what you're doing (you should leave the "HDR" flag unchecked until beta). Otherwise you will either have shoddy lighting, poor framerates, or both!

• Have you packed any custom content?
  • If you're using any custom content at all, you NEED to pack it using PackBSP or Pakrat (I have problems with Pakrat; so I recommend PackBSP). Just because YOU can see the stuff doesn't mean that the people playing on a server will.

• Does your packed custom content work?
  • To do this, first you need to reset your "\steamapps\*steamname*\team fortress 2\tf" folder back to stock. Rename your regular "tf" folder to something (I use "tfmain"), then go to your Steam library. Close the SDK if you have it running for whatever reason, then right-click on "Team Fortress 2," go to "Properties," then navigate to "Local Files" on the thing that pops up. Click "Verify Integrity of Game Cache." This will essentially reinstall TF2; it'll see your "tf" folder is missing and provide you with a stock one without the custom models in it. This process normally takes me about 10 minutes, and it typically gets stuck on "100%" for a while, even though it's not done yet. Just wait for the progress bar to go away entirely and you'll be fine.
  • Run your packed map and see if the custom models show up. If not, something has gone wrong somewhere. There are several different things that could have gone wrong, too many to cover in this guide, but a quick Google search will typically find you an answer (and if that doesn't help, our Steam chatroom is always willing to help; click that link to automatically join!).
  • If everything worked, you can rename the stock tf folder to something (I use "tfstock") and change your main tf folder (my "tfmain") back to "tf". You're ready to go!

Follow this checklist, and you should have a smooth alpha.

 

[mk_rules1]

Thats perfect great job!

 

[TheKieranator]

Nice list!

PS: Is this what you were looking for?

 

[Sergis]

there are people who don't use pakbsp for packing, dont use abspack, dont use hammers' default compile. some parts of this don't really apply to them. also, a way to check if custom stuff packing has worked is necessary in a writeup like this. people sometimes think they have packed their stuff when they actually haven't.

 

[English Mobster]

there are people who don't use pakbsp for packing, dont use abspack, dont use hammers' default compile. some parts of this don't really apply to them. also, a way to check if custom stuff packing has worked is necessary in a writeup like this. people sometimes think they have packed their stuff when they actually haven't.

I don't understand why they're not using ABS' pack, considering it doesn't majorly conflict with anything else (to my knowledge).
I mention the non-default Hammer compiles; basically I say those should be saved for a later alpha/beta. There are too many things going on in there to sum up nicely (also why I only mention PackBSP), where the summaries are generally aimed at newbie mappers understanding why/how things are the way they are.
As for checking if the packing has worked, I'll write something in about it in a second here.

Nice list!

PS: Is this what you were looking for?

That's the way I learned; but I think in the chat someone said that's not the best way to do it and posted something better a LONG time ago. My way DOES work, however, and it's by far the easiest to remember.

 

[Sergis]

abspack is useful i guess, but isnt really THAT necessary. your writeup pretty much relies on it in some places.

by not using hammer compile i meant using VBCT

also, your method to test if packing has worked is fucking crazy. what i do is i just drag the custom stuff files and folders to the desktop and then drag them back after testing. i need to overwrite the spray texture that is recreated, otherwise this method works smoothly. i think some people use renaming custom folders.

 

[Ravidge]

• Is your map's name in all lowercase?

• Most servers run on Linux, which is sensitive to uppercase letters. If a map with ANY uppercase at all is loaded onto it, it will crash the server (a major no-no). So keep your .vmf name (and thus map's filename) in all lowercase.

Not exactly true. You can have maps with capital letters, but linux servers distinguishes capitals as separate letters from lowercase (Windows machines do not). If the redirect file is in all lowercase letters (say ctf_coolmap_a1), and the linux server is trying to find a map with capitals in it (ctf_COOLmap_a1) you will be left with a missing map error and no one can download the map from the server. It won't crash though.
If the redirect file and server file have the exact same formatting and name it will work. But it's recommended you stay to lowercase only, as that will cause less problems for server operators across all platforms.

• Are your displacements power 2 or 3?

• Anything above power 3 WILL CRASH a server. It'll run fine until a body, rocket, stickybomb, or anything of the like hits it, then it'll crash. Stick to displacements of powers 2 or 3.

Not true either, power 4 displacements work fine. What doesn't work is high vertex density on a displacement map. If the disp power is too high in a small area, any physics object interacting with that displacement will cause the server to crash (most notably demoman grenades). However. On a large brush, power 4 displacements are not an issue.

 

[Freyja]

Exactly. There is no difference between 4 power 3 displacements (Each 512x512) in an area, than 1 1024x1024 power 4 displacement, when it comes to optimization, or stability of your map.

 

[English Mobster]

Not exactly true. You can have maps with capital letters, but linux servers distinguishes capitals as separate letters from lowercase (Windows machines do not). If the redirect file is in all lowercase letters (say ctf_coolmap_a1), and the linux server is trying to find a map with capitals in it (ctf_COOLmap_a1) you will be left with a missing map error and no one can download the map from the server. It won't crash though.
If the redirect file and server file have the exact same formatting and name it will work. But it's recommended you stay to lowercase only, as that will cause less problems for server operators across all platforms.


Not true either, power 4 displacements work fine. What doesn't work is high vertex density on a displacement map. If the disp power is too high in a small area, any physics object interacting with that displacement will cause the server to crash (most notably demoman grenades). However. On a large brush, power 4 displacements are not an issue.

Exactly. There is no difference between 4 power 3 displacements (Each 512x512) in an area, than 1 1024x1024 power 4 displacement, when it comes to optimization, or stability of your map.

Good to know; I'll make the corrections. Thanks!

 

[henke37]

Is there an automated tool that checks as many of these points as possible?

Also, let me add a point: provide spectator cameras. Listen servers WILL crash if the game can't find a camera to spectate for a player. This situation only happens if all players on a team are dead at the same time.

 

[Fruity Snacks]

No tool available as far as I know.

 

[henke37]

Can we make one? I think that it would help gameday hosts by doing a lot of the checks for them.

 

[mint onion]

i wish i had seen this thread when i was starting out. English Mobster, you are a scholar and a gentleman.

 

[wareya]

Is there an automated tool that checks as many of these points as possible?

Also, let me add a point: provide spectator cameras. Listen servers WILL crash if the game can't find a camera to spectate for a player. This situation only happens if all players on a team are dead at the same time.

I thought they fixed that some time this year.

 

[Skorly]

Thats a lot of info xD
but thx

 

[iiboharz]

Thats a lot of info xD
but thx

I think I'm speaking for everyone here when I say that I'd appreciate you not bumping threads just to leave statements like this. If you want to say thanks to someone, there's a button with that exact word on each post there for a reason.

 

[Fruity Snacks]

I think I'm speaking for everyone here when I say that I'd appreciate you not bumping threads just to leave statements like this. If you want to say thanks to someone, there's a button with that exact word on each post there for a reason.

Nah, this type of thing is A-Okay.

 

[iiboharz]

Nah, this type of thing is A-Okay.

Alrighty then, shows what I know.

 

[Pocket]

This subforum in particular can stand to have things bumped because all the good threads are just as relevant now as ever. If anything, we could stand to have them shuffled around more often so people get exposed to the ones that fell off the front page ages ago.

 

[Géza!]

Alright, I think I have all these things checked for the first alpha of my map, but I still gotta ask- what about the compile? Should I compile a first public alpha with HDR? Should I use the fancy advanced options, or just go with a basic compile because I'll change too many things in the future anyway?