DRL Wiki - User contributions [en]

Levels

2025-08-11T12:39:59Z

Epyon:

__NOTOC__
Levels are the heart of DRL, and without them there would be no game. It is where the player explores, where enemies roam, where special items lie in wait. They are filled with either fortune or your own personal demise.

==Basic Objects==
All levels are made of basic objects like floors, walls, and doors.
*'''HP''': This is one of the parameters that governs how difficult the object is to destroy. Whenever an object takes damage, its HP is decreased. Once its HP falls to 0, it changes to a floor tile. Some objects cannot be destroyed; these are indicated as "none". Also, some objects have two versions: one that can be destroyed and one that can't.
*'''Armor''': This also makes objects harder to destroy. Whenever an object takes damage, the object's armor is subtracted from the damage before the damage is subtracted from HP. Unlike the armor of the player and enemies, objects' armor can reduce damage to 0.
*'''Fragile''': Objects can usually only be damaged by [[Damage type#plasma|plasma]], [[Damage type#fire|fire]], or [[Damage type#acid|acid]] damage. Fragile objects can be damaged by any damage type.

{| style="rules: cols; border: 2px solid darkred; border-spacing: 0; font-size: 90%; margin: 0.25em 0.5em;"
|colspan=11 style="background: darkred; color: yellow; font-size: 120%; text-align: center"|'''Basic Objects'''
|-
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 1px 1px 0" width=100|'''Name'''
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 1px 1px 1px" width=50|'''Appearance'''
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 1px 1px 1px" width=50|'''HP'''
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 1px 1px 1px" width=50|'''Armor'''
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 1px 1px 1px" width=50|'''Fragile'''
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 0 1px 1px"|'''Special'''
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 1px 1px 0 0"|floor
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|'''·'''
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|none
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 1px 0 0 1px"|N/A
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|blood
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''·'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|none
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|N/A
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|pool of blood
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''•'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|none
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|N/A
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|Phobos rock
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''.'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|none
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|N/A
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|wall, blooded wall
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''#''', '''#'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|10
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|10
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|no
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|N/A
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|bloodstone, blooded wall
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''#''', '''#'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|15
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|10
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|no
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|N/A
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|green wall
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''#'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|15
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|10
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|no
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|N/A
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|crate, blooded crate
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''#''', '''#''', '''#'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|5
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|5
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|no
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|N/A
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|ammo crate, armor crate, blooded crate
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''#''', '''#''', '''#'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|5
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|5
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|yes
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|When destroyed, sometimes leaves behind ammo, armor, boots or medpacks depending on the crate type and seed. Note that walls have HP, a wall's hp can be downgraded to 1HP and still be standing.
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|closed door
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''+'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|6
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|4
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|yes
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|Can be opened.
|-style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|locked door
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''+'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|6
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|6
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|yes
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|N/A
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|open door
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''/'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|none
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|N/A
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|Can be closed.
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|[[lever]]
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''&'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|10
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|0
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|no
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|see link in name for details
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|barrel of fuel
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''0'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|2
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|3
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|yes
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|Can be pushed. When destroyed, creates a radius 4 [[explosions|explosion]] dealing 5d5 [[Damage type#fire|fire damage]].
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|barrel of acid
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''0'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|2
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|4
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|yes
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|Can be pushed. When destroyed, creates a radius 3 [[explosions|explosion]] dealing 6d6 [[Damage type#acid|acid damage]], sometimes leaving behind acid tiles.
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 0 1px 0 0"|barrel of napalm
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|'''0'''
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|2
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|5
|style="text-align: center; border: solid darkred; border-width: 0 1px 0 1px"|yes
|style="text-align: center; border: solid darkred; border-width: 0 0 0 1px"|Can be pushed. When destroyed, creates a radius 2 [[explosions|explosion]] dealing 7d7 [[Damage type#fire|fire damage]], sometimes (often) leaving behind lava tiles.
|}

==Random levels==
The archetypical level in DRL is a randomly-generated one. It is produced in such a way that no two games are particularly alike. There are many special considerations within the game engine, although many of these are technical and unimportant from a gameplay perspective.

* [[Level type]]
* [[Level feeling]]
* [[Level event]]
* [[Monster Generation]]
* [[Item Generation]]
* [[Room Generation]]
* [[Fluids]]

== Special levels ==
In stark contrast to random levels, special levels are constant and many of them appear every game. A few are static levels you must always go through on their designated floors (with the exception of certain challenges disabling them), while the rest are optional levels you may enter inbetween floors if you find the stairs to them (the entry to which are highlighted by red stairs). Each special level tends to have a gimmick to it, and completing them without the right equipment and plan can be very difficult, especially so on harder difficulties, but they offer great rewards that you will have a hard time procuring normally (or even be unable to obtain at all otherwise), as well as substantial EXP to level you up to a greater degree.

For obvious reasons, all of these pages are considered spoilers if you wish to learn how to beat them yourself. Some are particularly spoiler-heavy, though, and are indicated as such here.

* [[Phobos Base Entry]]
* [[Hell's Arena]]
* [[The Chained Court]]
* [[Military Base]]
* [[Phobos Lab]]
* [[Phobos Anomaly]]
* [[Hell's Armory]]
* [[Deimos Lab]]
* [[The Wall]]
* [[Containment Area]]
* [[Abyssal Plains]]
* [[City of Skulls]]
* [[Halls of Carnage]]
* [[Spider's Lair]]
* [[Tower of Babel]]
* [[The Vaults]]
* [[House of Pain]]
* [[Unholy Cathedral]] (Spoilers!)
* [[The Mortuary]] (Spoilers!)
* [[Limbo]] (Spoilers!)
* [[The Lava Pits]]
* [[Mt. Erebus]]
* [[Dis]] (Spoilers!)
* [[Hell Fortress]] (MAJOR SPOILERS!)

===Special level placement===
Some levels don't spawn on I'm Too Young To Die: Hell's Armory/Deimos Lab, The Vaults/House of Pain, Unholy Cathedral, and The Mortuary/Limbo.

Special stairs are always placed on a random empty tile.

Special level pairs are chosen randomly - exactly one from each pair appears per game.

{|
|'''Level'''
|'''Depth'''
|-
|Hell's Arena
|2 (Phobos 2)
|-
|The Chained Court
|5 (Phobos 5)
|-
|Phobos Lab/Military Base
|7 (Phobos 7)
|-
|Hell's Armory/Deimos Lab
|9 (Deimos 1)
|-
|The Wall/Containment Area
|11 (Deimos 3)
|-
|City of Skulls/Abyssal Plains
|12 (Deimos 4)
|-
|Spider's Lair/Halls of Carnage
|14 (Deimos 6)
|-
|The Vaults/House of Pain
|17 (Hell 1)
|-
|Unholy Cathedral
|19 (Hell 3)
|-
|The Mortuary/Limbo
|20 (Hell 4)
|-
|The Lava Pits/Mt. Erebus
|22 (Hell 6)
|}

Strategy:Ultra-violence

2025-08-11T12:39:42Z

Epyon:

{{infostrat switch}}

== Welcome to Hell ==
The name does not lie. Ultra-Violence is ultra-hard. Enemies get a +2 bonus to their accuracy, making it almost certain that even weak enemies will hit you if you're not dodging, and [[hell knight]]s can start spawning on level ''3,'' which means you get one level after [[Phobos Base Entry]], maybe [[Hell's Arena]], before you have to fight them. [[Demon]]s will be appearing right from the start. Barons of Hell will appear on level 6. [[Revenant]]s and [[Former commando]]s can start spawning while you're still in ''Phobos,'' and of course [[Mancubi]] and [[Arch-vile]]s will become common enemies early in Deimos.

Fooling-around builds have no place on Ultra-Violence unless you're really, '''''really''''' good. You have no time to arm up or get stronger, and it's possible to get an unlucky spawn location such that the only door leading out of your starting room will put you face-to-face with a hell knight and six demons, so you'll die and die very early on unless you have a plan and know exactly what you're doing. Never let yourself drop below 40% health, since you can get killed by a great many things in one attack at that health. Get good at corner shooting, giftdropping, and radar-shooting, because you're gonna need them. It's time to really start skipping special levels if you don't have a plan to beat it, because they will just kill you more often than not. [[Phobos Lab]] contains over a dozen [[nightmare demon]]s, which are very likely to kill you even if you're prepared because they'll get stuck in narrow halls you need to enter to progress, and they won't come out until they see you. Without two levels of [[Hellrunner]], even running is too slow to get away from them.

On the bright side, though, there's now a guaranteed green armor in [[Phobos Base Entry]]! It'll almost certainly be used, but it's something!

Since you have no time to prepare before the going gets ridiculously tough, you have to be familiar with the game's base mechanics and know what to do for every little situation that crops up. D veterans may be tempted to start here, but really, do not. You'll lose so fast that it won't teach you anything. You may also want to skip going for 100% kills every time until you're familiar with the difficulty level. It may level you up faster, but you'll also put yourself in more of the already-increased danger.

== Starting ==
Even the first level of the game will be a huge challenge if you don't know how to handle it. With no plan, it can kill you, or at best make you use one of your starting med-packs while leaving you no way to rescue the others. There is a better way, though. (see [[Strategy:Phobos Base Entry]])

Once you're in, there are a few ways of surviving the first few levels with little issue, even with 100% kills barring a challenge run.

=== Fast DPS ===
This is a risky but oftentimes rewarding strategy. Essentially what this entails is going for your DPS-increasing traits first, before any investment in survivability. For Rapid builds, that's [[Eagle Eye]] and [[Son of a Bitch]]. For Pistols, that's [[Son of a Gun]]. For shotgunners, that's [[Reloader]] and [[Finesse]]. Don't just go for your favorite DPS method, though, you need to have a plan, so it's better if this investment leads to something that also helps you survive.

* If you get [[Eagle Eye]], go for 2 levels of that and then get [[Intuition]] 2. Use Rapid weapons over pistols, even if you're going for a pistol build. Being able to see huge clusters of enemies before you open that door and aggro them all is going to save your life. Even good players can't reliably make plans without more information.

* If you get [[Finesse]], get [[Juggler]] next. Pick up every single [[shotgun]] you see. Now instead of reloading, press 2 to switch to your pistol and 3 to switch back to a shotgun. It will pick a shotgun that's already loaded every time, and this gives shotguns excellent DPS early-game at the cost of inventory slots. If you tossed your pistol, fear not, you can just use the mouse wheel (if you have one) to select fists then switch back to a shotgun.

* If you get [[Son of a Gun]], good luck, because while this can and does definitely work, you're playing on an extra layer of hard mode now, and you're more likely to die by getting unlucky. With at least two levels of SoG, if you hit a Former once, use an aimed shot to finish it off. If you get Dualgunner, aimed shots will take out formers in one attack semi-reliably. Get all 3 levels of Son of a Gun before anything else if you go this route. This is realistically your only option in Angel of Marksmanship.

* If you get [[Brute]], get [[Berserker]]. Being able to go berserk can save your life even if you need to run because of the resistances and action speed it grants you.

=== Fast Movespeed ===
This is by far the most safe and reliable strategy: get two levels of Hellrunner first and use a shotgun for DPS. Obviously, your damage will be lower out the gate, but Hellrunner gives you so much safety over the long run it's not even funny. By far the biggest hurdle to reaching the rest of the game is survival, and Hellrunner will allow you to outrun Demons without switching tactics to Running as long as you're wearing green armor or lighter, especially as a Scout, and if you do start Running, outrunning them will be trivial. In addition, two levels of Hellrunner gives you an extra 30% chance to dodge attacks while sidestepping. This works independently of enemy Accuracy, but only if you're sidestepping as you move - basically, don't run directly at an enemy's line of fire or directly away from it and you'll roll a chance to dodge. This does basically nothing against formers, who can't really be dodged unless you have [[Dodgemaster]], but against [[imp]]s, [[hell knight]]s, [[cacodemon]]s, and [[Barons of Hell]]? You will dodge against those enemies 80% of the time at ''minimum.'' Your dodge chance is then capped if you start Running.

Combined together, those stats mean you can now play ring around the rosie using columns and clusters of boxes. Without Hellrunner, if you take a step around a corner of a box cluster while an enemy is at the other corner, you'll take a step and that enemy will take a step forward and still be able to see you. They may even get to attack afterward, and you will NOT get to dodge because the last thing you did from that enemy's PoV was stand perfectly still. With Hellrunner 2, however, you're basically always moving at Running speed. Eventually, you will be able to move and move and move, and then on one of those moves you'll be out of the enemy's vision, which can give you time to reload your weapon, and possibly even enough time to take a step toward that enemy, which gives you a successful dodge roll, which causes them to hit themselves with their own attack as it collides with the wall you were just behind. Risky, but hilarious! It's even more reliable if you're Running.

Because of this trick, you can play Bugs Bunny with the barons of hell, hell knights, and cacodemons. You can even use this trick to make pinkies forget they ever saw you and go running off somewhere else!

Because of how good Hellrunner 2 is, you don't even really need Dodgemaster unless your build calls for it specifically. Once you get Hellrunner 2, it's better to start up your DPS path right away rather than delay it another level. Otherwise, you won't have enough DPS to kill the enemies this ''doesn't'' work against.

=== Fast Intuition ===
This is mainly an option for Scouts, but can also be used by other classes as a hybrid of Fast DPS by taking Eagle Eye 1/2 first, then taking Intuition 1/2 next. Scouts, however, are the creme de la creme of this option, since they can just go Intuition at level 1 and 2. Now that you always know if there's something around every corner, you never have to take any risks you can't afford to handle right now, and you can also avoid blindly shooting into the fog if there's a powerup over there. Being able to sense powerups and know which levers to avoid is such an immense benefit in the first few levels that it can save a run. For that reason, this is an incredible option that can work even through Nightmare! runs.

Once you get Intuition 2, start up a DPS level or two before you dive straight into Hellrunner (if you're allowed).

== Good Luck ==

From there, it's up to you to know your build and how strong it gets and how fast for what to take next! UV is going to test your fundamentals like no other and some builds may sadly stop being viable here unless you theorycraft something amazing. In which case, share your findings! It's always exciting to have more ways to play the game.

Strategy:Demon

2025-08-11T12:39:34Z

Epyon:

__NOTOC__
{{infostrat switch}}
== Main Guide (v0.9.9.4) ==

=== Version Changes (v0.9.9.5) ===
Nothing significant to the enemy itself.

=== General Tactics ===
Basic strategy posted by [[User:Elephant|Elephant]] 22:43, November 15 2011 (GMT).

Demons are the most melee-oriented enemies of the game. Lacking ranged attacks or any special abilities, their strategy consists of running up to the player to beat him up. They can't use doors or items, and will run trough any fluid to reach the player, which can be used effectively against them. The demons have a speed of 130%, meaning that while they can only attack in melee, they will reach the player quickly, are hard to run away from, and will often hit twice for a player's action. They hit fairly hard and have some armor, but lack any resistances. They rarely miss.
*Since demons don't have a ranged attack, they are harmless if they don't get close to you. Unfortunately, you sometimes just turn a corner and find a demon really close to you, and when they do attack you it will hurt. The key is to listen for the monster sounds, and recognize when there are demons nearby so you don't get surprised. [[User:Matt_S|Matt_S]] 5:22, November 10 2011 (GMT)
*They are fairly fast, so if you decide to run from them, you had better have a destination in mind that is close by, because, unless you have levels in Hellrunner or something else that boosts your speed, they will catch up to you. [[User:Tormuse|Tormuse]] 13:48, November 15 2011 (GMT)
**Running, which grants a 30% boost, will actually keep demons at bay (without worrying about other modifiers). Remember this if you are ever swarmed in a demon cave. [[User:S.K.Ren|S.K.Ren]] 17:07, November 14 2011 (GMT)

In the early levels, demons can be quite lethal, as the player lacks effective means to dispose of them before they get close (doubly so for melee runs), but later, when the player has more traits, weaponary and armor, they will not pose a threat but in the most unlucky scenarios.

|HITS NEEDED TO KILL PLAYER |
|no armor | 1 armor | 2 armor | 4 armor |
|min|avg|max|min|avg|max|min|avg|max|min|avg|max|
50hp | 6 | 8 | 9 | 8 | 9 |10 | 9 |10 |13 |13 |17 |25 |
100hp |13 |15 |17 |15 |17 |20 |17 |20 |25 |25 |34 |50 |
60hp | 8 | 9 |10 | 9 |10 |12 |10 |12 |15 |15 |20 |30 |
120hp |15 |18 |20 |18 |20 |24 |20 |24 |30 |30 |40 |60 |
80hp |10 |12 |14 |12 |14 |16 |14 |16 |20 |20 |27 |40 |
160hp |20 |23 |27 |23 |27 |32 |27 |32 |40 |40 |54 |80 |

*In general, you should follow this mindset against demons:
*:Stay at range. Its the best way to deal with them, period.
*:Don't neglect basic scouting techniquies like corner checking and listening. Nothing is more embarassing than walking into a trap.
*:Be mindful of your weapon when dealing with them. And be sure it's loaded at all times, as it should be. [[User:S.K.Ren|S.K.Ren]] 17:07, November 14 2011 (GMT)

=== Intelligence Analysis ===
The AI of the demons is probably the simplest in the game. Without any ranged offense, the demons will just run towards the player or melee him. Their unability to open doors and disregard for lava or acid puts them at disadvantage.
*Demons are probably the most dangerous when there are other enemies around to distract you, either enemies that do have ranged attacks or other demons that are approaching from different angles so that you can't hurt them all at once with shotgun blasts. If there are enemies that have ranged attacks, you should consider getting behind any cover that is nearby to keep from being shot at while you take care of the demons; if you don't have any cover, you should consider retreating if the enemies are too strong to take out easily, but the best solution to this situation is to simply do all you can to avoid it. If you are attacked by multiple demons approaching from different angles, you might want to consider running, either as an actual retreat or simply to get them all in your line of fire. [[User:Matt_S|Matt_S]] 5:22, November 10 2011 (GMT)
*They also have a slightly lower visual radius than you, so if you do find yourself in a situation where you're not capable of dealing with them, just keep them at the edge of your visual range, and they won't be able to see you, so they won't chase you. [[User:Tormuse|Tormuse]] 13:48, November 15 2011 (GMT)

==== Doors ====
Fighting demons is best done behind an open door, so that the door can be closed if one gets dangerously close. Then you can either wait for a while for the demon to stop chasing you and hopefully wander awayfrom the door (hard to know if you don't have tracking map/intuition 2), or get some distance to the door and blast it open letting the demons in. Note that some other monster might open the door, letting the demons in. Since demons are fast, it's usually better to close the door before they are just next to it, in case they get 2 moves.

#
#
#
#xx
#xx c
@/xx
#xx
#xx
#

When the demon reaches the "x", close the door.

==== Fluids ====
Demons, unlike other non-flying non-boss monsters, will chase you through any fluid. This means that acid/lava pools will become quite useful when fighting demons, especially for melee builds or groups of demons, or when you are REALLY short of ammo. Note that this also means that an acid puddle in a corridor will not stop them at their tracks.
*You can maximize the benefit of their fluid-walking by shooting them with the a to knock them back, forcing them to walk over the same squares of acid or lava over and over again. [[User:Tormuse|Tormuse]] 13:48, November 15 2011 (GMT)

By careful positioning, you can usually maximize the amount of harm the fluids will cause. Three turns on lava or seven on acid will kill them.

##############

==
====
X ====
== c
@ =
##############

If you move to position X, the demon will have to move through 4 tiles of acid/lava, instead of 1.

Melee characters will want to fight next to acid/lava, so that the demon will have to stay in the fluid, taking damage every turn.

c
#######/#######
===============
########X######

The correct position to take is marked by X.

==== Barrels ====
Luring demons near barrels is somewhat harder than luring B:s and h:s, due to their considerable speed and the fact that you can't giftdrop and have to use yourself as a lure. ut, if there's a demon next to a barrel, you are far enough (or have fireangel) and there is nothing important that might blow up, go on. (Note that the knockback might blow the demon closer to you if the barrel's behind them.)

They might be useful for clearing early vaults, by placing them next to the vault door, opening it, running a bit away and blowing it up with a shotgun when the demons follow. Note that this might destroy the items inside, so it's a bit of gamble.

=== Weapon Usage ===

==== Melee ====
Melee is arguably the worst way to dispatch demons, since you are very likely to get hurt in the process, especially when you lack the traits to do any serious damage. However, using the tricks mentioned earlier in this guide will make it easier to survive to the point you can reliably kill them in one or two hits.
*Demons have a hefty +3 to hit for melee. However, the running tactic impacts this by causing a -3 chance to-hit, so while it's not as effective as it would be versus other enemies, it can still cause a demon to miss, sparing you that hit and hopefully giving you time to kill it. Keep in mind that your melee damage is halved during this time. [[User:S.K.Ren|S.K.Ren]] 17:07, November 14 2011 (GMT)

In the start of the game it's recommended that you use another weapon or, if that is not possible, avoid them completely until you get beefier and recive better equipment.(And if you're doing a N! fist-only 100% run, you probably already knew you were screwed.)

===== Fists =====
Fighting demons with only your fist is almost always a very bad idea. Without brute, you will only make 1 point worth of damage every hit. With the demon having 25 hp, it will take you a long time and a ton of medpacks if you wish to kill them. With Brute1 and 2 the damage will rise to 2-4 and 5-7, but you will still take a few hits. However, with Brute 5 you will two-shot them everytime.(Note that berserking makes one-hit kills possible with Brute 4 and 5.)

Berserking and doing the fluid tricks will help a lot, but the best option might just be running away.

FIST HITS NEEDED TO KILL

min|avg|max
No Brute|25 |25 |25
Brute 1 | 7 | 9 |13
Brute 2 | 4 | 5 |5
Brute 3 | 3 | 3 |4
Brute 4 | 2 | 3 |3
Brute 5 | 2 | 2 |2

===== Combat Knife =====
Finding a knife will make slaying demons in melee a lot easier. it will deal 1-8 damage with the average of 4 even without any traits. Also, it can be thrown, unlike any other melee weapon. It's a good idea to throw one (or even two with Juggler and Finesse) at the demon before contact to soften it a little.

One-hit kills are possible from Brute2 with Malicious Blades or while berserking.

KNIFE HITS NEEDED TO KILL

min|avg|max
No Brute| 4 | 7 |25
Brute 1 | 3 | 4 |7
Brute 2 | 2 | 3 |4
Brute 3 | 2 | 2 |3
Brute 4 | 2 | 2 |2
Brute 5 | 2 | 2 |2

===== Other =====
The Chainsaw will, like in the original D, make short work of demons, being capable to one-hit with just one trait of Brute. Getting the chainsaw is the point for most melee builds when solitary demons stop being threathening, only beign dangerous in groups.

Chainswords are exactly like chainsaws, except more accurate. Piercing blades ignore armor, dealing 2 points more damage to demons. Chainsaw assemblies and melee uniques will wipe the floor with puny pinkies.

CHAINSAW HITS NEEDED TO KILL

min|avg|max
No Brute| 2 | 3 |13
Brute 1 | 1 | 2 |5
Brute 2 | 1 | 2 |4
Brute 3 | 1 | 2 |3
Brute 4 | 1 | 2 |2
Brute 5 | 1 | 1 |2

==== Pistols ====
Whitout SoG it's practically impossible to kill the demon with a pistol before it reaches you, and you need SoG2 to do so reliably. Dualwielding will kill quickly, but don't dualreload if a demon has managed to get at bite distance. Also, with enough SoG and power mods, you will be able to cause knockback, making demons even easier to kill without getting hurt.
*Pistols work if you can fire them fast enough. An unmodded pistol without SoG will rarely be able to take out a demon in one clip. This makes dealing with packs dangerous. If you're forced to use a pistol early game, you're best bet is to shoot them from out of sight(Use Aimed Shots to improve your chance of hitting) and finish them off with a second clip as they approach. [[User:S.K.Ren|S.K.Ren]] 17:07, November 14 2011 (GMT)

PISTOL HITS NEEDED TO KILL

min|avg|max
No SoG | 5 | 9 |25
SoG 1 | 4 | 7 |25
SoG 2 | 4 | 5 |13
SoG 3 | 3 | 5 |9
SoG 4 | 3 | 4 |7
SoG 5 | 3 | 4 |5

==== Shotguns ====
Shotguns are quite useful against demons. While they have be reloaded/pumped after every shot, the knockback lessens the effect. They can also hit multiple enemies at the same time, always hit, and need no traits to be effective.(Except the double shotty)
*Despite their armor, shotguns are probably the best way to take out a demon early on. The knockback will keep the demon from getting too close, and you can probably take it down with three or four shots, often without the demon getting a chance to attack you. For the best ammo efficiency without too much risk, you should fire when the demon is a couple of squares away from the edge of your view. [[User:Matt_S|Matt_S]] 5:22, November 10 2011 (GMT)

The double shotgun needs, due to it's reload time, either specific tactics or Shottyman to be effective. With Shottyman, you can just step away from the demons and fire again, but without it, it can still be used quite effectively by using doors.

DOUBLE SHOTGUN AND DOORS

# # #
# # #
@/c @+ c @/c
# # #

1.Open the door and 2.Close the door and 3.Repeat as necessary.
fire. reload.

Note that shotguns deal sharpnel damage and thus the demon's armor will block 4 instead of 2 points of damage. Shotguns suffer damage reduction at range.

SHOTGUN BLASTS NEEDED TO KILL (Note that the vaules are for point-blank shots)

|shotgun |combat s. |double s.
|min|avg|max|min|avg|max|min|avg|max
no traits | 2 | 3 | 9 | 2 | 3 |13 | 1 | 2 |4
SoB 1 | 2 | 3 | 7 | 2 | 3 | 9 | 1 | 2 |4
SoB 2 | 2 | 2 | 5 | 2 | 3 | 7 | 1 | 1 |3
SoB 4 | 2 | 2 | 4 | 2 | 2 | 5 | 1 | 1 |2
MAD | 2 | 2 | 4 | 2 | 2 | 5 | 1 | 1 |2
MAD + SoB2 | 2 | 2 | 3 | 2 | 2 | 4 | 1 | 1 |2

==== Rapid-fire ====

===== Chaingun =====
Without traits, you will miss a lot at long ranges, and your bullets will do only 1 point of damage half of time. Thus, it's better to use the shotgun on demons until you get a few traits, like EE, SoB or TH.
*Chainguns are like pistols on crack. Less accurate but waaaay more bullets. You can usually clear groups of 1-3 with a chaingun without issue. Just be sure to reload whenever you can. [[User:S.K.Ren|S.K.Ren]] 17:07, November 14 2011 (GMT)

DO NOT RELOAD WHILE A DEMON IS NEXT TO YOU! You will get your ass handed to you. Rather, have a spare chaingun and pull it out of your pack if you run out of bullets.

CHAINGUN BULLETS NEEDED TO KILL

min|avg|max
no traits | 7 |13 |25
SoB1 | 5 | 9 |25
SoB2 | 5 | 7 |25
SoB3 | 4 | 5 |13
SoB4 | 4 | 5 |9
SoB5 | 3 | 4 |7

Note that the numbers here are for individual bullets, not bursts. To calculate amount of bursts needed, divide the result by 4 + amount of TH traits, and always round up. For example, With SoB2 and TH1, the average amount of bursts needed is 7 : (4 + 1) = 1.4 = 2.

===== Plasma Rifle =====
Using the plasma rifle on demons is usually waste of power cells. Do it only if you have no other ammo left, or as a last resort if you are low on health and there's a group of demons closing in. The plasma rifle will kill demons very fast, even without any traits. It ignores half of armor.
*Plasma Rifles are just super Chainguns. When you start finding those, you should have more than enough fire power to deal with demons. [[User:S.K.Ren|S.K.Ren]] 17:07, November 14 2011 (GMT)

PLASMA RIFLE BULLETS NEEDED TO KILL

min|avg|max
no traits | 5 | 9 |25
SoB1 | 4 | 7 |25
SoB2 | 4 | 5 |13
SoB3 | 3 | 5 |9
SoB4 | 3 | 4 |7
SoB5 | 3 | 4 |5

To calculate bursts, x being the result from the chart: x : 6 + TH, rounded up.

==== Explosive ====

===== Rocket Launcher =====
Using the rocket launcher against solitary demons is a waste of rockets and potentially dangerous, but against groups of demons it's pretty useful and potentially dangerous. The explosion might knock some of them closer to you, so have shotty prepared, just in case.

The rocket launcher deals in theory 4-34 points of damage to demons, but practically the number is lower.

===== BFG9000 =====
You're not going to waste 40 power cells on a demon, are you?
*This of course can depend on the situation: if you don't have a shotgun or melee weapon and are caught in the middle of a swarm, it might not be a bad idea. It is highly unlikely that you will be stuck in this case, however, given that the BFG9000 appears halfway through the game and caves are spawning cacodemons by then. [[User:Game Hunter|Game Hunter]] 17:47, 10 January 2012 (CET)

VBFG9000

2025-08-11T12:39:24Z

Epyon:

{{infostrat switch}}
{{ranged weapon|
weapon_name=VBFG9000 - [[Big_Gun_Types|Big Gun Family]]|
weapon_dmg=Original +2 sides per die, [[explosions|radius]] +2|
weapon_avgdmg=Varies|
weapon_dmgtype=[[Damage type#Plasma|Plasma]]|
weapon_accuracy=Original|
weapon_ftime=Original|
weapon_rtime=Original|
weapon_clip=Original*1.5 (consumes 1.5 times original per shot)|
weapon_ammo=[[Power cell]]|
weapon_afire=None|
weapon_areload=[[Alternate reload#Overcharge|Overcharge]]|
weapon_get=[[Assemblies|Assembly]]: Any [[BFG 9000]] + PPP|
weapon_quote=N/A|
weapon_looks=}|
weapon_description=Assembly (same as original)|
weapon_other=N/A|
weapon_source=Modelled on the good ol' BFG 9000}}

Super shotgun

2025-08-11T12:39:14Z

Epyon:

{{infostrat switch}}
{{ranged weapon|
weapon_name=Super shotgun|
weapon_dmg=(8d4)x2/16-64, [[Shotguns|normal shotgun blast]]|
weapon_avgdmg=20 × 0.93 × 2 = 37.4|
weapon_dmgtype=[[Damage type#shrapnel|Shrapnel]]|
weapon_accuracy=+0|
weapon_ftime=1.0 second|
weapon_rtime=1.5 seconds|
weapon_clip=2|
weapon_ammo=[[Shotgun shell]]|
weapon_afire=None|
weapon_areload=None|
weapon_get=Random (10+)|
weapon_quote=''This little baby brings back memories!''|
weapon_looks=}|
weapon_description=''After the first hellish invasion, weapon engineers designed the super shotgun as the world's first firearm designed to kill demons. And boy does it.''|
weapon_other=[[Nano-shrapnel]] Super Shotgun + P is one of the few "Click to win" class ultra-powerful weapons, but it also doesn't destroy items.|
weapon_source=DII (whaddya expect, Mario?)}}

Nuclear BFG 9000

2025-08-11T12:39:06Z

Epyon:

{{infostrat switch}}
{{ranged weapon|
weapon_name=Nuclear BFG 9000 - [[Big_Gun_Types|Big Gun Family]]|
weapon_dmg=8d6/8-48, [[explosions|radius]] 8|
weapon_avgdmg=28|
weapon_accuracy=+5|
weapon_dmgtype=[[Damage type#plasma|Plasma]]|
weapon_ftime=1.5 seconds|
weapon_rtime=N/A|
weapon_clip=40 (consumes 40 per shot)|
weapon_ammo=None|
weapon_areload=[[Alternate reload#nuke|Nuclear overcharge]]|
weapon_afire=None|
weapon_get=Random (22+) or [[The Mortuary]]/[[Limbo]]|
weapon_quote=None|
weapon_looks=}|
weapon_description=''A self-charging BFG9000! How much more lucky can you get?''|
weapon_other=Just more lucky as to have [[Biggest fucking gun|two B and three F]] in order to clear the level in one click for free. The nuclear BFG 9000 automatically recharges 1 ammo on each of the wielder's actions. It cannot be otherwise reloaded or unloaded.|
weapon_source=The original BFG 9000 is, of course, from D. The nuclear version appears to be unique to DRL. Imbalanced BFG Family is a significant part of the D/Quake universe, even in canon.|
}}

BFG 9000

2025-08-11T12:38:59Z

Epyon:

{{infostrat switch}}
{{ranged weapon|
weapon_name=BFG 9000 - [[Big_Gun_Types|Big Gun Family]]|
weapon_dmg=10d6/10-60, [[explosions|radius]] 8|
weapon_avgdmg=35|
weapon_dmgtype=[[Damage type#Plasma|Plasma]]|
weapon_accuracy=+5|
weapon_ftime=1.0 second|
weapon_rtime=2.0 seconds|
weapon_clip=100 (consumes 40 per shot)|
weapon_ammo=[[Power cell]]|
weapon_afire=None|
weapon_areload=[[Alternate reload#Overcharge|Overcharge]]|
weapon_get=Random (20+), [[Halls of Carnage]], [[Spider's Lair]]|
weapon_quote=''HELL, NOW YOU'LL GET LOOSE!''|
weapon_looks=}|
weapon_description=''The Big Fucking Gun. Hell wouldn't be so fun without it.''|
weapon_other=The BFG 9000 is automatically equipped the first time it is picked up. (Juggler applies.) It deals half the normal amount of explosive knockback and doesn't harm the wielder.|
weapon_source=D}}

Plasma rifle

2025-08-11T12:38:53Z

Epyon:

{{infostrat switch}}
{{ranged weapon|
weapon_name=Plasma rifle - [[Rapid-fire_Types|Rapid-fire Family]]|
weapon_dmg=(1d7)x6/6-42|
weapon_avgdmg=4 × 6=24|
weapon_dmgtype=[[Damage type#Plasma|Plasma]]|
weapon_accuracy=+2|
weapon_ftime=1.0 second|
weapon_rtime=2.0 seconds|
weapon_clip=40|
weapon_ammo=[[Power cell]]|
weapon_afire=[[Alternate fire#Chain fire|Chain fire]]|
weapon_areload=[[Alternate reload#Overcharge|Overcharge]]|
weapon_get=Random (12+), dropped by [[Former commando|former commandos]].|
weapon_quote=''Peace through superior firepower!''|
weapon_looks=}|
weapon_description=''A plasma rifle shoots multiple rounds of plasma energy -- frying some demon butt!''|
weapon_other=N/A|
weapon_source=D}}

Vision

2025-08-11T12:38:42Z

Epyon:

Vision (or line-of-sight) is the process by which tiles around the player are revealed.

The player also has a sight [[Distance|radius]]. By default, this sight radius is 8, but it can be increased to 10 with the [[Traits|Cateye]] trait. Additionally, some other effects can reveal a limited number of objects outside the player's sight radius.

Certain tiles (like walls) block the player's vision. The effects of these obstructions are calculated by a modification of Isaac Kuo's [http://roguebasin.roguelikedevelopment.org/index.php?title=Isaac_s_fast_beamcasting_LOS fast beam casting algorithm]. The exact algorithm used by DRL is open-source as a part of [http://sourceforge.net/projects/fpcvalkyrie/ FPC Valkyrie].

Chaingun

2025-08-11T12:38:33Z

Epyon:

{{infostrat switch}}
{{ranged weapon|
weapon_name=Chaingun - [[Rapid-fire_Types|Rapid-fire Family]]|
weapon_dmg=(1d6)x4/4-20|
weapon_avgdmg=3.5*4=14|
weapon_dmgtype=[[Damage type#bullet|Bullet]]|
weapon_accuracy=+2|
weapon_ftime=1.0 second|
weapon_rtime=2.5 seconds|
weapon_clip=40|
weapon_ammo=[[10mm ammo]]|
weapon_afire=[[Alternate fire#Chain fire|Chain fire]]|
weapon_areload=None|
weapon_get=Random (6+), dropped by [[Former captain|former captains]], and part of the rewards in [[Hell's Arena]].|
weapon_quote=''Phobos ReLEADed, oh yeah!''|
weapon_looks=}|
weapon_description=''Chaingun directs heavy firepower onto your opponent making him do the chaingun cha-cha.''|
weapon_other=N/A|
weapon_source=There are [http://en.wikipedia.org/wiki/Chain_gun chain guns] in real life. However, in the original D game, the chaingun looked more like a [http://en.wikipedia.org/wiki/Gatling_gun gatling gun] (of which this game [[gatling gun|also has]]).}}

Double chainsaw

2025-08-11T12:38:23Z

Epyon:

{{infostrat switch}}
{{melee weapon|
weapon_name=Double chainsaw - [[Melee_Types|Melee Family]]|
weapon_dmg=4d12/4-48|
weapon_avgdmg=26|
weapon_dmgtype=[[Damage type#Melee|Melee]]|
weapon_accuracy=-1|
weapon_afire=None|
weapon_get=[[Assemblies|Assembly]]: {{exotic link|chainsaw}} + PPB|
weapon_quote=N/A|
weapon_looks=\|
weapon_description=Assembly (same as original)|
weapon_other=N/A|
weapon_source=D 64.}}

Chainsaw

2025-08-11T12:38:15Z

Epyon:

{{infostrat switch}}
{{melee weapon|
weapon_name=Chainsaw - [[Melee_Types|Melee Family]]|
weapon_dmg=4d6/4-24|
weapon_avgdmg=14|
weapon_dmgtype=[[Damage type#Melee|Melee]]|
weapon_accuracy=+0|
weapon_afire=N/A|
weapon_get=Random (12+), and in [[The Chained Court]].|
weapon_quote=''BLOOD! BLOOD FOR ARMOK, GOD OF BLOOD!''|
weapon_looks=\|
weapon_description=''Chainsaw -- cuts through flesh like a hot knife through butter.''|
weapon_other=You get a [[Berserk Pack]] effect when you pick this weapon up the first time.|
weapon_source=D, of course.}}

Modding:being API (0.9.9.7)

2025-08-11T12:37:18Z

Epyon:

''This page is currently under construction.''

== API ==

Please note that the type "integer" indicates an numeric value without a decimal part. It does not indicate the range of acceptable values.

An argument name in [square brackets] is an optional one. The function description will indicate how the function operates if it is omitted.

The [[Modding:Thing#API|Thing API]] can also be used with beings.

=== Being API Function List ===

{|class="wikitable" style="border: 2px solid darkred; border-spacing: 0; font-size: 90%; margin: 0.25em 0.5em;"
! colspan="2" style="background: darkred; color: yellow; font-size: 120%; text-align: center"|Being Interface
{{Table2Col
|es=background: #333;
|c1=font-weight:bold; text-align:right; vertical-align:top; padding:0px 2px;
|c2=padding:0px 2px;
|{{modarg|Being}}|{{moddef|list|new|dot||BeingID|id}}
|{{modarg|void}}|{{moddef|list|kill|cln||boolean|[overkill]}}
|{{modarg|void}}|{{moddef|list|ressurect|cln||integer|range}}
|{{modarg|void}}|{{moddef|list|apply_damage|cln||integer|amount|BodyTarget|target|DamageType|[type]}}
|{{modarg|void}}|{{moddef|list|get_name|cln||boolean|[known]|boolean|[capitalize]}}
|{{modarg|table}}|{{moddef|list|inv_items|cln}}
|{{modarg|Item}}|{{moddef|list|get_eq_item|cln||EquipSlot|slot}}
|{{modarg|void}}|{{moddef|list|set_eq_item|cln||EquipSlot|slot|Item|item}}
|{{modarg|boolean}}|{{moddef|list|add_inv_item|cln||Item|item}}
|{{modarg|void}}|{{moddef|list|play_sound|cln||SoundID|sound}}
|{{modarg|integer}}|{{moddef|list|get_total_resistance|cln||ResistType|resist|BodyTarget|[target]}}
|{{modarg|boolean}}|{{moddef|list|quick_swap|cln}}
|{{modarg|boolean}}|{{moddef|list|pickup|cln}}
|{{modarg|boolean}}|{{moddef|list|unload|cln||Item|item}}
|{{modarg|boolean}}|{{moddef|list|drop|cln||Item|item}}
|{{modarg|boolean}}|{{moddef|list|use|cln||Item|item}}
|{{modarg|boolean}}|{{moddef|list|wear|cln||Item|item}}
|{{modarg|boolean}}|{{moddef|list|attack|cln||Being|target}}
|{{modarg|boolean}}|{{moddef|list|attack|cln||Coord|target}}
|{{modarg|boolean}}|{{moddef|list|fire|cln||Coord|target|Item|weapon}}
|{{modarg|boolean}}|{{moddef|list|alt_fire|cln||Coord|target|Item|weapon}}
|{{modarg|boolean}}|{{moddef|list|reload|cln}}
|{{modarg|boolean}}|{{moddef|list|alt_reload|cln}}
|{{modarg|integer}}, {{modarg|Coord}}|{{moddef|list|direct_seek|cln||Coord|dest}}
|{{modarg|void}}|{{moddef|list|relocate|cln||Coord|dest}}
|{{modarg|boolean}}|{{moddef|list|path_find|cln||Coord|dest|integer|cutoff|integer|maximum}}
|{{modarg|integer}}, {{modarg|Coord}} or {{modarg|boolean}}|{{moddef|list|path_next|cln}}
|{{modarg|Coord}}|{{moddef|list|flock_target|cln||integer|range|integer|mind|integer|maxd}}
|{{modarg|void}}|{{moddef|list|msg|cln||string|msg_player|string|msg_being}}
|{{modarg|Item}}|{{moddef|list|select_slot_by_letter|cln||string|letter}}
|{{modarg|void}}|{{moddef|list|phase|cln||CellID|[cell]}}
|{{modarg|void}}|{{moddef|list|spawn|cln||BeingID|monster}}
|{{modarg|boolean}}|{{moddef|list|act|cln||Coord|coord}}
|{{modarg|boolean}}|{{moddef|list|eye_contact|cln||Coord|other}}
|{{modarg|boolean}}|{{moddef|list|eye_contact|cln||Thing|other}}
|{{modarg|boolean}}|{{moddef|list|in_sight|cln||Coord|other}}
|{{modarg|boolean}}|{{moddef|list|in_sight|cln||Thing|other}}
|{{modarg|boolean}}|{{moddef|list|is_player|cln}}
|{{modarg|integer}}|{{moddef|list|set_items|cln||SetID|set}}
|{{modarg|void}}|{{moddef|list|nuke|cln||integer|[time]}}
|{{modarg|Item}}, {{modarg|boolean}}|{{moddef|list|pick_mod_item|cln||string|modletter|integer|techbonus}}
|}}
|}

=== Being API Function Descriptions ===
;{{moddef|desc|new|dot|Being|BeingID|id}}
Creates a new being object from the specified blueprint.
:''id'': The ID of the being to create.
:'''Returns''': A reference to the new being object.
----
;{{moddef|desc|kill|cln||boolean|[overkill]}}
Kills the being.
:''overkill'': ''Optional.'' If ''True'', the being will be gibbed (extra blood, inventory will not drop, and a corpse will not be placed). If ''False'' the being will be killed normally. If omitted, the being will be killed normally.
----
;{{moddef|desc|ressurect|cln||integer|range}}
Resurrects the nearest eligble corpse in sight of the calling being. Handles all message output.
:''range'': The maximum distance (in terms of movement) that a corpse can be in order to be eligble for resurrection.
NOTE: The function name is a misspelling.
----
;{{moddef|desc|apply_damage|cln||integer|amount|BodyTarget|target|DamageType|[type]}}
Deals damage to the being.
:''amount'': The amount of damage the attack does. This is not necessarily the amount of HP the being will lose; the being's resistance and armor may apply against this value.
:''target'': One of TARGET_INTERNAL, TARGET_TORSO, or TARGET_FEET. TARGET_INTERNAL only uses the target's internal armor and resistances (equipment, for the most part, will be ignored). TARGET_TORSO uses the item in the armor slot to help reduce the damage, and TARGET_FEET uses the item in the boots slot to help reduce the damage.
:''DamageType'': ''Optional.'' One of the named constants starting with "DAMAGE_". Indicates the type of damage being dealt, which influences the properties and effects the damage has on the target. If omitted, DAMAGE_BULLET will be used.
----
;{{moddef|desc|get_name|cln||boolean|[known]|boolean|[capitalize]}}
Returns the name of the being, with the appropriate preposition.
:''known'': ''Optional.'' If ''true'', the being will not use an article (a, an, or the) when getting the name string. If ''false'', an article (a, an, or the) will be appended to the front of the name. If omitted, the default is to use an article. BF_UNIQUENAME determines when "the" is used instead of "a" or "an".
:''capitalize'': ''Optional.'' If ''true'', the name of the being will be capitalized. If ''false'', it will not be adjusted. If omitted, the default is to not adjust.
----
;{{moddef|desc|inv_items|cln|table}}
Gets an iterator over the items in the being's inventory.
:'''Returns''': A table containing references to each item in the being's inventory.
----
;{{moddef|desc|get_eq_item|cln|Item|EquipSlot|slot}}
Retrieves the item in the indicated equipment slot. Equivalent to "being.eq.''slotname''", where ''slotname'' is "weapon", "armor", "boots", or "prepared".
:''slot'': One of SLOT_WEAPON, SLOT_ARMOR, SLOT_BOOTS, or SLOT_PREPARED.
:'''Returns''': A reference to the item equipped in the indicated slot.
----
;{{moddef|desc|set_eq_item|cln||EquipSlot|slot|Item|item}}
Equips an item to the being. Equivalent to "being.eq.''slotname'' = ''item''", where slotname is "weapon", "armor", "boots", or "prepared".
:''slot'': One of SLOT_WEAPON, SLOT_ARMOR, SLOT_BOOTS, or SLOT_PREPARED.
:''item'': The item to equip to the slot. If there is a different item in the slot already, it will be destroyed. If nil, the equipped item is destroyed.
----
;{{moddef|desc|add_inv_item|cln||Item|item}}
Adds an item to the being's inventory.
:''item'': The item to add.
:'''Returns''': ''True'' if the item was added. ''False'' if the being's inventory is full.
----
;{{moddef|desc|play_sound|cln||SoundID|sound}}
Plays a sound at the being's location.
:''sound'': The sound to play.
----
;{{moddef|desc|get_total_resistance|cln|integer|ResistType|resist|BodyTarget|[target]}}
Gets the total resistance for being, given the resistance type and target.
:''resist'': The resistance to get the value for.
:''target'': ''Optional.'' One of TARGET_INTERNAL, TARGET_TORSO, or TARGET_FEET. TARGET_INTERNAL only uses the target's internal resistance (equipment, for the most part, will be ignored). TARGET_TORSO uses the item in the armor slot to calculate resistance, and TARGET_FEET uses the item in the boots slot to calculate resistance. If omitted, TARGET_TORSO is used.
----
;{{moddef|desc|quick_swap|cln|boolean}}
Switches the weapon in the "weapon" slot with the one in the "prepared" slot. Expends energy on success.
:'''Returns''': ''True'' if the swap worked. ''False'' if it failed.
----
;{{moddef|desc|pickup|cln|boolean}}
Attempts to pickup the item at the being's current location. Expends energy on success.
:'''Returns''': ''True'' if the pickup succeeded, ''False'' if it failed.
----
;{{moddef|desc|unload|cln|boolean|Item|item}}
Attempts to unload the indicated item. Expends energy on success.
:''item'': The item to try to unload.
:'''Returns''': ''True'' if the unloading succeeded, ''False'' if it failed.
----
;{{moddef|desc|drop|cln|boolean|Item|item}}
Attempts to drop an item. Expends energy on success.
:''item'': The item to try to drop.
:'''Returns''': ''True'' if the drop succeeded, ''False'' if it failed.
----
;{{moddef|desc|use|cln|boolean|Item|item}}
Attempts to use an item. Expends energy on success.
:''item'': The item to try to use.
:'''Returns''': ''True'' if the use succeeded. ''False'' if it failed.
----
;{{moddef|desc|wear|cln|boolean|Item|item}}
Attempts to equip an item. Expends energy on success.
:''item'': The item to try to wear.
:'''Returns''': ''True'' if the item was worn. ''False'' if the command failed.
----
;{{moddef|desc|attack|cln|boolean|Being|target}}
;{{moddef|desc|attack|cln|boolean|Coord|target}}
Attempts to attack something. Expends energy on success.
:''target'': A being or a location to attack.
:'''Returns''': ''True'' if the attack was attempted. ''False'' if the being couldn't attack.
----
;{{moddef|desc|fire|cln|boolean|Coord|target|Item|weapon}}
Attempts to fire a weapon at something. Expends energy on success.
:''target'': The location to fire at.
:''weapon'': The item to fire at the location with.
:'''Returns''': ''True'' if the weapon was fired. ''False'' if it failed.
----
;{{moddef|desc|alt_fire|cln|boolean|Coord|target|Item|weapon}}
Attempts to fire a weapon using its alternate fire mode.
:''target'': The location to fire at.
:''weapon'': The item to fire at the location with.
:'''Returns''': ''True'' if the weapon was fired. ''False'' if it failed.
----
;{{moddef|desc|reload|cln|boolean}}
Attempts to reload the equipped weapon.
:'''Returns''': ''True'' if the weapon was loaded with at least 1 ammo. ''False'' if the weapon didn't get any ammo put in it at all.
----
;{{moddef|desc|alt_reload|cln|boolean}}
Attemptes to reload the equipped weapon using its alternate reload.
:'''Returns''': ''True'' if the weapon was loaded with at least 1 ammo. ''False'' if the weapon didn't get any ammo put in it at all.
----
;{{moddef|desc|direct_seek|cln|integer, Coord|Coord|dest}}
Attempts to move directly toward a location. Expends energy only on a successful move. The being will try moving around objects in its way. It will only move at most 1 space for each time this is called.
:''dest'': The location to attempt to move toward.
:'''Returns''': An integer, representing the result of the move, and a Coord, holding the previous location of the being. The integer can be 0 (MOVEOK), 1 (MOVEBLOCK), 2 (MOVEDOOR), or 3 (MOVEBEING). 0 means the move was successful, and energy was expended. 1 means there was a wall in the way. 2 means there was door or other CF_OPENABLE cell in the way. 3 means a being was in the way.
----
;{{moddef|desc|relocate|cln||Coord|dest}}
Moves the being to the indicated location, with animations.
:''dest'': The location to move the being to.
----
;{{moddef|desc|path_find|cln|boolean|Coord|dest|integer|cutoff|integer|maximum}}
Search for a path to the indicated location. Pathfinding is a time intensive procedure, use conservatively.
:''dest'': The location to find a path to.
:''cutoff'': A path finding parameter. The search is aborted if this number of positions are checked without getting closer to the target destination. DRL uses 10 for normal enemies and 40 for bosses. Larger values may cause the algorithm to take longer.
:''maximum'': A path finding parameter. The search is aborted if this number of positions are checked without reaching the target. DRL uses 40 for normal enemies and 200 for bosses. Larger values may cause the algorithm to take longer.
:'''Returns''': ''True'' if a path was found, ''False'' if not.
----
;{{moddef|desc|path_next|cln|integer, Coord}} or '''boolean'''
Moves the being to the next space on the found path.
:'''Returns''': If there is a valid path, an integer, representing the result of the move, and a Coord, holding the previous location of the being, are returned. The integer can be 0 (MOVEOK), 1 (MOVEBLOCK), 2 (MOVEDOOR), or 3 (MOVEBEING). 0 means the move was successful, and energy was expended. 1 means there was a wall in the way. 2 means there was door or other CF_OPENABLE cell in the way. 3 means a being was in the way. If there was no valid path to move along, the boolean value ''False'' is returned instead.
----
;{{moddef|desc|flock_target|cln|Coord|integer|range|integer|mind|integer|maxd}}
Assigns a coord based on other beings of the same type.
:''range'': The distance to check.
:''mind'': Matching beings will try to keep this much distance between them.
:''maxd'': Matching beings will try to be at least this close to each other.
:'''Returns''': A coordinate. If the beings are ''mind'' away or closer, the coordinate will be away from the closest matching being. If the beings are ''maxd'' away or farther, the coordinate will be the location of the closest being. Otherwise, the coordinate is a random position within ''range''.
----
;{{moddef|desc|msg|cln||string|msg_player|string|msg_being}}
Prints a message depending on the status of the subject of the message.
:''msg_player'': ''Optional.'' If the calling being is the player, this message will be printed. If omitted, no message is printed if called by the player.
:''msg_being'': ''Optional.'' If the calling being is not the player, but is in the player's vision, this message will be printed. If omitted, no message is printed if called by a visible non-player being.
----
;{{moddef|desc|select_slot_by_letter|cln|Item|string|letter}}
Gets the slot based on the character entered.
:''letter'': A single character string.
:'''Returns''': If letter is "a", the item in the armor slot is returned. If letter is "b", the item in the boots slot is returned. If letter is "w", the item in the weapon slot is returned. If letter is "p", the item in the prepared slot is returned. Otherwise, nil is returned.
----
;{{moddef|desc|phase|cln||CellID|[cell]}}
Teleports the being to a new cell.
:''cell'': ''Optional.'' A cell id to search for. If multiple cells of that id are on the level, one is picked at random. If omitted, any cell empty of beings, items, stairs, walls, hazardous terrain, or LFNOSPAWN can be selected.
----
;{{moddef|desc|spawn|cln||BeingID|monster}}
Summons monsters around this being. Monsters summoned this way grant no experience to the player (that is, BF_NOEXP is set on the spawned beings).
:''monster'': The ID of the being to spawn.
----
;{{moddef|desc|act|cln|boolean|Coord|coord}}
Makes the being interact with the indicated location.
:''coord'': The location to interact with.
:'''Returns''': ''True'' if the action was successful, ''False'' if not.
----
;{{moddef|desc|eye_contact|cln|boolean|Coord|other}}
;{{moddef|desc|eye_contact|cln|boolean|Thing|other}}
Checks if something is visible from this being's location.
:''other'': A Coord, Being, or Item whose position will be checked.
:'''Returns''': ''True'' if the being can see the checked object or location, ''False'' if not.
----
;{{moddef|desc|in_sight|cln|boolean|Coord|other}}
;{{moddef|desc|in_sight|cln|boolean|Thing|other}}
Checks to see if something can be from the being's location. If the being is the player, the player's vision algorithm is used. Otherwise, the being's eye_contact algorithm is used.
:''other'': A Coord, Being, or Item whose position will be checked.
:'''Returns''': ''True'' if the object is visible, ''False'' if not.
----
;{{moddef|desc|is_player|cln|boolean}}
Returns whether this being is the player or not.
:'''Returns''': ''True'' if this being is the player. ''False'' if it is not.
----
;{{moddef|desc|set_items|cln|integer|SetID|set}}
Gets the number of items worn by the being that are part of a set.
:''set'': The set to check.
:'''Returns''': The number of items of that set worn by this being.
----
;{{moddef|desc|nuke|cln||integer|[time]}}
Creates a nuke under the being and sets the nuke timer.
:''time'': ''Optional.'' The number of game turns the the nuke will go off in. If omitted, the default is 1.
----
;{{moddef|desc|pick_mod_item|cln|Item, boolean|string|modletter|integer|techbonus}}
Performs the choice, check, and attachment of a mod to an item. Only the player can call this function.
:''modletter'': The letter representing the mod being attached. Standard DRL mod letters are:
Agility: A Tech: T Bulk: B Power: P
Sniper: S Firestorm: F Nano: N Onyx: O
Custom modpacks should use different letters.
:''techbonus'': The number of points of tech bonus the being has. DRL uses the Whizkid level for this number.
:'''Returns''': An Item and a boolean. The Item returned is the resulting item after being modded with the mod pack, unless an assembly (mod array) was matched and accepted. The boolean value is ''True'' if the modding was successful or ''False'' if it was not. If the boolean value is ''False'' or the Item was turned into an assembly, Nil is returned instead of the item.
----

Modding:Documentation

2025-08-11T12:37:04Z

Epyon:

Players are allowed to load custom game content into the DRL engine using the Custom Game menu option. These packages (called modules, mods, or wads) of new content are created by various members of the DRL community; look for modules on the [http://forum.chaosforge.org/index.php/board,22.0.html modding forum].

== Getting Started ==
As of right now the best place to learn about modding DRL is to view the source code of current mods and, if you can't find what you need there, to ask for advice on the Chaosforge IRC channel, #chaosforge. Mods and their sources can be found in the modding section of the Chaosforge forums. IRC, if you are not familiar with it already, can be accessed quickly by using a free web based IRC client like the one found [http://en.irc2go.com/webchat/?net=QuakeNet&room=Chaosforge here]. Unfortunately BOTH sources are filled with obsolete information, as is this wiki. It will get better over time.

Although currently very out of date there is a [[Modding:Tutorial|series of tutorials]] in place to help with some of the basics of modding (as well as some advanced tricks for more experienced modders). It is suggested that you read through these if you want to understand most of the documentation. If you want to learn only enough to build a quick map, head to the tutorial [[Modding:Tutorial/Constructing a Map|Constructing a Map]] for guidelines and an example.

If you're just here to figure out how to play modules, it is a very simple process:

*Download either a folder with the .module extension (this is a "raw" module) or a file with the .WAD extension.
*Place the folder or file into your "modules" directory, located in your DRL folder.
*Start DRL, then select the "Custom Game" option.
*Select from any of the modules in the menu, at which point the normal game startup procedure will begin.

== Documentation ==
This section is documents the DRL modding system including the various objects and libraries available to modders.

==== Modules ====

* [[Modding:Module|Module]]

==== Base Object ====

* [[Modding:Thing|Thing]]

==== Main Objects ====

* [[Modding:Item|Items]]
* [[Modding:Missile|Missiles]]
* [[Modding:Cell|Cells]]
* [[Modding:being|Beings]] ([[Modding:being blueprint|b]] [[Modding:being API|a]] [[Modding:being object|o]])
* [[Modding:player|Player]] ([[Modding:player API|a]] [[Modding:player object|o]])
* [[Modding:level|Levels]] ([[Modding:level blueprint|b]] [[Modding:level API|a]] [[Modding:level object|o]])

==== Secondary Objects ====

* [[Modding:ItemSet|Item Sets]]
* [[Modding:ModArray|Assemblies]]
* [[Modding:Affects|Affects]]
* [[Modding:Generator|Generator]]
* [[Modding:Coord|Coordinates]]
* [[Modding:Area|Areas]]
* [[Modding:AI|AI]]
* [[Modding:UI|User Interface]]
* [[Modding:Command|Commands]]

==== Other ====

* [[Modding:Core|Core]]
* [[Modding:Functions|Functions]]
* [[Modding:Kills|Kills]]
* [[Modding:Statistics|Statistics]]
* [[Modding:Badge|Badges]]
* [[Modding:Medal|Medals]]
* [[Modding:Traits|Traits]]
* [[Modding:Challenges|Challenges]]
* [[Modding:RankExp|Experience Ranks]]
* [[Modding:RankSkill|Skill Ranks]]

==== Constants ====

* [[Modding:Constants|Constants]]
* [[Modding:Constants#Flags|Flags]]
* [[Modding:sID|Object IDs]]

High power pistol

2025-08-11T12:36:46Z

Epyon:

{{infostrat switch}}
{{ranged weapon|
weapon_name=High power pistol - [[Pistol_Types|Pistol Family]]|
weapon_dmg= 2d6 / 2-12|
weapon_avgdmg= 7 |
weapon_dmgtype=Bullet|
weapon_accuracy=+4|
weapon_ftime=1.0 second|
weapon_rtime=1.2 seconds|
weapon_clip=4|
weapon_ammo=10mm ammo|
weapon_afire=Aimed shot|
weapon_areload=Dual reload|
weapon_get=[[Assemblies|Assembly]]: Pistol + PB|
weapon_quote=N/A|
weapon_looks=}|
weapon_description=Assembly (same as original)|
weapon_other=N/A|
weapon_source= [http://en.wikipedia.org/wiki/Browning_Hi-Power Real life] (Interestingly enough, in real life, high power was referring to the larger magazine round capacity of 13 shots, as opposed to higher damage as in DRL!)|}}

Modding:Medal

2025-08-11T12:36:16Z

Epyon:

Medals are [[achievements]] that are received, at most, once per game. As game objects, they are as functional as you require them to be.

== Prototype ==
As with all DRL lua objects, medals can be defined in any way at all. The following keys are used in DRL's base wad file:

{|class="wikitable" style="border: 2px solid darkred; border-spacing: 0; font-size: 90%; margin: 0.25em 0.5em;"
! colspan="3" style="background: darkred; color: yellow; font-size: 120%; text-align: center"|'''Medal Prototype'''
{{Table3Col
|es=background: #333;
|c1=font-weight:bold; text-align:right; vertical-align:top; padding:0px 2px;
|c2=vertical-align:top; padding:0px 2px;
|c3=padding:0px 2px;
|'''string'''|id|This is the medal's sid. It must be distinct from other string ids.
|'''string'''|name|This is the medal as it appears on the mortem and player info screens.
|'''string'''|desc|This is a description of the medal as it appears on the player info screen.
|'''boolean'''|hidden|This determines whether or not the medal is visible on the player info screen before the player has been given the medal.
|'''function'''|condition|This is a function that is used to set up the requirements for the medal. It usually looks at [[Modding:Statistics|statistics]] accrued throughout the game.
|'''boolean'''|winnoly|This determines if the medal is only received if the player wins the game. This is only necessary if the medal has been assigned a condition key.
|'''list'''|removes|This is a list of medal ids. Any medals added to this list will not be gained if this medal has been given. This is only necessary if the medal has been assigned a condition key.
|}}
|}

Strategy:Shottyman

2025-08-11T12:36:10Z

Epyon:

__NOTOC__
{{infostrat switch}}
== Main Guide (v0.9.9.4) ==

=== Version Changes (v0.9.9.5) ===
Nothing significant to the trait itself.

=== General Tactics ===
Basic strategy posted by [[User:theduck101|theduck101]] 18:12, 26 November 2011 (CEST)

[[Traits#Shottyman|Shottyman]] is an advanced trait, allowing you to reload your equipped shotgun automatically with every move you make. To access it you need to take two levels of [[Traits#Reloader|Reloader]].

Obviously Shottyman is a shotgun specialist trait. It ameliorates the shotgun's biggest weakness: the need to reload after every shot. If you plan to centre your game around shotguns or are playing as an Angel of Shotgunnery then this is a very important trait.

The first thing with Shottyman is to get out of the habit of reflexively hitting the 'r' key after every shotgun round. Instead, to get the most of Shottyman you should learn to use the reload provided by movement.

Fire and motion is the path to Shottyman success. The tactical advantage of moving and reloading at once is that it gives you the chance to dodge in the middle of combat and return fire the next move. Knowing how to [[Dodging|dodge]] effectively is therefore critical. A good habit to get into is to use diagonal movement (pgup, pgdown, home and end keys) as your default. I won't go into the details (see [[Dodging]] for the full rundown) but the most important idea is this: never move parallel to the firing line of your enemy i.e:

<pre>
XXX
O************@
XXX
</pre>

Moving to one of the squares marked with an X will give a chance to dodge the cacodemon's next shot.

With Shottyman, you'll reload pretty fast (two levels of Reloader will have you reloading a normal shotgun in about 0.6s). This makes corner shooting more effective as you can fire more shots than normal before an enemy can close in. This combined with the reload and move mechanic of Shottyman gives you a nice set of options: you can reload and fire at a sergeant before he has time to fire or you can move between the sergeant and another enemy to take advantage of a little friendly fire killing the sergeant on the next move.

For a nice increase to your damage output move in such a way that the knockback caused by your shot will push an enemy into a pool of acid/lava. This can be especially important in later levels because it will destroy the enemy corpse's making Arch-viles a little easier to deal with.

Reducing your move time through things like tactical boots/armour greatly increases the efficacy of Shottyman. The faster you move the more shots you can fire and the quicker you can get to cover.

Also remember to use a shotguns area of effect when targeting. Instead of aiming for a single enemy fire in the approximate midpoint of a group of enemies (as long as they are far away enough to be in the cone of spread). This deals damage to all of them at once. Manoeuvre in such a way that you deal damage to the maximum number of enemies for each round fired.

The damage drop off for shotguns makes taking down opponents with a lot of hit-points difficult. Sometimes you'll have the ammunition to spare to keep firing into the distance. Other times a dangerous enemy will need to be killed quickly. To maximise damage you need to get in close: within about 5 squares of your target. This is especially true for the hard hitting but range impaired double shotgun. The problem is that the closer you get to an enemy the greater their chance to hit you and the lower your chance to dodge.

There are a few ways to get around this. One is to use a combat or tactical shotgun; the damage drop off is such that 9 squares of range will still give you some bang for your, umm, buck. Otherwise you need to run.

Running is an indispensable tactic with Shottyman. It gives you 29 moves of faster movement, increased dodging ability and reduced enemy accuracy. Even better, the downside of running, -2 accuracy, doesn't matter at all to a shotgun player since shotguns never miss. Running is therefore your Shottyman turbo mode. Medpacks and Health, Berserk, Invulnerability, Supercharge and Mega powerups all restore fatigue: think of each one of these not only as source of healing but also as 'turbo boost' for each use.

Running allows you to charge dangerous enemies and dodge a greater percentage of their attacks. The 20% dodging bonus means you will still dodge effectively even if you're close and if you get in close you can take them out quickly. It also allows you a chance to get '''out''' of dangerous situations if you need to. Running separates the good DRL players from the rest - use it and use it well.

The move-and-reload ability of Shottyman is especially suited to powerful shotguns that take a long time to reload. The Double Shotgun (which is the arena prize if you're playing as an Angel of Shotgunnery) becomes a lot more useful when you don't have to worry about the 2s reload time.

Special mention should go to the [[Elephant gun]]. The elephant gun packs a punch (50% more damage than a regular shotgun) but comes with an horrendous reload time (the same as a chaingun!). Shottyman turns this lumbering beast into, if not an agile predator, then at least a predator that doesn't stop in the middle of a hunt to contemplate the meaning of life. An added bonus is that it deals out enough damage to be useful over a distance even with a normal shotgun damage decay.

The Combat Shotgun and it's bigger brother the Tactical Shotgun with their bigger clips and range are also fine options. They are especially suited for tactical play e.g. firing round corners and radar shooting.

Modding:Tutorial/Building an Episode

2025-08-11T12:35:51Z

Epyon:

The simplest of modules are built upon a single map, a single level. While this can provide for some very unique and thrilling gameplay, it is not nearly on the same scale of DRL itself, which is a gauntlet of many levels, one after another. If you'd prefer to have a module with the structure of something longer and more challenging than a single level can produce, you're probably looking to create an episode. The purpose of this tutorial is to explain exactly how that is done.

In order to fully explore the possibilities of an episodic module, make sure you understand the basics of modding. If nothing else, take a look at the tutorial [[Modding:Tutorial/Constructing a Map|Constructing a Map]] before continuing on.

== Special Concept: Setting Levels ==
The player object comes with a custom property called "episode". This is what determines where the player will be when they reach a certain depth. In fact, this is the majority is what is necessary to string together all the levels in an episode. This is combined with an episodic engine hook known as OnCreateEpisode to build the episode's content. Here is a simple example:

<source lang="lua">
core.declare( "a_mod", {} ) --initialize the module object

function a_mod.OnCreateEpisode()
player.episode = {} --initialize/reset the table

--defines first floor as a special level
player.episode[1] = { style = 1, script = "hells_arena" }
--defines second floor as a random level
player.episode[2] = { style = 1, number = 1, name = "Floor", danger = 1}
end
</source>

The following would create an episode with two levels. The first level is defined by calling a level "script": the script used here is actually Hell's Arena from the base game. Because the map was initialized with the rest of the game (and this is not a total conversion module), it is included as part of the potential level scripts. So long as a level object has been created and initialized in your module, you are free to include any levels you want as well. (Although style does not have an effect on the level, it is necessary to include as a formality.)

The second level is defined through level properties, rather than calling a script. When this is done, the game can initialize a level with these properties but must still produce some sort of generated content. For this, we require the OnGenerate() hook:

<source lang="lua">
function a_mod.OnGenerate()
Generator.reset()
Generator.generate_caves_dungeon()
end
</source>

OnGenerate() controls the content of unscripted maps. This can be technically used to create an identical series of maps, but it is much more interesting to create maps using generator functions. Generator.reset() clears any leftover data in the generator, while Generator.generate_caves_dungeon() creates a random cave level ([[Level Type#Cave|of which you are probably familiar]]). The properties defined from OnCreateEpisode() will come into play for the purposes of determining things such as the walls, doors, floors, danger level, and so on. See [[Modding:Generator]] for a complete list of generator functions with which to play around.

Now that we understand the basics of producing an episodic module, let us discuss a simple example that emulates that of a very old version of the game: Classic Mode.

== Engine Hooks ==

=== .OnCreateEpisode() ===
<source lang="lua">
function classic.OnCreateEpisode()
local BOSS_LEVEL = 10
player.episode = {}

player.episode[1] = { style = 1, script = "intro" }
for i=2,BOSS_LEVEL-1 do
player.episode[i] = { style = 1, number = i, name = "Phobos", danger = i}
end
player.episode[10] = { style = 3, script = "phobos_arena" }

statistics.bonus_levels_count = 0
end
</source>
As before, we initialize the episode table. We've also defined the end level, coined ''BOSS_LEVEL'', as the tenth floor. The layout is fairly straightforward:

*The very first level takes place in Phobos Base Entry. This is indicated with the script "intro".
*Floors two through nine are set as randomly-generated levels. They will be named "Phobos 2", "Phobos 3", etc, and will have danger levels of the same number.
*The final level is a level script called "phobos_arena". Although this is not included in the base game, we'll be providing this script ourselves for the purpose of this episode.

Finally, as a matter of completeness, since there are technically no "special" levels in this episode, we set the bonus level count to zero from the statistics object. Special levels can actually be included as part of the level initialization by defining the ''special'' key: red stairs will be automatically provided on that level in addition to everything else. In either case, however, the statistics for bonus levels must be manually set.

=== .OnGenerate() ===
<source lang="lua">
function classic.OnGenerate()
Generator.reset()
Generator.generate_tiled_dungeon()
end
</source>
This function is almost identical to the one from the concepts example: the generator object is reset, and then a tiled dungeon is set for any and all unscripted (random) levels. The tiled dungeon is the de-facto level style found in DRL: it is the one that always appears on the second floor, regardless of the circumstances. Since this is a classic map, all of the levels are determined in this manner. You can, however, use some randomization within '''OnGenerate()''' to change which map is actually generated. The specifics of the randomization in the base game can be found in [[Level type]].

=== .OnMortemPrint() ===
<source lang="lua">
function classic.OnMortemPrint(killedby)
if killedby == "defeated the Mastermind" then
killedby = "defeated the Cyberdemon"
elseif killedby == nil then
killedby = "played through the classics"
end
player:mortem_print( " "..player.name..", level "..player.explevel.." "..klasses[player.klass].name..", "..killedby )
end
</source>
'''OnMortemPrint()''' is where all mortem-printing should be done, hence its name. It comes with the ''killedby'' parameter, which determines the status of the player at the time of the printing. Despite its name, ''killedby'' can produce a variety of messages, including those for winning the game. This mortem_print in particular is just like the one from the tutorial for [[Modding:Tutorial/Recreating Hell's Arena|Hell's Arena]], so it should be familiar enough to understsand already.

Of particular note is that we require a change in the victory condition: ''killedby'' returns that the Mastermind was defeated in a standard victory, so we change it to reflect that it was the Cyberdemon instead.

=== .OnWinGame() ===
<source lang="lua">
function classic.OnWinGame()
ui.plot_screen([[
Once you beat the Cyberdemon and clean out the moon
base you're supposed to win, aren't you? Aren't you?
Where's your fat reward and ticket back home? What
the hell is this? It's not supposed to end this way!

It stinks like rotten meat but it looks like the
lost Deimos base. Looks like you're stuck on
The Shores of Hell. And the only way out is through...
]])
end
</source>
The '''OnWinGame()''' hook allows you to play around with some of the user interface commands upon winning the game. If you recall beating the base game, it's what happens immediately after killing the Spider Mastermind, but before the mortem appears. Our use of the hook simply displays a single screen of plot with the '''ui.plot_screen()''' function, which accepts a single string. You can play around with some properties here but that's better saved for '''OnMortem()'''.

== Levels: Phobos Arena ==
<source lang="lua">
Levels("phobos_arena",{
name = "Phobos Arena",
entry = "Then at last he found the Phobos Arena!",
welcome = "You enter a big arena. There's blood everywhere. You hear heavy mechanical footsteps...",

Create = function ()
Level.fill("wall")
Level.fill("floor", area.FULL_SHRINKED )
local scatter_area = area.new( 5,3,68,15 )
local translation = {
['.'] = "blood",
['#'] = "gwall",
['>'] = "stairs",
}
Level.scatter_put(scatter_area,translation, [[
.....
.###.
.###.
.###.
.....
]],"floor",12)

Level.flags[ LF_NOHOMING ] = true
Level.scatter(area.FULL_SHRINKED,"floor","blood",100)
Generator.set_permanence( area.FULL )
player.flags[ BF_ENTERBOSS1 ] = true
end,

OnEnter = function ()
local boss = Level.summon("cyberdemon")
boss.flags[ BF_BOSS ] = true
end,

})
</source>
This is the level included with Classic Mode: the end-game level, Phobos Arena. This is, more or less, a replica of the original end-game level prior to version 0.9.9.5. Many of the things covered here have already been explained in the singular module tutorials, so they will not be described in detail here. This is a quick overview:

*We start with a wall-bordered blank room, randomly add 12 pillars away from the borders, then randomly populate the rest of the level with blood.
*Homing phase devices will fail to work here (though there are no stairs to phase to anyway).
*Everything in the level is made permanent so that no walls can be destroyed
*The player's flags are modified so that the game knows we are on a boss level.
*Finally, the Cyberdemon is spawned at a random coordinate and given the boss flag, so that killing it ends the game.

One thing not seen in previous tutorials, however, is the Level object itself. In a singular module, the level is created with the '''run()''' function: in an episodic module, levels are defined separately and called when necessary. The basic level structure is as follows:

*Levels are technically handled with functional syntax. The identifier is placed as the first argument in this function, and a table that defines the level's properties and hooks is given as the second argument.
*Typical level properties are:
**''name'' is what the level is called, as it appears at the bottom-right.
**''entry'' is what appears in the mortem, signifying that you entered the level.
**''welcome'' is what appears in the message log as you enter the level.
*Hooks are added to the level, just as they would be for a singular module. Of particular note is that the '''run()''' hook is replaced with '''Create()''': they are functionally identical, but use different names due to where they are called.

Within the module's source, this level is given its own file in a separate folder called "data". In order for the module to access the file, a function called '''require''' is used:
<source lang="lua">
require "classic:data/phobos_arena"
</source>
The module's name is written before the colon, and the path from the module's root folder is written after. '''require''' assumes a .lua extension, and few other files would be useful at this time.

== Review ==
Included is the main.lua, phobos_arena.lua, and the module.lua used to run the file:

{{:Modding:Tutorial/Building an Episode/Source}}

Source data: [http://dl.dropbox.com/u/54818507/classic.module.zip classic.module]

Dis

2025-08-11T12:35:42Z

Epyon:

{{infostrat switch}}
{{Special level|
level_name=Dis|
level_dlvl=24|
level_intxt=You enter the damned city of Dis...|
level_loottxt=Congratulations! You defeated the Spider Mastermind!|
level_outtxt=N/A|
level_itytd=[[Spider Mastermind]]|
level_hntr=No difference|
level_hmp=Do I need to go over this anymore?|
level_uv=Work it out, Einstein...|
level_n=Well YOU sure ain't a mastermind!|
level_loot=None|
level_other=This map consists of an arena as close to round as you can get in DRL, with some 4x4 pillars in a circle as cover.}}

Strategy:Red armor

2025-08-11T12:35:35Z

Epyon:

{{infostrat switch}}

==0.9.9.5==
Red [[Armor]] is probably the single most important item in the entire game. It's nearly impossible to get through the last third of the game without it. With [[Baron]]s, [[Arachnotron]]s, [[Revenant]]s, [[Mancubi]], and [[Arch-vile]]s all stalking you in those last levels, the 4 damage (or 8% health, on average) it saves per hit is the difference between life and death. Moreover, the built-in 25% [[fire]] [[resistance]] (best to be capitalized on) takes the bite out of the worst three enemies. When you add in [[mod]]s, you have one of the most powerful and versatile items in the game.

So what's the downside? -20% speed isn't fun. And the enemies you could use it against the most, Barons, wreck it the most as well. Ultimately, Red Armor is still only packing 4 protection; against Barons which can deal 20 in one hit--and because it's acid damage, armor damage is doubled--it's not pretty. Barons can reduce its durability by up to 32% in a single hit--more, if it's below 50%. The lesson: Always carry spare armor.

Every mod goes well with this item. An agility mod brings it up to a cool -5% speed. Power mod brings it to 6 protection. Bulk gives an extra 100%--perfect against Barons--but you'll be moving slowww at -30% speed. Still, it may be your best option if you can't find any spare Reds. Technical mod is the only one that's average.

But assemblies is where this armor really shines. Don't want to worry about carrying spares? [[Nanofiber]] it. If you find a unique mod pack, even better--[[Plate armor|+8]], [[Power armor|nearly indestructible]] protection, anyone? Of course, the best assembly of all is one of the easiest--[[fireproof armor]]. This stacks onto the native 25% fire resistance to create a 4/4, 55% fire-resisting beast of a machine. Since the triple threat of Revenant, Mancubus, and Vile (not to mention the Cyberdemon) all use fire-based attacks, this is the best armor to have in the last third of the game. It's actually more effective than 6/6 armor! (i.e., regular power-modded red armor.) I've even heard rumors of a legendary "cerebus armor", but I'm afraid I haven't found the schematics for that one yet...

There's nothing better than red armor. Even exotics and uniques rarely beat its combination of high protection and fire resistance. It's flaws are easily negotiable as well. If speed is your issue, slap an agility mod on it. Against Barons, always carry a spare red. (Or two.) Even better, keep a dusty blue armor around for those fights...if it gets destroyed, who cares? With Red Armor, the drlguy truly has a marine's best friend at his side. (Literally.) [[User:GrimmC|GrimmC]] 00:25, 7 January 2012 (CET)

==0.9.9.6==
[[Powered Red armor]], [[Nanofiber armor]], and many other assemblies have different stats and effects than before. Additionally, the [[Plate armor]] assembly no longer exists, having been replaced by the [[Tower shield]] assembly.

==0.9.9.7==
The above guide is solid but outdated and doesn't go in depth on how the assemblies work for the Red armor, so here is a more up-to-date guide.

At base, the Red armor is still the same as it is in prior versions. 4 protection and 25% fire resistance is solid on its own as covered prior, significantly nerfing weak-to-moderate hits and giving you adequate protection against strong fire hits from the VMR (for example, it'll reduce an Arch-Vile's zap from a crushing 20 damage down to a nearly manageable 11 damage). With just a power mod and agility mod, you can get yourself an armor with 6 protection, 25% fire resistance, and only a -5% movement penalty, which is better than what many [[exotic]] and [[unique]] armors have. Such an armor would make a decent recipient of an [[onyx mod]] if you don't got one of the better exotic or assembled armors available, it's hard to do better than an APO Red armor without getting lucky with finding one of the good exotic armors. Getting a -10% movement penalty tacked on for applying a bulk mod stings and so you probably don't want to apply it to your primary Red armor if you're not playing a build that relies heavily on tanking hits, but applying it to a spare Red armor if you haven't found an onyx mod is a good idea, as Red armor with 200% durability will last a long time and is nice to have when dealing with those dastardly armor-destroying Barons.

As for assemblies, Red armor can be used for a whopping nine of them, which will be covered now (with the required mods being in parentheses):

*[[Fireproof armor]] (BT) - This assembly adds 30% fire resistance, in exchange for -30% melee resistance. Fireproof Red armor is one of the staple assemblies of DRL, that most players will swear by making ASAP, as getting 4 protection armor with 55% fire resistance is huge for nerfing the ever imposing threat of the VMR; with it you will reduce the Arch-vile's zap from 20 damage all the way down to 5 damage, letting a [[Scout]]/[[Technician]] with base HP take up up to 10 hits before dying instead of just 3, while a [[Marine]] can take up to 12 hits. Having this armor is great assurance when fighting these enemies that can normally wipe out a third or more of your health in one hit, no more will you have to worry about a Mancubus suddenly killing you because you stepped into one's sight. It severely nerfs the Cyberdemon's rockets too, with them averaging 5 or less damage per hit, and rarely being able to deal more than 10 damage against this armor, very helpful for builds that don't have [[Strategy:Dodgemaster|Dodgemaster]] nor are running [[Strategy:Berserker|Berserker]]. Not to mention it's also great for [[rocket jump]]ing, reducing the self harm from rocket jumps down to 1-3 damage without any reduction in knockback. The cheap mod cost and a guaranteed Red armor at [[Phobos Anomaly]] coming right when VMR are about to start showing up on UV difficulty makes this an imperative assembly to build. The -30% melee resistance is an unfortunate downside, which will hurt if you get hit by stronger melee enemies like Barons, but considering how much more dangerous those fire attacks are, it's certainly a well-worth tradeoff for most builds. Melee builds are the primary ones who won't want to make this assembly; aside from the obvious reason that they will actively get in melee range of enemies, the +60% resistances from [[berserk]] and VMR being great triggers for Berserker means they'll suffice enough with normal modded Red armor, or in the case of [[Strategy:Malicious Blades|Malicious Blades]], that master gives them +50% fire resistance at all times as long as they got a blade in their prepared slot, so normal-modded Red armor is pretty much always better for them (either with berserk or Malicious Blades, a base Red armor will reduce an Arch-vile's zap to ''1 damage'').

*[[Ballistic armor]] (AT) - This is essentially the reverse of Fireproof armor, with this assembly adding 30% melee resistance to any armor (in addition to +30% bullet and shrapnel resistance) while subtracting -30% fire resistance. Given how much the importance of fire resistance was stressed just above, you can obviously figure this assembly is often not worth using on Red armor, and if you do desire a very strong melee armor (such as for trying to beat the [[Unholy Cathedral]] without having [[Strategy:Brute|Brute]] investment, or when you're going to be taking a huge amount of melee damage throughout the game from going for something like the Strongman [[badges]]), the [[Duelist armor]], [[Ballistic armor]], or even the [[Medical armor]] would be better choices with their already built-in melee resistance this assembly will compound on. That said, if you cannot find any of those armors and do really need something better than a P-modded Red armor for melee, using Red armor for this assembly would do you better than the other standard armors, as that 4 protection will see substantial mileage on top of the resistance, and since it'll only go down to -5% fire resistance after the assembly, you won't get instantly vaporized if you get caught by the VMR in Ballistic Red armor.

*[[Nanofiber armor]] (BP) - This assembly gives any armor it's applied to infinite durability, in exchange for cutting its protection and all its resistance in half. Having infinite durability on your armor is very nice, but that's a very steep cost to pay that is usually not worth it; on Red armor you would get an armor with 2 protection and 12% fire resistance, a pitiful amount that will barely make a dent against surviving VMR attacks (it would reduce an Arch-vile zap from 20 damage down to 16, meaning you'll barely survive only one more hit from them than usual), while you'll still have that stiff -20% movement penalty. The main appeal of the assembly is insuring you'll always have a spare armor no matter what, regardless of how badly you get beaten up and how badly the RNG decides to deprive you of [[armor shard]]s to repair your armor. Generally though, bulk mods on your spare armors should be enough to get you through when your frontline armor gets damaged, and if you're getting hit so much that even B-modded Red armors can't last, you should be reevaluating your tactics as you are probably going to die if you're taking that much damage in Nanofiber armor. If you haven't found an onyx mod though and really want infinite durability armor above all else, Red armor is one of the best bases for this assembly and better than the other standard armors. It should be stated this assembly is situationally a lot more useful in [[Strategy:Angel of Purity|Angel of Purity]], where the restriction on powerups makes you unable to restore your armor through armor shards and [[Megasphere]]s, or for any run where tanking an extreme amount of damage is unavoidable, such as again with runs for the aforementioned Strongman badges. Even in these cases, you should still hold off on Nanofibering your first Red armor until at least after [[Hell's Armory]]/[[Deimos Lab]], where you'll have a good chance to get an onyx or [[nano mod]] that will completely obsolete the need for any Nanofiber armor.

*[[Fireshield]] (BTO) - An assembly that only the Red armor can be used for, which is an extreme take on the aforementioned Fireproof armor; in exchange for the same ingredients plus an Onyx mod, you'll get an armor with the same 4 protection and -20% movement speed as Red armor, but with '''''95% fire resistance'''''. This armor will reduce every single fire attack in the game down to 1 damage no matter how strong it is, the only fire protection better than this is the complete fire immunity from the Inquisitor Set (which considering how rare just finding one of [[Malek's Armor]] or [[Nyarlaptotep's Boots]] is, let alone both together in anything other than in an [[Strategy:Archangel of 666|Archangel of 666]] run, the Fireshield will be the more realistically obtainable best defense against fire). This sounds like a no-brainer assembly, but with it requiring an onyx mod and not having infinite durability, there is a huge opportunity cost to it. Furthermore, this armor is a shield, which means it cannot be repaired without a Megasphere, that you might go an entire game without ever finding one of. With 200% durability it can last a while, especially if you are only taking VMR attacks in it that will only ever deal 1 damage, but if other enemies start hitting it, especially Barons, you'll find this armor you spent your onyx mod gone before you know it. You'll be better off just using the onyx mod normally on Red armor, or if you want strong fire protection that lasts forever, make a Fireproof Red armor after getting Whizkid 2 and then applying the onyx mod to it; it would require the same ingredients as the Fireshield and you'll already need Whizkid to make a Fireshield. You should only consider this assembly if you find an onyx mod late in the game after having exhausted the modding slots of your main armors and have no other good use for it, while being late in the game also means it'll much more likely last the rest of the way regardless of Megasphere luck.

*[[Tower shield]] (PO) - Another assembly that only the Red armor can be used for, which gets you an armor with a massive 12 protection, the highest protection value any armor can get outside of a P-modded Cybernano [[Cybernetic Armor]] (which only Technicians can even make), and the [[Berserker Armor]] when you're at low HP. It has a massive -50% movement penalty however, and -90% knockback, so you'll really struggle to move at all in this armor. It additionally has no resistances, and so it won't protect as well from strong hits as you would expect; the Arch-vile zap we been using as a benchmark throughout this will deal 8 damage to you in this armor, a big reduction from its 20 damage but still quite worse than what simple Fireproof Red armor achieves, and barely better than P-modded Red armor. Worst of all however, like the aforementioned Fireshield, this requires an onyx mod, and it is a shield, so it can't be repaired without Megaspheres. The 150% durability is decent, but this will not last long if you try to make any active use of this armor, especially when the slowness of the armor will force you to take hits you wouldn't have otherwise. Like with the Fireshield, only consider this assembly if you find an onyx mod late and have no good armor to use it on.

*[[Power armor]] (PN) - An assembly that can only be used by the standard armors, which includes Red armor. This assembly adds a point of protection, doubles the armor's base resistances, adds +25% melee resistance, removes the movement penalty altogether (in effect being +20% movement speed for Red armor), and has regenerating durability. Red armor is unequivocally the best base of the standard armors for this assembly, as you'll get 5 protection and a very valuable 50% fire resistance, on top of the other benefits mentioned. Powered Red armor effectively fuses the fire defense of Fireproof Red armor with the melee defense of Ballistic Red armor, while also completely addressing the Red armor's movement weakness; combined with the regenerating durability, this is very good armor that you can possibly subsist solely on for the entire game. The only drawback is the -25% knockback penalty, which will nerf rocket jumping, while this armor's great fire resistance and regenerating durability makes it ideal rocket jumping armor otherwise. However, this assembly does require a coveted nano mod, which will often be better used on [[Nanomanufacture ammo]], [[Nano-shrapnel]], or [[Antigrav boots]]; the former two assemblies allow you to create some gamebreaking weapons, while Antigrav boots give you some gamebreaking movement speed. As good as Powered Red armor is, it's not a game-changer in the ways those other nano assemblies are, and so often it's not advised to be your first or second or maybe not even your third choice to use a nano mod on. The main exception would be if you're playing a build that can't or isn't getting Whizkid, or is not getting Whizkid until late into the game; in the former case, a single nano mod on a weapon is likely not doing much except for maybe a [[Plasma rifle]] or [[BFG 9000]], and in the latter case, you may not even survive long enough to get Whizkid to build those other nano assemblies (while there's also the argument of getting more immediate use from Powered Red armor for many floors rather than not getting anything from the nano mod but clogging inventory until those final few floors).

*[[Nanofiber skin armor]] (PPN) - An assembly that can be applied to any armor, which adds +25% resistance to all damage types on top of the armor's base resistances, in addition to regenerating durability and being indestructible, but you'll never be able to remove the armor for the rest of the run. Applying this assembly to Red armor will get you regenerating armor that protects nearly as well against fire attacks as Fireproof Red armor, while giving you some much needed resistance against Barons' acid balls and the hard-to-protect against plasma enemies. However, aside from what was said above about using a nano mod for armor, the caveat of not being able to ever remove this armor is a huge caveat; you'll be committed to this armor for the rest of this run, and if you're in a situation where it's not up to snuff, then you're screwed. As is, Nanofiber skin Red armor is certainly good armor, but not so much to be comfortable to be stuck with it; 25% resistance with 4 protection against acid and plasma attacks isn't all that much (Baron balls will still be averaging at least 5 damage and can do up to 11, Arachnotrons can still do more than 1 damage per plasma bolt with max damage rolls, which adds up quick with their rapid-fire volleys, and stronger plasma enemies are still hurting you), and you'll still have the Red armor's -20% movement speed. If you want to commit to this assembly, the [[Energy-shielded vest]], [[Phaseshift armor]], [[Cybernetic Armor]] (if you're a Technician), or even the [[Duelist armor]] are better, and if you don't have those, you would still be better off with Powered Red armor; it doesn't give you that bit of extra protection against acid and plasma, but it's much faster with no movement penalty, and you'll still have the option to remove it for other armor, such as one with actual good resistance against those acid and plasma enemies.

*[[Cybernano armor]] (PPNO) - An assembly that can be applied to any armor, which gives it +4 protection, in addition to infinite durability, but you'll never be able to remove the armor for the rest of the run. The +4 protection is big, double what you can get from a power mod, and you'll still have the option to add one more mod after, whether another power mod to go +6 on protection, or an agility mod to make you faster. This armor is similar to Nanofiber skin armor in the amount of extra defense you get (with Cybernano Red armor being slightly better against hits that deal less than 14 damage, while Nanofiber skin Red armor is slightly better against hits that deal more than 17 damage, and against plasma damage those values are instead 6 and 9 damage respectively), with the perk of infinite durability meaning you won't need to worry about a sudden big beating temporarily damaging your armor. However, it still has all the same problems; using a nano mod for armor is a big opportunity cost, this assembly is a huge commitment, and the Red armor is not an ideal base to be hitching your entire run on this assembly with. Additionally, the Powered Red armor is still better if you want to use your nano mod on armor and you haven't found a better exotic armor to use as a base, as the effective +20% movement speed, protecting better against fire attacks, and the ability to swap it out for other armor is better than 3 more protection points (not to mention that you would then be free to use the onyx mod elsewhere if you actually managed to get both it and a nano mod in the same run).

*[[Cerberus armor]] (PPTA) - An assembly that can be applied to any armor, which regardless of what base you use, results in an armor with 0 protection, -30% movement speed, and -30% knockback, but has an astounding 70% resistance to fire and acid attacks, a great 50% resistance against plasma attacks, and will inherent its physical resistances and durability from the base armor. Now Cerberus armor is very good, with the right assembly base you can potentially get yourself an armor with 50% resistance or more against every damage type in the game, but Red armor is among the worst bases for it; with Red armor having no resistance against any physical damage, using it will net you a baseline Cerberus armor that will leave you effectively naked in melee and against formers, while it has no durability perks like the [[Onyx armor]] netting you infinite durability Cerberus armor without the need for an onyx mod. Even [[Green armor]] would be a better base, as it does have something extra to give the Cerberus armor at least with its meager 15% resistance to bullet and shrapnel. You should hold off on assembling Cerberus armor until you get one of the good exotic armors for it, but baseline Cerberus armor is still pretty good (protecting you nearly as well against fire attacks as Fireproof Red armor, while protecting you much better against Barons and plasma enemies), and so if you cannot find any of the good exotic armors for it, using a Red armor for the base will still be acceptable.

Overall, the Red armor tends to be a good choice for the basic armor assemblies, particularly Fireproof Red armor, but for the more intricate assemblies it can be used for, it's either usually not worth it or clearly outclassed by other armors, or in the case of Power armor, it is great but the opportunity cost is usually too high to recommend it. And on its own the Red armor is far from the best armor, there are exotic and unique armors with a lot more potential than it, but it's certainly the most reliable armor when those better armors require luck to find. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 23:32, 11 August 2023 (UTC)

Modding:generator API (0.9.9.7)

2025-08-11T12:35:30Z

Epyon:

''This page is currently under construction.''

The generator holds all of the ever-present functions used to create the random maps in DRL. It also contains a variety of helper functions, many of them useful if not vital to the creation of intricate and meticulous game design.

== API ==

Please note that the type "integer" indicates an numeric value without a decimal part. It does not indicate the range of acceptable values.

The argument type "CellID" may be the numeric or string ID of a cell.

The argument type "CellSet" may be the numeric ID, string ID, or a list of numeric and/or string IDs.

The argument type "Flags" expects a list of [[Modding:Constants|flag constants]] of the indicated type.

An argument name in [square brackets] is an optional one. The function description will indicate how the function operates if it is omitted.

=== Generator API Function List ===

{|class="wikitable" style="border: 2px solid darkred; border-spacing: 0; font-size: 90%; margin: 0.25em 0.5em;"
! colspan="2" style="background: darkred; color: yellow; font-size: 120%; text-align: center"|'''Generator Interface - Functions'''
{{Table2Col
|es=background: #333;
|c1=font-weight:bold; text-align:right; vertical-align:top; padding:0px 2px;
|c2=padding:0px 2px;
||'''[[#Basic Cell Handling Functions|Basic Cell Handling Functions]]'''
|{{modarg|integer}}|{{moddef|list|get_cell|dot||Coord|loc}}
|{{modarg|string}}|{{moddef|list|get_cell_id|dot||Coord|loc}}
|{{modarg|integer}}|{{moddef|list|fast_get_cell|dot||integer|x|integer|y}}
|{{modarg|void}}|{{moddef|list|set_cell|dot||Coord|loc|CellID|what}}
|{{modarg|void}}|{{moddef|list|fast_set_cell|dot||integer|x|integer|y|integer|what}}
||'''[[#Map Checking Functions|Map Checking Functions]]'''
|{{modarg|integer}}|{{moddef|list|around|dot||Coord|where|CellSet|what}}
|{{modarg|integer}}|{{moddef|list|cross_around|dot||Coord|where|CellSet|what}}
|{{modarg|boolean}}|{{moddef|list|is_empty|dot||Coord|where|Flags|reqs}}
|{{modarg|boolean}}|{{moddef|list|is_empty_area|dot||Area|where|Flags|reqs}}
|{{modarg|boolean}}|{{moddef|list|scan|dot||Area|where|CellID|good}}
||'''[[#Map Searching Functions|Map Searching Functions]]'''
|{{modarg|Coord}}|{{moddef|list|drop_coord|dot||Coord|where|Flags|reqs}}
|{{modarg|Coord}}|{{moddef|list|find_coord|dot||CellSet|what|Area|[where]}}
|{{modarg|Coord}}|{{moddef|list|random_coord|dot||Area|[where]}}
|{{modarg|Coord}}|{{moddef|list|find_random_coord|dot||CellSet|what|Area|[where]}}
|{{modarg|Coord}}|{{moddef|list|find_empty_coord|dot||CellSet|what|Flags|reqs|Area|[where]}}
|{{modarg|Coord}}|{{moddef|list|random_empty_coord|dot||Flags|reqs|Area|[where]}}
|{{modarg|Coord}}|{{moddef|list|find_random_empty_coord|dot||CellSet|what|Flags|reqs|Area|[where]}}
|{{modarg|Coord}}|{{moddef|list|safe_empty_coord|dot||Area|[where]}}
|{{modarg|Coord}}|{{moddef|list|standard_empty_coord|dot}}
||'''[[#Advanced Cell Handling Functions|Advanced Cell Handling Functions]]'''
|{{modarg|void}}|{{moddef|list|fill|dot||CellID|what|Area|[where]}}
|{{modarg|void}}|{{moddef|list|fill_pattern|dot||Area|where|boolean|horiz|Table|line1|Table|[line2]}}
|{{modarg|void}}|{{moddef|list|fill_edges|dot||CellID|what}}
|{{modarg|Table}}|{{moddef|list|each|dot||CellID|what|Area|[where]}}
|{{modarg|void}}|{{moddef|list|set_blood|dot||Area|[where]|boolean|[value]|CellID|[what]}}
|{{modarg|void}}|{{moddef|list|set_permanence|dot||Area|[where]|boolean|[value]|CellID|[what]}}
|{{modarg|Table}}|{{moddef|list|cell_set|dot||CellSet|cells}}
|{{modarg|void}}|{{moddef|list|restore_walls|dot||CellID|wallCell|boolean|keepFluids}}
|{{modarg|void}}|{{moddef|list|plot_line|dot||Coord|where|boolean|horiz|CellID|cell|CellSet|block}}
|{{modarg|void}}|{{moddef|list|plot_lines|dot||Coord|where|Area|larea|boolean|horiz|CellID|cell|CellSet|block}}
|{{modarg|void}}|{{moddef|list|scatter|dot||Area|where|CellID|good|CellID|fill|integer|count}}
|{{modarg|void}}|{{moddef|list|scatter_blood|dot||Area|where|CellID|[good]|integer|count}}
|{{modarg|void}}|{{moddef|list|scatter_put|dot||Area|where|Table|translation|string|tile|CellID|good|integer|count}}
|{{modarg|void}}|{{moddef|list|transmute|dot||CellID|to|CellSet|from|Area|[where]}}
|{{modarg|void}}|{{moddef|list|transmute_marker|dot||Flag|marker|CellID|To|Area|[where]}}
||'''[[#Tile Handling Functions|Tile Handling Functions]]'''
|{{modarg|Table}}|{{moddef|list|create_translation|dot||Table|code}}
|{{modarg|Tile}}|{{moddef|list|tile_new|dot||string|map|Table|translation}}
|{{modarg|void}}|{{moddef|list|tile_place|dot||Coord|where|Tile|what}}
|{{modarg|void}}|{{moddef|list|place_tile|dot||Table|translation|string|tile|integer|x|integer|y}}
|{{modarg|void}}|{{moddef|list|place_dungen_tile|dot||Table|code|Tile|tile|Coord|where}}
|{{modarg|void}}|{{moddef|list|place_symmetry_quad|dot||string|tile|Table|translation}}
|{{modarg|void}}|{{moddef|list|place_proto_map|dot||Coord|where|string|proto_map|string|proto_key|Table|code}}
||'''[[#Room Handling Functions|Room Handling Functions]]'''
|{{modarg|void}}|{{moddef|list|add_room|dot||Area|room|string|[class]}}
|{{modarg|void}}|{{moddef|list|add_rooms|dot}}
|{{modarg|Room}}|{{moddef|list|get_room|dot||integer|min_size|integer|max_x|integer|max_y|integer|max_area|string|[class]}}
|{{modarg|integer, integer}}|{{moddef|list|get_endpoints|dot||Coord|where|boolean|horiz|CellSet|what}}
|{{modarg|void}}|{{moddef|list|handle_rooms|dot||integer|count|boolean|no_monsters}}
||'''[[#Generation Algorithm Functions|Generation Algorithm Functions]]'''
|{{modarg|void}}|{{moddef|list|run_drunkard_walk|dot||Area|where|Coord|start|integer|steps|CellID|fill|CellSet|[ignore]|boolean|[stop_at_edge]}}
|{{modarg|void}}|{{moddef|list|drunkard_walks|dot||integer|amount|integer|steps|CellID|fill|CellSet|[ignore]|boolean|[stop_at_edge]|Area|[where]}}
|{{modarg|void}}|{{moddef|list|contd_drunkard_walks|dot||integer|amount|integer|steps|CellID|fill|CellSet|edges1|CellSet|edges2|CellSet|[ignore]|boolean|[stop_at_edge]}}
|{{modarg|void}}|{{moddef|list|warehouse_fill|dot||CellSet|fill|Area|where|integer|size|integer|count|integer|special_chance|CellSet|special}}
|{{modarg|void}}|{{moddef|list|place_blob|dot||Coord|start|integer|size|CellID|cell}}
||'''[[#Generator Helper Functions|Generator Helper Functions]]'''
|{{modarg|<value>, <value>}}|{{moddef|list|roll_pair|dot||Table|list}}
|{{modarg|integer}}|{{moddef|list|being_weight|dot}}
|{{modarg|integer}}|{{moddef|list|item_amount|dot}}
|{{modarg|void}}|{{moddef|list|horiz_river|dot||CellID|cell|integer|width|boolean|[bridge]}}
|{{modarg|void}}|{{moddef|list|vert_river|dot||CellID|cell|integer|width|boolean|bridge|integer|position}}
{{moddef|list|vert_river|dot||CellID|cell|integer|width|boolean|bridge|Coord|position}}
|{{modarg|void}}|{{moddef|list|generate_rivers|dot||boolean|allow_horiz|boolean|allow_more}}
|{{modarg|void}}|{{moddef|list|generate_fluids|dot||Area|[where]}}
|{{modarg|void}}|{{moddef|list|generate_barrels|dot}}
|{{modarg|void}}|{{moddef|list|generate_stairs|dot}}
|{{modarg|void}}|{{moddef|list|generate_special_stairs|dot}}
|{{modarg|void}}|{{moddef|list|place_player|dot}}
|{{modarg|void}}|{{moddef|list|run|dot||Generator|gen}}
|{{modarg|void}}|{{moddef|list|reset|dot}}
||'''[[#Dungeon Generation Functions|Dungeon Generation Functions]]'''
|{{modarg|void}}|{{moddef|list|generate_tiled|dot}}
|{{modarg|void}}|{{moddef|list|maze_dungeon|dot||CellID|floor|CellID|wall|integer|granularity|integer|tries|integer|min_size|integer|max_size}}
|{{modarg|void}}|{{moddef|list|generate_caves_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_caves_2_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_lava_dungeon|dot}}
||'''[[#Event Handler Functions|Event Handler Functions]]'''
|{{modarg|void}}|{{moddef|list|roll_event|dot}}
|{{modarg|void}}|{{moddef|list|setup_flood_event|dot||integer|direction|integer|step|CellID|cell}}
|{{modarg|void}}|{{moddef|list|setup_deadly_air_event|dot||integer|step}}
|{{modarg|void}}|{{moddef|list|setup_explosion_event|dot||integer|step|integer|size|integer|dice|integer|[content]}}
{{moddef|list|setup_explosion_event|dot||integer|step|Table|size|integer|dice|integer|[content]}}
|{{modarg|void}}|{{moddef|list|setup_targeted_event|dot||integer|step}}
|}}
|}

=== Basic Cell Handling Functions ===
;{{moddef|desc|get_cell|dot|integer|Coord|loc}}
Gets the Numeric ID (NID) of the [[Modding:Cell|cell]] at a given map position.
:''loc'': The coordinates of the cell to get.
:'''Returns''': The NID of the cell.
----
;{{moddef|desc|get_cell_id|dot|string|Coord|loc}}
Gets the ID of the [[Modding:Cell|cell]] at a given map position.
:''loc'': The coordinates of the cell to get.
:'''Returns''': The string ID of the cell.
----
;{{moddef|desc|fast_get_cell|dot|integer|integer|x|integer|y}}
Gets the Numeric ID (NID) of the [[Modding:Cell|cell]] at a given map position.
:''x'': The X position of the cell to get.
:''y'': The Y position of the cell to get.
:'''Returns''': The NID of the cell.
----
;{{moddef|desc|set_cell|dot||Coord|loc|CellID|what}}
Assigns a [[Modding:Cell|cell]] to a map position.
:''loc'': The coordinates of the position to set.
:''what'': The ID of the cell to assign to the position.
----
;{{moddef|desc|fast_set_cell|dot||integer|x|integer|y|integer|what}}
Assigns a [[Modding:Cell|cell]] to a map position.
:''x'': The X position of the cell to set.
:''y'': The Y position of the cell to set.
:''what'': The NID (string IDs not allowed) of the cell to assign to the position.
----
=== Map Checking Functions ===
;{{moddef|desc|around|dot|integer|Coord|where|CellSet|what}}
Checks the positions adjacent to a location (including diagonally adjacent) and returns the number of cells that match one of the indicated cell IDs.
:''where'': The coordinate to check around. The coordinate sent in this way is not checked, only adjacent cells are.
:''what'': The cell(s) to check for.
:'''Returns''': The number of cells (from 0 to 8) that matched one of the ''what'' cell IDs.
----
;{{moddef|desc|cross_around|dot|integer|Coord|where|CellSet|what}}
Checks the positions adjacent to a location (but not diagonally adjacent) and returns the number of cells that match one of the indicated cell IDs.
:''where'': The coordinates to check around. The coordinate sent in this way is not checked, only adjacent cells are.
:''what'': The cell(s) to check for.
:'''Returns''': The number of cells (from 0 to 4) that matched one of the ''what'' cell IDs.
----
;{{moddef|desc|is_empty|dot|boolean|Coord|where|Flags|reqs}}
Checks to see if the indicated cell is "empty", defining "empty" based on a list of criteria.
:''where'': The position to check.
:''reqs'': A list of EmptyFlags (named numeric constants that start with EF_) indicating which types of objects or properties the position cannot have. For example, if the flag EF_NOBEINGS is sent, the function only returns true if the map position does not contain a [[Modding:Being|being]]. See [[Modding:Constants#Empty_Flags]] for more information.
:'''Returns''': ''True'' if the cell satisfies all of the conditions indicated in ''reqs'', ''False'' otherwise.
----
;{{moddef|desc|is_empty_area|dot|boolean|Area|where|Flags|reqs}}
Checks to see if the indicated area is "empty", defining "empty" based on a list of criteria.
:''where'': The area to check.
:''reqs'': A list of EmptyFlags (named numeric constants that start with EF_) indicating which types of objects or properties the area cannot have. For example, if the flag EF_NOBEINGS is sent, the function only returns true if the area does not contain a [[Modding:Being|being]]. See [[Modding:Constants#Empty_Flags]] for more information.
:'''Returns''': ''True'' if every cell in the area satisfies all of the conditions indicated in ''reqs'', ''False'' otherwise.
----
;{{moddef|desc|scan|dot|boolean|Area|where|CellID|good}}
Checks to see if the entire area is filled with a certain cell.
:''where'': The area to check.
:''good'': The cell to look for.
:'''Returns''': ''True'' if all cells in the area are ''good'', ''False'' otherwise.
----
=== Map Searching Functions ===
;{{moddef|desc|drop_coord|dot|Coord|Coord|where|Flags|reqs}}
Finds the nearest "empty" coordinate to a given coordinate, defining "empty" based on a list of criteria.
:''where'': The coordinate to try. If this coordinate is "empty", this coordinate will be returned.
:''reqs'': A list of EmptyFlags (named numeric constants that start with EF_) indicating which types of objects or properties the coordinate cannot have. For example, if the flag EF_NOBEINGS is sent, the function only returns a coordinate that does not contain a [[Modding:Being|being]]. See [[Modding:Constants#Empty_Flags]] for more information.
:'''Returns''': The nearest coordinate the satisfies the criteria. If the supplied coordinate meets the criteria, that coordinate will be returned. If not a nearby, random, coordinate will be checked.
----
;{{moddef|desc|find_coord|dot|Coord|CellSet|what|Area|[where]}}
Searches the map for the first coordinate containing one of the indicated cell IDs.
:''what'': The cell(s) to search for.
:''where'': ''Optional.'' The area to restrict the search to. If omitted, the coordinate can be picked from anywhere on the map.
:'''Returns''': The coordinates of the first position that contains one of the ''what'' cell IDs. The map is checked row by row starting from the top, going from left to right across each row.
----
;{{moddef|desc|random_coord|dot|Coord|Area|[where]}}
Searches for a random coordinate within the specified area.
:''where'': ''Optional.'' The area to restrict the coordinate to. If omitted, the coordinate can be picked from anywhere on the map.
:'''Returns''': A random coordinate.
----
;{{moddef|desc|find_random_coord|dot|Coord|CellSet|what|Area|[where]}}
Searches for a random coordinate within the specified area that contains one of the specified cell IDs.
:''what'': The cell(s) to search for.
:''where'' : ''Optional.'' The area to restrict the search to. If omitted, the coordinate can be picked from anywhere on the map.
:'''Returns''': A random coordinate that meets the supplied criteria.
----
;{{moddef|desc|find_empty_coord|dot|Coord|CellSet|what|Flags|reqs|Area|[where]}}
Searches the map for the first "empty" coordinate containing one of the indicated cell IDs, defining "empty" based on a list of criteria.
:''what'': The cell(s) to search for.
:''reqs'': A list of EmptyFlags (named numeric constants that start with EF_) indicating which types of objects or properties the coordinate cannot have. For example, if the flag EF_NOBEINGS is sent, the function only returns a coordinate that does not contain a [[Modding:Being|being]]. See [[Modding:Constants#Empty_Flags]] for more information.
:''where'': ''Optional.'' The area to restrict the search to. If omitted, the coordinate can be picked from anywhere on the map.
:'''Returns''': The coordinates of the first position that meets the supplied criteria. The map is checked row by row starting from the top, going from left to right across each row.
----
;{{moddef|desc|random_empty_coord|dot|Coord|Flags|reqs|Area|[where]}}
Searches the map for a random coordinate that is "empty", defining "empty" based on a list of criteria.
:''reqs'': A list of EmptyFlags (named numeric constants that start with EF_) indicating which types of objects or properties the random coordinate cannot have. For example, if the flag EF_NOBEINGS is sent, the function only returns a coordinate that does not contain a [[Modding:Being|being]]. See [[Modding:Constants#Empty_Flags]] for more information.
:''where'': ''Optional.'' The area to restrict the search to. If omitted, the coordinate can be picked from anywhere on the map.
:'''Returns''': A random coordinate that meets the supplied criteria.
----
;{{moddef|desc|find_random_empty_coord|dot|Coord|CellSet|what|Flags|reqs|Area|[where]}}
Searches the map for a random "empty" coordinate containing one of the indicated cell IDs, defining "empty" based on a list of criteria.
:''what'': The cell(s) to search for.
:''reqs'': A list of EmptyFlags (named numeric constants that start with EF_) indicating which types of objects or properties the random coordinate cannot have. For example, if the flag EF_NOBEINGS is sent, the function only returns a coordinate that does not contain a [[Modding:Being|being]]. See [[Modding:Constants#Empty_Flags]] for more information.
:''where'': ''Optional.'' The area to restrict the search to. If omitted, the coordinate can be picked from anywhere on the map.
:'''Returns''': A random coordinate that meets the supplied criteria.
----
;{{moddef|desc|random_square|dot|Coord|CellSet|what}}
Searches for a random 3x3 area containing only specified cells.
:''what'': The cell(s) to search for.
:'''Returns''': The center coordinate of the random 3x3 area.
----
;{{moddef|desc|safe_empty_coord|dot|Coord|Area|[where]}}
Searches for a random coordinate that meets certain predetermined criteria.

The function will try to find a coordinate that does not contain a being, item, staircase, wall, harmful terrain, spawning restrictions (cells marked with LF_NOSPAWN), and is more than 5 spaces from the player (EF_NOBEINGS, EF_NOITEMS, EF_NOSTAIRS, EF_NOBLOCK, EF_NOHARM, EF_NOSPAWN, and EF_NOSAFE). If a valid space isn't found, the function will ignore distance from the player (EF_NOSAFE). If a valid space still can't be found, the function will ignore stairs and harmful terrain (EF_NOSTAIRS and EF_NOHARM).
:''where'': ''Optional.'' The area to restrict the initial pass to. If a valid coordinate is not found within the area after ignoring stairs and harmful terrain, the search is restarted and expanded automatically to the entire map. If omitted, the entire map will be searched.
:'''Returns''': A random coordinate that meets the criteria.
----
;{{moddef|desc|standard_empty_coord|dot|Coord}}
Searches for a random coordinate that meets certain predetermined criteria.

The function will search for a coordinate that does not contain a being, item, staircase, wall, harmful terrain, or spawning restrictions (EF_NOBEINGS, EF_NOITEMS, EF_NOSTAIRS, EF_NOBLOCK, EF_NOHARM, and EF_NOSPAWN).
:'''Returns''': A random coordinate that meets the criteria.
----
=== Advanced Cell Handling Functions ===
;{{moddef|desc|fill|dot||CellID|what|Area|[where]}}
Fills an area of the map with a given cell.
:''what'': The cell to fill with.
:''where'': ''Optional.'' The area to fill with the cell. If omitted, the entire map will be filled.
----
;{{moddef|desc|fill_pattern|dot||Area|where|boolean|horiz|string|Table|line1|Table|[line2]}}
Fills an area of the map with a pattern of cells.
:''where'': The area to fill.
:''horiz'': If ''True'', the pattern will fill each row left to right, then move to the next row down in the area. If ''False'', the pattern will fill each column top to bottom, then move to the next column right in the area.
:''line1'': The pattern to fill with. If the pattern is shorter than the area size, the pattern will loop. The pattern does not restart at the end of a row or column.
:''line2'': ''Optional.'' If given, each time the end of row (if ''horiz'' is ''True'') or column (if ''horiz'' is ''False'') is reached, the function will switch to filling with the other pattern. That is, the first row will use ''line1'' then the second will use ''line2'', then the third will use ''line1'' again, etc.
----
;{{moddef|desc|fill_edges|dot||CellID|what}}
Fills the edges of the map with the given cell.
:''what'': The cell to fill with.
----
;{{moddef|desc|each|dot|Table|CellID|what|Area|[where]}}
Searches for a cell and returns a table containing every location it was found.
:''what'': The cell to search for.
:''where'': ''Optional.'' The area to restrict the search to.
:'''Returns''': A table containing a list of [[Modding:Coord|Coord]] objects.
----
;{{moddef|desc|set_blood|dot||Area|[where]|boolean|[value]|CellID|[what]}}
Adds blood to the map or removes blood from it.
:''where'': ''Optional.'' The area to affect. If omitted, the entire map will selected.
:''value'': ''Optional.'' ''True'' adds blood. ''False'' removes it. If omitted, the default is to add blood.
:''what'': ''Optional.'' If provided, only locations containing the given cell are affected. If omitted, all cells in the area are affected.
----
;{{moddef|desc|set_permanence|dot||Area|[where]|boolean|[value]|CellID|[what]}}
Makes cell permanent or removes their permanence.
:''where'': ''Optional.'' The area to affect. If omitted, the entire map will be selected.
:''value'': ''Optional.'' ''True'' adds permanence. ''False'' removes it. If omitted, the default is to add permanence.
:''what'': ''Optional.'' If provided, only locations containing the given cell are affected. If omitted, wall cells (which includes crate cells) are affected.
----
;{{moddef|desc|cell_set|dot|Table|CellSet|cells}}
Creates a cell group.
:''cells'': A list of cells to add to the group.
:'''Returns''': A cell group table.
----
;{{moddef|desc|restore_walls|dot||CellID|wallCell|boolean|keepFluids}}
Fixes the edge walls of the map.
:''wallCell'': The cell to fill the edge of the map with.
:''keepFluids'': ''True'' to maintain any fluid tiles on the edge of the map. ''False'' to overwrite them.
----
;{{moddef|desc|plot_line|dot||Coord|where|boolean|horiz|CellID|cell|CellSet|block}}
Splits an area into two at the indicated location.
:''where'': The starting point.
:''horiz'': ''True'' draws along the indicated X position of the ''where'' coordinate. ''False'' draws along the indicated Y position of the ''where'' coordinate.
:''cell'': The cell that will be used to split the area.
:''block'': The cell(s) that block the line plotting. The drawn line will stop before hitting a coordinate with one of these cells.
----
;{{moddef|desc|plot_lines|dot||Coord|where|Area|larea|boolean|horiz|CellID|cell|CellSet|block}}
Splits an area into two at the indicated location.
:''where'': The starting point.
:''larea'': The boundaries of the line. The line will not extend past the edge of the area.
:''horiz'': ''True'' draws along the indicated X position of the ''where'' coordinate. ''False'' draws along the indicated Y position of the ''where'' coordinate.
:''cell'': The cell that will be used to split the area.
:''block'': The cell(s) that block the line plotting. The drawn line will stop before hitting a coordinate with one of these cells.
----
;{{moddef|desc|scatter|dot||Area|where|CellID|good|CellID|fill|integer|count}}
Randomly places a certain cell around the map.
:''where'': The area to scatter the cell in.
:''good'': Only this locations with this cell will be changed by the function.
:''fill'': The cell to scatter around the area.
:''count'': The number to attempt to place. If the chosen location is not ''good'', then it will not change it. The final number placed may be less than ''count'' (or even 0), but never more.
----
;{{moddef|desc|scatter_blood|dot||Area|where|CellID|[good]|integer|count}}
Randomly adds blood in an area.
:''where'': The area to scatter blood in.
:''good'': ''Optional.'' If defined, only locations with this cell will have blood added. If omitted, any location my have blood added.
:''count'': The number of attempts. On each attempt, a random cell in the area will be chosen to have blood added. The number of cell that will end up bloody may be less than ''count'' (or even 0), but never more.
----
;{{moddef|desc|scatter_put|dot||Area|where|Table|translation|string|tile|CellID|good|integer|count}}
Randomly adds a specified tile (a defined arrangement of cells) around the map.
:''where'': The area to scatter the tile in. The tiles will only be placed in locations entirely within the area.
:''translation'': A table with to be used with the ''tile'' argument. Refer to this (will be linked soon) for more information.
:''tile'': A multi-line string, one row of the tile per line, that lays out the arrangment of the cells. Refer to this (will be linked soon) for more information
:''good'': Only locations with this cell will be valid for the tile placement. If any coordinates of the selected placement area are not ''good'', the tile will not be placed at that location.
:''count'': The number of tiles to try to place. The placement will continue until this many have been placed, or 10,000 attempts have been made, whichever comes first.
----
;{{moddef|desc|transmute|dot||CellID|to|CellSet|from|Area|[where]}}
Changes all of one cell on the map to another cell.
:''to'': The cell that will replace the existing cells.
:''from'': The cell(s) that will be replaced.
:''where'': ''Optional.'' If specified, only cells in the area are changed. If omitted, the function will change cells across the entire map.
----
;{{moddef|desc|transmute_marker|dot||Flag|marker|CellID|To|Area|[where]}}
Changes all positions on the map that have a specified LightFlag (a named constant starting with "LF", no underscore) to another cell.
:''marker'': The LightFlag to check for. Only cells with this flag will be changed.
:''to'': The cell that will replace the existing cells.
:''where'': ''Optional.'' If specified, only cells in the area are changed. If omitted, the function will change cells across the entire map.
----

=== Tile Handling Functions ===
;{{moddef|desc|create_translation|dot|Table|Table|code}}
Parses a translation table. Refer to this (will be linked soon) for more information.
:''code'': The translation table.
:'''Returns''': A parsed translation table.
----
;{{moddef|desc|tile_new|dot|Tile|string|map|Table|translation}}
Creates a new tile object.
:''map'': A multi-line string containing the arrangement of the tile using the ''translation'' to convert the characters to cells. Refer to this (will be linked soon) for more information.
:''translation'': A table with to be used with the ''map'' argument. Refer to this (will be linked soon) for more information.
:'''Returns''': The new tile object.
----
;{{moddef|desc|tile_place|dot||Coord|where|Tile|what}}
Places the cells of the tile on the map.
:''where'': The coordinate that the upper-left of the tile should reside at.
:''what'': The tile object that will be placed.
----
;{{moddef|desc|place_tile|dot||Table|translation|string|tile|integer|x|integer|y}}
Combines the tile_new and tile_place functions together, by placing a tile using a string and translation table.
:''translation'': A table with to be used with the ''tile'' argument. Refer to this (will be linked soon) for more information.
:''tile'': A multi-line string containing the arrangement of the tile using the ''translation'' to convert the characters to cells. Refer to this (will be linked soon) for more information.
:''x'': The X position that the tile will be placed at.
:''y'': The Y position that the tile will be placed at.
----
;{{moddef|desc|place_dungen_tile|dot||Table|code|Tile|tile|Coord|where}}
Places an entire tile, including beings and items in the translation, on the map.
:''code'': The translation table. Refer to this (will be linked soon) for more information.
:''tile'': A multi-line string containing the arrangement of the tile using the ''translation'' to convert the characters to cells and indicate the positions of the beings and items. Refer to this (will be linked soon) for more information.
:''where'': The coordinate the tile will be placed at.
----
;{{moddef|desc|place_symmetry_quad|dot||string|tile|Table|translation}}
Takes a tile object and places it in all four corners. The tile object should be setup for the upper left corner and will be mirrored to the other corners. The tiles are placed one space from the map edge.
:''tile'': A multi-line string containing the arrangement of the tile using the ''translation'' to convert the characters to cells and indicate the positions of the beings and items. Refer to this (will be linked soon) for more information.
:''translation'': The translation table. Refer to this (will be linked soon) for more information.
----
;{{moddef|desc|place_proto_map|dot||Coord|where|string|proto_map|string|proto_key|Table|code}}
Creates a map using multiple tile sets.
:''where'': The upper-left position of the map where the tiles will be layout from.
:''proto_map'': A string indicating the arrangement of the different pieces of the map. e.g., "ABCD", will lay out 4 different tiles with A on the far left and D on the far right.
:''proto_key'': A table containing, for each character in ''proto_map'', a table of the possible tiles for that section.
:''code'': The translation table for all the tile possibilities. Refer to this (will be linked soon) for more information. All tiles use the same translation table.
----

=== Room Handling Functions ===
;{{moddef|desc|add_room|dot||Area|room|string|[class]}}
Marks an area that can become a special room.
:''room'': The area of the room. This includes the walls.
:''class'': ''Optional.'' A string used to denote which room generators can be used on this room. If omitted, the class used is "closed".
----
;{{moddef|desc|add_rooms|dot}}
Finds all the areas that can be rooms on a map and adds them to the appropriate meta-map tables.
----
;{{moddef|desc|get_room|dot|Room|integer|min_size|integer|max_x|integer|max_y|integer|max_area|string|class}}
Selects a room given certain criteria.
:''min_size'': The smallest X and Y dimensions the room can be.
:''max_x'': The maximum width of the room.
:''max_y'': The maximum height of the room.
:''max_area'': The largest area the room can be.
:''class'': ''Optional.'' The string denoting which room classes are valid for this room generator. If omitted, "any" is used, which does not restrict the selection of rooms.
----
;{{moddef|desc|get_endpoints|dot|integer, integer|Coord|where|boolean|horiz|CellSet|what}}
Finds the ends of a line of cells.
:''where'': The starting coordinate.
:''horiz'': ''True'' checks horizontally. ''False'' checks vertically.
:''what'': The cell(s) that make up the line to check. The functions stops at the first cell '''not''' in this list.
:'''Returns''': Two integers. If ''horiz'' is ''True'', these are the X positions the line stops at. If ''horiz'' is ''False'', these are the Y positions the line stops at.
----
;{{moddef|desc|handle_rooms|dot||integer|count|boolean|no_monsters}}
Runs the rooms selection and setup process for a map.
:''count'': The number of rooms to attempt to place.
:''no_monsters'': ''True'' will exclude room generators that place monsters. ''False'' will not.
----
=== Generation Algorithm Functions ===
;{{moddef|desc|run_drunkard_walk|dot||Area|where|Coord|start|integer|steps|CellID|fill|CellSet|[ignore]|boolean|[stop_at_edge]|Area|where}}
Runs an algorithm that walks to random adjacent spaces.
:''where'': The area that the algorithm will run in. If the algorithm tries to leave the area, it will stop early or will be pushed back in the area (''stop_at_edge'' will determine which of these happen).
:''start'': The location the algorithm will begin at.
:''steps'': The number of steps the algorithm will take. The number of spaces covered by the algorithm will be at most this number.
:''fill'': The cell that will be placed at each location the algorithm hits.
:''ignore'': ''Optional.'' If specified, the algorithm will not place the ''fill'' cell in any location that has one of the cell(s) specified. If omitted, no locations are ignored.
:''stop_at_edge'': ''Optional.'' If ''True'', the algorithm will end early if it moves past the end of the area. If ''False'', the algorithm will clamp to the area (any moves to outside the area get moved back in the area). If omitted, the default is to clamp.
----
;{{moddef|desc|drunkard_walks|dot||integer|amount|integer|steps|CellID|fill|CellSet|[ignore]|boolean|[stop_at_edge]|Area|[where]}}
Runs multiple "drunken walk" algorithms.
:''amount'': The number of times to perform the algorithm.
:''steps'': The number of steps each run of the algorithm will take. The number of spaces covered by the algorithm will be at most the ''amount'' times the number of ''steps''.
:''fill'': The cell that will be placed at each location the algorithm hits.
:''ignore'': ''Optional.'' If specified, the algorithm will not place the ''fill'' cell in any location that has one of the cell(s) specified. If omitted, no locations are ignored.
:''stop_at_edge'': ''Optional.'' If ''True'', the algorithm will end early if it moves past the end of the area. If ''False'', the algorithm will clamp to the area (any moves to outside the area get moved back in the area). If omitted, the default is to clamp.
:''where'': ''Optional.'' The area the algorithm will run in. If the algorithm tries to leave the area, it will stop early or will be pushed back in the area (''stop_at_edge'' will determine which of these happen). If omitted, the default is entire area minus the very edge.
----
;{{moddef|desc|contd_drunkard_walks|dot||integer|amount|integer|steps|CellID|fill|CellSet|edges1|CellSet|edges2|CellSet|[ignore]|boolean|[stop_at_edge]}}
Runs multiple "drunken walk" algorithms starting at a space that doesn't have certain cells around it.
:''amount'': The number of times to perform the algorithm.
:''steps'': The number of steps each run of the algorithm will take. The number of spaces covered by the algorithm will be at most the ''amount'' times the number of ''steps''.
:''fill'': The cell that will be placed at each location the algorithm hits.
:''edges1'': The algorithm will not start on a space with a cell listed here next to it.
:''edges2'': The algorithm will not start on a space with a cell listed here next to it.
:''ignore'': ''Optional.'' If specified, the algorithm will not place the ''fill'' cell in any location that has one of the cell(s) specified. If omitted, no locations are ignored.
:''stop_at_edge'': ''Optional.'' If ''True'', the algorithm will end early if it moves past the end of the area. If ''False'', the algorithm will clamp to the area (any moves to outside the area get moved back in the area). If omitted, the default is to clamp.
----
;{{moddef|desc|warehouse_fill|dot||CellID|fill|Area|where|integer|[size]|integer|[count]|integer|[special_chance]|CellID|[special]}}
Fills an area with random squares of cells.
:''fill'': The cell(s) to use for each square. If a list is given, one is chosen at random for each square.
:''where'': The area to fill.
:''size'': ''Optional.'' The size of the squares to use. If omitted, the default is 2.
:''count'': ''Optional.'' The number of attempts. If omitted, the default is 50.
:''special_chance'': ''Optional.'' A number indicating the probability of using a special list of cells to fill the square with instead of the ''fill'' list. The roll used for the chance is based on the ''size'' parameter. A number from 1 to (100 * ''size'') is chosen for each square and if the roll is less than the special_chance number, the ''special'' cell set is used to fill the square instead. If omitted, all squares will be filled from the ''fill'' set.
:''special'': ''Optional.'' The list of cells to use if the special set is to be used, based on ''special_chance''. If omitted, all squares will be filled from the ''fill'' set.
----
;{{moddef|desc|place_blob|dot||Coord|start|integer|size|CellID|cell}}
Fills an area by expanding to random edge coordinates.
:''start'': The position to start the blob at.
:''size'': The number of spaces to expand the blob to.
:''cell'': The cell to fill the blob area with.
----
=== Generator Helper Functions ===
;{{moddef|desc|roll_pair|dot|<value>, <value>|Table|list}}
Takes a list of values of any type and returns two different values randomly from the list.
:''list'': The list to choose from.
:'''Returns''': Two different values. If the list only contains one choice, it will be returned, but only once.
----
;{{moddef|desc|being_weight|dot}}
Gets the total danger level for the current dungeon level.
'''Returns''': The danger level for the current dungeon level. This value is calcuated using the current difficulty and ''level.danger_level''.
----
;{{moddef|desc|item_amount|dot}}
Gets the number of items to drop for the current dungeon level.
'''Returns''': The number of items to drop for the current dungeon level.
----
;{{moddef|desc|horiz_river|dot||CellID|cell|integer|width|boolean|[bridge]}}
Places a horizontal river on the map.
:''cell'': The cell to use for the river. It does not have to be a fluid cell.
:''width'': The width of the river.
:''bridge'': ''Optional.'' If ''True'', a 2 space wide bridge will be placed at a random coordinate on the river. If ''False'', no bridge will be placed. If omitted, the default is to not place a bridge.
----
;{{moddef|desc|vert_river|dot||CellID|cell|integer|width|boolean|bridge|integer|[position]}}
;{{moddef|desc|vert_river|dot||CellID|cell|integer|width|boolean|bridge|Coord|[position]}}
Places a vertical river on the map.
:''cell'': The cell to use for the river. It does not have to be a fluid cell.
:''width'': The width of the river.
:''bridge'': ''Optional.'' If ''True'', a 2 space wide bridge will be placed at a random coordinate on the river. If ''False'', no bridge will be placed. If omitted, the default is to not place a bridge.
:: NOTE: Because of a bug, a bridge will always be placed on the river, even if this value is set to ''False'' or omitted.
:''position'': A coordinate or an integer. If an integer is supplied, this is the X position of the river's left edge. If a coordinate is supplied, the river will start at this coordinate. If omitted, the river's left edge will be selected from between X = 19 to 58.
----
;{{moddef|desc|generate_rivers|dot||boolean|allow_horiz|boolean|allow_more}}
Creates rivers based on normal DRL river generation.
:''allow_horiz'': ''True'' allows horizontal rivers to be generated. ''False'' will prevent the generation of horizontal rivers.
:''allow_more'': ''True'' allows multiple vertical rivers. ''False'' will prevent more than one vertical river from being placed.
----
;{{moddef|desc|generate_fluids|dot||Area|[where]}}
Creates fluids based on normal DRL fluid generation.
:''where'': ''Optional.'' The area to generate fluids in. If omitted, the area used will be the entire map minus the very edge.
----
;{{moddef|desc|generate_barrels|dot}}
Creates barrels based on normal DRL barrel generation.
----
;{{moddef|desc|generate_stairs|dot}}
Creates the normal staircase based on normal DRL stair generation.
----
;{{moddef|desc|generate_special_stairs|dot}}
Creates the special staircase based on normal DRL special stair generation. Whether a special staircase is placed depends on the level.special_exit value.
----
;{{moddef|desc|place_player|dot}}
Places the player on a random empty space.
----
;{{moddef|desc|run|dot||Generator|gen}}
Runs a generator object. These are stored in the generators table.
:''gen'': The generator object to run.
----
;{{moddef|desc|reset|dot}}
Resets the map.
----
=== Dungeon Generation Functions ===
;{{moddef|desc|generate_tiled|dot}}
Creates a tiled dungeon, also known as a "normal" dungeon. This only creates the layout, it does not place beings, items, stairs, barrels, or the player.
----
;{{moddef|desc|maze_dungeon|dot||CellID|floor|CellID|wall|integer|granularity|integer|tries|integer|min_size|integer|max_size}}
Creates a maze dungeon. This only creates the layout, it does not place beings, items, stairs, barrels, or the player.
:''floor'': The cell to use for the floor of the maze.
:''wall'': The cell to use for the wall of the maze.
:''granularity'': This denotes the size of the maze's paths.
:''tries'': Number of attempts to place a new wall in the maze.
:''min_size'': The smallest possible size of a wall.
:''max_size'': The largest possible size of a wall.
----
;{{moddef|desc|generate_caves_dungeon|dot}}
Runs the generation script for the cave dungeon. This is an all inclusive function, it also places all beings and items.
----
;{{moddef|desc|generate_caves_2_dungeon|dot}}
Runs the generation script for the cave-city dungeon. This is an all inclusive function, it also places all beings and items.
----
;{{moddef|desc|generate_lava_dungeon|dot}}
Runs the generation script for the lava dungeon. This is an all inclusive function, it also places all beings and items.
----
=== Event Handler Functions ===
;{{moddef|desc|roll_event|dot}}
Picks an event from the events table and sets it up.
----
;{{moddef|desc|setup_flood_event|dot||integer|direction|integer|step|CellID|cell}}
Runs the setup script for the flood event.
:''direction'': Use 1 to flood from the left. Use -1 to flood from the right.
:''step'': Number of turns (0.1 second intervals) between each flood step.
:''cell'': The cell to flood with. This does not have to be a fluid cell.
----
;{{moddef|desc|setup_deadly_air_event|dot||integer|step}}
Runs the setup script for the deadly air event.
:''step'': Number of turns between each "chill" (loss of HP).
----
;{{moddef|desc|setup_explosion_event|dot||integer|step|integer|size|integer|dice|integer|[content]}}
;{{moddef|desc|setup_explosion_event|dot||integer|step|Table|size|integer|dice|integer|[content]}}
Runs the setup script for the explosion event.
:''step'': Number of turns between each explosion.
:''size'': Either a number or a table of two numbers. Indicates the size of each explosion. If a table is supplied, the size is randomly chosen between the range supplied each time an explosion is created.
:''dice'': Number of d6 dice to use for the damage roll.
:''content'': ''Optional.'' The content to place in any space where the damage to a space is more than 20 points. If omitted, nothing will placed.
----
;{{moddef|desc|setup_targeted_event|dot||integer|step}}
Runs the setup script for the targeting event.
:''step'': Number of turns between each monster teleport.
----

Modding:being blueprint (0.9.9.7)

2025-08-11T12:35:05Z

Epyon:

The being [[Modding:blueprint|blueprint]] is used to define new beings.

== Blueprint ==

Being blueprints are registered with the ''register_being'' procedure. Registered blueprints are stored in a global Lua table called ''beings''.

{{drltable|Being Blueprint|3|{{Table3Col
|es=background: #333;
|c1=font-family:monospace; text-align:right; vertical-align:top; padding:0px 2px;
|c2=vertical-align:top; padding:0px 2px;
|c3=padding:0px 2px;
|id |{{modarg|string}}|The unique identifier used by the engine for this being. Passed as the first argument when registering a blueprint.
|name |{{modarg|string}}|This is the being's name.
|name_plural |{{modarg|string}}|This is the being's pluralized name. This defaults to the being's the name with an "s" appended.
|sound_id |{{modarg|being}}|If included the being will search for sounds bound to this id instead of its own.
|ascii |{{modarg|string}}|This is the being's picture in console mode. It should be a single character string.
|color |{{modarg|Color}}|This is the being's color in console mode.
|sprite |{{modarg|Sprite}}|This is the being's sprite in graphical mode.
|coscolor |{{modarg|ColorSet}}|This is a graphical mode filter that can be used to add color to specific sprites.
|glow |{{modarg|ColorSet}}|This is a graphical mode filter that can be used to give a sprite a colored glow.
|overlay |{{modarg|ColorSet}}|This is a graphical mode filter that can be used to subtract color from any sprite.
|hp |{{modarg|integer}}|This is the being's hpmax and starting hp. The default is 10.
|armor |{{modarg|integer}}|This is the being's armor bonus. The default is 0.
|attackchance |{{modarg|integer}}|This is the being's attackchance. The default is 75.
|todam |{{modarg|integer}}|This is the being's todam bonus. The bonus applies only to melee attacks. The default is 0.
|tohit |{{modarg|integer}}|This is the being's tohit bonus. The default is 0.
|tohitmelee |{{modarg|integer}}|This is the being's tohitmelee bonus. The default is 0.
|speed |{{modarg|integer}}|This is the being's speed. The maximum allowed speed is 255. The default is 100.
|vision |{{modarg|integer}}|This is the being's vision bonus. The default is 0, meaning the same vision as the player.
|min_lev |{{modarg|integer}}|This is a [[Monster Generation|monster generation]] parameter.
|max_lev |{{modarg|integer}}|This is a [[Monster Generation|monster generation]] parameter. The default is 10000.
|corpse |{{modarg|cell}}|The determines the corpse left by the being. Instead of passing in a cell directly you can pass a boolean ''true'' which will make the engine automatically create and assign an appropriate being corpse. You can also pass in ''false'' or leave this field blank to specify no corpse.
|danger |{{modarg|integer}}|This is a [[Monster Generation|monster generation]] parameter.
|weight |{{modarg|integer}}|This is a [[Monster Generation|monster generation]] parameter.
|xp |{{modarg|integer}}|This is the being's expvalue. By default, it is <font-family: monospace>3xD2+20, where D is the being's danger value (above).
|bulk |{{modarg|integer}}|This parameter is unused. The default is 100.
|flags |{{modarg|Being Flag}}|This parameter is an array of being flags which will be used by all beings of this type by default.
|ai_type |{{modarg|AI}}|This determines the being's AI.
|res_bullet |{{modarg|integer}}|This is the being's resistance to bullet damage. The default is 0.
|res_melee |{{modarg|integer}}|This is the being's resistance to melee damage. The default is 0.
|res_shrapnel |{{modarg|integer}}|This is the being's resistance to shrapnel damage. The default is 0.
|res_acid |{{modarg|integer}}|This is the being's resistance to acid damage. The default is 0.
|res_fire |{{modarg|integer}}|This is the being's resistance to fire damage. The default is 0.
|res_plasma |{{modarg|integer}}|This is the being's resistance to plasma damage. The default is 0.
|desc |{{modarg|string}}|This is the description of the being displayed in the 'more information' view.
|kill_desc |{{modarg|string}}|If included this being will have a special kill description in the mortem.
|kill_desc_melee |{{modarg|string}}|If included this being will have a special melee kill description in the mortem.
|weapon |{{modarg|Item Blueprint}}|You can inline an item blueprint here and it will be registered for you. Items defined this way are always natural ranged weapons that never drop and have no ammo. It will even be equippedly automatically for you.
|OnCreate |{{modarg|function}}|
|OnAction |{{modarg|function}}|
|OnAttacked |{{modarg|function}}|
|OnDie |{{modarg|function}}|
|OnDieCheck |{{modarg|function}}|
|OnPickupItem |{{modarg|function}}|
|}}
}}

== Engine Hooks ==

{{drltable|Being Hooks|2|{{Table2Col
|es=background: #333;
|c1=font-family:monospace; text-align:right; vertical-align:top; padding:0px 2px;
|c2=padding:0px 2px;
|{{modarg|void}} |[[#being_OnCreate |OnCreate]] ({{modarg|being}} self)
|{{modarg|void}} |[[#being_OnAction |OnAction]] ({{modarg|being}} self)
|{{modarg|void}} |[[#being_OnAttacked |OnAttacked]] ({{modarg|being}} self)
|{{modarg|void}} |[[#being_OnDie |OnDie]] ({{modarg|being}} self, {{modarg|boolean}} overkill)
|{{modarg|boolean}}|[[#being_OnDieCheck |OnDieCheck]] ({{modarg|being}} self, {{modarg|boolean}} overkill)
|{{modarg|void}} |[[#being_OnPickupItem|OnPickupItem]] ({{modarg|being}} self, {{modarg|item}} item)
|}}
}}

{{Anchor|being_OnCreate}}
'''OnCreate'''({{modarg|being}} self)
:This is called when the being is created. Usually inventory and equipment get added here but many more adjustments are possible.
----
{{Anchor|being_OnAction}}
'''OnAction'''({{modarg|being}} self)
:This is called at the beginning of a being's turn. It is never called more than once per tick and the player, sadly, does not use this.
----
{{Anchor|being_OnAttacked}}
'''OnAttacked'''({{modarg|being}} self)
:This is called when a being is attacked and is usually only used by being AIs. It is not possible to determine the attacker.
----
{{Anchor|being_OnDie}}
'''OnDie'''({{modarg|being}} self, {{modarg|boolean}} overkill)
:This is called when the being dies. ''overkill'' is true if the being was gibbed.
----
{{Anchor|being_OnDieCheck}}
'''OnDieCheck'''({{modarg|being}} self, {{modarg|boolean}} overkill) → '''boolean'''
:This is called right before a being would normally die. Returning '''false''' will prevent the death, giving the being a minimum of 1 hp. ''overkill'' is true if the being was gibbed.
----
{{Anchor|being_OnPickupItem}}
'''OnPickupItem'''({{modarg|being}} self, {{modarg|item}} item)
:This is called when a being picks up an item. It is only used in DRL for statistical purposes.

Manual:sound.lua

2025-08-11T12:34:56Z

Epyon:

This file allows you to manage the sounds that are played in DRL.
Sounds are organized by object, and each object has multiple sounds that can be changed depending on the action (for instance, one sound for an enemy taking damage, another for it dying).
In many cases, sounds for similar objects (like fuel barrels and acid barrels) can be changed separately.
The default sounds and the descriptions of each entry in the sound.lua (or soundhq.lua for the high quality version) are in the tables below, in the order they appear in the file (except for the being sounds, which are moved after everything else).

== Item Default Sounds ==

{|
! scope="col" align="left" cell-padding="1ex" | Object
! scope="col" align="left" cell-padding="1ex" | Action
! scope="col" align="left" cell-padding="1ex" | Description
! scope="col" align="left" cell-padding="1ex" | Default Sound (LQ)
! scope="col" align="left" cell-padding="1ex" | Default Sound (HQ)
|-style="background:#333"
|menu
|change
|Sound played when highlighting a menu option.
|
|wavhq/dspstop.wav
|-style="background:#333"
|
|pick
|Sound played when selecting a menu option (clicking on/pressing enter).
|
|wavhq/dspistol.wav
|-style="background:#333"
|
|cancel
|Sound played when backing up in menus (escape).
|
|wavhq/dsswtchx.wav
|-
|barrel (Barrel of Fuel)
|move
|Sound played when a fuel barrel is successfully pushed.
|
|wavhq/dsstnmov.wav
|-
|
|movefail
|Sound played when attempting to push a fuel barrel into a blocked space.
|
|wavhq/dsnoway.wav
|-
|
|explode
|Sound played when a fuel barrel blows up.
|
|wavhq/dsbarexp.wav
|-style="background:#333"
|barrela (Barrel of Acid)
|move
|Sound played when an acid barrel is successfully pushed.
|
|wavhq/dsstdmov.wav
|-style="background:#333"
|
|movefail
|Sound played when attempting to push an acid barrel into a blocked space.
|
|wavhq/dsnoway.wav
|-style="background:#333"
|
|explode
|Sound played when an acid barrel blows up.
|
|wavhq/dsbarexp.wav
|-
|barreln (Barrel of Napalm)
|move
|Sound played when a napalm barrel is successfully pushed.
|
|wavhq/dsstdmov.wav
|-
|
|movefail
|Sound played when attempting to push a napalm barrel into a blocked space.
|
|wavhq/dsnoway.wav
|-
|
|explode
|Sound played when a napalm barrel blows up.
|
|wavhq/dsbarexp.wav
|-style="background:#333"
|door
|open
|Sound played when a door is opened.
|
|wavhq/dsbdopn.wav
|-style="background:#333"
|
|close
|Sound played when a door is closed.
|
|wavhq/dsbdcls.wav
|-
|teleport
|use
|Sound played when the player or an enemy steps on a teleporter.
|
|wavhq/dstelept.wav
|-style="background:#333"
|lever
|use
|Sound played when a lever is pulled.
|
|wavhq/dsswtchn.wav
|-
|gib
|
|Sound played when an enemy is gibbed (overkilled).
|
|wavhq/dsslop.wav
|-style="background:#333"
|shglobe (Small Health Globe)
|powerup
|Sound played when a Small Health Globe is picked up.
|
|wavhq/dsgetpow.wav
|-
|lhglobe (Large Health Globe)
|powerup
|Sound played when a Large Health Globe is picked up.
|
|wavhq/dsgetpow.wav
|-style="background:#333"
|scglobe (Supercharge Globe)
|powerup
|Sound played when a Supercharge Globe is picked up.
|
|wavhq/dsgetpow.wav
|-
|iglobe (Invulnerability Globe)
|powerup
|Sound played when an Invulnerability Globe is picked up.
|
|wavhq/dsgetpow.wav
|-style="background:#333"
|ashard (Armor Shard)
|powerup
|Sound played when an Armor Shard is picked up.
|
|wavhq/dsgetpow.wav
|-
|bpack (Berserk Pack)
|powerup
|Sound played when a Berserk Pack is picked up.
|
|wavhq/dsgetpow.wav
|-style="background:#333"
|map (Computer Map)
|powerup
|Sound played when a Computer Map is picked up.
|
|wavhq/dsgetpow.wav
|-
|backpack
|powerup
|Sound played when a Backpack! is picked up.
|
|wavhq/dsgetpow.wav
|-style="background:#333"
|smed (Small Med-Pack)
|pickup
|Sound played when a Small Med-Pack is picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|
|use
|Sound played when a Small Med-Pack is used.
|
|wavhq/dsgetpow.wav
|-
|lmed (Large Med-Pack)
|pickup
|Sound played when a Large Med-Pack is picked up.
|
|wavhq/dsitemup.wav
|-
|
|use
|Sound played when a Large Med-Pack is used.
|
|wavhq/dsgetpow.wav
|-style="background:#333"
|phase (Phase Device)
|pickup
|Sound played when a Phase Device is picked up.
|
|wavhq/dsitemup.wav
|-
|hphase (Homing Phase Device)
|pickup
|Sound played when a Homing Phase Device is picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|epack (Environmental Pack)
|pickup
|Sound played when an Enviromental Pack is picked up.
|
|wavhq/dsitemup.wav
|-
|nuke (Thermonuclear Bomb)
|pickup
|Sound played when a Thermonuclear Bomb is picked up.
|
|wavhq/dsitemup.wav
|-
|
|explode
|Sound played when a Thermonuclear Bomb detonates.
|
|wavhq/dsfirxpl.wav
|-style="background:#333"
|mod_power
|pickup
|Sound played when a Power Mod Pack is picked up.
|
|wavhq/dsitemup.wav
|-
|mod_agility
|pickup
|Sound played when an Agility Mod Pack is picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|mod_bulk
|pickup
|Sound played when a Bulk Mod Pack is picked up.
|
|wavhq/dsitemup.wav
|-
|mod_tech
|pickup
|Sound played when a Technical Mod Pack is picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|garmor (Green Armor)
|pickup
|Sound played when Green Armor is picked up.
|
|wavhq/dsitemup.wav
|-
|barmor (Blue Armor)
|pickup
|Sound played when Blue Armor is picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|rarmor (Red Armor)
|pickup
|Sound played when Red Armor is picked up.
|
|wavhq/dsitemup.wav
|-
|sboots (Steel Boots)
|pickup
|Sound played when Steel Boots are picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|pboots (Protective Boots)
|pickup
|Sound played when Protective Boots are picked up.
|
|wavhq/dsitemup.wav
|-
|psboots (Plasteel Boots)
|pickup
|Sound played when Plasteel Boots are picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|ammo (10mm Ammo)
|pickup
|Sound played when 10mm ammo is picked up.
|
|wavhq/dsitemup.wav
|-
|shell (Shotgun Shell)
|pickup
|Sound played when Shotgun Shells are picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|rocket
|pickup
|Sound played when Rockets are picked up.
|
|wavhq/dsitemup.wav
|-
|cell (Power Cell)
|pickup
|Sound played when Power Cells are picked up.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|knife
|attack
|Sound played when attacking with a Combat Knife.
|
|wavhq/dspunch.wav
|-style="background:#333"
|
|pickup
|Sound played when a Combat Knife is picked up.
|
|wavhq/dswpnup.wav
|-
|pistol
|fire
|Sound played when a pistol is fired.
|
|wavhq/dspistol.wav
|-
|
|pickup
|Sound played when a pistol is picked up.
|
|wavhq/dswpnup.wav
|-
|
|reload
|Sound played when reloading a pistol.
|
|wavhq/dswpnup.wav
|-style="background:#333"
|shotgun
|fire
|Sound played when a shotgun is fired.
|
|wavhq/dsshotgn.wav
|-style="background:#333"
|
|pickup
|Sound played when a shotgun is picked up.
|
|wavhq/dswpnup.wav
|-style="background:#333"
|
|reload
|Sound played when reloading a shotgun.
|
|wavhq/dswpnup.wav
|-
|ashotgun (Combat Shotgun)
|fire
|Sound played when a combat shotgun is fired.
|
|wavhq/dsshotgn.wav
|-
|
|pickup
|Sound played when a combat shotgun is picked up.
|
|wavhq/dswpnup.wav
|-
|
|reload
|Sound played when reloading a combat shotgun.
|
|wavhq/dswpnup.wav
|-
|
|pump
|Sound played when pumping a shell into the combat shotgun.
|
|wavhq/dssgcock.wav
|-style="background:#333"
|dshotgun (Double Shotgun)
|fire
|Sound played when a double shotgun is fired.
|
|wavhq/dsdshtgn.wav
|-style="background:#333"
|
|pickup
|Sound played when a double shotgun is picked up.
|
|wavhq/dswpnup.wav
|-style="background:#333"
|
|reload
|Sound played when reloading a double shotgun.
|
|wavhq/dswpnup.wav
|-
|chaingun
|fire
|Sound played when a chaingun is fired. The sound plays for each shot.
|
|wavhq/dspistol.wav
|-
|
|pickup
|Sound played when a chaingun is picked up.
|
|wavhq/dswpnup.wav
|-
|
|reload
|Sound played when reloading a chaingun.
|
|wavhq/dswpnup.wav
|-style="background:#333"
|plasma (Plasma Rifle)
|fire
|Sound played when a plasma rifle is fired. The sound plays for each shot.
|
|wavhq/dsplasma.wav
|-style="background:#333"
|
|pickup
|Sound played when a plasma rifle is picked up.
|
|wavhq/dswpnup.wav
|-style="background:#333"
|
|reload
|Sound played when reloading a plasma rifle.
|
|wavhq/dswpnup.wav
|-
|bazooka (Rocket Launcher)
|fire
|Sound played when a rocket launcher is fired.
|
|wavhq/dslaunc.wav
|-
|
|pickup
|Sound played when a rocket launcher is picked up.
|
|wavhq/dswpnup.wav
|-
|
|reload
|Sound played when reloading a rocket launcher.
|
|wavhq/dswpnup.wav
|-
|
|explode
|Sound played when the fired rocket explodes.
|
|wavhq/dsrxplod.wav
|-style="background:#333"
|chainsaw
|attack
|Sound played when attacking with a chainsaw.
|
|wavhq/dssawhit.wav
|-style="background:#333"
|
|pickup
|Sound played when a chainsaw is picked up.
|
|wavhq/dswpnup.wav
|-
|bfg9000
|fire
|Sound played when a BFG 9000 is fired.
|
|wavhq/dsbfg.wav
|-
|
|pickup
|Sound played when a BFG 9000 is picked up.
|
|wavhq/dswpnup.wav
|-
|
|reload
|Sound played when reloading a BFG 9000.
|
|wavhq/dswpnup.wav
|-
|
|explode
|Sound played when the BFG shot hits something.
|
|wavhq/dsrxplod.wav
|-style="background:#333"
|spear (Longinus Spear)
|attack
|Sound played when attacking with the Longinus Spear.
|
|wavhq/dsgetpow.wav
|-style="background:#333"
|
|pickup
|Sound played when the Longinus Spear is picked up.
|
|wavhq/dswpnup.wav
|-style="background:#333"
|
|explode
|Sound played for the explosions when using the spear's alt-fire.
|
|wavhq/dsrxplod.wav
|-
|melee
|
|Default sound for melee actions.
|
|wavhq/dsclaw.wav
|-style="background:#333"
|reload
|
|Default sound for reloading.
|
|wavhq/dswpnup.wav
|-
|pickup
|
|Default sound for picking up items.
|
|wavhq/dsitemup.wav
|-style="background:#333"
|fire
|
|Default sound for firing a weapon.
|
|wavhq/dsfirsht.wav
|-
|explode
|
|Default sound for explosions.
|
|wavhq/dsfirxpl.wav
|-style="background:#333"
|powerup
|
|Default sound for picking up powerups.
|
|wavhq/dsgetpow.wav
|}

 

== Being Action Descriptions ==

{|
! scope="col" align="left" cell-padding="1ex" | Action
! scope="col" align="left" cell-padding="1ex" | Description
|-style="background:#333"
|die
|The sound that plays when this type of being dies.
|-
|act
|The sound that plays randomly whenever this type of being does something.
|-style="background:#333"
|hit
|The sound that plays when this type of being is hurt. For the player, this plays when the player walks over acid or lava.
|-
|melee
|The sound that plays when this type of being performs a melee attack. For the player, this is for an empty handed fist attack.
|-style="background:#333"
|hoof
|The sound that plays each time the being moves. This sound is typically only used for boss enemies.
|-
|phase
|The sound that plays when this type of being uses a phase device or homing phase device.
|-style="background:#333"
|fire
|The sound that plays when this type of being uses their natural ranged weapon.
|-
|explode
|The sound that plays when this type of being's natural ranged attack hits something and has an explosion radius (even if it's only 1).
|}

== Being Default Sounds ==

{|
! scope="col" align="left" cell-padding="1ex" | Being
! scope="col" align="left" cell-padding="1ex" | Action
! scope="col" align="left" cell-padding="1ex" | Default Sound (LQ)
! scope="col" align="left" cell-padding="1ex" | Default Sound (HQ)
|-style="background:#333"
|solider (Player)
|die
|
|wavhq/dspldeth.wav
|-style="background:#333"
|
|hit
|
|wavhq/dsplpain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dspunch.wav
|-style="background:#333"
|
|phase
|
|wavhq/dstelept.wav
|-
|former (Former Human)
|die
|
|wavhq/dspodth1.wav
|-
|
|act
|
|wavhq/dsposact.wav
|-
|
|hit
|
|wavhq/dspopain.wav
|-
|
|melee
|
|wavhq/dspunch.wav
|-style="background:#333"
|sergeant (Former Sergeant)
|die
|
|wavhq/dspodth2.wav
|-style="background:#333"
|
|act
|
|wavhq/dsposact.wav
|-style="background:#333"
|
|hit
|
|wavhq/dspopain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dspunch.wav
|-
|captain (Former Captain)
|die
|
|wavhq/dspodth2.wav
|-
|
|act
|
|wavhq/dsposact.wav
|-
|
|hit
|
|wavhq/dspopain.wav
|-
|
|melee
|
|wavhq/dspunch.wav
|-style="background:#333"
|commando (Former Commando)
|die
|
|wavhq/dspodth3.wav
|-style="background:#333"
|
|act
|
|wavhq/dsposact.wav
|-style="background:#333"
|
|hit
|
|wavhq/dspopain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dspunch.wav
|-
|imp
|die
|
|wavhq/dsbgdth1.wav
|-
|
|act
|
|wavhq/dsbgact.wav
|-
|
|hit
|
|wavhq/dspopain.wav
|-
|
|melee
|
|wavhq/dsclaw.wav
|-
|
|fire
|
|wavhq/dsfirsht.wav
|-
|
|explode
|
|wavhq/dsfirxpl.wav
|-style="background:#333"
|lostsoul
|die
|
|wavhq/dsfirxpl.wav
|-style="background:#333"
|
|act
|
|wavhq/dssklatk.wav
|-style="background:#333"
|
|hit
|
|wavhq/dsdmpain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dssklatk.wav
|-
|pain (Pain Elemental)
|die
|
|wavhq/dspedth.wav
|-
|
|act
|
|wavhq/dspesit.wav
|-
|
|hit
|
|wavhq/dspepain.wav
|-
|
|melee
|
|wavhq/dsclaw.wav
|-style="background:#333"
|demon
|die
|
|wavhq/dssgtdth.wav
|-style="background:#333"
|
|act
|
|wavhq/dsdmact.wav
|-style="background:#333"
|
|hit
|
|wavhq/dsdmpain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dssgtatk.wav
|-
|cacodemon
|die
|
|wavhq/dscacdth.wav
|-
|
|act
|
|wavhq/dscacsit.wav
|-
|
|hit
|
|wavhq/dsdmpain.wav
|-
|
|melee
|
|wavhq/dsclaw.wav
|-
|
|fire
|
|wavhq/dsfirsht.wav
|-
|
|explode
|
|wavhq/dsfirxpl.wav
|-style="background:#333"
|arachno (Arachnotron)
|die
|
|wavhq/dsbspdth.wav
|-style="background:#333"
|
|act
|
|wavhq/dsbspact.wav
|-style="background:#333"
|
|hit
|
|wavhq/dsdmpain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dsclaw.wav
|-style="background:#333"
|
|fire
|
|wavhq/dsplasma.wav
|-
|knight (Hell Knight)
|die
|
|wavhq/dskntdth.wav
|-
|
|act
|
|wavhq/dskntsit.wav
|-
|
|hit
|
|wavhq/dsdmpain.wav
|-
|
|melee
|
|wavhq/dsclaw.wav
|-
|
|fire
|
|wavhq/dsfirsht.wav
|-
|
|explode
|
|wavhq/dsfirxpl.wav
|-style="background:#333"
|baron
|die
|
|wavhq/dsbrsdth.wav
|-style="background:#333"
|
|act
|
|wavhq/dsbrssit.wav
|-style="background:#333"
|
|hit
|
|wavhq/dsdmpain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dsclaw.wav
|-style="background:#333"
|
|fire
|
|wavhq/dsfirsht.wav
|-style="background:#333"
|
|explode
|
|wavhq/dsfirxpl.wav
|-
|mancubus
|die
|
|wavhq/dsmandth.wav
|-
|
|act
|
|wavhq/dsmansit.wav
|-
|
|hit
|
|wavhq/dsmnpain.wav
|-
|
|fire
|
|wavhq/dsfirsht.wav
|-
|
|explode
|
|wavhq/dsfirxpl.wav
|-style="background:#333"
|revenant
|die
|
|wavhq/dsskedth.wav
|-style="background:#333"
|
|act
|
|wavhq/dsskesit.wav
|-style="background:#333"
|
|hit
|
|wavhq/dspopain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dsskepch.wav
|-style="background:#333"
|
|fire
|
|wavhq/dsskeatk.wav
|-style="background:#333"
|
|explode
|
|wavhq/dsbarexp.wav
|-
|arch (Arch-Vile)
|die
|
|wavhq/dsvildth.wav
|-
|
|act
|
|wavhq/dsvilact.wav
|-
|
|hit
|
|wavhq/dsvipain.wav
|-
|
|fire
|
|wavhq/dsvilatk.wav
|-style="background:#333"
|bruiser
|die
|
|wavhq/dsbrsdth.wav
|-style="background:#333"
|
|act
|
|wavhq/dsbrssit.wav
|-style="background:#333"
|
|hit
|
|wavhq/dsdmpain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dsclaw.wav
|-style="background:#333"
|
|fire
|
|wavhq/dsfirsht.wav
|-style="background:#333"
|
|explode
|
|wavhq/dsfirxpl.wav
|-
|cyberdemon
|die
|
|wavhq/dscybdth.wav
|-
|
|act
|
|wavhq/dscybsit.wav
|-
|
|hit
|
|wavhq/dsdmpain.wav
|-
|
|hoof
|
|wavhq/dshoof.wav
|-style="background:#333"
|jc
|die
|
|wavhq/dspodth1.wav
|-style="background:#333"
|
|act
|
|wavhq/dsposact.wav
|-style="background:#333"
|
|hit
|
|wavhq/dspopain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dspunch.wav
|-
|angel (Angel of Death)
|die
|
|wavhq/dsbrsdth.wav
|-
|
|act
|
|wavhq/dsbrssit.wav
|-
|
|hit
|
|wavhq/dsbrssit.wav
|-
|
|melee
|
|wavhq/dsclaw.wav
|-
|
|hoof
|
|wavhq/dshoof.wav
|-style="background:#333"
|mastermind
|die
|
|wavhq/dsspidth.wav
|-style="background:#333"
|
|act
|
|wavhq/dsdmact.wav
|-style="background:#333"
|
|hit
|
|wavhq/dsdmpain.wav
|-style="background:#333"
|
|melee
|
|wavhq/dsclaw.wav
|-style="background:#333"
|
|hoof
|
|wavhq/dsmetal.wav
|}

Strategy:Shotgun

2025-08-11T12:34:43Z

Epyon:

''This article is about strategy for the [[shotgun]] itself as a [[weapons|weapon]], not the category of [[weapons]] colloquially known as [[Shotgun_Types|"shotguns"]]. For specific strategies for the individual [[weapons]], please see the associated entries under their [[Shotgun_Types|names]]. For [[Shotgun_Types|"shotguns"]] in general, please see [[Strategy:Shotgun_Types|Strategy:Shotgun Types]].''

{{infostrat switch}}
== '''Overview''' ==
=== '''Brief Summary''' ===
The [[shotgun]] is one of the first [[weapons]] that you can find in DRL, and it will help you survive the first few levels. Even without the appropriate build, it is still incredibly versatile for the beginning of the game; with the appropriate build, even further.

Aside from greatly out-damaging a [[pistol]] in close to mid-range, [[shotgun_shell|shotgun shells]] will definitely be plentiful for a while. Probably the most widely employed [[shotgun]] strategy is [[Strategy:Corner-shooting|"corner-shooting"]], which is literally aiming the [[shotgun]] around a corner that you're standing at, and hitting enemies on the other side. For a more in-depth explanation, please see [[Strategy:Corner-shooting]] (''TBA'').

The [[shotgun]] is also the first weapon you can get that is immediately capable of causing [[knock-back]]. When enough damage is dealt to an enemy in one shot (''anyone who is aware of the exact number required, please edit this entry accordingly''), and it survives, it will be pushed back a square. This can be used to give yourself breathing room, or even to kill an enemy by pushing them into [[Fluids|acid]] or [[Fluids|lava]].

== '''Examination''' ==
=== '''Advantages to using the shotgun''' ===
* Easy to find
* Tons of ammo early on
* Strong corner-shooting game
* Knock back capable
* Ammo used amongst nearly all shotguns; can move on to a different shotgun and keep your ammo
* [[Traits#Shottyman|Shottyman]], [[Traits#Shottyhead|Shottyhead]] and [[Traits#Army_of_the_Dead|Army of the Dead]] trait selections

=== '''Disadvantages to using the shotgun''' ===
* Drops off in effectiveness mid to late game
* Only holds one shell at a time; must be reloaded prior to firing each time
* Slow reload speed
* Poor base choice for an [[Assemblies|Assembly]] ([[Shotgun_Types|other types of shotgun]] serve this role better)
* Ineffective at extreme distances

Remember that [[shotgun_shell|shotgun shells]] fired from a regular, unmodified [[shotgun]] are considered [[Damage_type#shrapnel|Shrapnel]] for the purposes of [[Damage_type|damage type]] and [[resistance|resistances]].

Shotgun Types

2025-08-11T12:34:36Z

Epyon:

{{infostrat switch}}

''The following is a list of [[weapons]] that are [[Weapon_Families|classified]] as the [http://doom.chaosforge.org/wiki/Shotgun_Types shotgun type] for the purposes of [[Challenges]] and [[Traits]].''

== Types ==

=== '''Standard''' ===
*[[Shotgun]]
*[[Combat_shotgun|Combat shotgun]]
*[[Double_shotgun|Double shotgun]]

=== '''[[Assemblies|Assembly]]''' ===
*{{assembly link|Elephant gun}}
*{{assembly link|Tactical shotgun}}
*{{assembly link|Focused double shotgun}}

*{{SpAssembly link|Plasmatic shrapnel shotgun}}
*{{SpAssembly link|Plasmatic shrapnel combat shotgun}}
*{{SpAssembly link|Plasmatic shrapnel double shotgun}}
*{{SpAssembly link|Plasmatic shrapnel assault shotgun}}
*{{SpAssembly link|Plasmatic shrapnel plasma shotgun}}
*{{SpAssembly link|Plasmatic shrapnel super shotgun}}

*{{SpAssembly link|Nano-shrapnel shotgun}}
*{{SpAssembly link|Nano-shrapnel combat shotgun}}
*{{SpAssembly link|Nano-shrapnel double shotgun}}
*{{SpAssembly link|Nano-shrapnel assault shotgun}}
*{{SpAssembly link|Nano-shrapnel plasma shotgun}}
*{{SpAssembly link|Nano-shrapnel super shotgun}}

=== '''Special''' ===
* {{exotic link|Assault shotgun}}
* {{exotic link|Plasma shotgun}}
* {{exotic link|Super shotgun}}
* {{unique link|Jackhammer}}
* {{unique link|Frag Shotgun}}

== '''About Shotguns''' ==

=== '''Overview and Strategy''' ===
{{infostrat switch}}
The weapons from the shotgun family of DRL all have an cone-shaped area of effect attack that makes them unique and powerful. Shotguns never miss any target in their affected area, and they always do at least one damage to each target. The size of the shotgun blast varies from weapon to weapon. It is governed by two parameters: range and spread. The range of a shotgun determines how far the blast extends from the attacker, and the spread determines the half-width of the blast when it reaches it's furthest point.

Shotgun damage also diminishes over distance. Each shotgun has a reduction rating that determines what percentage of damage is taken off per tile of [[distance]]. This penalty is applied linearly, and it is applied even at point-blank range. Rounding is to the nearest integer (0.5 rounds to even).

DRL uses shotguns with four different Area of Effect types:

{| style="rules: cols; border: 2px solid darkred; border-spacing: 0; font-size: 90%; margin: 0.25em 0.5em;"
|colspan=11 style="background: darkred; color: yellow; font-size: 120%; text-align: center"|'''Shotgun Area of Effect Types'''
|-
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 1px 1px 0" width=100|'''Name'''
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 1px 1px 1px" width=50|'''Range'''
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 1px 1px 1px" width=50|'''Spread'''
|style="text-align: center; padding: 1ex; border: solid darkred; border-width: 0 0 1px 1px" width=50|'''Reduction'''
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 1px 1px 0 0"|normal
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|15
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|3
|style="text-align: center; border: solid darkred; border-width: 1px 0 0 1px"|7%
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 1px 1px 0 0"|focused
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|15
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|2
|style="text-align: center; border: solid darkred; border-width: 1px 0 0 1px"|5%
|- style="background: #333;"
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 1px 1px 0 0"|wide
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|8
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|3
|style="text-align: center; border: solid darkred; border-width: 1px 0 0 1px"|10%
|-
|style="text-align: left; padding-right: 1ex; border: solid darkred; border-width: 1px 1px 0 0"|plasma
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|15
|style="text-align: center; border: solid darkred; border-width: 1px 1px 0 1px"|3
|style="text-align: center; border: solid darkred; border-width: 1px 0 0 1px"|5%
|}

=== '''Area of Effect Details''' ===
{{Technical}}
To calculate a shotgun's area of effect, first a target square is calculated by extrapolating from the vector pointing at the manually targeted square. The true target will be a tile that is at the shotgun's maximum range with an approximately parallel vector. Then, for each tile in a (2 × spread + 1) side-length square around the target, the game traces out the path of a missile until it hits a wall. (Shotgun blasts go through enemies.) The missile paths are truncated if the distance along one of the axes becomes greater than the shotgun's range. For each tile that was traced out in at least one of the missile paths, damage is applied.

Weapon Families

2025-08-11T12:34:29Z

Epyon:

{{infostrat switch}}
''The following is a list of the various classifications of [[weapons]] that exist within DRL. To see all the weapons that belong to a particular [http://drl.chaosforge.org/wiki/Weapon_Families family], click on the appropriate link below.''

*[[Melee_Types|Melee Types]]
*[[Pistol_Types|Pistol Types]]
*[[Shotgun_Types|Shotgun Types]]
*[[Rapid-fire_Types|Rapid-fire Types]]
*[[Explosive_Types|Explosive Types]]
*[[Big__Gun_Types|Big Gun Types]]
*[[Misc_Types|Miscellaneous Types]]

Strategy:Cyberdemon

2025-08-11T12:34:21Z

Epyon:

{{infostrat switch}}

==Basic Strategy==

The Cyberdemon is a particularly bulky boss who will greet you at the end of Deimos (Deimos 8: The Tower of Babel) and occasionally in the final levels of Ao100. He packs a melee attack that does 1d3 + 15 damage and a ranged rocket attack that does 6d6 damage. He is unique from most other DRL enemies in two ways—first, he knows where you are and he will get into range and attack unwaveringly. Second, he has a longer sight range than you do (unless you have MCe). Indeed, his large sight range makes it difficult to outspeed him, even though he only has 110% speed.

There are three basic strategies often employed to take down the Cyberdemon.

*Gather a large amount of [[dodge]]. Two levels in Hellrunner and donning [[Tactical armor]] is an example of having high dodge. This will ensure that most of the Cyberdemon's attacks will miss if the player dodges correctly. An even more surefire way to handle him using this method is to take the Dodgemaster trait. This will guarantee that his rockets will never score a direct hit. Be careful, though; the level is a bit cramped, considering the pillars. It is easy to get hit by the splash from the explosion. Also note that he will slowly close to melee range over the course of his attacks. You may need to retreat if you're in danger of being melee'd. This method is advised for low-DPS builds that rely on speed (i.e., MSh).

*Build a high-DPS character. Some characters do so much damage that they can kill the Cyberdemon before he is able to fire more than 4 or 5 rockets. Even if you get hit by 2 or 3 of them, that damage is easily mitigated by armor and medkits. An example of a typical high-DPS build might be a focus on rapid-fire, with traits such as SoB and TH. Dual pistols often fall into this category as well. Outside of weapon-restricted builds, rocket launchers and BFGs perform well against him. Remember to time your shots so that you can still get a dodge off before he fires! Fire speed helps a lot here.

*Melee him. The Cyberdemon doesn't do as much damage in melee as getting hit directly by a rocket. Even a non-melee build is able to make good use of the guaranteed chainsaw (from [[The Chained Court]]) to attack him, provided an armor with high melee resistance and/or armor value has been found. A red armor is doable with a melee build; for a non-melee build, it is advised to have something a little beefier.

==Tips==

*Use the pillars to buffer yourself when you first enter the level. You won't know exactly where the Cyberdemon is, so stay on the stairs-side of a pillar and wait for him to fire a rocket at you. The resulting chunk blown out of the pillar will allow you to pinpoint his location, so you can get into the fire->dodge->fire groove without giving him a free hit.

*The Cyberdemon is immune to acid and lava pools, so don't bother using the Acid Spitter or Napalm Launcher against him.

*Although the Cyberdemon is immune to knockback in The Tower of Babel, he can be knocked back in Ao100.

*The Cyberdemon will fire a rocket and some [[time]] (1.0s?) will pass before he reloads his rocket launcher. A message will be displayed to let the player know when the Cyberdemon has reloaded. This marks roughly the halfway point to when he will fire again. Take it as your cue to dodge. Check your firing speed (with the @ key) to get a rough idea of how many times you can attack before you need to dodge.

*When you reach Deimos 7, try to clear the level without using the powerups. If you're lucky, you will get an invincibility or berserk near the stairs, which will make the fight trivial. (You remembered to take the chainsaw with you, right?)

*The Cyberdemon will fire at you as long as you're in what would be his sight range; even if you're behind a pillar. This means that a character with sufficiently high movement speed can fire off some shots, duck behind a pillar to block the attack, then pop back out and fire off some more shots. Don't count on the pillar to take more than 3 or 4 hits for you, though.

[[User:Ashannar|Ashannar]] 11:34, 23 March 2013 (CET)
:"''Although the Cyberdemon is immune to knockback in The Tower of Babel, he can be knocked back in Ao100.''"

:I do not know if this was true in prior versions, but I can confirm this is not true as of 0.9.9.7, Cyberdemons in that version are still very much immune to knockback regardless of where they're encountered. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 02:37, 6 August 2023 (UTC)

Modding:Color (0.9.9.7)

2025-08-11T12:34:09Z

Epyon:

In console mode all game tiles are associated with a particular color. Choosing a good color scheme is an important part of modding, but the choice is limited--only 16 colors exist in the standard [http://en.wikipedia.org/wiki/VGA-compatible_text_mode VGA compatible console] which, when combined into foreground and background, results in only 256 possible combinations. There are some special engine colors as well to further complicate matters.

In graphics mode all game tiles are associated with a particular sprite. The sprites obviously support more than 16 colors. They can also be further manipulated by engine effects, color overlays (both additive and subtractive), and outlines.

==Console Colors ==
=== Color Definitions ===
{{Template:Color}}

=== Special Colors ===
{{Template:Special_Color}}

=== Background Colors ===
DRL uses 4 bit color. In 4 bit color consoles the lower four bits correspond to the foreground color while the upper four bits correspond to the background color (usually). When you assign a color using the color constants above the upper bits will equal zero, which is the default background color--black. You can change this by explicitly assigning the upper 4 bits a value using code similar to the following:
<source lang="lua">color = LIGHTGRAY + (RED * 16)</source>
The above statement will display light gray text over a red background. Officially this is unsupported. Unofficially it is used often enough that support for it will most likely continue. There is a caveat though--some combinations are used by the [[#Special Colors|special colors]] above and thus cannot be used for regular items.

=== Notes and Advice ===
* The [[Manual:color.lua|color.lua]] script can be used by players to customize tiles.
** Many objects have a color_id property that can be used to prevent unscrupulous players from distinguishing between items such as levers by color.
* Console colors are not always consistent. Brown in particular can vary a lot and more closely mimics orange in some environments.
* Dark Blue is hard to see on a black background and should be used sparingly, especially with beings who can be frustrating when hard to see.
* Background colors should be used sparingly, if at all. The clear divides break immersion.
* Be aware of common roguelike coloring customs, especially those used by NetHack and (obviously) DRL.

== Color Sets ==
A color set in DRL is an array in the form of '''{ ''red'', ''green'', ''blue'', ''alpha'' }'''. Each value is a decimal between 0.0 and 1.0, though at present ''alpha'' is not used.

=== Coscolor ===
A coscolor is an '''additive''' modifier found on [[Modding:cell|cells]], [[Modding:being|beings]], [[Modding:item|items]], and [[Modding:missile|missiles]]. To have any effect a sprite must have a grayscale color map associated with it. Currently only a small number of sprites, such as mod packs, do.

=== Overlay ===
An overlay is a '''subtractive''' modifier found on [[Modding:being|beings]] and [[Modding:item|items]]. It will remove colors from sprites--the overlay '''{ ''1.0'', ''0.0'', ''0.0'', ''1.0'' }''' for instance would turn a sprite completely red. This option is mostly intended for creating placeholder sprites quickly and is rather limited. Status effects react to overlays in unusual ways and since adding color or changing hues is impossible it is difficult to get a good end result.

=== Glow ===
A glow is an '''additive''' modifier found on [[Modding:being|beings]] and [[Modding:item|items]]. Unlike the other graphical modifiers this directly adds a color to a sprite based on its outline (minus its shadow). The effect is a smooth and pleasant glow effect which can be used to great effect without worrying about side effects.

Modding:level object (0.9.9.7)

2025-08-11T12:33:48Z

Epyon:

The ''level'' object in DRL pulls triple duty: it stores and publishes properties relevant to the current level, it provides access to the [[Modding:level API|level API]] which includes procedures from Lua, DRL, and valkyrie, and through clever use of metatables it exposes the light, cell type, and HP arrays stored in the valkyrie ''LuaMapNode'' object. Here we focus on its representation as an object.

== Properties ==
{{drltable|Properties |3|{{Table3Col
|es=background: #333;
|c1=font-family:monospace; text-align:right; vertical-align:top; padding:0px 2px;
|c2=padding:0px 2px;
|c3=padding:0px 2px;
|status |{{modarg|word}} |This is for use by level designers and is preserved after a level is exited.
|data |{{modarg|anything}}|This is for use by level designers.
|name |{{modarg|string}} |This is the level name as displayed on the HUD.
|name_number |{{modarg|word}} |This controls the "LevX" part of the level name. If zero, it won't be displayed.
|danger_level |{{modarg|word}} |Level generation parameter that usually corresponds to depth.
|style |{{modarg|byte}} |The style (tile set) used by the level generation functions.
|id |{{modarg|string}} |The id of the current level
|special_exit |{{modarg|string}} |The id of the level that red stairs lead to
|}}
}}

level.data and level.status are used to store information during (in the case of data) and after (in the case of status) level execution. Although one can work around the need for either it is considered good practice to use these two fields. level.status is limited; it can only store a single word value and it is intended for storing the current state of a level--just entered, reached the halfway mark, finished, etc. It is preserved so you may use this information to influence future levels. level.data is meant to track the current level as it exists now, should a word value be insufficient. Careful use of level.data and chaining/[[Modding:level blueprint#level_onenteritem|OnEnter]] hooks can also modify level behaviour in special modes (such as challenge modes) while keeping the level itself ignorant of the concept of a challenge.

== Array Properties ==
{{drltable|Array Properties|3|{{Table3Col
|es=background: #333;
|c1=font-family:monospace; text-align:right; vertical-align:top; padding:0px 2px;
|c2=padding:0px 2px;
|c3=padding:0px 2px;
|flags[{{modarg|Level Flag}}]|{{modarg|boolean}}|Get or set level flags
|light[{{modarg|coord}}][{{modarg|Light Flag}}]|{{modarg|boolean}}|Get or set cell light flags*
|map[{{modarg|coord}}]|{{modarg|cell}}|Get or set cells on a map by cell id
|hp[{{modarg|coord}}]|{{modarg|byte}}|Get or set cell HP values
|}}
}}

* As a special extension you can pass an area to level.light when setting flags and the procedure will automatically iterate through every coord

Modding:generator API

2025-08-11T12:33:46Z

Epyon:

Modding:Sprites (0.9.9.7)

2025-08-11T12:33:17Z

Epyon:

A sprite in DRL is comprised of three distinct components: a color spritesheet, a grayscale version for [[Modding:Color#Color Sets|coloring]], and a black and white version for outlining sans shadow. Very few sprites make use of all three.

As of this version it is not possible for modders to directly edit sprites so there is no need to go into further detail. What is needed is a list of sprites that modders can use:

== Player Sprites ==
Player sprites have colorable armor and change based on wielded weapon. They are good sprites to use for player-like beings provided you manually handle the corpse.

{{drltable|Player Sprites|1|{{Table1Col
|es=background: #333;
|c1=vertical-align:top; padding:0px 2px;
|SPRITE_PLAYER
|SPRITE_PLAYER_KNIFE
|SPRITE_PLAYER_CHAINSAW
|SPRITE_PLAYER_PISTOL
|SPRITE_PLAYER_SHOTGUN
|SPRITE_PLAYER_CSHOTGUN
|SPRITE_PLAYER_DSHOTGUN
|SPRITE_PLAYER_CHAINGUN
|SPRITE_PLAYER_BAZOOKA
|SPRITE_PLAYER_PLASMA
|SPRITE_PLAYER_BFG9000
|SPRITE_PLAYER_SPEAR
|SPRITE_PLAYER_STAFF
|SPRITE_PLAYER_CLEAVER
|SPRITE_PLAYER_DRAGON
|}}
}}

== Item Sprites ==
Armor, non-steel boots, mod packs, skulls, and phase devices are colorable. Choice is otherwise limited.

{{drltable|Item Sprites|1|{{Table1Col
|es=background: #333;
|c1=vertical-align:top; padding:0px 2px;
|SPRITE_KNIFE
|SPRITE_CHAINSAW
|SPRITE_PISTOL
|SPRITE_SHOTGUN
|SPRITE_CSHOTGUN
|SPRITE_DSHOTGUN
|SPRITE_CHAINGUN
|SPRITE_BAZOOKA
|SPRITE_PLASMA
|SPRITE_BFG9000
|SPRITE_SPEAR
|SPRITE_BFG10K
|SPRITE_STAFF
|SPRITE_CLEAVER
|SPRITE_DRAGON
|SPRITE_ARMOR
|SPRITE_AARMOR
|SPRITE_SBOOTS
|SPRITE_BOOTS
|SPRITE_MOD
|SPRITE_SKULL
|SPRITE_AMMO
|SPRITE_PAMMO
|SPRITE_SHELL
|SPRITE_PSHELL
|SPRITE_ROCKET
|SPRITE_PROCKET
|SPRITE_CELL
|SPRITE_PCELL
|SPRITE_PHASE
|SPRITE_BACKPACK
|SPRITE_ENVIRO
|SPRITE_HGLOBE
|SPRITE_LHGLOBE
|SPRITE_SUPERCHARGE
|SPRITE_INV
|SPRITE_MEGASPHERE
|SPRITE_SHARD
|SPRITE_MEDPACK
|SPRITE_LMEDPACK
|SPRITE_BERSERK
|SPRITE_MAP
|SPRITE_TMAP
|SPRITE_SCHEMATIC
|SPRITE_LIGHTAMP
|SPRITE_NUKE
|SPRITE_LAVAINV
|}}
}}

== Being Sprites ==
NoCorpse sprites can be accessed by adding 16 to the parent being, except in the case of oversized sprites--those just add 2. Lost Souls, pain elementals, and agony elementals do not have corpse sprites. Both the cyberdemon and mastermind are oversized sprites.

{{drltable|Being Sprites|1|{{Table1Col
|es=background: #333;
|c1=vertical-align:top; padding:0px 2px;
|SPRITE_FORMER
|SPRITE_SERGEANT
|SPRITE_CAPTAIN
|SPRITE_COMMANDO
|SPRITE_IMP
|SPRITE_DEMON
|SPRITE_LOSTSOUL
|SPRITE_CACODEMON
|SPRITE_PAIN
|SPRITE_KNIGHT
|SPRITE_BARON
|SPRITE_ARACHNO
|SPRITE_ARCHVILE
|SPRITE_REVENANT
|SPRITE_MANCUBUS
|SPRITE_BRUISER
|SPRITE_AGONY
|SPRITE_MASTER
|SPRITE_LAVAELEM
|SPRITE_ANGEL
|SPRITE_SHAMBLER
|SPRITE_JC
|SPRITE_CYBERDEMON
|SPRITE_MASTERMIND
|}}
}}

== Cell Sprites ==
Many cells have multiple sprite variants that, if you want to access separately will take some trial and error. Fluids are in a 2x2 square, walls are in a 3x15 vertical rectangle, floors are a 16x1 line, and most other multi-sprite cells are adjacent.
Stairs, cave walls, brick walls, and the colored boxes are colorable.

{{drltable|Cell Sprites|1|{{Table1Col
|es=background: #333;
|c1=vertical-align:top; padding:0px 2px;
|SPRITE_DOOR
|SPRITE_OPENDOOR
|SPRITE_HELLDOOR
|SPRITE_HELLOPENDOOR
|SPRITE_BARREL
|SPRITE_LAVABARREL
|SPRITE_ACIDBARREL
|SPRITE_TREE
|SPRITE_GRAYSTAIRS
|SPRITE_STAIRS
|SPRITE_REDSTAIRS
|SPRITE_PORTAL
|SPRITE_TELEPORT
|SPRITE_LEVER
|SPRITE_BLOOD
|SPRITE_BLOODPOOL
|SPRITE_CORPSE
|SPRITE_WALLBLOOD
|SPRITE_FLOOR
|SPRITE_CAVEFLOOR
|SPRITE_HELLFLOOR
|SPRITE_WALL
|SPRITE_CAVEWALL
|SPRITE_BRICKWALL
|SPRITE_TECHWALL
|SPRITE_BOSSWALL
|SPRITE_WATER
|SPRITE_ACID
|SPRITE_LAVA
|SPRITE_BRIDGE
|SPRITE_YBOX
|SPRITE_WBOX
|SPRITE_YBOXC
|SPRITE_WBOXC
|}}
}}

== Missile Sprites ==
There are only a few missile sprites. Color shots and acid shots are colorable.
{{drltable|Missile Sprites|1|{{Table1Col
|es=background: #333;
|c1=vertical-align:top; padding:0px 2px;
|SPRITE_SHOT
|SPRITE_CSHOT
|SPRITE_BLAST
|SPRITE_ROCKETSHOT
|SPRITE_EXPLOSION
|SPRITE_PLASMASHOT
|SPRITE_BFGSHOT
|SPRITE_FIREBALL
|SPRITE_PLASMABALL
|SPRITE_ACIDSHOT
|}}
}}

== Miscellaneous Sprites ==
These last few sprites are special purpose graphics that may still be of use. The arrow, select, and mark sprites are colorable.
{{drltable|Misc Sprites|1|{{Table1Col
|es=background: #333;
|c1=vertical-align:top; padding:0px 2px;
|SPRITE_ARROW
|SPRITE_SELECT
|SPRITE_MARK
|SPRITE_GRID
|}}
}}

Strategy:Dragonslayer

2025-08-11T12:33:12Z

Epyon:

{{infostrat switch}}

=== 0.9.9.7 ===
The Dragonslayer, perhaps the most elusive weapon, is the hardest weapon to use if you don't know how to obtain it.

A few of the DRL gurus know how to drop both the Berserker Armor and the Dragonslayer every time in a run, but the rest of us are kind of clueless on how to do such a feat.

However, here are some guidelines:

* The Dragonslayer and the Berserker armor are related, but one can actually use the Dragonslayer without the Berserker Armor. The Dragonslayer is required to WEAR the Berserker armor, not vice versa.

* The Dragonslayer will drop in the Unholy Cathedral in place of Azarel's Sycthe when played on Nightmare! (under some extra conditions, possibly on a damageless run?). Unfortunately, no one except those who know exactly how to have been able to pick it up and use it.

* The Berserker Armor can only be worn if you are wielding the Dragonslayer.

Not much has been found out about the Dragonslayer. If someone finds out a way to pick up the Dragonslayer reliably, we do not encourage you to post how on this wiki.

[[User:GinDiamond|GinDiamond]] ([[User talk:GinDiamond|talk]]) 21:57, 14 October 2013 (CEST)

Strategy:Cerberus armor

2025-08-11T12:33:04Z

Epyon:

{{infostrat switch}}

==Overview==
The Cerberus armor may have no [[protection]] value, but it carries a massive 70% [[resistance]] against [[fire]] and [[acid]], and a still tremendous 50% resistance against [[plasma]]. All seasoned DRL players come to learn that resistances are a lot more potent in damage reduction than sheer protection, so don't balk at the Cerberus armor's 0 protection value. An [[Arch-vile]]'s attack that deals a whopping 20 damage with no armor, enough to three shot any class with no [[Ironman]] investment, will deal a rather palatable 6 damage when you have this armor on, only 1 more than you will take with a [[Fireproof armor|Fireproof red armor]]. But then not only would you be tremendously protected against fire, a [[Baron of hell]] wouldn't deal anymore than 6 damage against you at maximum and would usually be dealing around 3-4 damage, when the acid attacks of Barons are notoriously difficult to get good armor to defend against. Then against [[Arachnotron]]s, you'll be only sustaining 1 or 2 damage per hit when you would need armor with a protection value of 6 or more to get this same effect, and against plasma-dealing enemies with single strong hits, you'll see a lot more appreciation with this armor than with just pure defense, due to armor having half protection against plasma, while resistances protect to their full value. So essentially with Cerberus Armor, you get an armor to well protect you against all the most dangerous enemies in the game that you would otherwise have a lot of difficulty in achieving.

The Cerberus Armor does come with a big drawback in its very heavy move [[speed]] and [[knockback]] penalties of -30%. Such a big movement penalty would be the main reason you definitely don't want to ditch all your other armor, as you should be keeping a primary armor for moving around with much better movement, while you reserve this armor for when you're going to get into a big open firefight or otherwise heavily risk walking into the range of one of the aforementioned enemies. Another big potential drawback is that this armor has no innate [[bullet]], [[shrapnel]], and [[melee]] resistance, with it inheriting those resistances from whatever armor you used to make this assembly. So if you used an armor without any of those resistances, your Cerberus armor will end up giving you no protection against them. Bullets don't matter much, but [[Former captain]]s can deal heavy damage when you have no sort of protection against them, and with no shrapnel defense you'll essentially be naked against [[Former sergeant]]s, whose shotguns are actually pretty threatening without armor, while obviously you will get really hurt if you go into an enemy's melee range without any melee defense. This flaw can be fixed though as covered in the next section.

==Which armor to use as a base==
When it comes to your standard armors, the [[Green armor]] would actually be the best choice, since it does carry a meager 15% bullet and shrapnel resistance, while the [[Blue armor]] and [[Red armor]] have no such resistance against them nor melee. Now this pittance of bullet and shrapnel resistance is barely any better than nothing, so you shouldn't be using a Green over the much better Exotic armor options and only use it as a last resort if you can't get a good Exotic armor, but in that case it's not going to make a real difference over using a Blue or Red armor, so you shouldn't lug a Green around long after they're obsolete just for this possibility.

When it comes to the Exotic armors, you can immediately cross off the [[Energy-shielded vest]], which covers the same set of resistances of the Cerberus armor and will work much better through conventional modding and other assemblies, and the [[Bullet-proof vest]], which only gives you a bullet resistance, while you'll rarely be threatened by bullets unless you somehow get surrounded by a swarm of [[Former captain]]s. [[Phaseshift armor]] provides a decent 30% resistance to bullet/shrapnel/melee, buts its wonderful movement bonus would be lost if you made it Cerberus, which is the most useful and defining part of that armor, so it's strongly advised to not use it for this assembly unless you really need especially strong armor and lack a better base. It is however worth pointing out that if you have the [[Phaseshift boots]] too, a Cerberus Phaseshift armor will still complete the Phaseshift set to provide you with the fluid immunity while the boots will keep your movement speed up, making this an effective combo when it is otherwise normally infeasible to have strong protection and fluid immunity without a severe sacrifice in movement speed. [[Medical armor]] provides an ok 20% resistance to the three physical types, which won't give you amazing Cerberus armor, but can be considered the baseline for acceptable Cerberus bases; if you don't have any of the upcoming superior armors, it'll make a decent Cerberus armor that will give you some protection against melee unlike the Green armor. Plus it will still have its ability to regenerate your health up to 25%, as rarely useful as it is.

[[Duelist armor]] provides a great 50% resistance against the physical trio, which will give you Cerberus armor that will make you take at least half damage against every damage source possible. However its +15% movement speed would be lost in the process, when the Duelist armor is one of the few armors in the game that improves your speed wearing it at base, while being decent armor at base on top of that. With that said, if you don't have the following three armors, and don't mind losing a movement-boosting armor, the Duelist armor will make a good base for this assembly, and the protection-for-movement tradeoff is a lot more favorable here than with the Phaseshift armor. The [[Ballistic vest]] also provides a 50% resistance against the physical trio, so it will result in the same exact Cerberus that the Duelist armor will result in. However with it having no movement bonus and having a lower armor rating than the Duelist armor, the Ballistic vest is the inferior armor by itself and would have nothing to offer you if you made Duelist Cerberus, while in the vice versa scenario the Duelist armor will still have its own use for movement while the Cerberus Ballistic will be just as effective. So in the scenario that you have both of them, turn the Ballistic vest Cerberus, and if you just have the Ballistic, it'll make a a great base while you'll lose nothing important by turning it Cerberus.

Now for the really good bases, there's [[Onyx armor]]. Onyx armor provides no resistances of its own, giving you a baseline Cerberus armor, but one other aspect of this assembly that gets carried over is durability. Normally this doesn't matter as you just get the typical 100% durability nearly every armor tends to have naturally. But since the Onyx armor has infinite durability, the Cerberus armor you make out of it will also have infinite durability without you needing to use an [[Onyx mod]], which not only gets you good indestructible armor without an Onyx mod (or saves you a valuable Onyx mod if you already had one), but also nets you infinite durability while saving a mod slot for your Cerberus armor to farther improve it (which will be covered in a bit). With Onyx Cerberus you will never have to worry about Barons and Arachnotrons destroying your armor again, and will have guaranteed strong protection against the VMR for the rest of your run no matter how badly you get beaten up. Then the absolute best choice for a base is [[Gothic armor]]; you get the great 50% physical resistances to the physical trio that Duelist armor and Ballistic vest give you, while the 200% durability is kept, so you get great protection against everything, on top of boosted durability. Additionally, using Gothic as a base means the Cerberus' set speed and knockback penalty are actually beneficial, as they're substantially better than the Gothic's, so making your Gothic armor Cerberus will give you a speed gain over twice as much as applying an [[Agility mod]] to the Gothic armor would. Making the Gothic Cerberus grants you a better result than every other possible base, while being an unquestionable improvement over the base armor itself. For one more note with the Gothic armor, if you also find the [[Gothic boots]], wearing both together will form the Gothic Arms set, which increases your armor's protection by 4. Normally the fact that set makes you completely immobile makes it impractical, but alongside Cerberus Gothic armor, it'll reduce an [[Arch-vile]]'s attack down to 2 damage (or 1 if you P-modded it or have any [[Strategy:Tough as Nails|Tough as Nails]] investment), while providing you the best acid protection any armor can have and the best plasma protection short of an [[Energy shield]], [[Plasma shield]], or [[Nanofiber skin]] [[Energy-shielded vest]], thus there are situations where it can be useful (such as an unescapable open fight where you need out to out-DPS a ton of enemies to live) and so is one more perk of Gothic Cerberus armor.

If you're a Technician and happen to find it, the [[Cybernetic Armor]] is one more option. It comes with 50% resistance to the physical trio, so it's another possible option to get the coveted >=50% resistance to all possible damage Cerberus armor, plus it already has the -30% speed and knockback penalities of Cerberus armor so it's no loss there. However its massive base protection of 7 is lost, and much more importantly, it's an armor that can never be unequipped while also featuring normal durability with no regeneration. Duelist, Ballistic, and Gothic Cerberus will provide just as much protection while being able to be unequipped if they get damaged, while the [[Nanofiber skin armor]] and [[Cybernano armor]] assemblies would be better options for an armor you can never unequip, as they still provide great protection while ensuring you won't have to ever worry about being trapped in a depleted armor. If you inadvertently put the Cybernetic armor on though as a Technician and don't have a Nano mod to make those assemblies, you might as well turn it Cerberus as resistances are still king and you'll be a lot more protected against the most dangerous enemies. Otherwise only use the Cybernetic as a base if you don't have any of the good Exotic armors to use and are really desperate for such strong protection over all else. If you decide to put on the Cybernetic to make it Cerberus, you will want to prioritise putting on an Onyx or Nano mod if you have one of them to ensure durability won't be an issue.

==Modding==
Since you need [[Whizkid]] 2 to make Cerberus armor, you will be able to apply a single mod to it.

The [[Power mod]] is an obvious choice, as it raises the armor's natural defense of 0 to 2. When the resistances lower the damage dealt so much, this +2 armor can provide a big difference in additional survivability; e.g. with base Cerberus armor it will take an Arch-vile 9 hits to kill a Scout/Technician without any [[Ironman]] investment, while with the armor P-modded, it'll take the Arch-vile 13 hits, increasing your armor's protection abilities over 40%. Plus if you made Cerberus with a base that provides no physical resistances, this will ensure you still will have some sort of protection against melee and Formers.

A Power mod is in stiff competition with an [[Agility mod]] however, as that Agility mod will make the movement speed penalty of the Cerberus armor a much more tolerable -15% (which for reference, is better than a base Red armor's -20%). For which mod to use, it depends on if your build values damage avoidance or damage tanking more, but the less melee resistance your Cerberus has, the more appealing a Power mod is to help cover up the gaping hole in your protection. Additionally if you already have another armor with much greater movement speed that you primarily wear while you mainly reserve your Cerberus Armor for unavoidable open fights and emergencies, you will probably also find better value in beefing up its protection over making it less slow.

A [[Technical mod]] is useless when why would you want to increase the knockback penalty even more when it's already so stiff, especially when you can improve its protection or movement speed substantially instead.

A [[Bulk mod]] is of questionable use, when your Cerberus should be able to usually last between [[Armor shard]]s and making its speed even worse really hurts. Plus a Power mod will indirectly significantly increase durability too through its damage reduction without costing you any more speed. Don't even think about using up your only mod spot on a Bulk mod with the Gothic Cerberus; you'll have to be playing really reckless or have gotten into some deep shit for 200% durability of Gothic Cerberus to not be enough on top of a Power or Agility mod.

A [[Nano mod]] will pretty much ensure your Cerberus will never face durability issues and will not be a bad use of your mod slot, but that Nano mod can probably be put to better use elsewhere in making yourself a broken weapon that eliminates ammo concerns or [[Antigrav boots]] to get yourself unmatchable movement speed.

An [[Onyx mod]] would make your Cerberus indestructible, but good Cerberus is pretty durable as is and you'll have to give up a really valuable Power or Agility mod boost for it. It might be more worth using it on another valuable but more fragile armor instead, it'll depend on the build you're running. Such as if you're running an extreme tanking build that will soak up a huge amount of unavoidable damage like a [[Vampyre]] build, then indestructible Cerberus could be more valuable to you over the other modding options. And needless to say, it has no effect on Onyx Cerberus, and would be quite wasteful on a Gothic Cerberus. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 18:23, 23 April 2017 (UTC)

Modding:being API (0.9.9.6)

2025-08-11T12:32:59Z

Epyon:

== API ==
The [[Modding:Thing#API|Thing API]] can also be used with beings.

{|class="wikitable" style="border: 2px solid darkred; border-spacing: 0; font-size: 90%; margin: 0.25em 0.5em;"
! colspan="2" style="background: darkred; color: yellow; font-size: 120%; text-align: center"|Being Interface
{{Table2Col
|es=background: #333;
|c1=font-weight:bold; text-align:right; vertical-align:top; padding:0px 2px;
|c2=padding:0px 2px;
|[[Modding:Being|Being]]|being.[[#being_new|new]]([[Modding:Being|Being ID]] id)
|'''void'''|[[Modding:Being|Being]]:[[#being_destroy|destroy]]('''boolean''' silent)
|'''void'''|[[Modding:Being|Being]]:[[#being_kill|kill]]('''boolean''' overkill)
|'''void'''|[[Modding:Being|Being]]:[[#being_ressurect|ressurect]]('''integer''' rrange)
|'''void'''|[[Modding:Being|Being]]:[[#being_apply_damage|apply_damage]]('''integer''' damage, [[Modding:Constants#BodyTarget|BodyTarget]] target, [[Modding:Constants#DamageType|DamageType]] damageType)
|'''string'''|[[Modding:Being|Being]]:[[#being_get_name|get_name]]('''boolean''' known, '''boolean''' capitalized)
|[[Modding:Item|Item]]|[[Modding:Being|Being]]:[[#being_get_inv_item|get_inv_item]]('''integer''' slot)
|'''void'''|[[Modding:Being|Being]]:[[#being_set_inv_item|set_inv_item]]('''integer''' slot, [[Modding:Item|Item]] item)
|[[Modding:Item|Item]]|[[Modding:Being|Being]]:[[#being_get_eq_item|get_eq_item]]([[Modding:Constants#Equip Slots|Equip Slot]] slot)
|'''void'''|[[Modding:Being|Being]]:[[#being_set_eq_item|set_eq_item]]([[Modding:Constants#Equip Slots|Equip Slot]] slot, [[Modding:Item|Item]] item)
|'''void'''|[[Modding:Being|Being]]:[[#being_play_sound|play_sound]]('''Sound ID''' sound)
|'''integer'''|[[Modding:Being|Being]]:[[#being_get_total_resistance|get_total_resistance]]([[Modding:Constants#Resistance|Resistance]] resistance, [[Modding:Constants#BodyTarget|BodyTarget]] target)
|'''boolean'''|[[Modding:Being|Being]]:[[#being_use|use]]('''integer''' slot)
|'''boolean'''|[[Modding:Being|Being]]:[[#being_wear|wear]]('''integer''' slot)
|'''boolean'''|[[Modding:Being|Being]]:[[#being_pickup|pickup]]([[Modding:Coord|Coord]] pos)
|'''void'''|[[Modding:Being|Being]]:[[#being_attack|attack]]([[Modding:Coord|Coord]] or [[Modding:Being|Being]] target)
|'''void'''|[[Modding:Being|Being]]:[[#being_fire|fire]]([[Modding:Coord|Coord]] target, [[Modding:Item|Item]] weapon)
|'''boolean'''|[[Modding:Being|Being]]:[[#being_reload|reload]]()
|'''integer'''|[[Modding:Being|Being]]:[[#being_direct_seek|direct_seek]]([[Modding:Coord|Coord]] target)
|'''boolean'''|[[Modding:Being|Being]]:[[#being_path_find|path_find]]([[Modding:Coord|Coord]] target, '''integer''' cutoff, '''integer''' maximum)
|'''integer'''|[[Modding:Being|Being]]:[[#being_path_next|path_next]]()
|[[Modding:Coord|Coord]]|[[Modding:Being|Being]]:[[#being_flock_target|flock_target]]('''integer''' range, '''integer''' mind, '''integer''' maxd)
|'''void'''|[[Modding:Being|Being]]:[[#being_msg|msg]]('''string''' msg_player, '''string''' msg_being)
|[[Modding:Item|Item]]|[[Modding:Being|Being]]:[[#being_select_slot_by_letter|select_slot_by_letter]]('''string''' letter)
|'''void'''|[[Modding:Being|Being]]:[[#being_phase|phase]]([[Modding:Cell|Cell ID]] cell)
|'''void'''|[[Modding:Being|Being]]:[[#being_spawn|spawn]]([[Modding:Being|Being ID]] being)
|'''boolean'''|[[Modding:Being|Being]]:[[#being_is_visible|is_visible]]()
|'''boolean'''|[[Modding:Being|Being]]:[[#being_is_player|is_player]]()
|'''integer'''|[[Modding:Being|Being]]:[[#being_set_items|set_items]]([[Modding:ItemSet|ItemSet]] set)
|'''void'''|[[Modding:Being|Being]]:[[#being_nuke|nuke]]('''integer''' time)
|[[Modding:Item|Item]], '''boolean'''|[[Modding:Being|Being]]:[[#being_pick_mod_item|pick_mod_item]]('''string''' modletter, '''integer''' techbonus)
|}}
|}

{{Anchor|being_new}}
;being.new([[Modding:Being|Being ID]] id) → [[Modding:Being|Being]]
:This creates a newly allocated being of the appropriate type. The being won't exist on the map until it is placed by e.g. Level.drop_being.
----
{{Anchor|being_destroy}}
;[[Modding:Being|Being]]:destroy('''boolean''' silent)
:Deallocates the memory associated with the being and removes it from the level (if applicable). The normal results of killing a being (e.g. leaving a corpse) are ignored. The ''silent'' parameter is optional. If true, applicable OnKill and OnKillAll hooks and events will also be ignored.
----
{{Anchor|being_kill}}
;[[Modding:Being|Being]]:kill('''boolean''' overkill)
:Kills the being. If the optional ''overkill'' parameter is true, then the being will be gibbed.
----
{{Anchor|being_ressurect}}
;[[Modding:Being|Being]]:ressurect('''integer''' rrange)
:Resurrects a single corpse that is found within a square of side-length 2 × ''rrange'' + 1, centered around the being. Nearer corpses are preferred. The corpse must not have another being standing on it and must be within sight of the being (as determined by the enemy line-of-sight algorithm). The resurrected being (if any) will have BF_NOEXP set. Messages are included.
----
{{Anchor|being_apply_damage}}
;[[Modding:Being|Being]]:apply_damage('''integer''' damage, [[Modding:Constants#BodyTarget|BodyTarget]] target, [[Modding:Constants#DamageType|DamageType]] damageType)
:Deals damage to the being using the given body target and damage type. (The default damage type is bullet damage.)
----
{{Anchor|being_get_name}}
;[[Modding:Being|Being]]:get_name('''boolean''' known, '''boolean''' capitalized) → '''string'''
:Returns the name of the being. If ''known'' is true, "the" is added, otherwise "a" or "an" is added. If BF_UNIQUENAME is set for the being, then no article is used in either case. If ''capitalized'' is true, then the first letter will be capitalized.
----
{{Anchor|being_get_inv_item}}
;[[Modding:Being|Being]]:get_inv_item('''integer''' slot) → [[Modding:Item|Item]]
;[[Modding:Being|Being]].inv['''integer''' slot] → [[Modding:Item|Item]]
:Returns the item in the given slot in the being's inventory. If the slot is empty, nil is returned instead.
----
{{Anchor|being_set_inv_item}}
;[[Modding:Being|Being]]:set_inv_item('''integer''' slot, [[Modding:Item|Item]] item)
;[[Modding:Being|Being]].inv['''integer''' slot] = [[Modding:Item|Item]] item
:Sets the given slot in the being's inventory to the given item. If the slot wasn't empty before, the previous constents are lost.
----
{{Anchor|being_get_eq_item}}
;[[Modding:Being|Being]]:get_eq_item([[Modding:Constants#Equip Slots|Equip Slot]] slot) → [[Modding:Item|Item]]
;[[Modding:Being|Being]].eq[[[Modding:Constants#Equip Slots|Equip Slot]] slot] → [[Modding:Item|Item]]
:Returns the item in the given equipment slot of the being. If the slot is empty, nil is returned instead. There are additional shorthands for each equipment slot: the ''eq'' table has .weapon, .prepared, .armor, and .boots fields.
----
{{Anchor|being_set_eq_item}}
;[[Modding:Being|Being]]:set_eq_item([[Modding:Constants#Equip Slots|Equip Slot]] slot, [[Modding:Item|Item]] item)
;[[Modding:Being|Being]].eq[[[Modding:Constants#Equip Slots|Equip Slot]] slot] = [[Modding:Item|Item]] item
:Sets the being's equipment slot to the given item. Any item that was previously in that slot is lost. There are additional shorthands for each equipment slot: the ''eq'' table has .weapon, .prepared, .armor, and .boots fields.
----
{{Anchor|being_play_sound}}
;[[Modding:Being|Being]]:play_sound('''Sound ID''' sound)
:Plays the given sound as if it came from the being's position.
----
{{Anchor|being_get_total_resistance}}
;[[Modding:Being|Being]]:get_total_resistance([[Modding:Constants#Resistance|Resistance]] resistance, [[Modding:Constants#BodyTarget|BodyTarget]] target) → '''integer'''
:Calculates the being's effective resistance against attacks of the given target (default is body). This accounts for inherent resists as well as equipment bonuses.
----
{{Anchor|being_use}}
;[[Modding:Being|Being]]:use('''integer''' slot) → '''boolean'''
;[[Modding:Being|Being]]:use([[Modding:Item|Item]] item) → '''boolean'''
:This makes the being use the given consumable item from its inventory. The function always returns false. (Bug: it is supposed to return true on success.)
----
{{Anchor|being_wear}}
;[[Modding:Being|Being]]:wear('''integer''' slot) → '''boolean'''
;[[Modding:Being|Being]]:wear([[Modding:Item|Item]] item) → '''boolean'''
:This makes the being wear the given eqipment from its inventory. Returns true on success and false on failure.
----
{{Anchor|being_pickup}}
;[[Modding:Being|Being]]:pickup([[Modding:Coord|Coord]] pos) → '''boolean'''
:This makes the being pick up the item at the given position. ''pos'' is optional; it defaults to the being's position. Returns true on success and false on failure.
----
{{Anchor|being_attack}}
;[[Modding:Being|Being]]:attack([[Modding:Coord|Coord]] or [[Modding:Being|Being]] target)
:This makes the being do a standard melee attack against the targeted being or coord.
----
{{Anchor|being_fire}}
;[[Modding:Being|Being]]:fire([[Modding:Coord|Coord]] target, [[Modding:Item|Item]] weapon)
:This makes the being fire at ''target'' with ''weapon''.
----
{{Anchor|being_reload}}
;[[Modding:Being|Being]]:reload() → '''boolean'''
:This makes the being reload its currently equipped weapon. The return value is true if there being had at least some of the appropriate ammo to attempt reloading with.
----
{{Anchor|being_direct_seek}}
;[[Modding:Being|Being]]:direct_seek([[Modding:Coord|Coord]] target) → '''integer'''
:This makes the being take a step towards the target. The being will always try to travel in a direct path. The return value is either 0, 1, 2, or 3. 0 indicates success, 1 indicates that a wall blocked the move, 2 indicates that a door blocked the move, and 3 indicates that a being blocked the move.
----
{{Anchor|being_path_find}}
;[[Modding:Being|Being]]:path_find([[Modding:Coord|Coord]] target, '''integer''' cutoff, '''integer''' maximum) → '''boolean'''
:This attempts to calculate a path between the being and ''target''. The ''cutoff'' and ''maximum'' parameters are somewhat technical, but basically they indicate how much time should be spend searching for a path. DRL uses 40, 200 for bosses and 10, 40 for normal enemies. The path will be remembered by the being, and can be followed using path_next. Modders should keep in mind that path-finding is a somewhat expensive operation, especially for large ''cutoff'' and ''maximum''. The return value indicates whether a path was found. Even if no path was found, a path will be loaded that will try to take the being closer to the target (although this path may be empty). This uses the AStar searching algorithm using Euclidean distance as a heuristic. The search is aborted if ''maximum'' nodes are expanded without finding the target or it ''cutoff'' nodes are expanded without getting closer to the target. When aborted, a path is created to the closest expanded node to the target in terms of the heuristic.
----
{{Anchor|being_path_next}}
;[[Modding:Being|Being]]:path_next() → '''integer'''
:This causes the being to take a step along the path last calculated by path_find. The return value follows the pattern of direct_seek.
----
{{Anchor|being_flock_target}}
;[[Modding:Being|Being]]:flock_target('''integer''' range, '''integer''' mind, '''integer''' maxd) → [[Modding:Coord|Coord]]
:This looks for the closest being of the same type to the being (within a square ''range''). If the being is farther than ''maxd'' away, then its position is returned. If it is closer than ''mind'', then a position opposite from the closest with respect to the being is returned. Otherwise (or if there is no nearby being of the same type), a random coord from the scanning area is returned.
----
{{Anchor|being_msg}}
;[[Modding:Being|Being]]:msg('''string''' msg_player, '''string''' msg_being)
:If the being is the player, then ''msg_player'' is displayed. If the being is not the player, but visible to the player, the ''msg_being'' is displayed. If either message is nil it is ignored.
----
{{Anchor|being_select_slot_by_letter}}
;[[Modding:Being|Being]]:select_slot_by_letter('''string''' letter) → [[Modding:Item|Item]]
:Returns the one of the being's equipment where "a" is for armor, "b" is for boots, "w" is for weapon, and "p" is for the prepared slot. If the slot is empty, nil is returned.
----
{{Anchor|being_phase}}
;[[Modding:Being|Being]]:phase([[Modding:Cell|Cell ID]] cell)
:If ''cell'' is omitted, then the being is displaced randomly as if it used a [[phase device]] (without the flashy interface stuff). If the cell is included, the being is displaced to a random cell of the given cell id. If the chosen cell is occupied, a nearby cell is used. If no such cell exists, a random cell is chosen.
----
{{Anchor|being_spawn}}
;[[Modding:Being|Being]]:spawn([[Modding:Being|Being ID]] being)
;[[Modding:Being|Being]]:spawn([[Modding:Being|Being]] being)
:Drops a new being of the appropriate type (or the given being) nearby. The dropped being is set with the BF_NOEXP flag.
----
{{Anchor|being_is_visible}}
;[[Modding:Being|Being]]:is_visible() → '''boolean'''
:Determines if the player can see the being.
----
{{Anchor|being_is_player}}
;[[Modding:Being|Being]]:is_player() → '''boolean'''
:Determines if the being is the player.
----
{{Anchor|being_set_items}}
;[[Modding:Being|Being]]:set_items([[Modding:ItemSet|ItemSet]] set) → '''integer'''
:Counts the number of the being's equipped items that belong to the given set.
----
{{Anchor|being_nuke}}
;[[Modding:Being|Being]]:nuke('''integer''' time)
:Sets the nuke timer to ''time'' and changes the cell under the being to the nuke cell. By default, ''time'' is 1. (Setting the nuke time to 0 will disable the countdown.)
----
{{Anchor|being_pick_mod_item}}
;[[Modding:Being|Being]]:pick_mod_item('''string''' modletter, '''integer''' techbonus) → [[Modding:Item|Item]], '''boolean'''
:This only works for the player. This gives the player the item select menu used by mods, and calculates whether the mod is legal (using the given ''techbonus''). This includes assembly checking. The first return value is the item on success. The second return value is true on

Modding:generator API (0.9.9.6)

2025-08-11T12:32:27Z

Epyon:

The generator holds all of the ever-present functions used to create the random maps in DRL. It also contains a variety of helper functions, many of them useful if not vital to the creation of intricate and meticulous game design.

== API ==
{|class="wikitable" style="border: 2px solid darkred; border-spacing: 0; font-size: 90%; margin: 0.25em 0.5em;"
! colspan="2" style="background: darkred; color: yellow; font-size: 120%; text-align: center"|'''Level Interface'''
{{Table2Col
|es=background: #333;
|c1=font-weight:bold; text-align:right; vertical-align:top; padding:0px 2px;
|c2=padding:0px 2px;
|{{modarg|Coord}}|{{moddef|list|safe_empty_coord|dot}}
|{{modarg|Coord}}|{{moddef|list|standard_empty_coord|dot}}
|{{modarg|void}}|{{moddef|list|set_permanence|dot||Area|ar|boolean|val|Cell|tile}}
|{{modarg|void}}|{{moddef|list|setup_ice_event|dot}}
|{{modarg|void}}|{{moddef|list|setup_perma_event|dot}}
|{{modarg|void}}|{{moddef|list|setup_alarm_event|dot}}
|{{modarg|void}}|{{moddef|list|setup_deadly_air_event|dot||integer|step}}
|{{modarg|void}}|{{moddef|list|setup_nuke_event|dot||integer|minutes}}
|{{modarg|void}}|{{moddef|list|setup_flood_event|dot||integer|direction|integer|step|Cell|cell|boolean|pure}}
|{{modarg|integer}}|{{moddef|list|being_weight|dot}}
|{{modarg|integer}}|{{moddef|list|item_amount|dot}}
|{{modarg|void}}|{{moddef|list|restore_walls|dot||Cell|wall_cell|boolean|keep_fluids}}
|{{modarg|Cellset list}}|{{moddef|list|cell_set|dot||list|list}}
|{{modarg|void}}|{{moddef|list|horiz_river|dot||Cell|cell|integer|width|boolean|bridge}}
|{{modarg|void}}|{{moddef|list|vert_river|dot||Cell|cell|integer|width|boolean|bridge|Coord|pos}}
|{{modarg|void}}|{{moddef|list|generate_rivers|dot||boolean|allow_horiz|boolean|allow_more}}
|{{modarg|void}}|{{moddef|list|drunkard_walk|dot||Coord|start|integer|steps|Cell|cell|Cell list|ignore|boolean|break_on_edge}}
|{{modarg|void}}|{{moddef|list|drunkard_walks|dot||integer|amount|integer|steps|Cell|cell|Cell list|ignore|boolean|break_on_edge|Area|drunk_area}}
|{{modarg|void}}|{{moddef|list|contd_drunkard_walks|dot||integer|amount|integer|steps|Cell|cell|Coord|edges1|Coord|edges2|Cell list|ignore|boolean|break_on_edge}}
|{{modarg|void}}|{{moddef|list|plot_lines|dot||Coord|where|Area|larea|boolean|horiz|Cell|cell|Cell list|block}}
|{{modarg|void}}|{{moddef|list|maze_dungeon|dot||Cell|floor_cell|Cell|wall_cell|integer|granularity|integer|tries|integer|minl|integer|maxl}}
|{{modarg|void}}|{{moddef|list|warehouse_fill|dot||Cell|wall_cell|Area|fill_area|integer|box_size|integer|amount}}
|{{modarg|void}}|{{moddef|list|warehouse_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|add_room|dot||Area|room}}
|{{modarg|boolean}}|{{moddef|list|add_rooms|dot}}
|{{modarg|Room}}|{{moddef|list|get_room|dot||integer|min_size|integer|max_x|integer|max_y}}
|{{modarg|void}}|{{moddef|list|generate_tiled|dot}}
|{{modarg|void}}|{{moddef|list|generate_warehouse_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_tiled_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_tiled_arena_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_city_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_maze_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_archi_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_caves_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_arena_dungeon|dot}}
|{{modarg|void}}|{{moddef|list|generate_fluids|dot||Area|drunk_area}}
|{{modarg|void}}|{{moddef|list|generate_barrels|dot}}
|{{modarg|void}}|{{moddef|list|generate_stairs|dot}}
|{{modarg|void}}|{{moddef|list|generate_special_stairs|dot}}
|{{modarg|void}}|{{moddef|list|generate_lever_room|dot}}
|{{modarg|void}}|{{moddef|list|generate_teleport_room|dot}}
|{{modarg|void}}|{{moddef|list|generate_ammo_room|dot}}
|{{modarg|void}}|{{moddef|list|generate_basain|dot}}
|{{modarg|void}}|{{moddef|list|generate_warehouse_room|dot}}
|{{modarg|void}}|{{moddef|list|generate_vault|dot}}
|{{modarg|void}}|{{moddef|list|add_room_feature|dot||boolean|no_monsters}}
|{{modarg|void}}|{{moddef|list|handle_rooms|dot||boolean|no_monsters}}
|{{modarg|void}}|{{moddef|list|place_player|dot}}
|{{modarg|void}}|{{moddef|list|roll_event|dot}}
|{{modarg|void}}|{{moddef|list|reset|dot}}
|}}
|}

;{{moddef|desc|safe_empty_coord|dot}}
:Gives a coordinate that satisfies all [[Modding:Constants#Empty Flags|empty flags]]. If one cannot be found, another attempt is made that excludes EF_NOSAFE; if one still cannot be found, another attempt is made that additionally excludes EF_NOSTAIRS and EF_NOHARM.
----
;{{moddef|desc|standard_empty_coord|dot}}
:Gives a coordinate that satisfies all empty flags other than EF_NOSAFE.
----
;{{moddef|desc|set_permanence|dot||Area|ar|boolean|val|Cell|tile}}
:Adds the "frozen" level event to the map and records it in the mortem history. Levels with the frozen event change all walls into ice walls and all fluids into water.
----
;{{moddef|desc|setup_ice_event|dot}}
:Adds the "frozen" level event to the map and records it in the mortem history. Levels with the frozen event change all walls into ice walls and all fluids into water.
----
;{{moddef|desc|setup_perma_event|dot}}
:Adds the "sturdy" level event to the map and records it in the mortem history. Levels with the sturdy event set all wall tiles to be permanent.
----
;{{moddef|desc|setup_alarm_event|dot}}
:Adds the "alarm" level event to the map and records it in the mortem history. Levels with the alarm event set all non-player beings' [[Modding:Constants#Being Flags|BF_HUNTING]] flag to true.
----
;{{moddef|desc|setup_deadly_air_event|dot||integer|step}}
:Adds the "deadly air" event to the map and records it in the mortem history. Levels with the deadly air event cause all beings to lose hit points every '''step''' turns.
----
;{{moddef|desc|setup_nuke_event|dot||integer|minutes}}
:Adds the "armed nuke" event to the map and records it in the mortem history. Levels with the armed nuke event begin with a [[thermonuclear bomb]] set at the player's starting position, which will explode in ''minutes'' game minutes.
----
;{{moddef|desc|setup_flood_event|dot||integer|direction|integer|step|Cell|cell|boolean|pure}}
:Adds the "flood" event to the map and records it in the mortem history. Levels with the flood event are slowly filled with a fluid: ''direction'' determines whether the floor travels from the right (-1) or from the left (+1); every ''step'' turns, ''cell'' will replace all tiles in a next column to be flooded. Setting ''pure'' to false will move the player and stairs to opposite sides of the map, with the player nearest the flood.
----
;{{moddef|desc|being_weight|dot|integer}}
:Gives a value equal to the difficulty-adjusted weight of beings for a given danger level. These are the results used for the base game's monster generation parameters.
----
;{{moddef|desc|item_amount|dot|integer}}
:Gives a value equal to the number of items spawned for a given danger level. On level types where the this amount isn't preset, this is the result used for the base game's item generation parameters.
----
;{{moddef|desc|restore_walls|dot||Cell|wall_cell|boolean|keep_fluids}}
:Sets all cells on the edge of the map to ''wall_cell''. If ''keep_fluids'' is set to true, fluid tiles will be maintained but set as permanent.
----
;{{moddef|desc|cell_set|dot|Cellset list|list|list}}
:Creates a cellset for all cells in ''list''. The returned list functions just like any [[Modding:Constants#Cellsets|CELLSET constant]].
----
;{{moddef|desc|horiz_river|dot||Cell|cell|integer|width|boolean|bridge}}
:Adds a horizontal river to the map, created using ''cell'' tiles. ''width'' sets the tile-width of the river. If ''bridge'' is set to true, a non-fluid floor bridge will be created on the river.
----
;{{moddef|desc|vert_river|dot||Cell|cell|integer|width|boolean|bridge|Coord|pos}}
;{{moddef|desc|vert_river|dot||Cell|cell|integer|width|boolean|bridge|integer|pos}}
:Adds a vertical river to the map, created using ''cell'' tiles. ''width'' sets the tile-width of the river, and ''pos'' sets the starting position of the river. If ''pos'' is given as an integer, then the starting y-coordinate of the river is at the top of the map. If ''bridge'' is set to true, a non-fluid floor bridge will be created on the river.
----
;{{moddef|desc|generate_rivers|dot||boolean|allow_horiz|boolean|allow_more}}
:Generates a random number of horizontal and vertical rivers on the map. See [[Fluids#Rivers|Rivers]] for more information. The fluid type varies with map depth.
----
;{{moddef|desc|drunkard_walk|dot||Coord|start|integer|steps|Cell|cell|Cell list|ignore|boolean|break_on_edge}}
:Generates ''cell'' tiles according to a drunken walk algorithm. It travels ''steps'' times, starting at the coordinate ''start''. Any cells in ''ignore'' will not be set over but the algorithm will still continue. If ''break_on_edge'' is set to true, the drunken walk will stop if it hits a map border: otherwise it will continue, clamping cells within the map as necessary.
----
;{{moddef|desc|drunkard_walks|dot||integer|amount|integer|steps|Cell|cell|Cell list|ignore|boolean|break_on_edge|Area|drunk_area}}
:As Generator.drunkard_walk, but repeated ''amount'' times. Additionally, rather than specifically a starting position, all walks are chosen from a random coordinate within ''drunk_area''.
----
;{{moddef|desc|contd_drunkard_walks|dot||integer|amount|integer|steps|Cell|cell|Coord|edges1|Coord|edges2|Cell list|ignore|boolean|break_on_edge}}
:As Generator.drunkard_walks, but rather than limiting the walk's starting position, the walk will stop prematurely if it has reached the x- or y-coordinates of both ''edges1'' and ''edges2''.
----
;{{moddef|desc|plot_lines|dot||Coord|where|Area|larea|boolean|horiz|Cell|cell|Cell list|block}}
:Generates a line of ''cell'' tiles on the map, starting at ''where'' and extending to the boundaries of ''larea''. ''horiz'' set to true will produce horizontal lines: otherwise it will produce vertical lines. If a cell from ''block'' is found, the line will end prematurely at the end on which it was blocked.
----
;{{moddef|desc|maze_dungeon|dot||Cell|floor_cell|Cell|wall_cell|integer|granularity|integer|tries|integer|minl|integer|maxl}}
:Generates a map-wide maze, using ''wall_cell'' as the wall tiles and ''floor_cell'' as the floor tiles. Wall corridors are at least ''minl'' tiles apart and at most ''maxl'' tiles apart: ''granularity'' sets a rough complexity of the map. The number of walls attempted to be made is equal to ''tries''.
----
;{{moddef|desc|warehouse_fill|dot||Cell|wall_cell|Area|fill_area|integer|box_size|integer|amount}}
:Generates ''wall_cell'' tiles in the shape of a square within ''fill_area''. ''boxsize'' sets the size of the side of a box, and ''amount'' sets the number of tries for boxes to be added.
----
;{{moddef|desc|warehouse_dungeon|dot}}
:Generates a map-wide warehouse setting. Warehouse dungeons are divided into three large rooms, each attempting 50 tries with boxes of side length 3.
----
;{{moddef|desc|add_room|dot||Area|room}}
:Adds ''room'' to the Generator.room_list and Generator.room_meta lists. This is used in conjunction with room generation functions.
----
;{{moddef|desc|add_rooms|dot|boolean}}
:As Generator.add_room, but locates all rooms on the map and adds them to Generator.room_list and Generator.room_meta instead.
----
;{{moddef|desc|get_room|dot|Room|integer|min_size|integer|max_x|integer|max_y}}
:Finds a room that contains at least ''min_size'' in both height and width, and has a width and height no bigger than ''max_x'' and ''max_y'', respectively.
----
;{{moddef|desc|generate_tiled|dot}}
:Generates a "normal" map. Normal levels are divided randomly into rectangular rooms.
----
;{{moddef|desc|generate_warehouse_dungeon|dot}}
:Builds a "warehouse" level. This includes everything necessary to be played as a typical random level.
----
;{{moddef|desc|generate_tiled_dungeon|dot}}
:Builds a "normal" level. This includes everything necessary to be played as a typical random level.
----
;{{moddef|desc|generate_tiled_arena_dungeon|dot}}
:Builds a "single-monster" level. This includes everything necessary to be played as a typical random level.
----
;{{moddef|desc|generate_city_dungeon|dot}}
:Builds a "city" level. This includes everything necessary to be played as a typical random level.
----
;{{moddef|desc|generate_maze_dungeon|dot}}
:Builds a "maze" level. This includes everything necessary to be played as a typical random level.
----
;{{moddef|desc|generate_archi_dungeon|dot}}
:Builds an "archi" level. This includes everything necessary to be played as a typical random level.
----
;{{moddef|desc|generate_caves_dungeon|dot}}
:Builds a "cave" level. This includes everything necessary to be played as a typical random level.
----
;{{moddef|desc|generate_arena_dungeon|dot}}
:Builds an "arena" level. This includes everything necessary to be played as a typical random level.
----
;{{moddef|desc|generate_fluids|dot||Area|drunk_area}}
:Generates all non-river fluids on the map using drunken walks, within ''drunk_area''. The fluid type varies with danger level.
----
;{{moddef|desc|generate_barrels|dot}}
:Generates all barrels on the map, The barrel type varies with danger level.
----
;{{moddef|desc|generate_stairs|dot}}
:Generates stairs on the map.
----
;{{moddef|desc|generate_special_stairs|dot}}
:Generates special stairs on the map, if a special level exists at the current map depth.
----
;{{moddef|desc|generate_lever_room|dot}}
:Finds a room of appropriate size and adjusts it into a lever room.
----
;{{moddef|desc|generate_teleport_room|dot}}
:Finds a room of appropriate size and adjusts it into a teleporter room.
----
;{{moddef|desc|generate_ammo_room|dot}}
:Finds a room of appropriate size and adjusts it into an ammo room. The type of ammo varies with danger level.
----
;{{moddef|desc|generate_basain|dot}}
:Finds a room of appropriate size and adjusts it into a room filled with fluid.
----
;{{moddef|desc|generate_warehouse_room|dot}}
:Finds a room of appropriate size and adjusts it into a room with boxes (as Generator.warehouse_fill).
----
;{{moddef|desc|generate_vault|dot}}
:Finds a room of appropriate size and adjust it into a vault. The monsters, items, and type of vault vary with danger level.
----
;{{moddef|desc|add_room_feature|dot||boolean|no_monsters}}
:Randomly selects a room generation function to be added to the map. ''no_monsters'' set to true excludes the possibility of a vault room being generated.
----
;{{moddef|desc|handle_rooms|dot||boolean|no_monsters}}
:Generates up to seven special rooms on the map and restores walls that were otherwise removed as a result of the room generation.
----
;{{moddef|desc|place_player|dot}}
:Adds to player to the map.
----
;{{moddef|desc|roll_event|dot}}
:Randomly select a level event function to be added to the map.
----
;{{moddef|desc|reset|dot}}
:Clears all generation properties and hooks, and changes the map into one bordered with the level style's walls and otherwise filled with the level style's floors.

Strategy:Ironman

2025-08-11T12:32:13Z

Epyon:

{{infostrat switch}}

==0.9.9.7==

Ironman

Ironman is a great trait to level up in--depending on what you want to do.

As a "standalone" trait (i.e., a trait to level up in just 'cause), Ironman is a great fill-in if you don't want to get other more "important" traits first.

This trait is also a great choice if you're really hurting in health, armor, and general resistances. Selecting Ironman won't give you "free health", it simply boosts your max HP by 10 points (and actually boosts your current HP by 10 also). Because damage is dealt by calculating how much HP you have, and to an extent, the percentage of max HP you have, having a level or two in Ironman can really come in handy when the late-game enemies come out to play.

Ironman will make you practically immortal against the former human/sergeant group (especially so when paired with a good armor and decent weapon).

Last words of advice? Ironman is a great trait to level up in for a defensive build, or just a good trait to have after completing a Master build.
I would recommend leveling up in more savory traits such as Reloader, Son of a Bitch, Finesse, and so on before selecting this trait.

[[User:GinDiamond|GinDiamond]] ([[User talk:GinDiamond|talk]]) 21:21, 14 October 2013 (CEST)

One less-discussed factor about Ironman is that it increases the power of health kits and health levers, since these always heal you by a percentage of your maximum HP. It might not build to Badass (TaN does that), and it actually doesn't build towards anything but Survivalist for Marines, but it is also blocked by nothing, so it fits into any build. If you're a Marine, you get Badass access free anyway, and getting more health further increases the power of Badass, since your boosted maximum is also increased. Even if Badass is blocked by your Mastery, Ironman isn't, so it can toughen you up a great deal. On Ao100 or Ao666, Ironman is invaluable, probably even moreso than offensive traits once you finish your mastery, since later enemies have a high chance of instakilling you without it, and since it increases the power of health packs, it can push your limited resources farther.

Since it does build towards Survivalist, it should be noted that Survivalist is probably the best General Mastery of all, since it makes you as tough as a goddamned tank. It might not be as fun as other masteries, but it's an ironclad insurance policy. More offense might help you win more fights, but more health will help you win the game.

[[User:Vid-szhite|Vid-szhite]] ([[User talk:Vid-szhite|talk]]) 06:38, 3 February 2017 (UTC)

Ironman is a filler trait through and through; 10 extra max HP is certainly not a bad thing to have (usually, we'll touch on that in a bit), but simply 10 extra HP isn't going to be doing all that much to win you the game in the way other traits will. Strictly defensive-based traits are already inherently flawed, as often for them to have any effect relies on bad play; there will certainly be situations where damage is unavoidable and even the best players will inevitably make mistakes that get them hit, but just playing better will do a lot to reduce the damage you take, and so traits that better facilitate good play thus have inherent value over those that rely on getting hit to have any effect. When it comes to improving your survivability, [[Strategy:Hellrunner|Hellrunner]] will often be the premier choice, as the increased movement speed and [[dodging]] rate will allow you to avoid hits you would have taken without it, while nothing reduces damage more than avoiding getting hit in the first place. Then Hellrunner is also not strictly a defensive trait, as it very much improves your offensive ability when you can better outmaneuver or approach enemies, and has other general utilities that taking less time per move grants. Another thing is that a good offense making a good defense is very much true in DRL; if you can kill enemies before they get the chance to attack you, you'll take no damage at all (i.e. the reason why [[Strategy:Angel of Max Carnage|Angel of Max Carnage]] is widely considered to be easier than the standard game, despite enemies hitting so brutally hard in it). As such, investing in DPS-boosting traits like [[Strategy:Finesse|Finesse]] and the various damage-boosting traits will very much keep you alive better than more max HP will. [[Strategy:Intuition|Intuition]] is another trait that will do a lot more to keep you alive; knowing where enemies are outside your vision will let you avoid stumbling into a bad situation in the first place, and knowing where powerups are will let you know where to beeline to if you need healing or the power of [[Invulnerability]]/[[berserk]] to fight a strong group of enemies. So overall, Ironman should generally only be picked after you already exhausted investing into pertinent traits and the only other remaining traits don't benefit your build at all (such as [[Strategy:Son of a Gun|Son of a Gun]] when you're not using [[pistol]]s).

One more consideration with Ironman if you do want a defensive-boosting trait, is whether to choose it or [[Strategy:Tough as Nails|Tough as Nails]], assuming your master trait blocks neither, whether as an endgame filler trait or because you are actively trying to run an extreme tanking build that isn't Survivalist (which has both required for it). Ironman has a slight edge in normal circumstances, due to it giving you a slightly wider margin of error against highly-damaging hits, not having its effect reduced by half against [[plasma]] attacks like TaN does, and netting you more effective HP from percentage-based health sources as covered prior. However, if you got very good [[armor]] with strong enough [[resistance]]s to reduce damage to 5 or less, you will increasingly improve your effective survivability by increasing your innate [[protection]] rather than your max HP (with a [[Scout]] or [[Technician]], reducing 5 damage to 4 will make them go from dying in 10 hits to 13 while 10 extra HP makes them take 12 hits; reducing 4 damage to 3 makes them go from dying in 13 hits to 17 while Iro makes them take 15 hits; reducing 3 damage to 2 makes them go from dying in 17 hits to 25 while Iro makes them take 20 hits; reducing 2 damage to 1 makes them go from dying in 25 hits to 50 while Iron makes then take 30 hits). Additionally, if you got [[Strategy:Berserker|Berserker]], TaN is clearly better to invest in if it's not blocked; aside from the +60% resistance to all damage given by berserk letting you often reduce damage to that aforementioned 5 or less threshold even without particularly good armor, increasing your max HP will actually nerf the ability for Berserker to activate off of very strong hits that deal a third or more of your max HP in damage. Considering Berserker kicking in this way will apply the resistances of berserk before the damage is calculated for those nasty hits and thus drastically reduce their damage, investing in Ironman can actually substantially worsen your survivability in these cases (10 extra HP is doing shit with mitigating the 20 damage of an [[Arch-vile]] zap, whereas Berserker activating will reduce it to a much less harsh 8 damage ''before'' your own armor is applied). Additionally, Scouts and Technicians with their base 50 max HP can rather easily intentionally activate Berserker at any time by just blowing up rockets in their face, and [[Marine]]s can still at least get free berserk by letting an Arch-vile zap them or by blowing up a napalm [[barrel]] in their face, while investing in Ironman eliminates this ability (investing in Iro just once as a Marine, or twice as a Scout/Technician, will mean even an Arch-vile zap will no longer be able to activate Berserker). So considering that, if you have Berserker, you likely won't want to invest in Ironman even after you fully invested in all other useful traits. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 18:30, 21 July 2023 (UTC)

==0.9.9.8==
Ironman has been buffed in 0.9.9.8 in two ways.

The first buff is that Berserker's activation from you getting hit is now based on nominal max HP, which means increasing your max HP from Ironman no longer hinders you from reaping the defensive benefits from Berserker (i.e. if you max out Ironman, attacks will still just need to deal one-third of 50 HP to activate Berserker rather than one-third of 100 HP). As such, if you're a melee build wanting easy Berserker procs from face rockets and the [[VMR]], or otherwise took Berserker for extra defensive insurance from very strong hits (as the resistances granted by berserk are still applied before damage is calculated), you can now take Ironman for extra durability and get the best of both worlds.

The second buff is that each level of Ironman now cumulatively gives you +10% inherent resistances to [[bullet]], [[shrapnel]], and [[melee]] damage. Aside from giving extra defensive utility and more value to take as an endgame filler trait (with multiple levels of Ironman combining nicely with armors that have strong energy resistances to bolster any lack of physical resistances they may have), there are these particular scenarios where this buff especially helps:

*Taking Ironman early or even as your first trait has more merit, when you're fighting predominantly Formers and melee enemies during the early game. Even just a single level for only 10% physical resistances is enough to reduce damage by 1 from [[Former human]]s over half the time, from each bullet of a [[Former captain]] burst a third of the time, always from a [[Lost soul]] charge and [[Demon]] bite, and nearly always from a [[Former sergeant]]'s [[shotgun]] blast (or even save you 2 damage if you take a high damage roll from close range). That is on top of the increased HP you get, and like all resistances, it gets applied before your armor, so it can seriously extend survival in the early game; for example a Demon bite does 7 damage on average, killing a Scout/Technician in 8 hits, while Green Armor will reduce it to 6 damage and extend survival by only a single hit, whereas with Ironman's 10% melee resistance + Green Armor reducing it to 5 damage while you now have 60 HP, it takes 12 Demon bites to kill you.

*Ironman is obviously much more lucrative for melee builds and melee-locked challenges, where lots of melee damage is unavoidable, and as demonstrated in the prior point, even just one level makes a substantial difference with increasing your hit-taking ability against enemies with mid tier melee attacks (that is unless you're running [[Strategy:Vampyre|Vampyre]] of course, where it being allowed the buffed Ironman proved to be near-IDDQD and so it's now the only mastery that blocks Ironman), while each additional 10% from successive levels of Ironman will reduce another point of damage from high tier melee attacks that deal at least 9 damage (or even 2 damage in the case of certain bosses and nightmare enemies with especially powerful melee attacks). Additionally, the resistances granted by Ironman get applied in damage calculation before your armor is factored, which means unlike Tough as Nails, Ironman ''does'' reduce damage your armor takes, and so your armors will also be lasting longer in melee combat (especially valuable as armor gets worn down so fast when you're fighting predominantly in melee).

*If you're trying to clear [[Unholy Cathedral]] with a build that has no [[Strategy:Brute|Brute]] investment nor the movement + attacking speed to repeatedly hit the [[Angel of Death]] without retaliation, a level or two into Ironman in conjunction with an armor that has strong melee resistance can push you into the range to reduce the AoD's attacks to 1 damage and thus still beat him in hand-to-hand combat (for example, +20% melee resistance from two levels of Iro combined with the 40% melee resistance and 6 protection of a P-modded [[Ballistic armor|Ballistic]] [[Red armor]] will be enough to reduce all the AoD's attacks to 1 damage).

Overall, Ironman is still mostly a filler trait for all the reasons I laid out prior, at the end of the day ramping up your offense and speed still reigns supreme in DRL over what is still a purely defensive trait, but now it can benefit you to pick it sooner than endgame filler, and otherwise there's no longer reason to actively avoid picking it. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 04:31, 20 July 2024 (UTC)

VMR

2025-08-11T12:32:03Z

Epyon:

VMR is a slang term in the DRL community used to quickly refer to the following three enemies:

*V = [[Arch-vile]]s
*M = [[Mancubi]]
*R = [[Revenant]]s

Strategy:Hellrunner

2025-08-11T12:31:55Z

Epyon:

{{infostrat switch}}

==0.9.9.7==

Hellrunner is an amazing trait that new players don't even realize the value of, but veterans eventually learn all the reasons to love. One of the biggest and most underrated reasons is that with two levels of Hellrunner, you're faster than [[Demon|Demons]] even while tired or cautious, but without Hellrunner, you have to start [[Tactics|Running]] and then expend almost all your moves in order to gain even one tile of space, and on UV, you better not be wearing armor or you're too slow to even do that while running. Hellrunner 2 makes Running speed your ''base'' speed, and makes you even better at dodging.

Another big reason to love it is that without its increase to dodge chance, you might as well not even bother trying to use the [[Dodging]] mechanic. Without any Hellrunner levels, dodging is essentially a coin flip against any fireball, and it's basically useless against Formers. With just Hellrunner 2 though, not even [[Dodgemaster]], your base chance to dodge fireballs jumps up to 80% before distance is factored in. That's a big difference! With Dodgemaster added in, you can dodge even the first bullet fired at you for free, and once you can actually use the dodging mechanic, getting caught out in the open surrounded by monsters is no longer a surefire death sentence. You can actually use dodging while zig-zag running to safety and the monsters chasing you will kill each other with attacks meant for you. Dodging is also one of the only ways to defeat the Cyberdemon on higher difficulty.

Being able to actually run away from things without chugging all your medkits or gambling on a phase device will let you survive so many difficult moments it's not even funny. I'll let Omega Tyrant go into detail about that though.

[[User:Vid-szhite|Ya Girl Juniper]] ([[User talk:Vid-szhite|talk]]) 11:48, 28 May 2023 (UTC)

Hellrunner increases your base movement speed by 15% for each level you take in it, as well as gives you an additional 15% bonus to your dodging rate. You can take up to 2 levels in Hellrunner normally for +30% movement speed and dodging rate, while upon hitting level 12 you can take a third level, for a maximum increase of +45%.

Movement speed is extremely important in DRL, for offensive, defensive, and general purposes. The better you're able to outmaneuver your enemies, the more favorable position you can manipulate them into and better confront them on your terms. The faster you can move and better you can dodge, the easier it will be to approach and fight enemies in the open. When needing to escape from a bad situation like being surrounded by enemies, nothing else will help you as much as movement speed and your dodging rate. When it comes to damage reduction, nothing reduces damage more than avoiding taking damage in the first place, so levels in Hellrunner can do a better job at keeping you alive than investment in [[Tough as Nails]] and [[Ironman]], especially when boosting your movement and dodging through equipment is harder than simply getting better protecting armor. Then you can run into [[level event]]s like acid/lava floods, armed nukes, and deadly air, where being able to escape/finish the level as soon as possible is imperative to avoid dying, and the less time you spend with each move, the greater leeway you get in being able to complete and thus survive these levels. Then when you're stair diving, the better you're able to evade enemies the easier and quicker you'll be able to get to the stairs. Another thing is when your health is boosted above 100% and you don't have the necessary levels of [[Badass]] to retain it, its decay rate is based on time (5.0 seconds to be exact). So the faster you move, the more actions you get to retain the boosted health, and if you gather up any remaining health globes/[[Supercharge]]s/[[Megasphere]]s at the end of the level, the more boosted health you'll get to carry with you to the next level, especially if those powerups were spreadout and/or located far away from the stairs.

Two levels in Hellrunner will additionally give you access to [[Dodgemaster]], which allows you to dodge the first projectile thrown at you between moves with a 100% dodging rate, a very handy trait to reduce the damage you sustain farther, as well as give you a free win against the [[Cyberdemon]] and make [[John Carmack]]'s rockets a nonissue.

So Hellrunner by itself is a very helpful trait to invest in regardless of your build, and is probably the most helpful basic trait independent of other factors. Fortunately many master traits have Hellrunner investment as a prerequisite; [[Blademaster]], [[Malicious Blades]], [[Gun Kata]], [[Shottyhead]], [[Fireangel]], and [[Gunrunner]]. You'll never feel constricted or as if you could have gotten something more useful when having to take Hellrunner to get your master. Quite a few masters block Hellrunner however; [[Vampyre]], [[Bullet Dance]], [[Army of the Dead]], and [[Survivalist]]. Vampyre though is the only master trait of those considered to be a worthwhile pick over their competitors, and not being able to get Hellrunner plays a part in those other masters being considered underwhelming.

If your master doesn't require Hellrunner, Hellrunner is a great trait to invest in after you get your master for any build that doesn't block it, and it will often be the most useful trait to invest in after your master, with [[Finesse]], [[Whizkid]] and [[Intuition]] being its only strong competition. If your master doesn't require it but doesn't block it, it may even be a decent idea to take a level in Hellrunner before getting your master, as delaying your master a level to get Hellrunner could mean the difference between death and being able to live long enough to get your master at all. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 20:04, 28 April 2017 (UTC)

Strategy:Unholy Cathedral

2025-08-11T12:31:46Z

Epyon:

{{infostrat switch}}

==Overview==
Unholy Cathedral is a special level which has a gimmick of melee-exclusivity. The level only features melee enemies, including a melee-only boss with ridiculous stats, and any guns will not fire if you attempt to, keeping you restricted to only melee attacks outside a few exceptions that will be covered later. Killing the [[Angel of Death]], the boss of the level, will reward you with the [[Longinus Spear]], an extremely powerful melee weapon that far exceeds any modded Chainsaw. Beat him on at least Hurt Me Plenty difficulty while carrying a 100% killrate up to that point, you'll instead be rewarded with the even more powerful [[Azrael's Scythe]]. Then if you beat him on Nightmare difficulty, while having beaten [[Hell's Arena]] earlier in the run without taking damage, you'll instead be rewarded with the [[Dragonslayer]].

If you're a melee build, or at least have some investment in [[Brute]], [[Berserker]], and a [[Chainsaw]], this level will be ridiculously simple. A horde of [[Lost soul]]s and [[Demon]]s are little threat and you can just run in, get berserked, and steamroll over them, while then run up to the Angel of Death and mash click until he dies. The ease of difficulty and the amazing melee weapon you get for beating this level makes it a mandatory stop for melee builds, and upon beating it the rest of the game will become a cakewalk, especially if you fulfilled the conditions to get Azrael's Scythe or the Dragonslayer.

If you're not a melee build while lacking Brute and Berserker, beating this level becomes a much more arduous task you will need proper preparation for, and you should normally skip it unless you're trying to achieve a Conqueror run (or really want that melee Artifact, in which case you probably would have invested in Brute and Berserker in the first place). The simplest way will be to find and carry with you a [[Thermonuclear bomb]] or some other means to nuke a level, and then find an [[Invulnerability Globe]] on dlevel 17, where you can then go into the Unholy Cathedral invulnerable and nuke the level (which will even still reward you the Artifact). This method however obviously relies on a great deal of luck, and shouldn't be relied on as your main plan, being reserved for non-melee builds who didn't intend to enter the Cathedral but happened upon these circumstances that allowed them to nuke it for some extra EXP.

When it comes to beating the level normally, it all revolves around being able to kill the Angel of Death. With an unmodified Chainsaw and no trait investment you can usually one-shot the Lost souls, while being able to chokehold them in the doorway to their room so they can't surround you. Then with the Demons, you can lure them outside into the lava that will quickly make short work of them. So that just leaves overcoming the Angel of Death in melee combat, whose health will be 290/340/410/500 depending on difficulty, while he boasts an incredible 10 armor to substantially soften your blows and make him an even greater tank than [[John Carmack]]. In addition, he's extremely fast at 150% speed, and his melee attack deals between 16-18 damage, enough to three-four shot any class without [[Ironman]] investment and any armor, while with a [[Red armor]] you'll only be able to take one more hit. So how do you beat him without Brute and Berserker, when you can't possibly hope to outdamage him in melee?

==Weaponry==
So without relying on luck to nuke the level, the thing you're going to need most is a [[Piercing blade|Piercing Chainsaw]]. With his armor, an unmodified Chainsaw will deal 1-14 damage, with several hits doing only 1 damage while averaging less than 5 against him, and bulk modded it will just raise it to a paltry 1-20 while the average will still be below ten damage. With a Piercing Chainsaw, you completely ignore his armor, and your attacks will be dealing 4-28 damage while averaging around 15, a tremendous improvement in your damage output against the Angel of Death while you're not sacrificing that much mods from your other more valuable equipment. A [[Double chainsaw]] and [[Ripper]] will offer even greater damage output despite no piercing effect, but with no Brute nor [[Eagle Eye]] investment, you'll be hitting with the Double chainsaw only a fourth of the time and not even a tenth of a time with the Ripper, which with their heavy mod investment, makes them horribly impractical for the purpose of beating the AoD with a non-melee build.

If you happen to find a [[Butcher's Cleaver]], it will deal 1-20 damage with an average below 10, so it would still be significantly inferior to the Piercing Chainsaw, and its Blademaster effect does nothing in 1-on-1 combat. If you somehow found the [[Dragonslayer]] before the Cathedral and were able to pick it up, then you can just run in and beat this level with no problem at all regardless of your build.

==Armor==
===Standard armors===
The other necessary piece of equipment is an armor with melee resistance, as a standalone Red armor barely helps as covered earlier, and a [[Power mod]] to it ''might'' let you just take one more hit. When it comes to the standard armors, none of them feature melee resistance at base, so the easiest reliable option is the [[Ballistic armor]] assembly, which gives any armor it's applied to an additional 30% melee resistance. Applied to a Red armor, you'll be taking 7-8 damage, so an unboosted Scout/Technician will be able to take 7 hits from the Angel of Death and a Marine will take 8-9 hits, a big improvement when you'll be able to live about twice as long against him between [[Large medkit]]s. However even on HNTR difficulty with the Piercing chainsaw, your life will be getting drained a lot faster than his, when it will take you about 20 hits to kill him assuming all your hits connect (which they won't without Brute/Eagle Eye). Plus your Ballistic Red armor will get damaged and lose half of its resistance around the time you need your first medkit, while the AoD will still have plenty of health left. So the Piercing chainsaw + Ballistic Red armor combo alone won't be viable without a spare, a lot of Large medkits, and maybe copious investment in [[Tough as nails]], and you'll definitely need something more on UV/Nightmare.

The other remotely viable standard option is to make the [[Power armor]] assembly with Red armor. It gives it a 25% melee resistance and an additional point of protection, which too will reduce his damage output to 7-8, so again it's not that good an option. However the armor regenerates and completely removes the movespeed penalty, so it won't be difficult to run away from the AoD while the armor regenerates before confronting him again between medkit uses. You will still need a lot of medkits, but you won't need multiple armors. Power armor requires a coveted [[Nano mod]], and it's very unadvised to make Power armor just for the AoD if you get a Nano mod as it's only a bit better over Ballistic Red armor, so it should only be a really desperate last resort option unless you're making Power Red armor already for general usage.

So preferably you will need some luck on finding an Exotic or Unique armor, but fortunately there are many of them that have melee resistance and you have a decent chance of finding at least one of them before the Unholy Cathedral.

===Exotic/Unique armors===
Among Exotics, there's the [[Ballistic shield]], which with its 95% melee resistance, will reduce any melee attack in the game to 1 damage. Plus being a shield, its resistances won't worsen when durability drops below 50%, so you'll effectively get 100 hits you can take against the Angel of Death with it on, all for 1 damage each (assuming you didn't let it lose durability prior to the Lost souls and Demons earlier in the level, and kept it fresh for the Cathedral), which even on Nightmare will give you way more than enough durability to beat him with just a Piercing chainsaw and no melee investment.

Outside shields, the best Exotic armor for this will be the [[Gothic armor]]. It carries a 50% melee resistance alongside a 6 protection rating, so unmodified the AoD will only be dealing 2-3 damage, allowing you to go over 20 hits without needing to pop a medkit, and it boasts 200% durability, so it will take a really long time before the AoD will be able to damage it. Even on Nightmare you will only need about 1 or 2 medkits, and if you apply a Power mod to it or have TaN investment, he'll only be hitting you for 1 damage, giving you a free win. The nigh-immobility of the Gothic armor is also a nonissue, when you will just be standing there trading blows and when it protects so well that the AoD getting a couple extra hits during medkit usage won't be an issue.

The next best Exotic will be [[Duelist armor]]. It too carries a 50% melee resistance, but with only a 2 protection value. Wearing it at base the AoD will deal 6-7 damage, not much of an improvement over Ballistic Red armor as you might just be able to take one more hit. However with just a Power mod applied, he will be doing 4-5 damage, and now a Scout/Technician at base will take 10-13 hits to kill and a Marine will take 12-15, giving you quite a bit more hits you can take between medkits. It additionally boosts your speed, so if you at least have [[Tactical boots]], you'll be able to run away to pop medkits regardless of [[Hellrunner]] boosts. Above HNTR you'll probably need to apply a [[Bulk mod]] in addition to the Power mod for it to survive more than one medkit round without being damaged if you don't have TaN investment, or otherwise sacrifice its usage for general play outside the Cathedral and turn it Ballistic. A Ballistic Duelist armor will have a massive 80% melee resistance, reducing all hits from the AoD to 1 damage, but that -30% fire resistance means you can no longer wear the Duelist armor when [[VMR]] are around.

Then there's the [[Ballistic vest]], which also carries 50% melee resistance, but only 1 point of protection, so you'll take 1 more point of damage with it than you would with the Duelist; even if you use the Ballistic armor assembly on it to increase its resistance to 80%, you'll still take 2 damage unless you have TaN or were able to make it after [[Whizkid]] 2 and thus be able to apply a Power mod to it. If you find one, you should definitely use that assembly on it if you have no plans to turn it [[Cerberus armor|Cerberus]] as it's not that useful outside the Cathedral, but on UV and Nightmare you may need a bit more to win here if you don't get TaN or Whizkid 2 + a Power mod to reduce the AoD's damage to 1 with it.

[[Phaseshift armor]] has a base 30% melee resistance alongside 2 protection, so you'll be taking 9-10 damage at base, which as you can see previously clearly isn't enough on its own. Turning it Ballistic to get 60% melee resistance will reduce the AoD's damage down to 4-5, which as established previously isn't quite enough above HNTR on its own unless you had [[Whizkid]] 2 and can apply a Power/Bulk mod or have TaN, while turning it Ballistic will lessen its great general usage by giving it a fire vulnerability. Its +25% movement speed at base though, that can be improved to +40% with an [[Agility mod]], makes it ideal for some certain non-conventional strats that will be elaborated on later.

Then there's the [[Medical armor]], which carries 20% melee resistance with 2 protection, obviously not enough. Turning it Ballistic will make it equivalent to the base Duelist armor, making it ok as a spare or otherwise with copious support. If you do use it, remember it starts regenerating your HP back up to 25% when it dips below that mark at the cost of its durability, which is a rather detrimental effect when you want the armor to keeps its protection as long as possible while you can heal instantly anyway with Large medkits, so you might want to use your medkits a bit early if you do have the armor on unless your medkit supply is near diminished.

Among Uniques, there's the [[Shielded Armor]], which with its 90% melee resistance and 2 protection to reduce the AoD's hits to 1 damage, in conjunction with its infinite durability, is pretty much an "I win" button for the Cathedral as long as you have the Piercing chainsaw. Then there's the [[Cybernetic Armor]], which has 50% melee resistance and 7 protection to reduce the AoD's hits to 1-2 damage, but with it being cursed and it having no regeneration, putting it on just for the Cathedral is obviously a bad idea that will cripple you for the rest of your run. If you're a Technician though who put it on and assembled it to [[Nanofiber skin armor]] or [[Cybernano armor]], then you'll be taking only 1 damage while having regenerating armor, giving you a free win here.

==Other items of interest==
When it comes to items besides the obvious medkits you can use to help, the most useful by far is the [[Hatred skull]], as it gives builds without Berserker the ability to get berserked on the level. Even with just Red armor and the Piercing chainsaw the level becomes easily doable for non-melee builds on about any difficulty, and a free win with any of the melee-resistant armor, provided they can get enough turns of berserk. That is the tricky part, as your only source of corpses in the Unholy Cathedral are the Demons, where killing them via lava will obviously leave no corpse, while they'll leave no corpse if you kill them in a doorway, and if you destroy the door to avoid that but kill them in the created chokehold to avoid getting surrounded, their corpses will replace each other and thus potentially leave you with as little as a single corpse. So you'll have to kill the Demons yourself instead of via lava, avoid killing them in a doorway, and leave their corpses scattered, in order to get as much turns of Berserk as you can. The good news is you don't need that many corpses even on Nightmare, so as a rule of thumb you can kill half the demons chokeholded through the doorway (5 on HNTR and HMP, 8 on UV and Nightmare), and then lure the rest outside and avoid killing them on top of each other. You might have to expend a medkit or two, but it will be worth it to get berserked against the AoD, especially if you don't have a good melee-resistant armor. A Hatred skull isn't guaranteed, but you have a good chance of getting one if you killed the [[Agony elemental]] in [[City of Skulls]]/[[Abyssal Plains]].

When it comes to the other skulls, the [[Blood skull]] should unquestionably be saved for [[The Mortuary]]/[[Limbo]], when you'll need ten corpses to get as much healing as a Large medkit, while you'll probably end up losing more than that health trying to kill the Demons that separated from each other. The [[Fire skull]] is a way to deal damage to the AoD outside melee, and each explosion from it can deal over 20 damage to him. With the explosions being able to gib corpses before they explode however, you'll need to kill the Demons really separated from each other to get significant damage on the AoD, so it's definitely not a reliable tool to beating him and it's better saving it for The Mortuary/Limbo. It can come handy though as a last resort to deal a much-needed big punch, when your armor and medkits are depleted with the AoD still not near death.

When it comes to other non-melee ways you can damage the the AoD, there's the [[Arena Master's Staff]], but with it dealing only 1 damage to the AoD while exhausting you, using it for that purpose is a joke. If you have the [[Subtle Knife]], its altfire can be used to deal 5 damage to the AoD, but with it exhausting you and permanently draining 2 HP from your max health, this too is never going to be worth it. The [[Shockwave pack]] will deal around 40-50 damage, a lot more damage than a non-melee build could ever hope to do in a single hit, and taking a good chunk out of the AoD's health. You might want to save a Shockwave pack for a perilous surrounded situation or The Mortuary/Limbo, but it could definitely be the extra push needed to win here if you didn't get good enough melee armor. Then there's the [[Hellwave Pack]], which will deal twice as much damage as the Shockwave pack. Again you might want to save it, but that could be a really big help here if you didn't get a Hatred skull and your armor is lacking.

==Non-conventional strats==
So you're a non-melee build where some combination of factors prevents you from realistically beating the Angel of Death in straightup combat, or simply you don't want to expend all these resources and effort to beat him while still wanting that Conqueror medal, you may be wondering if there's any way to just cheese it if you weren't able to nuke the level. Well one more way to damage the AoD without going into melee range is to a throw a [[Combat knife]] at him. You may be wondering how a thrown knife that will deal only 1 damage all of the time with no Brute, miss half the time without Eagle Eye, and you'll have to pick back up after each throw, would ever be remotely useful for beating the AoD. Well if you can get your movement speed faster than .67 seconds without having to activate [[Run]] (Phaseshift and Duelist armor will be very helpful to passing this benchmark), you can throw the knife a safe distance away, outmaneuver the AoD, pick the knife back up, throw it again, and repeat until the AoD dies, without him ever being able to touch you. Of course with the AoD having 290 health at minimum on the easiest difficulty you can fight him and as high as 500 on Nightmare, it's going to take a '''''loooooooooooooonnnnnnnnnnnggggggggggggggggggg''''' time until he dies, compounded farther by all the time you're going to have to spend lapping him to pick the knife back up inbetween throws. If you found and kept the [[Mjollnir]], another melee weapon you can throw, you can do this strat with it instead of the Combat knife, and since it doesn't leave your hands upon throwing it while some of it hits will deal a little over 1 damage to the AoD without any Brute, this strat will be a lot faster using the Mjollnir, but will still take a very long time.

The other option is to get both your movement and attacking speed faster than the AoD (faster than .67 seconds to be precise), where you will then be able to run away while being able to hit the AoD between its moves without retaliation (reaching that attack speed benchmark with a Scout will just require two levels of Finesse, but a Marine and Technician will need all three levels of Finesse, or two levels of Finesse and a Technical mod on their Chainsaw). If you're fast enough to do this method, your equipment and resources don't matter, and it won't take ridiculously long to kill the AoD as long as you have at least a Chainsaw (though making it piercing and/or having at least one level in Brute/Eagle Eye so you don't miss so often will speed the process up a lot). However to implement this strat, you need to understand how [[Time]] works in DRL, and have an acute enough sense of timing of yours and the AoD's movement to be able to time your hits correctly inbetween the AoD's moves, otherwise you'll just get mauled as you attack. Once you learn the trick, it's not difficult to do (get three tiles away from the AoD, wait a turn, and if he moves two tiles, you'll be able to get a hit in without him hitting back), but this is still something your average player will probably not be comfortable trying, and the margin of error isn't forgiving when any mistake will result in you taking a lot of damage if you don't have one of the aforementioned very strong melee-resistant armors (which considering how slow most of them are, you probably won't be able to use for this strat).

Now what if you're a non-melee build who doesn't have good enough equipment, can't nuke the level, and aren't fast nor patient enough to do those non-conventional strats? Well you're shit out of luck then, the Unholy Cathedral is effectively unwinnable and you'll need to skip it or die. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 03:17, 2 May 2017 (UTC)

Strategy:Acid Spitter

2025-08-11T12:31:38Z

Epyon:

{{infostrat switch}}

At first glance this looks like it could be an incredible weapon; 10d10 power is absolutely ridiculous, it can possibly one shot almost any normal enemy in the game and its average damage of 55 exceeds the maximum damage output of any rocket launcher while it carries a respectably large explosion radius of 3 to demolish hordes of enemies. The acid tiles it leaves behind in its explosion radius will additionally damage enemies farther, and potentially trap them to die if they're left surrounded by acid. It looks like it could be a [[Napalm launcher]] on steroids that just leaves behind acid instead of lava, but if there's a posterchild for awesomely impractical weapons in DRL, the Acid Launcher may take that title.

The critical problem with the weapon is how its ammo and reloading works. The Acid Spitter doesn't utilize conventional ammo, instead it actually uses acid. How it works is it has a clip of 10 that is expended entirely when it's shot, so you only get one shot with this weapon between reloads. Then to restore its ammo you have to be on top of an acid tile and then hit the reload button, where the acid is then absorbed into the Spitter. Each absorbed acid tile counts for 1 point of ammo, so you'll need to walk over and manually absorb 10 acid tiles before the Spitter is fully reloaded and able to be fired again. First this means unless you have a pair of boots that make you immune to acid this weapon is effectively unusable, as you'll need radsuits or excess sources of healing to reload the Spiiter, effectively meaning you'll practically only get to fire this weapon once or twice per level on average. And then even if you do have acid-immune boots, it'll effectively take you 20 actions to fully reload the Spitter; besides that being extremely tedious on its own, you'll typically only be able to fire once when enemies are onscreen, as it doesn't matter how fast your movement and reloading is you're going to be a sitting duck if you actually try to reload this thing with enemies in sight. You could possibly run away to reload it elsewhere, but unless you're in later Phobos or earlier Deimos you probably will lack an adequate source of acid to reload the Spiiter and will be relying on the acid it leaves around to reload, which immediately after firing will be right where the enemies are.

For actual combat purposes the Acid Spitter will be at best a very supplemental situational weapon; its best use will be if you have [[Juggler]], where you can fire it at a group of enemies to substantially weaken them and leave acid around them to inhibit their movement or trap them, while you then utilize Juggler to instantly switch to your primary weapons to finish them off. The one good caveat that comes from its unusual mechanics and ammo is that you won't have to devote any inventory space to ammo for it, and since its shots will usually leave behind enough acid to reload it, it will be self-sufficient without having to rely on other sources of acid spawning. So besides providing a big one-time punch to enemy hordes, it could also save you some ammo too. However, you're probably better off carrying another stack of ammo over keeping the Acid Spitter around, which will usually obsolete its potential ammo saving capabilities unless you're strapped for ammo when you find the Spitter. And of course, this all assumes you have acid-immune boots; if you don't have any and don't plan on making [[Cerberus boots]], absolutely do not bother with the Spitter if you find it.

For one final note, if you are using the Acid Spitter, remember that [[Baron]]s have a massive 50% acid [[resistance]], so they won't be damaged much by it and you can forget about any theoretical one shot kills on them. Despite their great acid resistance, they'll still not cross acid tiles, and if surrounded by acid they won't bother getting out, so you could still utilize the Spitter to inhibit or trap them. Just beware a Baron trapped in acid will take a very long time to die (they only take 1 damage from acid per action), and despite not being able to move, it will still fire at you when you're in sight, so don't dawdle around an acid-trapped Baron. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 08:50, 28 October 2019 (UTC)

For yet one more note, the Acid Spitter gives you a massive +75% acid resistance when equipped, but not when in your prepared slot. This mainly just serves to prevent you from accidentally instagibbing yourself with this weapon if you get caught in its explosion radius rather being something you can get real defensive utility from, as the only two enemies in the game with acid attacks, Barons and their boss variations in the [[Bruiser brother]]s, have the aforementioned 50% acid resistance that makes using this weapon against them laughably ineffectual (especially so for the Bruisers, as they don't take fluid damage and so you can't even attempt to trap them with acid). Melee builds however, can actually get utility from the Acid Spitter's bonus resistance if they have Juggler; while Juggler primarily exists for allowing instant weapon swapping, its other less utilized effect is allowing you to attack with a melee weapon in your prepared slot without having to swap to it. Normally this doesn't provide a real benefit, as you could have just instantly swapped to your prepared melee weapon anyway from Juggler, but the exception is here with the Acid Spitter, as this allows you to keep it equipped in the primary slot to get the +75% acid resistance while still being able to attack with a melee weapon. Considering how difficult it is to get armor with good acid resistance, this niche usecase can come handy to neuter the threat of Barons' acid balls if you're able to effectively exploit it (though they'll still hit you hard in melee if you don't have strong melee-resistant armor too). [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 07:55, 9 July 2024 (UTC)

Strategy:Archangel of 666

2025-08-11T12:31:31Z

Epyon:

{{infostrat switch}}

This challenge is just [[Angel of 100]] on steroids, where instead of the game ending after 100 floors you'll now have 566 more on top of that. It still pretty much plays the same way so the information found in the [[Strategy:Angel of 100|strategy page for Angel of 100]] is fully applicable here, the main difference being that unless you're someone who doesn't value their time at all and actually finds enjoyment from continuing the same DRL run for 566 more floors, '''you are going to start stair diving at some point'''. To make the stair diving most efficient to clear the additional 566 levels of grind as fast as possible you will need to pick a Scout for your class, playing a Marine or Technician will just needlessly cost you hours of additional time in your stair diving and make this so much grindier.

For some additional notes, the danger level used for level generation '''does''' stop rising after dlevel 100, so from that point forward there will be nothing new and levels cannot get anymore dangerous. If you want the [[Experience Cross]], this will be one of the only three realistic ways you can reach the max level of 25 to obtain it. This will additionally be the easiest way of the three methods to obtain it, as the other two require either playing Angel of 100 on [[Nightmare]] difficulty or combining [[Angel of Darkness]] with Angel of 100 in a Dual-Angel challenge. Then for the final note the [[Apostle]] does still spawn here on the final floor if you reach it with the [[Dragonslayer]] and [[Berserker Armor]] equipped. So if you want to kill him for the [[Apostle Insignia]] or for whatever reason, this will be the closest way you can guarantee it happening in a run without save scumming, as it still requires a lot of luck in Angel of 100, and an extreme amount of luck in the normal game whether you're relying on random drops or actually try for the guaranteed drops on Nightmare. As it is, each Unique can only spawn once in a game, so besides there being 565 more floors for the Dragonslayer and Berserker Armor to spawn in, other Uniques will be gradually taken out of the item generation pool as they spawn, gradually increasing the chances of you finding the DS and BA as you go on. If you're trying to do this and are stair diving, just pay attention to the level feeling at the start of each dlevel as it will notify you if a Unique has been spawned. If nothing, you can just head straight for the stairs, and if there is you can just seek it out, pick it up to take it out of the item generation pool, and keep going until you find the DS and BA. You can also run a few Ao666 games doing this to build your overall Unique collection for the Armorer [[badges]], where the gold badge requires finding all Exotics and Uniques, the platinum badge requires obtaining 1000 cumulative Exotics and Uniques total on your file, and the diamond badge requires you obtaining 3 of each Exotic and Unique on your file. There are 26 Uniques total, so you're essentially guaranteed to come across them all in 666 floors, so speedrunning a few Ao666 runs will be the fastest way to obtain all the Armorer badges and probably the easiest diamond badge. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 07:10, 31 October 2019 (UTC)

Strategy:Army of the Dead

2025-08-11T12:31:23Z

Epyon:

{{infostrat switch}}

When it comes to [[Shotgun Types|shotguns]], there are two primary weaknesses; shotguns have much worse DPS potential than other weapon types, and [[shrapnel]] [[damage]] gets doubly reduced by [[armor]], which not only compounds the aforementioned DPS issue, but also substantially hurts the ammo efficiency of shotguns when you start having to regularly fight enemies with 2 armor, such as [[Baron]]s, [[Former commando]]s, [[Arachnotron]]s, and the [[VMR]]. This can especially hurt later in the game, when [[shotgun shell]]s can become rather scarce, with them spawning less often and [[Former sergeant]]s stop spawning outside of [[monster group]]s, leading to shotgun builds possibly finding themselves short on shells in Hell. The latter problem can be addressed by the [[Marine]]'s shotgun mastery, Army of the Dead (MAD for short), which turns the damage type of all shrapnel weapons to piercing. This means instead of your shotguns' damage being doubly reduced by armor, they now completely ignore armor. So against all those aforementioned enemies with 2 armor, your shotguns will be dealing 4 more damage per hit, while against certain nightmare enemies and bosses, you can see an even greater damage increase. Put that way though, considering most of the time you're getting either just 2 or 4 extra damage per shotgun shot, you may be thinking this sounds underwhelming compared to some of the crazy stuff and unique utilities other masteries can do, when you'll ultimately just be saving a shell or two on those bigger baddies, and well... you would be right. But still it's a nice perk to have, so what's the catch? Well, there's some really big catches, that makes Army of the Dead one of the worst masteries in the game.

==The costs of Army of the Dead==
So what makes Army of the Dead so bad? A crucial part of masteries is that each of them will block you out from being able to pick certain traits. For most masteries, there may be a trait or two you may have wanted, but for the most part the tradeoff is well worth it. When it comes to Army of the Dead, you get blocked... [[Strategy:Eagle Eye|Eagle Eye]], [[Strategy:Hellrunner|Hellrunner]], and [[Strategy:Finesse|Finesse]]. ''Oh damn''.....

So starting with Eagle Eye, at first it sounds like no big deal, and true Eagle Eye itself is nothing, when shotguns can't miss anyway. But no Eagle Eye and not being a [[Scout]] means you can't get [[Strategy:Intuition|Intuition]], which aside from being one of the most useful traits in general, is especially valuable for shotgun builds, as they can exploit shotguns maintaining perfect accuracy against enemies outside their vision range that Intuition lets you see, and it saves them precious shells by no longer having to [[radar shoot]] to make sure they don't walk into the view of something nasty. The fact you'll have to keep radar shooting throughout the game with MAD negates one of mastery's supposed advantages of saving you shells. Losing just Intuition wouldn't be a dealbreaker however, especially since it would have required picking up two dead levels in Eagle Eye to even get, but then...

...Losing Hellrunner is a far bigger loss. Hellrunner itself is another very useful trait on its own regardless of build, as movement speed is so crucial in DRL, and a boosted [[dodging]] rate is also very handy to keeping you alive; nothing reduces damage more than not getting hit at all. But it's especially important for shotgun builds, as when you don't have the DPS to quickly smite enemies before they can hurt you, you're going to really need movement speed to limit damage you take, while fast movement speed is also needed to best utilize [[Strategy:Shottyman|Shottyman]]; after all the faster you can move, the faster you can reload with Shottyman, and the added dodging bonus of Hellrunner also ensures you're much safer when you're reloading with Shottyman in view of enemies. So with MAD, you'll be entirely dependent on equipment to increase your movement speed, which at best, will reliably come down to just [[Tactical boots]] and [[Tactical armor]], the latter of which will leave you very vulnerable with its complete lack of any protection; anything better will depend on getting lucky with rare [[Exotic]] and [[Unique]] drops. Also, since you need to take [[Strategy:Badass|Badass]] to get MAD, the knockback reduction from it nerfs your [[rocket jump]]s, making you even slower and making it even more difficult to get out of bad spots. On top of that with no Hellrunner, you can't get [[Strategy:Dodgemaster|Dodgemaster]], which does a lot to make open combat viable for shotguns, letting you dance through enemy attacks while simultaneously reloading with Shottyman, and it means you can no longer completely trivialize the [[Cyberdemon]], which is especially needed when your DPS is gonna be shit. At this point, Army of the Dead's viability is already tanked, but it doesn't stop here...

The last trait that Army of the Dead blocks is... Finesse, which is arguably even worse than being blocked Hellrunner. Not being able to improve your firing speed has two big effects; first it significantly hinders your DPS, and when you already struggle for DPS as a shotgun build, losing out on one of your only ways to improve it obviously really really sucks. The second big effect is it also make you a lot less safe in general, as any time you fire nearly ensures enemies will be able to retaliate as long as they can see you, and again as a shotgun build, you really need to be able to compensate for your lackluster DPS by being able to fire and stay on the move to limit enemies being able to attack you. That isn't all though, being blocked Finesse blocks [[Strategy:Juggler|Juggler]], which is another big loss for shotgun builds when they'll be utilizing a variety of shotguns ''and'' making heavier usage of the [[Rocket launcher]] than other builds will, meaning you won't be able to quickly switch between whichever weapon is best for the situation at hand, nor pull off the "shoot shotgun, instantly pull out another shotgun to shoot without reloading" trick. The pain train doesn't even stop there, as blocking Finesse '''''also''''' blocks [[Strategy:Whizkid|Whizkid]]. Being blocked Whizkid means you'll only ever able to apply a single mod to any weapon or equipment '''ever''', which is gonna suck when there are multiple good exotic shotguns like the [[Assault shotgun]], [[Plasma shotgun]], and best of all, the [[Super shotgun]], that MAD users will not be able to trick out like other shotgun builds get the joy of. It additionally means you won't ever be able to make a [[Focused double shotgun]], leaving you stuck with the vastly inferior [[Double shotgun]] for your big boomstick if you're not lucky enough to find a Super shotgun, while you're gonna all-around move even slower and be less protected when you're only ever limited to a single mod per equipment and basic [[assemblies]]. Worst of all, if you are lucky enough to find a [[Nano mod]], you cannot make any [[Nano-shrapnel]] shotgun to potentially autowin the game, nor can you make [[Antigrav boots]] to salvage your terrible movement speed. For one last kick in the groin, through Whizkid, other shotgun builds can easily make their shotguns hit as hard or even harder than MAD's shotguns will with just multiple [[Power mod]]s and assemblies, so there completely goes any sort of advantage MAD could have had.

So with Army of the Dead, you're much slower than other shotgun builds in every way, your DPS is much worse than other shotgun builds, and you ultimately don't even get the edge on lategame ammo efficiency when Whizkid can shore that up for other shotgun builds.

==How to make Army of the Dead work==
If you're a masochist that still wants to give Army of the Dead a try at this point, first and most important thing to know is you're going to need to really ''really'' love [[corner shoot]]ing. Corner shooting is already a crucial component for shotguns and DRL as a whole, but MAD just takes it to an absurd level. Other shotgun builds can eventually get the all-around speed to be able to get into open firefights and come out on top, especially [[Strategy:Shottyhead|Shottyheads]] with their crazy firing speed, while [[Strategy:Fireangel|Fireangels]] can leverage their immunity to splash damage to zoom everywhere with rocket jumps and laugh at the VMR's futile attempts to harm them. But when your movement speed is ass, your firing speed is ass, and your DPS is bottom-of-the-barrel, the only way to survive is eternally hugging behind that corner and slowly taking things out one or two at a time when they come into view. If playing the whole game clinging behind corners just to survive is gonna bore you to sleep, absolutely do not play MAD outside of the easier difficulties, as ''you will fail'' trying to play MAD in any more aggressive way.

The other vital thing to make MAD less awful to play is to invest in [[Brute]] and [[Berserker]], becoming a hybrid melee build. When you're so damn slow and your DPS is so shit, you realistically are just not going to be able to beat many of the bosses relying on your shotguns, without having very good armor and lots of [[Large medkit]]s. By having strong melee and Berserker, you'll be able to actually out-DPS them or at least won't need an insane amount of medkits to survive, while the guaranteed [[Longinus Spear]] or [[Azrael's Scythe]] from the [[Unholy Cathedral]] ensures you'll get an extremely powerful melee weapon for the late game that being able to use competently could save your ass if you ever find yourself having to fight in the open. Having the ability to get [[Berserk]]ed in general could also be the difference between survival and death, when it gives you such a big all-around speed improvement, on top of making you far tankier, something such a slow build really needs. One of the very few bright spots about MAD is that it lets you pick any one non-blocked trait of your choosing on the way to building to it, so you'll be able to pick up a level of Brute without delaying it and then get to Berserker only two more levels after getting MAD. It's probably a better idea however to delay getting MAD by heading straight to Berserker after spending your first three levels on the requisite two levels of [[Strategy:Reloader|Reloader]] and [[Strategy:Shottyman|Shottyman]], as [[Strategy:Badass|Badass]] is a pretty dead level and MAD isn't any sort of major boost as made very clear long ago, especially so on harder difficulties when Berserker + the [[Chainsaw]] might be the only thing that keeps you alive when staring down multiple [[Baron]]s, [[Commando]]s, and [[Revenant]]s near the end of Phobos. Hell, there might be an argument to go straight to Berserker at the start instead of Shottyman because it's so critical to patch up MAD's huge shortcomings (though you probably should just start with going straight to Shottyman, as making your Shotguns better will help you more in the early game, Brute isn't doing much before you get a [[Chainsaw]]). You might even end up finding yourself fighting in melee more often than actually using your shotguns with a MAD build, at which point, you might be wondering why didn't you just go with [[Strategy:Vampyre|Vampyre]]; it blocks [[Strategy:Eagle Eye|Eagle Eye]] (thus [[Strategy:Intuition|Intuition]]) and [[Strategy:Hellrunner|Hellrunner]] (thus also [[Strategy:Dodgemaster|Dodgemaster]]) too, but [[Strategy:Finesse|Finesse]] (and thus also [[Strategy:Whizkid|Whizkid]]) are still available, while Vampyre itself is a ''far more'' rewarding mastery than MAD could ever be. But if you're this insistent on trying out Army of the Dead, this is your best shot at making it work.

As for trying to sidearm rapid-fire weapons or pistols with Army of the Dead, don't even try. With no Eagle Eye, your rapid-fire weapons aren't hitting anything worth a damn unless you're lucky enough to find a [[Laser rifle]] (in which case, it will be a very good sidearm weapon), and no Whizkid means you can't try to compensate for their inaccuracy by adding multiple [[agility mod]]s to them. Then with pistols, aside from them demanding more trait and inventory investment than melee does to become viable, no Whizkid just completely kills any pistol viability, as modding is absolutely essential to get a good pistol when there is no guaranteed pistol stronger than the basic peashooter you start with. So aside from investment in Brute and Berserker, that only leaves investing in [[Strategy:Ironman|Ironman]] and [[Strategy:Tough as Nails|Tough as Nails]] to try making yourself as tanky as possible. Do note that investing in Ironman even once means you can no longer guarantee activating Berserker from an [[Arch-vile]]'s blast, which can prove very clutch, so investing in TaN should probably be the priority. [[Strategy:Son of a Bitch|Son of a Bitch]] is an option too to try doing something to boost your crappy damage output, though considering how shotguns and melee see little relative benefit from it, especially when you have such poor firing speed, maximizing your survival is probably better (unless you find the aforementioned Laser rifle that is). As long as you're not investing in Ironman to keep the ability to easily get berserked from Arch-viles, you should invest in SoB before Ironman, but probably not before TaN.

==Assemblies and miscellaneous tips==
Well with no [[Strategy:Whizkid|Whizkid]], Army of the Dead's choices for [[assemblies]] are very limited, but for what you can do, here are your options of particular note.

*[[Tactical boots]] - An essential assembly for any build, but there is especially no argument for MAD not building them ASAP; this will be your best guaranteed source of improving your movement speed in the game, and there is little else you could use your [[agility mod]]s for as a shotgun build that can't even build a [[Focused double shotgun]].

*[[Tactical shotgun]] - One mercy MAD gets is it can still build a Tactical shotgun, the most crucial weapon for any shotgun build that isn't lucky enough to find an [[Assault shotgun]] very early, so it's an obvious priority. It's probably even more vital for MAD, as given how slow they move, having to pump a [[Combat shotgun]] between shots is gonna be an even greater hindrance to them.

*[[Elephant gun]] - Given that you're blocked from getting the Focused double shotgun, and can never apply more than a single [[power mod]] to any weapon, an Elephant gun is MAD's most ammo efficient weapon and most powerful option against enemies more than a few tiles away that the [[Double shotgun]] can't effectively damage, unless they're lucky enough to find the [[Super shotgun]]. Additionally, given the inability to use the mods much for elsewhere, MAD probably won't mind the cost of two power mods that other shotgun builds might balk at. Just be really sure you have a [[shell box]] onhand when using this weapon, especially when relying on [[Strategy:Shottyman|Shottyman]] to reload isn't going to work as well with how slow you're gonna be.

*[[Tactical armor]] - An armor with 0 protection and no [[resistance]]s is really unattractive, but this will be your best guaranteed source of movement speed via armor, and as long established, you need all the movement speed you can get. The 15% [[dodging]] rate it gives could save you too, and it's the only way to improve your base dodging rate without [[Strategy:Hellrunner|Hellrunner]]. You're probably still better off getting as protected as you can with your armor, but anything short of [[Red armor]] or a good [[exotic]]/[[unique]] armor is unlikely to do you better than this, and again you're probably not going to be putting those agility mods to much use elsewhere after making Tactical boots, so the mod cost isn't the concern it is to other builds. It will also make a good complimentary piece in general to your primary protection armor, when you can wear it to move around with some semblance of a decent pace, while switching to the heavier armor when dangerous combat is unavoidable.

*[[Piercing blade|Piercing chainsaw]] - A Piercing chainsaw is normally inferior to just applying a [[bulk mod]] to a [[Chainsaw]], but there's one scenario where it really shines - fighting the [[Angel of Death]] to pierce through his insane 10 [[armor]]. Considering how important getting the [[artifact]] from the [[Unholy Cathedral]] will be to win the game with MAD, dedicating an assembly entirely for the purpose of beating it at the expense of having a slightly weaker melee weapon up to that point is very much worth it. This is especially so as with no [[Strategy:Finesse|Finesse]] investment to improve your attacking speed, and no actual melee mastery, you may find yourself losing the damage race with a standard Chainsaw against the Angel of Death on harder difficulties even with [[Strategy:Brute|Brute]] + [[Strategy:Berserker|Berserker]], especially if you don't find any armor with good melee resistance before then.

*[[Power armor|Power Red armor]] - If you're lucky enough to find a [[nano mod]] with MAD, Power Red armor is really all you can do with it. With no Whizkid, you're blocked off from [[Nano-shrapnel]], [[Antigrav boots]], [[Cybernano armor]], and [[Nanofiber skin armor]], while a nano mod on its own won't do much for a shotgun. That just leaves Power Red armor, which is a bummer compared to the amazing game-breaking stuff that a nano mod can allow other builds to make, but Power Red armor is still an extremely good armor; it's practically a [[Fireproof armor|Fireproof Red armor]], except with a 25% melee ''resistance'' instead of -30% weakness, an extra point of protection, regenerating durability, and best of all, no movement penalty. It's not remotely game-breaking, but it's still probably the best armor a build with no Whizkid can ask for aside from maybe [[Malek's Armor]], which is an even luckier find than getting a nano mod.

*[[Lava boots]] - If you get an [[onyx mod]] as MAD, and do not also find an [[Energy-shielded vest]], [[Phaseshift armor]], or [[Duelist armor]] to use that onyx mod on, nor found [[Enviroboots]] to freely walk through damaging fluids, it might actually be worth building Lava boots. Being able to freely walk through lava is such a tremendous advantage even if it slows you down a ton, as covered in the [[Cerberus boots]]' [[Strategy:Cerberus boots|strategy page]], of which MAD cannot ever build with its lack of Whizkid, while you won't get exceptional mileage out of using your lone mod slot on getting infinite durability for vanilla Red armor or any exotic armor that wasn't one of the three mentioned prior. Of course -30% movement speed when you're already so slow really really sucks though, so if you do build Lava boots as MAD, only put them on when going through lava is imperative, and be sure to immediately take them off once you get out of lava. You could build a [[Tower shield]] instead with that onyx mod to try maximizing your durability, but that 12 protection isn't quite as impressive as it looks with no resistances, and 150% durability that cannot be restored without a [[Megasphere]] won't last that long, nevermind the -50% movement speed penalty it has when you're already struggling so much for speed...

Overall, while it may not be in the same shit tier as near-unusable masteries like [[Strategy:Bullet Dance|Bullet Dance]] and [[Strategy:Entrenchment|Entrenchment]], Army of the Dead fucking sucks. If you want to play a tanky [[Marine]] shotgun build, you would actually be better off going masterless. You'll still be a lot worse than [[Strategy:Shottyhead|Shottyhead]] and even [[Strategy:Fireangel|Fireangel]], and it overall would be a pretty mediocre build, but being able to actually invest in some combination of [[Strategy:Hellrunner|Hellrunner]], [[Strategy:Dodgemaster|Dodgemaster]], Finesse, [[Strategy:Juggler|Juggler]], and especially Whizkid will do so much more for you than getting piercing shotguns ever will. Pick Army of the Dead only if you are explicitly looking to challenge yourself by being denied these essential traits (it's the only reason I ever tried runs with MAD, which were never pleasant). Also for one final note, picking Army of the Dead in [[Angel of Shotgunnery]] looks like an attractive option because of how concerned people get about shell shortages in Hell, and indeed it's a popular choice for it, but there you will not have melee to bail you out when you get into a fight with a big horde or boss that you cannot possibly hope to out-DPS with your slow ass shotguns nor effectively evade with your snail-like mobility, while lategame ammo efficiency can be addressed by Whizkid as mentioned prior (while you can just always farm [[Sergeant]]s in an [[Arch-vile]] [[group]] for a bit if you need to, they're not uncommon). If you really don't like Shottyhead for whatever reason or are just tired of always picking [[Scout]]s and want to try something different, then the aforementioned masterless Marine build will do a lot better than MAD would. Also absolutely do not pick MAD in [[Angel of 100]], all those blocked traits just become even more important there; good luck surviving a [[Nightmare arachnotron]] [[cave]] when your movement speed is barely over 100% and you get near-instantly melted by a stream of plasma from all over after making a single move, not to mention how miserable it'll be to get all the mods you'll find over 100 levels and not be able to do shit with them. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 22:56, 27 June 2023 (UTC)

Strategy:Hey, Not Too Rough

2025-08-11T12:31:13Z

Epyon:

{{infostrat switch}}

Hey, Not Too Rough is trivial for DRL veterans, who will be able to win a standard game at this difficulty virtually every time no matter their build, unless they're playing some hard challenge. Make no mistake though, the jump from [[Strategy:I'm Too Young to Die|I'm Too Young to Die]] to HNTR isn't an easy one, and most newer players who jump to it after conquering ITYTD ''will'' get stomped at least their first few times (and those who claim otherwise are probably lying). Aside from more enemies, all those bonuses you had on ITYTD are gone; no more doubled ammo pickups, no more inaccurate enemies, no more half damaging [[fluids]], [[Small medkit]]s and [[Small Health Globe]]s no longer heal double, time-based powerups no longer have twice the duration, and you get a lot less EXP from each kill. Special levels additionally will be tougher; [[Phobos Anomaly]] in particular is the most notorious example, as while you just had a straight fight with the [[Bruiser brother]]s on ITYTD, you will now have to deal with a nasty [[Lost soul]] ambush that will assuredly wreck players their first time through. While you could get away with running around guns blazing on ITYTD thanks to all that extra ammo, health, and longer powerups, HNTR will kick your teeth in for doing the same and will make you learn the ropes of the game. If you find yourself struggling to get over the first hump for new players that is HNTR, here are some pointers that will help you out:

*First and foremost, minimizing damage you take is important! With small health sources healing half what they did in ITYTD and enemies now hitting your more often, you can't just shrug off hits so easily anymore and will find yourself running out of health fast if you keep trying to tank hits.

*Have you been [[Corner shooting]], [[Radar shooting]], and [[Gift dropping]]? These are vital survival techniques that will go a very long way in minimizing the damage you take, and are absolutely necessary to learn if you ever want to try taking on the difficulties beyond HNTR. If you don't know what those techniques are, '''''go read their respective pages right now''''' (if corner shooting still doesn't have a page by the time you read this, check out the strategy page for [[Strategy:The Wall|The Wall]] instead to get a good primer on how to corner shoot).

*Pick your [[traits]] with a plan, picking traits at essentially random or whatever you think sounds cool at that moment will kneecap your attempts to overcome HNTR. If for example for your first five levels you went; [[Strategy:Son of a Gun|Son of a Gun]] -> [[Strategy:Badass|Badass]] -> [[Strategy:Brute|Brute]] -> [[Strategy:Reloader|Reloader]] -> [[Strategy:Son of a Bitch|Son of a Bitch]]; you'll be barely any stronger than you were when you first entered [[Phobos Base Entry]] and not be able to use any weapon particularly well, while now being at the point you're about to enter Phobos Anomaly and Deimos, where you will start regularly fighting enemies stronger than the measly formers and [[Imp]]s. If you don't have a strong grasp on the build you're going for and what traits will best facilitate your desired build, you should just plan a master trait you want from the outset and strictly only pick the traits that build to it to get your mastery as quick as possible, while then experimenting with other traits once you get your mastery. The optimal way to invest in traits doesn't necessarily require immediately gunning your mastery, plenty of high level DRL players have even claimed that going with no mastery is the most optimal build of all, but for newer players who don't yet fully understand the advantages of each trait, when most masteries generally require traits that facilitate their build and will largely block traits that would only serve as diversions, sticking to their mastery path will steer such players from picking the wrong traits and get them a fairly competent build.

*You will have to start considering the risk/reward of entering special levels, and in turn recognize when you will have to pass up on entering a special level as you don't have the resources to realistically beat it, instead of just blindly going down every set of red stairs you see. One perk of "graduating" to HNTR is that you can encounter all those special levels that didn't show up on ITYTD, but this exemplifies even more that special levels will not always be beatable. [[Unholy Cathedral]] and [[The Mortuary]]/[[Limbo]] are the most notorious examples, as players will have many runs that just will not have what it takes to beat those levels by the time they appear, and trying to do so will ensure a grisly demise. You will also have to recognize when you can only partially clear out a special level and be willing to cut your losses if things get too dicey. E.g. did you clear out [[Deimos Lab]] and just have the [[Shambler]]s left, but you got no medkits left nor even a healthy [[Blue armor]]? You best not hit the switches to release them and just leave with what you got, unless you want to kiss your run goodbye.

*Learn the [[assemblies]]! Assemblies can get you some very good equipment that doesn't rely on you getting lucky with an [[exotic]] or [[unique]] drops, and equipment can do more to power you up than just traits will. [[Tactical boots]] and [[Fireproof armor]] (particularly on [[Red armor]]) are two basic assemblies in particular that are easy to make every run and will be very helpful to about any build, if you haven't been building them start doing so. The [[Tactical shotgun]] is another very good basic assembly that's not only vital for shotgun builds, but will be very useful to any other build that keeps a shotgun handy for their utility purposes and corner shooting, as long as they can spare the mods for it. Be sure to check each assembly's strategy page for more helpful information on how they're best utilized, though be sure to try experimenting with them yourself, just building the aforementioned three basic assemblies will do a lot of heavy lifting.

*Be mindful of your ammo consumption. You shouldn't be struggling for ammo on HNTR, but still if you are just shooting blindly at everything and making no effort to stockpile ammo, you may find the reduced ammo pickups to start stinging you a bit. Try to carry at least a few stacks of ammo for your build's primary weapon, and if you're a shotgun build, try to make that four or five before you enter Hell. Also pay attention to the enemies that are in a level and try to actively utilize weapons they will replenish. Are there [[Former sergeant]]s abound? Go loose with your shotguns. [[Former captain]]s? Rev up your [[pistol]]s or [[chaingun]]. [[Revenant]]s and [[Mancubi]]? Get some use out of your [[rocket launcher]]. Are [[Former commando]]s lurking or a bunch of [[Arachnotron]]s stomping around? Get less stingy with your plasma weapons.

*Don't immediately grab powerups the instant you see them. Find a salivating [[Berserk Pack]] or [[Invulnerability Globe]], but you're in good shape as is and most of the enemies on the level are already dead? Leave them, mop up the rest of the level, and then grab them right before you go to the next level; you will carry powerup effects with you into the next level, and often the immediate beginning of a level can be the hardest part, as DRL loves to spawn you in a room full of baddies (which becomes progressively more common the higher the difficulty). Conversely, don't try to hoard powerups too much; if you're getting your ass kicked in a level or there's a nasty situation coming up, go retreat to your powerups and get them ASAP, those powerups can't help you if you died before you could even use them.

*On a related note, try to avoid hoarding your items and actually use them in the moments that they're needed. It might sting to have to "waste" a [[Large medkit]] when you're at only 50% health, as you may have wanted to save it for when you're on the brink of death to get more mileage out of it, but it is often better to be safe than sorry when you got enemies around who can suddenly wipe out half your health. Don't end up like the countless players who died with an inventory full of medkits.

*Have you learned what [[run]]ning is and utilized it yet? Have you also learned [[rocket jump]]ing? These are vital abilities '''''that will''''' save your ass in countless runs, and getting the hang of how to utilize them is absolutely necessary if you're gonna ever try playing the difficulties above HNTR.

That should cover much of the basics. Before long, you should get a broader understanding of how to play D the Roguelike and be able to conquer Hey, Not Too Rough, but don't feel bad if it takes you several runs to get your first victory, every failed run is a learning experience. Once you do get a handle on HNTR and the standard game is no longer much of a challenge, you can try the various [[Angel Challenges]], which you wouldn't have been able to play before on ITYTD, and then you can start thinking of making the next step to [[Strategy:Hurt Me Plenty|Hurt Me Plenty]]. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 08:49, 8 July 2023 (UTC)

Strategy:Tactical boots

2025-08-11T12:30:49Z

Epyon:

{{infostrat switch}}

==Patch notes==
===Pre-0.9.9.4===
Tactical Boots had 1 [[protection]], gave +20% movement [[speed]], gave -25% [[knockback]], and regenerated 1% durability per action.

===0.9.9.4===
Tactical Boots's movement speed bonus was nerfed to 10%, and its knockback resistance was reduced to -15%.

===0.9.9.6===
Tactical Boots now have 0 protection, but its movement speed was buffed up to +15%, the knockback resistance was removed, and it gives a +10% dodging bonus. Its regeneration was also buffed to recover 2% durability per action, albeit it now doesn't start regenerating until 5 actions without being damaged.

===0.9.9.7===
Tactical Boots was nerfed by having the dodging bonus removed entirely.

==Overview==
Tactical Boots is one of the big three staple assemblies alongside [[Fireproof armor]] and the [[Tactical shotgun]], and almost certainly reigns supreme as the most commonly made assembly of all. Only +15% movement speed doesn't sound amazing, and having no protection for your feet sounds bad when that is supposed to be the point of boots, but faster movement speed is very important for offensive and defensive purposes. Being able to outmaneuver even lowly [[Imp]]s without having to activate [[Run]] is a lot more useful than you would think, let alone outmaneuvering [[Hell knight]]s and [[Baron]]s that are the bane of players on Phobos when playing [[Ultra-violence]], and having your running speed be faster than [[Demon]]s, [[Revenant]]s, and [[Arachnotron]]s without [[Hellrunner]] will absolutely save your ass. You can read Hellrunner's [[Strategy:Hellrunner|strategy page]] for all the virtues that having faster movement speed grants.

The main thing that makes Tactical Boots so good is its cheap investment cost and its splashability. To assemble, it just requires common [[Steel boots]] and two [[agility mod]]s, the ingredients for which you can sometimes have after [[The Chained Court]] and will usually have before [[Phobos Anomaly]] if you don't skip out on [[Military Base]]/[[Phobos Lab]]. Then when it comes to splashability, every build in any sort of challenge benefits significantly from having more movement speed, so you'll want more movement speed as soon as you can get it. Now as mentioned earlier, Tactical Boots provide absolutely no protection against [[fluids]], but the thing is you can usually just avoid running into them, so the movement speed of your boots is far more important, and if you are concerned about scenarios where you're forced to run across fluids to progress or fighting in situations where you risk getting knocked into a pool of acid/lava, you can just carry another pair of boots with better protection while wearing your Tactical Boots for all other situations. Another knock one may levy against Tactical Boots is that the second agility mod to assemble only adds +5% movement speed over what the first agility mod added to the requisite Steel Boots (or any other pair of standard boots), while adding it to your [[armor]] instead will give it +15% movement speed, overall giving you an effective +25% movement speed boost when combined with the A-modded Steel Boots. However, the other thing that makes Tactical Boots great is that you'll get to always keep them on to always benefit from its speed boost (and their durability even regenerates if they get damaged, so you should never lose them), whereas you'll be constantly cycling through armors from them getting worn down or to utilize armor more suited for the battle at hand, so it'll generally serve you best to prioritize making your boots faster before your armors (not to mention that you'll be very unlikely to have anything better than [[Blue armor]] before the guaranteed [[Red armor]] in Phobos Anomaly).

For the final note on Tactical Boots, you can make their movement speed even faster if you got [[Whizkid]] 2, which allows you to apply a single mod to assemblies. There is no need to bother going through the other mod options, applying an agility mod is the only mod you should consider for your Tactical Boots, adding another +10% movement speed and overall giving +25% movement speed, tied with A-modded [[Phaseshift boots]] for the second fastest boots and only beaten by [[Antigrav boots]] that require a rare [[nano mod]] to create. Unfortunately in 0.9.9.7, you can only mod assembles you made ''after'' you get WK2, and since Tactical Boots is an assembly you'll almost always make in Phobos while WK2 is something you'll usually pick up at least a few levels into Deimos, you'll rarely get to utilize this outside of [[Angel of 100]] unless you're willing to put off assembling your Tactical Boots until you get WK2 or are willing to make another pair after getting WK2, either scenario usually being unideal. Fortunately in the upcoming long-awaited 0.9.9.8, WK2 had that dumb restriction removed and so you'll be able to mod your assemblies regardless of when you made them, allowing you to put another agility mod on those early Tactical Boots you make and solidifying this assembly's place as '''''the''''' staple assembly of DRL. [[User:Omega Tyrant|Omega Tyrant]] ([[User talk:Omega Tyrant|talk]]) 09:17, 6 July 2024 (UTC)

Strategy:Double shotgun

2025-08-11T12:30:04Z

Epyon:

__NOTOC__
{{infostrat switch}}
== Main Guide (v0.9.9.5) ==

=== General Tactics ===
Basic strategy posted by [[User:Kashi|Kashi]] 19:11 January 12, 2012 (GMT).

Ah, the Double Shotgun, one of the most emblematic weapons that ever existed in the game. It's the bigger, nastier brother of the normal shotgun, carrying an even deadlier pack that comes on a two-hitting blast, sending enemies flying towards the unknown in just one go. Still, while this weapon has very good pros, the cons balance them, turning what could be a gamebreaking weapon into a merely incredible one, depending on the use one gives to it. Yes, its strenghts are limited to what one decides to do, because the many drawbacks it has (Its range being the main one) turns it into a bad choice to use most of the time, unless one has the corresponding traits that bring out the best qualities of the weapon itself.

The main use of the double shotgun, which is a marked difference to other [[Damage_type#Shrapnel|shrapnel-based]] weapons in the game, is at short range while dealing with packs of mobs, as the weapon itself has an horrendous damage reduction based on the range, limiting the pain it can cause to the monsters if the are beyond 6 squares from the player. This is normally a problem for new players, as it's common to make the mistake of firing the double shotty as a long-range weapon, failing to cause any harm to the enemies. Another problem it has is that it consumes ammo the same as a fat child eating candies, as each fire makes use of '''two''' shots per use, combining it with a 2 second reload time, double of what the normal shotty has.

Still, this weapon can be a lifesaver when in a pinch (And by pinch, we mean "Surrounded by mobs"), as each shell fired from it counts as separate attacks, dealing damage and sending knockback '''separately'''. This can be translated as "The enemy flies farther and get damaged even more than with a normal shotty". Even though, the same disadvantages other shotguns have, namely the "shrapnel"-type of damage they cause, appear on the double shotgun, as it makes it a terrible choice when dealing with armored enemies, unless one assembles a [[Plasmatic shrapnel]] or gets the trait [[Traits#Army_of_the_Dead|Army of the Dead]].

While the weapon itself carries on with its good use even at late-game, the main problem that affects it at that stage is the same that can happen everytime, which is the lack of ammo. This, at the beginning, can be slightly handwaved, as enemies that drop shells are common, but during late-game levels, the number of spawned former sergeants drop, marking an end to the weapon itself, unless one makes use of the Plasmatic Shrapnel as a self-producing ammo factory, of course.

=== Modifications ===
At the current version of DRL (0.9.9.5), there are three possible assemblies that can be used on this weapon. Interestingly enough, two of them makes use of a unique mod that doesn't appear very often.

The first one, and the most simple is the Plasmatic Shrapnel, which can come in two flavors depending the way in which the shotgun gains more damage (And the eponymous change in damage type) or it gains the ability to manufacture its own ammo (At the cost of reloading) and gaining the plasma damage, too. This, while making use of a rare Nano Pack, it eliminates some of the disadvantages the weapon has, turning it into a viable choice even at late stages due to the change from shrapnel to plasma damage, also solving the ammo problem. Still, this doesn't do a thing about the lack of range, which is solved by another assembly.

Next comes the [[Nano-shrapnel]], which can do the same as the Plasmatic Shrapnel, but changing the damage type of the weapon to piercing instead of plasma. In my honest opinion, while this one ignores armor altogether, plasma can be better, because of the ability to destroy walls. Same thing, but it can be a bit stronger, depending how do you assemble the mods.

And the last, but not least, is the [[Focused double shotgun]], a souped-up version of the unmodded double shotty, which raises the damage it can cause, while changing the type of spread the weapon has. That, for starters, solve the problem with the range, as it gives it the same range as a normal shotgun. That means that mobs don't need to be as close as before. A good choice when you're doing a AoSh run, considering the fact that it doesn't rely on a rare level drop as the Nano Pack.

=== Trait Usage ===
There are several ways to bring out the best use of a double shotty in a game, be it a standard one or a challenge, most of them related to the character build used by the player. Obviously, all of them makes use of [[Traits#Shottyman|Shottyman]], because it makes moving and reloading a combined action, no longer wasting time as a sitting duck while you pump shells into your boomstick. This, combined with the fact that reduces the reloading time (Due to the Reloader L2 traits) and the fact that shotguns have perfect accuracy, can ensure that being hit by the enemies is as hard as it gets, even better if the player is running, as there is no drop-off in the aiming of the weapon.

In the case of damage-boosting, the trait to go is [[Traits#Son_of_a_Bitch|Son of a Bitch]], which grants a good +1 per trait level to the damage caused per shot, which basically means that the double shotty gets a free 2 damage to each enemy caught up in the blast in SoB L1. Pretty amusing to see those demons gibbed, yup.

When it comes to master traits, it depends on the way you want to have your weapon built with assemblies. A normal choice is [[Traits#Fireangel|Fireangel]], combined with the use of one of the assemblies that help ignore the armor of an enemy, be it Plasmatic or Nano-Shrapnel. Fireangel grants immunity to explosion damage (i.e: rockets, barrels, the Archvile AoE attack's splash damage, the Cacodemons' plasma ball, etc), raises the evasion of the character and the movement speed (Because of [[Traits#Hellrunner|Hellrunner]], grants a free [[Traits#Dodgemaster|dodge by sidestepping]] and also reloads the shotgun on movement.

Another choice is the previously mentioned Army of the Dead, which turns the shotgun into an armor-piercing stick of death against... pretty much everything in the game. Double health (Via [[Traits#Badass|Badass]]) and reloading on movement turns this trait into a secondary viable option, especially if you combine it with the powerhouse that is the Focused Double Shotgun, which deals incredible damage in one go to all enemies in the cone of fire. Still, you have to stock shells like hell, because the shortage can prove to be a pain in the ass later on.

Lever

2025-08-11T12:29:54Z

Epyon:

Levers are basic objects that appear on occasion throughout DRL. By definition they are items, but are more akin to [[Items#Powerups|powerups]] than anything else: they can be destroyed by splash damage rather easily and tend to disappear on use. Levers are always associated with the <font-family:monospace>& symbol.

In random levels, many different types of levers are created and are normally indistinguishable from one another. By investing in the [[Intuition]] trait, more information can be known about the lever before pulling it. The following is a list of all random levers and the information regarding them:

{|class="wikitable" style="border: 2px solid darkred; border-spacing: 0; font-size: 90%; margin: 0.25em 0.5em;"
{{Table5Col+Header
|hs=background: darkred; color: yellow; font-size:
|h1=text-align: center|h2=text-align: center|h3=text-align: center|h4=text-align: center|h5=text-align: center
|'''Exact Description'''|'''General Description'''|'''Uses'''|'''Map-wide [[Level feeling]]'''|'''Effect'''
|es=background: #333;
|c1=vertical-align:center; align:top; padding:0px 2px;
|c2=vertical-align:center; align:top; padding:0px 2px;
|c3=vertical-align:center; align:top; padding:0px 2px;
|c4=vertical-align:center; align:top; font-style: italic; padding:0px 2px;
|c5=vertical-align:center; align:left; padding:0px 2px;
|floods with water|neutral|1|The air is really humid here...|Sets all cells unoccupied by barrels or doors with water in the room/map.
|floods with acid|dangerous|1|In the State of Denmark there was the odor of decay...|Sets all cells unoccupied by barrels or doors with acid in the room/map.
|floods with lava|dangerous|1|You feel that smell? That gasoline smell? Oh hell...|Sets all cells unoccupied by barrels or doors with lava in the room/map.
|explodes barrels|neutral|1|N/A|All barrels on the map are simultaneously detonated.
|destroys walls|dangerous|1|You hear the trumpets of Jericho echoing in the distance...|Destroys all surrounding walls in the room, or all walls on the floor if it's a map-wide lever (excluding border walls).
|harms creatures|beneficial|1|The smell of a massacre...|Hits all enemies in the room/map with 20 [[fire]] damage.
|spawns enemies|dangerous|1-3|N/A|Spawns a random number of enemies directly adjacent to the lever: these enemies give no experience and are based on the current danger level, but will still drop any inventory the enemy normally drops.
|repairs armor|beneficial|1-3|N/A|Repairs currently-equipped armor and boots by 25%. Note that this is different from an [[armor shard]], which repair boots by 10%. This lever will not activate if you have no armor nor boots equipped that can be repaired. Its repairing amount is additionally not doubled in the [[I'm Too Young to Die]] and [[Nightmare!]] difficulties.
|heals player|beneficial|1-3|N/A|Heals player by the same amount as a [[small med-pack]]. This lever will not activate if you already have 100% or more health. Its healing amount is additionally not doubled in the I'm Too Young to Die and Nightmare! difficulties.
|ammo dispenser|beneficial|2-4|N/A|Drops a stack of [[10mm ammo]], [[shotgun shell]]s. [[rocket]]s, or [[power cell]]s. The ammo dropped is compatible with what weapon you have equipped when activating the lever, and the amount of ammo in each stack is not affected by the difficulty ammo multiplier. This lever cannot be activated if you're equipping a melee weapon or weapon that uses unconventional ammo.
|}}
|}

Modding:Tutorial/Designing AI

2025-08-11T12:29:48Z

Epyon:

{{incomplete}}
Before the more recent versions of DRL, all beings other than the player used a single algorithm for AI, or artificial intelligence, that directed how the being should act under certain circumstances. Although this default AI is modifiable to some extent through a few being flags, the extent to which beings acted remained roughly the same. When it became clear that this default AI could be outwitted with clever tactics, the AI object was added into the game (sometimes known as "lua AI"), allowing for complete customizability as to what a being does given any circumstances. Most beings, as of v0.9.9.4, call a particular AI object that governs their actions, and are thus more difficult to fight when playing the game (which is a good thing).

This tutorial goes through the basics of creating AI objects and what you can do with them. The AI object class is very flexible in that the basic structure is extremely simple, allowing you to add almost anything that the game allows from within its API. Unsurprisingly, designing your own artificial intelligence can be an extremely challenging task, depending on what exactly you want the AI to be capable of. Basic structuring techniques will be explained, as well as general guidelines when writing the code that your AI will consist of.

==Base Prototype==

Since the AI object is so very simple in its required fields, all of them will be contained in the following example:

<source lang="lua">
AI{
name = "simple_ai",

OnCreate = function(self)
self:add_property("ai_state", "first_state")
....
end,

OnAttacked = function(self)
....
end,

states = {
first_state = function(self)
....
end,

....
}
}
</source>

*''name'' is the identifier of the AI object, to be used as the field value for the being key ''ai_type''.
*'''OnCreate'''(''self'') triggers whenever ''self'' is created. For any being using this AI object, it is functionally identical to that being's '''OnCreate()''' hook in its own prototype.
**The "required" property here, ''ai_state'', is the key factor when determining what subfunction the being should run in the AI object.
*'''OnAttacked'''(''self'') triggers whenever ''self'' is hit. The hit does not have to cause damage. (Such a requirement can be a condition within the hook by comparing HP across multiple actions.)
*''states'' is an array of functions that are called based on the value of ''ai_state''. These functions will be run immediately after the being's own '''OnAction()''' hook in its own prototype. In the above example, since ''ai_state'' is set to "first_state" during '''OnCreate()''', the being will run the '''first_state()''' function.

Technically speaking, the "state" system of the AI object need not be used: one can instead invoke '''OnAction'''(''self'') directly. However, states are a very practical way to organize the various actions or modes that the AI transitions through, and its system will be used throughout this tutorial. Even including the optional state system, however, what is shown above is all that is necessary for the AI object to initialize.

==AI Rules==
While you are free to develop your artifical intelligence however you want, there are still some fundamental laws that govern their structure. (They are not so much mandated out of standardization as they are out of necessity: AI objects that do not follow these rules will not run correctly.)

===Rule 1===
'''<big>The AI must always lower the being's energy.</big>'''

Energy, or ''scount'', is determines when the being can take an action, and so long as its energy remains the same, it can continuously take more and more actions until the game refuses to allow a continuation (ie, infinite loop error). There are a number of API functions that will automatically cause the being's energy to decrease, but when none of these functions are called, you must directly lower the being's scount in the following manner:

<source lang="lua">
self.scount = self.scount - 1000
self.scount = self.scount - 10*self.speed
self.scount = 4000
</source>

While these three examples may appear similar, they are quite different. Recall that ''scount'' increases by ''speed'' each game turn, and decreases by 100 multiplied by the number of game turns for default actions (e.g., moving or attacking). Knowing this, we can see three separate possibilities:

*The first, reducing ''scount'' by 1000, will require a being with ''speed'' set to 100 to wait exactly ten game turns. For beings with ''speed'' greater than 100, it will occur sooner, and for beings with ''speed'' less than 100, it will occur later. Thus, a being with an action modified by this method will act "constant" with respect to its default action speed.
*The second, reducing ''scount'' by 10 multiplied by the being's speed, will require any being, regardless of ''speed'', to wait exactly ten game turns. Thus, a being with an action modified by this method will act "global" with respect to its default action speed (that is, all beings across the global scale take the same amount of time).
*The third, setting ''scount'' to 4000, is functionally identical to the first, except that it can be used immediately after default actions in order to make ''scount'' decrease by a very specific value. Suppose you wanted a being to be able to equip things immediately: using this method you can reset the scount value (to 5001) in order for the process to have taken no virtually no time at all. (Technically you could compare ''scount'' before and after actions taken, but this is a much simpler method.) Thus, a being with an action modified by this method will act "independent" with respect to its default action speed.

You will almost always use the "constant" modifier, but don't forget about the other two. (In particular, "global" and "independant" modifiers become important when you have several beings using the same AI and want to coordinate their actions very precisely.)

===Rule 2===
'''<big>Changing states in an AI during a single action always requires a way to exit the current state.</big>'''

There are two ways to exit a function: break and return. Consequently, there are two ways to switch states:

<source lang="lua">
AI{
name = "two_state",

OnCreate(self)
self:add_property("ai_state","state1")
end

states = {
state1 = function(self)
return("state2")
end,

state2 = function(self)
self.scount = self.scount - 1000
end,
}
}
</source>

The return method is a single line that both ends the function prematurely and sets the new ''ai_state''. In the above function, the being begins in '''state1()''', at which point it immediately changes to '''state2()''', then ends in '''state2()''' (since ''scount'' has decreased when that state ends).

<source lang="lua">
AI{
name = "two_state",
....
states = {
state1 = function(self)
self.ai_state = "state2"
break
end,

state2 = function(self)
self.scount = self.scount - 1000
end,
}
}
</source>

If changing states with the break method, you'll have to establish what state you're changing to first by modifying the "ai_state" property, then follow it with a break. On the surface, this is like the return method with an extra line. However, you can split the functionality when you assign the ai_state and when you break, in case you expect to purposefully want the state to repeat itself (and are reasonably certain that it will not tend toward an infinite loop error). In many cases, however, you should use the return method to immediately switch to another state.

Note that, were there no break or return in '''state1()''', even if ''ai_state'' was modified, the state will continuouslly repeat until an infinite loop error occured. This is unique to the AI object, due to the way that ''ai_state'' is handled.

===Rule 3===
'''<big>Always make sure that the AI will end a being's turn.</big>'''

This is a more subtle rule, as it already implies that the first two rules have already been addressed. In short, it is necessary that you make sure your conditions are always comprehensive in either changing states or lowering the being's energy.

This tutorial adopts some terminology regarding the completeness of states:

*'''Infinite''' states have obvious flaws that will cause a being to return an infinite loop error. AI objects with infinite states should always be fixed. However, infinite states can be used as a debugging tool: since infinite loops can easily be traced to a particular condition, they are a useful way to find a problem with the AI.
*'''Finite''' states will always either change to another state or cause the being's turn to end, regardless of the being's circumstances. Ideally, all states should be finite.
*'''Indefinite''' states, while not explicitly finite, will only cause infinite loop errors in unlikely circumstances. Sometimes it is feasible to fix these "indefinite conditions", sometimes not: these can be used in modules but care should be taken to avoid circumstances in which the error may manifest. (The simplest way to prevent an infinite loop is to simply set a limit on how much a loop can repeat itself, either with a loop counter or a finite iterator.) The most common indefinite states involve properties that are not explicitly defined in the AI, but belong to beings that use the AI.

States that satisfy rule 3 are considered finite, and when every state of an AI object is finite, the object itself is considered finite as well.

Let us suppose we want to construct an AI that only traveled up. Here is a simple example:

<source lang="lua">
AI{
name = "up_ai",

OnCreate = function(self)
self:add_property("ai_state", "walk_up")
end

states = {
walk_up = function(self)
local up_coord = self:get_position() + coord.new(0,-1)
self:direct_seek(up_coord)
end,
}
}
</source>

Any being with this AI will enter the "walk_up" state, get its position, add that coord to an upward-facing unit coord, and use the '''being:direct_seek()''' to move precisely to the new position. This is fairly complete, because the new position is only one tile away, so '''being:direct_seek()''' will never cause the being to run into obstacles between the being's position and the target position.

However, what happens when the tile above the AI is, itself, an obstacle? In such a case, '''being:direct_seek()''' does not perform a move, which means that the being's energy does not lower, and so the being is stuck in an infinite loop! We have created an infinite state and want to immediately resolve this problem. Fortunately, there is an easy way to deal with the loop, thanks to the way that movement methods work:

<source lang="lua">
AI{
name = "up_ai",
....
states = {
walk_up = function(self)
local up_coord = self:get_position() + coord.new(0,-1)
if self:direct_seek(up_coord) ~= 0 then
self.scount = self.scount - 1000
end
end,
}
}
</source>

'''being:direct_seek()''' returns an output integer, depending on what happens inside of the method. For our purposes, the method returns 0 whenever the being moves and returns a different number whenever it doesn't. Knowing this, we can set up a conditional checking to see if the return value is zero or not. If it is not, we cause the being to wait by lowering its energy. With our new condition, the being will move up until it can't, at which point it will do nothing; if the obstacle in the being's way is cleared, it will resume moving up. We have now formed a finite state, and since the AI only consists of a single state, we can consider the AI finite as a whole.

If you keep these rules in mind, you will have fewer problems in running the various algorithms within your AI.

==Default Actions==
There are a number of being methods that will automatically cause the being to lower its energy. Many of them are critical in developing an AI for DRL, and you would do well to memorize them:

===being:direct_seek()===
'''being:direct_seek'''(''coord'')) commands ''being'' to take a step toward ''coord'' following the most direct path possible. The direct pathing used here is the same as the game's default AI, and its algorithm can be roughly described by the following:

<source lang="text">
calculate the x-distance "dx" and y-distance "dy" from the target coordinate

if dx != 0 and dy != 0
attempt to move {sign(dx),sign(dy)}*
if move failed
if dy >= dx
attempt to move {0,sign{dy})
break on failure
else
attempt to move {sign(dx),0}
break on failure
end
end
elseif dx == 0
attempt to move {0,sign(dy)}
break on failure
elseif dy == 0
attempt to move {sign(dx),0)
break on failure
end

if break occurred, end turn

*sign(x) is +1 for positive x and -1 for negative x
</source>

'''being:direct_seek()''' returns an integer, which determines what occured with the being attempted to move:

*'''0''' indicates that the being move and that the being's energy lowered
*All other returns indicate that the being did not move and that its energy did not decrease:
**'''1''' indicates that the being was stopped by a wall
**'''2''' indicates that the being was stopped by a door
**'''3''' indicates that the being was stopped by another being

Specifically, when the movement process is interrupted, '''being:direct_seek()''' searches for CF_BLOCKMOVE. If it is not found on the blocking coordinate, '''3''' is returned; if CF_BLOCKMOVE is found but CF_OPENABLE is also found (which is used for doors), '''2''' is returned; in other cases when CF_BLOCKMOVE is found, '''1''' is returned.

===being:path_find()===
'''being:path_find'''(''coord'',''scan_cutoff'',''scan_max'') searches for a series of coordinates for ''being'' to travel between its current position and ''coord'', using parameters ''scan_cutoff'' and ''scan_max'' to choose the best path. ''scan_cutoff'' and ''scan_max'' are a part of the pathing algorithm and higher numbers tend to be pretty intensive. As a standard, ''scan_cutoff'' is set to 10 for normal enemies and 40 for bosses, while ''scan_maximum'' is set to 40 for normal enemies and 200 for boss enemies.

The return for this method determines whether or not a path was successfully found. Even if a complete path was not created, there will still be a path that '''being:path_find()''' established for ''being'', and can be used as a way to begin its approach to ''coord''.

'''being:path_find()''' does not actually move the being, nor does it decrease energy: use '''being:path_next()''' in order to initiate the movement attempt.

Generally speaking, it is not good practice to recalculate a pathing algorithm on every action, tempting as that may be. Naturally, the shuffling of enemies and opening/closing doors can affect whether or not the path is a correct one, but it is better to consider these exceptions as the time to call '''being:path_find()''', rather than doing so all the time.

===being:path_next()===
'''being:path_next()''' command ''being'' to move to a coordinate as specified by '''being:path_find()'''. To think of this process abstractly, consider that whenever '''being:path_next()''' is executed, an array of steps is called: the first step is then used as the coordinate into which the being moves, and is removed from the array. Thus, calling the method each time moves the being to each coordinate, until the array is entirely removed and the being has reached the supposed target position.

'''being:path_next()''' carries the same return values as '''being:direct_seek()''', and exceptions can be handled in the same manner.

===being:attack()===
'''being:attack'''(''coord'') commands ''being'' to use its melee attack on ''coord''. If ''coord'' cannot be attacked within melee distance, or ''being'' cannot use its melee attack, the being's energy does not decrease.

'''being:attack'''(''enemy'') commands ''being'' to use its melee attack on ''enemy'', another being. The same conditions for energy modification are used here.

The output returns true in the event that the attack was successful (whether or not it dealt damage is independent) and false otherwise

===being:fire()===
'''being:fire'''(''coord'',''weapon'') commands ''being'' fire its ''weapon'', aiming at ''coord''. If ''weapon'' cannot be fired (e.g., out of ammo), then the being's energy does not decrease.

As there is no return value to determine whether or not the being's attack was successful, you may want to set up exceptions in the event that ''weapon'' cannot fire.

===being:reload()===
'''being:reload()''' commands ''being'' to attempt to reload its currently-equipped weapon. If the weapon cannot be reloaded, then the being's energy does not decrease.

The output returns true if the being reloaded the weapon and false otherwise. The reload can partially fill the weapon's ammo capacity depending on the ammo reserves of ''being'', and '''being:reload()''' will still return true.

===being:wear()===
'''being:wear'''(''slot'') commands ''being'' to equip an item that exists in position ''slot'' of its inventory. (For instance, to equip the first item in the inventory, ''slot'' should be set to 1.) If the item in position ''slot'' cannot be equipped, or if the being cannot equip items, the being's energy does not decrease.

'''being:wear'''(''item'') commands ''being'' to equip ''item'' from its inventory. ''being'' will always equip ''item'' from the lowest slot in its inventory. If ''item'' does not exist in the being's inventory, or if ''being'' cannot equip items, the being's energy does not decrease.

The output returns true if the being equipped an item and false otherwise.

===being:use()===
'''being:use'''(''slot'') commands ''being'' to use the item that exists in position ''slot'' of its inventory. If the item in position ''slot'' cannot be used in any way, the being's energy does not decrease.

'''being:use'''(''item'') commands ''being'' to use ''item'' from its inventory. ''being'' will always use ''item'' from the lowest slot in its inventory. If ''item'' does not exist in the being's inventory, or if cannot be used in any way, the being's energy does not decrease.

Currently there is a bug that causes the output of this method to always return false, so it is useless to return.

===being:pickup()===
'''being:pickup()''' commands ''being'' to pick up an item at the same position as ''being''. If there is no item to pick up, or if ''being'' cannot pick up items, the being's energy does not decrease.

'''being:pickup'''(''coord'') commands ''being'' to pick up an item at ''coord'' from where it is standing. The same condition for energy modification is used here.

The output returns true if the being picked up an item and false otherwise.

==Single-minded AI==
A single-minded AI never needs to make an intelligent decision between two choices. Simply put, it follows only action-based algorithms: if there are changes that do not stem from actions, they are automatic or constant. Such AI are the easiest to create and implement, as their movements are always obvious when observed. There are two ways to implement a single-minded AI: create only single state that performs the actions, or divide each type of action into its own state and cycle through them. Most of the time a single state is all that is necessary, though there can be cases in which having separate states is a more logical procedure.

We will now return to our example AI from before, which involved either walking up or stopping whenever walking would cause it to hit a solid object. It is a sufficient AI but is certainly lacking in mobility: after all, the game will eventually run out of coordinates if it can only move in a single direction. Let us expand on the design by allowing it to move in any orthogonal direction (up, down, left, or right), depending on what direction it is currently walking and what is in the way.

We should begin by setting up the AI such that it can walk in all of the directions specified. Since each direction can be considered a separate action, you may be tempted to create a state for each one, like so:

<source lang="lua">
AI{
name = "walk_ai",

OnCreate = function(self)
self:add_property("ai_state","walk_up")
end,

states = {
walk_up = function(self)
local up_coord = self:get_position() + coord.new(0,-1)
if self:direct_seek(up_coord) ~= 0 then
self.scount = self.scount - 1000
return("walk_right")
end
end,

walk_right = function(self)
local right_coord = self:get_position() + coord.new(1,0)
if self:direct_seek(right_coord) ~= 0 then
self.scount = self.scount - 1000
return("walk_down")
end
end,

walk_down = function(self)
local down_coord = self:get_position() + coord.new(0,1)
if self:direct_seek(down_coord) ~= 0 then
self.scount = self.scount - 1000
return("walk_left")
end
end,

walk_left = function(self)
local down_coord = self:get_position() + coord.new(-1,0)
if self:direct_seek(down_coord) ~= 0 then
self.scount = self.scount - 1000
return("walk_up")
end
end,
}
}
</source>

This acts much like the original example, except that we have four states that the being cycles through: each time the being runs into a solid object, in addition to waiting, it will move to another state, which will be accessed on the next action. For most programmers this setup looks horribly inefficient, since it is a lot of copy-pasting with only a couple of changes per copy. There is a far more elegant way to set up the four directions using what is called a lookup table:

<source lang="lua">
AI{
name = "walk_ai",

OnCreate = function(self)
self:add_property("ai_state","walk")
self:add_property("walk_num",1)
end,

states = {
walk = function(self)
local c = self:get_position()
local coord_list = {c+coord.new(0,-1), --up (1)
c+coord.new(1, 0), --right (2)
c+coord.new(0, 1), --down (3)
c+coord.new(-1,0)} --left (4)
--attempt to move
if self:direct_seek(coord_list[self.walk_num]) ~= 0 then
--on failure, wait and turn clockwise
self.scount = self.scount - 1000
self.walk_num = math.fmod(self.walk_num,4)+1
end
end,
}
}
</source>

A lookup table is an array that contains a number of elements are necessarily hard-coded and conveniently organized for reference. The code doesn't know what a direction is until we explicitly express it somewhere: a convenient shortcut is to use a lookup table and simply call a certain element that we know to be of a certain definition. In some cases lookup tables are placed independently in separate functions for conversion purposes. Here we create a dynamic lookup table (since it changes every time the being's position does) that determines each movement coordinate in the orthogonal directions.

In order to make use of the table, we need a variable that keeps track of the being's current direction it wants to move: this is done by adding a property called ''walk_num'', which is an integer representing a coordinate from the lookup table. '''self:direct_seek'''(''coord_list''['''self'''.''walk_num'']) will now move the being based on the value of ''walk_num'' (comments in the example show the number-direction correlation).

When the being runs into a solid object, in addition to waiting, ''walk_num'' is incremented by one on a modulo-four cycle using the '''math.fmod()''' method. '''math.fmod'''(''divisor'',''dividend'') divides ''divisor'' by ''dividend'' and returns the remainder of the quotient (e.g., 7 / 4 = 1R3; math.fmod(7,4) returns 3). With each use of the cycling line of code, ''walk_num'' increases by one, and whenever it was equal to four, it is set back to one again (as '''math.fmod'''(4,4)+1 == 0+1 == 1).

This new state is functionally identical to the four-state case but is easily half its size in terms of lines of code. Finding ways to cut down on the magnitude of a script can greatly improve the ability to debug it, as well as allowing others to read and understand it. Since states can become very complicated, it is important to organize them as cleanly as possible.

Suppose we want this being to be able to attack the player whenever they get in its path. It is easy to include this in the AI we already have:

<source lang="lua">
AI{
name = "bulldozer_ai",

OnCreate = function(self)
self:add_property("ai_state","walk")
self:add_property("walk_num",1)
end,

states = {
walk = function(self)
local c = self:get_position()
local coord_list = {c+coord.new(0,-1), --up (1)
c+coord.new(1, 0), --right (2)
c+coord.new(0, 1), --down (3)
c+coord.new(-1,0)} --left (4)
--attempt to move
local move_to = coord_list[self.walk_num]
if self:direct_seek(move_to) ~= 0 then
--if player is in the way, attack them
if move_to == player:get_position() then
self:attack(move_to)
--otherwise, wait and turn clockwise
else
self.scount = self.scount - 1000
self.walk_num = math.fmod(self.walk_num,4)+1
end
end
end,
}
}
</source>

First, we define ''move_to'' as the coordinate where the being attempts to move: this is done to make the code easier to read through, since the coordinate will now be referenced multiple times. Next, after knowing that '''self:direct_seek()''' failed, we include a splitting:
*If ''move_to'' is equal to the player's current position, use '''self:attack()''' to attack the player.
*Otherwise, we do what was done before (wait a second and continue the directional cycling)

One could say that this borders on an intelligent decision made by the AI, but it is a very basic one and doesn't do anything other than include a special case in which the being is blocked by the player. Compared to what AI can eventually develop into, this is still an extremely simple example.

A truly single-minded AI that attacks would look something like this:

<source lang="lua">
AI{
name = "attack_ai",

OnCreate = function(self)
self:add_property("ai_state", "attack")
end,

states = {
attack = function(self)
local p = player:get_position()
if not self:fire(p, self.eq.weapon) then
if not self:attack(p) then
self.scount = self.scount - 1000
end
end
end,
}
}
</source>

First, we set ''p'' as the player's coordinate. The being then tries to fire a ranged attack at ''p''. If it cannot (either because the being has no ranged weapon or that weapon is out of ammo) then it will attempt a melee attack on ''p''. If it cannot execute the melee attack, it will simply wait. Such a being, with a ranged attack, will attempt to kill the player from anywhere on the map: after all, it lacks the intelligence to know whether or not it can see the player.

Single-minded AI are simple, but they lack the ability to give the player an intelligent challenge with respect to a being using it. Most modders will want to create AI that make decisions based on the whereabouts of various objects on the map, or the being's state, or even global timers. These require a more rigorous approach to ensure that they are produced without flaw.

Modding:Tutorial/The Infinite Arena

2025-08-11T12:29:27Z

Epyon:

(NOTE: if you are unfamiliar with the general structure of the Hell's Arena module, it is suggested that you [[Modding:Tutorial/Recreating_Hell's_Arena|read the tutorial]] before proceeding, as many of the topics found there also are here, and will only be touched upon in this tutorial.)

[[Hell's Arena]] is a fun little level, as it can be fairly difficult to complete without some grasp on DRL's mechanics, but pillar and monster placement aside, it is still a fairly static map. The following tutorial is a generalized version of Hell's Arena, coined the Infinite Arena, which has been reconstructed based on [[User:Yaflhdztioxo|yaflhdztioxo's]] design from v0.9.9.1. A fair number of seemingly-superfluous tools have also been created as a means to provide easy customization possibilities for those who want to quickly change the settings of the Arena. If nothing else, you will discover a variety of helper tools in this tutorial that may prove to be useful in your own modules.

==Special Concept: Custom Tables and Functions==
The basics of tables have already been explained in the [[Modding:Tutorial/Game Objects|Game Objects]] tutorial: it was also explained there that building your own tables is generally unnecessary. There are, however, plenty of reasons to make tables for your own purposes:

*You want the game to randomly choose from a group of variables
*You want to perform calculations or subroutines on many objects simultaneously
*You are creating an object map that other functions may require (e.g., translation table for .run() )
*You want to store a number of variables in an organized manner in order to access them easily

There are two kinds of tables. The first kind are what are more commonly referred to as tables, as they contain keys and values in each of their fields:

<source lang="lua">
local some_table = {
key1 = "value1",
key2 = "value2",
....
}
</source>

In fact, these tables can contain more tables, like so:

<source lang="lua">
local big_table = {
small_table1 = {
key1 = "value1",
key2 = "value2",
},
small_table2 = {
key1 = "value3",
key3 = "value4",
},
}
</source>

Note that these sub-tables do not have to carry the same information, although you may want them to (depending on the table's purpose). In doing so, you can create very large and intricate tables to suit your needs.

The second kind of table is commonly known in the modding community as an array, and is essentially a table that does not explicitly write keys in each field. The following examples show an array, followed by a table that imitates the functionality of an array:

<source lang="lua">
local some_array = {"value1","value2","value3"}

local some_imit_table = {
[1] = "value1",
[2] = "value2",
[3] = "value3",
}

local big_array = {
{"value1","value2","value3"},
{"value4","value5","value6"},
}

local big_imit_table = {
[1] = {
[1] = "value1",
[2] = "value2",
[3] = "value3",
},
[2] = {
[1] = "value4",
[2] = "value5",
[3] = "value6",
},
}
</source>

As you can see, the array format is a lot more compact, but it also forces very specific keys on each field (namely numerical ones). Naturally, tables and arrays can be combined seamlessly, such that you can have a table of arrays or an array or tables (as well as more complicated setups).

When you want to call various parts within a table or array, you can use the following syntax (we will base these on ''big_array'' and ''big_table''):

<source lang="lua">
big_table.small_table1 --returns the contents of small_table1
big_table[small_table1] --identical to above

big_table.small_table1.key1 --returns "value1"
big_table.small_table1[key1] --identical to above
big_table[small_table1].key1 --identical to above
big_table[small_table1][key1] --identical to above

big_array.1 --returns the contents of the first array in big_array
big_array[1] --identical to above

big_array.2.2 --returns "value5"
big_array.2[2] --identical to above
big_array[2].2 --identical to above
big_array[2][2] --identical to above
</source>

As a matter of convention, we will write table-like extensions using the dot syntax and array-like extensions using the bracket syntax. (This is typically how other languages write their arrays and tables, and it is often a good idea to organize your code in such a manner so that it is easier to read when looking back at it.)

Functions, like tables, are mostly known based on using parts of pre-defined object classes: in the case of functions, we should already be fairly familiar with their capabilities when calling engine hooks and API methods. The creation of a function is very simple, nearly identical to engine hooks.

<source lang="lua">
local function sum_diff(arg1,arg2)
val1 = arg1+arg2
val2 = arg1-arg2
return(val1,val2)
end

local add_diff = function(arg1,arg2) --this line is identical to the first line of the above function
....
end
</source>

*First you must give the function a name: the above example is called '''sum_diff()'''.
*Next you must supply input arguments, if any. These are variables that can be used within the function, which is otherwise self-contained. That is to say, a function can't use any variables from anywhere else in your lua script unless they are given through the input arguments. The above example takes in two arguments, generically named ''arg1'' and ''arg2''.
*From here we add the script that is to be run when the function is called (this is usually what you concern yourself with when working with the engine hooks). In the above example, the sum of ''arg1'' and ''arg2'' is assigned to ''val1'', and their difference is assigned to ''val2''.
*Finally, we consider what the function should output. This can be accomplished in two ways when modding:
**You can simply provide outputs to the function using the return() core method. This immediately stops the function and sends outputs to the line that called the function. In the above example, ''val1'' and ''val2'' are returned. (Note that, when called, the script should contain some variables so that the return values are properly assigned.)
**You can manipulate objects. Since changing objects (such as their prototype) modify things on the engine side of the game, this can be done without having any particular outputs to the function. Even though the function is self-contained within your script, it can influence things not belonging to the script.

If you want to call a function, use its name with the appropriate input and outputs. For the above example, you could call the function in the following way:

<source lang="lua">
local num1 = 5
local num2 = 4

local sum,diff = sum_diff(num1,num2)
</source>

The ''sum'' variable will have a value of 9, and the ''diff'' variable will have a value of 1.

In the Infinite Arena module, a large portion of the code is dedicated to constructing easy-to-read and well-organized tables, as well as functions that make use of them. The tables and functions will eventually be called in the engine hooks, which leaves us with a relatively small amount of run-time code to sift through. Ideally, modules should have a format in which much of the script is written not as a part of the core module, but as something that the core module will refer to.

==Initialization Code==

===Variables===

====mobGenStats====
<source lang="lua">
--customize min_lev/max_lev/weight of each enemy (defaults given)
--for names of beings, check Object IDs in the modding documentation
--be aware that JC auto-ends the game unless modified directly
local mobGenStats = {
{ being = "former", min_lev = 0, max_lev = 12, weight = 10 },
{ being = "sergeant", min_lev = 2, max_lev = 15, weight = 10 },
{ being = "captain", min_lev = 8, max_lev = 15, weight = 10 },
....
}
</source>

''mobGenStats'' is an array of tables: each table contains four fields relating to the being prototype. In each case, a being's identifier ''being'' is given, followed by a ''min_lev'', ''max_lev'', and ''weight'' (all generation parameters). The purpose of ''mobGenStats'' is to switch particular values for others in the being prototypes that already exist. Normally this can be done for a particular enemy with the following line:

<source lang="lua">
beings.former.weight = 0
</source>

This would change the ''weight'' key in the ''former'' table of the ''beings'' array (which holds all being prototypes) to zero, thereby removing the possibility of former humans appearing through standard generation procedures. However, if a modder wants to change many parameters at once, they can use what is done in the Infinite Arena. First is the creation of the above table, and then you use the table in a for loop as follows:

<source lang="lua">
--changes the generation stats of enemies based on mobGenStats
for _,v in ipairs(mobGenStats) do
beings[v.being].min_lev = v.min_lev
beings[v.being].max_lev = v.max_lev
beings[v.being].weight = v.weight
end
</source>

The conditional statement 'for a,b in ipairs(array)' breaks down in the following way:
*''a'' is the iterator of the for loop itself (whenever the code repeats, ''a'' increases by one)
**As we have no need for a basic iterator, we leave it blank using an underscore.
*''b'' is the array iterator (directly calls the particular array, similarly increments)
*in '''ipairs()''' tells the for loop to iterate through values in an array
*''array'' is the array in question

In this particular case, the loop iterates through each array and sets the being's ''min_lev'', ''max_lev'', and ''weight'' (as found in the being prototype) to the values as determined by ''mobGenStats''. ''v.being'' is the same as a being's identifier from ''mobGenStats'', which is how the loop iterates through all being prototypes. In this way all of the beings in the prototype array can be changed quickly without a bunch of lines specifying each key and value.

<source lang="lua">
--enemy scaling for each wave: note that game difficulty will modify scaling independently
local mob_scale_factor = 0.5
</source>

Finally, we have a variable that indicates the initial scaling of enemies. For the Infinite Arena, using the base game's scaling is probably too difficult for what a player at a given difficulty would expect, so it is cut in half by default.

====itemGenStats====
<source lang="lua">
--customize level/weight of items (defaults given)
--for names of items, check Object IDs in the modding documentation
local itemGenStats = {
--Commons

--weapons
{ item = "knife", level = 1, weight = 640 },
{ item = "pistol", level = 1, weight = 70 },
{ item = "shotgun", level = 2, weight = 180 },
....
--ammo/ammo packs
....
--armor/boots
....
--consumables
....
--powerups
....
--Exotics
....
--Uniques
....
}
</source>

''itemGenStats'' is just like ''mobGenStats'', except that it is an array of tables regarding generation parameters for items. Note that ''mobGenStats'' and ''itemGenStats'' in the source set all of the monsters and items to their default settings, so there will be no difference between the generation in the base game and in the Infinite Arena unless the modder chooses to customize it personally. (''mobGenStats'' and ''itemGenStats'' are also shortened here: see Review for the full arrays.)

<source lang="lua">
--changes the generation stats of items based on itemGenStats
for _,v in ipairs(itemGenStats) do
items[v.item].level = v.level
items[v.item].weight = v.weight
end
</source>

As with ''mobGenStats'', a for loop is used to run through all of the variables in the ''itemGenStats'' tables and change the prototypes to anything that the modder wishes to customize.

<source lang="lua">
--item scaling for each wave
local item_scale_factor = 0.5
</source>

The item scaling is also dropped to scale properly with the drop in monster scaling. (Feel free to change these around for your own amusement, of course.)

====anncrMsg and crowdMsg====

<source lang="lua">
--add your own announcer lines here
local anncrMsg = {
--displays whenever player completes wave
success = {
{
"The voice booms, \"Congratulations mortal!",
"The voice booms, \"Impressive mortal!",
"The voice booms, \"Most impressive.",
"The voice booms, \"You are a formidable warrior!",
},
{
....
},
{
....
}
},
--displays whenever player decides to continue to another wave
choice = {
....
}
}
</source>

''anncrMsg'' is the opposite of the generation variables: it is a table of arrays. There are two arrays within ''anncrMsg'' labeled ''success'' and ''choice'', each of which carry their own groups of variables. ''anncrMsg'' itself is called whenever the announcer displays a message (after the third wave), using either ''success'' (whenever the player completes the wave) or ''choose'' (whenever the player chooses to continue to the next wave). Since each group of strings should be handled separately, they are grouped separately, hence the need for a table of arrays.

In addition, ''anncrMsg.success'' and ''anncrMsg.choose'' are an array of arrays themselves. The reason for this will be explained in '''build_announcerMsg()'''.

<source lang="lua">
--add your own crowd lines here
--displays whenever enemy is killed
local crowdMsg = {
"The crowd goes wild! \"BLOOD! BLOOD!\"",
"The crowd cheers! \"Blood! Blood!\"",
"The crowd cheers! \"Kill! Kill!\"",
"The crowd hisses. \"We came for a REAL fight!\"",
"The crowd boos. \"No skill, no kill!\"",
}
</source>

By contrast, ''crowdMsg'' is a simple array of strings, called whenever a crowd message is necessary. Since the crowd only needs to be called in one case, only one group of strings is initialized, and so a table of arrays is no longer required.

===Functions===

====build_gear()====
<source lang="lua">
--changes player equipment
--add "nil" for any slot that should be empty
--always refreshes all slots: do not use to change only one equipment slot
local function build_gear(weap,prep,body,foot)
player.eq:clear()
if weap then player.eq.weapon = item.new(weap) end --main weapon
if prep then player.eq.prepared = item.new(prep) end --prepared weapon
if body then player.eq.armor = item.new(body) end --body armor
if foot then player.eq.boots = item.new(foot) end --boots
end
</source>

'''build_gear()''' is an example of a "helper function", as it runs a procedure that could easily be reproduced in the run-time code but simplifies the input whenever the code needs to be modified. In this case, the function clears all of the player's equipment and potentially adds a new item in each slot. There are four inputs, each corresponding to a particular slot: if the value in an input argument is not nil, it then adds a new item to that player's equipment slot.

In the run-time code, the player need only change the input variables rather than changing several lines. This may not appear very necessary for '''build_gear()''' but the concept of a helper function can make modifications to code much easier.

====build_pack()====
<source lang="lua">
--changes player inventory
--always refreshes all slots: do not use to change only one equipment slot
local function build_pack(itemPack)
player.inv:clear()
for _,part in ipairs(itemPack) do
if items[part.name].type == ITEMTYPE_AMMO then
--ammo is handled separately, loops for however many stacks are needed
for n=1,math.ceil(part.amt/items[part.name].ammomax) do
local pack = item.new(part.name)
if part.amt < pack.ammomax then
--remainder (or single) stack
pack.ammo = part.amt
else
--filled (and/or multiple) stacks
pack.ammo = pack.ammomax
part.amt = part.amt - pack.ammomax
end
player.inv:add(pack)
end
else
--loops for however many items are needed
for n=1,part.amt do
player.inv:add(part.name)
end
end
end
end
</source>

'''build_pack()''' is another helper function, this time clearing the inventory of the player and adding in new items there. It uses the "in '''ipairs()'''" iteration method to check all variables in an array in the following way:

*if the item's ''type'' is ITEMTYPE_AMMO:
**a new for loop is run, iterating from 1 to ''ammonum''/''ammomax'' for the specific ammo (''ammonum'' currently being how much that the player's inventory receives)
**first, the new ammo stack is created
**if ''ammonum'' is less than the ammo's ''ammomax'':
***set the ammo stack equal to ''ammonum''
**otherwise:
***set the ammo stack equal to ''ammomax''
***subtract ''ammonum'' by ''ammomax''
**finally, add the ammo stack to the player's inventory (and this process repeats as necessary)
*if the item's ''type'' is not ITEMTYPE_AMMO:
**a new for loop is run, iterating as many times as items should be added for the particular item in question
**the item(s) are then added to the player's inventory, one by one

The input requires an array of tables, although the format is rather simple. Here is an example of an input for '''build_pack()''':

<source lang="lua">
local itemPack = {
{name = "chaingun", amt = 1 }
{name = "ammo", amt = 360}
{name = "smed", amt = 5 }
}
</source>

Each table in the array requires only two fields: ''name'', which corresponds to the item's identifier, and ''amt'', which specifies how many of that item should be added. In the case of ammunition, the amount of ammo should be specified instead, as it is handled uniquely in order to produce an ideal number of stacks. The above example would add one chaingun, three 9mm ammo (x100) stacks, one 9mm ammo (x60) stack, and five small med-packs to the player's inventory. Keep in mind that the player can only hold 22 items, and any items added after 22 items have been added to the inventory will be disregarded.

====build_announcerMsg()====
<source lang="lua">
local function build_announcerMsg(MSG)
for _,msgNum in ipairs(MSG) do
ui.msg(table.random_pick(msgNum))
end
end
</source>

The '''build_announcerMsg()''' function iterates through an array and selects a random index from a table within the array. The purpose of this simple function is to loop through a series of arrayed strings from ''anncrMsg'' and randomly pick strings from those arrays. '''build_announcerMsg'''(''anncrMsg.success'') sets up three random messages from each array in its array, and '''build_announcerMsg'''(''anncrMsg.choose'') sets up two random messages from each array in its array. (Setting up a lot of tables within tables can be confusing, but it becomes relatively simple as a means to organize variables together when compared to keeping track of each variable separately.)

====get_corpses() and clear_corpses()====
<source lang="lua">
--initializes table of cells that only contains corpses
local corpseCells = {}

local function get_corpses()
for i = 1, #cells do
if cells[i] and cells[i].flags then
if cells[i].flag_set[CF_CORPSE] == true then
table.insert(corpseCells, i) --i == sID's numeric value
end
end
end
end
</source>

'''get_corpses()''' is a quick function that creates a table, ''corpseCells'', and loops through all cells in the cell prototype array, selecting only those that contain the CF_CORPSE flag (indicating that the cell acts like a corpse) and adding it to ''corpseCells''. This method is often the most effective way to create a selective table of objects.

<source lang="lua">
--removes corpses and blood-like cells
local function clear_corpses()
--fade away all blood
Generator.transmute("blood", "floor")
Generator.transmute("bloodpool", "blood")
--changes corpses to blood
for i = 1, #corpseCells do
Generator.transmute(corpseCells[i], "bloodpool")
end
end
</source>

'''clear_corpses()'' puts our table of corpses to use by transmuting any cells contained in the table into the "bloodpool" cell. Additionally, all blood pools are changed to "blood" and all blood is changed to "floor". This is added to the Infinite Arena so that a ridiculous number of corpses isn't around when Arch-vile enemies begin to show themselves.

==Engine Hooks==

===.run()===
<source lang="lua">
--Creation of Infinite Arena
function inf_arena.run()
Level.name = "Infinite Arena"
Level.name_number = 0
Level.fill("rwall")
Generator.set_permanence(area.FULL)

local translation = {
["."] = "floor",
["#"] = {"rwall", LFPERMANENT = true},
["X"] = "rwall",
[","] = "blood",
[">"] = "stairs",
}

local map = [[
#######################.............................########################
###########.....................................................############
#####..................................................................#####
##........................................................................##
#..........................................................................#
....,.......................................................................
.................................,...,......................................
.,.....................................,....................................
..,>.,..........................,...........................................
.,..,.................................,.,...................................
................................,..,...,....................................
............................................................................
............................................................................
#..........................................................................#
##........................................................................##
#####..................................................................#####
###########.....................................................############
#######################.............................########################
]]
--change up the column types
local column = {
[[
,..,.,
,XXXX.
.X##X,
.XXXX.
,..,.,
]],
[[
,..,.,
,X##X.
.####,
.X##X.
,..,.,
]],
[[
,..,.,
,####.
.####,
.####.
,..,.,
]]
}

Level.place_tile(translation,map,2,2)
for i=1,11 + math.random(4) do
Level.scatter_put( area.new(5,3,68,15), translation, table.random_pick(column), "floor", 1)
end
Level.scatter(area.FULL_SHRINKED, "floor", "blood", 100)
Level.player(38, 10)
end
</source>

The '''run()''' hook is very similar to that of the Hell's Arena one. In fact, other than the name change, the only real difference is that the ''column'' string has now been expanded to an array of strings, corresponding to an array of pillars. In order to randomly select pillars, '''Level.scatter_put()''' must be iterated a number of times, adding only one pillar each time: then, by adding the '''table.random_pick()''' method to the tiles-to-be-added argument, it randomly selects one of the pillars in the ''column'' array. The result is that the columns randomly have varying degrees of destructibility.

===.OnEnter()===
<source lang="lua">
function inf_arena.OnEnter()
--inventory table used for build_pack()
local itemPack = {
{name = "smed", amt = 2},
{name = "shell", amt = 50},
}
--set up starting eq/inv
build_gear("shotgun","pistol",nil,nil)
build_pack(itemPack)

--Print announcer messages
ui.msg("A devilish voice announces: \"Welcome to Hell's Arena, mortal! " ..
"\"You are either very brave or very foolish. Either way I like it! " ..
"\"And so do the crowds!\" Suddenly you hear screams everywhere! " ..
"\"Blood! Blood! BLOOD!\" \"Kill all enemies and I shall reward thee!\"")

--spawn first wave
Level.flood_monsters(Generator.being_weight()*mob_scale_factor)
Level.result(1)
end
</source>

'''OnEnter()''' makes significant use of the helper functions, using '''build_gear()''' and '''build_pack()''' to initialize the player's starting equipment and inventory. Besides the itemPack array, this only takes two lines of code, producing a much cleaner and more organized routine than in the original Hell's Arena.

In addition, rather than directly spawning enemies using the '''Level.summon()''' method, we imitate the base game's generation code by combining '''Generator.being_weight()''', which outputs the danger level for a given map level, and '''Level.flood_monsters()''', which randomly drops enemies on the level for a given danger level. Additionally, the ''mob_scale_factor'' variable is used to change the danger level, thereby changing the scaling of the first wave.

===.OnKill()===
<source lang="lua">
function inf_arena.OnKill(being)
--random message from crowdMsg array
ui.msg(table.random_pick(crowdMsg))
end
</source>

'''OnKill()''' does exactly the same thing as the one from Hell's Arena, except that the crowd messages have been tabulated and '''table.random_pick()''' is used to choose from one of said messages. Technically, '''build_announcerMsg()''' would also work here, but since both would only require one line of code, it may as well be the simplest one to understand.

===.OnKillAll()===
<source lang="lua">
function inf_arena.OnKillAll()
--print more announcer stuff
if Level.result() == 1 then
ui.msg("The voice booms, \"Not bad mortal! For a weakling that you are, " ..
"you show some determination.\" You hear screams everywhere! " ..
"\"More Blood! More BLOOD!\" The voice continues, \"I can now " ..
"let you go free, or you may try to complete the challenge!\"")
elseif Level.result() == 2 then
ui.msg("The voice booms, \"Impressive mortal! Your determination to " ..
"survive makes me excited!\" You hear screams everywhere! " ..
"\"More Blood! More BLOOD!\" \"I can let you go now, and give you " ..
"a small reward, or you can choose to fight an additional challenge!\"")
else
--random message from anncrMsg.success array
build_announcerMsg(anncrMsg.success)
end
....
</source>
'''OnKillAll()''' has received some simplifications similar to '''OnEnter'''. To start, after the first two waves, rather than dealing with an large number of random messages here, all of it is called from the previous ''anncrMsg'' table and the '''build_announcerMsg()''' function, which randomly picks a string from an array strings, then iterates through the entire array of arrays. In the displayed run-time code, this amounts of a single line (although it is actually running quite a few lines).

<source lang="lua">
....
local choice = ui.msg_confirm("Round " .. Level.result() + 1 .. " awaits. " ..
"Do you want to continue the fight?")
if choice == true then --continuing
--random message from anncrMsg.choice array
build_announcerMsg(anncrMsg.choice)
--set up the danger level for the next wave
Level.result(Level.result() + 1);
Level.danger_level = Level.result();
--spawn items for next wave
Level.flood_items(Generator.item_amount()*item_scale_factor)
--spawn enemies for next wave
Level.flood_monsters(Generator.being_weight()*mob_scale_factor)
....
</source>

Upon choosing to continue, we use '''build_announcerMsg()''' for more messages (again, only a single line of code). Then, we increment the level by one and increase the ''danger_level'' using the amount from '''Level.result()'''. (''Level.danger_level'' is actually a property of the level object.) Finally, we use the increased danger level to add items and monsters. '''Level.flood_items(Generator.item_amount())''' is the item equivalent of '''Level.flood_monsters(Generator.being_weight())'''.

<source lang="lua">
else --quitting
if Level.result() == 1 then
ui.msg("The voice booms, \"Coward!\" You hear screams everywhere! " ..
"\"Coward! Coward! COWARD!\"")
elseif Level.result() == 2 then
ui.msg("The voice booms, \"Too bad, you won't make it far then...!\" " ..
"You hear screams everywhere! \"Boooo...\"")
elseif Level.result() < 10 then
ui.msg("The voice booms, \"An impressive run, Mortal! We appreciate " ..
"it!\" The crowd starts to chant! \"Encore! Encore!\"")
else
ui.msg("\"Ladies and gentlemen, your champion, "
.. Player.get_name() .. ". He survived " .. Level.result() ..
" rounds in our arena! That has to be some sort of record. " ..
"Give him a hand folks!\" The crowd starts to chant your name " ..
"and they begin throwing items into the ring!")
Level.flood_items(Generator.item_weight())
end
end
end
</source>
Upon choosing not to continue, the announcer displays a variety of messages, although they are few enough (and specific enough) not to create another array for them. (They CAN be tabulated, but it is less bulky than for the other cases.) If the player survived at least ten waves before stopping, the crowd "throws items onto the stage" and you get some pointless gear when you're done, just as before.

===.OnExit()===
<source lang="lua">
function inf_arena.OnExit()
if Level.result() < 10 then
ui.msg("The voice laughs, \"Flee mortal, flee! There's no hiding in hell!\"")
else
ui.msg("The voice laughs, \"Remember to come back once you return to Hell " ..
"for the extended stay\"")
end
--used in .OnMortem()
inf_arena.result = "had enough of the gauntlet at wave "..Level.result()
end
</source>

'''OnExit()''' has only gained a cosmetic change in the case where the player survived more than ten waves before retreating.

===.OnMortem()===
<source lang="lua">
function inf_arena.OnMortem()
local kill = player.killedby --calls kill descriptions from beings
if inf_arena.result then kill = inf_arena.result end
player:mortem_print( " "..player.name..", level "..player.explevel.." "
.." "..klasses[player.klass].name..", "..kill )
--e.g., "Cool Guy, level 1 Marine, had enough of the gauntlet at wave 8"
player:mortem_print(" in the Infinite Arena...")
end
</source>

As with '''OnExit()''', '''OnMortem()''' only changes some of the text in the mortem depending on how the player ends the game.

==Review==
The following is the entire source code for the Infinite Arena.
{{:Modding:Tutorial/The_Infinite_Arena/Source}}

Source data: [http://dl.dropbox.com/u/54818507/inf_arena.module.zip inf_arena.module]

Modding:Tutorial/Game Objects

2025-08-11T12:29:16Z

Epyon:

Objects in DRL are based on object-oriented programming, which allows for very intracite and elegant systems of functions and variables to work in tandem. Practically everything in DRL, whether it be items and enemies, or the level itself, or even the player classes, is based in its particular object class. This section of the tutorial focuses on understanding this core part of the customization process: creating and modifying the game's objects.

==Introducing Tables==

A very large part of customizing the objects in DRL (weapons, powerups, enemies, etc) has to do with creating, manipulating, and referencing lua tables. All objects in the game are associated with some table or tables: they hold a number of fields, each of which contain a key (the variable) and a value. The following is an example of a very simple table:

<source lang="lua">
Dude = {
name = "John Romero",
type = "Awesome guy",
}
</source>

Adding this to a lua script would create a table called "Dude" with two fields: the key ''name'', which is set to the value 'John Romero'; and the key ''type'', which is set to the value 'Awesome guy'. (You can use numbers for keys as well.) If we want to reference the values in this table, we can use the following format:

<source lang="lua">
Dude.name --gives the value "John Romero"
Dude.type --gives the value "Awesome guy"

Dude["name"] --identical to Dude.name
</source>

While you can create tables yourself, more often than not you will be creating tables based on a specific class. (A class is like a variable type, except it can carry a vast amount of variables, tables, and functions within it. You just need to know how to work with them so there's no reason to go into detail.) These classes are based on the game's core objects and include "Beings", "Items", and "Missiles". To create a table using a class, do not use an equal sign.

<source lang="lua">
Beings{
name = "super enemy",
ascii = "S"
....
}
</source>

The result is that a new table called "super enemy" will exist as a part of the Beings class.

There are four important parts to understand when working with classes in DRL modding:

*The prototype is the game object's mold: the game uses it to make as many objects as necessary. Whenever you create a new object, you will do so by creating the prototype.
*The properties are the variables in a particular object that can be modified for said object. They are distinct from prototype: changing values in the prototype affects ALL objects, while changing properties affects only the object in your scope.
*The engine hooks are ways to execute code when particular events occur for an object. Hooks are why phase devices teleport you around when you use them (with an OnUse hook) and why shamblers regenerate their health every turn (with an OnAct hook).
*The API is a set of functions that lets you interact with various pieces of the DRL engine. Often this gives you an easier way to change the prototype after initializing it, although there are a wide-ranging collection of functions for each class that allow for interesting game possibilities.

We will cover all of these in the following sections.

==Prototypes==
Every game object starts with its prototype. It is meant to be a stable definition of an object from which various properties of an instantiated object can be used and modified. We will begin by looking at the basic keys used to designate an Item object prototype (full documentation can be found [[Modding:Item|here]]).

<source lang="lua">
Items{
name = "a thing", --name of the item, as viewed in-game
id = "thing", --item's in-script reference name (defaults to name)
color = LIGHTGRAY, --color of item, as viewed in-game
level = 1, --minimum in-game floor on which that item can appear
weight = 1000, --weighted likelihood of item spawning
type = ITEMTYPE_NONE, --type of item
}
</source>

You should notice that, in addition to the normal value types, there are special values used for ''color'' and ''type''. Very often there are a number of pre-defined values by the game and can be found in full in the [[Modding:Constants|constants and flags]] page, which should be used in some of the prototype fields. In particular, ''color'' can be [[Modding:Constants#Colors|any of sixteen colors]] (e.g., LIGHTGRAY) and ''type'' can be any of [[Modding:Constants#ItemType|twelve particular item settings]]. Most often you will see types such as ITEMTYPE_RANGED, ITEMTYPE_PACK, and ITEMTYPE_POWER used, but you should take a look at all of them to see what best suits your need for the particular item.

ITEMTYPE_RANGED, for instance, contains the following additional prototype keys:

<source lang="lua">
Items{
name 'big gun',
....
type = ITEMTYPE_RANGED,
desc = "It's a really big gun.", --in-game description, as viewed in the inventory
ascii = "}", --single character representing the weapon, as viewed in-game
damage = "4d4", --weapon's damage: should be written as 'XdY' ala dice notation
damagetype = DAMAGE_BULLET, --weapon's damage type
group = "weapon-biggun", --weapon's category: mainly for score-keeping
ammoID = "bigbullet" --ammo that weapon uses: use the id of that ammo here
fire = 10, --how quickly the weapon fires, in turns (1 second = 10 turns)
acc = 3, --how accurate the weapon is
ammomax = 50, --weapon's clip size
radius = 0, --size of shot's explosion radius
shot = 5, --how many shots the weapon fires
shotcost = 1, --how much ammo each shot takes
missile = "big_shot", --what the projectile of the weapon is
}
</source>

For the ''desc'' key, since the string itself contains a single quote, we can wrap the string around double-quotes: lua handles this without error. Alternatively, we could use a backslash (such as \') to add otherwise-unusable characters in strings.

There are also some additional keys for alt-fires and alt-reloads, but these are the most important for setting up a ranged weapon. Notice that the last key requires an identifier from a missile object: while there are a number of pre-set missiles from which you can choose, you can also [[Modding:Missile|create your own missile prototype]] and use the id key from that prototype for the missile (the above example would require a missile object with the id of 'big_shot'). Additionally, if the missile you design is unique to this weapon, you can define the prototype directly in the weapon, like so:

<source lang="lua">
Items{
name 'big gun',
....
missile = Missiles{ --assign missile prototype
.... --missile prototype keys go here
} --missile prototype completes on this line
} --item prototype completes on this line
</source>

In creating the missile this way, you can omit the identifier of the missile, as it is automatically created for you (and should not need to be called anyway).

Referencing and changing prototype values is a more difficult than changing properties (see below), and potentially dangerous depending on what you are trying to do. It is quite possible, however, by first referencing the class that the prototype belongs to, followed by the id of the prototype, followed by the key whose value you wish to reference/change:

<source lang="lua">
local new_damage = "3d3" --create a damage variable
items.pistol.damage = new_damage --change the damage key of the pistol prototype
</source>

Executing this code will change the damage of every pistol object in the game. In general, this is not recommended for use with any code that occurs after the game has already started.

==Properties==
An object's properties are its own unique set of characteristics that set it apart from any other object in the game, including other copies of the same object. An object will initially receieve its property values from the object's prototype on creation, but they can be changed constantly after this without affecting other object instances.

One easy object that can have its properties manipulated without worrying about other instances is the player. As there is only ever one player in the game at any time, it is much easier to simply manipulate property values rather than digging into the prototype. The player has properties from both the [[Modding:Player|player object]] and the [[Modding:Being|being object]], since the player is actually a sub-class of beings. If we wanted to change the player's health and experience level, we would do it in the following way:

<source lang="lua">
player.hp = player.hp + 10 --increases player's HP by 10
player.explevel = 5 --sets player's level to 5
</source>

Note that the health property is ''hp'', not ''HP'': while this is just a case-sensitive example, sometimes the key of a property field representing a prototype key can be very different (beings have the ''XP'' field for how much experience they give, but an ''expvalue'' for their corresponding property). Be aware of these differences when coding.

Properties must always refer to a specific instance of an object. While it may seem bothersome to have to point to a specific object every time you want to change a property, these are automatically handled by engine hooks and the API, as we will see shortly.

==Engine Hooks==
Engine hooks are functions that allow you to truly customize object interaction. They are associated with specific events in the DRL engine and essentially allow for input of anything you want to occur during those events.

Like prototype keys, engine hooks are added during the initialization process of the object. They should be placed at the end of all the prototype keys, and are written much like functions:

<source lang="lua">
Beings{
name = "nasty",
.... --other prototype keys are added
OnAction = function(being) --engine hook is called
.... --code to be executed in the hook goes here
end, --function ends
} --prototype ends
</source>

The following shows a being called "nasty" getting initialized into DRL and, with it, the hook '''OnAction()'''. Hooks work just like functions do, carrying input arguments and a potential output return value. '''OnAction()''' has a ''being'' input argument, which is used as a reference to the being whenever '''OnAction()''' triggers for that particular being; '''OnAction()''' has a void output argument, meaning that you cannot return a value using this hook. (Note that, for hooks with output arguments, the return value affects an outcome on the engine side rather than a usable value in the code.) The '''OnAction()''' hook itself is triggered whenever a being carries out an action (usually once per second), and so will be constantly called over the course of the being's lifetime.

Hooks are applied to a particular instance of an object, not the prototype itself. This means that, if you're changing, for instance, the HP value of a being, you must call the being's ''hp'' property rather than its prototype key. What makes the input argument so useful is that it automatically refers to whatever being activated the hook, rather than you needing to specify exactly which being needs to call the function. Thus, if we want a being object that regenerates its health on every action (like the shambler), we would write the following code:

<source lang="lua">
Beings{
name = "regenerator",
....
OnAction = function(being) --initialize the hook
if being.hp < being.hpmax --prevent being from healing past maximum health
being.hp = being.hp + 1 --being gains one HP
end --end of conditional statement
end, --end of engine hook
}
</source>

First, we check to see if the being instance's health is less than its maximum health: if this is true, we raise the hp property of the instance by one; if not, nothing happens. Once the if statement finishes, there is nothing left for the function to do, and so it ends as well. '''OnAction()''' will make it so that the if statement is called every time the being instance acts, so it could be hard to kill something like this! (Anyone trying to kill shambler with a shotgun should understand well enough.)

Most of the engine hooks are found with the item and level object classes, since there are a number of events that the engine specifically checks for these objects over the course of their lifetimes. Common hooks are '''OnCreate()''', '''OnEnter()''', and '''OnDestroy()'''/'''OnDie()''' (which practically do the same thing, just for different object classes).

==API==
Object API is very simple in DRL: for each object class, there is a set of pre-defined functions, called methods, that allow modders to manipulate objects of that class. Most, if not all, of the methods in an object's API are otherwise impossible to create within lua itself, which is why we are lucky to have them available. Unlike functions, however, you need not define methods as such: simply writing the functional expression itself (without preceding it with "local function", for example) is all that is necessary.

In lua, the convention for methods is to use a period between the class name and the method name. If the first argument requires a particular instance of an object in that class, one can use shorthand by writing out the object instance, followed by a colon, then the method name, at which point the first argument is automatically used in the method without having to explicitly write it.

<source lang="lua">
being.new(id) --this will allocate a new instance of the being object id to memory
being.destroy(some_being) --this will deallocate a being instance called some_being from memory

some_being:destroy() --identical to being.destroy(some_being)
</source>

Whenever you are not working with a particular instance of an object, it usually means you are creating a new one. For [[Modding:Coord|some objects]], this is a very important use. However, most of the API is meant to interact with specific object instances, so we will take a look at an example for such a method.

Let us suppose we want to make an enemy explode whenever it dies. One way to do this is the following:

<source lang="lua">
Beings{
name = "exploder"
....
OnDie = function(self) --engine hook upon death
position = self:get_position() --position for being is found
Level.explosion(position, 3, 30, 5, 5, YELLOW, "", DAMAGE_FIRE) --explosion occurs on the map
end,
}
</source>

Here we use the '''OnDie()''' hook to execute code whenever an "exploder" being dies. Creating an explosion on the map is done with the method '''Level.explosion()''', which carries quite a few input arguments: coordinates on the map where explosion should happen, radius of explosion, millisecond delay on explosion's path, damage dice, side of damage dice, color of explosion, sound id for explosion, and damage type of explosion. (Note that there are even more arguments, but these can be safely ignored if they appear after all the arguments we end up using.) The coordinates of the being instance are not immediately accessible in its properties, but can be found with the '''thing:get_position()''' method (where the Thing in this case is the being instance, or ''self'', defined inside of the OnDie hook). In order to get the coordinates, we assign an output argument ''position'' to '''thing:get_position''', and use it in '''Level.explosion''' when we need to define them.

==Review==
As a final, rather large example, we will take a look at one of the enemies from the HereticRL mod (though this exact code might be outdated at some point), the undead warrior. The undead warrior is a fairly straight-forward enemy with the unique twist in that it will occasionally throw red axes (as opposed to green ones), which deal much more damage. To start, we will first need to initialize the two axe weapons: since the undead warrior will have more than one weapon, we cannot inline them within the being definition.

<source lang="lua">
Items{
name = "nat_undeadgreen", --this is the green axe weapon
id = "nat_undeadgreen",
type = ITEMTYPE_NRANGED, --natural ranged-weapon type
damage = "2d6",
damagetype = DAMAGE_BULLET,
fire = 10,
missile = { --in-line missile definition
soundID = "undead",
ascii = "x",
color = LIGHTGREEN,
delay = 80,
miss_base = 10,
miss_dist = 5,
},
weight = 0, --don't want these being generated!
flags = {IF_NODROP, IF_NOAMMO}, --these are standard flags for NRANGED items
}

Items{
name = "nat_undeadred", --this is the red axe weapon
id = "nat_undeadred",
type = ITEMTYPE_NRANGED,
damage = "6d2", --better damage than green axe (on average)
damagetype = DAMAGE_PLASMA, --stronger damage type
fire = 10,
missile = { --in-line missile definition
soundID = "undead",
ascii = "x",
color = LIGHTRED, --different color
delay = 50,
miss_base = 10,
miss_dist = 3, --misses less
},
weight = 0,
flags = {IF_NODROP, IF_NOAMMO},
}
</source>

These must be placed in the code before we define the undead warrior itself, as they are called within the being prototype.

<source lang="lua">
Beings{
name = "undead warrior",
name_plural = "undead warriors", --this would work as such by default
id = "undead", --small ids are nice for calls
ascii = "u",
color = LIGHTGRAY,
sprite = 0, --necessary, always set to 0 for now
corpse = true, --whether being leaves a corpse
toDam = 6, --inherent damage modifier (for melee)
toHit = 4, --inherent accuracy modifier
speed = 100, --time of actions: 100 = 1s; <100 = >1s; >100 = <1s
armor = 2, --protection value
danger = 6, --weight for generation, can also determine experience
XP = 0, --set experience specially
weight = 250,
minLev = 7, --lowest floor being will generate
maxLev = 20, --highest floor being will generate
HP = 50,
attackchance = 60, --chance being will attack as its action
toHitMelee = 0, --inherent accuracy modifier (for melee, adds to toHit)
res_fire = 50, --percentage resistance to damage type DAMAGE_FIRE
res_acid = 50,
ai_type = "natural_melee_ranged_ai", --how the enemy moves/reacts, can define yourself
desc = "As part of the Order's insidious plot to control your world, they've recruited the dead, " ..
"gave them armor and armed them with deadly magic axes. Now they guard the evil cities and " ..
"toss their infinite supply of axes at any elf who passes by.",
kill_desc = "took an axe to the face from an undead warrior", --shows up in mortem if you died to this being
kill_desc_melee = "chopped in two by an undead warrior", --same as above but by melee attack
OnCreate = function(self)
self.eq.weapon = item.new("nat_undeadgreen")
end,
OnAction = function(self)
if(math.random(6) == 1) then
self.eq.weapon = item.new("nat_undeadred")
else
self.eq.weapon = item.new("nat_undeadgreen")
end
end,
}
</source>

Typically, for an enemy that has a ranged attack, you would use the prototype field ''weapon'' and in-line an item definition with type ITEMTYPE_NRANGED. However, since the undead warrior has two different attacks, we choose to assign it two separate weapons over the course of its lifetime through engine hooks.

*Whenever an undead warrior is created, it is given a green axe in its weapon equipment slot: this is done by assigning a new item to the weapon field of the equipment property with an '''OnCreate()''' hook.
*On every action there's a chance for the undead warrior to get a red axe in its weapon equipment slot.
**First we call the '''OnAction()''' hook to make a check on every action.
**Next, we supply a random condition using '''math.random(''num'')''' (which randomly chooses an integer between 1 and ''num''). if('''math.random(6)''' == 1) produces a 1/6 chance of the condition being true.
**If the condition becomes true, we create a new item (this time a red axe) to the same field as before.
**If the condition is false, we put a new green axe there instead. This is to ensure that the red axe is only in the undead warrior's equipment slot 1/6 of the time.

And that's all there is to it! You'll want to change the ''soundID'' in the missile definitions, but otherwise this code should run in any module you create.

Modding:Tutorial/Custom Beings

2025-08-11T12:28:44Z

Epyon:

In the following tutorial you will learn the basics of [[Modding:Being|being objects]]. Beings are anything in the game that can act independently on the map, without the need to specifically interact with with it. The [[Modding:Player|player object]] is also a being, and so all of the topics mentioned here will also apply to the player (with some exceptions). We will learn how to create new beings, as well as how to apply various modifications in order to produce special and unique varieties.

==Prototype==
The following is a complete list of the being prototype table:
<source lang="lua">
Beings{
name = "evil marine", --required field
name_plural = "evil marines", --defaults to name with an appended 's'
id = "badclone", --defaults to lowercased first word of 'name'
ascii = "@", --required field
color = DARKGRAY, --required field
sound_id = "soldier", --checked if 'id' has no sound bindings
desc = "It's you, but evil." --required field
kill_desc = "fragged by your evil clone", --defaults to ""
kill_desc_melee = "mauled by your evil clone", --defaults to ""
weight = 1, --required field
danger = 12, --required field
minLev = 20, --required field
maxLev = 100, --defaults to 200
corpse = true, --defaults to true
HP = 100, --defaults to 10
armor = 2, --defaults to 0
res_bullet = 0, --defaults to 0
res_melee = 0, --defaults to 0
res_shrapnel = 0, --defaults to 0
res_acid = 0, --defaults to 0
res_fire = 0, --defaults to 0
res_plasma = 0, --defaults to 0
weapon = "bazooka", --defaults to "" (no weapon)
toDam = 5, --defaults to 0
toHit = 5, --defaults to 0
toHitMelee = 0, --defaults to 0
attackchance = 60, --defaults to 75
vision = 11, --defaults to 9
speed = 100, --defaults to 100
XP = 2000, --defaults to 3*'danger'^2+20
ai_type = "cyberdemon_ai", --defaults to ""
group = 0, --defaults to 0
flags = {}, --defaults to {}
bulk = 100, --defaults to 100
sprite = 0, --required field, set to 0
overlay = {0,0,0,0}, --defaults to {0,0,0,0}
}
</source>

*''name'' is what the being appears to be in-game (e.g., using the 'look' command).
*''name_plural'' is what the game uses when a pluralized form of the name is required (e.g., in the kills section of the mortem).
*''id'' is the being identifier, to be used in lua whenever you want to call the item prototype.
*''ascii'' is the ASCII character used to represent the being in the console.
*''color'' is one of 16 (4-bit) [[Modding:Constants#Colors|colors]] that you can use to distinguish the being on the map.
*''sound_id'' is what you want the being's sound bindings to map to. If the being's id is not registered for sound bindings, it will use this key instead (useful when mapping several beings to a single set of sounds). (Note that in the current version, registering sound bindings for custom beings requires direct manipulation of the prototype. This will be explained later on.)
*''desc'' is the description of the enemy, as seen when using the 'more' command while looking.
*''kill_desc'' is what shows at the top of a mortem if the player was killed by this being's ranged attack.
*''kill_desc_melee'' is what shows at the top of a mortem if the player was killed by this being's melee attack.
*''weight'' affects the frequency that the being will appear, for random monster generation purposes.
*''danger'' is the capacity by which the being can be added to the map, for random monster generation purposes.
*''minLev'' is the earliest floor on which the being can appear, for random monster generation purposes.
*''maxLev'' is the latest floor on which the being can appear, for random monster generation purposes. ''weight'', ''danger'', ''minLev'', and ''maxLev'' are only important on levels that randomly generate beings using Level.flood_monsters().
*''corpse'' determines if the being will generate a corpse upon death. Alternatively, you can choose a cell (by referencing its id here) that the being will leave upon death.
*''HP'' determines how much damage the being can take before it dies.
*''armor'' determines how much damage the being absorbs before HP is subtracted, modified by the damage type of the source. Note that, without BF_HARDY, armor can only reduce damage to 1.
*''res_[damage_type]'' sets the internal [[resistances|resistance]] of the being for damage_type. Internal resistance affects both torso and foot sources. Note that amount of damage absorbed by resistance is calculated before any damage absorption due to ''armor'', and that 100% resistance can reduce damage to 0 (though anything less will not).
*''weapon'' sets the being's default weapon (in its weapon equipment slot). This can either be an id for a separate [[Modding:Item|item prototype]], or it can be inlined into the being prototype. If inlined, the following is true by default for the item prototype:
**''type'' is set to ITEMTYPE_NRANGED
**''id'' is automatically assigned (although no lua-based id (sid) will exist)
**''weight'' and ''sprite'' are set to 0
**IF_NODROP and IF_NOAMMO are added to the ''flags'' table
*''toDam'' is the damage modifier to the being's natural melee attack. It deals 1d3 damage unmodified.
*''toHit'' is the [[accuracy]] modifier to all of the being's attacks.
*''toHitMelee'' is the accuracy modifier to the being's melee attack. toHit and toHitMelee can have negative values (e.g., in order to set melee to-hit to 0 while keeping ranged to-hit at some positive value).
*''attackchance'' is the chance that the being will attack on a given turn. This can be overridden with custom AI.
*''vision'' is the [[distance]] in which the being can see, assuming no cells that block vision are present.
*''speed'' is the speed of any of the being's internal actions (e.g., movement and attacking). Values greater than 100 result in a faster being, while values less than 100 result in a slower being. The maximum value this can be set to is 255.
*''XP'' determines how much experience the player receives upon killing the enemy. Only the player can benefit from experience.
*''ai_type'' sets the AI of the being. There are a number of pre-defined AI for the base monsters, but it is possible to define your own.
*''group'' assigns the being to a particular group of other beings that it will not attack. Beings of different groups, by default, will attack each other. In the base game, all monsters are in group 0, while the player is in group 1.
*''flags'' defines what [[Modding:Constants#Being Flags|being flags]] you give the being.
*''bulk'' is an unused parameter, so you can ignore it entirely.
*''sprite'' is what will eventually be the graphical tile of the being. Set to 0 and ignore it for now.
*''overlay'', like sprite, is based on there being graphical tiles in DRL. You can ignore this key entirely for the time being.

==Properties==
Several of the being object properties are identical to their prototype counterparts, others differ only by name. The comparisons are given here:

*The following properties are the same as the prototype keys:
**''attackchance''
**''vision''
**''speed''
**''armor''
*The following properties have a different name than a prototype key, but function exactly the same as the key:
**The key ''sound_id'' is broken up into the following properties:
***''soundact'' is heard occasionally whenever the being acts
***''soundhit'' is heard whenever the being takes damage
***''sounddie'' is heard whenever the being dies
***''soundattack'' is heard whenever the being uses a ranged attack
***''soundmelee'' is heard whenever the being uses a melee attack
***''soundhoof'' is heard whenever the being moves (often disabled on most beings)
**''hpmax'' is the property of ''HP''
**''tohit'' is the property of ''toHit''
**''todam'' is the property of ''toDam''
**''tohitmelee'' is the property of ''toHitMelee''
**''expvalue'' is the property of ''XP''
*There are also a number of properties that are instantiated by default without automatic customization. They are as follows:
**''proto'' is the being's prototype. Don't change this unless you're planning on doing something really hacky.
**''hp'' is the being's current health. It defaults to the ''HP'' prototype key, but changes whenever the being takes damage.
**''scount'' is the being's speed count, or [[Time#Fractional_Time|energy]]. For each turn that passes, all beings' ''scount'' is increased 100 (modified by each's ''speed''); whenever a particular being takes an action, its ''scount'' is decreased by the amount of game seconds it takes for the action, multiplied by 1000. (For custom actions, ''scount'' must be modified manually in order for the action to take any time.)
**''todamall'' is a damage modifer applied to all of the being's attack (melee and ranged). (When the player invests in [[Son of a Bitch]], this property is modified.)
**Three properties affect the time in which particular actions are taken, given as a percentage relative to ''speed'':
***''movetime'' affects how much time it takes for the being to move: for the player, this also corresponds to an increased dodge chance. (When the player invests in [[Hellrunner]], this property is modified.)
***''reloadtime'' affects how much time it takes for the being to reload its weapon. (When the player invests in [[Reloader]], this property is modified.
***''firetime'' affect how much time it takes for the being to attack. (When the player invests in [[Finesse]], this property is modified.)
**''bodybonus'' reduces knockback by the number given, and any value greater than 0 will prevent health decay above 100%. (When the player invests in [[Badass]], this property is modified.)
**''pistolbonus'' lowers firetime and increases damage whenever the being is using a weapon with the item flag IF_PISTOL. (When the player invests in [[Son of a Gun]], this property is modified.)
**''rapidbonus'' modifies the number of shots fired from a weapon whose "shots" property is greater than one. (When the player invests in [[Triggerhappy]], this property is modified.)
**''techbonus'' increases the number of mods that can be added to the being's equipment, as well as what tier of assemblies the being can create. (When the player invests in [[Whizkid]], this property is modified.)
*Finally, there are the properties that beings inherit from [[Modding:Thing|things]]. (Some of the thing properties are readonly, meaning they can't be changed once the instantiated object is initialized. These will be bolded for clarification.)
**The following properties are the same as the prototype keys:
***''color''
***'''''id'''''
***''name''
***''sprite''
***''res_bullet''
***''res_shrapnel''
***''res_melee''
***''res_acid''
***''res_fire''
***''res_plasma''
**The following properties have a different name than a prototype key, but function exactly the same as the key:
***''picture'' is the property of ''ascii''
***''nameplural'' is the property of ''name_plural''
**The following properties are automatically given by default:
***'''''sid''''' is a string identifier, similar to '''''id'''''. This is what is used dominantly by modders, and is set based on the being's ''id'' key.
***'''''uid''''' is a unique identifier across all instantiated objects. This is often used to save the state of a game.
***'''''x''''' is the x-coordinate of the being on the map.
***'''''y''''' is the y-coordinate of the being on the map. '''''x''''' and '''''y''''' make up a being's [[Modding:Coord|coordinate]] indirectly.
***'''''__ptr''''' is a pointer to the object in the engine: you'll never have to worry about this property.

==Engine Hooks==
Beings come with three hooks:

*'''OnCreate'''(''being'') is called when ''being'' is allocated to memory (i.e., created but not necessarily placed on the map). Use this function to add or modify properties, or potentially cause special cases to occur depending on the circumstances of the creation.
*'''OnAction'''(''being'') is called whenever ''being'' takes an action. This is where a great deal of code used to be added when a modder wanted to manipulate the being's special abilities and/or AI, but is now mostly used as a means to have abilities that should be activated on every action. For more complicated setups, the modder should create a special AI for the being (explained in a separate tutorial).
*'''OnDie'''(''being'',''overkill'') is called whenever ''being'' dies. The ''overkill'' parameter is a boolean that only triggers '''OnDie()''' if ''being'' was gibbed on death. (In this way you can set up two separate '''OnDie()''' hooks to the same being prototype.)

==Basic Examples==
There are quite a few things you can do with beings. The following examples will go through the more common uses for beings: you should feel free to work with any of these as a base for your own designs.

===Dummy===
Dummies are beings that cannot be killed but cannot kill, either. They are mainly used as targets, potentially as a trigger or simply something to shoot at. In spite of this simple purpose, there is a lot you can do with dummies. First, let's add the prototype fields:

<source lang="lua">
Beings{
name = "dummy",
id = "dummy",
ascii = "I",
color = WHITE,
desc = "Nothing but a punching bag."
sprite = 0,
weight = 0,
danger = 0,
minLev = 0,
speed = 0,
flags = {BF_INV},
}
</source>

Since the dummy isn't going to be attacking at all, we can ignore a great deal of keys, and unless we want the dummy to be able to randomly spawn with other enemies, we set the generation parameters to 0. The important factors to this prototype involve the being's ''speed'' and ''flags'':

*''speed'' is set to 0, so the dummy will never have any turn whatsoever.
**If you want the dummy to attack but not move, you can set the BF_SESSILE flag (which does exactly that).
**If, instead, you want the dummy to move but not attack, you can set the BF_NOMELEE flag (which prevents melee attacks). To avoid ranged attacks, just don't give the dummy a ranged weapon with which to attack.
*"BF_INV" is the flag set when a player is [[effects#invulnerable|invulnerable]], which prevents any damage from being taken regardless of its source (even going so far as to include a nuclear explosion!).
**If you want to prevent only certain types of damage, you can alternatively set any of the six resistance keys to 100, allowing for complete immunity against that type of damage. Note that there is no resistsance for piercing attacks, nor would this dummy ever withstand a nuclear explosion.
**If you want the dummy to be able to take damage but not die, you can set the HP to a ridiculous amount, such as 1000, and use a hook to set its ''hp'' to ''hpmax''. This should prevent death in all but the most extreme cases. (I don't know the limit on HP, but 1000 will actually work.) Note that, if the dummy's speed is set to zero, the '''OnAction()''' hook won't trigger.

Now we can place the dummy on the map and go to town. However, this dummy can still be pushed around if it takes enough damage, and there's a good chance we don't want to chase this thing all across the map. There are two ways to add some knockback prevention:

<source lang="lua">
Items{
name = "dummysuit"
weight = 0,
sprite = 0,
type = ITEMTYPE_ARMOR,
desc = "for dummy",
knockmod = -100,
flags = {IF_NODROP},
}

Beings{
name = "dummy",
....
OnCreate = function(self)
self.eq.armor = item.new("dummysuit")
end
}
</source>

The first method is to create a [[Modding:Tutorial/Custom Items|custom item]], either armor or boots, that provides 100% knockback reduction, and then place the armor/boots in the dummy's armor/boots equipment slot on creation. The "IF_NODROP" flag is there so that, no matter what kind of dummy you create, it will never let the armor drop (allowing the player to wear it).

<source lang="lua">
Beings{
name = "dummy",
....
OnCreate = function(self)
self.bodybonus = 100
end
}
</source>
The second method is to alter the dummy's ''bodybonus'' property on creation, setting it to a very high amount so that only extreme amounts of damage will ever cause movement. ''bodybonus'' works like the Badass trait, so each point will prevent X damage from causing knockback, where X depends on the damage type (usually 12, 7 for fire). (Note that ''bodybonus'' accepts only ShortInt values, which range from -128 to 127.) This isn't as guaranteed as the first method, but requires fewer lines of code to execute and doesn't add a new item definition.

Now that we have an indestructible, immovable being, we can try making it useful. One fairly simple possibility is to have it spawn with an item and have it act as a decoy for other enemies to attack while you run from them. Here is one way to set it up:

<source lang="lua">
Items{
name = "hologram projector",
id = "holo",
level = 10,
weight = 30,
sprite = 0,
desc = "Creates a virtual replica of yourself. These hellish buffoons won't know the difference!"
type = ITEMTYPE_PACK,

OnUse = function()
local p = player:get_position()
local a = area.around(p,1)
Level.area_summon(a,"decoy",1)
return(true)
end,
}

Beings{
name = "decoy",
id = "decoy",
ascii = "@",
color = LIGHTGRAY,
desc = "It looks just like you!",
soundID = "soldier",
sprite = 0,
weight = 0,
danger = 0,
minLev = 0,
group = 1,
speed = 40,
flags = {BF_INV},

OnCreate = function(self)
self.bodybonus = 100
self.scount = 4000
end,

OnAction = function(self)
self:kill()
end,
}
</source>

The item, called ''holo'', uses '''Level.area_summon()''' to spawn a single dummy being adjacent to the player. The area is found by first getting the coordinate of the player using '''player:get_position()''', and then using that coordinate to create a square centered around that coordinate with '''area.around()'''.

The being, called ''decoy'', is very similar to our original dummy, although a few things have changed in order to make it work properly:

*First, we set ''speed'' to a non-zero but small number. This will serve as the decoy's timer.
*Next, we change the decoy's scount on creation to 4000. Since each turn increases ''scount'' by ''speed'', and beings take actions when their ''scount'' is 5000, we can calculate that (5000-4000)/40 = 25, which is the amount of game seconds that the being will exist before taking an action.
*Finally, we modify the decoy's '''OnAction()''' hook to remove itself from the map using the '''being:kill()''' method. This is used instead of the '''Level.clear_being()''' method so that it doesn't interfere with 100% completions (since any being added to the map will add one to the total enemies on the map).
*In addition to the changes above, we also set ''group'' to 1, same as the player's, so that all enemies will attack the decoy just as they would the player. (To be fair, I don't know how well this works with the enemy AI, but this is the only way for this to work short of very specific AI modifications.)

The end result is that we have an item that causes a decoy to spawn next to the player, which lasts for 25 turns and will be attacked by enemies before disappearing. It should work in theory, although the extent to which enemies will attack a pacifist decoy aren't well-known. It is likely that you'll need not to attack enemies yourself to get the best use out of it.

===Multi-form Beings===
A multi-form being is one that changes while you are fighting it. This can come in a variety of forms (HP loss, actions taken, level-specific triggers) and can cause a variety of changes (stat modifications, weapon changes, new abilities). They are most often created for the purpose of "boss fights" or some similarly final combat in the level or game. Let's begin by setting up the prototype for a multi-form being:

<source lang="lua">
Beings{
name = "mecha-baron",
name_plural = "mecha-barons",
id = "mechbaron",
ascii = "H",
sprite = 0,
color = LIGHTMAGENTA,
sound_id = "arachno",
desc = "Looks like someone found one of the gunner 'bots."
kill_desc = "gunned down by a mecha-baron",
kill_desc_melee = "smashed to dust by a mecha-baron",
weight = 1
danger = 15,
minLev = 20,
corpse = "baron",
HP = 140,
armor = 0,
res_bullet = 25,
res_melee = 50,
res_shrapnel = 25,
weapon = {
damage = "1d10",
damagetype = DAMAGE_BULLET,
fire = 12,
shots = 10,
soundID = "chaingun",
missile = "chaingun",
}
toDam = 15,
toHit = 1,
toHitMelee = -1,
attackchance = 40,
vision = 9,
speed = 80,
ai_type = "melee_ranged_ai",
flags = {},
}
</source>

The idea behind this multi-form being is that a Baron of hell is inside some kind of vehicle (typically known as a "mech") which augments its fighting power. It has the equivalent of an assault cannon for the attack and never runs out of ammo, though is slightly less accurate to compensate), and a remarkable amount of health and resistances. However, the baron operating this machine isn't quite as skilled a trained marine or the mech's own AI would be, so it's fairly slow at the same time.

Now let's add a second form:

<source lang="lua">
Beings{
name = "mecha-baron",
....

OnCreate = function(self)
self:add_property("rogue",false)
end,

OnAction = function(self)
if self.hp < 70 and not self.rogue then
self.hp = 70
self.name = "rogue mech"
self.color = DARKGRAY
self.weapon.fire = 10
self.tohit = 3
self.speed = 100
self.group = 2
self.rogue = true
self:msg("Pilot dead: massacre mode activated.")
end
end,
}
</source>

The idea behind the second form is that the player managed to kill the baron inside of the vehicle, but now that it no longer has a living pilot, the mech begins shooting everything around. In order to implement this form, we add a trigger property called ''rogue'' which is set to false upon creation. Once the mecha-baron's HP dips below 70 while ''rogue'' is false, we set the HP back to 70, change some properties like name, color, and combat stats, then set ''rogue'' to true (so that it doesn't trigger again). ''group'' is also set to a value different from normal enemies and the player, which causes the being to now attack and be attacked by everything. Finally, we get a message indicating that this has occured (assuming the player is in sight of the mecha-baron when this happens).

Note that, when the rogue mech finally dies, it will drop a baron corpse: the mech itself cannot be revived, but the mangled body inside of it can, which is why we set this. If you wanted to be creative, you could drop the corpse when the baron "dies", although you should be careful about where it's dropped and if it should be dropped (for instance, corpses typically don't replace fluid or door tiles).

===Special Abilities===
Even in the base game, there are a variety of special abilities that enemies use. Typically, these are handled either through flags or the '''OnAction()''' hook.

While there is really only one flag that takes care of in-game abilities for enemies (the first one here), there are plenty that correspond to benefits and disadvantages given to the player.

*'''Immunity to environmental damage''', namely walking on acid and lava tiles, is set with the BF_ENVIROSAFE flag. This is also the same flag used with the player activates an [[envirosuit pack]]. Custom hazard cells must check for this flag during the '''OnEnter()''' hook for it to apply (at which point the tile can deal whatever damage you want it to).
*'''Berserk boosts''' are handled with the BF_BERSERK flag (not to be confused with BF_BERSERKER).
*'''Invulnerability to all damage''' comes from the BF_INV, as described earlier.
*'''Increased ammo capacity''' is gained using BF_BACKPACK. This only works at a +40% bonus: if you want full control (and, to some extent, better handling of ammo in your inventory when you get this effect) you'll want to design a custom script that changes ''ammomax'' of all ITEMTYPE_AMMO items, then systematically rearrange the player's inventory when the effect activates.
*'''Regeneration''' can be handled through the BF_REGENERATE flag, which works once per second (rather than action). However, the benefit only applies for up to 20 HP.
*'''Class bonuses''' have a few flags as well:
**BF_POWERBONUS increases all base-game powerup durations by 50%. If you want to use both base and custom powerups, you'll have to check for this flag on any customs during the '''OnUse()''' flag that applies an effect (at which point you can change the duration to whatever you want). When modding with only custom powerups, this flag is superfluous.
**BF_STAIRSENSE counts all tiles with the CF_STAIRS flag as permanently visible.
**BF_INSTAUSE reduces all time spent using ITEMTYPE_PACK items to a single turn, rather than the default 1.0s (10 turns).
**BF_MAPEXPERT is what makes [[Computer Map|Computer Maps]] act like [[Tracking Map|Tracking Maps]]. For modding, this is mostly superfluous.
*'''Trait bonuses''' that don't include a simple change in stats (such the ''bonus'' properties) are typically given through flags:
**[[Juggler]] uses the BF_QUICKSWAP flag
**[[Berserker]] uses the BF_BERSERKER flag (attack-based benefits only apply to melee hits)
**[[Dualgunner]] uses the BF_DUALGUN flag (benefits only apply if both weapons in the weapon and prepared slots have the IF_PISTOL flag)
**[[Dodgemaster]] uses the BF_MASTERDODGE flag
**[[Intuition]] uses several flags:
***BF_POWERSENSE reveals powerups
***BF_BEINGSENSE reveals enemies (using the intuition color/symbol from config.lua)
***BF_LEVERSENSE1 and BF_LEVERSENSE2 provide more detailed information about levers. [[Modding:Tutorial/Custom Items#Lever (_LEVER)|Custom levers]] can be made to take advantage of these flags, if you so choose to.
**[[Shottyman]] uses the BF_SHOTTYMAN flag (benefits only apply to items with the IF_SHOTGUN flag)
**[[Vampyre]] uses the BF_VAMPYRE flag (benefits only apply to melee kills)
**[[Army of the Dead]] uses the BF_ARMYDEAD flag. (benefits only apply to weapons that use DAMAGE_SHRAPNEL)
**[[Survivalist]] uses two flags:
***BF_HARDY allows protection and resistances to reduce damage taken to zero. On Survivalist, this only works 50% of the time, but the BF_HARDY flag is hard-coded to work in every case.
***BF_MEDPLUS allows med-packs to heal above 100%. Dependings on how you create your own health supplies, this may be a superfluous flag.
**[[Blademaster]] uses the BF_CLEAVE flag (benefits only apply to melee kills)
**[[Gun Kata]] uses the BF_GUNKATA flag (benefits only apply to weapons with the IF_PISTOL flag)
**[[Sharpshooter]] uses the BF_PISTOLMAX flag (benefits only apply to weapons with the IF_PISTOL flag)
**[[Fireangel]] uses the BF_FIREANGEL flag
**[[Scavenger]] uses the BF_SCAVENGER flag. Since non-player beings don't know how to unload items, this is useless on any being but the player.
*'''Challenge perks''' can be arranged through some flags:
**[[Angel of Impatience]] is caused by the BF_IMPATIENT flag.
**The [[Angel of Darkness]] no-exploration effect is caused by BF_DARKNESS. Note that, if applied in mid-level, it only prevents other tiles from being counted as explored.
**The [[Angel of Max Carnage]] max-damage effect is caused by BF_MAXDAMAGE.
**[[Angel of Masochism]] is caused by BF_NOHEAL.

==="Smart" Beings===
Normally monsters act solely to kill the player. There are, however, some flags that allow beings to act more intelligently while they move around, without needing to define your own AI:

*"BF_USESITEMS" allows the being to pick up items with the "IF_AIHEALPACK" flag. Armor will be immediately equipped on pickup, but the being will not carry more than one armor at a time. Consumables will be used when the being is below 50% of their health.
*"BF_OPENDOORS" allows the being to open doors, if their path would require them to move into a door.
*"BF_DISTANCE" is a flag that causes the being, as opposed to normal movement, not to seek engagement with its attacker. Useful for enemies that don't have much of a melee weapon but a powerful ranged weapon.
*"BF_CHARGE" allows the being to enter hazardous tiles when moving around. Useful for enemies that you set immune to hazardous damage (through "BF_ENVIROSAFE").
*"BF_HUNTING" sets the being to precisely target the player, regardless of where the player is. Note that this flag does not necessarily pick the best path, so beings can stll become "stuck". Unlike other flags here, BF_HUNTING works with lua-scripted AI.

These flags are still somewhat limited with regards to being intelligence, but they cover a variety of needs without having to hassle with more advanced setups.

Modding:Tutorial/Constructing a Map

2025-08-11T12:28:37Z

Epyon:

There are endless possibilities when it comes to modding DRL, whether it be custom enemies and items, or additional special levels, or maybe themes that depend on what day of the week it is. However, much of this can be difficult to understand, let alone create, if you are unfamiliar with programming techniques. For those of you simply seeking to create a single level, leaving the core elements of the game intact, there is a very easy method of doing this, especially with the advent of modules.

==Initial Setup==

If you are creating a mod, the first thing necessary for DRL to recognize it is a directory that is the identifier of your mod, along with a .module at the end: this would be placed in the "modules" directory, which exists wherever your DRL directory is. For instance, if I were creating a mod that I would identify as "coolmap" (and assuming that my DRL directory were in something like C:/Games), the path to the module files would look like this:

<source lang="text">C:/Games/DRL/modules/coolmap.module</source>

Note that this identifier is not necessarily the NAME of your map, it is simply a way to distinguish it from other modules.

After we have created this directory, there are two necessary lua files that must be in it: main.lua, which acts as the file that initializes all of the module's data; and module.lua, which provides information about the module itself. main.lua will contain everything important to the actual modding part of this tutorial, but we shall look at module.lua first.

If you are unfamiliar with creating lua script files, it is as simple as creating a text file and changing the file extension to ".lua". Refer to the Tutotial main page for more information.

==module.lua==

module.lua is a very short script, containing only what is called a metadata table, or a table that holds information about the mod. Every module.lua should look have a base like so:

<source lang="lua">
module = {
id = "", --identifier of the module (same as the folder sans '.module')
name = "", --name of module as it appears in the Custom Game menu
author = "", --your name/gamertag/nickname/alias
webpage = "", --link to your page (use 'none' if you don't have one)
version = {0,0,0}, --version of the mod itself (first version is typically {0,1,0})
drlver = {0,0,0,0}, --version of DRL that module was made for (e.g., {0,9,9,4})
type = "single", --module type (currently only "single" works)
description = "", --explains mod, though you could put whatever you want here
difficulty = true, --allows player to set difficulty (false forces ITYTD)
}
</source>

Feel free to copy and paste this into your module.lua, then fill in the information as necessary.

==main.lua==

main.lua is the core of your module, containing all of the necessary components to make the mod run as you would like it to. To start, every main.lua requires the following line:

<source lang="lua">
core.declare("module_id", {} ) --replace module_id with your module's actual id
</source>

This declares a module table that you will use to store all of the module-ranging components. In the case of single levels (currently the only mod type available), this essentially replaces the [[Modding:Level|Level object]] for the purposes of creating engine hooks that depend on events that occur within the single level. These are the following engine hooks that your module can use:

<source lang="lua">
function module_id.run() end --works just like Level.Create() (initialize map/name/spawn point/etc)
function module_id.OnEnter() end --triggers immediately after .run(), when player enters the map
function module_id.OnTick() end --triggers every game turn
function module_id.OnKill() end --triggers whenever a being other than yourself dies
function module_id.OnKillAll() end --triggers whenever all beings other than yourself are dead
function module_id.OnExit() end --triggers when player exits the map (for instance, decsending stairs)
</source>

If you choose not to use an engine hook, you don't need to include it in the script, but there's no harm in writing an empty hook in there, either.

We will now provide some very basic examples of each engine hook so you get an idea of how they can be used. The module's identifier will be "blank".

===.run()===
<source lang="lua">
function blank.run()
Level.name = "Blank Map" --name of map as it appears in lower-right corner of HUD
Level.name_number = 0 --shows "LevX" where X is value: use 0 to remove entirely
Level.fill("wall") --necessary step, use whatever wall you will mostly use

--matches all characters on map to an object_id
local translation = {
["."] = "floor",
["#"] = "wall",
[">"] = "stairs",
}

--the map itself
local map = [[
##############################################################################
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#...........................................>................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
#............................................................................#
##############################################################################
]]

Level.place_tile(translation,map,1,1) --this is the map-creation step
Generator.set_permanence( area.FULL )
Level.player(39,10) --player is placed at this coordinate
end
</source>

'''run()''' deals with the absolutely necessary pieces if you want the module to work at all. Here we define the level's in-game name, create the map, and add the player. There are two important variables we define:
*''translation'' is a table of all object ids that will be placed on the map, along with the symbols that define them on said map. You can use any symbol you want to define an object (for instance, using ["y"] = "pwall"), just remember to place it on the map with that symbol. The symbols as they are used here will not affect how the actual objects appear in-game.
*''map'' is a string that corresponds to what the map should look like when it is initialized. Here we use double-square brackets ("<nowiki>[[</nowiki>" and "<nowiki>]]</nowiki>"), which takes every character between them and writes into a single string. You can start new lines as much as you want, but do NOT include spaces unless the space character is one of the symbols used in ''translation''.

You can define ''translation'' and ''map'' whatever you want so long as '''Level.place_tile()''' calls them appropriately. The last two arguments define what x- and y-coordinates are used to begin the placing: since we are copying an entire map, we start from the upper-left tile (which is (1,1)).

Finally, to make sure none of the border walls get destroyed, we include the Generator.set_permanence() function. Walls have a permanent flag that make them indestructible, and using this function you can set an area in which all tiles are given the flag. area.FULL is an area constant corresponding to the full extent of the map, thereby setting any tiles that can be made permanent tiles, into permanent tiles. (Floors cannot be made permanent, as they cannot take damage in the first place.)

===.OnEnter()===
<source lang="lua">
function blank.OnEnter()
ui.msg("Hello world!") --appears at the top of the screen
player.inv:add("shotgun") --puts a shotgun in the player's inventory
player.inv:add("shell") --puts a shotgun shell (x8) in the player's inventory
end
</source>

The '''OnEnter()''' hook has fairly limited uses, since it is only called once and doesn't do the crucial steps like making the map itself. For the most part, it is used to add messages at the start of the map, change around the player's inventory, and, depending on what else is going on in the map, initialize some timers or countdowns.

===.OnTick()===
<source lang="lua">
local countdown = 600 --set up a timer
local minute = 0 --set up a minute counter
local exit_check = true --set up a position check

function blank.OnTick()
if countdown == 0 then
countdown = 600
minute = minute + 1
ui.msg("Number of minutes passed: ".. minute)
end
countdown = countdown - 1

if player:get_position() == coord.new(45,10) and exit_check then
ui.msg("Leaving already?")
exit_check = false
end
end
</source>

'''OnTick()''' is, by far, the most extensive trigger of the module engine hooks, allowing you not only to set up time-specific events but also position-specific ones. In the example above, both cases are used:

*A ''countdown'' variable starts at 600: whenever it reaches zero (as 60 game seconds have passed), ''countdown'' is reset, ''minute'' is incremented by one, and the game tells you how many minutes have passed.
*Whenever the player enters the same tile as the stairs (the stairs happen to be on (45,10)), the game sends a message, and then sets exit_check to false. Were this check not added, the message would display continuously for each turn that you stay in the tile (so it will keep displaying the message if you wait on the tile, for instance). However, this also means it will only display once, as there are no conditions in the code in which exit_check can be made true again.

Setting up too many events in the '''OnTick()''' hook may cause some game slow-down, but it usually takes a monstrous amount of code (or some very iterative processes) before there is even a noticeable effect.

===.OnKill()===
<source lang="lua">
local killCount = 0 --set up a kill counter

function blank.OnKill()
killCount = killCount + 1 --increment the kill counter

--display messages dependent on kills
if killCount == 1 then
ui.msg("You have killed 1 enemy.")
else ui.msg("You have killed " .. killCount .. " enemies.")
end
if killCount == 10 then
ui.msg("Wow, killing spree!")
end
end
</source>

'''OnKill()''' lets you trigger events when an enemy is killed by you specifically. There are a number of possibilities you may want to try (adding to berserk time, increasing health, spawning new enemies, etc): this example displays a simple message whenever you kill something, and gives you a metaphorical pat on the back for ten kills.

===.OnKillAll()===
<source lang="lua">
function blank.OnKillAll()
Level.summon("former",5)
ui.msg("They just keep coming!!")
end
</source>

'''OnKillAll()''' is like '''OnKill()''' but only triggers when everything on the map has died. This is how, for instance, [[Hell's Arena]] knows when to start the next wave of enemies (or when you're completely done). In this example, whenever you kill everything on the map, the game randomly spawns five former humans, essentially allowing this trigger to occur for as many times as the player wants to do so.

===.OnExit()===
<source lang="lua">
function blank.OnExit()
ui.msg_enter("Goodbye world!")
end
</source>

'''OnExit()''', just as with '''OnEnter()''', is limited in its uses when it comes to a single level. You can add some messages, maybe tidy up some variables for the mortem, but once the player is leaving there isn't much left with which to interact. (In this case, ui.msg_enter() is used in order to force a confirmation on the player: otherwise the message could very well be lost in the mortem bloodslide effect.)

==Review==

The following is a summation of all the lines of codes used to create the module.lua and main.lua scripts, with a few changes here and there to ensure that everything will run as intended (and a couple additions to make it more playable).

{{:Modding:Tutorial/Constructing a Map/Source}}

Source data: [http://dl.dropbox.com/u/54818507/blank.module.zip blank.module]