Mapster32 Map Checking - Revision history

Helixhorned: /* level 3 */ suggest another resultion for "wall has length 0"

2013-08-13T11:05:15Z

level 3: suggest another resultion for "wall has length 0"

← Older revision		Revision as of 04:05, 13 August 2013
Line 47:		Line 47:
	==== level 3 ====		==== level 3 ====
	* WALL[''num1''] has length 0		* WALL[''num1''] has length 0
	~~possible~~ problems: divides by zero in engine/game code<br>		Poossible problems: divides by zero in engine/game code.<br>
	~~resolution~~: one point should be dragged away<br>		Resolution: one point should be dragged away, or if the corresponding sector is degenerate (has zero area), it should be deleted. See [http://forums.duke4.net/topic/6698-please-review-this-currently-unfinished-map/page__view__findpost__p__168306 this post at Duke4.net], for example.<br>

	* WALL[''num1''].NEXTWALL=''num2'' already referenced from wall ''num3''		* 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".		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".

	=== sprites ===		=== sprites ===

Helixhorned: /* level 4 */ add some info

2013-05-10T12:49:57Z

level 4: add some info

← Older revision		Revision as of 05:49, 10 May 2013
Line 33:		Line 33:
	* WALL[''num1''].NEXTSECTOR=''num2'' out of range: numsectors=''num3''		* WALL[''num1''].NEXTSECTOR=''num2'' out of range: numsectors=''num3''
	* WALL[''num1''].NEXTWALL is its own sector's wall		* WALL[''num1''].NEXTWALL is its own sector's wall
	resolution: manual (expert use)<br>		resolution: manual (expert use). Newer Mapster32 versions will make these walls white (may need specifying '??' alternative).<br>

	'''TODO''': various messages about TROR<br>		'''TODO''': various messages about TROR<br>
Line 42:		Line 42:
	* WALL[''num1''].NEXTSECTOR=''num2'' and .NEXTWALL=''num3'' inconsistent: missing one next pointer		* WALL[''num1''].NEXTSECTOR=''num2'' and .NEXTWALL=''num3'' inconsistent: missing one next pointer
	* WALL[''num1''].NEXTWALL=''num2'' out of .NEXTSECTOR=''num3'''s bounds [''num4'' .. ''num5'']		* WALL[''num1''].NEXTWALL=''num2'' out of .NEXTSECTOR=''num3'''s bounds [''num4'' .. ''num5'']
	~~possible~~ problems: crashes, "undefined behavior"<br>		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.<br>
	~~resolution~~: '''corruptcheck tryfix''' will attempt to find a matching .nextwall/.nextsector		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.

	==== level 3 ====		==== level 3 ====

Helixhorned: /* level 3 */ corruptcheck_noalreadyrefd

2013-01-11T16:15:52Z

level 3: corruptcheck_noalreadyrefd

← Older revision		Revision as of 09:15, 11 January 2013
Line 51:		Line 51:

	* WALL[''num1''].NEXTWALL=''num2'' already referenced from wall ''num3''		* 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".		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".


	=== sprites ===		=== sprites ===

Helixhorned: add a page about map checking

2012-09-27T14:07:01Z

add a page about map checking

New page

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" options ==
'''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 ==
=== sectors ===
==== level 4 ====
* 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 [http://forums.duke4.net/topic/5728-polymer-renderer-crash-when-loading-user-map-dharga-map-fixed/page__view__findpost__p__136111 topic at Duke4.net forums] for an example)

=== walls ===
==== level 4 ====
* 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) 

'''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" 
resolution: '''corruptcheck tryfix''' will attempt to find a matching .nextwall/.nextsector

==== level 3 ====
* WALL[''num1''] has length 0
possible problems: divides by zero in engine/game code 
resolution: one point should be dragged away 

* 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".

=== sprites ===
==== level 4 ====
* 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.