Mapster32 Map Checking
Mapster32 supports validation of loaded map files via the corruptcheck OSD command. It is also able to repair certain cases of damaged maps.
The severity of a map error is judged by a "level" number from 1 to 5, and can be interpreted like follows:
- warning (very minor issue)
- warning (minor issue)
- worth looking into: may have consequences
- serious/very serious corruption: must not occur in a clean map
- panic: something is very, very wrong!
Levels 3 and 4 are the ones that occur most often. Currently, Mapster32 prints only the maximal corruption level when checking. For levels 4 and above, it is advisable to restart Mapster32 and reload the map after fixing the particular corruption, since the internal state of the editor itself may have become corrupt.
After listing the corruptions, you can jump to each of them (provided they're not outside the editing grid) using the Alt+[ and Alt+] shortcuts.
corruptcheck now: prints out a list of all map corruptions, along with numbers used to refer to them and a short description
corruptcheck tryfix [num]: attempts to repair the corruption num if given, or all of them otherwise
all "corruptcheck" messages
- SECTOR[num1].WALLPTR=num2 out of range (numwalls=num3)
- SECTOR[num1].WALLPTR=num2 inconsistent, expected num3
- SECTOR[num1]: wallptr+wallnum=num2 out of range: numwalls=num3
resolution: manual (expert use)
- SECTOR[num1].WALLNUM=2, expected at least 3
resolution: highlight and delete the sector. (See topic at Duke4.net forums for an example)
- WALL[num1].POINT2=num2 out of range [num3, num4]
- WALL[num1].NEXTWALL=num2 out of range: numwalls=num3
- WALL[num1].NEXTSECTOR=num2 out of range: numsectors=num3
- WALL[num1].NEXTWALL is its own sector's wall
resolution: manual (expert use). Newer Mapster32 versions will make these walls white (may need specifying '??' alternative).
TODO: various messages about TROR
- WALL[num1].NEXTSECTOR is its own sector
resolution: corruptcheck tryfix will reset .nextwall and .nextsector or attempt to find matching ones
- WALL[num1].NEXTSECTOR=num2 and .NEXTWALL=num3 inconsistent: missing one next pointer
- WALL[num1].NEXTWALL=num2 out of .NEXTSECTOR=num3's bounds [num4 .. num5]
Possible problems: crashes, "undefined behavior". Specifically, the quick path of sectorofwall() may return -1 even though the passed wall number is inside the [0..numwalls-1] bounds.
Resolution: corruptcheck tryfix will attempt to find a matching .nextwall/.nextsector. When none are found, passing '??' to 'corruptcheck' tells it to make these walls white instead.
- WALL[num1] has length 0
Poossible problems: divides by zero in engine/game code.
Resolution: one point should be dragged away, or if the corresponding sector is degenerate (has zero area), it should be deleted. See this post at Duke4.net, for example.
- WALL[num1].NEXTWALL=num2 already referenced from wall num3
Issue: generally, red walls are supposed to have a 1-to-1 relationship, though there are certain uses for 1-to-N connections. Entering corruptcheck_noalreadyrefd will toggle the ignore state of this "corruption".
- SPRITE[num1].SECTNUM=num2. Expect problems!
- SPRITE[num1].STATNUM=num2 Expect problems!
These happen when the statnum or sectnum of a sprite is out of bounds.
resolution: delete or reinsert the sprites, or manually set the stat- or sectnums.
- SPRITE num1 at [num2, num3] is out of the maximal grid range [num4, num5]
possible problems: integer overflows in engine or game code
resolution: corruptcheck tryfix will place the sprite at its sector's first point.