Q: What Rules of Thumb do you use?

Many!

1. Never carve unless absolutely required. Even then, I often carve in a new map and paste the object within the one I'm working on. Sometimes this reduces problems with carving, and at other times it increases them. I just have to try both methods each time and see which one doesn't present any problems. Pasting intricate objects has proven disasterous a couple times, too.

2. Make Backups. I usually save versions of my file sequencially, such as mymap1, mymap2, mymap3. I always save to a new file name just before carving, if I plan to carve at all. After I've settled on a room or new addition, I make a new file before starting on a new area.

3. Run QBSP and VIS often. I run them just to make sure the map will compile (I watch for errors while QBSP and VIS run). Most of the time I have "Don't run the game" checked. If ever an error is generated, there are 2 things I can do: 1) I have a backup of the map that did compile, so I may start from there if I need to. 2) I usually know what I did most recently and I can delete or fix the offending object as needed. Once VIS -FAST generates the "leaf portals saw into leaf" error, you will have to begin using VIS -LEVEL 1 to continue seeing your map with the benefits from VIS. At this point you may decide to keep working with QBSP and wait to apply VIS -LEVEL 1 when you are closer to being finished.

4. Never manipulate vertexes unless necessary. Some of the simplest vertex manipulations just fill a map with problems. If this happens, I'd rather create a new brush and manipulate the new brush's vertexes, or go without an unmanipulated brush, than to suffer with the map's potential for problems. Jim Kaufman AKA Sgt. Thundercok, (the author of Rock1, Well6, and SpazBall) gave some me good advice on this issue, also: never drag a vertex on a vertex, and save as a .map file after doing a new manipulation.

5. Export to Map. Close. Open Map. Once I had a very strange error, it wasn't even a documented error. I did not want to lose my groupings so I did not export to MAP format even once, and now the map was almost done, it was generating a strange error. Exporting it to MAP format and then re-opening the MAP file took care of this curious problem.

6. Build the Hard Way. Instead of making a hollow box (room), then creating a block brush, carving with the block brush to make a doorway and using the block as the door, I do this instead: Ungroup the box (room) and make one side of the room smaller. Copy and paste another one of those smaller sides to make the other side of the door. Create a new brush to use as a door. Why? Refer to Rule of Thumb #1 - never carve unless absolutely required! I automatically ungroup my room walls after I'm fairly certain of the size I need. Re-grouping them for whatever reason is easily done later. To make hallways, I make a long block brush, hollow it out, ungroup it, and then delete the ends. Regroup it, and position it where it needs to go. It takes less time than typing this did, and I type 60 WPM on a good day.

7. I always test the map in Quake using a batch file. I'd noticed that some of the time the "run map in Quake" option in Worldcraft didn't work, or it was running an older version of the map I'm working on (This was an earlier and unregistered version of Worldcraft). When I realized this, I was displeased of course, and immediately made a batch file that copies my .bsp (and also the .pts in case I'm looking for a leak) into my fortress\maps directory, then runs Quake with -game fortress -winmem 24 +mapname. I keep a DOS session open all the time while I work on my maps. Let's say the name of the batch file is "DOMAP" then I just type domap mymap, it copies the files, passes the correct parameters and launches Team Fortress. I can Alt+Tab back and forth between Worldcraft and DOS. When I'm back at DOS, I hit the F3 key, which spams out my last-typed instruction (such as 'domap mymap').

Worldcraft has lots of new features and the command-string parameters you can change (at least in the Registered version) to suit your needs and your directory structure. I'm just too stuck on doing things the way I do them now. By the time I remember that WC has a whole slew of new options, the map is already loading in Quake. :P

Here is an example batch file, but you shouldn't need to mess with it if you don't want to:

copy c:\progra~1\worldcraft\%1.bsp d:\quake\fortress\maps
copy c:\progra~1\worldcraft\%1.pts d:\quake\fortress\maps
d:
cd quake
quake -game fortress -winmem 24 +map %1

Q: Why don't you use EntEd?

UPDATE:  I checked out Raistlan's new EntEd program, it's a must-see-to-appreciate. Here is the zipfile

Read some of the features that Raistlan wrote to me about his program:

Answer to Question: I tried EntEd back when I started making TF Maps and couldn't get it to work right. Nowadays I'm familiar enough with the goal structure of TF that I enter the goal properties right into Worldcraft, which also allows me to keep my groups. Raistlan has a good point: Yes, I have to look up and add up the bits almost every time, but I enjoy doing this. Sound like a headache? Get Raistlan's program, it's easier to figure out than TFENTREF.TXT! :P

Q: How do you get (trains, plats, doors, hurts, pushes, det-walls) to work right?

Learn by example, or by experimentation. That's how I did it... and still do! You can go to DOS and type EDIT and open any BSP file that you already have. The trick is to know what you are looking for. Go to SEARCH, and find things like INFO_TFGOAL, INFO_TFDETECT, ITEM_TFGOAL, et cetera. See how the author of the map names them and how they correlate with one another, or triggers, doors and other goals within the map. I intend to whip together some small zip files which include the MAP file, the BSP file and a TXT file here.

• Trains are brushes tied to a func_train entity. Trains need some path_corner entities in order for them to move. Be sure you name your path_corners (example 1st_stop, 2nd_stop, etc), and tell the Train that the name of the first path_corner needs to be the first stop it makes. If you want your train to double-back along its path like the carts in GOLD RUSH, you will need even more path_corners. If you want to build a multiple-brushed train, then build the objects that will be the train, group all the items together, and then tie the group to the func_train entity. Here is an example of a func_train and a path_corner:

"classname" "func_train" "speed" "450" "sounds" "1" "wait" "4" "lip" "0" "dmg" "0" "health" "0" "target" "stopa" "model" "*11" "classname" "path_corner" "targetname" "stopa" "target" "stopb" "wait" "5" "origin" "-684 -412 -270"

• Plats are simply brushes tied to the func_plat entity. Now all you need to do is see how far up (or down) it goes, and if that is high or low enough. You can also group several objects and tie the group to the func_plat.
• Doors are brushes tied to a func_door entity. DO NOT give this door a name ("targetname" "door_one") unless you want a button or something else to trigger it open, and remember that the button must know the doors name ("target" "door_one"). If you want to make Team-Only doors, add the statement "team_no" "(number)" either in DOS or you can add them directly into the map using WorldCraft by turning SmartEdit off. If you want two doors to open in opposite directions simultaneously when a player nears, just make sure the edges of both brushes touch and set the correct angle that each door needs to go. Use the "top view" of your map for reference when setting these angles.
• Hurts are simply brushes tied to a trigger_hurt entity. Place the damage at around 500 for a really nice gib effect. You may make them Team-Only the same way as a door. The brush you created for the Hurt will turn invisible once you tie it to the entity.
• Pushes are like hurts in that the brush will turn invisible once he's tied to the Push entity. Play around with the push's values. Pay some attention to the ANGLE value; start with angle "up" for the push to push you upwards. Some fun things come from pushes, like the cannons and smoke stacks on the Destroyers in WARSHIP1.
• EXAMPLE1.ZIP contains a detpackable wall. If you run the game with Team Fortress (explained in the text file if you don't know how), then drop a 5 second detpack near the dark wall with a dim circle of light on it (type IMPULSE 165 for a 5 second Det) and then run around the corner, back where you came from. Wha-laa.
• Things to look for in EXAMPLE1: 
• The Detpackable wall is tied to the entity func_door, and has a name ("targetname" "blow_this_wall").
• Check out the "speed" setting of the door, this makes it look instantaneous.
• The Info_TFGoal targets the door by name ("target" "blow_this_wall").
• The Info_TFGoal's "activation" is set at 2, which means "touched by a detpack."

Q: Why didn't you make your destroyers sink in "Warships?"

That was the original plan. Each base is an entire ship. What I *did* try was tying some water to a function in a test map I made. Ya know what? Water becomes hard as concrete when you tie it to anything. Which is so incredibly interesting! There has got to be a way to take advantage of that. We'll all have to change our names to "JC" and walk on water!

I'm afraid to experiment. I'll end up getting leaks.

For goodness sake DON'T BE. If you want to test something out, open a new file, build yourself a quickie room, put some light and an info_player_start in there. Then save the map as TEST.MAP or whatever you prefer. Then go on with what you want to test out. You can run this test map anytime you have something new you want to try out. Who cares if it ends up with leaks or other errors, it doesn't matter. Even if it does get errors, you may just learn how to avoid them in the future! If you like something you've done in your test map, edit > copy it and edit > paste it into your "main" map...you know, the one that *does* matter. Group the objects to keep them aligned, if it's more than one brush / goal. I've so many test maps it's pathetic! :P It's fun to mess around with a map you don't care about - it allows you the freedom to exercise your imagination.

Model issues, info TF goals and item TF goals

I see far too many model and basic goal function questions on the TF MapMaking Mailing List so I'm going to address these issues here. Click on the links above to get to the goal information.

I use QMe Lite model editor when I want to change or create a model. You can find QMe and other great products from 3DMatrix including QArt and QEd at the 3DMatrix Files page.

A model can be given to an info_TFgoal as well as an item_TFgoal. A resupplying bag, commonly called a backpack, is an info_TFgoal, whereas the "key" or "flag" is predominantly an itemTFgoal.

• Skins:  You may choose which skin you want to use on a model by adding "skin" "X" where X is the number of skin you want.)
• Frames: If the model has many frames (such as player.mdl) you may also choose which frame you want to use by adding "frame" "X" where X is the frame number. I've posted this on the Advice page but I think it will go well here, too: Here is the reference in my map for the Shambler (ICELAND3's Abominable Snowman):

InfoTFGoal: This is a very unique beast, he's used for all sorts of things. He's invisible *unless* you give him a model, then people can see him. This makes it easy for MapMakers to use him for different operations such as removing all your gear, activating other goals, hurting someone, or giving an entire team Quad damage for five seconds. Fun with this goal is the "failed critera" check. Take some time to learn about that. Here is an example of a resupplying bag, or Backpack:

Some of the values are self-explanatory, but I will run through them really quick. Keep in mind there are many more values that apply to the info_tfgoal:

• g_e is Goal Effects. This setting (1) means that only the player is affected. According to TFENTREF, we could ammo up the whole team, now wouldn't that be sweet? :P This setting is not needed since it is default. However, if I took it out, I don't think we'd see the happy little background flash when you touch the bag.
• Wait of 3 means the resupply bag will resupply someone else in 3 second (I hate waiting at resupply bags, myself!).
• Noise is the sound you hear (a wave file) when the bag refills you. Ambush (of Ambushed!  Mega-TF Mods) found this wav for me. Everyone already has it in their pak files. The next 11 items are of course how much ammo / armor / health / grenades to give. Remember that negative numbers actually take things away.
• The g_a is Goal Activation, which is set to one: Activated when touched by a player.
• The MDL as you can see is the backpack model. This particular model is already in Quake (less for players to have to download).. Notice the forward-leaning slash, that's very important!
• Netname doesn't mean anything to the map. All it is there for is so that I know exactly what goal this is. It's evidently one of team one's lower ammo packs. :}
• The team_no is set to team one because even if the Reds (team 2) get into the Blue's lower ammo room, they're not gonna get any goodies. And why should they! :P

ItemTFGoal: This is the guy usually used for keys and flags. Item and Info goals share some values, but not all! Here is one of the Crystals from ICELAND3:

I'll run through the variables quickly, but remember there are many more than just these that apply to item goals:

• delay is how long to wait before returning if the key is dropped by a dying player, in seconds.
• the broadcast messages are fairly self-explanatory. Be sure to put a carriage return (the "\n") after any messages you add to your goal.
• Goal_no is the unique number of this goal. When captures happen, the capturing goal (info_tfgoal) references this unique number with the axhitme line, thereby removing the goal from the capturing party, such as: "axhitme" "1". If there is not goal_no on your item goal and you try to capture it, you will get "could not find a goal item with a goal number of 1" spammed across your screen, and you'll run around glowing like a banshee...
• Items specifies which item to light up on the player's console. 131072 makes the silver key icon light up and 262144 is the gold key icon. Pretty cool, huh?
• team_no means only one team can activate this goal, usually the enemy team.
• skin is of course which skin of the crystal.mdl that this goal will use. This can be left out when using models with only one skin.
• group_no: If the item belongs to a group, here is how you tell it which group it's in. Makes it handy when your info_tfgoal can "activate_group_no" "1" instead of having to reference a bunch of goals individually.
• g_a: Goal activation of an item_tfgoal is different than that of an info_tfgoal. I use the TFENTREF file and just add up the bitfields:
• 1 : Carrying Player glows.
• 2 : Carrying Player moves at half speed.
• 4 : Item is dropped when a player with it dies.
• 8 : Item is returned when dropped.
• 16 : Item is returned when removed from players by a Goal
• 32 : Item is returned due to "pausetime" (see below)
• 64 : Only activated (picked-up) if AP fails Criteria.
• 128 : Enable "pausetime" removing.
• 256 : Players keep this item when they die.
• 512 : If this Item isn't being carried, it glows dimly.
• 1024: Don't remove the results of this Item when it's removed from a player.
• My Crystals, set for 693, means that the bits for this goal are 1010110101. 1 means the bit is used and 0 means it's not. Basically, I'm using bits 1, 4, 16, 32, 128 and 512 which adds up to 693. Here is how my Crystal behaves:
• 1 : Carrying Player glows.
• 4 : Item is dropped when a player with it dies.
• 16 : Item is returned when removed from players by a Goal
• 32 : Item is returned due to "pausetime"
• 128 : Enable "pausetime" removing. (strange, I don't have a pausetime setting) hmmm
• 512 : If this Item isn't being carried, it glows dimly.
• Noise is the sound you hear when you grab the key, in the form of a wave file.
• MDL is of course the model. Be sure to note the forward-leaning slash!