Quake3World.com
https://www.quake3world.com/forum/

AEon's Quake 4 Mapping FAQ - v3.2
https://www.quake3world.com/forum/viewtopic.php?f=10&t=19720
Page 1 of 1

Author:  AEon [ 04-30-2006 10:38 PM ]
Post subject:  AEon's Quake 4 Mapping FAQ - v3.2

AEon's Quake 4 Mapping FAQ

    v3.2 - 32 Q&As, for Quake 4 - 6/23/2006
    Edited by AEon (C) 2006

    (* Marks changes since v0.97)


Intro

    The following FAQ is intended for mappers with Q3A experience, that have decided to start mapping for Quake 4. As you will notice several basic things have changed from Q3A to Q4, notably the real time lighting, the way visibility is handled via Visportals, textures are no longer one simple image but bumpmapped, ... and many other changes. The following will hopefully help to transition from Q3A to Q4 mapping.

    Note: In some cases a short description is not enough to explain the more complex topics, thus links to more in-depth articles are provided.

    Focus: Multiplayer maps are the focus of this FAQ: DM (Death Match), Tourney, TDM (Team Death Match), and CTF (Capture the Flag, later maybe). But the information should also be applicable to other mods.

    Editor: The examples use Quake 4's built in editor, but should also be workable for the latest GTKradiant (v1.5).


    HTML Version: If you prefer a niced-up version of this FAQ, with working Index and Anchors see:


Index

    Getting Started
    • *Setting up Quake 4 for Mapping?
    • *Launching Q4 and the Editor?
    • Configuring Q4 and the Editor?
    • Useful mapping Tools & Mods?
    • How to Build a Map?


    The Basics
    • What are Q4's Heights & Distances?
    • How to Compile a Q4 map?

    • How to apply Visportals?
    • How to properly add lighting?
    • How to add outdoor (ambient) light?
    • *How to Clip MP Maps?


    Movement Related Elements
    • *How to add Respawn points?
    • *How to add Jumppads?
    • *How to add Acceleration Pads?
    • *How to make Teleporters work?
    • *How to add Weapon/Item Spawn Pads?
    • How to build a Ladder?
    • How to build an Elevator?
    • How to add Sliding Doors?


    Detail Elements
    • How to add a Skybox?
    • *Using Q3A Skybox textures in Q4?
    • *How to place Models?
    • How to add basic Fog?
    • *How to add Ambient Sounds?
    • *How to trigger Sounds?
    • How to add simple Terrain?
    • How to add Particle effects?


    Debugging & Finalizing the Map
    • How to Test a MP Map (Console Commands)?
    • How to Debug a Map?
    • How to wrap things up into a pk4?


    Additional Information
    • About the Q4 SDK?
    • Other FAQs & Tutorials?


    FAQ Related
    • *Notation
    • Credits
    • History
    • ToDo List



Getting Started


*Setting up Quake 4 for Mapping?
    Info:
      Long years of Q3A mapping have shown more than once that it is a good idea to install the game you are developing for twice!

      In one folder - the development folder - you install all the mods, editors, SDKs, and custom content (textures, models, etc.), and your different map versions. Usually you also start unpacking parts of Raven's original pak00#.pk4 archives. And if I remember correctly, this can lead to an un-pure local install (prohibiting online play). As you will see the install can get very untidy.

      The other folder - the test / online folder - is basically a clean install of the game that you use to try out the "finished" versions of your map .pk4. It is also the folder you should use to play online.

      Why use a second clean install?
      Because it lets you test your map for potentially missing custom content. A classic for Q3A used to be textures that came with GTKradiant, but were *not* part of the original game, thus would very often be missing in final map packs. Bad! So by simply walking through your map, you now can "see" if your pk4 has every relevant file included. Additionally you can also easily check the console warnings.

    Step by step:
    • Install Q4 from CD/DVD into a folder called Quake4\!

      Important: Raven points out that the default folder for Q4: Quake 4\ (note the space in the folder name), can lead to problems with the compiler or other parts of the editor. It is thus best to avoid installing Q4 in a path that contains spaces!

      E.g. "I:\Games\Quake4\" would be a good place, whereas "I:\Program Files\Quake 4\" would be asking for trouble!

    • Now install the latest Quake 4 Patch (presently 5/4/2006 v1.2).

      Note: Installing the latest patches is recommended, to avoid the hassle of unfixed bugs. Plus most online servers will quickly update to that patch, so that older versions of the game usually will no longer be able to connect.

    • Next make a duplicate of your Quake4\ folder, naming it e.g. Quake4Clean\ (this will be your "Vanilla Q4" test/online install).

    • Should you plan to create your own textures or models, or start work on your own modification (MOD) install the latest version of the Quake 4 SDK (v1.2) into your Quake4\ development folder.

    • Next you would go about running Q4 from both installs, setting up your key bindings and preferred game resolutions. E.g. create an q4base\autoexec.cfg file with key bindings.

    • Another interesting install for mappers is the Q4 Debug Mod that provides a powerful HUD (Heads Up Display) for Debugging your map. Install this in your Quake4\ folder as well or if you like into a parallel folder, i.e. Quake4SDK\.

    • Optionally you might like to install the community editor GTKradiant v1.5, as an alternative to Q4's built in editor. Again install its files in Quake4\.

      Tip: Next read up on the "Launching Q4 and the Editor?" Q&A and the "Configuring Q4 and the Editor?" Q&A.

      Downloads: See the "Useful mapping Tools & Mods?" Q&A to get the Q4 Debug Mod, the SDK, and GTKradiant.



*Launching Q4 and the Editor?
    Info:
      There are quite a few very convenient console commands that let you run Q4 with various options set on launch. A mapper will want to have at least *two* icons on his desktop, one to launch Q4 and another one to directly launch the Editor.

    Step by step:
    • Under XP Right-click on your Q4 icon on the Windows desktop.

    • Select Properties.

    • Under Target you should read something like "I:\Games\Quake4\Quake4.exe".

    • Now add (omit the // comments) to the command line:
      Code:
      +set com_allowconsole 1            // Allow cheats
      +set win_allowMultipleInstances 1  // Q4 copies
      +disconnect                        // No movies
             

    • This allows the use of cheats and will also skip the "annoying" startup movies.

      E.g.: "I:\Games\Quake4\Quake4.exe" +set com_allowconsole 1 +disconnect

      Tip: If you own very high-end hardware you might like to run Q4 twice. Once as editor and once to test your map in parallel. And switch between the copies via the system's Alt + Tab. For this use the +set win_allowMultipleInstances 1 parameter.

      Note: Tests show that you cannot run the game and the editor from the same Quake4\ folder, you need two installs of Q4 for this to work. A classic use, to run a dedicated server and the game from one folder is not possible either.

    • Make a copy of the Q4 icon, specifically to directly launch the Editor.

    • This time add (again omitting the // comments):
      Code:
      +set com_allowconsole 1  // Enable cheats
      +set r_mode <#>          // Set editor resolution
      +set r_fullscreen 0      // Editor in window mode
      +set r_brightness 1      // Fix desktop brightness
      +set r_multisamples 0    // Turn off Anti Aliasing
      +vid_restart             // Update changes
      +wait                    // Should the editor not
                               // start add several
                               // +wait commands
      +editor                  // Launch editor
                

    • The above turns off full screen mode (the editor needs to be run in window mode), corrects Q4's default brightness from 1.2 to the normal desktop brightness of 1, turns off Anti Aliasing (avoids grid blurring), performs a video restart, and launches the editor. For some folks that editor does not start properly with the above set of parameters, should that happen try adding one or more +wait commands.

      E.g.: "I:\Games\Quake4\Quake4.exe" +seta com_allowConsole 1 +set r_fullscreen 0 +set r_brightness 1 +set r_multisamples 0 +vid_restart +editor

      Tip: With +set r_mode <#> you set the render mode <#> from 3 (640x480) to 8 (1600x1200).

    • While you are at it run the software that controls your Graphics Card and turn off Anti Aliasing (AA). Q4's Editor at times crashes with AA enabled plus will badly blur the grid lines of the editor's 2D-views!

      Tip: For users of ATi cards, Right-click on your Windows desktop, and select the ATi Control Center, and under the Graphics Settings tab, 3D, Anti Aliasing, check "Let the application decide".

      Note: Also ensure AA is turned off in Q4! I.e. run Q4, via Settings menu, System, Video Settings, Advanced Settings, turn Antialiasing off.

      Tip: As an alternative you can turn off AA from the console with r_multisamples 0.

    Links:



Configuring Q4 and the Editor?
    Intro:
      As mapper you will need at least 2 configurations: One .cfg that lets you play (basics) *and* test/debug the various aspects of the game (e.g. mapping.cfg), and one specifically for online multiplayer games (e.g. mp.cfg).

      Why the need for different configurations?
      Because when mapping you will run everything at desktop resolution (i.e. editor) and probably pretty much at the best quality level your hardware can handle. Doing so will yield a better feeling for how your map "should" look, when you run Q4 from editor via F2-key.

      On the other hand when playing online, you will probably want to turn down all the graphics settings (low quality), lower the resolution, and also want special key bindings for online play (e.g. mod specific, or chat messages).

      Using these two configurations lets you change between them easily, and your multiplayer settings will also come in handy testing your map at *low* settings.

    Info:
      Q4 automatically executes the configuration file q4base\autoexec.cfg, so for simple scripting needs putting all the bindings and commands into this file will be a good start. E.g. place everything that is shared by both cfg files (mapping.cfg and mp.cfg) in the autoexec.cfg.

      Comment: I use the 3 mouse buttons, W, A, S, D movement keys, and the keys 1 to 0, Q, E, R, T, F, C, X, Y, Shift, Ctrl, Space as shortcuts to bring up weapons directly. But all the keys to the right of the keyboard are free to bind. (AEon)

    The mp.cfg:
      Primarily the default function keys for voting, plus several chat bindings that come in handy.
      Code:
      // MP Colored Nick Name
      // --------------------
      // ^0 Default ^1 Red   ^2 Green
      // ^3 Yellow  ^4 Blue  ^5 Cyan
      // ^6 Pink    ^7 White ^8 Gray
      // ^9 Black
      seta ui_name "^1^^3AEon^1^^0"

      // MP Chat Messages (fun)
      // ----------------
      // ^0 resets colors to default console/HUD color
      bind "h" "say '^7...^3Hi EvErYoNe^7... 8-)^0'"
      bind "m" "say '^7...^3ShMiLe^7... :)^0'"
      bind "j" "say '^7...^3WheEeEeEe^7... 8-))^0'"
      bind "k" "say '^7...^3ThAnKs^7... :-)'"
      bind "l" "say '^7...^3LaTeR fOlKs^7... :o)^0'"
      bind "i" "say '^7...^3AaArRrHhHgGg!^7...^0'"
      bind "n" "say '^7...^3NiCe OnE^7... :-P^0'"
      bind "o" "say '^7...^3OuChiLiE^7... :-|^0'"
      bind "p" "say '^7...^3OoOoPpPsSs^7... :D^0'"
      bind "u" "say '^7...^3SoRrY^7... :-)^0'"

      ...more coming soon...
            


    The mapping.cfg:
      Debug bindings...
      Code:
      ...coming soon...
            




Useful mapping Tools & Mods?
    Info:
      Even though most of what a mapper needs comes out of the box, i.e. is part of the Quake 4 retail game, a few additional downloads should make life easier.

    Downloads:
    • Quake 4 Debug HUD @ iddevnet.com
      Info: Very useful "official" Debug mod for Q4 from Raven.

    • GtkRadiant 1.5.0 beta - build 03-02 @ qeradiant.com
      Info: Powerful community developed editor, Q3A mappers will already know it.

    • Quake 4 SDK @ iddevnet.com
      Info: Everything you need to create your own custom Models and Textures, etc.

    • Map Rotator @ wfrevolution.com
      Info: Tool makes it easier to mirror CTF levels.

    • Tools & Utilities List @ quake3bits.com
      Info: MD5/MD3/ASE Importers & Exporters (Viewers) and Misc Tools.



How to Build a Map?
    Info:
      If you are totally new to mapping, many of the Doom 3 based tutorials should get you started, since D3 and Q4 basically use the same engine and editor.

    Links:





The Basics


What are Q4's Heights & Distances?
    Info:
      Every id game slightly changes the player height, the maximum jump height and jump distances, the maximum height of steps etc.

    Step by step:
    • Coming up (***).



How to Compile a Q4 map?
    Info:
      Compared to Q3map2, the options of Q4's compiler dmap are less complex, and since neighter visibility nor light need to be compiled, the compile process can easily be triggered via menu. Compile times are usually measured in seconds.

    Step by step:
    • Create a leak-free room with a player respawn (info, info_player_deathmatch).

    • Start the BSP compile (Bsp menu, bsp).

    • You can now test the map in-game via F2-key.

    Links:



How to apply Visportals?
    Info:
      Q3A used hint brushes to manipulate visibility, but that whole slew of ugly chopping apart of vis trees is a thing of the past. Q4 uses something simpler that can be calculated in real time: Visportals.

      Basically what this does: Imagine 2 rooms with a doorway connecting them. You place a brush that completely fills out the doorway, and place the Visportal "texture" on brush face that covers the doorway. Now when you stand in room 1, but cannot see the doorway in your field of view, room 2 will not be rendered. Thus optimizing FPS.

      Important: Walls will *not* autoclip the view like in Q3A, you need to make every area "airtight" with Visportals!

    Step by step:
    • Place brushes that cover your doorways or windows, these will become the Visportal brushes.

    • *One* face will become the Visportal, completely sealing the gap (Zones must be airtight!).

    • Select the brush with Shift + Left-click.

    • And apply textures/common/nodraw to make all faces invisible.

    • Select the chosen Visportal face with Ctrl+Shift + Left-click in the 3D view to select one face.

    • Finally apply the textures/editor/visportal texture to create the portal.

      Warning: Visportals segment all triangles they are in contact with, generating extra polygons!

      Testing: You can test the workings of Visportals with the console command r_showPortals 1 (0 to turn this off). This will draw all Visportals, green means an open portal and red a closed portal.

    Links:



How to properly add lighting?
    Links:
    • Lighting Tips @ map-center by Raven
      Info: Another must read on Lighting by the makers of Q4.

    • r_lightdetaillevel [n] @ quake3bits.com by Kat
      Info: Show specific lights only at defined "Quality Settings".

    • 'Overbright' Lights @ quake3bits.com by Kat
      Info: At times you may want to make a commonly used light brighter without much fuss.



How to add outdoor (ambient) light?
    Info:
      Lighting in Q4 is less trivial than in Q3A, especially since many overlapping light sources will very much slow down the frame rate, but luckily Raven provided ambient light shaders.

    Step by step:
    • Right-click on 2D-view, and add a light entity that covers the complete map.

    • Press J-key to open Light Editor dialog.

    • Uncheck Cast checkboxes, except Cast Diffuse.

    • From the texture scrollbox pick lights/ambientlight_nofall.

    • Pick an Ambient Color, close to black (e.g. dark gray).

    • Test effect on map.

    Links:



*How to Clip MP Maps?
    Info:
      While building your MP map, it is a good idea to cover / simplify the geometry for the players via clips to avoid them getting stuck.

      In Q3A this was especially useful (botclip) to optimize the map for AI. And apparently custom bots exist for Q4 as well.

      Note: I am aware of the Oak Bots, these seem to work well enough with player_clip but Raven recommends the usage of clip. It was proposed that monster_clip should work much like Q3A's botclip, but is does not. monster_clip actually breaks the bot movement!

    Step by step:
    • Anything the player might get stuck on, e.g. a painting on a otherwise flat wall, should be covered with a clip, a brush that covers the wall plus the frame of the painting.

    • Select the brush that you want to use for clipping with Shift + Left-click.

    • Pick the texture from the Media tab (M-key):

    • Click textures/common/clip texture, to apply it.

      Note: There are several other clip textures. But for the most part these will not be used much in for MP maps. For details read Clipping Your Level.

      Important: Raven uses textures/common/player_clip in it's MP maps, this is discouraged though, use clip as suggested above instead!

    • The player should no longer get stuck on that wall now.

      Tips: Raven suggests ramp-clipping stairways, to allow for ramp-jumping.

    More examples of clipping:
    • Typical examples of clipping are patches. It is almost always a good idea to cover rounded corners with multi-sided clip brushes. Especially because bots in Q4 get suck in patches!
    • Cover complicated geometry, e.g. sculptures with one big clip brush.
    • Close off map areas you do not want to player to reach with clipping.
    • Add small ramps to areas where a player might get stuck.
    • Most corners and even more so columns and frames should be clipped with 45 degree angles, to avoid the player getting stuck.

    Links:
    • Clipping Your Level @ iddevnet.com
      Info: Complete list if clipping textures, plus SP and MP tips for clipping.

Author:  AEon [ 04-30-2006 10:40 PM ]
Post subject: 

Movement Related Elements


*How to add Respawn points?

    Info:
      Before you can play test a multiplayer map, you will need to tell Q4 where players should respawn. There is an entity for Death Match, and two more for the different CTF team respawns (***).

    Step by step:
    • Right-click on 2D-view, and add a info, info_player_deathmatch entity for a Death Match respawn.

      Note:: It is a good idea to also add info, info_player_start. Not only does Q4 at times use this single player respawn point, but Q4's editor will place the CAM (3D) view there after loading a .map file.

    • Place the entity exactly on the floor of your map's "room".

    • Be sure to give the respawn entity a proper orientation (angle Key under Entity tab). The angle defines the direction the player faces after respawning from this entity! Shown as white arrows in the editor's CAM view.



*How to add Jumppads?
    Info:
      Jumppads and Acceleration pads are quite similar. In the case of the JPs the player is thrust up more than horizontally though.

    The Model:
    • Right-click in 2D-view, and select New Model... to create a func_static object.
    • Pick the TP model models/mapobjects/multiplayer/jump_pad/jump_pad_color.lwo.
    • This creates the new Key model in the Entity tab (N-key).
    • Add the following Key, Val (value) pairs in the Entity tab:
      • solid, 0
      • noshadows, 1
      • noclipmodel, 1
      • angle, 90
        Optionally defines the orientation of the model.
      • _color, <R> <G> <B>
        Colorize the model with explicit normalized RGB values. E.g. 1 .7 .1 for orange. Possible because of the special _color.lwo model version used.
    • Place the model flush to the ground.

    Decal under jumppad model:
    • Create a 128x128 unit brush (XY Top view).
    • Turn it into Patch menu, Simple Patch Mesh, Width/Height: 3x3.
    • Under Media tab, Textures, choose textures/command_ship/cs_prisonpipecapt
    • Patch Properties (Shift + S), Fit button, Done.
    • Place the decal patch exactly under JP model, flush with the floor.
    • Then turn on Grid 0.25, Shift + 3 and up the decal in Z-axis by one grid unit with Numerical Keypad +.
    • This places the decals "just" above the ground.

    Cushion Model:
    • Some JPs will push the player up quite a distance and it has become a good mapping tradition to cushion the area around the JP model to let the player drop without losing health.
    • Create a 128x128 unit brush in XY-view, with a height of 1 unit that centers on the JP model, and is placed flush to the floor.
    • From the Media tab cover the brush with textures/common/cushion.

    The JP effect:
    • Right-click in 2D-view, and select func, func_fx a new effect entity.
    • Center the entity in XY-view over the model, center of entity has same height as floor, i.e. sticks out by 8 units.
    • Change the properties of the still selected object, via Entity tab (N-key) and add the following Key, Val pairs:
      • fx, effects/mp/jumppad_color.fx
      • loop, 1
      • remove, 0
      • start_on, 1
      • angle, -1
        Upward direction.
      • _color, <R> <G> <B>
        Colorize effect with explicit normalized RGB values. E.g. 1 .7 .1 for orange.

    The Trigger brush:
    • Create a 8-sided brush (Brush menu, 8 sided; Ctrl + 8) the size of the JP model, with a height of 16 units.
    • From the Media tab cover the brush with textures/common/trigmulti.
    • Right-click in 2D-view, and select func, func_jumppad to turn the brush into a jumppad.
    • Optionally change the properties of the selected object, via Entity tab (N-key) and add the following Key, Val pairs:
      • fx_jump, effects/mp/jumppad_trigger_color.fx
        This uses the colorizable version of the JP "bounce" effect.
      • _color, <R> <G> <B>
        You can now colorize the effect that is triggered every time you step on the trigger. Default is a red-ish tone, try e.g. 1 0.7 0.1 for orange.

    JP Destination:
    • Right-click in 2D-view, and select target, target_null to create the JP trajectory destination point.
    • In MP the JP destination usually "floats" about one block (64u) above the edge of the destination floor level.
    • Deselect everything (Esc-key).
    • Select (Shift-click) the func_jumppad brush first, and then select the target_null entity.
    • Connect the objects with Ctrl + K (or via Selection menu, Connect entities).
    • A yellowish line with arrow should connect the trigger brush and the entity.

    JP Light:
    • Right-click in 2D-view, and select light to add a light source for the TP effect.
    • Size the light volume (pink outline) to cover a volume slightly larger than the JP model in XY and reach up from floor to upper JP level.
    • Open the Light Editor via J-key and try the following setup:
      • Radius X 64 Y 72 Z 160
      • Fall-off 0.0
      • Center X 0 Y 0 Z -144
        Light's origin originates from below.
      • Cast Shadows and Cast Dynamic Shadows off
      • Cast Diffuse and Cast Specular on
      • Color RGB 255 178 25 (orange = color of effect)
      • Detail Level 5
        This is an optional decorative light!
      • Texture, none
      • Apply, OK
    • Center of light is about 64 units above the center of the JP model (depends on JP height).



*How to add Acceleration Pads?
    Info:
      Basically Acceleration Pads are Jumppads with a much stronger horizontal impulse on the player. Traditionally Q4 also uses a different model and effect for the APs.

    The Model:
    • Right-click in 2D-view, and select New Model... to create a func_static object.
    • Under models/mapobjects/ pick the AP model multiplayer/acceleration_pad/acceleration_pad_color.lwo.
    • This creates the new Key model in the Entity tab (N-key).
    • Add the following Key, Val (value) pairs in the Entity tab:
      • solid, 0
      • noshadows, 1
      • noclipmodel, 1
      • angle, 90
        Defines the orientation of the model.
      • ( inline, 1 )
        Q4DM1 inline's the AP models, usually not done though.
      • _color, <R> <G> <B>
        Colorize the model with explicit normalized RGB values. E.g. 1 .7 .1 for orange. Possible because of the special _color.lwo model version used.
    • Place the model flush to the ground.

    Model Clip:
    • Since usually the models added to MP maps are not clipped, the player can walk right through them. For a Teleporter this is fine, but for a AP you should give the player something solid to walk on.
    • Create a wedge-shaped brush the size of the AP model, mimicking it's ramping.
    • From the Media tab cover the brush with textures/common/full_clip.
    • You can now "walk on" the AP model.
      Note: The trigger brush will cover most of the AP model, so you will not actually be able to walk on it, but the model should present an obstacle for rockets and the like.

    The AP effect:
    • Right-click in 2D-view, and select func, func_fx a new effect entity.
    • Center the entity in XY-view over the model, and place the entity 32 units away from the foot end of the model, and 16 above the ground.
    • Change the properties of the still selected object, via Entity tab (N-key) and add the following Key, Val pairs:
      • fx, effects/mp/accelpad_color.fx
      • loop, 1
      • remove, 0
      • start_on, 1
      • rotation, -0.242 0 -0.970 0 -1 0 -0.97 0 0.242
      • _color, <R> <G> <B>
        Colorize effect with explicit normalized RGB values. E.g. 1 .7 .1 for orange.

    The Trigger brush:
    • Create a brush the size of the AP model, that ramps up and sticks out on top by about 8 units.
    • From the Media tab cover the brush with textures/common/trigmulti.
    • Right-click in 2D-view, and select func, func_jumppad to turn the brush into a "jumppad".
    • Optionally change the properties of the selected object, via Entity tab (N-key) and add the following Key, Val pairs:
      • fx_jump, effects/mp/jumppad_trigger_color.fx
        This uses the colorizable version of the AP "bounce" effect.
      • _color, <R> <G> <B>
        You can now colorize the effect that is triggered every time you step on the trigger. Default is a red-ish tone, try e.g. 1 0.7 0.1 for orange.

    AP Destination:
    • Right-click in 2D-view, and select target, target_null to create the AP trajectory destination point.
    • In MP the AP destination usually "floats" about one block (64u) above the edge of the destination floor level.
    • Deselect everything (Esc-key).
    • Select (Shift-click) the func_jumppad brush first, and then select the target_null entity.
    • Connect the objects with Ctrl + K (or via Selection menu, Connect entities).
    • A yellowish line with arrow should connect the trigger brush and the entity.



*How to make Teleporters work?
    Info:
      Teleporters in Q4 not only transport players instantly but also Nailgun bullets, Rockets, Grenades and Plasma balls (Hyperblaster).

      The Q4 teleporters are made up of several parts, some mandatory like the trigger and the destination, the rest are nice visual clues for the player: The Teleporter model, a simply patch mesh decal, a trigger brush, a teleporter destination, a teleporter effect, and possibly a teleporter ambient sound and light.

    The Model:
    • Right-click in 2D-view, and select New Model... to create a func_static object.
    • Pick the default TP model models/mapobjects/multiplayer/teleporter.lwo.
    • This creates the new Key model in the Entity tab (N-key).
    • Add the following Key, Val (value) pairs in the Entity tab:
      • solid, 0
      • noshadows, 1
      • noclipmodel, 1
    • Place the model flush to the ground.

    Decal under teleporter model:
    • Create a 128x128 unit brush (XY Top view).
    • Turn it into Patch menu, Simple Patch Mesh, Width/Height: 3x3.
    • Under Media tab, Textures, choose textures/command_ship/cs_prisonpipecapt
    • Patch Properties (Shift + S), Fit button, Done.
    • Place the decal patch exactly under TP model, flush with the floor.
    • Then turn on Grid 0.25, Shift + 3 and up the decal in Z-axis by one grid unit with Numerical Keypad +.
    • This places the decals "just" above the ground.

    The TP effect:
    • Right-click in 2D-view, and select func, func_fx a new effect entity.
    • Center the entity in XY-view over the decal, and place it about 64 units (1 block) above the ground in Z-view.
    • Change the properties of the still selected object, via Entity tab (N-key) and add the following Key, Val pairs:
      • fx, effects/mp/teleporter.fx
      • loop, 1
      • remove, 0
      • start_on, 1
      • angle, 180
        Should point out of the TP, exactly toward entering player. Stick with right-angles 90, 180, 270 or 360!
      • rotation, 1 0 0 0 1 0 0 0 1
      • _color, <R> <G> <B>
        Colorize effect with explicit normalized RGB values. E.g. 1 .7 .1 for orange, will colorize the effect.
    • Place the model flush to the ground.

    The Trigger brush:
    • Create a brush the size of the trigger you want to use as a relay. E.g. 128u high, and 128u wide, approximately as deep as TP model.
      Note: The brush should be at right angles, not skewed in any way.
    • From the Media tab cover the brush with textures/common/trigshotclip.
    • Right-click in 2D-view, and select trigger, trigger_multiple to turn the brush into a trigger.
    • Change the properties of the still selected object, via Entity tab (N-key) and add the following Key, Val pairs:
      • anyTouch, 1
      • projectile_trigger, 1
        Rockets will pass the TP.
      • wait, 0

    TP Destination:
    • Right-click in 2D-view, and select info, info_player_teleport to create a TP destination object.
    • Change the properties of the still selected object, via Entity tab and add the following Key, Val pairs:
      • angle, 180
        Defines direction the player will face after exiting destination.
        Must be multiples of 90 (90, 180, 270, 360), or else projectiles will not pass the TP.
    • In MP the TP destination usually "floats" one block (64u) above floor and about one block away from a TP behind you, or a wall.
    • Deselect everything (Esc-key).
    • Select (Shift-click) the trigger_multiple brush first, and then select the info_player_teleport entity.
    • Connect the objects with Ctrl + K (or via Selection menu, Connect entities).
    • A redish line with arrow should connect the trigger brush and the TP destination.

    TP Light:
    • Right-click in 2D-view, and select light to add a light source for the TP effect.
    • Size the light volume (pink outline) to cover a volume slightly larger than the TP, reaching into the room.
    • Open the Light Editor via J-key and try the following setup:
      • Radius X 136 Y 96 Z 136
      • Fall-off 0.0
      • Center X 32 Y 0 Z 0
        In XY-view covers center of TP model
      • Cast Shadows and Cast Dynamic Shadows on
      • Cast Diffuse and Cast Specular on
      • Color RGB 255 178 25 (orange = color of effect)
      • Detail Level 10
        This is not an optional decorative light, 10 = show always!
      • Texture, lights/grenade_flicker
      • Apply, OK
    • Center of light, about 32 units outward of model center and about 1 block (64u) off the floor.

    Tips:
      Important: Teleporters in Q4 have to be at right (90-degree) angles to make the transport of projectiles like Rockets work properly!

      Comment: I'd open Q4DM1 in editor and copy/paste the parts of the teleporter into my own map and edit those.

    Links:
    • Teleporting @ doom3world.org by just1n
      Info: Doom 3 tutorial on teleporters.



*How to add Weapon/Item Spawn Pads?
    Info:
      It is a good idea to make it easier for players to remember where weapons or valuable items (pickups) spawn, via visual indicator or pad. Raven calls them MP Bases.

    The Model:
    • Right-click in 2D-view, and select New Model... to create a func_static object.
    • As MP base you can either pick the round models/mapobjects/multiplayer/mpbase_round.lwo model or the more techy
      models/mapobjects/multiplayer/mpbase_hard_edges.lwo model.
      Comment: I use the latter model as weapon bases and the former as armor / mega health respawn points.
    • This creates the new Key model in the Entity tab (N-key).
    • Add the following Key, Val (value) pairs in the Entity tab:
      • solid, 0
      • noshadows, 1
      • noclipmodel, 1
    • Place the model flush to the ground.

    Decal under weapon base:
    • Create a 48x48 unit brush (XY Top view).
    • Turn it into Patch menu, Simple Patch Mesh, Width/Height: 3x3.
    • Under Media tab, Textures, choose. textures/command_ship/cs_prisonpipecapt
    • Patch Properties (Shift + S), Fit button, Done.
    • Center the decal patch exactly under model, flush with the floor.
    • Then turn on Grid 0.25, Shift + 3 and up the decal in Z-axis by one grid unit with Numerical Keypad +.
    • This places the decals "just" above the ground.

    The TP effect:
    • Right-click in 2D-view, and select func, func_fx a new effect entity.
    • Center the entity in XY-view over the decal, and place it so that 8 units stick out of the ground and 8 units are hidden in the ground.
    • Change the properties of the still selected entity, via Entity tab (N-key) and add the following Key, Val pairs:
      • fx, effects/mp/item_holo.fx
      • loop, 1
      • remove, 0
      • start_on, 1
      • angle, -1
        The -1 points in "up" direction.
      • _color, <R> <G> <B>
        Colorize effect with explicit normalized RGB values. Not set by default.

    Weapon / Item:
    • Right-click in 2D-view, and select a pickup, weapon or pickup, powerup you would like to put on the MP base.
    • Place item's center (red dot in model), 16 units above the center of the MP base model.
    • Change the properties of the entity, via Entity tab and add the following Key, Val pair:
      • nodrop, 1
        This ensures the item does not drop to the floor, but floats.



How to build a Ladder?
    Info:
      Again not really part of normal multiplayer maps, but some old-school designer might use them.

    Step by step:
    • Create a brush to be your ladder.

      Tip: The Visual part of the ladder can be anything, brush-work or a model.

    • Create another brush slightly larger than the size of your ladder.

    • Pick the texture from the Media tab (M-key):

    • Click textures/common/ladder, to apply it to the brush.

    • Place the brush so that it covers your ladder object.

      Note: With this method you can make anything climbable, but try to give the player a hint that this is indeed the case.

    Links:



How to build an Elevator?
    Info:
      Even though Elevators are not really required in Q4, due to Jumppads, folks might like to go old-school anyway.

    Step by step:
    • Build a room, with an upper level area you want reach via elevator platform.

    • As elevator platform you can pick anything you want, i.e. a Brush, a Patch or Model. In this case simply create a brush.

    • Pick a texture from the Media tab (M-key).

    • Open the Surface Inspector (S-key), and click the Fit button under Texturing. Press OK to close the dialog.

    • Move the platform brush to the top level, i.e. flush with the upper level floor.

    • Count the units between lower edge of the platform brush and the floor. The 2D-view grid in side view (Ctrl + Tab) should help.

      Note: This height value defines how much the platform will move up and down.

    • Right-click on 2D-view and pick func, func_plat to turn the brush into a "moving" platform.

    • Open Entity tab (N-key).

    • Add Key "height" with Val "<height>".

    • Instead of <height> enter the height in units you just measured.

    • This should respawn the platform at the bottom level when you run the game.

      Note: You may need to experiment with the height a bit.

    • Do a BSP compile (Bsp menu, bsp), and test it in-game (F2-key).

      Comment: I am not fully sure this actually works in Q4, needs testing! (***)

    Links:



How to add Sliding Doors?
    Info:
      Another more old-school map element.

      Comment: Personally I avoid using doors in MP maps, but a sufficiently complex map may require dynamic control of Visportals via doors.

    Step by step:
    • Create a brush that is to be your door, and texture (e.g. from textures/base_door) it.

    • Use a trim texture for the door sides (e.g. from textures/base_trim).

    • Right-click on 2D-view and select func, func_door (to turn the selected brush into a door).

    • Open Entity tab (N-key)

    • Change Key "wait" to Val "1"

    • Add Key "speed" with Val "30"

    • Add Key "movedir" with e.g. Val "270"

      Tip: Define direction via 8 'direction buttons' at the bottom left of the dialog.

      TODO: Link door to Visportals (***)?!

    Links:





Detail Elements


How to add a Skybox?
    Info:
      A Skybox is basically a set of 6 textures placed on the inside faces of a cube. But obviously you could also cover just one brush face for a "window".

    Step by step:
    • Create the brush-work for the areas where you want to see the skybox.

    • Select the brush faces (Shift+Ctrl+Alt + Left-click).

    • Pick a skybox texture from the Media tab (M-key):

    • E.g. click Textures/textures/skies/commoutside, to apply it to the faces.

      Note: Apply the skybox textures only where they make sense! E.g. do not apply it to a wall in the middle of the room.

    Links:



*Using Q3A Skybox textures in Q4?
    Info:
      The skyboxes in Q3A and in Q4 are basically a 360 (up /down as well) view of the world mapped onto 6 orthogonal textures that are placed on the inside faces of a cube. Though Q4 has some interesting skyboxes, you might prefer using the nice skyboxes created for Q3A.

      To make this work you will need a special "skybox" shader and abide to the new filename conventions for skybox textures introduced by Q4.

    Example Q4 Skybox Shader:
      Material: The skybox shader should be placed your map's material file q4base\materials\<mapname>.mtr (e.g. q4base\materials\aetri.mtr).

      Location: Abiding to Q4's folder structure place the 6 skybox textures (image files) in q4base\gfx\env\.

      Naming: Replace the below <skybox> tag with the name of your skybox files, i.e. with q4base\gfx\env\iceflow_up.jpg you should name <skybox>: iceflow.

      Shader: Give the your skybox shader a unique name by replacing below <mapname> tag with the name of your map, e.g. textures/aetri/skybox.

      Code:
      // Skybox code based on Raven's:
      //      textures/skies/Red_Sky
      // e.g. textures/aetri/skybox
      textures/<mapname>/skybox
      {
        qer_editorimage   textures/editor/sky.tga
        noFragment
        forceOpaque
        noimpact
        noshadows
        {
          blend           add
          // e.g. gfx/env/iceflow
          cameraCubeMap   gfx/env/<skybox>
          texgen          skybox
        }
      }
            


    Q4 Skybox Filename Convention:
      Format: Skyboxes usually are available in .tga format, and many Q3A mappers will use the .jpg versions to cut down the file size. Q4 seems to understand both image formats, though Raven prefers to use full quality 1024x1024 pixel .tga images.

      Location: Usually the Q3A environment textures (skyboxes) will reside in baseq3\env\aedm7\<skybox>_<tag>.tga, you will want to move them into the Q4's default skybox folder: q4base\gfx\env\.

      Rename: To make the skybox textures work in Q4, you need to rename the Q3A files in the following manner:

      Code:
        Q3A Name            Q4 Name
        --------            -------
        <skybox>_bk.tga     <skybox>_left.tga
        <skybox>_dn.tga     <skybox>_down.tga
        <skybox>_ft.tga     <skybox>_right.tga
        <skybox>_lf.tga     <skybox>_back.tga
        <skybox>_rt.tga     <skybox>_forward.tga
        <skybox>_up.tga     <skybox>_up.tga
            


    Using the Custom Skybox:
      In Q4's editor, simply pick the textures/<mapname>/skybox shader from the Material tab, and apply the texture on all the brush faces you want to turn into the skybox.



*How to place Models?
    Info:
      You can take advantage of the way modern graphics cards are optimized to draw many instances of the very same object. UT2003 calls them Static Meshes, here they are simply called models. If you take a closer look at some of Ravens maps you will notice that certain decorative geometry is placed as models. E.g. the metal beams near the ceiling in all corridors of Q4DM1.

    Step by Step:
    • Right-click in 2D-view, and select New Model... to create a new func_static object.
    • Pick the model you would like to add from the browser, usually under models/mapobjects/ and models/mapobjects/multiplayer/.
    • This creates the new Key model in the Entity tab (N-key).
    • Keys let the mapper define certain models characteristics. Typically the clipping for models will be turned off because they can take up too much resources, i.e. the collision model is too complex. E.g. Jumppads, Acceleration pads and Teleporters are not solid.
    • Often used Key, Val (value) pairs applied to models:
      • solid, 0
        Player can walk through model.
      • noshadows, 1
        Model will not cast shadows.
      • noclipmodel, 1
        Model clipping turned off.
      • angle, 90
        Defines the orientation of the model.
      • _color, <R> <G> <B>
        Colorize the model with explicit normalized RGB values. E.g. 1 .7 .1 for orange. For some models there is a special _color.lwo model version available.
      • inline, 1
        Q4DM1 inline's the AP models, usually not done though. (***)



How to add basic Fog?
    Info:
      Q4 handles fog a bit differently than Q3A, here it actually is a light source.

    Step by step:
    • Right-click on 2D-view, and add a light entity to the map.

    • Press J-key to open Light Editor dialog.

    • Under Texture, pick fogs/basicfog.
      (*** There is not fogs/ folder in Q4. Where are the fog materials?)

    • Click Color button and select a color for the fog.

    • By changing the size of the Radius, you control the size of the area the fog will cover.

    • Click Apply and OK buttons to close the dialog.

    • Open Entity tab (N-key)

    • Change Key "shaderParm3" to Val "<density>"

    • Instead of <density> enter fog density value.

      Tip: High values = *less* fog density. E.g. try a value of 10000 for interesting fog.

    • Hit F7-key to update the CAM view.

    Links:



*How to add Ambient Sounds?
    Info:
      Part of making a map more like a real place is the sound scape. Various ambient sounds like computer bleeping, howling wind, ominous creepy sounds, and grating machines help to make the otherwise dead map come alive.

    Step by Step:
    • Right-click in 2D-view, and select speaker to add a new sound entity.

    • In the Entity tab (N-key), click the Sound... button.

    • Pick a interesting sound from Dialog, e.g. sound/ambience/xscapes/scape_29.wav. Close Dialog.

      Tip: You can test sounds via Play button in Dialog.

    • With the speaker entity still selected, in the Entity tab (N-key) there are many properties for your speaker.

    • Some of the often used Key, Val (value) pairs:
      • angle, 60
        Possibly control the direction of a sounds?! (***)
      • s_shader, sound/ambience/xian/scape1/genx_02.wav
        The sound file to play. Click the Sound... button to change it.
      • s_looping, 1
        Loop the sound, for ambient sounds always on.
      • s_shakes, 0
        Camera shake on playing the sound? (***)
      • s_volume, -7
        Sound volume, typically ambient sounds are quiet with -6 or -7.
      • s_mindistance, 512
        Radius in units that will play sound at full volume.
      • s_maxdistance, 1200
        Radius in units at which the sound fades out.
      • s_omni, 1
        Omnidirectional sound (in all directions).
      • s_occlusion, 0
        No portal occlusion of sound.
      • s_waitfortrigger, 0
        Wait for a trigger or not.
      • wait, 0
        Plays sound immediately. Wait time in seconds.
      • random, 0
        Wait play variance.



*How to trigger Sounds?
    Info:
      Though this may be rarely uses in multiplayer maps, it can be fun to trigger sounds, e.g. when a secret was found or a some "piece of art" is bumped into.

    Step by step:
    • Create a brush that will be your trigger area, and keep it selected.

      Tip: You may need to make it as high as the player.

    • Pick the trigger texture from the Media tab (M-key):

    • Click textures/common/trigonce, to apply it.

    • Right-click on 2D-view, and pick trigger, trigger_once to turn the brush into an entity.

    • Deselect the trigger brush (Esc).

    • Right-click on 2D-view, and pick speaker and place is where you want to sound to play.

    • In the Entity tab (N-key), click the Sound... button.

    • Pick a interesting sound from Dialog, e.g. sound/ambience/xscapes/scape_29.wav. Close Dialog.

      Tip: You can test sounds via Play button in Dialog.

    • With the speaker entity still selected, in the Entity tab (N-key) there are many properties for your speaker.

      Note: You can change volume, loop play mode, distance etc. See the description text in the tab.

    • Finally link the trigger to the speaker: Deselect everything (Esc), select the trigger brush first (Shift + Left-click), then select the speaker, and press Ctrl+K.

    • When you now walk into your trigger a sound should be played.

      Comment: In MP Trigger Multiple might be better?! (***)

    Links:



How to add simple Terrain?
    Info:
      At times you will want to add more organic / natural looking environments like terrain or cave walls. The Q&A should help you get started with that "different" look.

    Step by step:
    • Basic terrain is based on a Simple Patch Mesh with a nice texture.

    • Create a brush in XY Top view with the size of your terrain (height is not important).

    • Pick a texture from the Media tab (M-key):

    • E.g. click Textures/textures/fragalot/grass01, to apply grass.

    • Turn the brush into a mesh via Patch menu, Simple Patch Mesh....

    • In the Patch Density dialog change Width and Height to e.g. 5.

      Note: More vertex points will make your map run slower (not very much in Q4), but give you more control over the mesh.

    • Now go into Vertex Mode (V-key).

    • You can then select the Verteces in XY Top view, and change their heights in a Side/Front view (Ctrl + Tab) by Left-click + Drag on a selected (= blue) vertex.

      Tip: Left-click + Dragging in XY Top view will let you select more than one vertex, and Esc deselects.

      Note: You will need solid brushes surrounding your terrain, since patches do not block visibility and would thus make your map leak.

      Tip: Since the terrain will probably totally cover your floor, the floor brush should be covered with the caulk texture (textures/common/caulk) to avoid z-fighting, in areas where the terrain "merges" with the floor brush.

    Links:



How to add Particle effects?
    Info:
      A typical decorative element of Q4 (and other modern engines) are Particle effects like Gas Venting from Pipes.

      Comment: I have no idea how badly this impacts the FPS (Frames per Second), q4dm1 uses it a lot though.

    Step by step:
    • Right-click on 2D-view, and add a func, func_fx to the map.

    • Place and rotate for desired particle emitting direction.

    • Keep emitter object selected.

    • In the Entity tab (N-key), click the Particle... button.

    • Pick an effect under Particles.

    Links:

Author:  AEon [ 05-01-2006 07:09 AM ]
Post subject: 

Debugging & Finalizing the Map


How to Test a MP Map (Console Commands)?
    Info:
      Simply loading your map map mp/<mapname> (devmap mp/<mapname>) via Q4's console will not work properly for multiplayer maps, since Q4 will be run the map in Single Player Mode. To quick fix the players running speed, type pm_speed 320.

      To actually spawn a multiplayer server by typing spawnserver mp/<mapname> on the console is a better way to go. This may not set the proper game mode though. E.g. DM, TDM, ...

      When testing you map many times, the best way to ensure you are running it in the correct gameplay mode is to write a small configuration file, and run that:

    Step by step:
    • Create a text file (e.g. with Wordpad) in your Q4 folder Quake4\q4base\.

    • Give it a name like <mapname>.cfg (i.e. Quake4\q4base\aeglow.cfg)

    • Then add the following lines to that file (you can omit the // comments):
      Code:
      seta si_pure 0              // Pure server
                                  //  Changed pk4's
                                  //  do not work!
      seta si_map "mp/<mapname>"  // Mapname "mp/aeglow"
      si_gametype <gametype>      // Gametype "dm"
      seta net_allowcheats 1      // Allow cheats: god
      spawnserver                 // Start the server
                

    • Replace <mapname> with the name of your map in the above code.

    • Replace <gametype> with "dm" (Death Match), "tdm" (Team Death Match), "ctf" (Capture the Flag), or "arena ctf" to set the appropriate mode.
      (***AEon: What about tourney?)

    • Save the configuration file <mapname>.cfg.

    • To test run your map simply type exec <mapname>.cfg in the game console.

      Important: Use this only to *test* your map (since map saves do *not* work) and then quit Q4 and reload your map again in the editor. (Toireht)

    • Other useful Console Commands:
      Code:
      noclip              // Fly mode (through walls).
      com_showFPS 1       // Show Frames per Second
      con_noPrint 1       // No console output on screen
      ui_showgun 0        // Turn off Gun model
      g_showhud 0         // Turn off HUD
      net_allowcheats 1   // Enable cheats on MP server
      r_multisamples 0    // Turn off Anti Aliasing
      pm_noclipspeed 300  // Noclip speed (default 270)
      r_usescissor 1      // OpenGL scissor rendering
      g_showdebughud 5    // Debug HUD (Mod) (see Links)

      r_showlightcount 1  // Lights/surface color coded
                          // 0x Black,
                          // 1x Red,
                          // 2x Green (GOOD),
                          // 3x Blue (MAX!),
                          // 4x Light Blue (Cyan),
                          // 5x Pink, 6x White (FIX!)

      r_showprimitives 1  // Reports surfaces,
                          // vertex indexes,
                          // vertex & texture memory
                          // 0 - off,
                          // 1 - 1st info set,
                          // 2 - 2nd info set

      r_showtris 1        // Highlights polygon edges.
                          // 0 - off,
                          // 1 - Visible surfaces,
                          // 2 - Front faces,
                          // 3 - Front&Back faces

      // (***) add more
                


    Links:



How to Debug a Map?
    Info:
      When building your map there quite a few useful commands to debug / analyze your map. This is especially useful when your maps starts to get slow (low FPS). With these various tools you should be able to track down the problem and fix it.

    Step by step:
    • Primary factor that can massively reduce FPS in your map is wrong lighting. In particular when you have many overlapping light sources. To check on this turning on "Light Count" is helpful:
      Code:
      r_showlightcount 1  // Lights/surface color coded
                          // 0x Black,
                          // 1x Red,
                          // 2x Green (GOOD),
                          // 3x Blue (MAX!),
                          // 4x Light Blue,
                          // 5x Pink, 6x White (FIX!)
            

    • This color codes every surface in your map, and counts how many light sources are hitting a particular surface. Black means 0 lights, Red 1 light, Green means 2 lights and this is considered "good", anything above 3 light sources or more should be eyed with suspicion, and can potentially require fixing.

    • Once you have located the surfaces that are hit by too many lights, it is helpful to check what light boxes are actually leading to the unwanted overlaps (turn off r_showlightcount 0). Now analyze the "Light Volumes":
      Code:
      r_showLights 2      // Light volumes as boxes
                          // 0 - off,
                          // 1 - volume numbers,
                          // 2 - draw volume faces,
                          // 3 - also draw volume edges
            

    • The translucent box around the light volumes will help you see what is going on. Blue boxes represent Shadowcasting lights, whereas red boxes show Non-Shadowcasting lights.

      Tip: Avoid several lights hitting a brush face, by cutting *large* brushes into several smaller ones.

      Note: You need to use different "trims" (textures) because the compiler efficiently merges manually cut up brush faces that share the same texture!

    • Another thing to watch out for is Geometry Overdraw (often causes Z-Fighting), test this with:
      Code:
      r_showoverdraw 1    // Geometry Overdraw
                          // Blue = good, Red = bad!
            

    • Should you detect red areas, take a close look at your brushwork and try to avoid the intersection of brushes.

      Tip: Generally it is a good idea to Caulk (even in Q4) every brush face that will never be seen in the map. Caulked surfaces (texture) are ignored by the engine.

    • If you are looking for as much visualized stats and debug information as possible, then you should
      download and install the Quake 4 Debug HUD mod from iddevnet.com. Use g_showDebugHud 1 to 11 to switch through the various displays, though Performance - option 5 - is probably used most.

      Tip: These bindings may come in handy:
      Code:
      bind u "toggle
              g_showDebugHud 0 1 2 3 4 5 6 7 8 9 10 11"
      bind i "toggle g_showDebugHud 0 5" // Performance
            

    • A definitive rundown of Performance and Framerate from iddevnet.com should be carefully read. It features details on Quake 4 Debug HUD, Lighting, Shadows, Draws & Batch Size, Visportals, Game Frame & the CPU, and Memory Limits.

    Links:



How to wrap things up into a pk4?
    Info:
      Here you will find the folder structure for maps for Raven's pk4 (pak = zip) files, details how to add a loadscreen, and how to set up the game type.

      pk4 "archives" much like the pk3 files for Q3A are basically zip files that mimick the folder structure Q4 uses. So you can use any zip tool to "collect" and "place" the files. Just rename the .zip file with .pk4 when done.

      Why use a pk4 file?
      It is the only accepted way for community maps to be distributed, it is less messy to install, and lets servers provide your map for automatic download.

      Where do your .map files go?
      Relative to the pk4's path multiplayer maps go into maps/mp/<mapname>.map. The absolute path in your Q4 folder would be Quake4\q4base\maps\mp\<mapname>.map.

    pk4 Structure:
      This is Q4's folder structure, the map's pk4 should be placed in Quake4\q4base\.

      Comment: I would recommend id's naming convention for map pk4 files: map_<mapname>.pk4 (e.g. map_aeglow.pk4). This makes it clear that the pk4 is indeed a map or set of maps, and not a texture set etc. And trust me, there will be many files the q4base\ folder!
      Code:
      q4base/map_<mapname>.pk4

          addon.conf               // Enables autodownload
          def/
                  <mapname>.def    // Defines <mapname>
                                   // map loadscreen path

          gfx/guis/loadscreens/
                  <mapname>.tga    // Loadscreen image

          gfx/guis/mainmenu/
                  <mapname>.tga    // X360 Thumb image

          maps/mp/
                  <mapname>.map    // Level source file
                  <mapname>.proc   // Compiler output
                  <mapname>.cm     // Compiler output
                  <mapname>.aas    // Compiler output AI
                  <mapname>.aas32  // Compiler output AI

          materials/
                    (any custom material files)
          models/
                    (any custom models files)
          scripts/
                    (any custom scripts files)
          sound/
                    (any custom sounds files)
          textures/
                    (any custom textures files)
            


    Enable autodownload of map pk4 via addon.conf:
    • With the map_<mapname>.pk4/addon.conf file you turn your map into an addonPak that Q4 servers will let players automatically download. Especially useful (obviously) for custom content. Folks will then be able to play your map on the fly and join the game.

      Here an example addon.conf:
      Code:
      // Marks this pk4 as an addonPak for autodownload.
      addonDef        {}

      // mapDefs for each map present in the pk4.
      // <MAP PATH> :  e.g. mp/aeglow
      // <MAP NAME> :  e.g. "AEon's Glow" (full name)
      mapDef <MAP PATH>
      {
          // Map name (Shown in Server Creation window)
          "name"          "<MAP NAME>"

          // Available Gametypes (1 enables, 0 disables)
          "DM"            "1"
          "Team DM"       "1"
          "Tourney"       "1"
          "CTF"           "0"
          "Arena CTF"     "0"
      }
            


    • Replace <MAP PATH> with your map's path relative to q4base\maps\, i.e. mapDef mp/<mapname> (e.g. mapDef mp/aeglow).

    • Also Replace <MAP NAME> with a nice (long) long for your map e.g. The Fragging Grounds.

    Custom Loadscreen via .def file:
    • To get Q4 to use your custom Loadscreen image, you will need to create a def/<mapname>.def Definition File with a duplicate of the mapDef entry mentioned in the addon.conf above.

      So here is an example <mapname>.def:
      Code:
      mapDef <MAP PATH>
      {
          // Map name (Displayed on load screen.)
          "name"        "<MAP NAME>"

          // Loadscreen (and Thumbnail) Image
          "loadimage"   "gfx/guis/loadscreens/<mapname>"

          // Thumbnail Image for XBox 360 (***)
          "mp_thumb"    "gfx/guis/mainmenu/<mapname>"
      }
            

    • Use the same <MAP PATH> and <MAP NAME> as defined in your addon.conf.

    • id / Raven recommends a 512x512 pixel TGA (and/or DDS) file as loadscreen image, but any power of 2 image will do. To speed up the "scrolling" of custom maps on the multiplayer screen of Q4, you can also provide a 128x128 pixel TGA thumbnail image (Kat).

      Note: You can also use .jpg images with an 80% quality to cut down on the map's .pk4 file size!

    Links:





Additional Information


About the Q4 SDK?
    Info:
      If you only plan to use Raven's resources in Q4, plus a few custom textures or models here and there, but do not plan on creating your own custom content (other than build a map), the SDK (Source Development Kit) is not actually required for mapping.

      It does contain a lot of potentially useful info if you do plan on using any other custom content like textures and material (the new "shader") files, as well as a few good pointers and tips. (Obsidian)

    Links:



Other FAQs & Tutorials?




FAQ Related


*Notation
    Info:
      Various shorthands are common in mapping, here you can look them up:

    • SP - Singleplayer - Offline play, usually missions.
    • MP - Multiplayer - Any form of online gaming.
    • TP - Teleporter.
    • AP - Acceleration pad.
    • JP - Jumppad.
    • FPS - Frames per Second - Less than 25 FPS is laggy, 60+ FPS are preferred in MP.
    • SDK - Source Development Kit - Free development package that helps you create new content, e.g. custom models or textures.
    • HUD - Heads up Display - Information projected onto your screen, e.g. crosshair, ammo counts, health and armor.

    • *** - Denotes things that need more work / checking.


Credits
    Info:
      Thanx go to the folks here at Level Editing and Modeling @ quake3world.com (LEM) and also to all the sites mentioned in the Links section of the Q&As.

      Special thanx go to KungFuSquirrel, Kat, Method, Toireht, tequila!, obsidian, pjw, hemostick, ...

      Features: Comments by Raven Designer "KungFuSquirrel" (coming up).


History
    Info:
    • v3.2 32 Q&As total, 3 new Q&As, 6 updates, 0 split, 179 changes, since v0.97 (6/23/2006)
    • v0.97 29 Q&As total, 0 new Q&As, 0 updates, 0 split, 0 changes, since v0.5 (5/7/2006)
    • v0.5 Putting together the Q&As, answering the most basic Questions. (4/30/2006)


ToDo List
    Info:
    • Do a copy and paste from one map to another work with brushes, models, etc? It does GTKradiant 1.5 to Q4's editor.
    • Fix the texture and material examples that are based on D3 mapping!
    • Two .cfg files for MP: optimized low gfx settings and high quality settings for tests.
    • Add something like a checklist referencing the Q&As in order.
    • Unpacking parts of Q4... from maps/mp/ pak002.pk4 and pak013.pk4 into your q4base\maps\mp\ folder.
    • Add Q&A on proper map name, e.g. betas and also all lowercase names!
      http://www.quake3world.com/forum/viewtopic.php?p=380550

Author:  tequila! [ 05-01-2006 01:13 PM ]
Post subject: 

Here's what I use for debugging junk, there are a few more commands in there than you listed. Info on how to use the "Debug Hud" can be found at:

http://www.iddevnet.com/quake4/LevelEditor_Performance

----------------------------------------------------------------------------------

Code:
bind "BACKSLASH" "toggle r_showprimitives"  // triangle counts
bind "[" "toggle con_noPrint"               // prints 3 lines of the console
bind "]" "toggle com_showFPS"               // show FPS
bind "p" "toggle r_showlightcount"          // lighting overdraw*
bind "o" "toggle r_showoverdraw"            // geometry overdraw**
bind "i" "toggle r_showtris"                // show triangles***
bind "y" "toggle r_usescissor"              // uses OpenGL scissor when rendering***
bind "u" "toggle r_showportals"             // show vis portals****

bind "k" "toggle ui_showgun"
bind "l" "toggle g_showhud"

bind ";" "g_showdebughud 5"  // or bind ";" "toggle g_showdebughud 0 5"
bind "'" "g_showdebughud 0"

bind "/" "noclip"

----------------------------------------------------------------------------------

* Lighting overdraw, black = 0 lights, red = 1 light , green = 2 lights, dark blue = 3 lights, cyan = 4 lights, etc.

"r_showlightscissors 1", combined with "r_showlightcount 1" can be useful in understanding exactly how light overdraw is determined by the engine.

Using those two commands plus "r_showtris 1" is also handy, for learning, as you can see exactly why very large triangles tend to have worse light overdraw than small triangles.

This is why it is sometimes recommended to split up large surfaces - sometimes it is worth adding a few more triangles to save yourself some light overdraw. A floor with a bunch of chicklet lights around the edges is a classic case for splitting a large surface.

----------------------------------------------------------------------------------

** Geometry overdraw, blue = good, red = bad basically.

----------------------------------------------------------------------------------

*** Setting "r_showtris 2" and "r_usescissor 0/1" (toggle it) can be useful for learning how the engine works.. not something you really need later on - at least not often IMO. As long as you understand exactly what vis portals do, you can infer this information simply by using "r_showportals 1".

----------------------------------------------------------------------------------

**** Vis portals, green is an "open" portal, red is a "closed" portal.

Nothing beyond a closed portal is drawn or even sent to your video card per frame.

Everything in front of a closed portal is sent to your video card for the geometry to be translated from world space to perspective space. (Not sure if that is the proper terminology)

Open portals in your scene act like windows, using OpenGL's "scissor" function to only actually render, pixel by pixel, what you can see THROUGH whatever open portals are in your current view.

Turn on "r_showportals 1", and "r_showtris 2", and then toggle "r_usescissor" to see difference between triangles which are only translated, versus triangles that are actually rendered pixel by pixel.

Triangles which are translated only are cheaper than those that are both translated and rendered, but it should be noted that the translation stage uses some of your CPU and VPU time available per frame; it is not free.

----------------------------------------------------------------------------------

edit: Edited a few things. One thing I should have been more clear about, "r_usescissor" is by default set to 1, and should be kept that way for playing. There's no reason to turn it off for actual playing unless you like fewer FPS.

Edit by AEon: Niced up bindings a bit.

Author:  pjw [ 05-01-2006 04:57 PM ]
Post subject: 

tequila! wrote:
Debug Hud
I was just going to post this, and you beat me to it. :) Long time no see; how the heck are you?

[Edit: Sent you a PM, so as not to crap up the thread.]

Author:  AEon [ 05-01-2006 07:34 PM ]
Post subject: 

tequila! wrote:
bind "o" "toggle r_showoverdraw" // geometry overdraw**


I had most of your commands in my autoexec.cfg, that I plan to really clean up and post, but the Geometry Overdraw is new to me. Nifty :)

Quote:
edit: Edited a few things. One thing I should have been more clear about, "r_usescissor" is by default set to 1, and should be kept that way for playing. There's no reason to turn it off for actual playing unless you like fewer FPS.


That's one of the things I also found strange when reading the FAQs. The feeling I got was it would be off by default. Will turn it on now by default, I assume this would really help in MP gaming online?

I edited your post slightly, placing your bindings in a code tag.

BTW:
Code:
bind ";" "g_showdebughud 5"
bind "'" "g_showdebughud 0"

can be elegantly condensed to
Code:
bind ";" "toggle g_showdebughud 0 5"

since toggle now understands a "list" of possible numerical states.

Thanx, will carefully read all the info and add it to the FAQ.

Author:  AEon [ 05-03-2006 01:15 AM ]
Post subject: 

Already have to split the FAQ into 2 Posts... ieeks...

Author:  obsidian [ 05-03-2006 07:24 AM ]
Post subject: 

AEon wrote:
Already have to split the FAQ into 2 Posts... ieeks...


You sir, are amazing. I'd hug you except tigers have a tendency to pounce and bite.

Author:  AEon [ 05-03-2006 05:50 PM ]
Post subject: 

Thanx :)

Only noted these past few days that Q4 mapping seems to be off to a troubled start, even more so than D3. Not only here at LEM but also over at D3W.org's Q4LE... hmmm.

As that may be a few of the Q&As are starting to be interesting by themselves, meaning containing information spread over several sites. So hopefully the FAQ will be of some use at some point.

Alas my copy of :q4: has yet to arrive. Sigh...

Author:  KungFuSquirrel [ 05-03-2006 09:37 PM ]
Post subject: 

Seems odd to be compiling an FAQ without having touched the game yet yourself. ;)

Pretty good coverage so far... things I've noticed:

-Visportals work best in pairs. Just having a single portal in an open connection between rooms won't close. Think of it as defining chunks of level to draw at once. Because you can see one end of that chunk, the entire chunk draws. If you have a longer hallway between rooms, and then place a portal at each end, you'll get a better result. When you're looking down the hallway into the other room, the portals overlap and open. As soon as the back portal is no longer visible from the near portal, it closes, blocking the other room. You'll see a lot of narrow double-portaled chunks in our maps for this reason, or an occasional portal in the middle of a room to cull off exits on the other side. Hopefully that's a clear enough description...

The triangle gain you get from portals (or most anything else, really) is insignificant, and can be useful for helping light overdraw on faces without having to offset textures or add trims. What is dangerous about portals is the batch size splitting. You can really ramp up your draw calls if you portal too aggressively, but they can also go too high if you don't portal enough. It's a fun balance to find. :)

Portals also automatically toggle off and on when placed inside func_doors (the portal face should be on the same plane as the origin). Handy!

also, crossing vis portals is like crossing the streams ghostbusters. Don't ever do it unless it's time to save your map from a giant marauding marshmallow. :)

Oh, and fading portals! these fade from fully visible to a specified image over the units specified in the material file. Might be worth a mention as well. Handy for windows in some dire cases.

-ambient light. Be careful with this; it still adds a light pass to everything. Also, ambients sort of bake a highlight onto normals, so mirrored textures and flipped objects can look really ugly if you go too bright. You can sort of see this on MP characters in the MP maps. Great for illumination, but terrible for visuals if you're not careful.

-clipping. For our maps we used player clip, but I'd recommend regular clip at this point. Community-made bots need an aas32 file, and player clip does not define AAS.

-Q4 has limited portal sky functionality that can easily be 'hacked' via script to get a proper parallax effect. Use skycaulk in areas where you want the portal sky to draw, then use a func_portalsky_camera (I may have just typed that wrong, actually) placed in a smaller skybox area using a regular sky texture and whatever you feel like (terrain models, structures, effects, etc.)

-All terrain in Q4 was modeled in Lightwave. I would highly recommend against using patch or old-school tri-souped terrain. Modeled terrain allows more controlled/defined shapes, better silhouettes, and texture blending based on vertex color.

-Particle button/functionality is completely removed in Q4. You have to manually set an "fx" key or use the effects editor in the game. I recommend the latter; you can use the entity editor to drop new effects, align them, orient them, edit them, etc. etc. and then save out your .map file with the changes. Much easier than manual placement.

-Biggest performance console command, r_showbatchsize, is barely touched on. Toggling this on shows how efficiently triangles are being sent to the video card (which likes to eat triangles at about 500+ at a time). I've stopped using r_showtris entirely in favor of this; raw triangle count barely matters vs. draw calls/batching and light overdraw/shadows.

Managing draw calls is arguably the single most important aspect of render speed optimization. It's covered pretty well in our performance guide on iddevnet, but I'd recommend detailing it out so it's not overlooked by anyone who might find this first and not bother to follow the links. :)

-oh, and compile time. vis portals (the geometry splitting on portals, for example) and some lighting information (for shadow purposes) are calculated during compiles. For an MP -noaas or -aasonly32 compile it should still be pretty quick, but complex geometry and lighting can jump that up quick. Larger SP maps could take in the range of 15-30 minutes. But given how long these used to take previously, that's still not too shabby. :)

Great resource, though, let me know when you get it to a more permanent location and I'll toss it onto the iddevnet links list.

Author:  AEon [ 05-04-2006 12:50 AM ]
Post subject: 

KungFuSquirrel wrote:
Seems odd to be compiling an FAQ without having touched the game yet yourself. ;)


Yep :)... but then again I have been working with id engines a while, and also did a week of D3 testing, and tested a few things in the Q4 Demo. But there are bound to be errors.

Will carefully read your feedback later, thanx!

Author:  AEon [ 05-04-2006 02:54 AM ]
Post subject: 

Quote:
Visportals ... double-portaled chunks ...


A few nice sketches that illustrate this would probably really help. I guess one tip - as always - is to look at Raven's maps and see what they did. If someone would just scribble things out on paper and scan that, I'd sit down and do a nice version in Photoshop.


Quote:
The triangle gain you get from portals (or most anything else, really) is insignificant, and can be useful for helping light overdraw on faces without having to offset textures or add trims. What is dangerous about portals is the batch size splitting. You can really ramp up your draw calls if you portal too aggressively, but they can also go too high if you don't portal enough. It's a fun balance to find.


Still need to learn and understand this. And - much like hint brushes - placement of portals seems to be an art form.


Quote:
Portals also automatically toggle off and on when placed inside func_doors (the portal face should be on the same plane as the origin). Handy!


A detailed Q&A on how to get Visportals to work with Doors would be handy. Or is placement "inside" enough?


Quote:
Also, crossing Visportals is like crossing the streams ghostbusters. Don't ever do it unless it's time to save your map from a giant marauding marshmallow.


Good to know :)


Quote:
Oh, and fading portals!


I skimmed those but were beyond me, someone would have to write something up on those. I am not sure how interesting these are for MP maps though?


Quote:
Ambient light... Be careful with this; it still adds a light pass to everything.


Basically that brings the lightcount to +1 for everything.

Quote:
Also, ambients sort of bake a highlight onto normals, so mirrored textures and flipped objects can look really ugly if you go too bright. You can sort of see this on MP characters in the MP maps. Great for illumination, but terrible for visuals if you're not careful.


Aha... lighting will be tough... sigh.


Quote:
Clipping. For our maps we used player clip, but I'd recommend regular clip at this point. Community-made bots need an aas32 file, and player clip does not define AAS.


Then I did understand the information correctly, player_clip does not create AAS data, but full clip does. Will add the info. Still have to find a custom bot though.


Quote:
Q4 has limited portal sky functionality ...


Screams for another Q&A... hint :)


Quote:
Biggest performance console command, r_showbatchsize, is barely touched on. Toggling this on shows how efficiently triangles are being sent to the video card (which likes to eat triangles at about 500+ at a time). I've stopped using r_showtris entirely in favor of this; raw triangle count barely matters vs. draw calls/batching and light overdraw/shadows.


Good to know.


Quote:
Managing draw calls is arguably the single most important aspect of render speed optimization. It's covered pretty well in our performance guide on iddevnet, but I'd recommend detailing it out so it's not overlooked by anyone who might find this first and not bother to follow the links.


Will do that...


Quote:
Oh, and compile time. Visportals (the geometry splitting on portals, for example) and some lighting information (for shadow purposes) are calculated during compiles. For an MP -noaas or -aasonly32 compile it should still be pretty quick, but complex geometry and lighting can jump that up quick. Larger SP maps could take in the range of 15-30 minutes. But given how long these used to take previously, that's still not too shabby.


If I understood what the "community bots" actually require, one could probably optimize the compile options to either completely skip AAS generation for all local tests, and only turn on a "full" compile for distribution.


Quote:
Great resource, though, let me know when you get it to a more permanent location and I'll toss it onto the iddevnet links list.


Thanx :)... the FAQ will definitely stay in this thread, and I am also posting it over at Doom3World.org's Q4 LE forum. But at some point I'll do a niced up HTML version for my site (planetquake.com/aeons). The phpBB to HTML parser for this is already written (used it for my KotOR II FAQ).

Thank you for the feedback, definitely appreciated. I am sure as soon as I actually start mapping, tons of new things will come up.

Author:  KungFuSquirrel [ 05-04-2006 04:10 AM ]
Post subject: 

Make sure you're talking about "clip" and not "full_clip" - "full_clip" also blocks visibility and all weapons fire, which is not so good on a wide scale. :)

I'll try write up some more detailed info for you tonight; it was getting late last night or I could have probably given you a few other examples. :)

Author:  AEon [ 05-04-2006 04:16 AM ]
Post subject: 

Wonderful, much appreciated.

I'll probably be quoting you all over the place, that way folks that "really" understand things will not have to live with my missinterpretations ;).

Author:  AEon [ 05-06-2006 09:30 AM ]
Post subject: 

Finally Q4 arrived yesterday, and in 13 hours I played through the SP game... whee...

Now for the MP part.

Ironically I had actually been thinking of converting q3dm17... to my surprise that had already happened. A bit glitzy though IMO.

But that still leaves q3dm7 :)... might really be fun to use a new "design" defined by existing maps and use the q3dm7 layout. Maybe...

Well in any case this means I can finally test the FAQ...

Author:  AEon [ 05-20-2006 05:19 AM ]
Post subject: 

Note to self...

Add a section about support for Oak Bots and on how to properly make them work, i.e. clip.

http://www.quake3world.com/forum/viewtopic.php?t=20450

Author:  wviperw [ 05-27-2006 01:31 PM ]
Post subject: 

Quote:
* Tips: Raven suggests ramp-clipping stairways, to allow for ramp-jumping.


The 1.2 patch fixed stairs so mappers should *no longer* clip stairs. If they want ramps then they should be making ramps. (this should be updated on iddevnet as well probably).

Author:  AEon [ 05-27-2006 05:47 PM ]
Post subject: 

Hmmm... yeah read that as well.

But the stairs in q4dm1 I was trying to ramp jump on did not let me do so. Or do folks actually *want* to "turn off" ramp jumping on stairs?


Personally I'd want to be able to use stairs much the same way I would use ramps for ramp jumping.

Are stairs some sort of "strategic" gameflow thing? I usually used stairs as decoration, clipping them off to be ramps (with player clip).

Author:  wviperw [ 05-27-2006 07:44 PM ]
Post subject: 

Yes, there is a gameplay difference between stairs and ramps that matters. When strafing over "real" stairs the player maintains horizontal momentum whereas when strafing over "ramped" stairs the player loses horizontal momentum and gains vertical (popping the player up in the air due to the ramp-jump). This can be quite detrimental to the player's health if he gets popped into the air on a set of stairs that should *not* have done so, since it can ruin the player's speed and give his an opponent a potentially easy rail.

Author:  AEon [ 05-28-2006 08:11 AM ]
Post subject: 

I noted - with my limited strafe jumping skills - that ramps in AEdm7 slow me down most of the time, badly. Whereas in Q4 I'd tend to ramp jump about.

So presently AEdm7 seems to be more Q4 "friendly".

Author:  AEon [ 06-23-2006 04:31 AM ]
Post subject: 

Just updated the FAQ to v3.2 in this thread. Also see:

Æon's Quake 4 Mapping FAQ v3.2 - HTML


changes since (internal) v0.97:

  • sections: getting started,
    the basics,
    movement related elements,
    detail elements,
    debugging & finalizing the map,
    additional information.
  • detailed step by step descriptions for teleporter,
    jumppads, acceleration pads, weapon/item bases, ...
  • 32 q&as total
  • 3 new q&as
  • 6 q&a updates
  • 179 changes

Author:  obsidian [ 11-13-2006 05:05 PM ]
Post subject: 

After much bashing my head against the table...

Under "Launching Q4 and the Editor",

With the patched versions of Q4, you also need to add set r_useSMP 0 along with disabling multisamples to get the editor to work.

Author:  AEon [ 11-13-2006 11:14 PM ]
Post subject: 

I am surprised that set r_useSMP 0 is not set to zero by default. Or do you actually have a dual processor system?

Author:  obsidian [ 11-14-2006 06:04 AM ]
Post subject: 

Hyperthreaded, so it set itself to 1. The editor spits out the same bunch of errors as the multisamples one. I did some head scratching for a while since I was positive that I disabled multisamples.

Author:  Method [ 01-06-2007 12:55 AM ]
Post subject: 

Very nice work on formatting the information, AEon. Very easy on the eyes to read.

-Method

Author:  A1yssa [ 02-03-2007 05:32 AM ]
Post subject: 

I use to play online every day, so I use a high tweaked cfg...pasted in the autoexec.cfg.

where can I find a cfg for my mapping time?

Author:  wviperw [ 03-13-2007 05:29 PM ]
Post subject: 

For teleporters, you should use 'textures/common/trigshotclip' for the material rather than 'textures/common/trigmulti'.

Author:  Bill_Brooks [ 03-22-2007 07:54 AM ]
Post subject:  My Site FPS has moved to a new host.

After 8 years of no trouble I just lost my host for my site.
So I bought a .com and hosted it with godaddy.

So in a few days all links to F.P.S will be broken.

The old url http://fps.brainerd.net

Should now be http://www.wemakemaps.com The site name will change to We make maps but you could leave it as FPS if you want.

I haven't done any thing in Q3 for a long time now but I do still have many tutorials and the best collection of map models in one spot that I know of.

Author:  addseo1115 [ 07-18-2015 02:08 AM ]
Post subject:  Re: AEon's Quake 4 Mapping FAQ - v3.2

where can I find a cfg for my mapping time?
จีคลับคาสิโนออนไลน์

Author:  AEon [ 07-18-2015 03:05 AM ]
Post subject:  Re: AEon's Quake 4 Mapping FAQ - v3.2

Never got around to releasing that info IIRC... been such a long time ago. A lot never got done for that FAQ.

Page 1 of 1 All times are UTC - 8 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/