home *** CD-ROM | disk | FTP | other *** search
/ Hot Shareware 35 / hot35.iso / ficheros / VDUKE / CDM.ZIP / CDM.TXT < prev    next >
Text File  |  1996-11-05  |  12KB  |  228 lines
  1. CDM
  2. Check Duke3D Map V1.0
  3. Copyright 1996
  4. by Peter Hardie
  5.  
  6.  
  7.     This program performs several "sanity" checks on a duke3d map and prints
  8. out some information about the map. It can be useful for either a map builder
  9. who wants to check that their map doesn't contain common errors, or it can be
  10. used by duke players who download maps and use cdm to tell them whether the map
  11. has errors and also whether the map is for Single, Dukematch, and/or Coop play
  12. (because either there's no documentation for the map or, as sometimes happens,
  13. the documentation file is wrong).
  14.  
  15.         The program only performs some fairly simple tests at the moment but I
  16. hope to make it do more extensive tests in the future. It does test for one of
  17. the most common and frustrating errors in a map - water transports which kill
  18. Duke.
  19.         At the moment the program can be run from Win95 DOS only (not standalone
  20. DOS) and is called using the following syntax:
  21.  
  22.         cdm [-s] [-a] [-c] [-z] [-w] filename[.map]
  23.  
  24.         If cdm is called with no arguments at all, it will print out a brief
  25. summary of its usage, otherwise the filename argument must be present and the
  26. .map extension can be omitted if you wish.
  27.  
  28.         The optional arguments are primarily useful to map builders.
  29.         They are:
  30.  
  31.         -z      print out detailed information about *every* sector, wall and
  32.                 sprite in the map and then exit without performing any tests.
  33.                 This is only useful for small test maps.
  34.  
  35.         -s      print out the sector information for any transport sector
  36.                 effectors (water, elevator or normal).
  37.  
  38.     -w    print out extra information about the walls of transport 
  39.         sectors.
  40.  
  41.     -a    print out the colour and locations of all access cards and
  42.                 switches.
  43.  
  44.         -c      Print out information about conveyor sector effectors and the
  45.                 angle of the floor sprite that they are on. This is an attempt
  46.                 to have the program check that the floor's texture will move in
  47.                 the same direction as the SE sprite is pointing (or at least not
  48.                 in the opposite direction).
  49.                 HOWEVER, the program doesn't do any testing yet and this output
  50.                 is for information purposes only right now.
  51.  
  52.     The following list describes the tests and messages printed out by the
  53. program in the order that they occur: 
  54.  
  55.         -       If the map is not version number 7 the program prints an error
  56.                 message and terminates because it cannot handle versions other
  57.                 than 7. If the version isn't 7 it often means that the file
  58.                 isn't a map anyway.
  59.  
  60.     -    If the map has no sectors or walls, the program prints an error
  61.                 message and terminates.
  62.  
  63.         -       The program now prints out the numbers of sectors, walls and
  64.                 sprites. Note that there may not be any sprites, which means
  65.                 there isn't a useful game in the map but for map builders this
  66.                 may not be an error.
  67.  
  68.         -       If the starting position has the coordinates (0,0), the program
  69.                 prints a warning message because this is the default start
  70.                 position in an empty map. It is not treated as an error because
  71.                 it is possible for a valid map to start at this position but
  72.                 the program does not test to see if the start position falls
  73.                 inside valid user space.
  74.  
  75.     The program now performs some tests on the sprites in the map and so
  76. the following messages may be mixed together. When error messages concern
  77. objects such as sprites or walls, which have a specific coordinate in the map,
  78. the message will always contain the (x,y) coordinate.
  79.  
  80.         -       An error message is printed if an access card is found to have
  81.                 an incorrect palette number (i.e. the card is not red, blue or
  82.                 yellow).
  83.  
  84.         -       An error message is produced if the program finds duplicate
  85.                 cards of the same colour - because I have assumed that there
  86.                 should be only one of each colour.
  87.  
  88.         -       The program also looks for the access switches corresponding to
  89.                 the cards and if a switch has an invalid palette an error
  90.                 message is produced. Actually, this isn't necessarily an error
  91.                 because there may be matching cards and switches and this
  92.                 switch is not even intended to work - but I print the message
  93.                 anyway just in case the builder made a mistake.
  94.  
  95.         -       The program can keep track of up to 19 access switches of each
  96.                 colour. If more than 19 of one colour exist then a message is
  97.                 printed for each extra switch.
  98.  
  99.         -       The program looks for both RECON (flying pig) sprites and for
  100.                 the SE which indicates a subway engine. If it finds one or more
  101.                 of both, then a warning message is printed. This is because the
  102.                 duke3d program can handle several subway tracks or *ONE* RECON
  103.                 track but NOT both types at the same time. This is not a bug as
  104.                 such because all that will happen is that one or more of the
  105.                 RECON vehicles will start flying erratically in a small circle
  106.                 which only makes it easier for Duke to kill!
  107.  
  108.     -    If the -c flag is specified, the program prints out the
  109.                 coordinate, angle and Fbits for each conveyor SE (lotag is 24).
  110.                 The Fbits are the bits set in the sectors floorstat variable by
  111.                 the F command in the build program. I will use this information
  112.                 at a future date to implement code which will issue a warning if
  113.                 the floor moves in the direction opposite to that indicated by
  114.                 the SE sprite.
  115.  
  116.         -       The program counts the number of Dukematch and Co-op starting
  117.                 points in the map and if there are any it prints how many it
  118.                 has found plus one for the single player start position
  119.                 (i.e. the printed amount includes the SP start and is therefore
  120.                 one greater than the number of dukematch or co-op starting
  121.                 sprites).
  122.  
  123.         -       I have assumed that, like a Single Player game (as explained
  124.                 below), a Co-op game should have an exit. If there are Co-op
  125.                 start points but no exits, the program adds a note to this
  126.                 effect.
  127.  
  128.         -       The program also checks the map for exits (sectors with a lotag
  129.                 of 65535, a NUKEBUTTON with a lotag of 32767 or 65535 OR the
  130.                 presence of a BOSS in the map). I have assumed that, to be
  131.                 useful, a Single Player map must have an exit. At this point
  132.                 the program uses this information to classify whether the map
  133.                 can be played by a Single Player. If there are no dukematch or
  134.                 coop starting points and the map has no exit the program prints
  135.                 an error message. If there is an exit but no coop or dukematch
  136.                 starting points then the map is classified as Single Player
  137.                 only.
  138.  
  139.     -    The access cards and switches are now checked. If the -a flag is
  140.                 specified then the location of all cards and switches and their
  141.                 colours is printed. If a card does not have corresponding
  142.                 switches, or vice-versa, an error message is printed (even if
  143.                 -a flag is not set).
  144.  
  145.  
  146.         -       The program now checks any transporter sprites found in the map.
  147.                 These must occur in pairs with the same lotag. An error message
  148.                 is printed if only one, or more than two, such sprites are
  149.                 found.
  150.                 The lotags of the sectors, in which the two sector effectors are
  151.                 found, are also tested. They must both either indicate water or
  152.                 a normal transport or be elevator transports.
  153.         If the -s flag is specified considerable extra information is
  154.                 printed about the location of the transport sprites. If the -w
  155.                 flag is specified even more information about the walls of their
  156.                 containing sector is printed.
  157.                 If the sectors are water or elevator transporters then they are
  158.                 tested to see if they are the same size and shape and an error
  159.                 message is produced if they aren't. However, the program can't
  160.                 always test the sectors because if a sector contains an
  161.                 "island" it is very difficult to locate all the walls which
  162.                 define the boundary of the sector. If the -s flag is specified
  163.                 then a warning message is printed if the sector couldn't be
  164.                 tested due to its shape.
  165.                 If all of a sector's walls are found and there are more than 4
  166.                 of them, the program tests to see if the sector is actually
  167.                 rectangular. If it is, then the extraneous interior walls
  168.                 are removed and the sector is treated as a rectangle. This
  169.                 allows the program to compare the shapes and SE location of
  170.                 many more transporters than would otherwise be possible. This
  171.                 is because many water transports, whose overall shape is
  172.                 rectangular, have extra walls in them because they have tunnels
  173.                 or other features which add extra walls to the basic
  174.                 rectangle.
  175.                 Water transports are subjected to one further test. If the
  176.                 program can determine that the sectors are the same size and
  177.                 shape, then it also checks that the SE sprites in the two
  178.                 sectors occur in the same relative positions within their
  179.                 sectors. Duke will transport to death if these two sprites
  180.                 aren't positioned correctly.
  181.  
  182.     This is all that is tested at the moment. I may add tests for things
  183. such as making sure that TOUCHPLATE sprites have a corresponding switch which
  184. they affect and that all ACTIVATOR and ACTIVATORLOCKED sprites have a
  185. corresponding switch or touchplate.
  186.  
  187.         It is worth commenting here about the way that the program classifies
  188. a game as SP because it can be wrong in some cases. As I mentioned above, I
  189. have assumed that a useful SP game must have an exit. It is easy to locate the
  190. different ways in which the game can be terminated and it is worth listing
  191. them all here:
  192.  
  193.         - A NUKEBUTTON which has a lotag of 32767, 65535 or a number between
  194.           1 and 11.
  195.         - A sector which has a lotag of 65535
  196.         - A BOSS or its STAYPUT which has a palette of zero.
  197.  
  198. Any of the above conditions indicate that there is a way to exit the game.
  199. However, it does not mean that a single player can actually get to the exit.
  200. For example, a NUKEBUTTON may be hidden behind a door which can only be opened
  201. with a switch which can only be seen in multiple play. It is extremely
  202. difficult (if not impossible) for a program to detect this kind of situation.
  203. Therefore, if the program classifies a game as Single Player, it only means
  204. that there is an exit - not that the exit is accessible to the single player.
  205.  
  206.         I hope to be able to recompile the program so that it will run under
  207. standalone DOS but I haven't figured out this Borland C++ V5.0 compiler yet.
  208.  
  209.     More complex tests are not as likely to be done. For example, although
  210. it is easy to test that the LOCATOR sprites of a subway have sequential lotags,
  211. it is not as easy (for me at least) to test that they all occur in the correct
  212. order around the subway track's sectors. It is even more difficult to test
  213. a subway to make sure that the subway car(s) will not pass through a wall
  214. when playing a real game.
  215.  
  216.         If you find this program useful, buggy, or have suggestions for
  217. additional tests please Email me.
  218.  
  219.         The latest version of this program can be obtained from:
  220.  
  221.         ftp://ftp.usask.ca/pub/amiga/ibm/cdm.zip
  222.  
  223.  
  224.  
  225. Keep on Duking!
  226. Pete Hardie
  227. ve5va.qrp@usask.ca
  228.