DebuggingGRFCode - Revision history

Planetmaker: /* Introduction */ remove left-over syntax-issue from conversion

2011-07-08T06:46:02Z

Introduction: remove left-over syntax-issue from conversion

← Older revision		Revision as of 06:46, 8 July 2011
Line 15:		Line 15:
	Due to the logging the game will become very slow when the debugger is active, so it is best to enable it in paused mode only, and to only briefly unpause if necessary. To trigger redrawing the graphics that are currently on the screen, press "t" (transparent mode) once. Otherwise, if the graphics in question are shown in a window, moving that window a small amount will also trigger redrawing them and call any callbacks necessary to display it.		Due to the logging the game will become very slow when the debugger is active, so it is best to enable it in paused mode only, and to only briefly unpause if necessary. To trigger redrawing the graphics that are currently on the screen, press "t" (transparent mode) once. Otherwise, if the graphics in question are shown in a window, moving that window a small amount will also trigger redrawing them and call any callbacks necessary to display it.

	When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan~~[[]]DaleStan[[~~ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250\|tool] to parse the "grfdebug.log" file into a more descriptive text file.		When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, DaleStan has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250\|tool] to parse the "grfdebug.log" file into a more descriptive text file.

	GET cccciiff <GRFID>		GET cccciiff <GRFID>

Pm-bot: Bot: Automated text replacement (-variational action 2 +VarAction2)

2011-06-19T16:33:29Z

Bot: Automated text replacement (-variational action 2 +VarAction2)

← Older revision		Revision as of 16:33, 19 June 2011
Line 23:		Line 23:
	ACT2 <sprite> 00000000		ACT2 <sprite> 00000000

	When processing a regular, random or ~~variational action 2~~. The sprite number is the sprite number in the .NFO file minus one, given in hex.		When processing a regular, random or VarAction2. The sprite number is the sprite number in the .NFO file minus one, given in hex.

	RND <value> <rndbits>		RND <value> <rndbits>
Line 31:		Line 31:
	VAR <value> <adjusted>		VAR <value> <adjusted>

	In a ~~variational action 2~~, the variable value has been computed as <value>, and <adjusted> will be used after shift/and/add/mod/div adjustments were applied. Note that this is a DWORD value, but only the BYTE/WORD part will be used depending on the VarAction2 type.		In a VarAction2, the variable value has been computed as <value>, and <adjusted> will be used after shift/and/add/mod/div adjustments were applied. Note that this is a DWORD value, but only the BYTE/WORD part will be used depending on the VarAction2 type.

	RSLT <result> 00000000		RSLT <result> 00000000

Pm-bot: Bot: Automated text replacement (-var.action 2 +VarAction2)

2011-06-19T16:31:08Z

Bot: Automated text replacement (-var.action 2 +VarAction2)

← Older revision		Revision as of 16:31, 19 June 2011
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

	For the most part, writing NFO code, especially ~~var.action 2~~ chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.		For the most part, writing NFO code, especially VarAction2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.

	OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: [http://wiki.openttd.org/NewGRF_Debugging\| OpenTTD NewGRF debugging]		OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: [http://wiki.openttd.org/NewGRF_Debugging\| OpenTTD NewGRF debugging]
Line 31:		Line 31:
	VAR <value> <adjusted>		VAR <value> <adjusted>

	In a variational action 2, the variable value has been computed as <value>, and <adjusted> will be used after shift/and/add/mod/div adjustments were applied. Note that this is a DWORD value, but only the BYTE/WORD part will be used depending on the ~~var.action 2~~ type.		In a variational action 2, the variable value has been computed as <value>, and <adjusted> will be used after shift/and/add/mod/div adjustments were applied. Note that this is a DWORD value, but only the BYTE/WORD part will be used depending on the VarAction2 type.

	RSLT <result> 00000000		RSLT <result> 00000000

Pm-bot: Bot: Automated text replacement (-callback 12 +callback 12)

2011-06-16T09:29:02Z

Bot: Automated text replacement (-callback 12 +callback 12)

← Older revision		Revision as of 09:29, 16 June 2011
Line 11:		Line 11:
	The "1" is there to activate the debugger. This creates a file "grfdebug.log" (deleting any existing version first) to which all following debug information is written. The optional feature, id and callback values specify what to log. If specified, only the given feature, id and callback are logged. Note that the values have to be entered in ''decimal'', despite being hex everywhere else. When a value is missing or is equal to 255, it is not checked for a match. If the cheat fails due to "invalid parameter", it means the file "grfdebug.log" could not be created, possibly because a file of the same name exists but is not writable. If it fails with "unknown cheat", the given version does not have the GRF debugger built in (only nightly versions have it, not releases because it slows down graphics processing a little even when not used).		The "1" is there to activate the debugger. This creates a file "grfdebug.log" (deleting any existing version first) to which all following debug information is written. The optional feature, id and callback values specify what to log. If specified, only the given feature, id and callback are logged. Note that the values have to be entered in ''decimal'', despite being hex everywhere else. When a value is missing or is equal to 255, it is not checked for a match. If the cheat fails due to "invalid parameter", it means the file "grfdebug.log" could not be created, possibly because a file of the same name exists but is not writable. If it fails with "unknown cheat", the given version does not have the GRF debugger built in (only nightly versions have it, not releases because it slows down graphics processing a little even when not used).

	For instance, "Cht: grfdebug 1 1 255 18" logs callback 12 (load amount, decimal 18) for all road vehicles.		For instance, "Cht: grfdebug 1 1 255 18" logs [[Callbacks#Load amount callback 12\|callback 12]] (load amount, decimal 18) for all road vehicles.

	Due to the logging the game will become very slow when the debugger is active, so it is best to enable it in paused mode only, and to only briefly unpause if necessary. To trigger redrawing the graphics that are currently on the screen, press "t" (transparent mode) once. Otherwise, if the graphics in question are shown in a window, moving that window a small amount will also trigger redrawing them and call any callbacks necessary to display it.		Due to the logging the game will become very slow when the debugger is active, so it is best to enable it in paused mode only, and to only briefly unpause if necessary. To trigger redrawing the graphics that are currently on the screen, press "t" (transparent mode) once. Otherwise, if the graphics in question are shown in a window, moving that window a small amount will also trigger redrawing them and call any callbacks necessary to display it.

Pm-bot: use GRFID consistently

2011-06-15T16:05:59Z

use GRFID consistently

← Older revision		Revision as of 16:05, 15 June 2011
Line 17:		Line 17:
	When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan[[]]DaleStan[[ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250\|tool] to parse the "grfdebug.log" file into a more descriptive text file.		When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan[[]]DaleStan[[ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250\|tool] to parse the "grfdebug.log" file into a more descriptive text file.

	GET cccciiff <~~grfID~~>		GET cccciiff <GRFID>

	Written at the start when determining the sprite/callback result for feature ff, ID ii in callback cccc (callback is 0 if none, or 1 when determining random triggers). The given ~~grfID~~ is the one owning the action 3 in question.		Written at the start when determining the sprite/callback result for feature ff, ID ii in callback cccc (callback is 0 if none, or 1 when determining random triggers). The given GRFID is the one owning the action 3 in question.

	ACT2 <sprite> 00000000		ACT2 <sprite> 00000000

Pm-bot: use grfID consistently

2011-06-15T16:04:22Z

use grfID consistently

← Older revision		Revision as of 16:04, 15 June 2011
Line 17:		Line 17:
	When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan[[]]DaleStan[[ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250\|tool] to parse the "grfdebug.log" file into a more descriptive text file.		When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan[[]]DaleStan[[ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250\|tool] to parse the "grfdebug.log" file into a more descriptive text file.

	GET cccciiff <~~grfid~~>		GET cccciiff <grfID>

	Written at the start when determining the sprite/callback result for feature ff, ID ii in callback cccc (callback is 0 if none, or 1 when determining random triggers). The given ~~GRFID~~ is the one owning the action 3 in question.		Written at the start when determining the sprite/callback result for feature ff, ID ii in callback cccc (callback is 0 if none, or 1 when determining random triggers). The given grfID is the one owning the action 3 in question.

	ACT2 <sprite> 00000000		ACT2 <sprite> 00000000

Pm-bot: /* Introduction */ links should not have nowiki formating

2011-06-14T23:48:38Z

Introduction: links should not have nowiki formating

← Older revision		Revision as of 23:48, 14 June 2011
Line 3:		Line 3:
	For the most part, writing NFO code, especially var.action 2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.		For the most part, writing NFO code, especially var.action 2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.

	OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: ~~<nowiki>~~http://wiki.openttd.org/NewGRF_Debugging		OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: [http://wiki.openttd.org/NewGRF_Debugging\| OpenTTD NewGRF debugging]

	TTDPatch nightly versions from r663 and up include a sort of GRF debugger that displays what is going on.		TTDPatch nightly versions from r663 and up include a sort of GRF debugger that displays what is going on.

Pm-bot: remove heading

2011-06-14T23:47:31Z

remove heading

← Older revision		Revision as of 23:47, 14 June 2011
Line 1:		Line 1:

	== Introduction ==		== Introduction ==

	=DebuggingGRFCode=

	For the most part, writing NFO code, especially var.action 2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.		For the most part, writing NFO code, especially var.action 2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.

	OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: <nowiki>http://wiki.openttd.org/NewGRF_Debugging		OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: <nowiki>http://wiki.openttd.org/NewGRF_Debugging

	</nowiki>

	TTDPatch nightly versions from r663 and up include a sort of GRF debugger that displays what is going on.		TTDPatch nightly versions from r663 and up include a sort of GRF debugger that displays what is going on.

Pm-bot: Bot: Automated text replacement (--= +==)

2011-06-14T23:46:46Z

Bot: Automated text replacement (--= +==)

← Older revision		Revision as of 23:46, 14 June 2011
Line 1:		Line 1:

			== Introduction ==
	'''''Tools for debugging problems in GRF code'''''

	=DebuggingGRFCode=		=DebuggingGRFCode=
Line 6:		Line 6:
	For the most part, writing NFO code, especially var.action 2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.		For the most part, writing NFO code, especially var.action 2 chains, is done by trial-and-error until it works. To help with this process, TTDPatch and OpenTTD provide various debugging tools.

	OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. ~~ ~~OpenTTD newgrf debugging tools are described in the OpenTTD manual: <nowiki>http://wiki.openttd.org/NewGRF_Debugging		OpenTTD nightly versions from r19723 and up include multiple newgrf debugging tools, including 'inspect' and a sprite aligner. OpenTTD newgrf debugging tools are described in the OpenTTD manual: <nowiki>http://wiki.openttd.org/NewGRF_Debugging

	</nowiki>		</nowiki>
Line 12:		Line 12:
	TTDPatch nightly versions from r663 and up include a sort of GRF debugger that displays what is going on.		TTDPatch nightly versions from r663 and up include a sort of GRF debugger that displays what is going on.

	To activate the debugger, use the sign cheat ~~"~~Cht: grfdebug 1 ~~<nowiki><nowiki>~~[<~~/nowiki~~>~~</nowiki><feature>~~ ~~<nowiki><nowiki>~~[<~~/nowiki~~>~~</nowiki><id>~~ ~~<nowiki><nowiki>~~[<~~/nowiki~~>~~</nowiki><callback>~~]]]~~"~~.		To activate the debugger, use the sign cheat "Cht: grfdebug 1 [<feature> [<id> [<callback>]]]".

	The ~~"~~1~~"~~ is there to activate the debugger. This creates a file ~~"~~grfdebug.log~~"~~ (deleting any existing version first) to which all following debug information is written. The optional feature, id and callback values specify what to log. If specified, only the given feature, id and callback are logged. Note that the values have to be entered in ''decimal'', despite being hex everywhere else. When a value is missing or is equal to 255, it is not checked for a match. If the cheat fails due to ~~"~~invalid parameter~~"~~, it means the file ~~"~~grfdebug.log~~"~~ could not be created, possibly because a file of the same name exists but is not writable. If it fails with ~~"~~unknown cheat~~"~~, the given version does not have the GRF debugger built in (only nightly versions have it, not releases because it slows down graphics processing a little even when not used).		The "1" is there to activate the debugger. This creates a file "grfdebug.log" (deleting any existing version first) to which all following debug information is written. The optional feature, id and callback values specify what to log. If specified, only the given feature, id and callback are logged. Note that the values have to be entered in ''decimal'', despite being hex everywhere else. When a value is missing or is equal to 255, it is not checked for a match. If the cheat fails due to "invalid parameter", it means the file "grfdebug.log" could not be created, possibly because a file of the same name exists but is not writable. If it fails with "unknown cheat", the given version does not have the GRF debugger built in (only nightly versions have it, not releases because it slows down graphics processing a little even when not used).

	For instance, ~~"~~Cht: grfdebug 1 1 255 18~~"~~ logs callback 12 (load amount, decimal 18) for all road vehicles.		For instance, "Cht: grfdebug 1 1 255 18" logs callback 12 (load amount, decimal 18) for all road vehicles.

	Due to the logging the game will become very slow when the debugger is active, so it is best to enable it in paused mode only, and to only briefly unpause if necessary. To trigger redrawing the graphics that are currently on the screen, press ~~"~~t~~"~~ (transparent mode) once. Otherwise, if the graphics in question are shown in a window, moving that window a small amount will also trigger redrawing them and call any callbacks necessary to display it.		Due to the logging the game will become very slow when the debugger is active, so it is best to enable it in paused mode only, and to only briefly unpause if necessary. To trigger redrawing the graphics that are currently on the screen, press "t" (transparent mode) once. Otherwise, if the graphics in question are shown in a window, moving that window a small amount will also trigger redrawing them and call any callbacks necessary to display it.

	When the problematic graphics have been displayed, turn off the debugger again with ~~"~~Cht: grfdebug~~"~~. This closes the ~~"~~grfdebug.log~~"~~ file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan[[]]DaleStan[[ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250\|tool] to parse the ~~"~~grfdebug.log~~"~~ file into a more descriptive text file.		When the problematic graphics have been displayed, turn off the debugger again with "Cht: grfdebug". This closes the "grfdebug.log" file, which may then be examined for the following entries. For help in interpreting the debug lines, ))DaleStan[[]]DaleStan[[ has written a [http://www.tt-forums.net/viewtopic.php?p=573250#573250\|tool] to parse the "grfdebug.log" file into a more descriptive text file.

	~~<pre>-+~~GET ~~ ~~cccciiff ~~<grfid>+-~~<~~/pre~~>		GET cccciiff <grfid>

	Written at the start when determining the sprite/callback result for feature ff, ID ii in callback cccc (callback is 0 if none, or 1 when determining random triggers). The given GRFID is the one owning the action 3 in question.		Written at the start when determining the sprite/callback result for feature ff, ID ii in callback cccc (callback is 0 if none, or 1 when determining random triggers). The given GRFID is the one owning the action 3 in question.

	~~<pre>-+~~ACT2 ~~<~~sprite~~>~~ 00000000~~+-</pre>~~		ACT2 <sprite> 00000000

	When processing a regular, random or variational action 2. The sprite number is the sprite number in the .NFO file minus one, given in hex.		When processing a regular, random or variational action 2. The sprite number is the sprite number in the .NFO file minus one, given in hex.

	~~<pre>-+~~RND ~~ <~~value~~>~~ ~~<rndbits>+-~~<~~/pre~~>		RND <value> <rndbits>

	In a random action 2, the random value is ~~<~~value~~>~~ with ~~<~~rndbits~~>~~ being the bits used to choose the next action 2.		In a random action 2, the random value is <value> with <rndbits> being the bits used to choose the next action 2.

	~~<pre>-+~~VAR ~~ <~~value~~>~~ ~~<adjusted>+-~~<~~/pre~~>		VAR <value> <adjusted>

	In a variational action 2, the variable value has been computed as ~~<~~value~~>~~, and ~~<~~adjusted~~>~~ will be used after shift/and/add/mod/div adjustments were applied. Note that this is a DWORD value, but only the BYTE/WORD part will be used depending on the var.action 2 type.		In a variational action 2, the variable value has been computed as <value>, and <adjusted> will be used after shift/and/add/mod/div adjustments were applied. Note that this is a DWORD value, but only the BYTE/WORD part will be used depending on the var.action 2 type.

	~~<pre>-+~~RSLT ~~<~~result~~>~~ 00000000~~+-</pre>~~		RSLT <result> 00000000

	A callback result has been computed. When not in a callback, this causes the sprite determination to fail and default sprites to be used.		A callback result has been computed. When not in a callback, this causes the sprite determination to fail and default sprites to be used.

	~~<pre>-+~~SPRT ~~<~~sprite~~>~~ 00000000~~+-</pre>~~		SPRT <sprite> 00000000

	A sprite number has been computed. When in a callback, this causes the callback to fail if it isn't following a RSLT line indicating a valid callback result.		A sprite number has been computed. When in a callback, this causes the callback to fail if it isn't following a RSLT line indicating a valid callback result.
Line 48:		Line 48:
	Since the value is mapped into TTD's sprite number space, it is not directly related to sprite numbers in the NFO file. To translate the returned sprite number to an action 1 block sprite, it is necessary to have this grf file be loaded first in newgrf(w).cfg. Then the sprite numbers of action 1 blocks will be allocated consecutively starting from the base number (see below) for each feature.		Since the value is mapped into TTD's sprite number space, it is not directly related to sprite numbers in the NFO file. To translate the returned sprite number to an action 1 block sprite, it is necessary to have this grf file be loaded first in newgrf(w).cfg. Then the sprite numbers of action 1 blocks will be allocated consecutively starting from the base number (see below) for each feature.

			{\|
	\|\|Feature\|Base number		!Feature!!Base number

			\|-
	other\|1324 (4900) Note: this includes all features not listed below as well as GRM sprite allocations		\|other\|\|1324 (4900) Note: this includes all features not listed below as well as GRM sprite allocations

			\|-
	Trains\|4000 (16384)		\|Trains\|\|4000 (16384)

			\|-
	Road vehicles\|6CDC (27868)		\|Road vehicles\|\|6CDC (27868)

			\|-
	Aircraft\|99B8 (39352)		\|Aircraft\|\|99B8 (39352)

			\|-
	Ships\|BBCD (48077)		\|Ships\|\|BBCD (48077)

			\|-
	Houses\|DDE2 (56802)\|\|		\|Houses\|\|DDE2 (56802)
			\|}

	The feature-specific base numbers are only valid if the extended sprite limit is active, otherwise all features use the ~~"~~other~~"~~ base number.		The feature-specific base numbers are only valid if the extended sprite limit is active, otherwise all features use the "other" base number.

	For instance, the first sprite block of 32 (20 hex) sprites for a road vehicle would start at sprite 6CDC, then the following sprite block would start at 6CDC+20=6CFC.		For instance, the first sprite block of 32 (20 hex) sprites for a road vehicle would start at sprite 6CDC, then the following sprite block would start at 6CDC+20=6CFC.

Orudge: 6 revisions

2011-06-12T19:23:34Z

6 revisions

← Older revision	Revision as of 19:23, 12 June 2011
(No difference)