Using ZIPs as WAD replacement - Revision history

Corbin: Cleaned up slightly.

2019-11-26T06:05:36Z

Cleaned up slightly.

Corbin: Updated article with more verbosity

2019-06-14T05:47:43Z

Updated article with more verbosity

Show changes

Corbin at 18:17, 27 December 2017

2017-12-27T18:17:37Z

Corbin at 17:49, 27 December 2017

2017-12-27T17:49:44Z

Corbin at 22:18, 15 December 2017

2017-12-15T22:18:44Z

Corbin at 22:14, 15 December 2017

2017-12-15T22:14:57Z

Corbin: Added EPK

2017-12-15T22:13:23Z

Added EPK

Corbin at 01:55, 8 July 2017

2017-07-08T01:55:26Z

Corbin: added two new namespaces exclusive to 3DGE (AFAIK)

2017-01-16T07:08:33Z

added two new namespaces exclusive to 3DGE (AFAIK)

Corbin: lol, changed SNDINFO from ZDoom -> SOUNDS.DDF equivalent

2017-01-15T20:11:38Z

lol, changed SNDINFO from ZDoom -> SOUNDS.DDF equivalent

@@ Line 1: / Line 1: @@
 {{DoomWiki|PK3}}<!-- NOTE: Only v2.1.0 RC-1 and DRDTeam Builds are able to read compressed archives!  -->[[3DGE|EDGE]] allows using several compressed [[archive format]]s instead of the traditional [[WAD]]s. Most notably:
 ;[[EPK]]
-:EDGE uses a modified ZIP container named '''EPK''' ('''E'''dge '''P'''a'''K'''), which is the recommended extension for EDGE-specific mods. The main data-file for EDGE now uses this container format ('''edge.epk'''). It is a basically a ZIP/PK3 container renamed so other ports do not accidentally load EPK files.
+:EDGE uses a modified ZIP container named '''EPK''' ('''E'''dge '''P'''aC'''K'''), which is the recommended extension for EDGE-specific mods. The main data-file for EDGE now uses this container format ('''edge.epk'''). It is a basically a ZIP/PK3 container renamed so other ports do not accidentally load EPK files. Though this is preferred, any archive format EDGE loads will still assume that data is stored in the proper namespaces.
 ;{{wp|ZIP_(file_format)|ZIP}}
-:A .zip file used as the container for an EDGE mod is  usually given the '''.pk3 extension''', instead of .zip. While there is no technical differences, this helps avoid potential confusion from users thinking the mod should be extracted from it, and also prevents Windows from presenting it as a directory. EDGE supports several ZIP archiving methods: stored (no compression), shrunk, imploded, {{wp|DEFLATE|deflated}} (the most commonly used), {{wp|bzip2}} and {{wp|LZMA}} algorithms. Note that many ZIP utility only partially implement the ZIP standard and as a result their support is limited to stored and deflated files. This partial implementation also affects some [[editing tools]] which normally support the PK3 format, such as [[3DGE Builder|EDGE Builder]], Doom Builder 2, and [[Slumped]].
+:A .zip file used as the container for a source port mods are usually given the '''.pk3 extension''', instead of .zip. While there is no technical differences, this helps avoid potential confusion from users thinking the mod should be extracted from it, and also prevents Windows from presenting it as a directory. EDGE supports several ZIP archiving methods: stored (no compression), shrunk, imploded, {{wp|DEFLATE|deflated}} (the most commonly used), {{wp|bzip2}} and {{wp|LZMA}} algorithms. Note that many ZIP utility only partially implement the ZIP standard and as a result their support is limited to stored and deflated files. This partial implementation also affects some [[editing tools]] which normally support the PK3 format, such as [[3DGE Builder|EDGE Builder]], Doom Builder 2, and [[Slumped]]. EDGE employs PhysicsFS for archive handling.
 ;{{wp|7z}}
 :A .7z file used as the container for a EDGE mod is usually given the .pk7 extension, for similar reasons. This format offers much better compression ratio, however its reduced support, especially by modding utilities, make it less interesting overall. It also increases the memory footprint on the engine, so caution must be taken when choosing between a 7z and a PK3 format. A possibility would be to develop a mod as a PK3, then convert it to a PK7 once finished, to decrease the size of the archive to be distributed. However, keep in mind that decompression is quite slower than for zips, so loading times are increased.
 ;[http://quakewiki.org/wiki/.pak PAK]
-: A .PAK file is used as an alternative container for EDGE mods; it follows Quake's PAK convention strictly. This also works for Quake II PAKs, as well as .SIN packfiles. It is nearly functionally identical to the WAD container format.
+: A .PAK file is used as an alternative container for EDGE mods; it follows Quake's PAK convention strictly. This also works for Quake II PAKs, as well as .SIN packfiles. It is nearly functionally identical to the WAD container format. EDGE mods wishing to use a custom IWAD replacement as a container over .WADs should prefer .PAK files.
+:
 Compressed archives have many advantages over PWADs and PAKs, even for storing content for Doom:
 * Smaller file size due to compression
 * Greatly reduced memory usage during play
-* Proper use of directories instead of WAD namespaces
+* Proper use of directories instead of WAD namespaces (directories also shares the distinction of being referred to as namespaces)
 * You no longer need dedicated WAD management tools like XWE for manipulating your data.
 * More flexibility due to the use of full path names. Currently there is only limited support but it is planned to change everything that references lump names to support full paths.
 == How to ==
-You can embed WADs inside ZIPs. Any WAD file found in the root directory will be added to the lump directory as well. This allows loading many of the ZIPs distributed through /idgames without the need to extract them. If several wads are included in an archive, they will be loaded in alphabetical order.
+You can embed WADs inside the top level root of an archive. Any WAD file found in the root directory will be added to the lump directory as well. This allows loading many of the ZIPs distributed through /idgames without the need to extract them. If several wads are included in an archive, they will be loaded in alphabetical order. If maps wish to stay in the WAD format, they need to be given the explicit lump name (MAPxx, ExMx, or whatever custom format you define in Levels.ddf). They can also be extracted verbatim as uncompressed data (as in, the /maps directory would contain all map data and node information like a top level PWAD would).
-::'''WARNING:''' Loading WAD files inside of a ZIP or a PK3 will cause memory issues to arise. EDGE will unpack each WAD file and use more memory to access the contents. This effect quickly adds up, especially in larger mods (with the exception of map wads in the maps/ folder, provided they follow the format explicitly -- see below). The bigger the mod is, the more likely it may run out of memory during play and crashing EDGE, or for '''memory corruption''' to occur. Thus, it is '''highly''' recommended to completely unpack the entire contents of any WADs inside, or part of the mod, into the sorted directories.
+::'''WARNING:''' Loading WAD files inside of a ZIP or a PK3 can potentially cause memory issues to arise. EDGE will unpack each WAD file and use more memory to access the contents. This effect quickly adds up, especially in larger mods (with the exception of map wads in the maps/ folder, provided they follow the format explicitly -- see below). The bigger the mod is, the more likely it may run out of memory during play and crashing EDGE, or for '''memory corruption''' to occur. Thus, it is '''highly''' recommended to completely unpack the entire contents of any WADs inside, or part of the mod, into the sorted directories.
-::'''Furthermore''', EDGE supports and promotes subdirectories under the main ones for sorting purposes (i.e. Sprites/Weapons/Cannon, Sprites/Monsters/Technodemon, etc). No extra effort is needed to indicate the sprites are present, as EDGE automatically scans all subdirectories (though PNG and JPG images will still need to be defined in [[IMAGES|IMAGES.DDF]].
+::'''Furthermore''', EDGE supports and promotes subdirectories under the main ones for sorting purposes (i.e. Sprites/Weapons/Cannon, Sprites/Monsters/Technodemon, etc). No extra effort is needed to indicate the sprites are present, as EDGE automatically scans all subdirectories as long as they reside in their proper namespaces. If Images are contained this way, some users wouldn’t even need to define the name entry in Images.DDF.
 Unlike WADs which do not have a true directory structure, the placement of data within ZIPs is much more strictly enforced in order to allow the engine to recognize it as a default lump. Any special data must be placed in the respective directory inside the ZIP or it will not be found. For the [[lump]] name, the first 8 characters of the file name are used, the extension is stripped. So for example, to place a [[COAL Manual|COALHUD]] into a ZIP file, you have to name your file '''coalhud1.TXT''', '''COALHUD1.LMP''' (or whatever extension you like) and place it in '''"./scripts"'''. The following sub directories are used to assign data to the existing WAD [[namespace]]s in EDGE:
@@ Line 76: / Line 76: @@
 * [https://github.com/sirjuddington/SLADE SLADE] or similar programs are recommended for creating the actual .zip file, to ensure programs like WinZIP or WinRAR do not create them with unsupported file compression. Otherwise, they may appear to be damaged, which may hinder modifications of the epk with SLADE, Slumped, etc.
-* [https://github.com/sirjuddington/SLADE SLADE] is also capable of creating the .epk file directly, where WinZIP and WinRAR cannot; WinRAR/7Z can still open epks though.
+* [https://github.com/sirjuddington/SLADE SLADE] is also capable of reading and writing the .epk archive directly, where WinZIP and WinRAR natively cannot; WinRAR/7Z can still open epks though.
 * The ZIP file's directory is sorted alphabetically before adding it to the lump directory; any WAD files in the .zip are then loaded afterwards. Keep that in mind when creating data that relies on file name ordering. For most things, there is no need to depend on ordering, with the exception of texture animations of type ''range'' that animate textures from the flats/ or textures/ subdirectories.
@@ Line 84: / Line 84: @@
 * Sprite lumps for the '''\''' frame in a WAD (such as '''VILE\*''' for one of the Arch-Vile's healing frames) can be put in a ZIP file, the backslash character just has to be changed to a caret character ('''^'''). So, '''VILE^1''' to '''VILE^8''' in a ZIP file will be interpreted as the '''VILE\1''' to '''VILE\8''' lumps. This replacement only works for sprites, any other lump name should not contain backslashes anywhere. As it is possible to use multiple sprite names for an actor with [[DDF]], frames beyond '''Z''' need not be used however.
-* '''It is ''strongly'' recommended to use the .EPK extension, not .zip, when creating a file meant to be loaded directly into EDGE'''. The average user is used to opening a .zip file and extracting a .wad from it, so naming the actual game file a .zip will often cause unwanted confusion.
+* '''It is ''strongly'' recommended to use the .EPK extension, not .zip or .pk3, when creating a file meant to be loaded directly into EDGE'''. The average user is used to opening a .zip file and extracting a .wad from it, so naming the actual game file a .zip will often cause unwanted confusion.
-* '''The contents of the files inside the ZIP must be identical to the lumps in a WAD.''' This is especially important for graphics. '''EDGE does not read .BMP files!''' Even though that is the most likely format you will encounter, importing them with a WAD manager will convert them to Doom's internal format. [[XWE]] converts graphics encoded in Doom's internal format to .BMP during export. [[SLumpEd]] can export these graphics as raw Doom lumps. In order for EDGE to recognize graphics as such, they have to be either in Doom's internal format or a supported [[image format]] such as [[PNG]].
+* '''The contents of the files inside the ZIP must be identical to the lumps in a WAD.''' This is especially important for graphics. Even though that is the most likely format you will encounter, importing them with a WAD manager will convert them to Doom's internal format. [[XWE]] converts graphics encoded in Doom's internal format to .BMP during export. [[SLumpEd]] can export these graphics as raw Doom lumps. In order for EDGE to recognize graphics as such, they have to be either in Doom's internal format or a supported [[DDFIMAGE|image format]] such as [[PNG]].
 * '''Beware of hidden files!''' If you add a full directory, or directory tree, to a EPK, it is possible that unwanted system files (such as Windows' <tt>thumbs.db</tt> file that tends to be created in any folder containing pictures) will be included as well. They will needlessly increase the file size and can possibly trigger warning messages when loading EDGE. [[Slumped]] frequently crashes when browsing through an EPK's resources, as it expects thumbs.db to be a graphic and obtain incoherent values.

← Older revision		Revision as of 18:17, 27 December 2017
Line 1:		Line 1:
−	{{DoomWiki\|PK3}}	+	{{DoomWiki\|PK3}}'''NOTE: Only''' {{LatestS}} '''and higher is able to read compressed archives.'''
−	:''~~PK3 redirects here. The PK3 file format is the same as the [[ZIP]] file format, and is treated exactly the same by 3DGE.~~''
−
−	''~~'NOTE: Only 3DGE 2.1.0-Test 3~~ and higher is able to read compressed archives.'''

	[[3DGE]] allows using several compressed [[archive format]]s instead of the traditional [[WAD]]s. Most notably:		[[3DGE]] allows using several compressed [[archive format]]s instead of the traditional [[WAD]]s. Most notably:

@@ Line 27: / Line 27: @@
 ::'''Furthermore''', 3DGE supports and promotes subdirectories under the main ones for sorting purposes (i.e. Sprites/Weapons/Cannon, Sprites/Monsters/Technodemon, etc). No extra effort is needed to indicate the sprites are present, as 3DGE automatically scans all subdirectories (though PNG and JPG images will still need to be defined in [[IMAGES|IMAGES.DDF]].
-Unlike WADs which do not have a true directory structure, the placement of data within ZIPs is much more strictly enforced in order to allow the engine to recognize it as a default lump. Any special data must be placed in the respective directory inside the ZIP or it will not be found. For the [[lump]] name, the first 8 characters of the file name are used, the extension is stripped. So for example, to place a [[COALHUD]] into a ZIP file, you have to name your file '''coalhud1.TXT''', '''COALHUD1.LMP''' (or whatever extension you like) and place it in the ZIPs root directory. The following subdirectories are used to assign data to the existing WAD [[namespace]]s in 3DGE:
+Unlike WADs which do not have a true directory structure, the placement of data within ZIPs is much more strictly enforced in order to allow the engine to recognize it as a default lump. Any special data must be placed in the respective directory inside the ZIP or it will not be found. For the [[lump]] name, the first 8 characters of the file name are used, the extension is stripped. So for example, to place a [[COAL Manual|COALHUD]] into a ZIP file, you have to name your file '''coalhud1.TXT''', '''COALHUD1.LMP''' (or whatever extension you like) and place it in the ZIPs root directory. The following sub directories are used to assign data to the existing WAD [[namespace]]s in 3DGE:
 {| {{prettytable}} style="font-size: 95%;"
@@ Line 39: / Line 39: @@
 | '''colormaps/''' || contains [[Boom]] and [[3DGE]] colormaps normally found between '''C_START''' and '''C_END'''.
 |-
-| '''doom_ddf/''' || can contain all [[DDF]], [[RTS]], and [[COAL]] scripts here. This is not explicitly needed however, since they can be added in the root directory of the ZIP all the same.
+| '''doom_ddf/'''
 |-
 | '''filter/''' || {{new}} contains lumps and directories that will only be loaded with specific games. '''Not yet implemented!'''
@@ Line 49: / Line 53: @@
 | '''hires/''' || contains high-resolution textures normally found between [[HI_START]] and [[HI_END]]
 |-
-| '''maps/''' || contains levels in form of WADs. These WADs must only contain the data for one single level (including GL nodes lumps if required). Any other data in such a WAD will be ignored. Note that the file name and not the map label inside the WAD determines how the map is named in the game, unless otherwise specified by [[Levels.DDF]]. 3DGE will automatically build the GL nodes via glBSP if a map is found.
+| '''maps/''' || contains levels in form of WADs. These WADs must only contain the data for one single level (including GL nodes lumps if required). Any other data in such a WAD will be ignored. Note that the file name and not the map label inside the WAD determines how the map is named in the game, unless otherwise specified by [[LEVELS|Levels.DDF]]. 3DGE will automatically build the GL nodes via glBSP if a map is found.
 |-
 | '''models/''' || contains [[MD2]], [[MD3]], or [[MD5]] models. ''This namespace does not exist in WADs''.
@@ Line 61: / Line 65: @@
 | '''skins/''' || contains all skins to be loaded for 3D models. ''This namespace does not exist in WADs.''
 |-
-| '''sounds/''' || contains all sound files that are referenced by [[SOUNDS.DDF|DDFSFX]]. ''This namespace does not exist in WADs.''
+| '''sounds/''' || contains all sound files that are referenced by [[SOUNDS|DDFSFX]]. ''This namespace does not exist in WADs.''
 |-
 | '''sprites/''' || contains [[sprite]]s normally found between '''[[S_START]]''' and '''[[S_END]]''' (also known as '''SS_START''', '''SS_END''')

@@ Line 7: / Line 7: @@
 ;{{wp|ZIP_(file_format)|ZIP}}
 :A .zip file used as the container for an 3DGE mod is  usually given the .pk3 extension, instead of .zip. While there is no technical differences, this helps avoid potential confusion from users thinking the mod should be extracted from it, and also prevents Windows from presenting it as a directory. 3DGE supports several ZIP archiving methods: stored (no compression), shrunk, imploded, {{wp|DEFLATE|deflated}} (the most commonly used), {{wp|bzip2}} and {{wp|LZMA}} algorithms. Note that many ZIP utility only partially implement the ZIP standard and as a result their support is limited to stored and deflated files. This partial implementation also affects some [[editing tools]] which normally support the PK3 format, such as [[3DGE Builder]], Doom Builder 2, and [[Slumped]].
-:[[EPK]]
+;[[EPK]]
-:EDGE 2.1.0 Test3 and higher use a modified ZIP container named '''EPK''' ('''E'''dge '''P'''a'''K'''), which is the recommended extension for EDGE-specific mods. The main datafile for EDGE 2.1.0 Test3 now uses this container format.
+:EDGE 2.1.0 Test3 and higher uses a modified ZIP container named '''EPK''' ('''E'''dge '''P'''a'''K'''), which is the recommended extension for EDGE-specific mods. The main datafile for EDGE 2.1.0 Test3 now uses this container format.
 ;{{wp|7z}}
 :A .7z file used as the container for a 3DGE mod is usually given the .pk7 extension, for similar reasons. This format offers much better compression ratio, however its reduced support, especially by modding utilities, make it less interesting overall. It also increases the memory footprint on the engine, so caution must be taken when choosing between a 7z and a PK3 format. A possibility would be to develop a mod as a PK3, then convert it to a PK7 once finished, to decrease the size of the archive to be distributed. However, keep in mind that decompression is quite slower than for zips, so loading times are increased.
@@ Line 25: / Line 25: @@
 ::'''WARNING:''' Loading WAD files inside of a ZIP or a PK3 will cause memory issues to arise. 3DGE will unpack each WAD file and use more memory to access the contents. This effect quickly adds up, especially in larger mods (with the exception of map wads in the maps/ folder, provided they follow the format explicitly -- see below). The bigger the mod is, the more likely it may run out of memory during play and crashing 3DGE, or for '''memory corruption''' to occur. Thus, it is '''highly''' recommended to completely unpack the entire contents of any WADs inside, or part of the mod, into the sorted directories.
-::'''Furthermore''', 3DGE supports and promotes subdirectories under the main ones for sorting purposes (i.e. Sprites/Weapons/Cannon, Sprites/Monsters/Technodemon, etc). No extra effort is needed to indicate the sprites are present, as 3DGE automatically scans all subdirectories (though PNG and JPG images will still need to be defined in [[IMAGES.DDF]].
+::'''Furthermore''', 3DGE supports and promotes subdirectories under the main ones for sorting purposes (i.e. Sprites/Weapons/Cannon, Sprites/Monsters/Technodemon, etc). No extra effort is needed to indicate the sprites are present, as 3DGE automatically scans all subdirectories (though PNG and JPG images will still need to be defined in [[IMAGES|IMAGES.DDF]].
 Unlike WADs which do not have a true directory structure, the placement of data within ZIPs is much more strictly enforced in order to allow the engine to recognize it as a default lump. Any special data must be placed in the respective directory inside the ZIP or it will not be found. For the [[lump]] name, the first 8 characters of the file name are used, the extension is stripped. So for example, to place a [[COALHUD]] into a ZIP file, you have to name your file '''coalhud1.TXT''', '''COALHUD1.LMP''' (or whatever extension you like) and place it in the ZIPs root directory. The following subdirectories are used to assign data to the existing WAD [[namespace]]s in 3DGE:
@@ Line 74: / Line 74: @@
 == Tips ==
-* [[SLADE]] or similar programs are recommended for creating the actual .zip file, to ensure programs like WinZIP or WinRAR do not create them with unsupported file compression. Otherwise, they may appear to be damaged, which may hinder modifications of the pk3 with SLADE, Slumped, etc.
+* [https://github.com/sirjuddington/SLADE SLADE] or similar programs are recommended for creating the actual .zip file, to ensure programs like WinZIP or WinRAR do not create them with unsupported file compression. Otherwise, they may appear to be damaged, which may hinder modifications of the pk3 with SLADE, Slumped, etc.
-* [[SLADE]] is also capable of creating the .pk3 file directly, where WinZIP and WinRAR cannot; WinRAR can still open pk3s though.
+* [https://github.com/sirjuddington/SLADE SLADE] is also capable of creating the .pk3 file directly, where WinZIP and WinRAR cannot; WinRAR can still open pk3s though.
 * The ZIP file's directory is sorted alphabetically before adding it to the lump directory; any WAD files in the .zip are then loaded afterwards. Keep that in mind when creating data that relies on file name ordering. For most things, there is no need to depend on ordering, with the exception of texture animations of type ''range'' that animate textures from the flats/ or textures/ subdirectories.

@@ Line 7: / Line 7: @@
 ;{{wp|ZIP_(file_format)|ZIP}}
 :A .zip file used as the container for an 3DGE mod is  usually given the .pk3 extension, instead of .zip. While there is no technical differences, this helps avoid potential confusion from users thinking the mod should be extracted from it, and also prevents Windows from presenting it as a directory. 3DGE supports several ZIP archiving methods: stored (no compression), shrunk, imploded, {{wp|DEFLATE|deflated}} (the most commonly used), {{wp|bzip2}} and {{wp|LZMA}} algorithms. Note that many ZIP utility only partially implement the ZIP standard and as a result their support is limited to stored and deflated files. This partial implementation also affects some [[editing tools]] which normally support the PK3 format, such as [[3DGE Builder]], Doom Builder 2, and [[Slumped]].
-:'''EPK'''
+:[[EPK]]
 :EDGE 2.1.0 Test3 and higher use a modified ZIP container named '''EPK''' ('''E'''dge '''P'''a'''K'''), which is the recommended extension for EDGE-specific mods. The main datafile for EDGE 2.1.0 Test3 now uses this container format.
 ;{{wp|7z}}

@@ Line 7: / Line 7: @@
 ;{{wp|ZIP_(file_format)|ZIP}}
 :A .zip file used as the container for an 3DGE mod is  usually given the .pk3 extension, instead of .zip. While there is no technical differences, this helps avoid potential confusion from users thinking the mod should be extracted from it, and also prevents Windows from presenting it as a directory. 3DGE supports several ZIP archiving methods: stored (no compression), shrunk, imploded, {{wp|DEFLATE|deflated}} (the most commonly used), {{wp|bzip2}} and {{wp|LZMA}} algorithms. Note that many ZIP utility only partially implement the ZIP standard and as a result their support is limited to stored and deflated files. This partial implementation also affects some [[editing tools]] which normally support the PK3 format, such as [[3DGE Builder]], Doom Builder 2, and [[Slumped]].
 ;{{wp|7z}}
 :A .7z file used as the container for a 3DGE mod is usually given the .pk7 extension, for similar reasons. This format offers much better compression ratio, however its reduced support, especially by modding utilities, make it less interesting overall. It also increases the memory footprint on the engine, so caution must be taken when choosing between a 7z and a PK3 format. A possibility would be to develop a mod as a PK3, then convert it to a PK7 once finished, to decrease the size of the archive to be distributed. However, keep in mind that decompression is quite slower than for zips, so loading times are increased.
 ;[http://quakewiki.org/wiki/.pak PAK]
-: A .PAK file is used as an alternative container for 3DGE mods; it follows Quake's PAK convention strictly. This also works for Quake II PAKs, as well as .SIN packfiles. By default, the main data file for 3DGE uses this format; though it is ''uncompressed'', only preserving directory structure. Aside from that, it is nearly functionally identical to the WAD container format.
+: A .PAK file is used as an alternative container for 3DGE mods; it follows Quake's PAK convention strictly. This also works for Quake II PAKs, as well as .SIN packfiles. It is nearly functionally identical to the WAD container format.
-−
+:
 Compressed archives have many advantages over PWADs and PAKs, even for storing content for Doom:
 * Smaller file size due to compression
@@ Line 27: / Line 29: @@
 Unlike WADs which do not have a true directory structure, the placement of data within ZIPs is much more strictly enforced in order to allow the engine to recognize it as a default lump. Any special data must be placed in the respective directory inside the ZIP or it will not be found. For the [[lump]] name, the first 8 characters of the file name are used, the extension is stripped. So for example, to place a [[COALHUD]] into a ZIP file, you have to name your file '''coalhud1.TXT''', '''COALHUD1.LMP''' (or whatever extension you like) and place it in the ZIPs root directory. The following subdirectories are used to assign data to the existing WAD [[namespace]]s in 3DGE:
-{| {{prettytable}}
+{| {{prettytable}} style="font-size: 95%;"
 |-
 | '''Directory''' || '''Description'''
 |-
-| '''acs/''' || contains [[Libraries|ACS libraries]] normally found between '''A_START''' and '''A_END''' '''Not yet implemented!'''
+| '''acs/''' || contains [[Libraries|ACS libraries]] normally found between '''A_START''' and '''A_END''' '''''Not yet implemented!'''''
 |-
 | '''cameras/''' || contains [[CAMDAT]] files for [[CAMERA-MAN_Manual|camera-man]] scripts.
@@ Line 49: / Line 51: @@
 | '''maps/''' || contains levels in form of WADs. These WADs must only contain the data for one single level (including GL nodes lumps if required). Any other data in such a WAD will be ignored. Note that the file name and not the map label inside the WAD determines how the map is named in the game, unless otherwise specified by [[Levels.DDF]]. 3DGE will automatically build the GL nodes via glBSP if a map is found.
 |-
-| '''models/''' || contains [[MD2]], [[MD3]], or [[MD5]] models. "This namespace does not exist in WADs."
+| '''models/''' || contains [[MD2]], [[MD3]], or [[MD5]] models. ''This namespace does not exist in WADs''.
 |-
 | '''music/''' || contains all data that is used as music. ''This namespace does not exist in WADs.''
@@ Line 97: / Line 99: @@
 * [[Tips for using ZIPs as WAD replacement]]
-[[Category: Guides]][[Category:Technical aspects]]
+[[Category: Guides]]

@@ Line 46: / Line 46: @@
 |-
 | '''maps/''' || contains levels in form of WADs. These WADs must only contain the data for one single level (including GL nodes lumps if required). Any other data in such a WAD will be ignored. Note that the file name and not the map label inside the WAD determines how the map is named in the game, unless otherwise specified by [[Levels.DDF]]. 3DGE will automatically build the GL nodes via glBSP if a map is found.
 |-
 | '''music/''' || contains all data that is used as music. ''This namespace does not exist in WADs.''
 |-
 | '''patches/''' || contains [[patch]]es normally found between '''PP_START''' and '''PP_END'''
 |-
 | '''sounds/''' || contains all sound files that are referenced by [[SOUNDS.DDF]]. ''This namespace does not exist in WADs.''