RTCW & WW
- May 10th, 2010
Return to Castle Wolfenstein Mapping
The following are a list of tutorials, posts, and related notes I have gathered over the years. Where appropriate I have cited credits to original authors, otherwise assume the rest is written by myself.
As with all tutorials, USE AT YOUR OWN RISK. I assume no responsibility for any loss or damages that may occur as a result of using the following tutorials. Exercise common sense and always use Best Practices to ensure your work is properly backed up before you make any modifications.
The following Tutorials apply to RTCW and its MODS, like the WildWest.
| Accums Areaportals Bumpmapping Compiling, How To Console, Useful Commands Corona’s, Using EasyGen Tutorial 1 EasyGen Tutorial 2 Elevators, Multi-Floor Fog Maps, Max Vis, No Hom Hints, Removing Icons from Entities Lightning Bolts |
Models, Useful Info Pitch, Yaw and Angle Player Dimensions Portals and Blocksizes ROQ Videos Scripting Moving Entities Sparklies, bad Staff Car Model Fix Tags on Models Waterfalls Waterfogvars, Fogvar, Skyfogvars |
| Accums
Tutorial and Example Map by: shLep From the scripting definitions doc:
There are two things you can do with Accums. One is to give them a numerical value, the other is to use their current value to decide if a script should run. If you don’t understand scripting at all, you will need to read up on some basic scripting tutorials. However, I can tell you that accums are commonly used for script_movers and/or objectives that need updating (i.e. to prevent them from firing repeatedly). Generally speaking, set your accum to 1 0 at the beginning of your script – which is stating that it is off. Then, in the objective, or script_mover part of your script, you set accum 1 1 – meaning, it is now on. Accums are also needed to end an objective map – to update the game globally. Something like this:
If accum is not set to 1 1, then do not end the match! There IS more to be aware of when working with accums, especially when you get into complex elevator scripts or other scripted movers. But generally speaking, the accums you’ll see in the mp_beach, and mp_base scripts will cover most of what you need. I also would add a word of caution: accums are not always needed, so before you go building your script, riddled with hasty accum calls to the engine, be sure they are needed first! (i.e. try running your map without one) Example Accum Tutorial Map (WildWest) |
| Areaportals
Original Tutorial by: Tunnelram Areaportals are used in a few rare scenarios to increase map performance (i.e. higher framerates). They do this by essentially preventing any part of the map outside the areaportal from being drawn (from the players point of view). Cool right?! Sadly however, it does have it’s limitations. And that is what I will primarily focus on here, as most people fail to get them to work period.
This means if you have four solid walls; with one door, and that door has an areaportal, then you shouldn’t have a problem. However if you add a window to the room then it wouldn’t be contained any longer, and the areaportal won’t be sealing the room and won’t work in the process. I’m sure you’re wondering whether or not they can be used in entities other than func_door and func_door_rotating. As far as I know they can’t. It seems that other entities such as func_explosive and script_movers aren’t able to turn the areaportal OFF. In the end, areaportals can only be used in a few scenarios. I haven’t used them often for the same reasons Tunnleram has cited… Multiplayer is typically better without func_doors to begin with. And the few real doors that you might have in a map, probably aren’t contained anyways… Example Areaportal Tutorial Map (WildWest) |
| Bumpmapping
Originally Posted By: Ydnar, Omnix, demospawn, chavo one & shadowspawn All you have to do is take an image (TGA works best) that is a “standard” RGB encoded normalmap, and add the following to your shader:
It will be spread across the surface with the same mapping as the surface’s texture. For high-resolution lightmaps, I’d recommend using a fine-detail normalmap, and for lightmapped terrain, use a large, blurry normalmap.
An example shader:
Note: This requires a Photoshop plug-in called normalmapfilter. Your shader is going to be a q3map_normalimage used to display the texture properly. You can get the plug in here. Note: If you are using Photoshop 7, you will need this Photoshop 7 Targa fix – Download here. As well, the Photoshop 7.0.1 update contains all functionality included in this revised Targa plug-in, so check what version of PS you are running first. This is important because having the correct Targa plug-in will allow you to create alpha channels, which are needed to create Bumpmapped textures.
Example Bumpmap Tutorial Map |
| Compiling, How To
By: shLep BSP Stage – The BSP stage is Required. You can think of this stage as the wrapper in which your compile will be held and ultimately outputted to a .bsp file. Typically, the only switches used in this stage are -meta, and -patchmeta – which will greatly optimize and speed up your overall compile. In fact, using these switches, you will not need to use any other VIS stage switches. VIS Stage – The VIS stage is often only used for final compiles, and it’s switches have largely become outdated. This stage of a compile creates a BSP Leaf Node tree, which is essentially an index of every leaf (or portal) in your map. Portals are created from numerous sources, the most common are: _blocksize, arrangement of structural vs. detail brushes, and any usage of Hint Brushes. Based on all of these factors, your leaf Node Tree is created and it calculates what is drawn from any given point in a map, but more importantly, it calculates what is NOT drawn from any given point in a map. When we are speaking in these terms, we are really dancing around the topic of Map Optimization. Optimizing a map for an efficient VIS stage should be the goal of any mapper. If done properly it always translates to lower R_speeds (High Framerate), and a typically smaller .bsp file. Map Optimizing is a large subject and one I will have to expand on later. For now, I’ll add that the only useful VIS switch is -saveprt. Saveprt allows you to import the compiled leaf nodes into GTKRadiant’s Portal Viewer, thus allowing you to optimize or otherwise troubleshoot any low Framerate issues your map may have. Light Stage – Without this optional stage, your map will be fullbright with zero shadows and contrast. As the light stage can take awhile, this is ideal for testing purposes, however a final compile should ALWAYS have a Light stage. This final stage has a couple dozen switches available (many of which are now legacy), but generally speaking I typically use a half dozen or so. Because there are so many switches in the Light Stage, I will only explain the ones I use:
Note: These definitions come directly from Q3Map2Build by DLB. Whether you are compiling your map within GTKRadiant, or an external application/process such as Q3Map2Build, you SHOULD be using q3map2.exe by ydnar, a heavily modified version of the original q3map.exe. Q3map2 offers a wide array of switches to utilize. You will want to investigate these further as you move your map closer to a final release. In the meantime, here are the 2 most common set of compile switches that I use. Testing Compile:
Final Compile:
Further Reading 1 Further Reading 2 |
| Console, Useful Commands
The following commands are essential for troubleshooting a map. These console commands are a part of the necessary set of tools mappers use to produce quality maps. Learn them, use them, live them.
Further Reading 1 |
| Corona’s, Using
Original Post by: shLep & demonspawn First of all, coronas like most entities can be triggered on and off via script. This needless to say is neat for any effects you may want to trigger. An example: A factory that when destroyed activates a few coronas placed near a few light textures (the textures themselves have no light property). This way the texture produces a nice glowing effect, dynamically based on event in the game. Furthermore, using func_static, you can swap out “off” textures with “on” textures, to further enhance this effect. Script Example
Coronas can move like any other script_mover, so treat them exactly like one. Assign the targetname to the corona, and make some path_corner’s, script it, and your good to go! Lights for moving vehicles! Yay! Example Coronas Tutorial Map |
| EasyGen Tutorial 1 – Quick and Simple EasyGen
Tutorial by: demonspawn
Select the “base” option and you will now have the ability to adjust the “base noise”, “base smooth” and “base scale” with a value between “0” and “2” Crank the base scale up to 2 and see what you have. A good judge to see the actual height of your terrain is if you have the “draw axis” check box checked then there will be a red and green line across the terrain. At the center of the map will be a red box. This box is the height of a character in RTCW. You now have a pretty good idea how your terrain will look in you map. If you find that you just don’t have the exact shape in any particular area of your terrain you can adjust individual vertices by doing the following: To move your camera view use the following key commands. If you wish to move several vertices at once, change the “modifier” to “LEVEL” (either circle diamond or square) These key commands also work for the other modifiers that are available. Try them out to see what they do… but in general the ones I have explained will allow you to achieve any shape terrain that you want. Applying TexturesSelect the “ALPHAMAP” tab, you will notice that your nice grayscale terrain has now changed to black, not a problem, we’ll fix that in this step. You will now notice at the bottom of the “alphamap” command tab, bitmap images of the texture directory you’ve chosen. Make sure all your textures are the same size (256 X 256 is a good size) as when they are tiled across your terrain. Their tiling can all be increased or decreased and it will make for even tiling. There will be a series of black squares (16 X 16) across the top of the “alphamap” command tab. These will be your material choices. Although the materials won’t show-up when you export your terrain they will give you a good indication as to whet the texture you have associated with them will be. (Ex green material for a “grass” texture) I recommend that you choose only 3 textures for your map, when you get to understand EasyGen better there are ways to get more (I have 5 on my Operation Evil Eye terrain) Sub-step #1
Sub-step #2
Sub-step #3
IMPORTANT So now you have the basics of a terrain for your map. The next step will explain how to import prefabs and how to create holes in your terrain to accommodate buildings and tunnels for your map. Importing PrefabsIf you have a specific build layout that needs to work in unison with your terrain. (i.e. a road that leads into a underground garage, or a overhead walkway that leads to a cave entrance) Then you can easily import these objects into EasyGen and make sure that your ground is ready for them when you export your terrain. Simply select the objects in your map and make them into a prefab.
This will make a prefab of the group of brushes for you to select and import into your map or in this case into EasyGen. The cool thing about this is it will come into EasyGen the same distance away from the center origin of your map as it was saved from allowing you to bring in a template of your map. You may be saying, “I don’t have any of the buildings yet? How is this going to help me?”. I will explain the benefits in a moment. These “pink” poly’s WILL NOT be exported with the terrain leaving holes in your terrain when you see it in Radiant. This will also remove the “shaded 3 texture problem” described above. This won’t seem to useful until you know where you want your holes in your terrain. If you apply your textures with this ability in mind you can maximize your terrain texturing ability. (Think about it, you’ll be surprised when you know what your doing with it, remember I have 5 textures in my map Operation Evil Eye) Easy ExportThe only things you need to change:
Your don’t need to change the metashader’s name or the alphashaders name if you’ve saved your EGN file in the RTCW/main and have selected textures from the RTCW/main/textures directory, they should have the same name as your map. Written by Beau (demonspawn) Sutton. |
| EasyGen Tutorial 2 – A Beach Terrain Example
Tutorial By: TanyaCheex
NOTE: You can lower the contrast to make it smoother. Make sure you save the picture as it is so you can edit it later if need be.
EasyGenOn starting you are asked to set the preferences:
NOTE: Each face can only have 2 textures on it, when you add a third it will turn black to show that there is three textures applied to it, you must paint over the black ones. It gets real annoying sometimes When you have finished painting on the textures:
Any terrain adjustment I do by the heightmap, not in Easygen or Radiant. |
| Elevators, Multi-Floor
Posted By: Paposo To create a multi floor elevator, you can set a single variable such as accum 1. You use bitset with accum 1. Each bit is a floor. So bit 1 of accum 1 is equal to floor 1. Bit 2 is floor 2 etc. That way you can determine which floor the elevator is on. So if the elevator is on floor 3 say “accum 1 bitset 3″. This sets the bit at position 3 to “true” for the variable accum 1. When the elevator leaves floor 3 you say “accum 1 bitreset 3″ This now clears the bit at position 3 so it is now “false”. Using this 1 variable you are now able to determine which floor an elevator is on. Now to determine what floor the door should open on, for instance, you would write a series of functions: trigger floor1 open, trigger floor2 open, etc. At each trigger the first line is now “accum 1 abort_if_not_bitset x” where x is equal to the floor the function is set for. So, if your function is for the doors opening on the 9th floor you would write as the first line “accum 1 abort_if_not_bitset 9″. This allows you to create a single variable which controls all the elevator functions without writing a bunch of scripts for each button. It also avoids scripting conflicts where people are pushing the same buttons simultaneously or such. Example Elevator Tutorial Map Further Reading 1 |
| Fog Maps, Max Vis, No Hom
Posted By: ydnar Added “_foghull” worldspawn key. Use in conjunction with “_farplanedist” to set up fogged maps with max visibility distance and no HOM (Hall of Mirrors). Note this will generate larger visdata on certain maps. This is because the BSP is split on BLOCKSIZE in Z as well as X and Y. This is to make the far plane culling more effective. An Example Fog Shader:
Example Fog Tutorial Map Further Reading 1 |
| Hints, Removing Icons from Entities
Posted By: Tunnelram In most entities you can set this:
You can also set the cursorhint to whatever you want. You can find the listing of them all in the func_invisible_user entity. I like to use the hint_none on things like windows and boards that I want to be breakable, but I don’t want the player to realize it. It makes things a lot more realistic. Example Removing Hint Icons Tutorial Map Further Reading 1 |
| Lightning Bolts
Posted By: DeMoNeYe The original link to this tutorial is now dead. If a duplicate of the original can’t be located I will create another in its place. Example Lightning Bolt Tutorial Map Further Reading 1 |
| Models, Useful Info
Posted By: demonspawn and ydnar Clip ModelsTo Fully Clip your Models, Highlight the model and set the following:
This makes the model fully clipped, so you don’t have to spend all that time with clip brushes, clipping off models. However, I wouldn’t use this on overly complicated models as intense geometry will bog down the engine and adversely affect your map. Entities do not cast shadows (including models)Entities with “model2” models will never receive shadows because they are only referenced in-game, hence “rgbGen lightingDiffuse.” This means they use the lightgrid to determine their coarse ambient + directed illumination. You should also remove the lightmap stage from the first shader. Lightmaps do not apply to MD3 models, especially dynamic (model2) models. Also, add “surfaceparm pointlight” or “nolightmap” to all of your shaders. Further Reading 1 |
| Pitch, Yaw and Angle
Posted By: shLep In scripting you sometimes need to know the faceangles of a script_mover so the object can turn or rotate around any axis. In RtCW, the Yaw, Pitch, and Roll are known as faceangles:
Example Faceangles Tutorial Map Further Reading 1 |
| Player Dimensions
Posted By: shLep
Also, the doors in mp_beach are 112h x 64w x 4d – so it might be a good idea to stick to that to get the correct sense of scale. Example Player Dimensions Tutorial Map Further Reading 1 |
| Portals and Blocksizes
Tutorial By: B0ltyB0y The original tutorial link to this is dead. If I cannot locate a duplicate version I will create a new tutorial in its place. In the meantime, try checking out the Further Reading below. |
| ROQ Video and In Game Videos
Tutorial By: Hewster The original link to this ROQ Creation Tutorial is now dead. Until I find a duplicate version, you can attempt to use the original .roq utility released by id software here. Additionally, you can use the following to play a .roq movie inside a map via a custom texture/shader set:
Note: Be sure to include the texture folder for the final .pk3 And while we’re talking about in game videos or movies, philby added “I would have used a flickering texture for the effect. Like this animation:”
As a final note, you can only have 1 .roq per map. You CAN play 1 .roq video both in the objective overview screen, and “in-game” at the same time, but indeed through my own tests, only 1 given .roq to a map regardless of their subsequent name /folder convention. Example ROQ Videos Tutorial Map Further Reading 1 |
| Scripting Moving Entities
Posted By: Tram Design Members I was in search of a clean approach to scripting out a series of detailed events in my map, namely Aeroplanes that fly, attack, and explode in to buildings – causing further flamed, smoky structural carnage. And yes, all of this with a sound effects track that lined up. I believe it was ultimately Demoneye who came up with the following script, but I could be wrong:
Crashed is highlighted because it is worth note. The crashed plane script_mover is labeled crashed within GTK. In addition, so are the effects entities, such as the smoke and debris. This is one of the main things Demoneye impressed on me… Entities can have the same targetname or scriptname if they are indeed to be fired simultaneously. It helps cut down on some confusion… Play around with it, you’ll see what I mean. script_movers can trigger more script_movers within its own script. And since it is then put on a timeline, events and other things can be arranged through uses of func_static’s, target_smoke and target_effects, etc… They can be triggered from a func_explosive in game, or from another part of the script, or simply on a timer as the one above is. For more details, please see the example map below. Example Scripting script_movers Tutorial Map Further Reading 1 |
| Sparklies, Bad
Posted By: shLep The original notes I had on this subject are missing the pictures, and without them the words fail to fill in the gaps. Until I can find the original tutorial or one similar, please see the further reading below. Further Reading 1 |
| Staff Car Model Fix
Posted By: DeMoNeYe All you’ve got to do is copy mercedes_1.tga to mercedes_1v.tga and use staff_car_v.md3, and put a nice repeating glass texture into glass2.tga to get a working windscreen. All in models/mapobjects/vehicles… Example Staff Car Tutorial Map |
| Tags on Models
Posted By: nib and DeMoNeYe The models have “tags” built into them and you attach the secondary models to these “tags”. For example, in a truck you might have 4 tags, one for each wheel (left_front, right_front, left_rear, right_rear). Then, with your tire model, you would use the targetname of “left front” and when the game ran, it would “attach” the tire model’s origin to the truck model where the “left_front” tag was. Basically, you have to just know what the tags are and, moreover, unless you make your own model, you have no control over where the tags are located. A good example I’ve got is putting some small lantern models (models/mapobjects/light/lantern.md3) that I want to sit on a rotating railway turntable script_mover. I have a “target” of “turntable” on the misc_model entity, and a “targetname” of “turntable” on the script_mover. The models are now attached to the script_mover. They will stay on the script_mover in the same position as you place them relative to the origin of the script_mover. Example Model Tags Tutorial Map Further Reading 1 |
| Waterfalls
Posted By: demonspawn and shLep The downwards water flow is created by adjusting the “tcmod scroll” and the foam is adjusted by a combination of the lake shaders chop and the foam shaders chop or “deformVertexes.” The texture for the foam has a wave displacement built into it. This is a rather big subject as it touches on many facets of mapping. Will the waterfall be accessible by a player? If so, shouldn’t it move the player accordingly? Further, to create a nicely shaped waterfall, shouldn’t the mesh be made from a model? Or will a patchmesh suffice? What about realistic looking spray/mist at the base of the waterfall? Can you use a waterfall in a map that already has fog? Due to all of these questions and more, I will be creating a waterfall tutorial map from scratch. In the meantime, try the further reading below. Example Waterfall Tutorial Map Further Reading 1 |
| Waterfogvars, Fogvar, Skyfogvar
Posted By: demonspawn, omnix and rummie
Fogvar represents a fog that you would walk through; it just covers the ground and can/will disperse when walked through. Remember that fogs are calculated by a single direction, or the direction which it is entered. Some of this may be fact… then again maybe my guess is a bit off. The skyfogvars seem to be RTCW related and seems to not work like the waterfogvars…. I am guessing this is because the q3map does not support it. You can change it. Here is a sample fog I did that will fog the whole level.
In the following example, the numbers in brackets are the RGB values of the fog or the color. I believe that the different types of fog represent the different styles of fog.
RGB values – Red Green Blue. Any color can be defined by these channels. Normally in every application but the Quake 3 engines, these are represented by a number from 0 to 255. In Quake 3 games they are 0 to 1, with 1 being equivalent to 255. The lowest number 0,0,0 is black. The highest number 255,255,255 is white. So let’s say you make a nice color in Photoshop that you want your fog to be tinted. Simply get the RGB color numbers and divide each one by 255 to get your Quake 3 equivalent color. So if I wanted some freaky green fog based on RGB (112, 239, 118) I would do this:
So the value for my fog is:
And that will get you some nasty looking soupy green fog. Example Waterfogvars, Fogvar and Skyfogvars Tutorial Map Further Reading 1 |












No comments yet.