RMQ Mapping Guide

written by gb, ijed, …

We’ll show you how to use some of RMQ’s new entities in the map editor.

• func_ladder: Ladders
• rotate_door, rotate_continuous: RMQ rotating entities and hmap2
• func_water: Moving water, healing pools, skill dependant liquids, using Skip with func_water and more
• info_groupleader, info_location etc.: Lardarse’s Randomizer
• .monstergroup: Monster groups
• .is_waiting: Waiting triggers (and funcs)
• Multiple targets/targetnames
• item_key / trigger_lock: Custom keys
• info_camera: Cutscenes
• “Fence textures”
• .caster_level, magic.qc: Spellcasters
• SPAWNED, SILENT, ALERT – prespawned monsters and items
• .ritem: Respawning items
• Wargear flags: One monster, different gear
• fx_sound, fx_ambientsound: Playing sounds and how to make looping .wav files
• fx_spark, fx_drip, fx_beam
• trap_shooter, trap_spikeshooter: New ammo
• weapon_railgun, axe replacements etc: New weapons
• trigger_checkpoint and the checkpoint system
• func_emitter, func_emitter_volume: Model emitters
• func_nodraw: An alternative to Clip brushes
• func_grapplepoint, item_grappling_hook: The grappling hook, and how it changes the world
• item_backpack: You found a backpack full of ammo!
• func_nomantle, walljump, pogo, stairglide, dash, and how those change the world
• The Use of Coloured Lights
• Physics and how it changes the world
• func_pushable, trigger_pushcatcher: Pushable bmodels and how they change the world
• func_train, func_watertrain: Things you can do with trains
• func_breakaway, func_explobsp, func_bspframe: Stuff that breaks
• The uses of .alpha
• func_hordespawn: Everybody loves it. From Scourge to Chapters to RMQ.
• func_door: Bronze and platinum keys
• misc_model: Mapmodels and what they’re good for, and how to use them in Radiant
• info_player_*: Spawneffects, spawntargets, deathtargets and more
• Stimpacks and armour shards and what worldtype does to items
• Redspwans, blueflags, and Capture the Flag.
• info_command, trigger_command: How to bully the engine into doing your bidding.
• The Use of Replacement Textures, and how to anticipate them while mapping
• Entity scale and alpha
• Limits are subject to negotiation, mostly
• Monster roaming: The figgin is a lie
• misc_victim, misc_npc: Non-player characters, and where they’re going
• New monsters: Base flyer, Elder Ogre, Proto-Shalraths and their big, bad friends
• Will it play my Quoth maps? Yes, in all likelihood, it will
• Will it play my vanilla Quake map that uses all sorts of entity hacks? …
• … I dunno negke, just man up and use QC already, that’s what it’s there for
• Do you do requests? Yes, actually requests are what made RMQ.
• Can I have the source? Yes, actually we’re going to release it.
• Can I be your friend? Yes, sure.
• Can I have a .fgd file? Yeah, see below.

Latest .def and .fgd files for level editors

func_

func_ladder: Ladders

Build the ladder’s geometry out of brushes, or use a misc_model. Afterwards, create one tall brush that stretches from the foot of the ladder to the top. Use the trigger texture for this. Make this trigger brush about the same width as the ladder geometry, and have it extend roughly 8 units in front of the ladder itself so the player will safely stick to it. Turn this trigger brush into a func_ladder.

Give the func_ladder an ‘angle’ key with a value between 1-360 (0 = 360). Make this the direction the player must face to climb the ladder.

NB: The ‘angle’ key in Quoth is reversed; however, RMQ will also load Quoth trigger_ladders correctly.

Make the top of the func_ladder flush with the ledge.

If the ladder is two-sided (ie free-standing) you must put a func_ladder on each side, with the proper ‘angle’ value in each case. Put a clip brush between the two func_ladders in this case to separate them.

In RMQ, the ‘angle’ value is used to determine the direction the player must face to climb, and the direction the player is pushed into when jumping off. Jumping off while facing the ladder will eject the player backwards off it; jumping while facing to the side will eject the player in that direction; facing away from the ladder will make the player drop.

func_water: Moving water

Create a water brush as usual. Turn this into a func_water.

NB: func_water must have a rectangular bounding box, like triggers. Thus, you cannot have L- or U- shaped func_waters and you must avoid using just one water brush (or just one func_water) for irregularly shaped bodies of water.  Reason: Your func_water’s bounding box will extend into non-water areas of the map, possibly neighboring rooms, which will cause water splashes and weird behaviour when the player enters those areas.

As a rule of thumb, when you have non-rectangular bodies of water, break them up into rectangular brushes and turn each of those into a func_water. This will avoid the problem where the bounding box extends into non-water areas. If your water body has 45 degree angles, use narrow rectangular water brushes that follow the angled wall in a stairstep pattern. (this may be fixed in the future, but don’t count on it)

Give the func_water a ‘watertype’ key to define what kind of liquid it is (-3 water, -4 slime, -5 lava); a ‘height’ key to define the number of units it’ll move (negative number = move down); ‘speed’ and ‘wait’ keys the same as for doors. It can be triggered to move (tagetname) or it can simply keep bobbing up and down. The func_water can play a sound when moving to create the impression of running water.

When you’re inside a func_water, its sides will be visible (unlike real water). To avoid this effect, texture the sides you don’t want visible with the Skip texture (simply a texture with ‘skip’ as its name) and apply a Skip tool as the last step in the map compiling process. A skip tool removes all skip-textured faces from the map.

You can get metlslime’s newskip tool here. It runs under Windows and Linux.

Moving water is the simplest thing func_water does. It has other interesting properties, too:

Func_waters can be abused as a healing spring (example: DM6RQ). This is explained in the def/fgd.

Func_waters can have the NOEASY, NOMEDIUM, NOHARD and NODM spawnflags set. This means that you can have water on Easy skill, slime on Medium, and Lava on Hard, for example. You can also have a teleporter on Normal and lava on Hard (example: E1M6RQ).

Func_waters can have a current. This can be used to make the player travel large distances underwater without drowning, or to block access to an area.

Func_waters can be attached to a moving train. See func_watertrain.

func_grapplepoint: The grappling hook and how it changes the world

In RMQ, unlike most other Quake mods, you cannot grapple everywhere. Your grappling hook can only latch on to a func_grapplepoint entity placed by the level designer. Reason: If you could grapple everywhere in a singleplayer map, it would practically “break the map” since you could just bypass any challenges, blockades, key doors and ambushes. Let’s be fair to the mapper here. He goes through all the trouble to set up a memorable experience for you and plans how the player will move through the map. By the use of grapple points, he can decide where the player is allowed to grapple. basically, grapple points = giving control to the designer.

Create the grapple point geometry out of brushes. Make that a func_grapplepoint.

NB: The center of the func_grapplepoint entity should be within a brush. Cross-shaped rungs on the ceiling have proven to work, so have simple bars. Make sure any grapple points are easily understood by the player to be grapple points! A special texture, a certain shape that they all have in common will get the message across.

The grapple will aim directly for the func_grapplepoint’s center.

The workings of the grapple:

Method 1, this is what almost all test pilots tend to do…

Method 2! This is what gb uses (yeah, hold it right there!)… negke dubbed this the “grapple boost”.

Take note that you can place grapple points (red) in such a way that method 2 is required. For example you can grapple directly upwards through a hole by placing a grapple point on the side of the hole. This will require method 2 to grapple successfully. Most people simply don’t get method 2 and will come to the level designer’s house with torches if he does that. You have been warned. The player is, as ijed likes to say, a dunce.

Method 2 does allow you to gain incredible speed though. It is a good idea to allow skilled players to use method 2 optionally.

Lesson: The placement of grapple points is worth spending some thought on.

The grapple command, as in most Quake mods so far, is +hook. Jump disengages. You can reel in/out by using the keys for next/previous weapon, but if you use method 2, those are pretty redundant.

The grappling hook itself is given to the player via an item, item_grappling_hook. You will also get a fragged player’s grapple via his/her backpack.

func_pushable: Pushable things

Pushable boxes go back in Quake to the time of Mission Pack 1, Scourge of Armagon. They weren’t really used in very creative ways, though, and had many shortcomings. However, when done well, pushables can really be a multipurpose gameplay element. You can jump on them to reach a ledge, after you a) noticed the ledge and b) brought a pushable into position. You can stack them to eventually reach a ledge. You can hide stuff behind them. And I’ll be damned if you can’t block doors with them. Anyway, you can do pretty clever puzzles with one or several func_pushables. The puzzles get more difficult the more pushables are involved.

Create a box, 64x64x64 is a good practical size. Turn that into a func_pushable. Done. You can now push that around ingame.

… There’s a little more to them than that, of course. Optionally. Things a level designer might want to know:

• A pushable acts like a grapple point.
• A pushable can drop down ledges.
• A pushable can not swim (yet).
• A pushable will go up and down a lift or train.
• A pushable will block moving brushes, if between them and a wall.
• A pushable will be pushed by a moving brush.
• A pushable will stack onto another pushable, if it is pushed or dropped onto it.
• A pushable can be stood on, jumped off, or rocket jumped off.
• A pushable can be forced onto a certain path, or into a certain slot or hole. The space will have to be at least 1 unit bigger than the pushable on all sides (ie a 64 unit wide crate will fit into a 66 unit wide slot, hole or channel).
• The movement speed of a pushable can be set by the mapper.
• A pushable can break or even explode if shot (spawnflag).
• A pushable can be pulled with the grapple (spawnflag).
• A pushable can cause a trigger_pushcatcher to fire upon touching it.

Same as with grapple points, you want to make sure the player understands that something can be pushed. Usually. Playtesters have walked right past pushables that looked like simple crates. Exploit that for secrets, but make pushables that are required for progress very noticeable, probably even by giving a message.

func_nodraw: An alternative to clip brushes

This works like a func_wall, but it’s invisible and dumb. The effect is much like a clip brush, with the following differences:

• It can be killtargetted
• Monsters will walk on it
• Projectiles will not pass through it (leave holes for any lava balls etc.)

It’s pretty useful. I suggest choosing a texture that really stands out, or creating a texture that actually says “nodraw” on it, so these are recognizable in the editor.

func_togglewall: A toggleable invisible wall

Again much like a func_wall, only invisible, but can do things like toggle on/off, damage the player upon touching it and play sounds. I know Quoth (Scourge probably as well?) uses this to create forcefields, which is nifty and we might eventually do that as well, but for now these can be combined with a func_emitter_volume emitting particles to create forcefields. I don’t think we’re using these a terrible lot at the moment, but we’ll probably do the forcefield thing eventually (read: when one of our coders really, really has nothing better to do).

func_hordespawn: Spawn things every X seconds

Most people know what this does, it is a version of the Scourge of Armagon / Lost Chapters / Quoth mass-spawning code. It does what it says on the tin, really: spawning something (I only tested monsters) in regular intervals. Like, spawn a zombie from a hole in a sewer area every 2 seconds until you run out of zombies or the player ragequits…

This is a point entity despite its name, but info_hordespawn works just the same.

You must set both the ‘spawnfunction’ (this references a QuakeC function like monster_zombie) and the ‘spawnclassname’ (to give the spawned monsters a QC classname) keys for this to work. Refer to the .def/.fgd files for details.

We give these things Quoth-compatible names in order to support Quoth maps to a certain degree, by the way, and to make it easy on level designers who are used to mapping for Quoth. We have utter respect for Quoth and we didn’t decompile it or anything, we actually code this stuff up ourselves while referencing Custents, Scourge of Armagon, and Lost Chapters source code. There are only so many ways you can do a func_hordespawn, folks. It’s not rocket science.

fx_

fx_spark, fx_drip: Sparks and drips

These are particle-emitting point entities that also play the matching sound. fx_spark will send sparks flying from a broken switch, or from behind a missing wall panel. fx_drop will create an ambience of dropping water, in a cistern or the like. Technically these are shortcuts into the whole func_emitter business. They save you the effort of having to set up a func_emitter just for some sparks.

fx_beam: Stationary lightning

Targets an info_notnull to draw a constant lightning beam. Warning: This might require a modern engine with a raised limit on the number of beams you can have at the same time.

Enough said.

fx_sound, fx_ambientsound: Playing sounds

Sound design is extremely important. An fx_sound will generally play a .wav file when triggered; this can either be a one-time event or the sound can be played at certain intervals. It can even be a looped .wav file, playing on endlessly. fx_sound can be triggered off as well as on.

This entity is very useful when combined with a trigger_once in the player’s path. You can do things like a distant explosion sound (combined with a trigger_shake for a slight screenshake effect), sound of distant battle, a sudden monster growl behind a wall, sudden bursts of steam coming from a pipe, or a garbled radio message starting to play from a broken console when the player rounds a corner. Using triggered sounds, you can make the level seem bigger and more alive than it really is. Shock effects can be done using triggered sounds as well, but these days you have to be really clever to scare players after games like Doom 3 overdid the scary sounds thing. Still, triggered sounds are great for ambience.

An fx_ambientsound will play a looped .wav file as a normal ambient sound, for example a spooky ambience, the sound of a thunderstorm, music, or anything that is supposed to play constantly in a certain area. There are tricks to have an ambient sound be audible in the entire level, though, such as placing a sound player in all cardinal directions and setting the ‘distance’ key to 0.

You can specify the sound’s falloff distance by giving the ‘distance’ key a number from 0 (ATTN_NONE) to 3 (ATTN_STATIC). It’s explained in the .def file.

Technical advice: RMQ uses 44100 HZ (44.1kHz), 16 bit sounds (ie there is no more need to downsample sounds). These sound samples must be mono, not stereo (1 channel). WAV format is required (atm). Tell your players to use -sndspeed 44100 on their Quake command line, otherwise there will be weird behaviour.

You create a looped .wav file by opening the sample in a sound editor like Goldwave, then setting a single ‘cue point’ at the start of the track. It doesn’t matter what you name the cue point. You can get lots of free .wav files on the internet, at sites such as Freesound. There are also affordable online sample libraries like Soundsnap.

info_

info_camera: Cutscenes

An info_camera is a point entity very similar to an info_intermission. Place it where you want the cutscene camera to be, and trigger it (trigger_once, trigger_pushcatcher, monster killed, button pressed, spawntarget, whatever). The player’s view will go to the camera’s position for ‘wait’ seconds. The camera view can be aborted by pressing Fire, unless spawnflag 1 is set.

NB:

• An info_camera can target another info_camera; in this case, after the first camera’s ‘wait’ is up, the view will go to the next camera. We call this daisy-chaining cameras. You can have a lot of camera angles in a cutscene this way.
• An info_camera can print a message during the camera view.
• An info_camera can play sounds when switching to/from it.
• When the TRANSITIONAL spawnflag is set, and optionally a speed, the view will move smoothly from the previous camera in a daisy chain to this one. It will also change pitch or yaw smoothly during the transition, from the old camera’s ‘mangle’ (pitch yaw roll) to the new camera’s.  This way you can have the camera view do a corkscrew motion, or move to/from a certain point, through a succession of traps for example (show the instruments!).

This allows you to do all manner of cutscenes etc. during the course of a level, activated by triggers. One example is to show an opening door after the player presses a button. Impatient players can simply “click the camera away” unless spawnflag 1 is set. You should usually allow them to do that, otherwise they’ll get angry and come to your house with torches, again.

NB: ‘mangle’ on an info_camera is set like this: ‘pitch yaw roll’. Pitch 90 means down, -90 means up. Yaw is the horiziontal rotation (you can get where “0” is by setting an ‘angle’ key temporarily, most editors will show a little arrow then). Roll is the diagonal skew.

Pro tip: If you want an item to spawn, or something like that, during a cutscene, you must trigger that before you trigger the camera chain. Trigger_relay and multiple targetnames are your friends.

To avoid a cutscene playing when the player died while triggering it (huge things exploding…), use a trigger_relay with spawnflag 1 set, ONLYLIVING.

info_groupleader etc: Lardarse’s Randomizer

This code allows you to do any of the following:

• have a number of locations where monsters from a pre-defined group are randomly spawned
• have one monster spawn at one randomly selected location from a pre-defined group
• other things that are so crazy that my brain fails to put them into words.

How to go about setting this up. For the first example above, you need:

1. A group of monsters with the same ‘group’ key. These monsters are only fodder for an info_groupleader entity, so the monsters themselves can be moved out of the way somewhere. They do not spawn by themselves.

2. A set of info_location point entities. Put an info_location at each spot you possibly want monsters to appear. Set its “group” key to the groupname. Set “angle” as you would on a monster, or a teleport destination.

3. An info_groupleader. This point entity does all the thinking. When a map is loaded, all info_groupleaders will scan for their groups and start to populate the level by randomly spawning monsters from their respective groups at the respective info_locations. It makes sense to put these in the vicinity of their info_locations.

‘group’ needs to be identical on a group’s monsters, info_locations, and the groupleaders. In addition, set ‘groupcount’ on the info_groupleader to tell it when to stop.

NB:

• This can be combined with SPAWNED monsters, ie Quoth-style prespawning, and things like AMBUSH.
• The probability of a certain monster type from a group spawning can be influenced by the percentage of that monster type in the group. Between 9 ogres and one shambler, it’s extremely unlikely for the shambler to get picked.
• You can have one info_groupleader per skill level per group (see image). You can also set the skill related spawnflags on the individual monsters in a group. This allows you to define a) what monsters can spawn at all from a group on a certain skill level, and b) how many monsters from a group are spawned on a certain skill level (‘groupcount’ and NOEASY etc. on the info_groupleaders).
• You can use this randomizer feature with items, as well.

This whole randomizing business might seem like complete chaos, but I assure you it is not. It increases the replay value of a level by a ton if you have an ogre spawning in on the left instead of on the right, have a berserk ogre spawn in place of a normal one, or have a shambler pop up in an unexpected place.

Per playthrough, that is.

Imagine a group with one groupleader, one location, two SLEEPING shamblers, and one AMBUSH shambler. Two thirds of the time, the shambler will be sleeping. Sometimes though, he will be quite awake.

Another example is a group with a few locations and a lot of harmless monsters – with one spellcasting vore mixed in on Hard. Say the spellcaster will be spawned 10% of the time; you will see him  very rarely, but if he does appear, he’ll wreak havoc. Spellcasters are complete crazies.

Third example is a group consisting of one monster, say a fiend, and a lot of locations scattered throughout the level. The fiend will pop up rather unpredictably somewhere in the level. This’ll shake things up if you do it right.

Fourth example: A shambler that spawns in either in front of or behind the player, at a 50/50 chance. You’ll need a groupleader, two locations, and the shambler. Set SPAWNED and ALERT on the shambler and trigger it when the player passes a trigger_once. The groupleader will position the prespawned shambler when the map loads, but it won’t become visible and active until it itself is triggered.

item_

item_key, trigger_lock: Custom keys

Remember the Tank Commander’s Head from Quake 2? It was a keyitem that, once collected, allowed you to proceed past a retina scanner. Or the Lost Valley level from Tomb Raider? You had to collect three cogs and put them into a mechanism to change the course of a river. Remember all the fuses to collect in TR’s Natla’s Mines, the missing door panel in Doom 3‘s Central Processing, all of the insane keyitems in Hexen 2?

Of course the designers could have used simple buttons or computer consoles to open all those doors (ultimately, it’s about getting past obstacles, isn’t it). But the thing about unusual keyitems is that they have a story attached to them.

The keys required to proceed through a level can instantly set its theme and form a little story all by themselves. They add depth to the experience. Pressing a button is rather profane, don’t you think! What about requiring the player to acquire and use a signal horn in a medieval castle level, in order for the guards to unwittingly lower the drawbridge for him? Maybe a letter that’ll allow its owner to pass? A Quake 2 style power cube that needs to be plugged in somewhere? A severed hand, as in Prey, to get past a scanner? An arm and a leg? A sacrifice delivered on a blood-stained altar?

Notice how those kinds of keys practically define the theme of the level already.

You can have those in RMQ by using an item_key. It’s an entity that’ll load a model, either a .mdl or a .bsp, and for all practical purposes act like a key. You can pick it up and as soon as you touch the matching trigger_lock, the trigger will fire and thus open a door, or whatever else.

A level can have up to 4 custom keyitems (on top of the 4 predefined keys). You have to define their names in worldspawn, and set the matching spawnflags on both an item_key and the trigger_lock it belongs to. You can do a little show with the key’s name, model, and any sounds played when picking up and opening the lock.

• Keyitems will travel across maps.
• Keyitems will be displayed in the inventory. The command for this is, well, ‘inventory’.

item_backpack: You found a backpack full of ammo!

This allows you to place a backpack item in the level which the player can pick up. You get control over the backpack’s contents, of course. It can contain ammo, health, and/or armour – the latter are conceptually stimpacks, health packs, and armour shards. See .def/.fgd file for details.

item_grappling_hook: The Grappling Hook

Gives the player the grappling hook.

item_stimpack

A stimpack. Gives the player 5 health points when picked up. Appearance is dependant on worldtype. These make good casual pickups, for example around fights and in areas that are a little harder to access, but not quite a secret yet. Be aware that these give 5 HP each! Five stimpacks are a full medkit.

item_armorshard

Armour shard. Gives the player 5 armour points when picked up. Appearance is dependant on worldtype. Much the same goes for these as for stimpacks. Keep in mind that picking up stuff is a reward for the player, as well as a motivation to keep playing. Stimpacks and armour shards are candy for the player, pretty much. Don’t overdo it; three shards are quickly picked up and are equivalent to 15 points of green armour (or whatever color of armour the player is wearing). Three shards can be 15 points of red armour! A few of these can make the player survive several cauterizer (railgun) hits. Be aware of this especially in multiplayer maps.

misc_

misc_model: Load an external static model

Using misc_model (func_model also works) you can position an external model inside your level. It loads any of the following things:

• Sprites (.spr)
• Models (.mdl, so far)
• Maps (.bsp)

and displays them in the level. They will be nonsolid (edit: what about bsp, I forgot) and dumb. BSP files have to be pre-lit and centered at (0 0 0) in the map editor. They do not need to be vised.

Mapmodels can be anything, really. Trees, bodies, ladders, terrain, rocks, plants, barrels, boxes, furniture, flags, handrails, chains, pipes, mysterious modules, pianos, decoration of any sort, even complete parts of a level. Anything that is dumb and doesn’t animate. The catch: You’ll have to create them, either in a model editor (Blender, Max, Maya) if it’s a .mdl, in a map editor in the case of a .bsp, or in a program like Fimg for sprites. You can place clip brushes or func_nodraws around a mapmodel to make it seem solid to the player.

A benefit of doing for example a ladder as an external .bsp is that its faces, vertices etc. won’t count towards the limit. Neither will it affect VIS. Terrain is something that can very well be done as a model. Another benefit is that you can build something once, then load it a dozen times as a map model (trees for example, anything that you need a lot of). Finally, you can rotate mapmodels to suit your needs, while rotating world brushes in the map editor can be quite shitty and error prone.

Mapmodels do not cast shadows.

Pro tip: See how much of your level you can turn into models. Everyone likes to play that game a lot these days. 😛

monster_

Monsters in ReMakeQuake are expanded over their old versions, having new abilities, new ai and various tweaks to fit them in with our modified weapons and additional stuffs.  Additionally they can be given new abilities and different behaviour via spawnflags, this being loosely described as wargear.  Something to note is that the monsters in RMQ typically don’t have more health than the standard id1 versions, unless their function in the game depends on them being tough to kill.  Usually they will have an expanded set of attacks and AI routines, making them more unpredictable, and often more dangerous, instead.

Below are listed all the monsters and any relevant changes and abilities to keep in mind when mapping with them.

Global Changes:

Roaming

Monsters, unless toggled not to, will roam around the place, not staying put.  Spawnflags like AMBUSH and SLEEP will also stop them from roaming.

Melee Hit View Shake

Melee hits will knock the players view (and the player) about – copied from Doom3, although not as annoying.

Projectile Speed

All enemies that fire lineal projectiles (as opposed to hitscan or homing attacks) will do so with a speed defined relative to the difficulty level.  Someone on skill 3 will have player speed enemy attacks to deal with.

Random Health

Each monster will decide its health on birth, with the original value as a starting point.  Again, this is also relative to the skill setting, so the higher the skill, the tougher the monsters.  Don’t expect random super Grunts or wimpy Shamlers, there is just enough variation to give the player the occassional surprise.

Z-Aware Aiming

Monsters that make attacks with an arc (grenades, some magic, anything thrown) will do so relative to the player’s vertical position, being able to hit targets that were out of their reach before.

Infighting

Monsters have modified infighting, explained under their relevent entry below.

NB: Monsters with the same monstergroup key will act as a squad, and will not infight, instead focusing completely on the player and alerting each other.

Spawning

Based off of Preach’s code which was advanced in Quoth we’ve included monster spawning.  As per Quoth all monsters can be spawned in (won’t appear until targetted) via the SPAWNED spawnflag.  They can also be set to STEALTH and ALERT.  The former will make them not produce a teleport sound (or effect) when spawning in and the latter will make them immediately angry at the player.

Due to the .def and .fgd file sometimes being written independently of each other, STEALTH is also known as SILENT and some monsters can be called by alternative names, like monster_oldogre / monster_xogre. They do the same thing.

Gyro

Monsters are physics objects. So are their projectiles. For example, ogre grenades now have physical properties that make them react to water, react to being shot at with a rocket, react to explosions etc.

Drowning

Poor monsters are often too stupid to escape water. This is still being worked on. They will usually drown.

Burning

Monsters placed near lava might be stupid enough to fall in, depending on their behaviour. Some weapons’ gyro effects will also knock them in. Falling in lava will violently kill most monsters.

All of those are still WIP, you can safely assume there are more of them coming and we’ll fill them up with wargear and options until we absolutely run out of spawnflags. Some tweaks to the AI are being discussed that aren’t even mentioned here.

monster_fish

Fish go unsolid right after their death so as not to block a player from trying to reach air – this idea taken from Quoth.  The mesh also has the fabled head fix, rumoured to be in various places but not there.  Basically in id1 the head of the fish shrinks when it dies, so we hunted down the fix for that and included it.

SMALL: Fish can now be flagged as small, which reduces both their health and size to something more piranha-like.  They also get a slight speed boost.  Using these in unlit areas isn’t recommended since they’re harder to see.

monster_dog

The only change so far is that a Dog will detect invisible players by smell, and alert other monsters to the interlopers prescence.

monster_flyer

This new enemy is the equivalent to a tech scrag, with three modes of behaviour and a near-death attack.  When very low on health it will become frenzied – stop moving and fire constantly in an inaccurate spread at its target until destroyed.  By default Flyers are only moderately aggressive, although they will always circle-strafe any potential victim relatively quickly, even if they’re not attacking.  Flyers will always close to an enemy and circle them, their attack frequency based off their emotional state, as set by their spawnflags.  They are fast moving and have low health.  A good annoyance enemy that will bring the fight quickly to the player over any terrain.  When destroyed a flyer will break into custom gibs.  It’s worth noting that although it explodes, the explosion does no damage.

PASSIVE: This makes the flyer more of an observer, like the HL2 camera drones.  It still keeps its frenzy behaviour though, so if shot at can produce a nasty surprise.

AGGRESSIVE: The player loses all its timidity and goes into highly aggressive mode, whilst still using its strafing routines.  In this mode it is a much higher priority target.

monster_army

Strafing – grunts will strafe whilst making ranged attacks now.  Not as fast as Nehahra enemies, but more of a challenge than the old version.

NAILGRUNT: Comes packing a nailgun with which to spike the player at longer ranges.  Will fire continually, reloading occassionally.

AXEGRUNT: An even more psychotic version of the normal one, this guy wields only an axe and is pretty fast on his feet.  As well as this he has a slight chance to throw a single additional axe at the player for a healthy whack of damage, relavant to the current skill setting.  They also take advantage of the MELEE_ONLY trigger_monsterjump flag in this mode.

monster_turret

A static turret, good for defending base entrances and the like.  Fires standard blaster shots, as always these are faster on higher difficulties.  Relatively low on health, a single well placed grenade or rocket will take it out.  One thing to consider is that a turret explodes with relatively high-yield damage when destroyed.  This can injure nearby enemies or seriously hurt any player stupid enough to melee a turret.

DOUBLE / TRIPLE: This either doubles or triples the firing output of the turret, also adding a larger firing pattern – making it slightly more difficult to dodge.  No other effects.

monster_enforcer

These crack troops have a bit more intelligence in RMQ as well as a range of wargear that the mapper can set on them to give them new abilities.  Firstly, they will use a new AI routine called Overwatch on players who run away.  Instead of running blindly after the player an Enforcer will occassionally go into Overwatch mode.  This means that he will wait there until the player moves back into view, and at that point launch a rapid barrage of laser blasts in their direction.

Additionally, Enforcers have a small chance to launch a grenade at the player.  Again, this is dependant on skill – higher skill = more grenades.

Note that the Enforcer spawnflags are wargear – they can be combined to create a much more powerful enemy.

HYPER / HYPERENFORCER: Carries a powerful hyperblaster.  This souped up cannon delivers laser blasts at a much higher ROF than the standard blaster and is good for pinning players down, keeping them cowering behind cover.  Visually the model changes to wield a Q2 Hyperblaster – expect this to change in future iterations.

HUNTERKILLERS: In a tribute to the HL2 MetroCop the Enforcer’s grenades are swapped for what can best be described as a flying homing bomb.  This is a massive damage surprise attack and must be treated with respect.  It is also pretty good at killing other monsters, or the Enforcer himself.  Use in open areas if you want to make sure only the player gets hit.  Also, there is no visual indication that the Enforcer is carrying these lethal items.

monster_zombie

A shambling undead, much like the original but with some subtle differences.  They chuck their gibs at the player regardless of height, they revive after being knocked down at a random time (no longer can the player wait exactly five seconds and fire a grenade) and, most importantly, they can be gibbed by the DBS and melee weapons.  The former is at close range and both involve the player putting themselves at greater risk – getting into the thick of it and being hit by gibs unless they’re very fast.  The zombie model includes two additional skins.  Giving the monster a skin value of 1 makes it a mummy and 2 green.  This is a purely cosmetic change, but maybe it’ll look better for your map.  Additionally all zombies now have custom gibs, so expect to see arms and legs flying when you manage splat one.

CRUCIFIED: The classic – no changes yet.

SLEEPING: This makes the zombie inert until targetted – it just lies there on the floor.

UNDERGROUND: Similar to the above, except the zombie isn’t visible and will rise up out of the ground when targetted.  An easy way to recreate the classic id/Zerstorer rising from the grave spawn effect without having to mess about with brushwork.

monster_wizard

The scrag has one important difference and a secondary ability which enhances their unnerving primary one.  Upon taking damage a Scrag will sometimes ‘Blink’ – teleporting themselves to a different position to avoid further immediate damage.   This ability is skill dependant – they’re much more likely to perform this manouvere on higher skill settings and incapable of it on easy mode.  One  exception is when a Scrag is infighting with a zombie.  Thanks to PM’s Cranked code they will always telefrag the offending zombie, then turning their attention back to the player.  The secondary ability is akin to ventriloquism.  Whilst angry at the player they will throw their ‘voice’ to another point, always leaving the player unsure about where the next attack will come from.  To clarify, the idle sounds may come from behind, above or below their target, whilst the Scrag itself gets into position to launch its next volley of attacks.  This doesn’t change their usage in maps a great deal, but does make them more interesting and eldritch to fight.  Additionally, Scrags produce custom gibs on death.

monster_vomitus

A burping monstrosity made from scraps of undead flesh amalgamated into a cross between a medic and caretaker.  Current version vomits blood and globs of meat at its victims and can occassionally swallow grenades fired at it to spit them back at aggressors.  As well as this it has zombie style regeneration – if it takes enough damage to become deflated then it will eventually reanimate after a random delay.  It also has a very heavy melee attack, taking a massive bite out of any foe who gets close enough – which also restocks it’s gib ammo and recovers health.  Future versions will be able to create zombies by eating corpses.  These are best used for slowing the player down and providing support for packs of zombies, like an undead tank.  Their attacks will not make zombies infight, so they can be mixed in with both zombie and zknights without risk.  Vomitii track their quantity of gibs eaten and can be given additional on startup by giving them ammo_shells.  Gib ammo is slightly better than regular, blood ammo since it bounces and is therefore more likely to hit.  They can also be given starting grenade ammo by adding a value to ammo_rockets.

SLEEPING: Like zombies, Vomitii can be made to start sleeping.  In this mode they will not awaken until targetted.

monster_ogre

RAAR!  The Ogres are back, with a variety of weapons, bad breath and attitude as well as a few other tricks.  Generally, the Ogres do a lot more damage but are more vulnerable to the RMQ weapons.  A single point blank SSG shot will knock one down.  In balance, their chainsaw and other attacks will cut down players much quicker than before.  Aside from the rocket ogre, all ogres are much more fearsome in close combat.  Also they have a corrected bounding box, meaning that the player has to actually hit them now.  This is important with the RMQ shotguns, which have a wider spread – meaning point blank is the best for max damage.  When gibbed Ogres will produce custom gibs.

NAILOGRE: Fires a spray of nails at the player reminiscent of Kinn’s maps, instead of his grenades.  Will fire these on the run, trying to close to melee range with the player.  Bearing this in mind, you should place them where they have a reasonable chance of getting close – the nail spray isn’t a particularly long ranged attack either.

ROCKETOGRE: A rocket launcher replaces the grenades.  Unfortunately it is two-handed, so the Ogre loses his chainsaw when using this weapon, having to rely on a bayonet attached to its front.  Best used at long range – up close the player can make mincemeat of these guys.

BERSERKOGRE: This Ogre opts for double chainsaws as opposed to any ranged attack.  The main difference is that he swings the saws twice as fast – being close to one of these will reduce any player without pent into mush very quickly.  They also take advantage of the MELEE_ONLY trigger_monsterjump flag in this mode.  Completely useless at long distances, these are best either surprising the player or in enclosed spaces where the player can’t run away as easily.

monster_xogre / monster_oldogre

These ancient Ogres were never conquered by Shub-Niggurath and have led an independant existance from their more technologically advanced yet enslaved cousins for thousands of years.  Physically, they’re bigger and tougher, although eschewing ranged attacks – despite the odd thrown axe.  They wield a large shield as well as their endless axe supply, which due to various magics is able to deflect any attack, conventional or otherwise, when used properly.  Additionally, they have limited magic use, being able to recover from their injuries in the thick of battle.  In terms of toughness an Elder Ogre ranks about the same as a Death Knight or Vore.

monster_tarbaby

No changes yet.

monster_dweller

Aka the frogman.  These stygian foes currently have a harpoon to fire at the player and are unique in Quake’s menagerie in that they function both underwater and on land.  As well as the harpoon they can also claw at the player with a moderately damaging melee attack.  Usage is as a mid range fodder enemy.  Their dark skin makes them hard to spot, so players tend to close in on them for the kill.  Current version is much more powerful underwater.  In their own element they will quickly spear the slow-moving player to death.  With this in mind its worth giving the player advantages when fighting these creatures underwater – extra health, breathing spots and so on.

monster_knight

These guys have additional wargear in the form of a crossbow option.  They will also use subtle skin changes randomly for a bit of variety in your horde battles.  Additionally, they can be undead.  Finally, they can pray at the altars, shrines and bloody sacrifices that you construct.

PRAYING / CRUCIFIED: If a normal knight then they will pray, producing a monotonous chanting and not waking until damaged or activated.  If also undead then this crucifies them – follow the same placement rules for crucified zombies (12 units into the wall, facing away from it).  They will writhe in pain from the nails holding them there and, randomly, having their own sword jammed into their thorax.

CROSSBOW: The knight has an accurate, though low ROF ranged attack.  Currently they will stick to this even if the player is in sword range, so are best used at medium to long distances.

ZKNIGHT: A shambling undead, clad in armour.  This means they can’t rip off bits of their own bodies to throw, but are also resitant to most other anti-undead tactics thanks to the armour plate.  The idea is for them to slowly trudge in until they trap the player in a corner, at which point their clumsy attacks will eventually bring them down.  Explosives are the players only real option against these monsters.  Note that they won’t infight (or take damage) when hit by vomitii or zombies.

monster_hell_knight

Again, from Cranked, the Hell or Death Knight will use all of its animations to launch attacks – firing vertical and straight shot spreads of fireballs in additional to the classic horizontal.  As well, he will also make more varied melee attacks and succumb to a frenzied modifier (meaning higher damage) when low on health.  So far his spawnflags haven’t been implemented.

PRAYING: The same as regular Knights, the Death Knights can also be made to pray to the dark god of your choice, or Mexx.  This functions as an alternative AMBUSH stance with praying animation and chanting.

monster_shalrath

Currently the Shalrath has a modified voreball ability, her multi-voreball abilities not yet implemented.  The new Voreball functions similarly to a drunken rocket style attack. Like a few others, the Vore is a potential spellcaster, but its default caster_level is 0. You can set this to 1 or 2 to give it varying levels of access to the spell library. This will make certain Shalraths a lot more intimidating.

monster_proto

QTest shalrath, RMQ style. The proto-shalrath is an elderworldly mage and cultist, and if you see one of those guys you better be prepared – or run away, quickly. Default caster_level 1. Caster_level on this guy can be increased to make his arcane skills not even remotely fair to the player. Even more of a mini-miniboss than a spellcasting Vore. Like all spellcasters, he’s fueled by the Necr… I mean magic.qc.

monster_demon1

Currently the only change for the Fiend is that it can use MELEE_ONLY monsterjumps.  I also removed the spikes from its head again, to better show its eyes, and because asthetically they look stupid.

monster_shambler

The big guy, as yet, has few additional capabilities.  What is there follows Lovecrafting / Bloch themes, specifically their DIMENSIONAL spawnflagged ability.  Simple changes come from Cranked and give them slightly better AI – able to break their berserker charge, giving them an advantage against ‘dancing’ players and an automatic two handed smash against undead targets, resulting in an instagib.

SLEEPING: The shambler is sleeping the deep sleep until he’s disturbed.

DIMENSIONAL: This is a spawnflagged ability since it represents a major change in the tactical approach required to defeat a Shambler.  Basically, if the player runs away then the Shambler can teleport itself to a point nearby to continue the attack.  This is disconcierting and very dangerous.  Personally, I think it’s the missing piece of the puzzle with this enemy – the player should never feel safe if they’ve pissed off a Shambler.  It’s skill dependant, disabled on easy.  After a certain amount of time without seeing the player a Shambler angry at them will teleport itself to a nearby position.  Currently it’s not perfect, since the Shambler may well teleport themselves into a hazard.  The next step is to fix their escape via teleport from hazard code.  Also, this turns on a secondary, cosmetic ability.  When a DIMENSIONAL Shambler is killed it will attempt to teleport itself home just before death.  Sometimes this works, sometimes not.  Failure state results in gib rain.

monster_boss

The original fat red guy with spikes.  The only change is that he can be knocked out by damage like a normal enemy.  Not really used in RMQ anymore, but not removed either.

monster_lavaman

The scaled down version of the above from the DOE mission pack.  Fairly crappy enemy really, although the new boss1 will most likely gain some minions, inspired by these.

monster_boss1 (WIP)

A more arcane imagining of the original (retextured placeholder?) model.  Also with a new range of attacks and vulnerabilities.

monster_boss2 (WIP)

This foul creature is the owner of the Manse and a horrific opponant with a large range of deadly attacks, spells and unique abilities at his disposal.  Not to be underestimated.

monster_oldone

Unchanged and will become obsolete, though not deleted to maintain backwards compatability.

Dragons

Dragons in RMQ come in 4 sizes and three colours, and with a lot of attitude, thanks to PM’s Dragons 2008. They haven’t been improved much since then, probably because nobody has truly made full use of them yet. However, they will feature prominently in at least one map, and when their time comes, they will be polished until their scales shine brighter than the purple sun.

They share a number of spawnflags which affect their behaviour. Besides the SPAWNED, SILENT and ALERT flags, you can set the following:

PACIFIST: Dragon will be peaceful

FAST: Stronger, more agile

SLOW: The opposite of FAST

FLAT: Cannot fly up or down

If both FAST and SLOW are set, the dragon’s intelligence varies according to skill level.

You must set the skin key to determine the colour (type) of dragon. The different types also use different forms of attack. Set skin to one of the following:

0: red (fire)

1: green (slime)

2: blue (lightning)

3: white (ice)

monster_dragon_small

Small dragon, 200 HP.

monster_dragon_classic

450 HP dragon. I think we should reduce these to small, medium and large, btw, and we should also reorganise the spawnflags to make them do more interesting stuff. Don’t use _classic for now. Dragons will get an overhaul in the future.

monster_dragon

Fully-grown dragon, 800 HP. Should eventually make this a link to _medium.

monster_dragon_large

Miniboss caliber dragon; 1800 HP.

rotate_

rotate_door: Rotating doors

RMQ includes code for rotating entities with proper collision, without using any hiprotate-style hacks. If your map uses these, the map compiler (qbsp) needs to support them. RMQ’s TxQBSP2 and Lord Havoc’s hmap2 compiler supports this type of rotating entity.

What you do, quite basically, is create your door geometry and turn it into a rotate_door. You target it at an info_null sitting exactly on the center, or the axis, of rotation (like an origin brush, but we’re using a point entity instead).

The axis around which it rotates (sideways, up/down) is set via spawnflag. The amount of rotation is set, in degrees, via the ‘distance’ key. Negative number here means “the other direction”. A ‘speed’ key can be used to determine how fast it spins. And that’s it, folks.

You can set most of the usual door attributes on these, including gold/silver key, toggle, start open, wait, etc. Bronze and platinum key do NOT work on these since there aren’t enough spawnflags due to the rotation-related ones.

If you want two of these to rotate in unison, you have to set the ‘linkname’ key on both to an identical string.

rotate_continuous: Continuously rotating bmodel

Very similar to the rotate_door, except it keeps rotating. Fans, pumps, and whatever else rotates continuously can be done with this. As an added benefit, you can make it change direction, accelerate, and decelerate when triggered. Has collision all by itself, no need to mess with anything besides the actual brush geometry and an info_null, again to mark the axis of rotation. Direction of rotation again set by spawnflag, check the def/fgd files.

RMQ does not have a rotate_train yet. I guess nobody needed it so far, but it will come. RMQ supports Hipnotic rotating entities though, so you can have a rotating train that way until ours is done.

trigger_

.is_waiting: Waiting triggers

By setting ‘is_waiting’ to 1 on a trigger, it will not activate before it’s been triggered itself.

Example: A slipgate that the player needs to activate; the trigger_changelevel would have is_waiting set to 1 so the slipgate would not work until activated via trigger event (trigger_lock, button etc).

Example 2: A func_ladder whose geometry is actually a func_door that is extended by a button. The func_ladder (trigger brush)  itself would have is_waiting set to 1 and would be triggered shortly after the actual ladder geometry is extended. (Think Doom 3 activating service ladders). Yes, func_ladder would be more aptly named trigger_ladder. Hey, that works as well though. Whatever floats your boat.

Example 3: A teleporter that’s activated by a button. And so on.

.target2, .target3… : Multiple targets

As in Quoth and Custents, you can trigger more than one target now with a single trigger. You can have up to six targets and two killtargets.

trigger_checkpoint: The Checkpoint System

In addition to the old quicksave and quickload feature, RMQ will save your game at the beginning of a level, and at each trigger_checkpoint you encounter. If your player character dies, the game will load the latest checkpoint save. You will not have to play through the entire level again, even if you forgot to quicksave.

Trigger_checkpoints are placed by the level designer just like trigger_once. They need no target, they simply do a checkpoint save. It is wise to place these at a few points throughout the map, especially in conjunction with traps or puzzles – having to redo a puzzle because you got ambushed by a hyper enforcer, or fell victim to the Swarm, or got pasted or nailed or succumbed to a forcewall spell, is frustrating. Remember that trigger_checkpoint can have is_waiting set to 1, so the player can pass through it multiple times without anything being saved, until the checkpoint gets activated by something.

{texturename

“fence textures”

To create alpha masked textures, ie textures with see-through parts, paint the invisible parts of the texture with palette index 255 (pink), using a program like Wally or Texmex. The name of the new texture must begin with ‘{‘. Only supporting engines, such as RMQEngine, will display these textures properly.

Texture a brush with these and turn it into a func_wall or similar. All faces behind the see-through parts will be culled.

For replacement textures, turn the see-through parts of the replacement transparent, using a graphics program.

Alternative way to get alpha-masked textures into the game: Oriented sprites (created with Fimg 2) and a misc_model. See misc_model.