NFORenum - Automatic Sprite Correction ====================================== NFORenum is capable of performing some automated correction of your pseudo-sprites. The following items can be corrected, with the following limitations: Action 0 <num-props>: Changed to the number of valid property bytes with the sufficient following data for <new-info>. This can fail in very interesting ways if <num-info> is not correct. ([*] when corrected value is 00, 01, or more than 2 below the old value.) Action 0 <num-info>: Corrected after <num-props>, and only if <num-props> is 01 and the property being set is not variably lengthed. For these purposes, "variably lengthed" means anything that is not a byte, extended byte, word, or doubleword. House/industry tile action 2 <num-sprites>: Changed to the number of valid sprite blocks (<sprite> followed by 3 or 6 bytes of meta-deta), but not if either the original or new values are 00. Standard action 2 <feature>: Corrected to the feature of the preceding action 1 if it requires sprites from an action 1, or if the feature is not valid. ([*] when changing from an invalid feature, or between the standard (features 00..05,0B) and house/industry tile (features 07/09) formats.) The sprite will then be completely rechecked. Variational/random action 2 <feature>: Corrected to the feature of the referenced action 2s, if all referenced action 2s are defined with the same feature. The sprite will then be completely rechecked. Variational action 2 <nvar>: Only corrected if a corrected value exists that makes the sprite length agree with nvar. Random action 2 <nrand>: Only corrected if a corrected value exists that makes the sprite length agree with nrand, and the corrected value has exactly one bit set. Action 3 <feature>: (See var/random action 2 feature.) Action 3 <num-cid>: Only corrected if a corrected value exists that makes the sprite length agree with num-cid. This can fail in very interesting ways if <num-ids> is not correct. [*] Action 4 <num-ent>: Count of strings found in the action 4. Action 6: A trailing FF will be added if doing so will make the sprite valid. Action 7/9 <varsize>: Only corrected if the sprite length, variable, and condition all agree on the correct value. For bit-tests, this value is corrected to 01. Action A <num-sets>: Only corrected if a corrected value exists that makes the sprite length agree with num-sets. Action E <num>: Only corrected if a corrected value exists that makes the sprite length agree with num. Action 12 <num-def>: Only corrected if a corrected value exists that makes the sprite length agree with num-def. All actions containing strings (4, 8, B, F): A trailing 00 will be added if end-of-sprite is encountered while parsing a string. [*] These can be unsafe, and are not enabled unless -a/--autocorrect is specified twice. In all cases, the parsing logic changes; in some cases substantially. If the resultant error/warning messages are illogical, try again without -a, and you may get better messages. The beautifier must be on for auto-correction to work. If the beautifier is off when -a/--auto-correct is seen, NFORenum will behave as if the option "--beautify convertonly=on" immediately followed it on the command line. You are free to turn the beautifier back off, which is useful for doing dry runs of the auto-corrector. If you want to do this, -aab- is one of the many command line arguments that can be used. (NOTE: -ab- -a should not be used. The second -a will turn the beautifier back on again, which is almost certainly not what you wanted.) Add a --lock if you want to be sure that no @@BEAUTIFY commands from the NFO will cause the autocorrecter to make corrections.