User Tools

Site Tools


tns:wadpreparation

TNS WAD Preparation

This page describes how to prepare WADs for each TNS session. When the wads have been prepared, they can be uploaded to the TNS WAD repository. A readme with a wad list and additional server settings should also be created for each session (at least for L@P and Ducks, unless you agree with the hosts otherwise; but it is recommended to always do this as it also serves as documentation); the tns#.wad along with tns#readme.txt go into their respective /www/tns# directory (other session-specific wads can go there too).

If hosted on Ducks, the WADs should follow the Ducks WAD Uploading Policy (coming later; in the meantime, follow what the next sentences say). In short, choose unique and descriptive names for unique WAD versions. If you don't want to bother with this too much, just glue a -tns# suffix to everything. Names should still be lowercase and limited to the characters listed in the policy though.

IMPORTANT: Do not forget to include TXT files when creating new ZIP archives! It is also strongly recommended that you keep updating the CHNGLG lumps in WADs which contain them.

WADs with Maps

NOTE: This section contains only basic information at the moment and should (will) be expanded.

It is necessary to make sure the WAD will load fine in ZDaemon, and that there will be no major issues. Certain types of lesser issues can also be avoided or fixed if you do a proper analysis. See Making WAD Fixes on how to create and name -coopfix, and -zdfix WADs (coming later; maybe just call them -tnsfix# for now, and create them according to your own guidelines/judgement).

You can use tnswutil to ease the task; it will dump loads of information for you. Some of it will convey a clear message directly, some will only guide you in what to look at in the editor (GZDB or DB work best as you can search using various criteria, but Slade can be used as well because tnswutil “always” outputs IDs).

Here is the command I used. ~rhinoduck

tnswutil -o -c tnscheck mptypes mpweapons countmonsters coopstarts dmstarts w1teles detectboom extendednodes keens exits -w <path_to_wad>

Output from this utility will also help you with making decisions which the next sections put in front of you.

d#spfx##[-?].wad

Only use it if you have a free WAD slot. Only use it if the WAD you are playing does not contain a custom palette (unless the effects aren't disastrous). Consider dropping it if the WAD you are playing replaces all or majority of sprites.

There are two versions of this WAD:

  • no suffix - only contains gfx fixes
  • -withdeh - contains small DEHACKED fixes as well

Normally, the -withdeh version should be safe to use, but care should be taken if the WAD you are playing has custom dehacked, especially if it modifies weapons. If unsure, do test, or use the no suffix version.

IMPORTANT: Always load it before any map and resource WADs.

fd2rsrc#.wad

If you are having a Doom 1 session, load this WAD before the WAD you are playing if you want to have Doom 2 monsters and weapons available for total randomisation (or anything else).

Also set the following CVARs

set commn_doom1 1
set rds_randDoom1Specials 1

tns#.wad

There are two things to take care of before each sessions.

  1. choosing of PATCHINF which will decide the fate of MP items
  2. conjuring of MAPINFO so that everything works as expected

PATCHINF

There are several versions of the PATCHINF lump available:

  • _PISTD - normal PATCHINFO
  • _PINODM - removes MP items (except radiation suits)
  • _PINOWPN - removes MP weapons only, and leaves other items be
  • _PIMPTAG - PATCHINFO which tags MP items for use with the thing_removeMpItems CVAR
  • _PIHTIC - PATCHINFO for Heretic
  • _PIORIG - original old worst's PATCHINFO

The ones used in 99% of cases are _PISTD or _PINODM based on whether you want to keep or remove MP items respectively. The _PIMPTAG allows to dynamically remove MP items using a CVAR, but, unfortunately, ghost items appear too much when this approach is used.

To use one of these lumps, delete the current lump named PATCHINF, make a copy of the one you want it to replace, and rename it to PATCHINF.

MAPINFO

Having a working MAPINFO is important when you are playing a WAD which changes skies, music, map names, and maybe more. Certain rhinolib functionality also depends on having a MAPINFO with activateowndeathspecials in the defaultmap section. Rhinolib uses this to track when monsters die, and resmod, showtids, and timod will not work without it.

NOTE: Quite a collection of ready-to-use MAPINFOs can be found in the Ducks WAD repository as ducks-<wad_name>-mapinfo-<date>.wad or, using the newer naming scheme, ducks-mapinfo-<wad-name>-<date>.wad. If you are lucky, you can save yourself the work.

NOTE: When doing re-runs, it might also be possible to reuse MAPINFO lumps from old tns# WADs. But be careful, the more into the past you go, the more probable it will be that the MAPINFOs will not satisfy all the currently required criteria.

Here is what to do to get a working MAPINFO for a session:

  1. If the WAD you are playing does not have its own MAPINFO, and uses stock map names, remove the current lump named MAPINFO (if any), copy the _MISTD lump, and rename it to MAPINFO.
  2. If the WAD you are playing does not have its own MAPINFO, but has a DEHACKED lump with map names defined, use mapinfolookup.py (will be provided later) to genereate a MAPINFO from that DEHACKED. Use the generated MAPINFO.
  3. If the WAD has its own MAPINFO, but it is a ZMAPINFO lump or a MAPINFO lump in the new ZDoom format, use test.py (will be provided later, with a better name) to convert it from the new format to the old one which ZDaemon can understand. Continue reading the next points treating the converted ZMAPINFO as your WAD's new MAPINFO.
  4. If the WAD you are playing has its own MAPINFO, and the map names are embedded in it (no lookup keyword), then add or amend the defaultmap section with the activateowndeathspecials keyword. Use this MAPINFO.
  5. If the WAD you are playing has its own MAPINFO, but map names are specified using the lookup keyword, use mapinfolook.py to embed the names into the MAPINFO. Map names will be located in a DEHACKED or a LANGUAGE lump. Also add or amend the defaultmap section with the activateowndeathspecials keyword. Use this MAPINFO.

IMPORTANT: Always try to load the MAPINFO in ZDaemon (can be done in single player), and check if there are no errors in the console. When the parser encounters an error, it ignores the rest of the MAPINFO. Unknown keywords, sections, or malformed sky entries occur quite often, and need to be removed/fixed. Only the map defining sections are important for TNS, you can safely delete cluster definitions and such.

tns-dehacked-########.wad

NOTE: If the WAD you are playing contains a DEHSUPP lump, give up right away, and don't use any TNS dehacked.

Since tns-dehacked-20180123, the -nonazis variant no longer needs to exist; you can use the base WAD with everything.

Since tns-dehacked-20171226, weapon mods are safe to use with TNS dehacked; this was not possible before because of mistakes in the TNS DEHSUPP.

Custom DEHACKED

Since tns-dehacked-20180123, TNS dehacked makes no use of original Doom frames so it should be fine to load it alongside any simple Doom PWAD.

NOTE: ZDaemon does not support MBF frames, so do not expect WADs using those to work properly; tns-dehacked or no tns-dehacked loaded.

Custom Palette

If the WAD you are playing contains a custom palette, test how TNS monsters will look. If everything will look like too much of a mess, use Slade to convert the TNS dehacked gfx so that they use the new palette. Name the new wad like this:

tns-dehacked-<original_date>-<wad_name>-<variant>.wad

in case of aaliens, this turned out as

tns-dehacked-20130918-aaliens-nonazis.wad

in case you duck up and need to re-release

tns-dehacked-20130918-aaliens-nonazis-r2.wad

NOTE: This naming convention is still suboptimal, but, hopefully, you won't need to do this often.

tns/wadpreparation.txt · Last modified: 2018-02-15 12:12:15 (10 months ago) by rhinoduck