I am not asked questions very frequently, so I made most of these up in defensive anticipation. Some of the others are common questions which date back to the olden days. Most of these aren't even questions, really. Rather they are 'exclamatory frustrated outbursts'. "Frequently Asked Questions" was just a simpler title than "Frequently Exclaimed Frustrated Outbursts".

Interface Issues

• "I'm using Windows and I can't play Duke3D!"

Get the latest version of EDuke32. It's native to Windows so it should solve all of your problems. Well, not all of your problems, youuu messed up little human, you..

• "I'm using a laptop and I don't have a number keypad!"

There should be a "function" Fn key or some equivalent on your keyboard which allows you to access numerical keypad functions. Unfortunately for you, lacking a numerical keypad with this program is like missing a limb. You can still access all of the functions, but it will take a toll on your mapping efficiency.

• "I do have a number keypad but it isn't working!"

Try enabling/disabling the keypad with NumLock.

It has also come to my attention that some laptop manufacturers have been implementing 'pseudo' numerical keypads which do not use unique keyboard scancodes; In other words, they won't function with the map editor which renders them useless for our purposes. Why would they do this? Because they're morons, that's why. Apparently, some of them really have it out for us mappers and have eliminated the numerical keypad functionality entirely! In cases like these, the only options I can suggest are searching for keyboard drivers which add the numeric keypad functionality, or using an external USB keyboard with a functional numeric keypad.

• "Some of the keypresses aren't working for me!"

This is a problem associated with some newer keyboards. When you press a key, a scancode is sent to the program. If your keyboard uses unusual scancodes, then the map editor will not be receiving the correct ones, and thus will not be responding with the expected functions. I'm not sure if this can be fixed with Build, but at this point in time you should have already switched to Mapster32 anyway.

The solution is to ask around for a copy of mapster32_scancode.exe. I can send you one myself if you're polite and offer me food. This version of the program will dump your keyboard scancodes to the mapster32.log file as you press the keys, allowing you to suss out your specific keyboard scheme and compare it with the one displayed at the end of the mapster32.cfg file. Once you figure out which key should have which scancode, you can add a line to the end of the mapster32.cfg file that follows this format: remap = <your scancode>-<desired scancode> separating each instance by a comma if more than one redefinition is necessary (personally I had to remap 7 keys). For the sake of a full example, and just in case by some fluke coincidence your keyboard uses the same scancodes as mine, here's what I had to plug into the end of my mapster32.cfg file: remap = 1A-1B,1B-2B,90-0D,91-1A,92-28,94-29,DD-36. I have found that in the newest versions of Mapster32, my remapping is no longer necessary, which means that the program has probably been updated to accommodate an industry change in keyboard scancodes.

• "I'm using Mapster32 and autosave is bloody annoying!"

Yes. Yes it is. There are two ways to disable this: Apostrophe ( ' ) + A will toggle autosave, but this is only a temporary fix. To permanently disable it, find this line in your mapster32.cfg file: autosavesec = <value> and change the value to 0. It was actually my nagging one of the developers that resulted in the existence of this configuration option, after which I became quite a happy person.




Sprite Issues

• "What's the difference between pink and blue sprites?"

Pink sprites (or walls) means that they are blocked. The player cannot pass through a blocked object.

• "I can't select a sprite!"

If several sprites are overlapping each other in 2D mode, you will not see the selected sprite flickering while highlighted (even though it is). You can use the Left Mouse Button to drag it away from the other sprites. If several sprites are overlapping each other in 3D mode, some of them may not be accessible from certain viewing angles. If you want to modify the attributes of a sprite that is not accessible, try approaching it from a different viewing angle. If that doesn't work, you can temporarily adjust the elevation of the "foremost" sprite with PGUP/PGDN in order to access the sprite(s) hidden "behind" it.

• "My sprite is only visible from one side!"

Point the mouse cursor at it and press 1 to toggle it back to two-sided.

• "I moved some sectors and then all of the floor-aligned sprites dropped to the ground!"

This seems to be a rare issue when moving sectors with Right Shift. This is especially aggravating with one-sided floor-aligned sprites which only display the bottom side. Since it basically grafts itself to the floor, there is simply no way to access the sprite again within Build (thankfully the sprite's values can be edited directly in Mapster32 using F8). The only workaround in Build is to delete and replace the sprite. A solution to this problem is to use Right Alt to move sectors instead.

• "How do I place active tripmines?"

Place a TRIPBOMB (#2566) on a wall. It is oversized by default, but the size will have absolutely no effect in-game (you can shrink it down if it bothers you). TRIPBOMBSPRITE (#27) is just tripbomb ammo.




Wall Issues

• "I can't select a line in 2D mode!"

If a wall is too long, you will no longer be able to highlight it with the mouse cursor, which also means you won't be able to insert any new vertices onto it. Mapster32 will change the colour of these lines after they exceed the maximum length, as a visual warning. The only way to insert new vertices on a 'long' wall would be to temporarily resize it until it's short enough. While I am on the subject, you may also notice that occasionally it is difficult to highlight a wall because the mouse cursor keeps focusing on a nearby sprite instead. You can alleviate this issue by temporarily disabling the grid (press the G key until the grid disappears).

• "My masked wall is only visible from one side!"

Point the mouse cursor at it and press M until it toggles back to two-sided.

• "I can't resize a wall with the Keypad 2/4/6/8 keys!"

This happens in Build when the top and bottom halves of a wall are set as separately editable (using the 2 key). The bottom half of the wall won't respond to anything until you've pressed 2 on the top half to make both halves share attributes. If this isn't the case, try enabling/disabling the keypad with NumLock.

• "My door frame moves up and down with my door!"

Press O (the letter O, not zero) on each side of the door frame. This will orientate the walls to the floor so they won't move up and down with the ceiling. In the case of a split door, the frame texture will always move with the door, since the door moves both the floor and ceiling. The workaround is to create thin 'door frame' sectors attached to the door (make sure they don't share the door sector Lo-Tag).

• "How do I stop my elevator's walls from moving up and down with the elevator? I've already tried using the O key!"

If you are making an elevator with the sector tag [0,18] or [0,19], this will always happen regardless of orientation. The O key aligns walls to either the floor or the ceiling, and since those types of elevators move both the floor and the ceiling, the walls will always move up and down with the elevator. The workaround is to create your elevator sector inside of another sector, creating a thin border (make sure the bordering sector has no Lo-Tag). That way, the bordering sector's walls will stay still while the elevator sector moves up and down.




Sector Issues

• "My sectors keep disappearing in 3D mode!"

This is most likely happening because you surrounded a red-lined sector with another red-lined sector. This will produce rendering issues of the sector within. This can also happen if you have created a larger bounding sector than the engine can handle. Another possibility (if you are using Build) is that you may have collapsed a red-lined sector's vertices in order to delete it. This will corrupt your map file, causing many rendering issues. Fortunately, Mapster32 prevents you from doing this with an "invalid operation" message. Remember, it is okay to overlap vertices from red-lined sectors to delete them, so long as there are always more than two vertices left.

• "It keeps saying 'Can't make a sector out there' when I try to use Alt + S!"

You probably constructed the sectors in reverse order by surrounding a white-lined sector with another white-lined sector. You must always create sectors starting from the outside and working inwards, not the other way around. Another possible problem is that the white-lined sector is too large, which means you can't highlight the walls. Try making it smaller before using the keys. Once you've constructed the sectors properly, make sure that the mouse cursor is inside the "inner loop", and that it is highlighting an interior wall before you press Alt + S.

• "I'm having problems deleting and copying sectors!"

There are some bugs related to deleting or copying sectors, so it is recommended that you save your work beforehand.

If you are deleting a sector, first you should delete all of the sprites and tags within it. Now, there are actually a few different methods to delete a sector. The simplest and most recommended method is to highlight a wall inside the sector and use Right Ctrl + Delete. However, if you are trying to get rid of a nested sector (valid player space), and don't want to delete the adjacent sector(s), then you have two options: 1) Use the sector joining function (J) to join it with an adjacent sector (make sure the sectors are adjacent, i.e. sharing a line!); 2) Use Right Ctrl + Delete, then overlap all of its vertices to fully collapse and delete it (make sure the walls are white before doing this!).

If you are copying a sector, remember that the copy will have white walls when you paste it. If you want the copy to have red walls, first create a shell for the copied sector to fit into. This shell must have all of the same exterior vertices as the copy will have, so that the two sets of one-sided walls will be able to merge into two-sided walls. Place the copy inside the shell and the walls will turn red. With this knowledge, it becomes apparent that copying complex objects can be immensely simplified by creating the object(s) inside a sector of very few vertices (i.e. a square, or even a triangle to conserve walls), and then dropping a copy into a shell sector.

Copying sectors between maps is done by highlighting the sectors, then loading the map which you want to copy them into. The copied unit will appear in exactly the same position it was in prior to loading the new map. However, there occasionally seems to be a glitch with this feature: After loading the map, the sprites within the copy will not move until you deselect the whole unit, then highlight it again. Due to the possibility of this glitch, it is best practice to take the precautionary step of making sure that the area the duplicate will appear in is an empty one. Otherwise it will overlap with other sectors after loading the map and things will generally begin interfering with each other. Note that it is not possible to copy sectors into a brand new map. The map must already exist first (this limitation seems to have been eliminated in Mapster32).

Keep in mind that there is a limit to how much you can copy, determined by the standard sector/wall/sprite limits (the original Build limits can be exceeded in Mapster32). When copying objects, the combined amount of sectors/walls/sprites in both the original and duplicated objects must be taken into account in order to avoid exceeding these limits (even if you are copying between maps). In Build, surpassing these limits could potentially corrupt the program memory. This issue has been fixed in Mapster32. So, unless a level is quite small, you wouldn't be able to copy its entire contents to a different map file. In such a case, you would simply copy the map in segments.

Sometimes after using Insert to copy objects, the copies will refuse to respond to mouse clicking, and so cannot be moved. To fix this, temporarily switch to 3D mode and then back to 2D mode. The copied objects will remain highlighted and will now move freely. This issue seems to have been fixed in Mapster32.

• "I copied a sector with an effect built into it, but the copy doesn't work!"

If the copy has been rotated with , / . (aka < / >), the sprites within the copy will have been rotated as well. Any copied effects which depend on sprite angles will stop functioning correctly until the sprite angles are fixed. This will also affect a sector which is just highlighted with Right Alt and rotated.




Parallaxing Issues

• "I've parallaxed the sky and now Duke dies when he enters the sector!"

That's because you've parallaxed either BIGORBIT1 (#84) or MOONSKY1 (#80), which are lethal space textures. You can fix this problem by giving the ceiling a palette value greater than 0 (the floor palette has no effect, even if the texture is only parallaxed on the floor!). A palette value of 3 works great because it doesn't actually affect the colour.

• "My parallaxed sky looks messed up!"

Okay, there is a lot to explain about this. The reason it looks mingled is because you're using a 'parallaxed texture set' in your map. A parallaxed texture set combines a sequence of textures and displays them as one complete image. There are only three parallaxed texture sets in the art files: MOONSKY1 (#80) which combines a sequence of four textures from #80-83, BIGORBIT1 (#84) which combines a sequence of five textures from #84-88, and LA (#89) which combines a sequence of five textures from #89-93.

You only need to paste the first texture of a set and the rest is displayed automatically after saving and reloading the map or running the game. A set will not display its sequence until after you have saved and reloaded the map! Upon reloading, all parallaxed textures in the map are overridden by the set and will now also consider themselves a 'set', and display a sequence of textures accordingly. This is why your other parallaxed skies are displaying a bunch of seemingly random unrelated textures. To fix this, either get rid of the set, or stick with it and paste it over every parallaxed texture in the map (use the Alt + C function to make a quick job of this). Remember that the changes will not take effect until after you've saved and reloaded the map again.

Of course, a texture set will only be activated if the initial texture is parallaxed, but I can't imagine why you would be using a non-parallaxed sky texture. Parallaxed floors by themselves are not programmed to work with texture sets, and hence will not interfere with any other parallaxed textures. They require a ceiling using the same texture set in order to be overridden and display the proper sequence.

It is perfectly fine to use individual parallaxed textures of all varieties in your map, even a "named" one, provided it's not the initial texture of a 'set'. You can even get away with using a non-initial texture from a set without upsetting the other parallaxed textures in the map, since only the initial one is coded to display the sequence. The non-initial space textures will also be neutral since only the initial one is coded to be lethal. However, you cannot get away with using two different texture sets even if they both display the same number of textures (namely BIGORBIT1 and LA), because the textures display their sets differently. Whichever one takes priority will tear the other one apart (they are very territorial creatures).

Phew! Finally, remember that you are not restricted to using textures designed for parallaxing, you can parallax any texture!

If you are are still having problems, and are not using any parallaxed texture sets, then it could be possible that some of your parallaxed textures have different attributes from the rest (inconsistent shading/visibility values are especially noticeable). In this case you will either have to disable parallaxing in each sector until you find the culprit(s), or copy and paste a known 'good' texture over the others.




Texture Issues

• "My textures look messed up!"

When selecting textures for floors, ceilings, walls, or floor-aligned sprites, only textures with dimensions which are powers of 2 will look proper. For example, 128x256 would look normal, but 93x256 would not. This doesn't necessarily mean that you can't use these textures, but generally they will look meshed if used on horizontal surfaces (floors/ceilings/floor-aligned sprites), or broken at odd intervals if used on vertical surfaces (walls). This doesn't affect face-aligned or wall-aligned sprites. Many (but not all) of these display issues seem to have been fixed in EDuke32.

• "My textures keep going out of alignment!"

This is normal. When you move a vertex, the attached walls will readjust their texture repeats. When you are moving sectors, only floor/ceiling textures with relative alignment enabled will maintain their alignment. Other floors/ceilings do not: The textures remain stationary while the sectors move. You can see this visually while moving sectors with Mapster32's 2D texture mode enabled (Backspace key). To ensure that floor and ceiling textures maintain their panning alignment, always move the sectors by an even number of grid spaces on grid resolution 1, or twice that amount per grid resolution. Don't even bother trying to perfect texture alignment until after you're finished the structure of a map. Build is especially notorious for screwing with textures, even if you change something completely unrelated.

• "My textures are somehow giving themselves tag values!"

This is happening because you are copying and pasting textures with tag values. This can easily cause effects to stop functioning until you manually restore the correct tag values. Submergible Water is the prime example of this, because most people simply copy and paste the water texture between sectors, potentially overwriting tags in the process. Try to develop the habit of using Apostrophe ( ' ) + Enter when pasting textures. This ensures that only the picnum (texture) is pasted. Similarly, you can use Shift + Enter to paste only the shade/palette of a copied object.

• "What the heck is HOM?"

An acronym that stands for "Hall Of Mirrors". HOM is when a texture "sticks" to the screen and it is a really ugly graphical glitch. There are a few ways HOM can happen: 1) A texture that has been assigned to a solid object (floor, ceiling, or non-masked wall) in a map does not exist in any of the ART files (which leaves an open window into invalid player space), 2) A mirror was not constructed properly, particularly it may be missing a 'behind-the-mirror' sector, 3) A security viewscreen is attempting to display a mirror while not in active use (i.e. being viewed passively from a distance), 4) There is more than one mirror in a map and (a) The player is able to see a mirror other than the one closest to them, or (b) The mirrors are built close enough to one another so that their 'behind-the-mirror' sectors interfere with each other. Point 4 is explained in further detail below.

Generally speaking, there is a viewing distance 'threshold' between mirrors: Whichever mirror is closest to a player's view (not physical position) will function correctly. Any other mirrors (including those across invalid player space) will be guaranteed (or at least very prone) to display the HOM effect. Never allow a player to see more than one mirror simultaneously, including mirrors reflecting each other. This issue is per-player, meaning that multiple player views will not conflict with each other. Mirrors within close proximity to one another tend to be especially unstable. It seems as though the sectors being displayed in the mirrors can interfere with each other if they overlap.

Assuming the mirrors themselves are constructed properly, there are two basic rules that must then be followed to prevent HOM issues when a map contains more than one mirror. Rule 1: The player must never be able to cross the viewing distance threshold between mirrors while still being able to see a mirror beyond that threshold. Rule 2: The mirrors must not be within close enough proximity to one another so that the sectors they display can possibly overlap and interfere with each other.

• "My floor/ceiling seems blurry, kind of like the HOM glitch."

In Mapster32, the T key cycles through three different "Translucent Masked" floor/ceiling cstat flags, which are unused remnants of the engine. It is easy to accidentally assign these flags by pressing the T key by itself, when you intended to press the Apostrophe ( ' ) + T key combination used to assign a sector Lo-Tag. For this reason, sectors with a Lo-Tag are the most likely places to encounter this mistake. This happened to me in multiple places around TUTORIAL.MAP, before I even knew these flags existed, let alone that they could be assigned with a keypress.




Lighting Issues

• "Why do lighting effects seem to work on some objects but not others?"

Are you ready for this? Because this is stupid complicated.

Floors, walls, and ceilings are all considered separate from each other, and will not share their shade or palette values unless a lighting effect forces them to do so. However, sprites tend to share the lighting attributes of either the floor or ceiling. Floor shade affects all sprites within the sector (except wall-aligned sprites), unless the ceiling of the sector is parallaxed, in which case sprites within the sector will ignore the floor's shade and take on the ceiling's shade instead (except wall-aligned sprites). Wall-aligned sprites seem to be the odd one out here: They will only respond to changes in shade when certain lighting effects force it on them. The floor will always have priority on a sprite's palette. The floor palette will affect all sprites within the sector (including wall-aligned sprites).

To the best of my knowledge, lighting effects simply adjust the shade and/or palette of a sector's objects, after which the sprites follow the conventions described above. As always with this engine, there are exceptions. A description of each individual type of lighting effect follows:

Switch-Activated Light (SE 12): The shade and palette of the sectors will show when the light is off. The sector palette will only show if the light is initially off, and will be disabled after the light effect has been toggled. The shade and palette of the SE determines the appearance of the sectors when the light is on. Turning the light on forces everything in the sector to match the SE palette, but only the floor and sprites will match the SE shade, while the walls and ceiling are adjusted relative to their shades in the map. Turning the light off forces everything in the sector except the ceiling to match the floor's shade, while the ceiling reverts to the shade it has in the map. Essentially this means that walls will be forced to match the floor shade after toggling the light off once, while the ceiling will always be adjusted relative to its shade in the map. This type of lighting effect does affect the shade of wall-aligned sprites.

Open/Close Door Room Lights (SE 8/SE 9): The shade of the sectors will show when the light is off. The palette of the sectors will be permanent. The shade of the SE determines the appearance of the sectors when the light is on. The shade of the floor, walls, and ceiling in the sector are adjusted relative to their individual shades in the map, and by association the sprites will always match the floor's shade. This type of lighting effect does not affect the shade of wall-aligned sprites.

Flickering Lights (SE 4): The "Random" lighting effects swap the usage of sector and SE palettes. The palette of the sector will show when the light is on, and the palette of the SE determines the appearance of the sectors when the light is off. The shade of the floor determines the shade of everything except the walls when the light is off. The darkest wall determines the shade of every wall in the sector when the light is off. The floor and walls should be set to the same shade to avoid lighting issues. The walls will be forced to match the palette of the floor when the light is on, but the ceiling will use the palette it has in the map. This type of lighting effect does affect the shade of wall-aligned sprites.

Flickering Lights when Shot (SE 3): The "Random" lighting effects swap the usage of sector and SE palettes. The palette of the sector will show when the light is on, and the palette of the SE determines the appearance of the sectors when the light is off. The shade of the floor determines the shade of the entire sector when the light is off. The walls and ceiling will not automatically match the floor's palette, they must be manually set. The wall palettes will be permanent. This type of lighting effect does not affect the shade of wall-aligned sprites.

Pulsating (Cycler) Lights: The shade of the sectors determine the light's darkest point. The palette of the sectors will be permanent. The shade of the Cycler determines the light's brightest point. The shade of the floor determines the shade of the entire sector when the light is off. The walls and ceiling will not automatically match the floor's palette, they must be manually set. This type of lighting effect does not affect the shade of wall-aligned sprites.




Gameplay Issues

• "The game crashes when I run my level!"

Did you place the player start position within valid player space? In 3D mode, move to the exact position, angle, and height you want to start at, then switch to 2D mode and hit Scroll Lock. A brown arrow will appear indicating the player start position (this arrow has changed colour in Mapster32). If this isn't the problem, check the bottom of this page for a list of game run-time errors.

• "My start position keeps changing!"

Build has an annoying tendency to do this. When you load a level, the very first time you switch to 3D mode it will save the start position to that location. To solve this problem, always switch to 3D mode immediately after loading any level. This ensures that the start position will remain in place until you quit. This seems to have been fixed in Mapster32.

• "I can't press some of the switches in my map!"

I used to think that the cause of this problem was trying to press through other sectors, but after a bit of testing I realized the real problem is trying to press through other sprites, particularly the 10 intangible special sprites. Despite being ostensibly intangible, these sprites actually do interfere with the player's ability to press switches. It seems that when the player attempts to press a switch, any intangible sprites in between steal the focus of the player's action, and the switch is ignored. This problem is exacerbated when the switch is surrounded by a cluster of these sprites. If you are still able to press the switch from certain angles, then this is most definitely the problem. This can be fixed by shrinking the special sprites to a much smaller size and generally keeping them clear of the proximal area of any switches.

Unfortunately, if this did not solve the problem in your case, then aside from trivial errors such as incorrect tags or lack thereof, it is probably an engine quirk and nothing can be done about it. In these situations it is best to either redesign your switch layout until it works, or use switches which can be triggered by the player's gunfire (bullets only): DIPSWITCH (#162), DIPSWITCH2 (#164), DIPSWITCH3 (#168), and HANDSWITCH (#1111) (of course TARGET (#4359) and DUCK (#4361) also work, but they are rarely-used novelties).

• "I can't press the Nuke Button!"

If a two-sided wall is blocked and has a non-zero overtile value (i.e. any masked texture except the default brown brick texture) assigned to it, the player will not be able to press 'through' the wall to activate a Nuke Button on the other side (even if the wall is unmasked). This also occurs if the two-sided wall is only blocked on one side (the side that the player is trying to press through). In this scenario, all that is necessary is to disable the overtile, either by setting the value to 0 manually (with the F8 editing menu in Mapster32), or by temporarily masking the wall, setting the masked texture to 0 (the default brown brick texture), then unmasking the wall again to hide it. Alternatively, you could disable the wall's blocking flag instead and leave the overtile active. The wall's blocking flag does not interfere on its own, nor does the overtile: It is only when the two are used in tandem that the issue arises. There are many cases in the original levels where the Nuke Button is encased in glass and cannot be activated until the glass is smashed, so this "feature" was certainly intentional.

• "My switch(es) won't work with <effect>!"

When constructing effects that use switches, try to avoid using the Combination Switches: DIPSWITCH (#162), TECHSWITCH (#166), or ALIENSWITCH (#1142) unless the tutorial specifically requests that you use them. If this is not the problem, then you must have made a mistake while creating the effect. It's a very common (and annoying) problem when an effect won't work, and you discover after hours of problems that you accidentally swapped tag values or made some other simple error.

• "My Star Trek door plays the opening sound twice!"

This is a bug which cannot be fixed. In some cases, the volume can be balanced by assigning the sound number to both the Hi-Tag and Lo-Tag of the MusicAndSFX sprite (don't ask me why). Otherwise, you could just make your Star Trek Doors silent. Check the "References - Sector/Effector Tags" section for more information about this.

• "My subway shoots rockets at me!"

If a subway's floor is parallaxed, it will fire rockets at the player. To disable this, give the floor of the subway car a palette value greater than 0 (3 works great because it doesn't affect the texture's colour). Have a look at the circling ship that fires rockets at you in E2L1.MAP: "Spaceport" for a better idea of how this works. It is a common misconception that the ceiling of the subway determines whether or not it will fire rockets, but it is a lie, a dirty filthy lie that has perpetuated through the ages. It was probably written somewhere in the official documents, which would explain why it still echoes to this day.

• "I die on the teleporter for no reason!"

Ah, but there are reasons. This could mean one of two things: 1) Your teleporter was built incorrectly, or 2) You have been telefragged. Telefragging occurs when someone uses a Standard/One-Way Teleporter to teleport to a sector which you are currently within, so don't stay inside a teleporter for long!

• "I can't destroy sprites with the freezer gun!"

The freezethrower projectile has some hit-detection problems with floor-aligned sprites, and objects which are close to the ground in general. I also want to randomly mention here, since I can't find any more suitable place for it, that this weapon is called the "freezer" in the game manual, but the "freezethrower" in the game itself. I found "freezer" slightly more ambiguous, so I went with "freezethrower".




Customization Issues

Note: Character limits are provided here as given in the code. However, character limits are virtually always short of what they claim to be. I have comprehensively tested all of them myself to be certain, and found only one exception (the par time character limit). I have listed all of the actual character limits either next to the given values, or within the descriptions following code excerpts. This note applies to character limits only, all other limits have been tested and are accurate as given.

• "I want to extract/create a GRP file! How do I do this?"

There is a pair of programs that come with the game called KGROUP and KEXTRACT. These can be used to handle the GRP file format. Make sure the programs and the GRP file are in the game's root directory. Run a command prompt, and switch to the game directory by typing CD C:\DUKE3D (replace with the location of your game directory if it's in a different place). The usage for either program is as follows: <program> <group file> <file(s)>. <program> can be either KGROUP or KEXTRACT, depending on whether you want to create a group file or extract the contents from a group file. <group file> is the filename of the group file you want to create or extract (this field is literal, so be sure to include the .GRP extension in the filename). <file(s)> is/are the file(s) you want to either pack into the new group file or extract from an existing group file. You can use the wildcard character (*) as either the filename or file extension to process more than one file at a time. For example, KEXTRACT DUKE3D.GRP *.MAP would extract all of the maps from the DUKE3D.GRP file, and KEXTRACT DUKE3D.GRP *.* would extract the entire contents of the DUKE3D.GRP file. Note: Files within the game's root directory have precedence over files of the same name within DUKE3D.GRP (and case-sensitivity does not apply, although this may differ in alternative operating systems). If you find these programs inconvenient, incompatible, or would just prefer something with a graphical user interface, there are alternative programs for handling group files available online.

• "How do I change the display names of the textures in the map editor's texture list?"

There is a file called NAMES.H that comes with the original game and EDuke32 (it is not stored in DUKE3D.GRP however). Simply open it with a text editor and modify the names as you see fit.

• "What are these CON files I keep hearing about? How do I get them?"

CON files are Duke3D's CONtrol files (I prefer to think of them as CONfiguration files), which can be edited with any basic text editor. There are three CON files that come with the game: DEFS.CON, GAME.CON, and USER.CON. DEFS.CON is simply a list of texture, sound, and various other definitions used to link the game components. GAME.CON is the largest and most complex, housing a considerable chunk of the raw game code for enemies and objects (not all of them however, many are hard-coded). USER.CON is designed with the user in mind, and as such is easy to modify and full of fun code to play with. EDuke32 can also make use of an optional EDUKE.CON file that is created from scratch by the user.

All of the default CON files are packed inside the DUKE3D.GRP file, but the original game also had them stored in the C:\DUKE3D directory. If your CON files are missing, or if you wish to extract fresh copies for any reason, you can use the KEXTRACT program described previously in this page to extract the original copies from the DUKE3D.GRP file. Make sure the program and the GRP file are in the game's root directory. Run a command prompt, switch to the game directory by typing CD C:\DUKE3D (replace with the location of your game directory if it's in a different place), and type KEXTRACT DUKE3D.GRP *.CON. This will extract all of the CON files into the game's root directory. If you can't get this to work, there are also alternative programs (with graphical user interfaces) for handling group files available online.

Note: (From the header of GAME.CON and USER.CON) If you are playing a Multiplayer game (DukeMatch or Co-Operative) and you are using modified CON files, then each player must be using the exact same CON files, or the game will get out of sync and/or develop interesting problems.

• "How do I change the names of the skill settings?"

This just requires some extremely basic editing of the USER.CON file in the game's root directory. Open the USER.CON file with a text editor. If you scroll through it you will eventually see the list of skill titles, as shown below:

// Skill titles cannot excede 32 characters.

defineskillname 0 PIECE OF CAKE
defineskillname 1 LET'S ROCK
defineskillname 2 COME GET SOME
defineskillname 3 DAMN I'M GOOD

Not that you'll need it, but the format is as follows:

defineskillname <skill number> <skill title> // Note that skill number begins at 0

Simply change the skill titles to whatever you'd prefer. The actual skill title character limit is 30 characters in the original game, and 31 characters in EDuke32.

• "How do I modify the quotes used throughout the game?"

This just requires some basic editing of the USER.CON file in the game's root directory. Open the USER.CON file with a text editor. If you scroll through it you will eventually see the list of game quotes. The following is an excerpt:

// Maximum quote size is 64 characters.
// Maximum quotes is 192 slots.


definequote 0 AUTO AIMING
definequote 1 SHOW MAP: OFF
...
definequote 123 AMMO FOR EXPANDER
definequote 124 MAP HAS A DIFFERENT NUMBER OF PLAYERS

The format is as follows:

definequote <quote number> <quote> // Note that quote number begins at 0

Simply replace the quotes as you see fit. Note that some quotes are reserved and advise you to "<Please Leave Blank>". The original game has a quote limit of 192 slots (0-191), with a character limit of 64 (62) characters per slot. EDuke32 has increased the quote limit to 16384 slots (0-16383), with a character limit of 127 (126) characters per slot, just in case you want the player to read an essay while playing.

• "How do I make custom episodes? / How do I set the level par times?"

I combined these two questions since answering the first also answers the second. All that is required is some basic editing of the USER.CON file in the game's root directory. Open USER.CON with a text editor. If you scan through it you will eventually see a list of the episodes and levels. The following is the list of episodes (referred to as "volumes" in the code):

// Volume titles cannot excede 32 characters.

definevolumename 0 L.A. MELTDOWN
definevolumename 1 LUNAR APOCALYPSE
definevolumename 2 SHRAPNEL CITY
definevolumename 3 THE BIRTH

The format is as follows:

definevolumename <volume number> <volume name> // Note that volume number begins at 0

In the original game, the only way to create a custom episode was to overwrite an original one. However, in EDuke32, you can also create new custom episodes by adding more to the list. Currently the maximum is 3 additional episodes, bringing the total to 7 episodes. Note that replacing Episode 4 ("The Birth") would require further modifications to disable the introductory cinematic, so it would be easier to replace any of the first 3 original episodes instead. The actual volume title character limit is 30 characters in the original game, and 31 characters in EDuke32.

If you continue to scan through the code, you will see the list of levels just beneath the list of episodes. The following is an excerpt (and I just noticed they misspelled "exceed"):

// Level file names cannot excede 128 characters.
// Level par cannot excede 5 characters (min:sec)
// Level titles cannot excede 32 characters.

definelevelname 0 0 E1L1.map 01:45 00:53 HOLLYWOOD HOLOCAUST
definelevelname 0 1 E1L2.map 05:10 03:21 RED LIGHT DISTRICT
...
definelevelname 3 9 E4L10.map 10:50 05:25 THE QUEEN
definelevelname 3 10 E4L11.map 04:20 02:10 AREA 51

The format is as follows:

definelevelname <volume number> <level number> <map file> <par time> <3D Realms' time> <level name> // Note that volume and level numbers begin at 0

Simply fill in the appropriate field values, then name your maps accordingly and place them in the game's root directory. In the original game, the maximum number of levels per episode was 11. In EDuke32, the maximum number of levels per episode has been increased to 32. The level filename character limit is actually 127 characters in the original game, and has been increased to 256 (255) characters in EDuke32. The par time character limit (5 characters in min:sec format, including the colon) is the only character limit that is accurate as given in the code! The actual level title character limit is 30 characters in the original game, and 31 characters in EDuke32.

• "How do I add custom music and sound effects?"

Rename the custom files to match the names of the sound or music files you are replacing, then just dump them straight into the game's root directory. When the game boots, it will search for any replacement sound/music files in its root directory, and it will use those instead. It is also possible to add completely new sound and music by editing the USER.CON and DEFS.CON files. Acceptable file formats for sound effects are VOC and WAV, and for music is MID. EDuke32 also supports the OGG (Ogg Vorbis) format for sound effects and music. It seems that OGG files are predominant over MID files of the same name if both are present in the game's root directory.

The ancient method of adding music was to rename the custom MIDI file to DETHTOLL.MID, since user maps are loaded as E1L8.MAP, and DETHTOLL.MID is the default MIDI file associated with that map. Although this method does work with EDuke32 (including the alternative use of DETHTOLL.OGG), it has been made semi-obsolete since EDuke32 autoplays MID/OGG files that have the same name as a loaded user map. The only exception is if the user map has the same name as an official map in the E#L# format. The original game considers a map in E#L# format to be a user map regardless of the filename, and so loads it as E1L8.MAP and plays DETHTOLL.MID accordingly. However, EDuke32 considers it to be an official map and plays the music file defined for that map in USER.CON.

Concerning the music files, here is an excerpt from USER.CON:

// Music will not play if the .MID file excedes 72000 bytes.

// Music for title and end
music 0 GRABBAG.MID BRIEFING.MID

// Music for the individual levels
music 1 stalker.mid dethtoll.mid streets.mid watrwld1.mid snake1.mid
thecall.mid ahgeez.mid dethtoll.mid streets.mid watrwld1.mid snake1.mid

Despite the rather clunky presentation, the format should be simple enough to understand:

music <volume number> <music file(s)> // Note that volume number begins at 0

Episodes are referred to as "volumes" in the code. A volume number of 0 followed by two music filenames will define the title and "end" music (BRIEFING.MID actually appears in the introductory cinema scene of "The Birth" episode, I am not sure why it is referred to as "end" music in the code). Beyond 0, volume numbers refer to actual volumes, followed by the music filenames for the levels in sequential order as they appear in the episode. If using EDuke32, note that the increased episode and level limits apply (7 episodes, 32 levels per episode), and that the 72,000 byte limit on MIDI files does not apply. There doesn't appear to be a character limit on music filenames in the code, but shorter names are preferable regardless, just to keep things simple and avoid issues.

Concerning the sound files, here is an excerpt of a sound effect definition split between DEFS.CON and USER.CON:

define DUKE_DEAD 41 // DEFS.CON

definesound DUKE_DEAD DMDEATH.VOC -64 64 255 4 0 // USER.CON

The format for each CON file (respectively) is as follows:

define <definition name> <sound number> // Note that sound number begins at 0

definesound <definition name> <sound file> <random pitch variation range (minimum)> <random pitch variation range (maximum)> <priority> <bitfield value> <volume adjustment>

All of these values are documented in the "References - Sound List" section, as well as a complete listing of the sound effects in the game, and more detailed information. The sound filename character limit is 13 (12) characters in the original game, and has been increased to 256 (255) characters in EDuke32.

• "Wow! What other cool things can be done with the CON files?!"

Lots. In USER.CON alone, you can modify the enemy strengths, ammo capacities, weapon damage amounts, gravity, etc, none of which I am going to elaborate on here. With the examples given above, you will have gained more than enough knowledge to modify anything in the USER.CON and DEFS.CON files. A book could be written on GAME.CON and the new coding possibilities introduced in EDuke32, so I'm not getting into that. Rest assured, it's not too difficult if you're willing to devote the time to learning it, especially if you have any prior programming experience.

• "How do I add custom textures or modify the existing ones?"

Unfortunately I can't offer much help on this subject. I have only minimal experience modifying the ART files, and the program I used (called EDITART, which comes with the official Duke Nukem 3D: Atomic Edition CD) is extremely archaic and counter-intuitive. The modern method of adding custom textures involves using EDuke32 definition files with their plethora of new and improved features. Although the syntax and overall process is not complicated, I simply have not had the time to familiarize myself with any of these new methods, let alone document them. There are also programs available online to view/create/extract both the ART format used for the textures in the game, and the ANM format used for the cinema scenes in the game.

• "How do I make a DukeTag level?"

All of the information you need is provided in the DUKETAG.TXT and BUILDTAG.TXT files that come with the official Duke Nukem 3D: Atomic Edition CD. There is also a fully-functional example of DukeTag in E4L10.MAP: "The Queen".




Run-time Errors

If you receive these errors when you try to play your maps, here are the explanations and solutions:

• "Map <filename> not found!"

The next specified map to be loaded does not exist. The most common specific example of this run-time error is "Map E1L9.MAP not found!". This happens because the game loads user maps as E1L8.MAP: "User Map". When the level is finished, the game will search for E1L9.MAP and quit if it doesn't find it.

• "Too many sprites spawned."

This error occurs when the sprite limit is exceeded (this limit has been increased in EDuke32/Mapster32). This can happen during gameplay by destroying multiple sprites at once, causing an overload of gibs/debris to spawn and crash the game. If you get this error often, reduce the number of sprites in your map.

• "Too many player sprites (max 16.)"

This means you have placed too many APLAYER sprites for either DukeMatch or Co-Operative mode. Technically speaking, the maximum for each is actually 15. The default start position counts as the remaining start point in either case, and it should not be classified as a "player sprite". Placing more than 7 Co-Operative start points is useless, but DukeMatch start points are randomized after the initial spawn, so there is valid reason to place more than 7.

• "Found lonely Sector Effector (lotag 0) at (<co-ordinates>)"

This means there is a SectorEffector in your map which has no tag values. Either delete it, or give it tag values.

• "Could not find any locators for SE# 6 and 14 with a hitag of <Hi-Tag>."

A Subway Vehicle requires Locators to be present in its track sector. Place and tag the necessary Locators.

• "Subway found no zero'd sectors with locators at (<co-ordinates>)."

Technically, this means exactly what it says. Translated to English: The Subway (the vehicle's bounding sector, containing the SectorEffector) found no zero'd sectors with Locators (is not immediately surrounded by a functional track sector). There could be many different reasons for this error: The SectorEffector on the Subway Vehicle or Two-Way Train may not be in the vehicle's bounding sector; The vehicle's nested sectors may be interfering with the vehicle's bounding sector (the bounding sector must be a single sector containing all nested sectors and it must not be split); The Locators might be tagged incorrectly; The vehicle may not be in the track sector; The track sector may have tag values when it shouldn't; The track sector might be split into multiple sectors; The Subway Vehicle might not be tagged accordingly, etc. As you can see, there are a large number of potential causes for this issue. Check the "Advanced FX" tutorials and make sure you've done everything correctly.

• "Too many moving sectors at (<co-ordinates>)."

There are too many moving sector effects in the map. Any effect which has even the potential to physically move (or rotate) its sector can trigger this error (this means that an overabundance of stationary Two-Way Trains or Sliding Doors can also trigger it). Floor and/or ceiling movement is not taken into account, since neither actually moves the sector. In my experience, it requires quite a large amount of moving sectors to trigger this error.

• "Too many cycling sectors."

There are too many Cycler sprites in the map. The maximum is 256 in the original game, and 1024 in EDuke32.

• "Too many mirrors (64 max.)"

There are too many mirrors in the map. The maximum is 64 in both the original game and in EDuke32. Note that only functional mirrors with a 'solid' one-sided masked wall and a 'behind-the-mirror' sector will be counted towards the limit.

• "Too many switches (64 max)."

I am not sure what this is talking about. I saw this error in the source code, but have no recollection of ever experiencing it myself. To my knowledge there is no switch limit at all, let alone a measly 64 maximum. I tested this by placing more than 64 switches with unique Lo-Tags in a map, and did not encounter the error. I then tested linking more than 64 switches with identical Lo-Tags to a single door, and still did not encounter the error. I repeated both of these tests using the specialized types of switches and still nothing. After this I decided that the code is either not referenced in the game, or it only applies to a very specific case which I did not feel like testing thoroughly enough to find.

• "Too many 'anim' walls (max 512.)"

This error is caused by too many 'animated' textures being present in the map. Which textures are considered 'animated' differ between masked walls and solid (non-masked) walls. Check the "References - Compatibility Listings" section for the complete list. The maximum combined amount of animated textures is 512, but oddly this number seems to drop to 511 when including solid (non-masked) wall textures. Each individual animated texture counts towards the limit (meaning that a masked two-sided wall would be considered two separate textures), and masked wall textures count whether they are visible or not.

This error could easily happen by accident, due to some quirks of the map editor. For example, you may have masked one wall as a spinning fan texture, and then created some completely separate sectors which the map editor decided (without warning) should also have masked spinning fan textures. You might not even notice, because the walls aren't actually set as being masked, but the animated texture is still attributed to those walls. Try masking some random walls around your map and you may discover that they are using animated textures.

• "Timed out."

This just means that a network game has gone out of sync and quit.

• "Don't screw with my name."

Apparently Ken Silverman added this to the Build engine code to prevent people from tampering with his name in the executable file. Having never heard of this message for almost two decades, imagine my surprise when I received this message after crashing the editor (due to using picnums that were out of range). I honestly thought for a few moments that my computer was trying to communicate with me.