• How to prevent Respawn Camping - Matt <armstron@flash.net>
• Another way to find leaks - Carl Christensen <carlcmc@binary.net>
• Using what's already in Quake .PAK files - "Raistlan" <raistlan@atheist.com>
• How do the tripwires in Rock1 work? - "j3" <l.l.coolj3@worldnet.att.net>
• Putting lightning in a map - Jim Kaufman <jek19@idt.net>
• The Buttons on Well6 - Jim Kaufman <jek19@idt.net>
• WAD files / Textures - DyerMaker
• How did you make the alarm System for GR? - DyerMaker

How to prevent Respawn Camping:

On the TF Newswire BB there is a thread about finding a simple way to stop repawn campers without making a complicated anti-camper setup. We've come up with a simple solution that could easily be applied to ANY map in it's current set up with only one additional ent per respawn area.

Simply set a TFGOAL in the respawn area that kills any players from the enemy team that are in the room when it is triggered. Then set all the respawn ents to trigger that goal. That's it.

Now, you can raid the enemy resupply area, but you must be quick. And if you move slow or try to camp, you will be killed by the first enemy to respawn there. It's simple.

This will allow supply raids of the enemy stores but makes respawn camping a VERY bad idea. It doesn't account for enemy grenades, but if you want to stop enemy grenades, you will probably have to do something more far reaching. This could easily be added to almost any current map by the original designer in a few minutes with the current TF ents.

Just an idea I thought was worth passing along. -Matt

[Note from DyerMaker]: This sounds like a great idea! I build func_hurts and place them at entries to ammo rooms, giving it the enemy's team_no, of course. The above idea is more lenient, prevents the actual "camping," and allows enemies to sneak in and hope that no one respawns when he does. Cool! A very simple way to prevent respawn camping *entirely* is to make a warp in the the ammo room which is the only way out. Respawning, of course, is the only way in!

Another way to find leaks:

Draw a large box covering half of your level and do just a bsp. if it eliminates the leak then cut the box down to 1/4 of level

if not go to the other half. keep doing this until you have it down to a small area and examine it and make sure that your walls are touching etc.

[Note from DyerMaker]: The above, I've actually done - but once I had to use a hollow room as QBSP was having a hard time building all those brushes inside that huge solid brush(?). Once I also got a "leaf portal saws into leaf" message, so I moved one of the room walls, and that took care of the problem. I prefer to do "sections" of the map, try to cut off tubes that connect, for example, the entire "upper area" or "lower area" of my map. If I suspect only one room, I will start with a hollow box around that room first.

Using what's already in Quake .PAK files

Using a .pak file explorer [I use an old version of PakExplorer, the URL it lists in the About box doesn't work so I'm not sure what its homepage is; you can probably find it on cdrom.com or around...], open Quake\id1\pakX.pak where X is a number starting at 0. then browse to the progs subdirectory in the .pak file to see the .mdl files, and the subdirectories of the sounds subdirectory to see the .wavs. Also look in Quake\Fortress\pakX.pak and Quake\qw\pakX.pak. Then Quake\id1\progs, Quake\id1\sounds, Quake\Fortress\progs, Quake\Fortress\sounds, Quake\qw\progs and Quake\qw\sounds. [The last six directories may not exist, so don't worry if they're not there.] These are the possible values for "noise" [the wav files] and "mdl".

For the "mdl" field, use the path to the .mdl file from the "game" directory [id1 for normal Quake, Fortress for TF, qw for Quakeworld, etc.], like so: "mdl" "progs/v_asscan.mdl"

Two things to remember. First it doesn't matter which game directory it's in if it's in id1 for normal quake or qw for Quakeworld OR it's in the directory specified by the -game command line option to Quake [i.e., with "-game fortress" Quake will look in the Fortress directory]. Second, use a "/" NOT A "\"! Quake interprets a "\" followed by certain characters differently than you might expect. "progs\tf_flag.mdl" looks to Quake like "progs\f_flag.mdl" so just be safe and always use "/" for directory separators.

[Note from DyerMaker]: This is how I put my Abominable Snowman (aka The Shambler) at the info_intermission in ICE LAND 3. Here's the goal for this, right from ICE LAND 3: (Pay attention to the "frame" setting...it's the frame of the model of the Shambler with his arms raised, making it look like he's holding the big white "ICELAND" letters)

How do the tripwires in Rock1 work?

Ok...this is how it works to the best of my knowledge... The "wire" is a teleport trigger with a team_no field. Therefore, when in Team 1's base, a team 2 person crossed the wire the telepotation is triggered, with the destination being the jail cells. The jail doors are the same idea, using a team_no field so that only the local team can open the door. Mail me if you need more clarification. -j3

[Note from Jim Kaufman] "The actual wire you see is a func_illusionary, just there for effect." (thanks for clearing that up, Jim! - >-DM->)

Putting lightning in a map

You need a trigger that will target an 'event_lightning'. The event lightning will set off the bolt between 2 func_doors with a 'target' of 'lightning' and a 'targetname' of 'nothing'. I also add the info_null with a targetname of lightning so I don't get an error message with each compile.

You can only use this in one place on any map.

[Update from Jim Kaufman] You need a trigger_multiple or info_tfgoal with a 'target' of 'flashit' to trigger the event_lighning. - Jim Kaufman

The Buttons on Well6:

Contrary to DyerMaker's page, it is not a button on top of a button (sorry Dyer, I meant to mail you that), but a shootable button that targets the door and a trigger_multiple that targets the door. So it appears you touch the button and open the doors but actually you trigger the trigger. - Jim Kaufman

[Note from Dyermaker] Thanks for clearing this up Jim! That's what I get for not asking, huh? :}

Wad files / Textures

"Instead of mailing that TF mapmakers thingy...i though i'd just ask u..? Where can i get a program that can convert bmps/pcx's to mips???!!?!? I'm having real probs with it coz i juast add the bmp files to wads with 'Qart' and they don't show up in worldcraft =( could u help me out??...please?"

Be sure to read this first, then come back here. Okay, after you've successfully created a .WAD file... Well let's start from the get-go.

Get your .BMP into it's own .WAD file. For example, I want real looking trees, I have a really happy .BMP file, and so I export it as trees.wad. Ok. Good to go, except that WC can't read my mind. So I go under TOOLS then OPTIONS and then TEXTURES in WC. There, I can add my TREES.WAD file.

Now after a while, you're gonna have tons of these little "one texture" wadfiles all over your hard drive. Get MipDip to compile them together. With MipDip, you can load in a texture wad, open another, and then copy>paste it to a different texture wad. Say your main wad file is MYTEXT.WAD. Now open TREES.WAD and click on the one texture there, hit edit>copy, then click on your MYTEXT.WAD window in MipDip, and then edit>paste. Now you can tell Worldcraft not to load the TREES.WAD file any longer, under TOOLS then OPTIONS and then TEXTURES. WC will scream and say some textures you loaded won't be (yadda yadda yadda). As long as you're still loading MYTEXT.WAD, you'll be fine. - DyerMaker

How did you make the alarm System for GoldRush?

"I was just wondering, how the hell did you make the alarm system thing???!!!"

That's a really good question. When I look at Gold Rush now, even though I've made 2 maps since GR and am working on a 3rd since GR, I still shake my head in amazement. I tell you, I don't think I'll try anything that tricky in the near future. It was no picnic, I remember that. And the fact that it works under QuakeWorld is an out-and-out MIRACLE, period.

But, since you're interested, I'll go ahead and explain the goal structure as best I can for ya. Sit down and grab a soda or some coffee, this is going to take a while:

Little gold nuggets down in the mines are all Item Goals that have a group_no, aka group number. They all share the same group number. Let's say the number is 35 just for fun cuz that's my fave number. Ok. All gold nuggets have a group number of 35.

When you take the gold to the vault (inside the bank), there's an Info Goal sitting there waiting for someone to show up with an Item (taken from an Item Goal) who has a group number of 35 (gold nugget). We will call this Info Goal "Bob." There are other Item Goals in the map (such as the other team's money bag). Bob checks to see if the Item a player is carrying around came from an Item Goal that has the right group number (35, gold nugget). The money bags don't even have group numbers (or at least not the same as "35") so Bob completely ignores the fact that you've shown up with that particular Item (money bag). If you show up with a gold nugget, however, then Bob takes the nugget, deposits it into the bank (or so it seems) and gives you your frags... then he waits for another player to arrive, checks the item he's carrying, and on and on.

There is another goal sitting right next to Bob, we'll call him Bill, and his job is to look for arriving players with the item number that corresponds with the enemy team's money bag. This setup is your basic capture the flag / key situation as seen in 99% of TF maps - but, on Mega servers, if the enemy team robs your bank your team loses 10 points and the enemy gains it!

Now, for the goals upstairs in the bank. I recommend you get a piece of paper and a pen :} I worked the goaling system out on paper before attempting this... and it does look good on paper :}

Like Bob, three goals on each bank's second floor (one per pad) are waiting for arriving players to show up with an Item (given from an Item Goal) with a group number of 35. But, unlike Bob, only the first goal (on pad no.1) is currently waiting for an arriving player carrying a gold nugget. The other 2 goals (pads no.2 and no.3) are in the REMOVED state when the map loads. When someone arrives with a gold nugget, all hell breaks loose, hence:

Goal no.1 (sitting on pad no.1) tells an Info Goal (the alarm goal) in the doorway to return from removed state and do its job (sound an alarm when enemy enters bank). It also has to tell yet another goal (that is also sitting on pad no.1) to show itself - that goal's job is to just have a model of a gold nugget, so that newly-joining players know that pad 1 has been activated. Then it tells Goal no.2 to start doing its job. Since Goal no.1 has to tell the "alarm" goal down in the doorway, the "nugget" goal on the pad, *and* goal 2 (who's on pad no.2) to become restored, all these goals share the same group number. So Goal no.1 just restores group no (pick a number). Now, Goal no.1 is told to get gone when done (goal_result of 3) so that he can't reactivate anything, he's done his job, time to rest. He's done a lot, after all :}

Now we have Goal no.2 sitting on pad no.2 waiting for an arriving player with an item from group number (if I haven't lost you yet, that would be "35"). Goal 2 is touched by a player with a gold nugget. Goal 2 places the nugget on the pad by restoring the goal that represents the gold nugget, and also tells Goal no.3 to work now. And Goal 2 has to tell a different goal in the doorway to "hurt" enemy players as they enter the bank. (I'm using restore_group_no again). Then Goal 2 takes his well-deserved vacation.

Now we have Goal 3 on pad no.3 waiting for an arriving player with an item from an Item Goal with a group number of... 35 yes? :} Goal 3 activates the "gold nugget" goal on the pad and also tells a goal in the doorway to give Quad to the home team for 5 seconds. Then Goal 3 goes on holiday.

Duplicate same thing on other side (using different group_no's for those bank's goals) and wha-laa, Gold Rush. - >-DyerMaker->