All brush based entities now support loading models from external files, rather than from models within the bsp file of the map. Simply create a point entity with the correct classname, and set the "model" field to the path of the model file. For example, to create a func_illusionary of an exploding box, set the "model" key to "maps/b_explob.bsp". You can use this method to create a prefab like a door or wall fitting, and use the same model repeatedly throughout the map, which will save precaches. If you are creating your own external models, we recommend creating a subdirectory of /maps with the same name as your map filename. For instance, models to be used in the map slither.bsp should be kept in maps/slither/.

To create new models, simply make a new map in your editor, design your model and compile it. Run light on it, but there is no need for vis. Then place the newly compiled map in the required folder. The origin of your map will correspond with the origin of the point entity, so bear this in mind when building the model. Since this will also be the center of rotation for your model, this feature can be useful for making rotating entities. Care must be taken to light your model in such a way that it suits the region of the map it is placed in. If the model will be static, it will not have the correct world lighting that an internal model would have. If this model if used in a moving entity, you can make sure the lighting is believable for the entire journey of the model.

Again, to help worldcraft users, you can add the suffix _point to any func_ classname to create a functionally identical class of entity. See also

Contents

All items that can respawn in DM can be made to respawn in SP with the "ritem" key. Set this to 1 to enable this behaviour.

If the "respawndelay" key is set, will override the default respawn time to whatever is set.

If the "respawncount" key is set, this item will only respawn that many times, and will then remove itself after it has done so.
This is useful to set a cap on the amount of times it can be picked up. Very nice when you have an arena fight and you don't want to clutter the whole area up with items, or to make a healing pool that can be eventually depleted.

Contents

Feel free to put fish in your maps.

Contents

A highly maneuverable flyer. He'll try to stay slightly above the player by flying upwards whenever he shoots. If the player is far below him, however, he won't fly up, choosing instead to go lower, down to the player's level. On Nightmare skill, the bobbot moves slightly faster when firing.

Necros says
Because of their maneuverability, fights with these guys may last longer than your typical quake monster fight would, and because of their small size, the SSG is mostly a waste against them. Keep this in mind that players will want to use nails the most to take them out, or if there is one bob alone, a normal shotgun should do.

Kell says
Aiming at bob is the hardest part of combat here, with dodging his laser volley coming second. Nail weapons feel the most natural against bobbots, but the RL makes for a good challenge because it only takes a couple of hits but those hits may take a bit of effort to score. As with other flying monsters, distance makes the GL and LG less effective. The PG will burn them down very fast, but if the player wields it in later areas of a map several bobbots can be used without overwhelming the combat.
Try to give bob a bit of space to maneuver. The simplest way to achieve this is to raise the ceiling height of a room.

Contents

Fires mildly tracking, weak, explosive missiles at the player. The missiles gradually ramp up in speed, so they track marginally better at close ranges (distance < 500) while they are still moving relatively slow. They will accelerate forever, however, so quickly start moving rather fast. They can't track very well at this stage, but they make up for it in fast movement.
Also note that the missiles won't home on to the player when he isn't visible. If the player goes out of sight, the missile will continue moving forward and accelerating, waiting to try to find a lock on the player again if he becomes visible later.

Necros says
Your standard long range irritant, really. Use these guys at a distance, and they'll be fine. They are nearly useless in melee, however. Also, at 60 health, they aren't tanks. If the player sees them early, they'll be lucky to get one shot off. Keep this in mind when placing them in your maps.

Kell says
These guys are fun, and the way the rockets track makes them much more interesting to fight than other sniper monsters. But because of this, the challenge and - possibly - frustration increases exponentially with each additional rocketeer in an area; 4 rocketeers is far more than 4 times the challenge of just 1. In later areas of base maps, their low health may make it tempting to include more of them, but also consider mixing other monsters in.

Countermeasures
They're still grunts, just with redder armour. Shotguns will deal with them fairly quickly and anything above that can swat them like flies often before they get a shot off. Placing rocketeers for surprise can balance this, as can restricting the use of certain weapons by range or ammo. Placing rocketeers far apart is a good way to increase their chance to shoot, since even the most powerful weapon takes time to turn 180° and aim.

Contents

A base map variant of the ogre, he'll lob grenades at the player if the player meets two criteria:
1. The player must be below the defender
2. The player must be at least ~200 units away from the Defender to prevent self-damage from explosions.
If the player is above the defender, or close to him ( or both ), he'll switch over to the Super Shotgun.

Beyond that, he behaves just like any other monster.

Necros says
Since they have two viable weapons, they can be used pretty much anywhere. They are your general purpose monster after enforcers, with slightly higher health and more powerful attacks. If you need a bombardier, place them like you would an ogre, otherwise, anywhere will do.

Kell says
Solid soldiers, but they won't tank the player instantly unless they have backup. Their use of a shotgun at close range can be utilised for cheap surprise attacks behind doors - especially key doors - at the top of lifts or the other side of teleporters. If you place defenders where they can use their shotguns, however, provide a little health afterwards or players may hate you ;)

Countermeasures
Plugging away with the SG at medium range is much the same against defenders as enforcers. Should the player end up in their shotgun range, a diplomatic exchange of buckshot can be quite fun despite how low those weapons are on the inventory. Nail weapons will chew with satisfying ease, especially given the more lengthy and theatrical pain animations in the model. Once trading explosives with defenders, only being below them - as with ogres - will make them a serious threat.

Contents

Preach says
The pyro is a close range attack force for the enforcer team. At long range they can be picked off easily by the player. At close range a full-on blast from the flamethrower can be very damaging. In addition, the flames will fill small corridors and rooms, distracting and disorienting the player.
Pyros will infight with other base monsters, and their attack covers such an area they are likely to hit something when placed in mixed groups.
On the other hand, pyro flames will not damage other pyros, increasing the effectiveness of groups comprised solely of pyros. Multiple pyros in a single location will make it very hard for the player to see anything, so care should be taken.
The flames are stopped by water, so giving the player a pool to dive in near pyros will make them easy to handle.

Additionally, the biosuit powerup will endow the player with the same flame-retardant property the pyros themselves enjoy. However, only the player's health will be protected - their armour will still be burned away by the flamethrower.

Kell says
The pyros are slightly odd in that they wield a weapon with no equivelant in the game. The closest approximation would be an area effect lightning gun. This unfamiliarity makes them a little harder to understand, for players and mappers.
The most useful thing to consider with regards placing of pyros is that the low damage coupled with high rate of fire of the flames has the consequence that if the player is wearing any armour at all, it will deplete far faster than their health. In fact, no health points will be lost at all while the player retains some red or even yellow armour.
Add to that the 15 health each pyro drops upon demise, and what you have is an enemy unlikely to leave the player seriously wounded but quite possibly naked. The pyro is an armour-stripper.

See kellbase1 for this effect. The 4-pyro combat in the rusty basement most likely removes any GA left on the player after encountering the 3 edies above. Once they leave that area and climb the ladder to the ventilation section, even a handful of vorelings in the dark can make the player feel vulnerable because they only have their health to survive on.

How best to make use of this in your map is somewhat oblique, but it can be useful to burn away what armour the player has left after a combat so the next armour they find in the map is sure to be acquired, and even welcomed. It also allows the arc of increasingly powerful items to be varied, so the player doesn't simply advance uninterrupted from green to yellow to red over the course of a map.

The short range but broad area of the flamethrower means you want to keep the pyros for smaller areas. They're not snipers. Instead, they can act as interdictors, aggravating the player's attempts to progress down narrow corridors and walkways, or grouped in rooms around vital items like keys.

Contents

Preach says
The eliminator is an elite enforcer, with a much more powerful attack from the plasma gun. They are effective in the same situations that an enforcer would be, but remain viable when the player has higher powered weapons available. Because they are protected from splash damage ( but not direct hits ) inflicted by plasma attacks - including their own weapons - in larger groups they are less likely to kill each other.

It also discourages the player from simply whipping out their own PG whenever they meet eliminators, both of which are likely to appear in the later stages of a base map.

Kell says
As the supposed elite of the enforcer reskins, it may seem odd - and perhaps disappointing - that the eliminator does not arrive with an array of weaponry comprehensive enough to make an action hero envious. But this is not a shortcoming of either the eliminator or our imaginations. They are designed to be simple. Shoulder cannons, forcefields, multi-bombs, and other such exotic monster attacks - while cool on paper - do not neccessarily translate into absorbing gameplay. The eliminator is the top of the enforcer team precisely because his equipment is powerful enough on its own.

The simplicity and similarity of the eliminators' attack to the enforcers' makes them easier to get to grips with for both players and mappers. Players tackle them with the same manoeuvers as they would enforcers, but with the certainty of a much greater penalty should their skills be found lacking. Mappers can place them just like enforcers, but towards the end of a base map where the player can comfortably be awarded the equipment normally reserved for tackling things with bigger bounding boxes and fewer eyes.

Contents

Preach says
The Scourge is the mechanical scorpion from the Scourge of Armagon mission pack. It is one of the few base monsters to have a melee attack, and so can be useful to drive the player back and engage at range.

Kell says
A straight rip of the terribly cute cyber-scorpions from mission pack 1. One of the most popular choices for expanding the ranks of the base enemies, and rightly so.
The centroid is:
1. Not another bloke with a gun.
2. Cool. I mean seriously, a cyborg scorpion? Fuck Skynet.
3. Armed with comprehensive - rather than gimmicky - weaponry, including a decent melee attack.

The large bounding box and medium forward speed of the centroid are its limiting characteristics. They will manoeuver adequately around a base map, but deliver their sting primarily because of a generous supply of nails. And although they don't charge quickly, they can rotate to face the player quite fast. The result is essentially a mini tank, an enemy that advances relentlessly while hosing ammo into the room.

Although plentiful, the nails are weak and innaccurate enough that players can stay in the open if they either keep moving or have good armour. With less armour or more centroids, the player will quickly run for cover to escape the iron hail. Good for cat-and-mouse stalking amongst a cratescape, or place centroids in deliberately empty areas when you want to make the player really feel under attack.
The melee tail strike is there to punish players who attempt to deal with the nailguns by charging rather than dodging, but can also be employed by placing centroids in confined spaces where the player will stumble into them.

In open areas and at medium range, the centroid can detect and attempt to dodge incoming projectiles. Faster projectiles, like the bursts from the plasmagun, are usually too fast for the centroid to dodge. But slower projectiles, perhaps rockets at medium to long range, might miss. The centroid's nimble strafing also makes them harder to hit, giving them a little longer to spray nails at the player.

Centroids are useful guards; the bounding box, nail barrage, and deterent of the tail strike mean they are likely to discourage the player getting past them to more desirable locations, like supplies on the far side of a room or an escape route.

Generally, use centroids when you want to throw a lot of nails at the player, and force them to throw a lot back or retreat.

Contents

classname: monster_sentinel
health: 150
size: small
ranged: lasers/nails
melee: none
special: flying

Kell says
The sentinel was inspired partly by the spikemines from Scourge Of Armagon, partly by the spike-shooters in e2m7, and also by the desire to have another aerial enemy more Quakey than bob.
The result is more akin to a trap than a conventional monster; something that is deployed under special circumstances and behaves systematically rather than intelligently.

The best placement for sentinels is in chambers that are high, wide, or both. The more space the better because it is the attempt by the player to predict and avoid the unrelenting projectile barrage that defines sentinel combat, and this requires time.
The eerie way in which the sentinel will closely match the player's height, but remain otherwise unresponsive to events is effective if you can herd the player in a particular direction. Have the player tracked by sentinels while trying to ascend a series of ladders and catwalks in a giant hangar. Deploy them in the sky over an outdoor landscape across which the player must navigate to safety like a 3D minefield.

Any weapon with a good range is fine for knocking sentinels out of the air - their relatively slow movement means the player only has to correctly time their emergence from cover.

Contents

classname: monster_edie
health: 450
size: large
ranged: nailgun volley
melee: buzzsaw
special: none

Preach says
Edie is a vore level monster for base style maps. His nailgun fires in 10 round bursts, with spread enough that the player will find it difficult to avoid all the nails without some form of cover available. At close range the buzzsaw lifts the player as well as damaging, and is also harder to avoid than a shambler's melee. This means providing something to hide behind is more important for an encounter with an edie than with a shambler. The amount of cover provided can depend on the level of weaponry the player possesses.

Kell says
Edie is our candidate for 'larger base monster' although his design is intended to fit in metal or medieval maps too.
Like the centroid above, edie is large, slow and essentially a walking tank. His supernailgun can deliver a substantial amount of damage, but only if the player stays exposed long enough.

Contents

classname: monster_ogre_flak
health: 200
size: large
ranged: flak gun
melee: chainsaw
special: drops 10 nails

Preach says
The flak ogre differs from a conventional ogre only in the ranged attack it possesses. The flak gun fires a pattern of nails at the player. The primary advantage of this attack is that it can fire at a player who is elevated above the ogre and still do damage, unlike the grenade launcher. It can also hit the player from further away than a grenade can.
The direct attack of the flak gun can be dodged as easily as a grenade, but if it misses the player it does no damage at all. A grenade lying on the ground still poses a threat. So attacking from above, the conventional ogre is more effective. Also of note is that the flak ogre yields nails when killed rather than rockets, which can be useful if you wish to limit the player's supply of explosives during the early part of a map.

Kell says
This is a straightforward reskin, intended to be a simple and useful expansion of mapping options.
Everything except the ranged attack and elements of the skin are deliberately identical to the grenade ogre, including the frequency with which the flak ogre will fire at the player and its tendency to go into protracted pain animations. This means that placing and fighting flak ogres is intuitive, but the flak opens up a few more options for combat.

The flak is fixed to fire in a cross of 5 nails, rather than spew randomly like spikey buckshot. This is also to allow combat to be intuitive and reliable, where the mapper's planning and player's skill determine the outcome.

The skin just incorporates a bit more metal onto the traditional grubby leather to help identification at a distance without commiting thematic heresy, and perhaps because the flak ogre has better taste in music.

Really, you can put a flak ogre almost anywhere in any map and you'll have instant Quakey goodness.

Contents

Quake has never had a small, weak, scittery monster ( the closest is probably the gremlin in Scourge Of Armagon, or the rare appearance of custom spiders ). The voreling is designed to be the Quake equivelant of the facehugger from Aliens or the headcrab from Half-Life.
Its characteristics are what you would expect of such a creature - small, weak and fast.

Dangling
Vorelings can be made to begin in a map hanging from a ceiling so that they can drop down on unsuspecting players. To do this, place the monster below a ceiling and set the key/value "dangle" "1"
It does not have to be placed precisely, it wil be 'autoraised' into position.
The voreling's exact behaviour proceeds as follows:
Normally, monsters will awaken when they 'see' the player; however, when a voreling is dangling from the ceiling this behaviour is overriden. Note also that its idle sound plays less often. Sneaky buggers.
Vorelings will not detach from the ceiling even if they see the player. They will wait for a short while to see if the player will move underneath them.
Two things can happen. If the player moves away, the voreling will give up it's plan and detach to attack the player. If the player continues to close and move under a voreling in dangle mode, it will detach and fall on the player, inflicting damage. Afterwards, it will behave like a normal voreling.

Once on the ground and fighting the player, vorelings are much like tiny fiends - concerned only with getting into melee and able to leap occassionally to achieve this.

The main gameplay purpose of vorelings is to harass the player, stripping away a few health points either while they have more pressing concerns or prior to a major combat.
In this respect, think of vorelings as mobile antihealth kits.

Countermeasures
Any weapon will kill a voreling fairly swiftly, but using shotguns is sometimes a bit too slow to prevent the little shits getting in at least one rasping attack. With enough warning, the player can deal with a voreling without much effort: it is surprise, confusion or weight of numbers that give vorelings a chance.
Nail weapons can chew through several vorelings in swift succession, though the player can't always target every individual in a group.
Explosives can obviosuly chunk handfuls of the wretched creatures at once, but the speed at which a voreling can reach melee makes this more risky than players will usually prefer.
The LG is predictably fast, but could be considered wasted on vorelings.

The Necrosian Dirty Ammo Trick
Because the voreling model is designed to fit a 32x32x24 unit volume, it can be completely submerged inside a large ammo box or megahealth.
Place an ammo entity in your map, enable its 'large' spawnflag and place a monster_voreling on top of the ammo, resting on the floor as normal. Enable its "delayspawn" and "spawnsilent" spawnflags and have it targetted by some other event in your map such that the player will not be aware of it when it is spawned in. Set the voreling's angle key to face away from the direction the player is most likely to approch to pick up the ammo and enable its "ambush" spawnflag to reduce the chances of it being alerted by other monsters.
When the player goes for the ammo box they'll discover it contains a nasty bonus.

Contents

Straight from the pages of Lovecraft, the flying polyp is a decidedly exotic monster to use. As well as being a flying monster, its windblast and invisibility powers throw up unusual gameplay effects.

Setting the "startonground" key to "1" places the polyp on the floor in the same idle posture as the spawn, though the polyp has a wobbly animation too. When alerted, it will play once through its launch animation then fly into combat as normal. It will not land again. Apart from the aesthetic effect of this, the launch behaviour allows a very short opportunity for the player to attack the polyp before it can use its windblast or turn invisible. It's also a definite attention-grabber.

The polyp's general behaviour is to advance quickly towards the player until it reaches optimum distance for its windblast. Having no melee attack, the polyp is not concerned with reaching bounding box contact and will begin to circle strafe the player instead. However, during the chaos of polyp combat, it is not uncommon for the player to stumble closer to a polyp, sometimes being surprised when it decloaks at point blank range.

Windblast
This attack is basically a non-solid projectile, but has the added effect of pushing the player away from the polyp when it hits. There are any number of ways a deviously inventive mapper can take advantage of this to the player's peril. The actual damage inflicted by the windblast is relatively low, but if the player actively moves against the direction of the blast the damage increases. If several polyps are able to blast the player simultaneously, the combined force can pin the player into a corner.

Invisibility
This is the polyp's most unusual and disconcerting behaviour. While previous custom monster have had the ability to teleport short distances, when coupled with the polyp's fast flight maneuvers invisibility allows the monster to travel almost anywhere to attack the player.
The polyp will cloak in order to move closer to the player or circle around them. While invisible, it cannot use its windblast and emits a throaty chant which warns the player of its proximity. The player can attempt to track a polyp via sound, but this is very hard to do. The polyp cannot move through obstacles that would block it while visible. If wounded while invisible, the polyp is forced to decloak and reveal its location, most likely windblasting the player for their trouble.
Both cloaking and decloaking are signaled by very distinctive sounds.

Gibs
When a polyp is killed, it explodes. Unlike the spawn, this is not a rocket type explosion. The polyp merely spatters in several directions as a spew of bright green slimey gibs, causing very low damage if they happen to strike the player.

The biggest difference between polyps and other monsters during combat is their ability to rapidly outflank the player through a combination of very fast strafing and invisibility. In the right area, this can make combat more circular than linear. With two or more polyps attacking from different directions, the chances are high that the player will have to turn right around at least once instead of just backing away and shooting. So open areas work well for this, especially if the player's exits are limited.
Cover is important, as much for the polyps as the player because they can pass behind structures while invisible and avoid being wounded into decloaking. Courtyards with widely-spaced pillars or multilevel rooms with walkways and stairs are good hunting grounds for polyps.
But even alone, a polyp's apparently ferocious movement, sounds and attack can induce uncertainty or even panic disproportionate to how easy it actually is to kill.

Countermeasures
The SG can be useful, if weak, for wounding invisible polyps and forcing them to decloak because its higher ROF allows the player to take pot shots quickly. The SSG can be enough against a single polyp when it gets close without the player suffering too much damage before the combat is over.
Nail weapons are the ideal for combating polyps. They're very high ROF allows the player to spray indiscriminately around them to hit invisible polyps and force them back to visibility sooner. The SNG is powerful enough that once visible, a polyp is unlikely to live long enough to cloak again. Controlling the acquisition of nails is usually a high priority when polyps are around.
The RL can kill a polyp in two good shots, or one if it's already slightly wounded. However, the difficulty zeroing them even when they're visible means rockets are often wasted and the polyp's occasional habit of decloaking very close to the player makes explosives risky.
When combat occurrs on a level area the player can opt to grenade spam the floor around them where the polyp's tendency to float at low altitude means they may get caught passing over explosions. Doing this, though, effectively paints the player into a corner since they block themselves off from their own strafing maneuvers. If the player is attacked by polyps while on an elevated position, grenades are almost totally fucking useless.
The LG, having the highest ROD, can make short work of them. But it's easy for the player to burn off cells impotently while trying to hit invisible polyps.

Lightning Gun
"Though their senses could penetrate all material barriers, their substance coul not; and certain forms of electrical energy could wholly destroy them"

"Lightning Gun: A rare Yithian weapon, this device was created by the race shortly after their arrival on prehistoric Earth. Built to combat the carnivorous flying polyps, it is a camera-shaped weapon that fires great gouts of electricity."

Based on these two extracts ( from The Shadow Out Of Time and the CoC Rulebook respectively ) and the general characteristics of polyp combat, the LG does double damage against polyps. It's fun. But still tricky.

Flying Infighting
Because of the way Quake's flying AI works, if a polyp and scrag infight they will continuously rise to gain altitude above the other. In some map areas this can cause both monsters to become trapped in the ceiling structure, unable to finish the fight. Clip off ceiling cavities in areas where polyp vs scrag infights may occurr, or keep the flying monsters separate.

Contents

The weakest of the Death Brigade, these guys work in almost any situation, and are designed to be your generic-use medieval monster.

Necros says
They can be used either as melee or ranged sniper, so anywhere you want to place them should be fine. Their chop attack is a slow one, so the 'shambler dance' maneuver works on them as well.

Kell says
Guards are very useful monsters because they're middle range health and quick but weak attacks allow them to be used just about anywhere. Having 200 health and an inaccurate ranged attack they are similar to ogres, with the notable exceptions that they move faster and with the smaller bbox. Think of death guards as leaner, fitter ogres.

Contents

You'll no doubt be very familiar with this monster already. We haven't changed his characteristics at all.

What we have changed about him are the entities: monster_death_knight is what now appears in the quoth .def and .fgd files. The original monster_hell_knight does not, but remains in the progs so that older maps that use him remain playable in Quoth. Both the _hell and _death versions behave identically, including the disabled infighting with other Death Brigade. To the player, these changes are utterly transparent.

The other reason he has an entry in the tutorial is to allow us to explain a little about the Death Brigade.
Death knight reskins have been a staple of Q1SP mods almost from the beginning because the model itself is a rather nice piece of work and also contains several animations not used by the finished monster. However, we have taken this one step further by creating the Death Brigade, a loose cult of fantasy-medieval hard men who share certain similarities that the other Quake monsters do not.

The most important of these to your map is that members of the Death Brigade do not infight. Their attacks still cause each other damage though, and they will infight with other monsters with customary machismo.
Each current member of the Death Brigade is designed to work alone, or with other monsters, as normal; there is no requirement to group them together. But if you're looking for a decent, varied horde combat the Death Brigade are a good choice to consider.

Contents

The stronger of the Death Brigade, these guys have a magical aura that is active whenever they are not firing and halves the damage they take ( it is essentially an intermittent version of the Cross powerup, hence the emblem on his breastplate ).
At close range (not just melee), they will blast the player with lightning. If the player is close enough they'll be hit by the sword chop as well. The tracking fireballs behave much like the rocketeer's missiles, except that they do not accelerate continuously.

Necros says
Can be used in a fair variety of places, however, it may be wise to provide some cover, at least in lower skill levels. They aren't all that powerful, given enough weapons and ammo. Keep in mind they could introduce a bit of ammo unpredictability, because some players may choose to wait until the aura drops before attacking while others may not. Be prepared to add a small amount of ammo to make up for this discrepancy.

Kell says
The lords are strange fellows indeed, and fighting them isn't quite like for any other monster. Aside from the aura, which mostly slows the pace of combat and demands a little more tactical thinking of the player, their most eccentric feature is speed; lords will only run to regain LOS to the player, the rest of the time they walk or stand and fire. This means that the more direct movement required of the player in other combats isn't as appropriate. Usually you will want to lock the player in an area with a lord, or at least require them to hang around. This coupled with the lords' higher-than-middle health makes them a good choice to protect a progress-dependent feature, such as a door or key. In this regard, think of them as very minor boss monsters.

Countermeasures
Both shotgun and nail weapons are about right for taking on a lord, nails being more likely to be wasted, or at least underused, if fired while the deflective aura is active.
Grenades are effective while the aura is down, similar to their use against vores. But while the aura is up, grenades simply bounce off without causing any damage at all. Which can be interesting in combats involving other monsters alongside the lord.
The RL will drop a lord reasonably fast, even with his aura, but the player will need to do most of the legwork to continue dodging his firestorm while keeping back from their own splash.
The LG is fast, but still takes long enough that the lord will most likely make a good attempt with his own lighting attack in retaliation. If the lord's aura is up, however, the LG shaft will be reflected off at full damage. Possibly right back at the player.
The PG has no real drawbacks here, and is even better in horde combats where other monsters might also be hit as the player spams the lord with plasma.

Contents

Flying, long ranged snipers. They are slow moving, and prefer to stay high up, away from the player.

Necros says
The lightning, although hitscan, does in fact trail slightly behind the player, so a strafing player can fight a gaunt in a wide open area with no cover without taking any damage, if they are careful. They also play their hooting idle sounds with a much lower attenuation than other monsters. It can be a great atmosphere tool. However, should you not want that, then simply spawn them silently in when they are needed.

Kell says
The gaunt was originally conceived to fill the role of 'larger flying monster'. They now do this by two main properties above the scrag: health and persistance of ranged attack. As necros notes above, the lighting is not nearly as powerful as the shambler's and players learn this quickly. The slow, langorous speed at which they flap through the air also mitigates their power. What makes the lightning powerful is the duration for which it fires and its hitscan nature: gaunts can damage the player from very far away or, preferably, very high up. Distance is the key to making gaunts dangerous, be it horizontal or vertical. This doesn't mean they can't appear indoors, but they prefer to remain above and aloof. Their high health means they will always live long enough to present some threat to the player.

Countermeasures
With the emphasis on distance, fighting gaunts with shotguns is boring. NG and SNG are good because, although the nails travel fast, they are not hitscan and with more than one gaunt around ammo is going to run out sooner rather than later. The RL is an easier weapon to wield because it is more or less desigend to knock large, slow targets at a distance, but its slower ROF also gives gaunts a little more time to retaliate with hitscan. The LG and GL are so limited by range they are rarely effective against gaunts. The PG, with it's faster ROF and travel speed, is pretty much the ideal for players to take gaunts out of their airspace.

Note
Anyone with a good memory may recall the special ability the gaunt was originally to have, the gauntdrop. This has not been abandoned but the highly unusual nature of the behaviour demands that we implement it as rigourously as possible. It is not available in this version of Quoth, but when it appears in a later update it will not cause incompatability. Any appearance of the gaunts in current release maps will continue to work.

Contents

The basic concept for this bizarre monster is to provide Quake's bestiary with a 'blunt' version of the shambler - large and tough, with a strong melee attack and projectile-splash instead of hitscan for its ranged attack. Its health and attacks place it a bit below the shambler but above the death brigade. Like a vore, but fast.

Quoth Note
Since debuting the drole in Chapters, we have rapidly come to the conclusion that we allowed the drole to become too powerful. We try, but summoning Lovecraftian monsters affects even our grip on reality. So the speed at which the drole-bombs travel has been slightly reduced, and the damage inflicted by the tentacles in melee has been substantially reduced.
Never let it be said that we don't have our players' best interests at heart, even if that heart is cold, dripping and attached to the wall with a spike.

The most complex piece of the drole's behaviour is drole-rage.
When a drole is wounded below 350 health it roars in a distinctive way and becomes enraged. This causes two important changes in its behaviour:
Attack preference - before becoming enraged, the drole is predominantly, though not exclusively, range oriented. It will advance at a fast walk towards the player and shoot frequently. On reaching melee it will attack with double-swipes of each pair of tentacles, alternating left and right at a reasonable rate.
When it becomes enraged, the drole's emphasis shifts from ranged to melee. It will charge the player, strafing and shooting less as it closes the distance; within a short distance, it will just charge.
On reaching melee, it will pummel the player with its tentacles in an attempt to kill the arrogant bastard as fast as fucking possible. Note that once engaged in melee, droles are relentless; they continue to advance, unlike shamblers, so the old 'shambler dance' tactic of provoking a melee attack then backing off is harder to execute against droles.
This behavious is integral to all droles; it cannot be disabled.
Drolejump - this uses the trigger_drolejump entity. It is identical to a trigger_monsterjump but only affects droles and only when they are enraged. With it, an enraged drole can be made to leap off a surface to charge the player. A drole can actually be placed in your map completely inside a trigger_drolejump and it will not be affected by it until enraged.
Good setups for this involve stationing droles as sentries on walkways or guard platforms from which they can bombard the player below with their ranged attacks. Once sufficiently wounded by the player's retaliation, their rage will trigger them to jump off their vantage points to charge across open ground.
Being dependant on the placing of trigger_drolejumps, this behaviour is at the mapper's discretion.

Countermeasures
Just as wielding the LG against a shambler is a case of 'fight lightning with lightning', the best way to combat a drole is to use projectile-splash against projectile-splash. Unlike shamblers, droles suffer normal damage from explosives. The RL allows the player to kill a drole quickly while maintaining their distance, thus increasing the opportunity to dodge its bombs. The GL is similar, but obviously has useful gameplay implications if the drole begins on an elevated surface.
Nail weapons usually provide a more involved combat, with more chance of the drole reaching melee range even across larger rooms.
Fighting a drole with shotguns is like trying to halt a charging rhino with a mallet.

Contents

The biggest, baddest, non boss quake monster yet. They move slow, but make up for it in sheer damage potential. Their bilebomb attack is a blanketting attack. The main bilebomb will split into two fragments shortly after launch then each will explode into a few more smaller chunks when they hit.

The paw swipes not only take a fair bit of health away from the player, but also knock him back. If the player is still in melee range after the first swipe, the same arm will take another swipe with it's second paw. The paw swipes also hit any other players and/or monsters in a forward cone in front of the gug. Secondary targets only sustain ~10 to 15 damage, but take the full knockback effect. Monsters that are hit by this will become angry at the gug.

Finally, every so often or if the player has been out of sight for a while, the gug will use its Quake attack. This is an area-of-effect damaging attack that disregards cover. Only sheer distance will mitigate the damage from this one. There is a short timer on the attack, and the gug will only do it every 4.5 seconds. This attack also damages any other players or walking monsters in it's range. However, monsters will not be angered and turn on the gug.

Necros says
A nice way to finish a map, or even just during normal play, these guys will make an impression... on your skull. o.0
Things to keep in mind are that other melee monsters may not get along so well with the Gug because of the area-of-effect melee attacks. Ranged monsters or flyers are prefered. Also, since the Quake attack will damage walking monsters, it may further be advantageous to use flyers ( see kelltest3 for an example of this ).
Since the Gug's ranged attack covers a fairly wide area when it detonates, remember to provide ample room to move around and at least some decent cover. Beyond that, have fun. ^_^

Kell says
The primary location for gugs is at the climax of a singleplayer epic, without having to resort to a predictable boss monster. However, with the inclusion of sufficient kit, players could encounter them earlier. The unmissable presence of an angry gug grabs the player's attention and keeps it, so memorable setpieces are good locations for such an encounter.
Also consider the knockback from the pawswipes and the shaking from the quake attack: the danger these present can be drastically increased or decreased by the map features nearby, such as lava pools or secondary monsters.

It is important to understand the nature of the bilebomb. It's a mass ballistic attack, not projectile; a mutlitude of grenades at once. Given that the fragments bounce rapidly off the architecture, this adds a chaotic, random element to the already substantial splash damage. This means it is very hard for the player to avoid taking damage at all when subjected to the attack, but by dodging skillfully relative to both the bilebomb and the gug itself they can greatly minimise the damage they take. Failure to do so is appropriately brutal for the power of the monster. But given that the bile is ballistic it is also limited in range by gravity. Unlike the ogre, the gug can attempt to fire upwards, but there is still a maximum effective range.
What this all means is that room to maneuver is as equally important as cover. The balance (or lack of) between the two is perhaps the most important element of a gug combat to work on. The gug and player are actually more closely matched in terms of overall power than with any other monster, but their strengths and weaknesses are more or less opposites. The gug is large, tough and can spread its damage wide, but is also slow, unmaneuverable and less than precise. So the player's best hope lies in outmaneuvering the gug, taking advantage of distance, space and cover to escape the worst of the bile. Then retaliating with short, concentrated attacks with the most appropriate weapon at the time.
Time is also more of a factor in gug combat than normal. Because completely avoiding damage is almost impossible, and the gug has secondary attacks to resort to on occassion, the player does not have the luxury of determining when to attack and when to flee. Once a gug attacks, the combination of bile spatter, quakes and the likely close call from the pawswipes ensures that death is not far away.

We'd like to think that this style of combat is a pretty good recreation of the sort of 'david and goliath' confrontations common to heroic fantasy, such as the Luke vs Rancor fight in Return Of The Jedi, but without the 'hit its weak spot' specialisation of a classic boss. As with those fights, should the player's advantages run out - room, cover, distance, time - and they allow themselves to be cornered by a gug they are, to put it bluntly, fucked.

Countermeasures
As kelltest3 demonstrates, SSG + NG can be enough to defeat a single gug as long as health and/or armour are increased so the player can go the distance. SNG and GL are usually good weapons for gug combat, giving the player the confidence to make a conserted attack but still requiring a bit of skill. RL, LG and PG can end a gug combat surprisingly quickly but this can also be compensated for by conversely lowering the available health and armour. This makes for a shorter but more panicky combat as the player has more damage at their disposal but a narrower margin of error. Such variation is what makes gug combat different from proper boss combat, but generally you should allow the player to at least feel they have a chance before taking on a gug.

Contents

Our new boss monster is intended to provide a more usefual and varied alternative to either of the id bosses. It is also much easier to implement in a map than the likes of the Dissolution Of Eternity dragon, not being dependent on any special entity setup.

The main characteristic of the vermis is that, like Chthon, it remains at a fixed location and rotates around its z-axis to follow the player. Unlike Chthon, it has both a ranged and melee attack, the challenge of which are both greatly affected by the design of the map in which combat occurs. As well as chapter_finale at the climax of The Lost Chapters, wormtest1 and wormtest2 provide good demonstrations of the variation in gameplay possible with vermis combat.

Slight variations in behaviour are implemented for the vermis between different skill settings: the higher the skill setting, the shorter the pause between spore attacks.

For coop, the vermis' behaviour is sufficiently modified to ensure that it will direct its attacks at one player for a minimum length of time regardless of any subsequent damage from other players in the game. This is to prevent the coop tactic whereby alternating damage from several players renders a monster helpless as it continuously switches its targets faster than it can make an attack.
Also, watching teammates being grabbed and thrown is just funny.

Placement
The vermis' unusual size and shape means that it's bbox is wide and very tall. Placing it in your map is not too difficult; the editor boxes specified in the .fgd and .def center roughly on where the base of the vermis' upper body begins i.e. that part of it the player needs to see and which animates most noticeably. Right in the center of the fleshy 'bulb'.
The width of the editor box corresponds to the impact bbox used to calculate weapon hits in-game: 128x128 units.

Normally the vermis begins at its full height, but with its feeding tentacle raised and closed while the whole upper body sways slightly from side to side. Alternatively, the vermis can begin well below its combat height inside a pit, pool or other such feature. All of the vermii appearing in the Chapters maps begin in this state.
To implement, add to the vermis the key/value "coiled" "1"

Skin
Because of the way Quake lights models, a vermis rising out of a darkened pit or the void will be inappropriately visible right down to the bottom of the model. To compensate for this there are a few skin variants that can be enabled with the key/value "skin" "#" where # corresponds thus:
0 = plain flesh ( default )
1 = void darkness - fading to black at the bottom
2 = slime glow - covered in greenish towards the bottom
3 = lava glow - fading to bright orange at the bottom

Countermeasures
The vermis takes damage as normal from all weapons, but its high health means that anything below the SNG is too slow for a main attack.
Grenades are good to provide because the GL has a slightly faster ROF than the RL but its lower accuracy means the player must take a little longer to aim and missed shots will likely fall harmlessly into whatever pit the vermis occupies.
The RL, conversely, allows for a more traditional duck and cover approach, but relying on just rockets from a distance can lead to a slower and possibly less exciting combat.
The LG allows the player to make a satisfying attack on the vermis for the short intervals they are out from cover, while its limited range helps bring them closer to a possible grab attack.

With so much health to decimate, the player is unlikely to enter combat with a vermis already carrying sufficient ammo and it is relatively easy to ensure this is the case in your map. Therefore it is not only the weapons that the player wields on arrival but the ammo that is available during the combat and the associated dangers of acquiring it that determines much of the challenge.

Contents

An item with rather obvious purpose, but still worthy of note.
The flashlight is a distinct item, rather than an inbuilt feature as it is in most games, for the same reason as the warhammer melee upgrade: to keep it optional and ensure players know the mapper wants to them to have it should they decide to include it in their map.

Once acquired, the player retains the flashlight until changeleveling to start.bsp, or any map with "lose_items" set in its worldspawn.

The flahslight battery will last 90 seconds, 10 seconds per indicator light ( the flashlight will remain on for 10 seconds after all the lights on the indicator go out ), and recharges at the rate of 5 seconds per light. There is a period of 5 seconds after the battery runs out when the player must wait for it to recharge.

The flashlight beam will alert monsters that see it, unless they have their "ambush" spawnflag set.

Contents

There are only two notable differences to the keys in Quoth.

We have merged the models for gold and silver versions of each key design into one, thus saving another slot for model precaches.

There is also a new 'elderkey' design to match the episode 4 theme, since base, medieval and runic all have there own key designs. Enable this in the same way as for other keys, via the worldspawn key/value "worldtype" "3"
Touch messages and sound effects have also been added to match.

With respect to the carrying of keys across map changes, see also the worldspawn entry.

Contents

Forged from the three nails used to crucify christ, this rune multiplies the player's attack damage by three, but only affects nail weapons.

The trinity is a valuable powerup because it offers a good boost in combat without the insane carnage* and explosives hazard of the quad.
One of the interesting effects is that when the player is carrying the trinity, the NG becomes half-again as powerful as the SNG while using less ammo, but the player has to make the most of it.
Gameplay setups involving a non-secret trinity and limited weaponry can be created to bait the player into ambushes and so forth. Because the player must use nail weapons if they are to benefit from the trinity, it can also be used to encourage the player to deplete their precious nail ammo in predictable ways.
Against most monsters, trinity + SNG = swathe of destruction.

Note that carrying both the trinity and quad has a multiplying effect - the SNG will become devastatingly powerful. This is left to your discretion.

* Not that there's anything wrong with insane carnage. But we're talking balanced gameplay here, okay?

Contents

This is basically the Battle Suit from Quake 3, which was itself based on the Resistance rune created by Zoid for Q1CTF. It provides powerful protection without the gameplay-negating invulnerability of the pent.

It is a more complex powerup than most, with the following effects:

Protects completely from liquid hazards - the player will not drown or burn.
Note that if submerged underwater for long enough to have otherwise started drowning, the player will immediately begin drowning when the cross wears off, unlike with the biosuit.

Protects completely from LG underwater discharge.
Note that the pain twist and redscreen experienced when doing this with a pent do not occurr with the cross.

Protects completely from splash damage. This includes indirect hits from all projectile and ballistic weapons like ogre grenades and vorepods. Direct hits will still inflict half damage. It also neutralises the player's own explosions, allowing them to rocket jump with impunity.

All other damage is halved. This includes direct hits from splash attacks, all non-splash attacks, funcs and triggers, plus environmental hazards such as lavaballs, lasertraps and spikeshooters.

Does not protect against trigger_void.

Contents

Though forged with archaic magic that binds the strength of Thor, this warhammer is not as powerful as the god's own weapon - the Mjolnir from Scourge Of Armagon. However, it does deal more punishment than the standard battleaxe.
The axe takes ½ second to swing, inflicting 20 dmg for a successful blow. The hammer takes exactly the same time to swing, but delivers a hefty 40 dmg when it strikes. When the player picks up the hammer it does not appear in a new weapon slot, but simply replaces the axe.
The practical upshot of all this is that the hammer is really just a melee upgrade.

This weapon upgrade is inspired by the modifications to the standard axe appearing in certain SP mods.
The default axe is so weak as to be essentially useless, but some map designs can benefit from a decent melee weapon. By providing this upgrade in the form of a weapon visually similar but distinct from the axe, it leaves it optional for any mapper to include or not and ensures that the player is clearly aware of the upgrade if and when it has been delivered.

There isn't really any need to provide the hammer in your map unless you feel that it has definite benefits. Although necros and I have tested the hammer in a number of different maps, we have yet to include it in any finished gameplay.
There are a number of small but significant benefits for players wielding the hammer. Against vorelings and other weak monsters, the hammer is quick ( though not instant ) and allows the player to conserve a bit of ammo. Used against low- to middle-bestiary monsters in solo combats, the hammer can sometimes be enough to win with relatively little damage being sustained. In hordes or against upper-bestiary monsters, even alone, the neccessity to reach melee range makes the hammer an unattractive option.
Combined with the Quad, the hammer will inflict 160 damage per strike, which is more than a normal rocket hit, but that still leaves the question of getting close enough to use it.

Contents

Designed to be an inventory-topping weapon, the plasmagun is a powerful yet non-gimmicky tool.
It's characteristics make it mostly similar to the PGs appearing in id's other games: the DooM 1/2/3 and Q3A versions. It isn't quite as fast firing as those, but its greater damage puts it comfortably higher than them.
The most powerful aspect of the PG is not any of its individual characteristics, but the overall ease with which it can be wielded. The .2 ROF is fast enough for rapid spamming of groups of weaker monsters or fewer, stronger monsters but is also slow enough for controlled shots against lone weak monsters. Although projectile, the plasma bursts travel at a good speed, enough to hit flying monsters even at longer ranges without too much effort to compensate for movement. And the small splash radius is enough to further compensate for aim, as well as being ideal for groups of monsters as are likely to be thrown at the player in the latter stages of a map.
In simpler terms, the PG sits almost exactly between the SNG and RL. And this is a good way to think of the weapon.

The use of cell ammo for the PG, rather than a new ammo type, is a less obvious but perhaps more important characteristic to understand with regards your map. Because the LG is expected to usually not appear until the final stages of a map, and has clear pros and cons as to when to wield it, cells also are not expected to appear very often. The PG, however, with its '1 cell per individual projectile' functionality can make more efficient use of available cells and can use those cells to resolve a far greater range of combat situations. Providing cells for the PG instead of LG becomes more like providing nails for NG and SNG. In fact, with a map design carefully oriented towards it, the PG can actually become a 'main' weapon - one that the player will choose to wield most of the time and use at the opening of combats until circumstances incline them to switch to another gun.
Also of interest to the issue of cell ammo is the possibility of the player carrying both the LG and PG. The weapons are still different enough - more so than the NG and SNG, probably more so than even the GL and RL - that they offer a good choice for the player. The problem is that the way in which they translate cell ammo into use and damage is quite different. A nail is essentially the same non-splash projectile, whether it is fired from the NG or SNG. An explosive is still the same large splash attack whether it is fired from the GL or RL. Not so for the LG and PG, and this produces a discrepency between use of LG and use of PG that can be harder to account for. Take into consideration the choice of monsters and combats the player will face if they have both LG and PG, and also consider the option of having only one or other weapon in your map.

I may be overstating the issues with the PG somewhat. It is a fun and easy weapon to use; just take these issues into consdieration for your map.

There are also some specific idiosyncrasies with the use of the PG.
Similar to the LG, it cannot be used underwater. Unlike the LG, it does not discharge and kill the player; it simply will not fire. As well as making thematic sense, what with it also being an electrical weapon, it adds a minor and very clear limitation to the benefits of the PG. Make of this what you wish, but bear in mind that players can easily become frustrated if such mutually-exclusive gameplay elements such as PG and water are unavoidably close together.

The PG also gibs zombies with one shot. Having a higher ROF and far less danger from self-inflicted splash damage, this can be an enourmous benefit. In some situations.

Finally, and we find it amusing that this did not occurs to us at the time, the Quoth PG now allows for the same trick jumping maneuvers as the PG in Q3. Plasmaclimbing. A single shot from the PG can be used to plasma-jump, exactly like a rocket-jump but with a much lower altitude; about 64 units, twice normal jump height. However, its much higher ROF allows a cumulative effect whereby players can aim at an angle of about 45° while facing a wall, hold down fire and rise. The maximum height I've ever managed is 128 units, though I've never been much of a plasmaclimber in Q3. Still, that's enough of an advantage above normal jump height to potentially short-circuit the route through your map. To say nothing of speed running. Be warned ;)

Contents

For those who may not recognise it, this is basically the kamikaze carried item from Quake III: Team Arena. But by including it for coop, its use is a bit different from the original's CTF application.
The obvious situation for players to use the bomb is against large numbers of closely packed monsters i.e. hordes or at the climax of a map against gugs/vermii etc., in locations where they hopefully have enough room to maneuver into the best position before firing. There really isn't much more to it than that.

The challenge of maximising the damage and the restriction of only one detonation per player per map, take the edge off the devestation this weapon may initially seem to provide. Add to that the reluctance some players may have to suicide, even with the guarantee of a coop respawn, and the rarity of coop play compared to SP, and the carefully crafted gameplay of your map is not likely to be ruined by including the bomb.

The best reason to include the bomb is if your map has one, or preferably more, major combats where players have the option - but not neccessity - to tackle it with this weapon.

From the benefit of our more recent and varied coop runs we have discovered there are only 2 major elements to the Q1coop experience:
1. Fun
2. Chaos

And these are really what the bomb is for.

See also: info_bomb

Contents

This entity allows mapobjects to be made of any mdl ( such as monsters, gibs etc. ) or bsp ( such as custom fans, turbines and other prefabs ).

Note that there are two new mdls currently without associated entities that may be of interest with this entity:

tree1.mdl
reed1.mdl

Both can be seen in e1m2quoth.
The tree does not animate, but the reed will even without specifiying a frame; it's animation is a framegroup.
These are preliminary vegetation mapobjects, many more of which we hope to add in the next update to Quoth.

In the case of custom bsps, we recommend a convention where your mapobject bsp is given the same name as your map, followed by an underscore and a description of the object e.g.

kellbase1.bsp
kellbase1_fan.bsp

This will help keep associated mappage together in players' folders.

spawnflags
Setting spawnflag 1 makes the mapobject a static entity.

model
This key should contain the path to the desired model e.g.
progs/tree1.mdl
maps/kellbase1_fan.bsp

frame
This sets which frame of the model to use. Remember that frame numbers start at 0.

mangle
If set, this is used as the entity's facing instead of angles.

avelocity
The rotational velocity of the object can be set, so if you need simple rotation on a fan or similar, you may find it easier to use this entity than the hipnotic rotating entities.

Contents

These four crate prefabs complement the original exploding radioactive containers.
As with the originals, these come in small and large, being 32x32x32 and 32x32x64 respectively.

The biohazard crates are weaker than the radioactive originals, and the plasma are stronger. The biohazard crates merely burst into a shower of green gibs identical to the demise of a polyp. As with the polyp, the biosuit will protect the player from the - admitedly mild - damage they can cause.

The plasma crates are lethal if the player is caught in the explosion.

Contents

This mapobject allows you to add some alpha masked textures to your quake maps. The most important caveat is that these sprites are one sided, if the player can see both sides of your mesh you need to place two entities. The supplied sprites provide a variety of grills and wire meshes, but the "model" key allows you to specify your own.

Spawnflag 1 makes the mesh a static entity, and if this is not set, spawnflag 2 makes the mesh solid. Making it solid like this will prevent players and shots passing through, to block players but not attack you should use clipping brushes instead. Also, the solid bounding box is aligned to the world axes, and although the size of the box adjusts to accomodate rotation, it will probably block too much if the mesh is rotated more that a few degrees away from alignment with the axes. If you are trying to clip off a 45 degree mesh, you should use clipping brushes or a func_togglewall.

The classname mapobject_grill64 creates a mapobject_mesh with "model" set to "progs/grill64.spr". mapobject_grill128 is similar, but with the default model "progs/grill128.spr".

Contents

This is a simple metal light fixture, similar in style to some of those found in Doom, for use in base maps.

There are four different skins available and are chosen by setting the key "color" with a numerical value as follows:

0 = yellow-white ( default )
1 = bluish-white
2 = red
3 = gray ( off )

Note that if this entity is set to act as a triggerable light, the skin on the model will alternate between the chosen color and gray when switched on and off.
To make this mapobject destroyable, see the example in breakable.map

Contents

This is a simple metal light fixture, taller than the postlight and with a grill around the light source, for use in base maps.

There are four different skins available and are chosen by setting the key "color" with a numerical value as follows:

0 = yellow-white ( default )
1 = bluish-white
2 = red
3 = gray ( off )

Note that if this entity is set to act as a triggerable light, the skin on the model will alternate between the chosen color and gray when switched on and off.
To make this mapobject destroyable, see the example in breakable.map

Contents

This is the original golden globe entity, represented ingame by a sprite. It now comes in a range of colors and slightly weirder designs that can be chosen to fit with your map's aesthetic. The red, green, blue and white versions are simple recolors of the original.

There are seven different designs available and are chosen by setting the key "color" with a numerical value as follows:

0 = gold ( default original )
1 = red
2 = green
3 = blue
4 = white
5 = evile
6 = evile zombie

Contents

This is a simple eyecandy effect comprising a cloud of small, wandering sprites like those used for air bubbles.
It is intended to be used also as a light source, though this is not mandatory. Marshlights can be used to provide spooky illumination for areas where other light features may be innapropriate, such as outdoors at night or islands floating in the void.
Because they are fullbright and animate in an obvious, semi-random manner, they are also easily spotted and can be used to attract the player's attention to important items, indicate route choices or hint at secrets.

There are seven different colors available and are chosen by setting the key "color" with a numerical value as follows:

0 = white ( default )
1 = bluish white
2 = blue
3 = green
4 = orange
5 = red
6 = purple

Contents

This is a variant of the standard id walltorch model. As the name suggests, the handle is a good bit longer and it also has a short metal chain and bracket so that it hangs form the wall at an angle.
Set the "angle" key to point towards the wall surface that the longtorch is to be mounted on.
Place the entity's origin 8 units from the wall. For a wall angled at 45° place the entity's origin at a distance of 6 units diagonally.

classname: light_flame_brazier_short
classname: light_flame_brazier_tall

These two models are variants, the shorter version simply being the decorative top segment of the taller.
They are basically square in shape, like highly sculpted and textured brushwork, and exactly fit a space 16x16x16 and 16x16x56 respectively, not counting the flames on top.

The origin for both is centered on the flames, not the brazier itself, but at a height that allows them to be placed correctly with your editor's grid set to 16 unit squares.
Place the short brazier so its origin is 16 units above the floor, and the tall brazier 64 units above the floor.
The editor bounding boxes specified in both the .def and .fgd provided in the download represent the volumes occupied by the braziers and the flames on top.

There are six matching skins for both sizes of brazier, which can be specified using the key "skin" with a numerical value as follows:

0 = knave ( default ) 1 = rust 2 = redbrick 3 = copper 4 = altar 5 = wizmet

various kbrick trim textures from the knave.wad various kmetr trim textures from the knave.wad red versions of the kstn_ and kstone textures from the knave.wad based on the cop3_ telepad textures from the id wads based on the altar1_6 texture from the id wads yes everyone's favorite texture, with angular runes on the taller brazier

By default, mapobjects to do not block movement. To implement this simply, add a clip brush of the dimensions noted above placed on the floor.

For extra ( ahem ) authenticity, place a 16x16x16 trigger_hurt at the top of the entity and give it the following keys/values:
"dmg" "1"
"wait" "0.1"
"deathtype" "played with fire"

Contents

message
targetname

This key takes the form of a console command. When triggered, the command is executed as normal. For example "message" "r_wateralpha 1". This can be a quick way to ensure the ideal wateralpha value is set for your map when it is loaded, regardless of the player's previous r_wateralpha setting.

Only certain console commands will work in this context; "god" for example, will not enable godmode for the player. Unfortunately, we do not currently have a comprehensive list of what commands are viable. Experiment and see what results you get.

Note that this is a point entity and therefore does not require a brush model or an engine precache. It does require something to trigger it, however, via its targetname.

See also: trigger_command

Contents

targetname

This point entity acts as the source of an explosion identical to that of the weapon_bomb. It can be triggered any number of times.
The potential applications of this effect, particularly in tech themed maps, should be obvious. Use creatively, and with care.

Contents

angle
mangle
speed
wait

This is a visual effect entity that emits a pulse of dynamic light along a straight path, identical to the glow from an enforcer's laser blast ( but without the projectile ).
The angle at which the pulse travels from the entity's origin can be set with either the "angle" or "mangle" keys.
The "speed" key specifies the constant travel speed of the pulse in units per second.
Pulses will be emitted indefinitely, with a time lapse in seconds set via the "wait" key. If set to -1, only 1 pulse will be emitted.
The entity can also be triggered via the usual "targetname" key, and with a "delay" value before the first pulse is emitted.

If you're very clever, you can even set up this entity to send a dynamic light to follow in sync with a moving func, e.g. an industrial elevator with its own light fixtures.

Contents

mapindex
target

These two entities are designed to allow hub map functionality for a group or episode of maps.
They work via a bitflag that, unlike most gameplay features, is retained across map changes. Like the four episode runes from the id maps.
The first thing to note about these entities is that they require more than one map, and both the 'ordinary' map and the hub/start map must be edited appropriately.

The info_mapgate and info_endgate entities themselves should be placed in the hub map. Both of them require a value for their "mapindex" key, but the value corresponds to different things.

For the mapgates, these are affected by only one map each. Their mapindex value should be unique for each different map in the episode and this value must be in binary form. For example, if you have 4 maps plus a start map, the info_mapgates would have values 1, 2, 4 and 8 respectively. Then to each trigger_changelevel in the corresponding map add the same "mapindex" key and value. When the player hits the trigger_changelevel in one of the maps ( i.e. exits ) this is where the bitflag is set. It then has an affect when the hub map is loaded.

For the info_endgate, this is affected by the cumulative value of all the bitflags of the other maps. This value should not be in binary form, but simply the number of 'ordinary' maps that are required to be completed before a final event is triggered in the hub map. In the example above, the info_endgate would have a "mapindex" value of 4.

Both types of entity should then be given a "target" key/value and this can be directed at whatever events you wish to be triggered in the hub map, such as opening a door, killtargetting a func_wall, extending a bridge and so on. The info_mapgates and info_endgates are fired automatically on map load, but take a fraction of a second to fire. So bear this in mind when designing your hub.
If you place an info_player_start2 in your hub, the presence of any of the bitflag values will cause the player to start there instead of at the info_player_start, just like for the episode selection hall in the id start map.

Note that both entities have a "reverse" spawnflag which can be set to make the entity fire when the required bitflag value is not present.

This seems terribly confusing. So what's it all about?
Well this is how we did the start map for The Lost Chapters. Each chapter map entrance had an info_mapgate that triggered a func_door to close and block the corresponding teleporter entrance in the start map once it had been played. The maps could be played in any order and only those maps that had been completed would be blocked to the player on their return to the start. Once all the chapter maps had been played, an info_endgate fired to killtarget the barrier across the entrance to the finale map.

Given the essentially infinite number of these entities you can use and the consequences of them firing at targets, any start/hub map type functionality can be implemented. You could even have the start map fill with monsters once the rest of the maps have been completed. And your start/hub map doesn't actually need to be named start.bsp.

For easier testing of these entities, see also the developer cheats.

Contents

ltime
multiplier
lip
targetname

This is another purely visual effect.

The "ltime" key sets the total duration the screenshake will last, with the amount of shaking diminishing over time.
The "multiplier" key increases or decreases the intial strength of the shake; n > 1 increases and n < 1 decreases. Defaults to 1.
The "lip" key specifies how often the engine should update the screen, as a fraction of frames per second. So a value of 1 means 1 screen update per second. A value of 0.1 means 10 updates per second, 0.05 means 20, and 0.01 means 100 (or as fast as it can). Defaults to 0.01.

Contents

style
duration
dmg
noise
coiled

This is a classic lightning effect that can be triggered to fire as a trap against the player, or used just as a visual environmental effect.
The direction the lightning fires from the entity's origin can be set with "angle" or "mangle" or by targetting at another entity, such as an info_notnull.

The lightning will use the LG shaft model by default. Setting "style" to 1 will use the ( slightly thicker ) shambler lightning shaft.
The time for which the lightning will burn is set via the "duration" key in a value of seconds. Default is 0.1
If functioning as an actual trap, the damage inflicted against any player or monster struck by the lightning is set via "dmg" as for a trigger_hurt.
By default, the lightning makes the LG 'crackling' sound when it fires, but you can use the "noise" key to specify a custom sound instead. Use the format "enforcer/enfire.wav" ( the "/sound/" bit is automatically added by the engine ).
If the spawnflag "boom" is enabled, it will make it play the LG's initial firing sound as well as the repeating one. Not having this spawnflag set will still play the looping sound. Use "coiled" "1" to make a silent lightning bolt

Contents

startdisabled
mapindex

If "startdisabled" is set to 1, the changelevel won't be active until triggered via its targetname. Once activated it must then be touched to work as normal.
This simply allows for the player to exit through the same location they entered the map.

The "mapindex" key is only used in conjunction with the info_mapgate / info_endgate entities.

Contents

message

This key takes the form of a console command. When triggered, the command is executed as normal. For example "message" "r_wateralpha 1". This can be a quick way to ensure the ideal wateralpha value is set for your map when it is loaded, regardless of the player's previous r_wateralpha setting.

Only certain console commands will work in this context; "god" for example, will not enable godmode for the player. Unfortunately, we do not currently have a comprehensive list of what commands are viable. Experiment and see what results you get.

Note that this is a brush entity and therefore requires an engine precache slot, but does not require another entity to trigger it. If you only have one command to be executed in a particular area, use a trigger_command.

See also: info_command

Contents

health
target

This is normally used to emulate destroyable scenery.
It will only fire its targets once its "health" value has been met or exceeded through damage inflicted.
It also has two spawnflags; "multi_use" tells the trigger not to remove itself after being fired which allows the trigger to be used multiple times, and "invisible" tells the trigger to not be visible. If left visible, it will function more like a destroyable func_wall.

Contents

angle
speed
height

Used as described above to fling enraged droles in a specified direction. Identical to a trigger_monsterjump, set the "angle" key for the direction the drole will jump, "speed" for the number of units/sec the drole will move horizontally and "height" for the number of units/sec vertically.

Contents

wait
cnt
deathtype

Identical to the original, but with some added keys for greater control.
"wait" can be used to specify the frequency with which the trigger will inflict damage. For example, a good burning effect can be simulated with a relatively low "dmg" value but a "wait" of "0.1"
"cnt" can be used to specify the number of times the trigger will inflict damage before becoming inactive.

Contents

angle
noise

Quoth ladders emulate the func_ladder from Half-Life; they are created as a single invisible brush of any size, and players move when inside the trigger's boundary according to their direction of facing.

Creating a trigger_ladder is very easy, since it is a simple trigger brush, but some things should be noted:
Bring the top surface of the trigger_ladder to be flush with the floor surface on to which the player is to move when reaching the top of the ladder.
Make the trigger about 8 to 16 units narrower than the visible rungs of the ladder you build.
Ensure the trigger_ladder protrudes some short distance out from the rungs, so the player's bounding box will collide with it. About 8 units should do.
Players are likely to be facing upwards upon reaching the top of a ladder and attempting to detach. Take care to construct the architecture at the summit of your ladder - and any other altitude where a destination is available - to assist player movement.
Players can detach from a ladder at any time by jumping - some speed is imparted to this manouver in the direction of facing, but for this to work best set the "angle" of your trigger_ladder to point away from the ladder rungs.

The sound effect for the player's footsteps on the ladder rungs is set using the "noise" key. Default sound is metal rungs. Wooden rung sounds can be set with the value "player/ftladwd.wav".
The sound made when the player first touches the trigger_ladder can be set in the same way using the key "noise1".
Either sound can be set to any wav file.

See kellbase1.map for examples of trigger_ladder construction.

Contents

sounds
noise

Identical to the originals with one addition; by first setting the "sounds" key to 4, any wav file can be specified via the "noise" key to be played when the trigger is touched.
Use the format "noise" "ambience/nightmare.wav" ( the "/sound/" bit is automatically added by the engine ).

This custom sound option can also be applied to the trigger_command

Contents

onlymonster
notelefrag
state

Identical to the original, but with some extra funcionality.
By setting the "onlymonster" key to 1, this will teleport monsters but not the player. Just like the "player_only" spawnflag in reverse.
Setting the "notelefrag" key to 1 will prevent any monsters or players on the destination point being telefragged, but will wait instead until the destination is clear.
Lastly, setting "state" to 1 will not impart the forward velocity normally applied to the player on arrival at the destination ( like teleporters in Doom ).

Contents

gravity

From the hipnotic entities, this trigger will change the gravity experienced by the player.
Unlike for the worldspawn key or the console command, the key "gravity" here is in the form of a percentage. A value of 100 is normal gravity, as is the default of 0. A value of 50, therefore, would produce half normal gravity.

Note that this can be used to create specific 'lo-g' areas of a map, like in the SoA start map, but only affects the player. Monsters and coop team-mates will not be affected.

Contents

deathtype

Similar to a trigger_hurt, but guarantees the player will die on contact. No powerup - not even the pentagram - will protect from this hazard. Only godmode will save you.
The default obituary is "Player was lost to the void"
This hazard will also kill monsters on contact and instantly remove them from the map.

Contents

spawnclassname + spawnfunction
count
wait

New horde spawning entity. This entity is capable of spawning hordes of enemies from a single entity when triggered. Needless to say, a real edict saver.
This entity spawns them in one at a time from the same point ( it's origin ). The entity will only spawn a monster if there is room, and will wait if there isn't. Once it is activated, it will spawn until it has created the amount of monsters specified. The monsters spawn in already awake and aware of the player.
The value for "spawnclassname" and "spawnfunction" should be the classname for the type of monster to be spawned e.g. monster_demon1. Both of these values must be added and both must be the same. Only one type of monster can be spawned form each func_hordespawn.
Specify the number of monsters to spawn with "count". Default is 3.
The "wait" key as usual is used to specify the pause between each spawning.

If you want to have different types of monster spawning into a horde, you can use multiple func_hordespawns but you cannot place them on top of each other without risking different monsters getting stuck.

Note that although this entity is prefixed with 'func_' it is a point entity and therefore should not have a brush attached. Yeah, it would have made more sense to call it info_hordespawn, but we're perverse like that.

Contents

health
noise
noise1 - noise4
modelpath
count
rsize
t_width
ritem

The func_breakable entity allows you to create destructable objects in your map, which throw out chunks of debris as they are destroyed. The objects can either have a health value which must be depleted before they are destroyed, or can be destroyed by a trigger.
The info_rubble entity will spawn rubble in exactly the same way as a func_breakable when triggered, but have no corresponding brush model.

spawnflag 1
Makes the func_breakable display the standard rocket/grenade explosion effect at the same time as it dies and spawns the rubble. Useful when making computers or machines.

health
When set, the object will take damage and break when killed. If no targetname is given, the object defaults to 1 health. If targetname is given but health is not set, then the object will not take damage and only breaks when triggered.

noise
Custom break sound to play when destroyed.

noise1 - noise4
Randomised bounce sounds for the thrown debris. Any you do not set will be replaced with default sounds ( see preset below ). Use "misc/null.wav" for any or all four to eliminate bounce noises.

modelpath
Specifies the model to throw when killed.

count
The number of pieces of rubble to spawn. Default is 0 ( no debris, just remove and play break sound ).

rsize
Sets the frame of the debris model being thrown, but see also "delay".

t_width
Turns on random frame selection. Set "rsize" to the minimum frame number, and "t_width" to the maximum frame you want generated. So "rsize" "5" and "t_width" "10" will choose each of the frames 5, 6, 7, 8, 9 and 10 of the selected model with equal probability. The frame is randomised on a per gib basis.

ritem
The skin to use for debris models with multiple skins.

preset
Automatically fills in any values of "noise", "noise1"-"noise4" and "modelpath" that have not been custom set, according to the following values:

0 = Rock ( default )
1 = Wood
2 = Flesh
3 = Machine
4 = Glass
5 = Brick ( 8 units )
6 = Brick ( 16 units )
7 = Brick ( 32 units )
8 = Metal

These presets use only the first skin from the corresponding debris model, but the models contain many skins to cover as many mapping themes as possible.

To view them easily in-game we have provided breakable.bsp, a map that demonstrates each preset in a separate gallery in numerical order from left to right. The galleries display examples of the skins of the model also in numerical order from left to right, except flesh, machinery, and glass whose skins generally get mixed together when used. The different sizes of bricks are displayed in the same gallery, since the skins are the same regardless of size.
The map is a fun showcase for the sorts of structures and flavours of breakable scenery you can now create in Quoth. It is also a warning of how quickly packet overflows can be encountered using breakable features.
Go smash some stuff. We'll wait for you.

Contents

noise
noise1
wait
dmg

This is basically an invisble func_wall that can be toggled on and off indefinitely.
The "noise" key is used to specify the sound effect played when the wall is triggered and "noise1" is for the sound played while the wall is actually blocking the player's movement. Add these in the format "weapons/lhit.wav" ( the "/sound/" bit is automatically added by the engine ).
The wall can also be set to inflict damage on the player every "wait" seconds, with "dmg" specifying how much damage per hit. Default values are 0.5 and 0 respectively.

This entity can be used alone, but is also designed for use in conjunction with rotating entities.

Contents

These are cool things to add to your map, and there is a lot of potential in how they can be used. They are, however, a pain in the ass to set up.

Fortunately, we can follow in the footsteps of great mappers. Here we present the original hiprotate tutorial written by the awesome and quite literally scandinavian czg.

CZG's instructions for making a HIPNOTIC rotating entity!

Firstly, place an info_rotate on the center/axis of rotation and give it a unique targetname.
Next make your rotating bit, and make it a rotate_object, give it too a unique targetname, and also let it target the info_rotate.
Then make a func_rotate_entity or a func_rotate_door, which despite their names are point entities, and target them at the rotate_object. They too must be placed on the center/axis of rotation.

Now for a func_rotate_entity, you must give it a "rotate" key and set its value to three integers, "0 -90 0" for example, which will make it roatate clockwise along the Z axis at 90 degrees/second. You can set it to rotate around all the axis too, and to make it rotate the other way, just add/remove a - ( minus sign ).
Give it a "speed" field which sets the amount of time it should take from it's triggered, until it's at full speed, ie it accelerates.
Spawnflags 1 makes it toggleable, and spawnflags 2 makes it start on.

Now for the func_rotate door:
Set the "rotate" field to three 0's or 1's, with either 1 or -1 to set which axis it will rotate on. i.e. "0 1 -1" will make it rotate counterclockwise around the Z axis and clocwise around the Y axis.
Then give it an "angles" field too, that sets how much it should rotate on each of the axis.
So "rotate" "0 1 -1" and "angles" "0 90 -180" will make a door that rotates 90 degrees counterclockwise on the Z axis, and 180 degrees clockwise on the Y axis. Ofcourse set it to whatever suits your needs.
Then give it a "speed" which is the amount of time in seconds it should take to complete the movement.
You can give it a "dmg" to make it hurt you, more on that later, as it's a bit complicated.
"sounds" are sounds as normal, base, medieval, and metal.

Now, all this only makes a nonsolid shell that rotates.
To emulate collision on it, (because that's the best you can do in Q1,) you need loads of func_movwalls.
The func_movewalls move in a circular orbit around the func_rotate_entity or func_rotate_door, but don't rotate themselves. So make a lot of tiny func_movewalls that will move around and keep roughly in the same place as the rotate_object.
They should be targeted by the func_rotate_entity or func_rotate_door, and you can set the following spawnflags on them:
Spawnflags 1 makes it visible, as it by default is invisible to only provide collision on other entities.
Spawnflags 2 makes it damage you even if you just touch it, and you're not squished by it. Useful for maybe fans or something.
Spawnflags 4 makes it nonsolid, which is completely useless unless you also set spawnflags 1 too. Otherwise it's make an invisible, nonsolid brush that does nothing. Stupid.

A couple of general notes:
+ rotate_objects don't block a monsters line of sight, but a func_movewall does.
+ rotate_objects are textured in a quite bizarre manner. In order for them to have an origin that can be used in Quake, QBSP moves them together with their respective info_rotate so it is situated smack on the center of the level: (0 0 0) The rotate_objects are textured from there, so when they are moved back to their original position in game, the textures will appear misaligned. To compensate you either have to use a flat texture on them so any misalignments aren't visible, or you have to move them to the center of the level yourself, texture them there and then move them back again yourself.
+ func_movewalls don't move 100% exactly after the rotate_object; they lag slightly behind, creating a staircase effect. Adjust their thickness/placement to compensate.
+ Oh yeah, the most important thing of all: You must have compile tools that can handle these entities. The most popular and powerful compilers for Quake 1 are those by aguirRe. His site is here: http://user.tninet.se/~xir870k

Contents

noise
volume
speed

This is a point entity for playing any ambient sound effect.
The sound file is specified with the "noise" key in the format "ambience/wind2.wav" ( the "/sound/" bit is automatically added by the engine ). The "volume" of the sound can also be set. Default is 1, maximum volume.
The attenuation, i.e. the way in which the sound fades out with distance, can be changed with the "speed" key. Higher values cause the sound to fade out faster, but anything above 4 or 5 fades out too fast to be useful. A value of -1 means no attenuation: the sound will be heard constantly throughout the map. Default is 1, normal attenuation.
Because this entity is for ambient sounds, only looped sound effects can be used. Any sound file without the 'data chunk' required to make it loop seamlessly will not load and will show an error message in the console. Also, this entity cannot be triggered on or off.

Contents

noise
volume
speed
impulse
wait
targetname

This is a point entity for playing any sound effect when it is triggered.
The sound file is specified with the "noise" key in the format "ambience/nightmare.wav" ( the "/sound/" bit is automatically added by the engine ). The "volume" of the sound can also be set. Default is 1, maximum volume.
The attenuation, i.e. the way in which the sound fades out with distance, can be changed with the "speed" key. Higher values cause the sound to fade out faster, but anything above 4 or 5 fades out too fast to be useful. A value of -1 means no attenuation: the sound will be heard throughout the map. Default is 1, normal attenuation.
A sound channel on which to play the sound can be set, with values from 0 -> 7. Default is 0.
The sound can also be set to repeat every "wait" seconds.

Here is a list of new environmental sound files in the pak0.pak, with a brief description of each. Those denoted by ‡ are looped and can therefore also be used with the ambient_generalpurpose entity.

necros/dias.wav
Used for the large Dais in ne_marb, a loud, screaching, rumbling sound of something big moving. Important times:
0 seconds: Rusty sounds of things being strained
2 seconds: Actual movement starts
14 seconds: Movement stops
( yes, i mispelled 'dais' ¬_¬ )

necros/drivshft.wav
Used for the Driveshaft under the large Dais in ne_marb, starts off slow, then will continue looping forever.

necros/forebode.wav ‡
A low, foreboding sound from System Shock 2. A cool atmosphere setter as it's vaguely like music, but not quite.

necros/gen.wav ‡
A low rumbling of stone on stone or metal on stone ( used as an ambient sound from the two generators in ne_marb )

necros/gen_fire.wav
The firing sound for the generators in ne_marb. Important times:
0 seconds: Movement sound starts
2 seconds: Lightning noise starts
6 seconds: Lightning noise stops and movement sounds starts to slow down
8 seconds: End

necros/highwind.wav ‡
A sharp and cold sounding wind sound. Plays midway up the elevator in ne_marb. Loops

necros/irulan.wav
The sound that plays in ne_marb2 when the gug room rotates. Starts off the same as dias.wav Important times:
0 seconds: Rusty sounds of things being strained
2 seconds: Actual movement starts
7 seconds: Movement stops

necros/sgatehum.wav ‡
A wierd humming/thruming sound... Loops.

necros/strongwind.wav ‡
A strong, forlorn wind sound. Plays at the top of the castle in ne_marb. Loops

necros/tld_strt.wav ‡ and necros/tld_stop.wav
tld_strt will start and loop, while tld_stop is one shot. Meant to be used like a door sound, but for func_trains or rotaters. It sounds like rusty, grating metal with a bit of machinery sound.

necros/wat_amb.wav ‡
Quiet water lapping (blood? o.0) Loops.

necros/water6.wav ‡
Water fall (blood fall? 0.o) Loops.

necros/woodmve.wav ‡ and necros/woodstp.wav
woodmve will start and loop, while woodstp is one shot. Meant to be used like a door sound, but for func_trains or rotaters. Sounds like wood on stone, wood on wood.

ambience/nightmare.wav
A low, drawling moan. One shot, slightly spooky.

ambience/thrum.wav ‡
Deep, malevolent droning. The sound of the finale stargates of Contract Revoked and The Lost Chapters.

Contents

Preach - Kell - necros