General strategy for implementing new graphics

1. First sprite is special, defining the total number of entries in the .grf file.
2. Start with one or more action 7 entries that decide whether or not to load these graphics, for example based on the current climate.
3. After the action 7 entries, define your GRF ID with action 8.
4. Then define one or several action 0 entries, that (possibly among other things) set the vehicle sprite IDs to FD (trains) or FF (all other vehicle types). Only vehicles with these sprite IDs will be using the new sprites.
5. Start a block of new graphics with an action 1 (sprite block) entry, followed by the actual sprite data. Ideally, you put the graphics of all vehicles together in this one sprite block, taking note of what sets of sprites have what number (as determined by their position in the block).
6. After action 1, give action 2 (cargo ID) entries for each different combination of vehicle and cargo type. The cargo IDs should start at zero and be numbered consecutively.
7. After all action 2 entries, use action 3 (veh ID to cargo ID maps) to specify what cargo IDs are to be shown for which vehicle and which cargo types.

Small remark by George: for My LVs I use a bit different sprite orders. First I define groups of sprite blocks of graphics. Then I combine them with action 3. And then I specify action 0 and 4 for the object, that uses that graphics.

Dealing with the sprite numbers and pseudo-sprite blocks

It can be quite a chore to make sure that the sprite numbers increase by one, and that you have the correct length for the pseudo-sprite blocks. Currently, GRFCodec has only limited parsing capabilities, so you need to make sure that they are indeed correct. As of GRFCodec version 0.9.4, you can specify a sprite number of "-1", which turns off the number checking for that sprite. The following sprites still need correct numbers (unless they also have "-1" as the number), and the sprite length still needs to be specified.

renum.pl

One help in this task is a Perl script called renum.pl, which is included in the TTDPatch source archive. If you haven't heard of Perl before, it's a powerful programming language that you can get for free. For example, you can install it with the Cygwin packages (www.cygwin.com), or from activestate.com or perl.com.

If you have written a .nfo file, but it doesn't have the right numbers for the sprites or the lengths, run the renum.pl script like this:

perl renum.pl < your.nfo > yournew.nfo

It will take the your.nfo (substitute your actual filename), and write yournew.nfo with correct sprite numbers and pseudo-sprite lengths.

Note that the format of the nfo needs to be correct for this to work properly; in particular, the sprite numbers and pseudo-sprite lengths must already be *there* (as dummy numbers), but they need not be correct. Also, renum.pl does not understand strings. Decode with -t and do not use strings if you plan to use renum.pl.

NFORenum

Another program that can be used is NFORenum. This program does understand strings, and is run like this:

renum your.nfo

You may also drag and drop your nfo file onto the NFORenum executable.

Again, substitute the actual filename; that file will be rewritten with a correct sprite 0, correct sprite numbers, and correct pseudo-sprite lengths. NFORenum also does some checking of your code, and will complain if it finds something it thinks is wrong.

As with renum.pl, the format of the nfo needs to be correct for this to work properly.