TTWiki - User contributions [en-gb]

NFO Foundations

2019-01-29T11:17:52Z

Planetmaker: /* 4. Encode and decode again your own file */

{{NFOTutorial}}

The fundamental files that control your new graphics are the .nfo and the .pcx file. The .pcx file contains the actual drawings, and the .nfo file the instructions what to do with them.

==To get started==

To draw a new train, you first need a base from which to start working. Since you probably aren't familiar with all the intricacies yet, it's best to copy one of TTD's vehicles and then draw your own graphics. Basically, you follow these steps:
# Extract TTD's trg1r.grf (or trg1.grf for the DOS version or ogfx1_base.grf when using OpenGFX)
# Look through trg1r.pcx (TTD) or ogfx1_base.grf (OpenGFX) for a vehicle similar to the one you're going to make
# Copy the corresponding data from the .nfo file into your own file
# Encode and decode again your own file

Now to look at these steps in a bit more details. If you de-compiled OpenGFX's file, use the appropriate filenames instead in the subsequent text.

==1. Extract TTD's trg1r.grf / OpenGFX's ogfx1_base.grf==

First of all, you need to download [http://www.openttd.org/download-grfcodec grfcodec] and unzip it into your TTD folder. Then you open a DOS command window. If you are using Windows 2000 or Windows XP you can open a DOS command window by typing cmd in the execute option in the start menu. When you see the command window run grfcodec like this:

<pre>cd C:\TTD
grfcodec -d trg1r.grf</pre>

Obviously, change <tt>C:\TTD</tt> to point to your TTD directory. If you're using the DOS version of TTD, use <tt>trg1.grf</tt> instead of <tt>trg1r.grf</tt>.

This will make a new folder called sprites, and will put trg1r.pcx and trg1r.nfo in it.

You can also use [http://www.divxland.org/ttd/grfwizard.htm GRFWizard] with grfcodec. It will add a user interface to grfcodec. Just follow the options in the wizard to decode a .grf file, it will also add a sprites folder and generate the .nfo and .pcx files.

==2. Look through trg1r.pcx / ogfx1_base.pcx==

You now open trg1r.pcx from the sprites folder. There are many graphics programs to view and edit .pcx files.

Look for a vehicle that is similar to the one you want to make. For example, if you want to make a train engine with 8 views, you can use the SH 125. So you go looking for its graphics in trg1r.pcx. For the SH 125, you'll find them at numbers 2941 to 2948 (those are the little numbers above the images). Write down those numbers. For example, this is what it might look like:

[[File:sh125.png]]

==3. Copy the corresponding data from the .nfo file into your own file==

So now that we know what sprites to base the graphics on, we need to copy those into a new file. Open the trg1r.nfo file in a text editor, for example Notepad. Also, open another .nfo file for your own graphics, say for example "mytrain.nfo".

Now, copy and paste the first three lines beginning with "//" to your mytrain.nfo file. While they may look like comments, they are actually important.

In the next step, find the lines beginning with the sprite numbers you're written down in the previous step. In the example above, we'd find the lines with numbers 2941 to 2948. Copy those eight (or however many) lines to your mytrain.nfo file as well.

==4. Encode and decode again your own file==

Now we want to make our own .grf file. Unfortunately, grfcodec is a bit picky and will complain loudly if your lines are not numbered properly. To make grfcodec shut up, you have to go through your .nfo file, and change the numbers at the beginning of the lines to go from 0 to 7 (nforenum can do that for you).

At this point, your .nfo file should look something like this:

<pre>// Automatically generated by GRFCODEC. Do not modify!
// (Info version 6)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
0 C:\TTD\SPRITES\trg1.pcx 530 10664 01 18 8 -3 -10
1 C:\TTD\SPRITES\trg1.pcx 546 10664 09 15 20 -14 -6
2 C:\TTD\SPRITES\trg1.pcx 578 10664 01 12 28 -14 -6
3 C:\TTD\SPRITES\trg1.pcx 626 10664 09 16 20 -4 -8
4 C:\TTD\SPRITES\trg1.pcx 658 10664 01 18 8 -3 -10
5 C:\TTD\SPRITES\trg1.pcx 674 10664 09 16 20 -14 -7
6 C:\TTD\SPRITES\trg1.pcx 706 10664 01 12 28 -14 -6
7 C:\TTD\SPRITES\trg1.pcx 754 10664 09 15 20 -4 -7</pre>

Now run grfcodec again, first to encode and then to decode your file. This creates mytrain.pcx and changes your .nfo to refer to that copy of the sprites:

<pre>grfcodec -e mytrain.grf
grfcodec -d mytrain.grf -p 2</pre>

Leave off the "-p 2" if you're working with the DOS graphics instead of the Windows graphics.

==Good job!==

Now you have your own mytrain.grf file with the corresponding mytrain.nfo and mytrain.pcx files. We'll use this as a base for making these graphics TTDPatch compatible.

Note that you can't yet take your mytrain.grf file and put it in TTDPatch's newgrfw.cfg file yet, because it doesn't have the necessary information to allow TTDPatch to know what to do with it.

However, you can go ahead and edit the graphics in mytrain.pcx to your liking and make them look like your train.

Once you're ready, go on to the [[TheFirstVehicle|next section]].
[[Category:Tutorials]][[Category:GRF Tutorial]]

NMLTutorial/Starting an NML file

2015-02-04T22:12:53Z

Planetmaker: NML doesn't work with TTDP anyway

{{NMLTutorial}}

It's time to create your first NML file! All this reading must have made you hungry by now, so let's continue right quick.

== Where to put the NML file ==

From the [[NMLTutorial/Language files|Language files]] section you may remember this folder structure:

mygrf
|- lang
| |- english.lng
| |- other_language.lng
|- custom_tags.txt
|- mygrf.nml

This is exactly where the NML file should go: one folder above the language files, and in the same folder as custom_tags.txt. You can name the file any way you want, but try to avoid spaces. Create it either from the file explorer or from your text editor.

== The grf block ==
Nearly all NML files will start with a grf block. The grf block takes no parameters and is one of the simplest blocks there is. Your NML file also has no more than one grf block. NML files without a grf block are only useful for ''base graphic'' files such as the grf files from OpenGFX. So chances are that you need a grf block.

The general syntax of the grf block is:

<pre class="pseudo">
grf {
grfid: <literal-string>;
name: <string>;
desc: <string>;
version: <expression>;
min_compatible_version: <expression>;
}
</pre>

We'll be looking at every line of this grf block and give you an example how to fill it in.

=== Line 1: grf { ===
This indicates the start of the grf block and the ''opening curly bracket'' defines the start of it's contents. Just type it in your editor:

<pre style="color:darkblue">
grf {
</pre>

=== Line 2: grfid: <literal-string>; ===
This defines the GRFID of your NewGRF. A GRFID is a four-byte string that should be unique. If two NewGRFs have the same GRFID, only one can be used at a time and in OpenTTD chances are only one shows up in the NewGRF list. It's a convention to use the first two bytes for the creator's initials. The last two bytes should be numbers, typically the first number identifying which of the author's sets this is, and the second number being a version number.

The GRFID must be written as a quoted string, but now comes the complicated part: one character is one byte, but one byte is two hexadecimal characters. The first two bytes are best written as a normal quoted string. The last two are best written as escaped bytes, as this allows for 256 sets/versions rather than just 10.

So if your name is Simon Foster and you're starting the first version of your first set, your GRFID can be <code>"SF\01\01"</code>. This way, your GRFID is exactly four bytes: two normal characters S and F, and two escaped bytes 01. The backslash indicates that the next two characters together make one byte. When using escaped bytes, remember that they are in hex and as such can only consist the numbers 0-9 and letters A-F. See [http://en.wikipedia.org/wiki/Hexadecimal Wikipedia] for more details on the hexadecimal numeral system.

Now your second line of the nml file will be (but then with your own GRFID):

<pre style="color:darkblue">
grfid: "SF\01\01";
</pre>

=== Line 3: name: <string>; ===
This is the name of your NewGRF, as displayed ingame. NML expects a reference to a string in your language file here. Luckily, we [[NMLTutorial/Language files|already]] put a name for our NewGRF in there. Open the language file and check what name you attached to the string. In our example that would be <code>STR_GRF_NAME</code>.

To tell NML to use a string from the language file, you have to use the function <code>string(<string-name>)</code>, replacing <code><string-name></code> with the actual name of the string. This gives us <code>string(STR_GRF_NAME)</code>.

Put this in the third line:

<pre style="color:darkblue">
name: string(STR_GRF_NAME);
</pre>

=== Line 4: desc: <string>; ===
The description is similar to the name of the NewGRF. Again look up the name of the string in the language file and use the <code>string()</code> function to put it in the grf block. Line four:

<pre style="color:darkblue">
desc: string(STR_GRF_DESCRIPTION);
</pre>

=== Line 5: version: <expression>; ===
Another version? Yes. If your NewGRF is aimed at (but not limited to) OpenTTD you should use this to indicate the actual version and leave the GRFID constant. If your NewGRF is aimed at (but not limited to) TTDPatch you still should provide this version number, but ''bump the GRFID'' whenever a new release is not compatible with the previous release. More on this at the end of this page.

The first release of your NewGRF will start with version 0 and every subsequent release you will increase this value. In case you use a version control system, set this to the revision number.

This gives line five:

<pre style="color:darkblue">
version: 0;
</pre>

=== Line 6: min_compatible_version: <expression>; ===
For the first release, the minimal compatible version is also 0. Leave it at 0 for as long as subsequent releases are compatible with all previous releases. Whenever you need to break compatibility, you set this to the version number (from above) in which you have broken the compatibility.

Line six:

<pre style="color:darkblue">
min_compatible_version: 0;
</pre>

=== Line 7: } ===
The ''closing curly bracket'' defines the end of the grf block; it closes it if you will.

Just type a curly bracket on line seven:

<pre style="color:darkblue">
}
</pre>

== Summarizing ==
Already? You haven't told us about the semicolons at the end of each line in the grf block!

I haven't? Well, let's do that now then...

=== Semicolons ===
Like in a lot of other programming languages, a semicolon defines the end of an instruction. You must use these at the end of every instruction inside and outside a block, but not on lines that open or close a block (with a curly bracket).

The usage of semicolons in NML is identical (with the exception of templates) to that in Java or C-family (or PHP) languages. It allows to have multiple instructions on one line, which is useful in some cases.

=== Summarizing ===
This completes our grf block. All lines together, the example looks like this:

<pre style="color:darkblue">
grf {
grfid: "SF\01\01";
name: string(STR_GRF_NAME);
desc: string(STR_GRF_DESCRIPTION);
version: 0;
min_compatible_version: 0;
}
</pre>

If you like, you can encode this into a grf to see if it works. The grf will not do anything, but it should show up in the game if you add it.

You still remember how to use ''nmlc' on the command line, right? If not, check the [[NMLTutorial/Installation|Installation page]] with the details for your operating system, or maybe the following pointer is enough to get you going:

nmlc --grf mygrf.grf mygrf.nml

{{NMLTutorialNavbar|NML Syntax|Road vehicle}} 

== Breaking compatibility ==
Sometimes it happens that you have to break compatibility between different releases of your NewGRF. The NML Documentation has a separate chapter on [http://newgrf-specs.tt-wiki.net/wiki/NML:NewGRF_compatibility NewGRF compatibility] and what actions break compatibility and how to avoid breaking it in the first place.

However, if you must break compatibility, here's how to handle the version information in your NML file:

* Keep the GRFID you have;
* Don't forget to update <code>grf { version }</code>;
* Set <code>grf { min_compatible_version }</code> to the value of <code>grf { version }</code>.

This way, OpenTTD will hide the old release from the NewGRF window while keeping it available for older savegames to use (provided the user doesn't delete the old release). Old releases can still be downloaded from BaNaNaS for old savegames.

{{NMLTutorialNavbar|NML Syntax|Road vehicle}}

File:0913POTM pm.jpg

2013-09-20T18:17:43Z

Planetmaker: amend description

industrial: abandoned production site of rocket engines in the former forced labour camp "Mittelbau Dora"

File:0913POTM pm.jpg

2013-09-20T16:16:51Z

Planetmaker: industrial: abandoned production site of rocket engines

industrial: abandoned production site of rocket engines

POTM September 2013

2013-09-20T16:09:01Z

Planetmaker: /* Entries */ add entry

The September 2013 [[Photo of the Month]] competition is now open.
* [http://www.tt-forums.net/viewtopic.php?f=49&t=68626 Entries topic]
* [http://www.tt-forums.net/viewtopic.php?f=49&t=68626 Voting topic (Not yet available)]

The theme for this month is '''Industrial''' - Set by last months winner, vear.

=== Winner ===

The winner of the August Photo of the Month competition was: TBA

=== Entries ===
<gallery>

File:0913POTM_pm.jpg|planetmaker

</gallery>

=== Voting results ===

Not yet available.

=== External links ===
* [http://www.tt-forums.net/viewtopic.php?f=49&t=68626 Entries topic]
* [http://www.tt-forums.net/viewtopic.php?f=49&t=68626 Voting topic (Not yet available)]

NFOTutorial

2013-07-10T16:57:09Z

Planetmaker: /* NFO tutorial */ add station

{{NFOTutorial}}

This section collects tutorials targeting at creating NewGRFs for TTDPatch and OpenTTD using the NFO language.

For authors: please write these in order and always explain changes from one step/page to the next. Also ideally each topic would have a downloadable demo file that shows these steps "in action")

== NFO tutorial ==
This will be a step-by-step guide that teaches how to make new graphics sets using NFO, from the first simple train engine to the most sophisticated train sets with liveries that change in time and special effects such as wagon backlights. How to draw graphics is covered in the [[GraphicsTutorial]].

While the tutorial will be mostly covering train vehicles, all the steps apply to other vehicle types as well, although with slight (but obvious) changes.

Some pages may have sections labelled "advanced concepts", in which the more advanced uses of certain features are explained. You should perhaps not try to understand these at the first reading, but keep them in mind and come back later if you're ready for a little more sophisticated graphics.

* [[Preliminaries]] - What you need to know and do when making new graphics
* [[NFOFoundations]] - How to get started on .nfo editing
* [[TheFirstVehicle]] - Getting your first vehicle into the game
* [[SelectiveGrfLoading]] - Selectively loading GRF files
* [[VariableVehicleID]] - How to implement grfs with variable vehicle IDs
* [[CallbacksTut]] - Tutorial on using callbacks
* [[GeneralNfoStrategy]] - General strategy for writing NFO files
* [[SampleNfoFile]] - A simple NFO file
* [[SimpleNFOStation]] - A simple NFO station
* [[PoweredWagons]] - How to make trains which have powered wagons

== Unfinished Tutorials ==
* [[TestingChanges]] - How to test changes you make to your graphics files
* [[SettingSpeedEtc]] - How to set speed and other properties of your vehicle
* [[NamingYourVehicle]] - How to give your new vehicle a name
* [[EnsuringCompatibility]] - How to make your file compatible with others
* [[ShowingLoadingStates]] - How to show gradual loading effects
* [[DifferentCargoTypes]] - How to have your wagon show different cargo types
* [[WagonOverride]] - How to make train sets with matching wagons
* [[LiveryChanges]] - How to have your vehicle's graphics change with time or other factors
* [[RandomLivery]] - How to get random livery
* [[SpecialEffects]] - Various special effects you can use for new graphics

== Other tutorials ==
Here tutorials on coding NFO are listed.

=== GRFMaker ===
GRFMaker is a tool that provides a graphical user interface for coding NewGRFs in NFO. You still need to be able to understand the concepts of NFO to be able to use it.

* [[UsingGRFMaker]] - Information about how to use GRFMaker

=== Lakie's tutorials ===
These are tutorials that Lakie from [http://www.tt-forums.net/ TT-Forums] wrote, these are on his website for the moment.

Please note these are being worked on, and are not fully complete.

* [http://users2.tt-forums.net/lakie/NfoCoding.php?id=1 Train Refitting - The Basics]

[[Category:Tutorials]]

GraphicsTemplates

2013-06-11T13:13:36Z

Planetmaker: /* Infrastructure */ Add description of template

This page shall just provide a list of templates for easy use and to avoid re-doing the alignment task

== Landscape ==
=== Ground tiles ===
[[File:ground_tiles.png]]
Normal terrain has 19 different slopes as in the order in the image above. Shown are the grid lines which are part of each ground tile.
<pre>
template tmpl_groundsprites(x, y) {
[ 0+x, y, 64, 31, -31, 0 ]
[ 80+x, y, 64, 31, -31, 0 ]
[ 160+x, y, 64, 23, -31, 0 ]
[ 240+x, y, 64, 23, -31, 0 ]

[ 320+x, y, 64, 31, -31, 0 ]
[ 398+x, y, 64, 31, -31, 0 ]
[ 478+x, y, 64, 23, -31, 0 ]
[ 558+x, y, 64, 23, -31, 0 ]

[ 638+x, y, 64, 39, -31, -8 ]
[ 718+x, y, 64, 39, -31, -8 ]
[ 798+x, y, 64, 31, -31, -8 ]
[ 878+x, y, 64, 31, -31, -8 ]

[ 958+x, y, 64, 39, -31, -8 ]
[1038+x, y, 64, 39, -31, -8 ]
[1118+x, y, 64, 31, -31, -8 ]
[1196+x, y, 64, 47, -31,-16 ]

[1276+x, y, 64, 15, -31, 0 ]
[1356+x, y, 64, 31, -31, -8 ]
[1436+x, y, 64, 31, -31, -8 ]
}
</pre>

There are four additional flat rough tiles. They need to be inserted after the usual 19 rough tiles:
<pre>
template tmpl_rough(x, y) {
tmpl_level_ground( x, y)
tmpl_level_ground( 80+x, y)
tmpl_level_ground(160+x, y)
tmpl_level_ground(240+x, y)
}

template tmpl_additional_rough(x, y) {
tmpl_rough(1510+x, y)
}
</pre>

== Infrastructure ==
Roads and (default) tracks share a common layout to ease drawing of level crossings and avoid much copy & paste of the underlaying ground tiles, best done by using a layered graphics file.
=== Roads ===
Not all tiles are covered by road. The tiles without road can be savely ignored when only adressing roads.
[[File:template_roads.png]]
<pre>
template tmpl_level_ground(x, y) { [ x, y, 64, 31, -31, 0 ] }
template tmpl_short_slope(x, y) { [ x, y, 64, 23, -31, 0 ] }
template tmpl_long_slope(x, y) { [ x, y, 64, 39, -31, -8 ] }

template tmpl_infrastructure_road() {
/* Level road tiles */
tmpl_level_ground( 82, 40)
tmpl_level_ground(162, 40)
tmpl_level_ground(242, 40)
tmpl_level_ground(322, 40)
tmpl_level_ground(402, 40)
tmpl_level_ground(482, 40)
tmpl_level_ground(562, 40)
tmpl_level_ground(642, 40)
tmpl_level_ground(722, 40)
tmpl_level_ground( 2, 88)
tmpl_level_ground( 82, 88)

/* slopes */
tmpl_long_slope ( 82, 152)
tmpl_short_slope( 162, 152)
tmpl_short_slope( 242, 152)
tmpl_long_slope ( 322, 152)

/* Half road tiles */
tmpl_level_ground(402, 152)
tmpl_level_ground(482, 152)
tmpl_level_ground(562, 152)
tmpl_level_ground(642, 152)
}

</pre>

File:Template roads.png

2013-06-11T13:10:36Z

Planetmaker:

GraphicsTemplates

2013-06-11T13:10:10Z

Planetmaker: Add templates for roads

This page shall just provide a list of templates for easy use and to avoid re-doing the alignment task

== Landscape ==
=== Ground tiles ===
[[File:ground_tiles.png]]
Normal terrain has 19 different slopes as in the order in the image above. Shown are the grid lines which are part of each ground tile.
<pre>
template tmpl_groundsprites(x, y) {
[ 0+x, y, 64, 31, -31, 0 ]
[ 80+x, y, 64, 31, -31, 0 ]
[ 160+x, y, 64, 23, -31, 0 ]
[ 240+x, y, 64, 23, -31, 0 ]

[ 320+x, y, 64, 31, -31, 0 ]
[ 398+x, y, 64, 31, -31, 0 ]
[ 478+x, y, 64, 23, -31, 0 ]
[ 558+x, y, 64, 23, -31, 0 ]

[ 638+x, y, 64, 39, -31, -8 ]
[ 718+x, y, 64, 39, -31, -8 ]
[ 798+x, y, 64, 31, -31, -8 ]
[ 878+x, y, 64, 31, -31, -8 ]

[ 958+x, y, 64, 39, -31, -8 ]
[1038+x, y, 64, 39, -31, -8 ]
[1118+x, y, 64, 31, -31, -8 ]
[1196+x, y, 64, 47, -31,-16 ]

[1276+x, y, 64, 15, -31, 0 ]
[1356+x, y, 64, 31, -31, -8 ]
[1436+x, y, 64, 31, -31, -8 ]
}
</pre>

There are four additional flat rough tiles. They need to be inserted after the usual 19 rough tiles:
<pre>
template tmpl_rough(x, y) {
tmpl_level_ground( x, y)
tmpl_level_ground( 80+x, y)
tmpl_level_ground(160+x, y)
tmpl_level_ground(240+x, y)
}

template tmpl_additional_rough(x, y) {
tmpl_rough(1510+x, y)
}
</pre>

== Infrastructure ==
=== Roads ===
[[File:template_roads.png]]
<pre>
template tmpl_level_ground(x, y) { [ x, y, 64, 31, -31, 0 ] }
template tmpl_short_slope(x, y) { [ x, y, 64, 23, -31, 0 ] }
template tmpl_long_slope(x, y) { [ x, y, 64, 39, -31, -8 ] }

template tmpl_infrastructure_road() {
/* Level road tiles */
tmpl_level_ground( 82, 40)
tmpl_level_ground(162, 40)
tmpl_level_ground(242, 40)
tmpl_level_ground(322, 40)
tmpl_level_ground(402, 40)
tmpl_level_ground(482, 40)
tmpl_level_ground(562, 40)
tmpl_level_ground(642, 40)
tmpl_level_ground(722, 40)
tmpl_level_ground( 2, 88)
tmpl_level_ground( 82, 88)

/* slopes */
tmpl_long_slope ( 82, 152)
tmpl_short_slope( 162, 152)
tmpl_short_slope( 242, 152)
tmpl_long_slope ( 322, 152)

/* Half road tiles */
tmpl_level_ground(402, 152)
tmpl_level_ground(482, 152)
tmpl_level_ground(562, 152)
tmpl_level_ground(642, 152)
}

</pre>

GraphicsTemplates

2013-06-11T12:28:07Z

Planetmaker: /* Ground tiles */ explain ground tile image a bit more

File:Ground tiles.png

2013-06-11T12:26:47Z

Planetmaker: Template for ground tiles

Template for ground tiles

GraphicsTemplates

2013-06-11T12:25:11Z

Planetmaker: Add template for plain ground tiles

This page shall just provide a list of templates for easy use and to avoid re-doing the alignment task

== Landscape ==
=== Ground tiles ===
[[File:ground_tiles.png]]
Normal terrain has 19 different slopes as in the order in the image above
<pre>
template tmpl_groundsprites(x, y) {
[ 0+x, y, 64, 31, -31, 0 ]
[ 80+x, y, 64, 31, -31, 0 ]
[ 160+x, y, 64, 23, -31, 0 ]
[ 240+x, y, 64, 23, -31, 0 ]

[ 320+x, y, 64, 31, -31, 0 ]
[ 398+x, y, 64, 31, -31, 0 ]
[ 478+x, y, 64, 23, -31, 0 ]
[ 558+x, y, 64, 23, -31, 0 ]

[ 638+x, y, 64, 39, -31, -8 ]
[ 718+x, y, 64, 39, -31, -8 ]
[ 798+x, y, 64, 31, -31, -8 ]
[ 878+x, y, 64, 31, -31, -8 ]

[ 958+x, y, 64, 39, -31, -8 ]
[1038+x, y, 64, 39, -31, -8 ]
[1118+x, y, 64, 31, -31, -8 ]
[1196+x, y, 64, 47, -31,-16 ]

[1276+x, y, 64, 15, -31, 0 ]
[1356+x, y, 64, 31, -31, -8 ]
[1436+x, y, 64, 31, -31, -8 ]
}
</pre>

There are four additional flat rough tiles. They need to be inserted after the usual 19 rough tiles:
<pre>
template tmpl_rough(x, y) {
tmpl_level_ground( x, y)
tmpl_level_ground( 80+x, y)
tmpl_level_ground(160+x, y)
tmpl_level_ground(240+x, y)
}

template tmpl_additional_rough(x, y) {
tmpl_rough(1510+x, y)
}
</pre>

GraphicsTutorial

2013-06-11T12:16:23Z

Planetmaker: /* Other */ Add link to template list

This page collects several individually written tutorials about drawing 8bpp sprites for OpenTTD and TTDPatch. These graphics can then be coded using either [[NFOTutorial|NFO]] or [[NMLTutorial|NML]].

=== General ===
* [[grfspecs:PalettesAndCoordinates|Palettes and Coordinates]] - How to work with palettes, and the 2D and 3D coordinates.
* [[Save paletted image files]] - How to save image files with the correct palette applied.

=== Vehicles ===
* [[DrawingSprites]] - George's tutorial on how to draw road vehicles in his Long Vehicles scale.
* [http://users.tt-forums.net/purno/PDT/ Purno's Drawing Tutorial] - Purno's extensive tutorial on drawing train vehicles.

=== Other ===
* [[StationDrawingTutorial]] - How to draw new stations.
* [[GraphicsTemplates]] - List of example templates with alignment

[[Category:Tutorials]]

NMLTutorial/Object slopes

2013-05-24T13:17:11Z

Planetmaker: off by one

{{NMLTutorial}}
''The example used here is from the [http://dev.openttdcoop.org/projects/dutchroadfurniture/repository Dutch Road Furniture]. The original graphics for this are by FooBar. The code is by FooBar, based on code for the object example from the [http://dev.openttdcoop.org/projects/nml/repository/show/examples NML source] by planetmaker and Hirundo. Code and graphics are both licensed according to the GPL v2 or later. The code has been modified for the purpose of this tutorial.''

This continues and concludes the [[NMLTutorial/Object graphics|second part]] of the object example. In this last part we'll make the object compatible with sloped terrain as well as snow and desert terrain. For this some recent features of OpenTTD will be used, which makes this last part of the example '''incompatible with OpenTTD earlier than 1.2.0 (r22723)'''.

== Version check ==
As indicated, the particular code on this page only works on OpenTTD 1.2.0 (r22723) or higher. Therefore, we want to disable this NewGRF on older versions. This is done by comparing said version number with the <code>openttd_version</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:General#General_variables variable] in an ''if statement''. To avoid having to write the version number in hex, we can use the <code>version_openttd()</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function] and have NML do that for us. If the current game version is older than said version number generate a fatal [http://newgrf-specs.tt-wiki.net/wiki/NML:Error error] message, otherwise skip the error message and continue with the rest of the NewGRF:

<pre class="example">
if (version_openttd(1,2,0,22723) > openttd_version) {
error(FATAL, REQUIRES_OPENTTD, string(STR_OPENTTD_VERSION));
}
</pre>

For the error message we set that it must be <code>FATAL</code>, which means that an error message is issued and loading the NewGRF is aborted. As message we use the builtin string <code>REQUIRES_OPENTTD</code> (automatically translated by the game). This default string must be supplied with the actual version number, provided via the custom string <code>string(STR_OPENTTD_VERSION)</code>.

Due to this custom string reference, we of course also must define it in the language file (it's sufficient to only have this in the default language file):

<pre class="example">
STR_OPENTTD_VERSION :1.2.0 (r22723)
</pre>

== Sloped ground sprites ==
So far our object can only show flat ground tiles. Now we could make a spritelayout for each different slope (19) and each different view of the object (4) which would give us 76 spritelayouts. Luckily, recent versions of OpenTTD allow us to use temporary variable storage to be used inside spritelayouts, which means we can write a small piece of NML code that makes the game calculate what ground sprite to use for a given slope.

This calculation is done in a switch block, so we need to reference a different switch block from the graphics block. This new switch block in turn will reference the switch block we already have:

<pre class="example">
default: switch_fingerpost_3_object;
</pre>

The new switch block will make the calculation based on the <code>tile_slope</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Objects#Object_variables object variable] using the <code>slope_to_sprite_offset()</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function]. This calculates how many sprites (the offset) after the flat ground sprite the sprite for the slope is located at. This is then stored in temporary storage register 0 using the <code>STORE_TEMP()</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function].

Because we don't actually need to make a decision in this switch (it's just used to store the slope sprite offset), we only have a default value inside this switch referencing the original switch block that selected the proper spritelayout block depending on the object view:

<pre class="example">
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_object, STORE_TEMP(slope_to_sprite_offset(tile_slope), 0)) {
switch_fingerpost_3_view;
}
</pre>

Now that we have the calculation, we must actually use it in the four spritelayout blocks for the ground sprite. This means that instead of only referencing the flat ground sprite, we must add the calculated slope sprite offset to this to actually get the sprite number for the slope we want:

<pre class="example">
//south east
spritelayout spritelayout_fingerpost_3_SE {
ground {
sprite: GROUNDSPRITE_NORMAL + LOAD_TEMP(0);
}
building {
sprite: spriteset_fingerpost_3(0);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 12; //from NW edge
zoffset: 0;
}
}
</pre>

Here we take the sprite number of the flat ground sprite (<code>GROUNDSPRITE_NORMAL</code>) and add the calculated offset to this. We get this offset from the temporary storage using the <code>LOAD_TEMP()</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function]. The argument <code>0</code> defines what storage register we want to get a value from. Because we stored in 0, we need to load from 0 as well.

The ground sprite for the other spritelayouts is changed in the same way. We will not give you the other spritelayout blocks here, as they need to be changed once more.

=== Purchase menu ===
Now we have a small problem with the purchase menu. The <code>tile_slope</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Objects#Object_variables object variable] isn't available there, so we cannot use the calculation for the purchase menu! This can be solved easily by not doing the calculation for the purchase menu and always have a sprite offset of 0 there (always giving the flat ground sprite). So for the purchase menu we just set the temporary storage value to 0.

First reference the purchase callback from the graphics block and link to a switch block where we will set the temporary storage:

<pre class="example">
purchase: switch_fingerpost_3_purchase;
</pre>

The switch block itself will only set temporary storage register 0 to a value of 0 and then immediately reference the switch block that makes the decision based on the object views:

<pre class="example">
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_purchase, STORE_TEMP(0, 0)) {
switch_fingerpost_3_view;
}
</pre>

Now the purchase menu works again.

== Snow and desert tiles ==
Now our object works fine on slopes, but still shows a grass tile on snow and desert tiles. Not good! This is because we always use <code>GROUNDSPRITE_NORMAL</code> as a base for the ground sprite to draw, which is the grass tile in all climates.

The solution here is to use the <code>terrain_type</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Objects#Object_variables object variable] to check what terrain we're actually building on. Now you can again have a bunch of spritelayouts for each different terrain type, but also here we can use the temporary storage to save what terrain sprite to use and retrieve this again in the spritelayouts. Let's give that a go, shall we?
* For this we will use the second storage register (with index 1).
* The default case is the normal grounds sprite, so store that in the register: <code>STORE_TEMP(GROUNDSPRITE_NORMAL, 1)</code>.
* In case of the tropic climate, we need to choose between grass and desert depending on the <code>terrain_type</code> variable. If grass, use the storage we already had, otherwise change the storage: <code>STORE_TEMP(terrain_type == TILETYPE_DESERT ? GROUNDSPRITE_DESERT : LOAD_TEMP(1), 1)</code>. What this does is store in register 1: if the terrain is desert the sprite number of the desert flat ground sprite from <code>GROUNDSPRITE_DESERT</code> and if the terrain is not desert what we already had in register 1.
* In case of the arctic climate, we need to choose between grass and snow depending on the <code>terrain_type</code> variable. If grass, use the storage we already had, otherwise change the storage: <code>STORE_TEMP(terrain_type == TILETYPE_SNOW ? GROUNDSPRITE_SNOW : LOAD_TEMP(1), 1)</code>. What this does is store in register 1: if the terrain is snow the sprite number of the snow flat ground sprite from <code>GROUNDSPRITE_SNOW</code> and if the terrain is not snow what we already had in register 1.

These three expressions need to be put somewhere in our NML file. Each expression can go in a separate switch block all linked together, but luckily we may provide an array of expressions in a single switch block. This is done by separating each command by a comma and grouping them together between straight brackets. The decision of the switch block is based on the last expression in the chain (but that is in this case not important as we only have a default return for the switch block).

Change the switch block we made earlier on this page:

<pre class="example">
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_object, [
//tile slope offset in storage register 0
STORE_TEMP(slope_to_sprite_offset(tile_slope), 0),
//terrain type in storage register 1
STORE_TEMP(GROUNDSPRITE_NORMAL, 1),
STORE_TEMP(terrain_type == TILETYPE_DESERT ? GROUNDSPRITE_DESERT : LOAD_TEMP(1), 1),
STORE_TEMP(terrain_type == TILETYPE_SNOW ? GROUNDSPRITE_SNOW : LOAD_TEMP(1), 1)
]) {
switch_fingerpost_3_view;
}
</pre>

For this new calculation to work, we must also change the spritelayout blocks. The choice of the flat ground sprite number is now stored in temporary storage register 1, so we must use this instead of the hardcoded <code>GROUNDSPRITE_NORMAL</code>. Just replace <code>GROUNDSPRITE_NORMAL</code> for the ground sprite with <code>LOAD_TEMP(1)</code> in all spritelayout blocks. If you haven't made the first change to all four spritelayout blocks, do that now all in one go:

<pre class="example">
//south east
spritelayout spritelayout_fingerpost_3_SE {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(0);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 12; //from NW edge
zoffset: 0;
}
}

//south west
spritelayout spritelayout_fingerpost_3_SW {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(1);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 12; //from NE edge
yoffset: 6; //from NW edge
zoffset: 0;
}
}

//north west
spritelayout spritelayout_fingerpost_3_NW {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(2);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 0; //from NW edge
zoffset: 0;
}
}

//north east
spritelayout spritelayout_fingerpost_3_NE {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(3);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 0; //from NE edge
yoffset: 6; //from NW edge
zoffset: 0;
}
}
</pre>

=== Purchase menu ===
Now we have again broken the purchase menu, because the <code>terrain_type</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Objects#Object_variables object variable] is also not available there. This can be solved easily by again not doing the calculation for the purchase menu and always have the grass terrain sprite in the purchase menu. So for the purchase menu we just set the temporary storage register 1 value to <code>GROUNDSPRITE_NORMAL</code>.

This change is similar to the change of the other switch block we just did:

<pre class="example">
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_purchase, [
//use flat gound sprite for purchase menu
STORE_TEMP(0, 0),
//use normal terrain for purchase menu
STORE_TEMP(GROUNDSPRITE_NORMAL, 1),
]) {
switch_fingerpost_3_view;
}
</pre>

So for the purchase menu we just use the flat sprite of the grass terrain. Now the purchase menu works again.

With this the end of the object example is reached. You can now encode this as a NewGRF.

== The complete code ==
If you put everything in the correct order, this will be the complete NML file:

<pre class="example small">
// define the newgrf
grf {
grfid: "\FB\FB\05\01";
name: string(STR_GRF_NAME);
desc: string(STR_GRF_DESCRIPTION);
version: 0;
min_compatible_version: 0;
}

//check OpenTTD version
//parameterized spritelayout is only supported since OpenTTD 1.2.0 r22723
if (version_openttd(1,2,0,22723) > openttd_version) {
error(FATAL, REQUIRES_OPENTTD, string(STR_OPENTTD_VERSION));
}

//templates
template template_fingerpost(x,y,filename) {
[x, y, 20, 32, -10, -28, filename]
[x+30, y, 20, 32, -10, -28, filename]
[x+60, y, 20, 32, -10, -28, filename]
[x+90, y, 20, 32, -10, -28, filename]
}

//spriteset with four directions
spriteset (spriteset_fingerpost_3) {
template_fingerpost(0,0,"gfx/dutch_fingerpost.png")
}

/* spritelayouts */

//south east
spritelayout spritelayout_fingerpost_3_SE {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(0);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 12; //from NW edge
zoffset: 0;
}
}

//south west
spritelayout spritelayout_fingerpost_3_SW {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(1);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 12; //from NE edge
yoffset: 6; //from NW edge
zoffset: 0;
}
}

//north west
spritelayout spritelayout_fingerpost_3_NW {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(2);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 0; //from NW edge
zoffset: 0;
}
}

//north east
spritelayout spritelayout_fingerpost_3_NE {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(3);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 0; //from NE edge
yoffset: 6; //from NW edge
zoffset: 0;
}
}

//decide spritelayout for each of the 4 views
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_view, view) {
1: spritelayout_fingerpost_3_SW;
2: spritelayout_fingerpost_3_NW;
3: spritelayout_fingerpost_3_NE;
spritelayout_fingerpost_3_SE;
}

//calculate ground sprite for object
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_object, [
//tile slope offset in storage register 0
STORE_TEMP(slope_to_sprite_offset(tile_slope), 0),
//terrain type in storage register 1
STORE_TEMP(GROUNDSPRITE_NORMAL, 1),
STORE_TEMP(terrain_type == TILETYPE_DESERT ? GROUNDSPRITE_DESERT : LOAD_TEMP(1), 1),
STORE_TEMP(terrain_type == TILETYPE_SNOW ? GROUNDSPRITE_SNOW : LOAD_TEMP(1), 1)
]) {
switch_fingerpost_3_view;
}

//calculate ground sprite for purchase menu
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_purchase, [
//use flat gound sprite for purchase menu
STORE_TEMP(0, 0),
//use normal terrain for purchase menu
STORE_TEMP(GROUNDSPRITE_NORMAL, 1),
]) {
switch_fingerpost_3_view;
}

item (FEAT_OBJECTS, item_fingerpost_3) {
property {
class: "NLRF";
classname: string(STR_NLRF);
name: string(STR_FINGERPOST_3);
climates_available: ALL_CLIMATES;
size: [1,1];
build_cost_multiplier: 2;
remove_cost_multiplier: 8;
introduction_date: date(1961,1,1);
end_of_life_date: 0xFFFFFFFF;
object_flags: bitmask(OBJ_FLAG_REMOVE_IS_INCOME, OBJ_FLAG_NO_FOUNDATIONS, OBJ_FLAG_ALLOW_BRIDGE);
height: 2;
num_views: 4;
}
graphics {
default: switch_fingerpost_3_object;
purchase: switch_fingerpost_3_purchase;
autoslope: return(CB_RESULT_AUTOSLOPE);
additional_text: string(STR_FINGERPOST_3_PURCHASE);
}
}
</pre>

The language file will now contain:

<pre class="example small">
##grflangid 0x01

#Main grf title and description
STR_GRF_NAME :{TITLE}
STR_GRF_DESCRIPTION :Description: {SILVER}Dutch Road Furniture is an eyecandy object NewGRF that features road furniture that can be found alongside Dutch roads. {}(c)2011 FooBar. {}{BLACK}License: {SILVER}GPLv2 or higher.

#error messages
STR_OPENTTD_VERSION :1.2.0 (r22723)

#object classes
STR_NLRF :Dutch Road Furniture

#object name and description
STR_FINGERPOST_3 :Dutch Fingerpost three-way
STR_FINGERPOST_3_PURCHASE :The three-way fingerpost is centered at one side of the tile and facing outward. Intended to be placed directly opposite of the secondary road at a three-way junction.
</pre>

The next part of the tutorial will teach you some things about adding 32 bit sprites to your NewGRFs.

{{NMLTutorialNavbar|Version check|32 bit sprites}}

NMLTutorial/Object slopes

2013-05-24T13:16:02Z

Planetmaker: simplify some wording

{{NMLTutorial}}
''The example used here is from the [http://dev.openttdcoop.org/projects/dutchroadfurniture/repository Dutch Road Furniture]. The original graphics for this are by FooBar. The code is by FooBar, based on code for the object example from the [http://dev.openttdcoop.org/projects/nml/repository/show/examples NML source] by planetmaker and Hirundo. Code and graphics are both licensed according to the GPL v2 or later. The code has been modified for the purpose of this tutorial.''

This continues and concludes the [[NMLTutorial/Object graphics|second part]] of the object example. In this last part we'll make the object compatible with sloped terrain as well as snow and desert terrain. For this some recent features of OpenTTD will be used, which makes this last part of the example '''incompatible with OpenTTD 1.2.0 (r22723) or earlier'''.

== Version check ==
As indicated, the particular code on this page only works on OpenTTD 1.2.0 (r22723) or higher. Therefore, we want to disable this NewGRF on older versions. This is done by comparing said version number with the <code>openttd_version</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:General#General_variables variable] in an ''if statement''. To avoid having to write the version number in hex, we can use the <code>version_openttd()</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function] and have NML do that for us. If the current game version is older than said version number generate a fatal [http://newgrf-specs.tt-wiki.net/wiki/NML:Error error] message, otherwise skip the error message and continue with the rest of the NewGRF:

<pre class="example">
if (version_openttd(1,2,0,22723) > openttd_version) {
error(FATAL, REQUIRES_OPENTTD, string(STR_OPENTTD_VERSION));
}
</pre>

For the error message we set that it must be <code>FATAL</code>, which means that an error message is issued and loading the NewGRF is aborted. As message we use the builtin string <code>REQUIRES_OPENTTD</code> (automatically translated by the game). This default string must be supplied with the actual version number, provided via the custom string <code>string(STR_OPENTTD_VERSION)</code>.

Due to this custom string reference, we of course also must define it in the language file (it's sufficient to only have this in the default language file):

<pre class="example">
STR_OPENTTD_VERSION :1.2.0 (r22723)
</pre>

== Sloped ground sprites ==
So far our object can only show flat ground tiles. Now we could make a spritelayout for each different slope (19) and each different view of the object (4) which would give us 76 spritelayouts. Luckily, recent versions of OpenTTD allow us to use temporary variable storage to be used inside spritelayouts, which means we can write a small piece of NML code that makes the game calculate what ground sprite to use for a given slope.

This calculation is done in a switch block, so we need to reference a different switch block from the graphics block. This new switch block in turn will reference the switch block we already have:

<pre class="example">
default: switch_fingerpost_3_object;
</pre>

The new switch block will make the calculation based on the <code>tile_slope</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Objects#Object_variables object variable] using the <code>slope_to_sprite_offset()</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function]. This calculates how many sprites (the offset) after the flat ground sprite the sprite for the slope is located at. This is then stored in temporary storage register 0 using the <code>STORE_TEMP()</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function].

Because we don't actually need to make a decision in this switch (it's just used to store the slope sprite offset), we only have a default value inside this switch referencing the original switch block that selected the proper spritelayout block depending on the object view:

<pre class="example">
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_object, STORE_TEMP(slope_to_sprite_offset(tile_slope), 0)) {
switch_fingerpost_3_view;
}
</pre>

Now that we have the calculation, we must actually use it in the four spritelayout blocks for the ground sprite. This means that instead of only referencing the flat ground sprite, we must add the calculated slope sprite offset to this to actually get the sprite number for the slope we want:

<pre class="example">
//south east
spritelayout spritelayout_fingerpost_3_SE {
ground {
sprite: GROUNDSPRITE_NORMAL + LOAD_TEMP(0);
}
building {
sprite: spriteset_fingerpost_3(0);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 12; //from NW edge
zoffset: 0;
}
}
</pre>

Here we take the sprite number of the flat ground sprite (<code>GROUNDSPRITE_NORMAL</code>) and add the calculated offset to this. We get this offset from the temporary storage using the <code>LOAD_TEMP()</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function]. The argument <code>0</code> defines what storage register we want to get a value from. Because we stored in 0, we need to load from 0 as well.

The ground sprite for the other spritelayouts is changed in the same way. We will not give you the other spritelayout blocks here, as they need to be changed once more.

=== Purchase menu ===
Now we have a small problem with the purchase menu. The <code>tile_slope</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Objects#Object_variables object variable] isn't available there, so we cannot use the calculation for the purchase menu! This can be solved easily by not doing the calculation for the purchase menu and always have a sprite offset of 0 there (always giving the flat ground sprite). So for the purchase menu we just set the temporary storage value to 0.

First reference the purchase callback from the graphics block and link to a switch block where we will set the temporary storage:

<pre class="example">
purchase: switch_fingerpost_3_purchase;
</pre>

The switch block itself will only set temporary storage register 0 to a value of 0 and then immediately reference the switch block that makes the decision based on the object views:

<pre class="example">
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_purchase, STORE_TEMP(0, 0)) {
switch_fingerpost_3_view;
}
</pre>

Now the purchase menu works again.

== Snow and desert tiles ==
Now our object works fine on slopes, but still shows a grass tile on snow and desert tiles. Not good! This is because we always use <code>GROUNDSPRITE_NORMAL</code> as a base for the ground sprite to draw, which is the grass tile in all climates.

The solution here is to use the <code>terrain_type</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Objects#Object_variables object variable] to check what terrain we're actually building on. Now you can again have a bunch of spritelayouts for each different terrain type, but also here we can use the temporary storage to save what terrain sprite to use and retrieve this again in the spritelayouts. Let's give that a go, shall we?
* For this we will use the second storage register (with index 1).
* The default case is the normal grounds sprite, so store that in the register: <code>STORE_TEMP(GROUNDSPRITE_NORMAL, 1)</code>.
* In case of the tropic climate, we need to choose between grass and desert depending on the <code>terrain_type</code> variable. If grass, use the storage we already had, otherwise change the storage: <code>STORE_TEMP(terrain_type == TILETYPE_DESERT ? GROUNDSPRITE_DESERT : LOAD_TEMP(1), 1)</code>. What this does is store in register 1: if the terrain is desert the sprite number of the desert flat ground sprite from <code>GROUNDSPRITE_DESERT</code> and if the terrain is not desert what we already had in register 1.
* In case of the arctic climate, we need to choose between grass and snow depending on the <code>terrain_type</code> variable. If grass, use the storage we already had, otherwise change the storage: <code>STORE_TEMP(terrain_type == TILETYPE_SNOW ? GROUNDSPRITE_SNOW : LOAD_TEMP(1), 1)</code>. What this does is store in register 1: if the terrain is snow the sprite number of the snow flat ground sprite from <code>GROUNDSPRITE_SNOW</code> and if the terrain is not snow what we already had in register 1.

These three expressions need to be put somewhere in our NML file. Each expression can go in a separate switch block all linked together, but luckily we may provide an array of expressions in a single switch block. This is done by separating each command by a comma and grouping them together between straight brackets. The decision of the switch block is based on the last expression in the chain (but that is in this case not important as we only have a default return for the switch block).

Change the switch block we made earlier on this page:

<pre class="example">
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_object, [
//tile slope offset in storage register 0
STORE_TEMP(slope_to_sprite_offset(tile_slope), 0),
//terrain type in storage register 1
STORE_TEMP(GROUNDSPRITE_NORMAL, 1),
STORE_TEMP(terrain_type == TILETYPE_DESERT ? GROUNDSPRITE_DESERT : LOAD_TEMP(1), 1),
STORE_TEMP(terrain_type == TILETYPE_SNOW ? GROUNDSPRITE_SNOW : LOAD_TEMP(1), 1)
]) {
switch_fingerpost_3_view;
}
</pre>

For this new calculation to work, we must also change the spritelayout blocks. The choice of the flat ground sprite number is now stored in temporary storage register 1, so we must use this instead of the hardcoded <code>GROUNDSPRITE_NORMAL</code>. Just replace <code>GROUNDSPRITE_NORMAL</code> for the ground sprite with <code>LOAD_TEMP(1)</code> in all spritelayout blocks. If you haven't made the first change to all four spritelayout blocks, do that now all in one go:

<pre class="example">
//south east
spritelayout spritelayout_fingerpost_3_SE {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(0);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 12; //from NW edge
zoffset: 0;
}
}

//south west
spritelayout spritelayout_fingerpost_3_SW {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(1);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 12; //from NE edge
yoffset: 6; //from NW edge
zoffset: 0;
}
}

//north west
spritelayout spritelayout_fingerpost_3_NW {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(2);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 0; //from NW edge
zoffset: 0;
}
}

//north east
spritelayout spritelayout_fingerpost_3_NE {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(3);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 0; //from NE edge
yoffset: 6; //from NW edge
zoffset: 0;
}
}
</pre>

=== Purchase menu ===
Now we have again broken the purchase menu, because the <code>terrain_type</code> [http://newgrf-specs.tt-wiki.net/wiki/NML:Objects#Object_variables object variable] is also not available there. This can be solved easily by again not doing the calculation for the purchase menu and always have the grass terrain sprite in the purchase menu. So for the purchase menu we just set the temporary storage register 1 value to <code>GROUNDSPRITE_NORMAL</code>.

This change is similar to the change of the other switch block we just did:

<pre class="example">
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_purchase, [
//use flat gound sprite for purchase menu
STORE_TEMP(0, 0),
//use normal terrain for purchase menu
STORE_TEMP(GROUNDSPRITE_NORMAL, 1),
]) {
switch_fingerpost_3_view;
}
</pre>

So for the purchase menu we just use the flat sprite of the grass terrain. Now the purchase menu works again.

With this the end of the object example is reached. You can now encode this as a NewGRF.

== The complete code ==
If you put everything in the correct order, this will be the complete NML file:

<pre class="example small">
// define the newgrf
grf {
grfid: "\FB\FB\05\01";
name: string(STR_GRF_NAME);
desc: string(STR_GRF_DESCRIPTION);
version: 0;
min_compatible_version: 0;
}

//check OpenTTD version
//parameterized spritelayout is only supported since OpenTTD 1.2.0 r22723
if (version_openttd(1,2,0,22723) > openttd_version) {
error(FATAL, REQUIRES_OPENTTD, string(STR_OPENTTD_VERSION));
}

//templates
template template_fingerpost(x,y,filename) {
[x, y, 20, 32, -10, -28, filename]
[x+30, y, 20, 32, -10, -28, filename]
[x+60, y, 20, 32, -10, -28, filename]
[x+90, y, 20, 32, -10, -28, filename]
}

//spriteset with four directions
spriteset (spriteset_fingerpost_3) {
template_fingerpost(0,0,"gfx/dutch_fingerpost.png")
}

/* spritelayouts */

//south east
spritelayout spritelayout_fingerpost_3_SE {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(0);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 12; //from NW edge
zoffset: 0;
}
}

//south west
spritelayout spritelayout_fingerpost_3_SW {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(1);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 12; //from NE edge
yoffset: 6; //from NW edge
zoffset: 0;
}
}

//north west
spritelayout spritelayout_fingerpost_3_NW {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(2);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 6; //from NE edge
yoffset: 0; //from NW edge
zoffset: 0;
}
}

//north east
spritelayout spritelayout_fingerpost_3_NE {
ground {
sprite: LOAD_TEMP(0) + LOAD_TEMP(1);
}
building {
sprite: spriteset_fingerpost_3(3);
xextent: 4;
yextent: 4;
zextent: 24;
xoffset: 0; //from NE edge
yoffset: 6; //from NW edge
zoffset: 0;
}
}

//decide spritelayout for each of the 4 views
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_view, view) {
1: spritelayout_fingerpost_3_SW;
2: spritelayout_fingerpost_3_NW;
3: spritelayout_fingerpost_3_NE;
spritelayout_fingerpost_3_SE;
}

//calculate ground sprite for object
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_object, [
//tile slope offset in storage register 0
STORE_TEMP(slope_to_sprite_offset(tile_slope), 0),
//terrain type in storage register 1
STORE_TEMP(GROUNDSPRITE_NORMAL, 1),
STORE_TEMP(terrain_type == TILETYPE_DESERT ? GROUNDSPRITE_DESERT : LOAD_TEMP(1), 1),
STORE_TEMP(terrain_type == TILETYPE_SNOW ? GROUNDSPRITE_SNOW : LOAD_TEMP(1), 1)
]) {
switch_fingerpost_3_view;
}

//calculate ground sprite for purchase menu
switch (FEAT_OBJECTS, SELF, switch_fingerpost_3_purchase, [
//use flat gound sprite for purchase menu
STORE_TEMP(0, 0),
//use normal terrain for purchase menu
STORE_TEMP(GROUNDSPRITE_NORMAL, 1),
]) {
switch_fingerpost_3_view;
}

item (FEAT_OBJECTS, item_fingerpost_3) {
property {
class: "NLRF";
classname: string(STR_NLRF);
name: string(STR_FINGERPOST_3);
climates_available: ALL_CLIMATES;
size: [1,1];
build_cost_multiplier: 2;
remove_cost_multiplier: 8;
introduction_date: date(1961,1,1);
end_of_life_date: 0xFFFFFFFF;
object_flags: bitmask(OBJ_FLAG_REMOVE_IS_INCOME, OBJ_FLAG_NO_FOUNDATIONS, OBJ_FLAG_ALLOW_BRIDGE);
height: 2;
num_views: 4;
}
graphics {
default: switch_fingerpost_3_object;
purchase: switch_fingerpost_3_purchase;
autoslope: return(CB_RESULT_AUTOSLOPE);
additional_text: string(STR_FINGERPOST_3_PURCHASE);
}
}
</pre>

The language file will now contain:

<pre class="example small">
##grflangid 0x01

#Main grf title and description
STR_GRF_NAME :{TITLE}
STR_GRF_DESCRIPTION :Description: {SILVER}Dutch Road Furniture is an eyecandy object NewGRF that features road furniture that can be found alongside Dutch roads. {}(c)2011 FooBar. {}{BLACK}License: {SILVER}GPLv2 or higher.

#error messages
STR_OPENTTD_VERSION :1.2.0 (r22723)

#object classes
STR_NLRF :Dutch Road Furniture

#object name and description
STR_FINGERPOST_3 :Dutch Fingerpost three-way
STR_FINGERPOST_3_PURCHASE :The three-way fingerpost is centered at one side of the tile and facing outward. Intended to be placed directly opposite of the secondary road at a three-way junction.
</pre>

The next part of the tutorial will teach you some things about adding 32 bit sprites to your NewGRFs.

{{NMLTutorialNavbar|Version check|32 bit sprites}}

Tutorials

2012-08-29T07:34:11Z

Planetmaker: add link to wiki page with NewGRF debugging tools

== Playing OpenTTD and TTDPatch ==

* [[PreSignalsTutorial]]: How to use pre-signals

== Coding NewGRFs for OpenTTD and TTDPatch ==

* [[NFOTutorial|NFO Tutorial]]: How to make NewGRFs using NFO (incomplete)
* [[NMLTutorial|NML Tutorial]]: How to make NewGRFs using the NewGRF Meta Language (NML)
* [http://www.tt-forums.net/viewtopic.php?f=26&t=62069 Station Tutorial]: Complete tutorial on station coding from scratch in NFO.

* [[Releasing a NewGRF]]: How to release your NewGRF to the public once you made one.

== General sprite drawing ==

* [[GraphicsTutorial]]: How to draw new 8bpp graphics sprites
* [[Creating_new_Sprites_with_3dsMax|Using 3dsmax]]: Creating sprites using 3DSMax (aimed at Locomotion currently)

== Debugging NewGRFs ==
* [http://wiki.openttd.org/NewGRF_Debugging| Debugging tools] in OpenTTD

Preliminaries

2012-06-14T11:08:00Z

Planetmaker: update link to grfcodec

{{NFOTutorial}}

'''NOTE TO AUTHORS''': Read the LocalStyleGuide, otherwise the page may be rolled back to the last well-commented edit. (This applies everywhere, not just on the pages that mention it.)

To write:

* explain GRFCodec / GRFWizard
* explain hex codes: specific examples using Windows calculator, ideally with screenshots
* maybe: explain DOS/Windows version and how to convert between them
* other things?

==What's a .GRF file?==

As you probably already found out ttd can load new graphics files with help of the patch. These files have the extension .grf and are located in the newgrf folder.

These .grf files are made by [http://dev.openttdcoop.org/projects/grfcodec GRFcodec], this program merges a [[DrawingSprites|.pcx]] file and a .nfo file. (links to george his tut now, but I think on top of that page should be an explanation about pcx files and their palette) In this tutorial we won't look at those 2 file types yet, at first we shall try to explain the basics.

== The GRFCodec and the GRFWizard ==

Like said before a .grf file is a file made by the GRFCodec. The codec is a package of 3 programs:

# GRFCodec: Convert a GRF into an editable PCX file and vice versa
# GRFDiff: Compare two GRF files for differences, and write only the differences to a GRD file
# GRFMerge: Take a GRD file and merge it back into the GRF file

In this tutorial we will only use the first program, if you want more info about the other programs look [http://www.ttdpatch.net/grfcodec/grfcodec.html here].

The GRFCodec is a command line program. This means it's option are only been set in the command line, there is no nice user interface. For the nice interface you can download the [http://www.divxland.org/ttd/ttdsolutions.htm GRFWizard] This program is really helpful. Be warned though for the GRFWizard to work you need the GRFCodec too.

When you run the GRFWizard for the first time you have to point it to the codec, when you have done this everything is really straight forward, you can encode your homemade sprites (sprites are the little drawings that represent one side of a building/vehicle) or you can decode a grf from someone else.

When you want to encode graphics you have to point the wizard which grf file you want to encode the 2nd step is to tell it in which you placed the NFO and PCX. All these file should have the same name.

If you want to encode totally new graphics you have to make a "fake" grf. Just make a new txt file and rename it to the grf you want to encode.

If you choose to decode a grf, the nfo and pcx will be extracted to a map called sprites in the in the folder where you placed the grfcodec in.

==Hex==

'''Unless noted clearly (yes, there are a very few exceptions), assume that all the code on these pages is in hex.'''

hex <nowiki>[heks]</nowiki>
# verb - to bewitch; practice witchcraft on
# adjective - of or pertaining to a numbering system that uses 16 as the radix, employing the numerals 0 through 9 and representing digits greater than 9 with the letters A through F.
# adjective - relating to or encoded in a hexadecimal system, esp. for use by a digital computer.

The guts of your computer consist of a bunch of circuits connecting processor chips, memory chips and a bunch of other stuff.

Each chip consists of a bunch of switches that are off (0) or on (1). A series of switches would look something like this: 1001 0001 1110 0101. This is called binary code. A program that you run on your PC reads and/or writes this code. Unless you are a computer genius, mathematician or a nerd, you would probably need definition 1 above to make this work. Consequently, several people from the aforementioned group devised a way for chips to understand a more manageable numbering system called hex (Definitions 2 and 3 above). They called it Assembly Language, probably because it assembles something called a program. TTDX and TTDPatch are programs. They are written in Assembly Language. This is why you need hex to code an nfo code for your new graphics.

HEX is a way of counting. You normally count from 1 till 9 and then go to 10,11 etc. In HEX it works a bit differently: you count from 0 till 9 but then you go one with A, B,C,D,E,F. So 1 till 9 is just 1 till 9, but then it gets funky A=10, B=11, C=12 and so one till F= 15. when you reach F you just do like you would do normally, you start at 0 again but now with a 1 in front thus 10 (gee that's almost like normal counting! :P) so 10=16 If you want a better understandable explanation visit [http://oss.oetiker.ch/rrdtool/tut/bin_dec_hex.en.html this] link.

Now it would be rather uneasy if you have to count it all by yourself (or at least for me being of the lazy generation) so you can use the windows calculator for that.

If you open it it take any hex, so you have to go to scientific. Just open view and click on scientific mode.

If you did it correctly it will look like this:

(sorry I had to eat, I will see this page later on again)

(He's been out to lunch since last modification: Monday 24 of October, 2005 [20:31:32] by dmccoy. [[File:icon_eek.gif]] Meanwhile I have added a reason why you need hex to the hex section. [[File:icon_cool.gif]])

Hopefully the document on these pages will help you to avoid resorting to hex definition 1 too often.
[[Category:Tutorials]][[Category:GRF Tutorial]]

Ttd-palette-for-gimp

2012-04-16T07:54:00Z

Planetmaker: moved Ttd-palette-for-gimp to Ttd-dos-palette-for-gimp: non-unique naming would lead to confusion.

#REDIRECT [[Ttd-dos-palette-for-gimp]]

Ttd-dos-palette-for-gimp

2012-04-16T07:54:00Z

Planetmaker: moved Ttd-palette-for-gimp to Ttd-dos-palette-for-gimp: non-unique naming would lead to confusion.

== TTD Palette File for GIMP ==

The following code will allow you to create a TTD palette file for GIMP. Copy the text below into a plain text editor and save as a plain text file with a .gpl extension.

<pre>
GIMP Palette
Name: ttd-newgrf-dos
Columns: 16
#
0 0 255 Index 0
16 16 16 Index 1
32 32 32 Index 2
48 48 48 Index 3
64 64 64 Index 4
80 80 80 Index 5
100 100 100 Index 6
116 116 116 Index 7
132 132 132 Index 8
148 148 148 Index 9
168 168 168 Index 10
184 184 184 Index 11
200 200 200 Index 12
216 216 216 Index 13
232 232 232 Index 14
252 252 252 Index 15
52 60 72 Index 16
68 76 92 Index 17
88 96 112 Index 18
108 116 132 Index 19
132 140 152 Index 20
156 160 172 Index 21
176 184 196 Index 22
204 208 220 Index 23
48 44 4 Index 24
64 60 12 Index 25
80 76 20 Index 26
96 92 28 Index 27
120 120 64 Index 28
148 148 100 Index 29
176 176 132 Index 30
204 204 168 Index 31
72 44 4 Index 32
88 60 20 Index 33
104 80 44 Index 34
124 104 72 Index 35
152 132 92 Index 36
184 160 120 Index 37
212 188 148 Index 38
244 220 176 Index 39
64 0 4 Index 40
88 4 16 Index 41
112 16 32 Index 42
136 32 52 Index 43
160 56 76 Index 44
188 84 108 Index 45
204 104 124 Index 46
220 132 144 Index 47
236 156 164 Index 48
252 188 192 Index 49
252 208 0 Index 50
252 232 60 Index 51
252 252 128 Index 52
76 40 0 Index 53
96 60 8 Index 54
116 88 28 Index 55
136 116 56 Index 56
156 136 80 Index 57
176 156 108 Index 58
196 180 136 Index 59
68 24 0 Index 60
96 44 4 Index 61
128 68 8 Index 62
156 96 16 Index 63
184 120 24 Index 64
212 156 32 Index 65
232 184 16 Index 66
252 212 0 Index 67
252 248 128 Index 68
252 252 192 Index 69
32 4 0 Index 70
64 20 8 Index 71
84 28 16 Index 72
108 44 28 Index 73
128 56 40 Index 74
148 72 56 Index 75
168 92 76 Index 76
184 108 88 Index 77
196 128 108 Index 78
212 148 128 Index 79
8 52 0 Index 80
16 64 0 Index 81
32 80 4 Index 82
48 96 4 Index 83
64 112 12 Index 84
84 132 20 Index 85
104 148 28 Index 86
128 168 44 Index 87
28 52 24 Index 88
44 68 32 Index 89
60 88 48 Index 90
80 104 60 Index 91
104 124 76 Index 92
128 148 92 Index 93
152 176 108 Index 94
180 204 124 Index 95
16 52 24 Index 96
32 72 44 Index 97
56 96 72 Index 98
76 116 88 Index 99
96 136 108 Index 100
120 164 136 Index 101
152 192 168 Index 102
184 220 200 Index 103
32 24 0 Index 104
56 28 0 Index 105
72 40 4 Index 106
88 52 12 Index 107
104 64 24 Index 108
124 84 44 Index 109
140 108 64 Index 110
160 128 88 Index 111
76 40 16 Index 112
96 52 24 Index 113
116 68 40 Index 114
136 84 56 Index 115
164 96 64 Index 116
184 112 80 Index 117
204 128 96 Index 118
212 148 112 Index 119
224 168 128 Index 120
236 188 148 Index 121
80 28 4 Index 122
100 40 20 Index 123
120 56 40 Index 124
140 76 64 Index 125
160 100 96 Index 126
184 136 136 Index 127
36 40 68 Index 128
48 52 84 Index 129
64 64 100 Index 130
80 80 116 Index 131
100 100 136 Index 132
132 132 164 Index 133
172 172 192 Index 134
212 212 224 Index 135
40 20 112 Index 136
64 44 144 Index 137
88 64 172 Index 138
104 76 196 Index 139
120 88 224 Index 140
140 104 252 Index 141
160 136 252 Index 142
188 168 252 Index 143
0 24 108 Index 144
0 36 132 Index 145
0 52 160 Index 146
0 72 184 Index 147
0 96 212 Index 148
24 120 220 Index 149
56 144 232 Index 150
88 168 240 Index 151
128 196 252 Index 152
188 224 252 Index 153
16 64 96 Index 154
24 80 108 Index 155
40 96 120 Index 156
52 112 132 Index 157
80 140 160 Index 158
116 172 192 Index 159
156 204 220 Index 160
204 240 252 Index 161
172 52 52 Index 162
212 52 52 Index 163
252 52 52 Index 164
252 100 88 Index 165
252 144 124 Index 166
252 184 160 Index 167
252 216 200 Index 168
252 244 236 Index 169
72 20 112 Index 170
92 44 140 Index 171
112 68 168 Index 172
140 100 196 Index 173
168 136 224 Index 174
200 176 248 Index 175
208 184 255 Index 176
232 208 252 Index 177
60 0 0 Index 178
92 0 0 Index 179
128 0 0 Index 180
160 0 0 Index 181
196 0 0 Index 182
224 0 0 Index 183
252 0 0 Index 184
252 80 0 Index 185
252 108 0 Index 186
252 136 0 Index 187
252 164 0 Index 188
252 192 0 Index 189
252 220 0 Index 190
252 252 0 Index 191
204 136 8 Index 192
228 144 4 Index 193
252 156 0 Index 194
252 176 48 Index 195
252 196 100 Index 196
252 216 152 Index 197
8 24 88 Index 198
12 36 104 Index 199
20 52 124 Index 200
28 68 140 Index 201
40 92 164 Index 202
56 120 188 Index 203
72 152 216 Index 204
100 172 224 Index 205
92 156 52 Index 206
108 176 64 Index 207
124 200 76 Index 208
144 224 92 Index 209
224 244 252 Index 210
200 236 248 Index 211
180 220 236 Index 212
132 188 216 Index 213
88 152 172 Index 214
244 0 244 Index 215
245 0 245 Index 216
246 0 246 Index 217
247 0 247 Index 218
248 0 248 Index 219
249 0 249 Index 220
250 0 250 Index 221
251 0 251 Index 222
252 0 252 Index 223
253 0 253 Index 224
254 0 254 Index 225
255 0 255 Index 226
76 24 8 Index 227
108 44 24 Index 228
144 72 52 Index 229
176 108 84 Index 230
210 146 126 Index 231
252 60 0 Index 232
252 84 0 Index 233
252 104 0 Index 234
252 124 0 Index 235
252 148 0 Index 236
252 172 0 Index 237
252 196 0 Index 238
64 0 0 Index 239
255 0 0 Index 240
48 48 0 Index 241
64 64 0 Index 242
80 80 0 Index 243
255 255 0 Index 244
32 68 112 Index 245
36 72 116 Index 246
40 76 120 Index 247
44 80 124 Index 248
48 84 128 Index 249
72 100 144 Index 250
100 132 168 Index 251
216 244 252 Index 252
96 128 164 Index 253
68 96 140 Index 254
255 255 255 Index 255
</pre>

Ttd-dos-palette-for-gimp

2012-04-16T07:53:24Z

Planetmaker: Replace with proper colour indices

Save paletted image files

2012-04-16T07:51:11Z

Planetmaker: Directly link to palette. Previously linked wiki page with palette has faulty entries.

This pagecovers how to apply a palette to a graphics file in several graphics editor. If your editor is not listed here and you know how to work with palettes using it, please add it here.

You find a range of palettes with and without action colours (which might be useful for conversions) for various graphics programmes on the [http://dev.openttdcoop.org/documents/1| DevZone]

== Adobe Photoshop ==
[[Image:Photoshop palette window with windows ttd palette.png|thumb|50%|Fig. 1: Photoshop palette window showing in this case the Windows palette]]
[[Image:Photoshop indexed color window.png|thumb|50%|Fig. 2: Photoshop indexed color window]]

In this subsection it is explained how to create a palette file and how to apply it using Adobe Photoshop (CS5 is used here, but identical or similar procedures apply in other versions of Photoshop). It is assumed that you have a clue about working with Photoshop.

=== Retreiving a palette file ===
You can use an existing graphics file that has the correct palette applied to retrieve the palette and save it to a separate file. This palette can then be applied to graphics files that don't have a palette. You can skip this part if you have [http://dev.openttdcoop.org/attachments/1749/photoshop-ttd-dos.act| downloaded a premade palette file].

# Open a graphics file of which you know it has the correct palette in Photoshop. Decoded NewGRFs (using GRFCodec) surely will have the correct palette applied.
# Go to Image > Mode > Color Table... The window from Fig. 1 will appear.
# Click Save... and store the palette file (*.act) somewhere on your computer.

=== Applying a palette from file ===
The Windows or DOS TTD palette must be applied to your graphics file for them to work in GRFCodec and NML. For the next steps we assume that you have a palette file (*.act) with the palette of your choice stored somewhere on your computer.

# Open a graphics file in Photoshop.
# Go to Image > Mode and check if RGB Color is checked. Select it if that is not the case, which will convert your graphics file to full-colour, maintaining the colours as they appear.
# Go to Image > Mode > Indexed Color... The window from Fig. 2 will appear.
# From the Palette drop-down, select Custom... The palette window (see Fig. 1) appears.
# Click Load... and browse the palette file. Click OK to close the palette window.
# In the indexed color window, you may select your choise of Dither. The dither will convert all colours that are in the graphics file but not in the palette to the palette colours. Either use the Diffusion dither (with preserving exact colors) or the Noise dither. Play around with the settings using the Preview to see the result and pick whatever looks best. If the sprites in the image file were drawn properly (using only palette colours), you should see no difference.
# Click OK to apply the palette file (and dither) to this image file. Note that this will flatten all layers (if any) in your graphics file.
# Save the file as (preferrably) a PNG image.

=== Important note on PCX files in Photoshop ===
Photoshop has a quirk in which palettes from PCX files are read and written backwards. This is no problem is you stay with pcx, but it is if you convert from pcx to png (and the other way round). Any such conversion will have the palette stored backwards in the target file, making it unusable by GRFCodec or NML. Note:
* You cannot use the palette file saved from a PCX file for a PNG file;
* You cannot use the palette file saved from a PNG file for a PCX file;
* When converting PCX <-> PNG, you must convert to RGB Color first and then back to Indexed Color, applying the palette file of your target file format (e.g. when converting to PNG, apply the palette retrieved from a PNG file).

== GIMP ==
[[Image:GIMP palette window.png|thumb|50%|Fig. 3: GIMP palette window]]
[[Image:GIMP import palette window.png|thumb|50%|Fig. 4: GIMP import pallete window showing the TTD Windows palette]]
[[Image:GIMP indexed color conversion window.png|thumb|50%|Fig. 5: GIMP indexed color conversion window]]

In this subsection it is explained how to create a palette file and how to apply it using the GNU Image Manipulation Program (2.6 is used here, but identical or similar procedures should apply in other versions). It is assumed that you have a clue about working with GIMP.

=== Download a palette file ===
In case of doubt you simply want to get the [http://dev.openttdcoop.org/attachments/1741/ttd-newgrf-dos.gpl| DOS palette]. See the above link to the DevZone for more options.

=== Import a palette file ===
Before you can use a palette in GIMP you must import it. You can import a palette form a file that has the correct palette applied or import a downloaded palette (*.gpl) file.

# Open a graphics file of which you know it has the correct palette in GIMP if you want to get the palette from that file (otherwise go to the next step). Decoded NewGRFs (using GRFCodec) surely will have the correct palette applied.
# Go to Windows > Dockable Dialogs > Palettes... The window from Fig. 3 with a list of builtin palettes will appear.
# Rightclick anywhere in the list with palettes and click Import Palette... from the context menu. The window from Fig 4. will appear.
# Now choose if you want to retrieve the palette from the opened image or if you want to import a palette from a palette file.
## Select Image below Select Source to get the palette from the current image file.
## Select Palette file below Select Source and browse to a *.gpl palette file to get the palette from that file.
# The palette will be shown. Give the palette a name and click Import. The TTD palette will now be added to the list of palettes.

=== Applying a palette ===
Make sure the palette you want to use is imported in GIMP (see above).

# Open a graphics file in GIMP.
# Go to Image > Mode and check if RGB is selected. Select it if that is not the case, which will convert your graphics file to full-colour, maintaining the colours as they appear.
# Go to Image > Mode > Indexed... The window from Fig. 5 will appear.
# Select Use custom palette and then select the TTD palette from the palette list (click on the button showing a palette).
# Make sure to '''uncheck''' Remove unused colors from colormap.
# In the same window, you may select your choise of Dithering. The dither will convert all colours that are in the graphics file but not in the palette to the palette colours. Play around with the settings to find the best result. If the sprites in the image file were drawn properly (using only palette colours), you should see no difference.
# Click Convert to apply the palette (and dither) to this image file.
# Save the file as (preferrably) a PNG image.

=== Saving a palette to file ===
If you want to share your imported palette, you must have a palette file.

# Exit GIMP to automatically save your palette(s).
# Reopen GIMP (and the palette window via Windows > Dockable Dialogs > Palettes if this is closed).
# Rightclick your palette in the palette window and choose Copy Palette Location. This copies the path to the palette file to the clipboard
# With GIMP open, get the clipboard contents and browse to the specified folder (usualy ~/.gimp-2.6/palettes).
# Copy or upload the *.gpl file with the palette from there.

Surely there must be an easier way to do this, but I haven't found that so far.

[[Category:Tutorials]]

ECS Vectors Translations - Machinery vector strings. Industries

2011-09-03T19:21:20Z

Planetmaker: typo

[[Category:ECS Translations]]
<pre>
// - Strings for industries names -
// Vehicles factory
1 * 25 04 0A FF 01 F0 D0 "ÞVehicles factory" 00
1 * 22 04 0A 82 01 F0 D0 "ÞAutomobilwerk" 00
1 * 28 04 0A 83 01 F0 D0 "ÞUsine d'automobiles" 00
1 * 33 04 0A 84 01 F0 D0 "ÞFábrica de automóviles" 00
1 * 46 04 0A 87 01 F0 D0 "ÞАвтомобильный завод" 00
1 * 44 04 0A 90 01 F0 D0 "ÞАўтамабільны завод" 00
1 * 23 04 0A A7 01 F0 D0 "Fabbrica di auto" 00
1 * 34 04 0A B7 01 F0 D0 "ÞFábrica automobilística" 00
1 * 30 04 0A 95 01 F0 D0 "ÞStrojírenský podnik" 00
1 * 25 04 0A BA 01 F0 D0 "Þ중장비 공장" 00
1 * 26 04 0A 9F 01 F0 D0 "ÞVoertuigenfabriek" 00
1 * 60 04 0A A4 01 F0 D0 "Þ\UE09A\14\UE09A\10\01gépjárműgyárat\UE09A\11Gépjárműgyár\UE09A\12" 00
// Shipyard
1 * 17 04 0A FF 01 F1 D0 "ÞShipyard" 00
1 * 14 04 0A 82 01 F1 D0 "ÞWerft" 00
1 * 23 04 0A 83 01 F1 D0 "ÞChantier naval" 00
1 * 19 04 0A 84 01 F1 D0 "ÞAstilleros" 00
1 * 19 04 0A 87 01 F1 D0 "ÞВерфь" 00
1 * 17 04 0A 90 01 F1 D0 "ÞВерф" 00
1 * 24 04 0A A7 01 F1 D0 "ÞCantiere navale" 00
1 * 18 04 0A B7 01 F1 D0 "ÞEstaleiro" 00
1 * 18 04 0A 95 01 F1 D0 "ÞLoděnice" 00
1 * 18 04 0A BA 01 F1 D0 "Þ조선소" 00
1 * 20 04 0A 9F 01 F1 D0 "ÞScheepswerf" 00
1 * 48 04 0A A4 01 F1 D0 "Þ\UE09A\14\UE09A\10\01hajógyárat\UE09A\11Hajógyár\UE09A\12" 00
// Bauxite mine
1 * 21 04 0A FF 01 F2 D0 "ÞBauxite mine" 00
1 * 21 04 0A 82 01 F2 D0 "ÞBauxitmine" 00
1 * 21 04 0A 87 01 F2 D0 "ÞБокситовый рудник" 00
// - Strings for industries descriptions -
// vehicles factory
1 * 59 04 0A FF 01 E0 D0 "ÞVehicles factory does not have special conditions." 00
1 * 62 04 0A 82 01 E0 D0 "ÞDas Automobilwerk hat keine besonderen Anforderungen." 00
1 * 66 04 0A 83 01 E0 D0 "ÞL'usine d'automobiles n'a aucune condition particulière." 00
1 * 86 04 0A 87 01 E0 D0 "ÞАвтомобильный завод не имеет ограничений." 00
1 * 82 04 0A 90 01 E0 D0 "ÞАўтамабільны завод не мае абмежаванняў." 00
1 * 75 04 0A A7 01 E0 D0 "ÞLe fabbriche di automezzi non hanno alcuna condizione particolare." 00
1 * 69 04 0A B7 01 E0 D0 "ÞFábricas automobilísticas não têm condições especiais." 00
1 * 69 04 0A 95 01 E0 D0 "ÞStrojírenský podnik nemá žádné zvláštní požadavky." 00
1 * 56 04 0A BA 01 E0 D0 "Þ중장비 공장은 특별한 조건이 없다." 00
1 * 88 04 0A B0 01 E0 D0 "ÞWytórnia Sprzętu Komunikacyjnego nie ma specjalnych wymagań lokalizacyjnych." 00
1 * 80 04 0A 9F 01 E0 D0 "ÞVoor het bouwen van voertuigfabrieken gelden geen speciale voorwaarden." 00
1 * 53 04 0A A4 01 E0 D0 "ÞGépjárműgyárat akárhol lehet építeni." 00
// steel mill
1 * 64 04 0A FF 01 E1 D0 "ÞSteel mill should be built on flat land far from towns." 00
1 * 86 04 0A 82 01 E1 D0 "ÞStahlwerk muss auf flachem Land und weit entfernt von Städten gebaut werden." 00
1 * 86 04 0A 83 01 E1 D0 "ÞSUne usine sidérurgique doit être bâtie sur terrain plain loin des villes." 00
1 * 93 04 0A 87 01 E1 D0 "ÞСталилитейный завод стрится вдали от городов." 00
1 * 101 04 0A 90 01 E1 D0 "ÞСталеліцейны завод будуецца ўдалечыні ад гарадоў." 00
1 * 94 04 0A A7 01 E1 D0 "ÞUn'industria siderurgica dev'essere costruita su terreno piano, lontano dalle città." 00
1 * 80 04 0A B7 01 E1 D0 "ÞSiderúrgicas devem ser construídas em terreno plano longe de cidades." 00
1 * 93 04 0A 95 01 E1 D0 "ÞOcelárna smí být postavena pouze na ploché zemi ve velké vzdálenosti od měst." 00
1 * 92 04 0A BA 01 E1 D0 "Þ제철소는 마을에서 멀리 떨어진 편평한 땅에 지어져야 합니다." 00
1 * 77 04 0A B0 01 E1 D0 "ÞHuta stali powinna być budowana zdala od miast na płaskim terenia." 00
1 * 81 04 0A 9F 01 E1 D0 "ÞHoogvens moeten op vlak land en ver van plaatsen vandaan worden gebouwd." 00
1 * 81 04 0A A4 01 E1 D0 "ÞAcélöntőt lapos területen, településektől távol lehet építeni." 00
// iron ore mine
1 * 136 04 0A FF 01 E2 D0 "ÞIron ore mine is prospected with 78% probability near other iron ore mines, with 25% probability far from other iron ore mines." 00
1 * 145 04 0A 82 01 E2 D0 "ÞEisenerzmine wird mit 78% Wahrscheinlichkeit in der Nähe und mit 25% Wahrscheinlichkeit weit entfernt von anderen Eisenerzminen gebaut." 00
1 * 133 04 0A 83 01 E2 D0 "ÞUne mine de fer est prospectée avec le 78% de probabilité près d'autres mines de fer, et avec le 25% loin d'autres mines." 00
1 * 223 04 0A 87 01 E2 D0 "ÞГеологическая разведка обнаруживает залежи руды с вероятностью 78% вблизи других шахт, с вероятностью 25% вдали от них." 00
1 * 224 04 0A 90 01 E2 D0 "ÞГеалагічная разведка выяўляе залежы руды з верагоднасцю 78% паблізу ад іншых шахтаў, з верагоднасцю 25% удалечыні ад іх." 00
1 * 130 04 0A A7 01 E2 D0 "ÞPuoi trovare un giacimento di ferro col 78% delle probabilità se vicino ad altre miniere di ferro, e col 25% se lontano." 00
1 * 155 04 0A B7 01 E2 D0 "ÞMinas de ferro são pesquisadas com 78% de probabilidade perto de outras minas de ferro e com 25% de probabilidade longe de outras minas de ferro." 00
1 * 210 04 0A 95 01 E2 D0 "ÞLožisko železné rudy bude nalezeno s 78%-ní úspěšností poblíž existujících železnorudných dolů a s 25%-ní úspěšností ve velké vzdálenosti od existujících železnorudných dolů." 00
1 * 155 04 0A BA 01 E2 D0 "Þ철 광산은 다른 철 광산의 근처에서 78%의 확률로 시굴되고, 멀리 떨어진 철 광산에서는 25%의 확률로 시굴된다." 00
1 * 106 04 0A B0 01 E2 D0 "ÞKopalnia rudy żelaza powstanie z 75% prawdopodobieństwem w pobliżu innej kopalni rudy żelaza." 00
1 * 133 04 0A 9F 01 E2 D0 "ÞDe kans op het succesvol bouwen van een ijzerertsmijn dichtbij bestaande ijzerertsmijn(en) is 78% en 25% in andere gevallen." 00
1 * 181 04 0A A4 01 E2 D0 "ÞKutatás támogatása esetén vasércbánya 78% valószínűséggel létesül más vasércbánya közelében, 25% valószínűséggel pedig más vasércbányáktól távol." 00
// Ship yard
1 * 33 04 0A FF 01 E3 D0 "ÞReserved for future use." 00
1 * 33 04 0A FF 01 E3 D0 "ÞReserviert für zukünftigen Gebrauch." 00
1 * 45 04 0A 83 01 E3 D0 "ÞRéservé à une utilisation future." 00
1 * 30 04 0A 87 01 E3 D0 "ÞНедоступен." 00
1 * 30 04 0A 90 01 E3 D0 "ÞНедаступны." 00
1 * 34 04 0A A7 01 E3 D0 "ÞRiservato per usi futuri." 00
1 * 45 04 0A 95 01 E3 D0 "ÞRezervováno pro budoucí použití." 00
1 * 45 04 0A BA 01 E3 D0 "Þ미래에 사용하기위해 예약." 00
1 * 54 04 0A B0 01 E3 D0 "ÞZastrzeżone do zastosowania w przyszłości." 00
1 * 46 04 0A 9F 01 E3 D0 "ÞGereserveerd voor toekomstig gebruik." 00
1 * 43 04 0A A4 01 E3 D0 "ÞFenntartva későbbi használatra." 00
// Bauxite mine
1 * 134 04 0A FF 01 E4 D0 "ÞBauxite mine is prospected with 78% probability near other bauxite mines, with 25% probability far from other bauxite mines." 00
1 * 134 04 0A 82 01 E4 D0 "ÞEine Bauxitmine zu erkunden ist mit 78% Wahrscheinlichkeit nahe anderen Bauxitminen und mit 25% Wahrscheinlichkeit von ihnen entfernt erfolgreich." 00
1 * 223 04 0A 87 01 E4 D0 "ÞГеологическая разведка обнаруживает залежи бокситов с вероятностью 78% вблизи других шахт, с вероятностью 25% вдали от них." 00
// - Industry window texts -
// Bauxite mine
1 * 88 04 0A FF 01 DC D0 "Þ\90Bauxites left: \UE07B tonnes (\80 / \80)\nLevel: \UE07C% (\80)\nRemain: \UE07C months (0-undef)" 00
1 * 111 04 0A 87 01 DC D0 "Þ\90Залежи бокситов: \UE07B тонн (\80 / \80)\nУр-нь: \UE07C% (\80)\nСнос: \UE07C мес. (0-неизв.)" 00
// vehicles factory
1 * 53 04 0A FF 01 DD D0 "Þ\90Lines: \UE07C (\80)\nRemain: \UE07C months (0-undef)" 00
1 * 60 04 0A 82 01 DD D0 "Þ\90Montagelinien: \UE07C (\80)\nRest: \UE07C Monate (0-undef.)" 00
1 * 57 04 0A 83 01 DD D0 "Þ\90Lignes: \UE07C (\80)\nRestant: \UE07C mois (0=indéfini)" 00
1 * 67 04 0A 87 01 DD D0 "Þ\90Линий: \UE07C (\80)\nСнос: \UE07C мес. (0-неизв.)" 00
1 * 67 04 0A 90 01 DD D0 "Þ\90Ліній: \UE07C (\80)\nЗнос: \UE07C мес. (0-невяд.)" 00
1 * 61 04 0A A7 01 DD D0 "Þ\90Linee: \UE07C (\80)\nRimanenti: \UE07C mesi (0 = indefinito)" 00
1 * 58 04 0A B7 01 DD D0 "Þ\90Linhas: \UE07C (\80)\nRestante: \UE07C meses (0-não def)" 00
1 * 77 04 0A 95 01 DD D0 "Þ\90Linek v provozu: \UE07C (\80)\nUzavře se za: \UE07C měsíců (0-neurčito)" 00
1 * 61 04 0A BA 01 DD D0 "Þ\90생산 라인: \UE07C (\80)\n\UE07C 달 남음 (0-미정의)" 00
1 * 95 04 0A B0 01 DD D0 "Þ\90Taśmy produkcyjne: \UE07C (\80)\nDo upadłości zotało: \UE07C miesięcy (0-niezdefiniowano)" 00
1 * 70 04 0A 9F 01 DD D0 "Þ\90Productielijnen: \UE07C (\80)\nResterend: \UE07C maanden (0-oneindig)" 00
1 * 88 04 0A A4 01 DD D0 "Þ\90Gyártósorok: \UE07C (\80)\nHátralévő idő: \UE07C hónap (0 = nincs meghatározva)" 00
// iron ore mine
1 * 83 04 0A FF 01 DE D0 "Þ\90Ore left: \UE07B tonnes (\80 / \80)\nLevel: \UE07C% (\80)\nRemain: \UE07C months (0-undef)" 00
1 * 84 04 0A 82 01 DE D0 "Þ\90Erzreserve: \UE07B Tonnen (\80 / \80)\nLevel: \UE07C% (\80)\nRest: \UE07C Monate (0-undef.)" 00
1 * 95 04 0A 83 01 DE D0 "Þ\90Minéral restant: \UE07B tonnes (\80 / \80)\nNiveau: \UE07C% (\80)\nRestant: \UE07C mois (0=indéfini)" 00
1 * 111 04 0A 87 01 DE D0 "Þ\90Залежи руды: \UE07B тонн (\80 / \80)\nУр-нь: \UE07C% (\80)\nСнос: \UE07C мес. (0-неизв.)" 00
1 * 111 04 0A 90 01 DE D0 "Þ\90Залежы руды: \UE07B тон (\80 / \80)\nУзр-нь: \UE07C% (\80)\nЗнос: \UE07C мес. (0-невяд.)" 00
1 * 107 04 0A A7 01 DE D0 "Þ\90Minerale rimanente: \UE07B tonnellate (\80 / \80)\nLivello: \UE07C% (\80)\nRimanenti: \UE07C mesi (0 = indefinito)" 00
1 * 100 04 0A B7 01 DE D0 "Þ\90Minério restante: \UE07B toneladas (\80 / \80)\nNível: \UE07C% (\80)\nRestante: \UE07C meses (0-não def)" 00
1 * 111 04 0A 95 01 DE D0 "Þ\90Železné rudy zbývá: \UE07B tun (\80 / \80)\nÚroveň: \UE07C% (\80)\nUzavře se za: \UE07C měsíců (0-neurčito)" 00
1 * 84 04 0A BA 01 DE D0 "Þ\90광석 \UE07B톤 남음 (\80 / \80)\n레벨: \UE07C% (\80)\n\UE07C 달 남음 (0-미정의)" 00
1 * 105 04 0A B0 01 DE D0 "Þ\90Pozostało rudy: \UE07B ton (\80 / \80)\nPoziom: \UE07C% (\80)\nPozostało: \UE07C miesięcy (0-niezdefiniowano)" 00
1 * 100 04 0A 9F 01 DE D0 "Þ\90Resterende ijzererts: \UE07B ton (\80 / \80)\nNiveau: \UE07C% (\80)\nResterend: \UE07C maanden (0-oneindig)" 00
1 * 121 04 0A A4 01 DE D0 "Þ\90Hátralévő vasérc: \UE07B tonna (\80 / \80)\nSzint: \UE07C% (\80)\nHátralévő idő: \UE07C hónap (0 = nincs meghatározva)" 00
// steel mill
1 * 92 04 0A FF 01 DF D0 "Þ\90Furnaces on: \UE07C\nRemain: \UE07C months (0-undef)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 100 04 0A 82 01 DF D0 "Þ\90Hochöfen in Betrieb: \UE07C\nRest: \UE07C Monate (0-undef.)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 101 04 0A 83 01 DF D0 "Þ\90Fours en fonction: \UE07C\nRestant: \UE07C mois (0=indéfini)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 137 04 0A 87 01 DF D0 "Þ\90Используется печей: \UE07C\nСнос: \UE07C мес. (0-неизв.)\nВыплавка: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 145 04 0A 90 01 DF D0 "Þ\90Выкарыстоўваецца печаў: \UE07C\nЗнос: \UE07C мес. (0-невяд.)\nВыплаўка: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 103 04 0A A7 01 DF D0 "Þ\90Fornaci attive: \UE07C\nRimanenti: \UE07C mesi (0 = indefinito)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 101 04 0A B7 01 DF D0 "Þ\90Fornalhas acesas: \UE07C\nRestante: \UE07C meses (0-não def)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 113 04 0A 95 01 DF D0 "Þ\90Pecí v provozu: \UE07C\nUzavře se za: \UE07C měsíců (0-neurčito)\nVýroba: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 99 04 0A BA 01 DF D0 "Þ\90용광로 가동: \UE07C\n\UE07C 달 남음 (0-미정의)\n생산: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 140 04 0A B0 01 DF D0 "Þ\90Włączono wielkich pieców: \UE07C\nPozostało do zamknięcia: \UE07C miesięcy (0-niezdefiniowane)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 106 04 0A 9F 01 DF D0 "Þ\90Hoogovens aan: \UE07C\nResterend: \UE07C maanden (0-oneindig)\nProductie: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 132 04 0A A4 01 DF D0 "Þ\90Bekapcsolt kazánok: \UE07C\nHátralévő idő: \UE07C hónap (0 = nincs meghatározva)\nTermelés: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
</pre>

ECS Vectors Translations - Machinery vector strings. Industries

2011-09-03T19:20:35Z

Planetmaker: German translations for Bauxite mines

[[Category:ECS Translations]]
<pre>
// - Strings for industries names -
// Vehicles factory
1 * 25 04 0A FF 01 F0 D0 "ÞVehicles factory" 00
1 * 22 04 0A 82 01 F0 D0 "ÞAutomobilwerk" 00
1 * 28 04 0A 83 01 F0 D0 "ÞUsine d'automobiles" 00
1 * 33 04 0A 84 01 F0 D0 "ÞFábrica de automóviles" 00
1 * 46 04 0A 87 01 F0 D0 "ÞАвтомобильный завод" 00
1 * 44 04 0A 90 01 F0 D0 "ÞАўтамабільны завод" 00
1 * 23 04 0A A7 01 F0 D0 "Fabbrica di auto" 00
1 * 34 04 0A B7 01 F0 D0 "ÞFábrica automobilística" 00
1 * 30 04 0A 95 01 F0 D0 "ÞStrojírenský podnik" 00
1 * 25 04 0A BA 01 F0 D0 "Þ중장비 공장" 00
1 * 26 04 0A 9F 01 F0 D0 "ÞVoertuigenfabriek" 00
1 * 60 04 0A A4 01 F0 D0 "Þ\UE09A\14\UE09A\10\01gépjárműgyárat\UE09A\11Gépjárműgyár\UE09A\12" 00
// Shipyard
1 * 17 04 0A FF 01 F1 D0 "ÞShipyard" 00
1 * 14 04 0A 82 01 F1 D0 "ÞWerft" 00
1 * 23 04 0A 83 01 F1 D0 "ÞChantier naval" 00
1 * 19 04 0A 84 01 F1 D0 "ÞAstilleros" 00
1 * 19 04 0A 87 01 F1 D0 "ÞВерфь" 00
1 * 17 04 0A 90 01 F1 D0 "ÞВерф" 00
1 * 24 04 0A A7 01 F1 D0 "ÞCantiere navale" 00
1 * 18 04 0A B7 01 F1 D0 "ÞEstaleiro" 00
1 * 18 04 0A 95 01 F1 D0 "ÞLoděnice" 00
1 * 18 04 0A BA 01 F1 D0 "Þ조선소" 00
1 * 20 04 0A 9F 01 F1 D0 "ÞScheepswerf" 00
1 * 48 04 0A A4 01 F1 D0 "Þ\UE09A\14\UE09A\10\01hajógyárat\UE09A\11Hajógyár\UE09A\12" 00
// Bauxite mine
1 * 21 04 0A FF 01 F2 D0 "ÞBauxite mine" 00
1 * 21 04 0A 82 01 F2 D0 "ÞBauxitmine" 00
1 * 21 04 0A 87 01 F2 D0 "ÞБокситовый рудник" 00
// - Strings for industries descriptions -
// vehicles factory
1 * 59 04 0A FF 01 E0 D0 "ÞVehicles factory does not have special conditions." 00
1 * 62 04 0A 82 01 E0 D0 "ÞDas Automobilwerk hat keine besonderen Anforderungen." 00
1 * 66 04 0A 83 01 E0 D0 "ÞL'usine d'automobiles n'a aucune condition particulière." 00
1 * 86 04 0A 87 01 E0 D0 "ÞАвтомобильный завод не имеет ограничений." 00
1 * 82 04 0A 90 01 E0 D0 "ÞАўтамабільны завод не мае абмежаванняў." 00
1 * 75 04 0A A7 01 E0 D0 "ÞLe fabbriche di automezzi non hanno alcuna condizione particolare." 00
1 * 69 04 0A B7 01 E0 D0 "ÞFábricas automobilísticas não têm condições especiais." 00
1 * 69 04 0A 95 01 E0 D0 "ÞStrojírenský podnik nemá žádné zvláštní požadavky." 00
1 * 56 04 0A BA 01 E0 D0 "Þ중장비 공장은 특별한 조건이 없다." 00
1 * 88 04 0A B0 01 E0 D0 "ÞWytórnia Sprzętu Komunikacyjnego nie ma specjalnych wymagań lokalizacyjnych." 00
1 * 80 04 0A 9F 01 E0 D0 "ÞVoor het bouwen van voertuigfabrieken gelden geen speciale voorwaarden." 00
1 * 53 04 0A A4 01 E0 D0 "ÞGépjárműgyárat akárhol lehet építeni." 00
// steel mill
1 * 64 04 0A FF 01 E1 D0 "ÞSteel mill should be built on flat land far from towns." 00
1 * 86 04 0A 82 01 E1 D0 "ÞStahlwerk muss auf flachem Land und weit entfernt von Städten gebaut werden." 00
1 * 86 04 0A 83 01 E1 D0 "ÞSUne usine sidérurgique doit être bâtie sur terrain plain loin des villes." 00
1 * 93 04 0A 87 01 E1 D0 "ÞСталилитейный завод стрится вдали от городов." 00
1 * 101 04 0A 90 01 E1 D0 "ÞСталеліцейны завод будуецца ўдалечыні ад гарадоў." 00
1 * 94 04 0A A7 01 E1 D0 "ÞUn'industria siderurgica dev'essere costruita su terreno piano, lontano dalle città." 00
1 * 80 04 0A B7 01 E1 D0 "ÞSiderúrgicas devem ser construídas em terreno plano longe de cidades." 00
1 * 93 04 0A 95 01 E1 D0 "ÞOcelárna smí být postavena pouze na ploché zemi ve velké vzdálenosti od měst." 00
1 * 92 04 0A BA 01 E1 D0 "Þ제철소는 마을에서 멀리 떨어진 편평한 땅에 지어져야 합니다." 00
1 * 77 04 0A B0 01 E1 D0 "ÞHuta stali powinna być budowana zdala od miast na płaskim terenia." 00
1 * 81 04 0A 9F 01 E1 D0 "ÞHoogvens moeten op vlak land en ver van plaatsen vandaan worden gebouwd." 00
1 * 81 04 0A A4 01 E1 D0 "ÞAcélöntőt lapos területen, településektől távol lehet építeni." 00
// iron ore mine
1 * 136 04 0A FF 01 E2 D0 "ÞIron ore mine is prospected with 78% probability near other iron ore mines, with 25% probability far from other iron ore mines." 00
1 * 145 04 0A 82 01 E2 D0 "ÞEisenerzmine wird mit 78% Wahrscheinlichkeit in der Nähe und mit 25% Wahrscheinlichkeit weit entfernt von anderen Eisenerzminen gebaut." 00
1 * 133 04 0A 83 01 E2 D0 "ÞUne mine de fer est prospectée avec le 78% de probabilité près d'autres mines de fer, et avec le 25% loin d'autres mines." 00
1 * 223 04 0A 87 01 E2 D0 "ÞГеологическая разведка обнаруживает залежи руды с вероятностью 78% вблизи других шахт, с вероятностью 25% вдали от них." 00
1 * 224 04 0A 90 01 E2 D0 "ÞГеалагічная разведка выяўляе залежы руды з верагоднасцю 78% паблізу ад іншых шахтаў, з верагоднасцю 25% удалечыні ад іх." 00
1 * 130 04 0A A7 01 E2 D0 "ÞPuoi trovare un giacimento di ferro col 78% delle probabilità se vicino ad altre miniere di ferro, e col 25% se lontano." 00
1 * 155 04 0A B7 01 E2 D0 "ÞMinas de ferro são pesquisadas com 78% de probabilidade perto de outras minas de ferro e com 25% de probabilidade longe de outras minas de ferro." 00
1 * 210 04 0A 95 01 E2 D0 "ÞLožisko železné rudy bude nalezeno s 78%-ní úspěšností poblíž existujících železnorudných dolů a s 25%-ní úspěšností ve velké vzdálenosti od existujících železnorudných dolů." 00
1 * 155 04 0A BA 01 E2 D0 "Þ철 광산은 다른 철 광산의 근처에서 78%의 확률로 시굴되고, 멀리 떨어진 철 광산에서는 25%의 확률로 시굴된다." 00
1 * 106 04 0A B0 01 E2 D0 "ÞKopalnia rudy żelaza powstanie z 75% prawdopodobieństwem w pobliżu innej kopalni rudy żelaza." 00
1 * 133 04 0A 9F 01 E2 D0 "ÞDe kans op het succesvol bouwen van een ijzerertsmijn dichtbij bestaande ijzerertsmijn(en) is 78% en 25% in andere gevallen." 00
1 * 181 04 0A A4 01 E2 D0 "ÞKutatás támogatása esetén vasércbánya 78% valószínűséggel létesül más vasércbánya közelében, 25% valószínűséggel pedig más vasércbányáktól távol." 00
// Ship yard
1 * 33 04 0A FF 01 E3 D0 "ÞReserved for future use." 00
1 * 33 04 0A FF 01 E3 D0 "ÞReserviert für zukünftigen Gebrauch." 00
1 * 45 04 0A 83 01 E3 D0 "ÞRéservé à une utilisation future." 00
1 * 30 04 0A 87 01 E3 D0 "ÞНедоступен." 00
1 * 30 04 0A 90 01 E3 D0 "ÞНедаступны." 00
1 * 34 04 0A A7 01 E3 D0 "ÞRiservato per usi futuri." 00
1 * 45 04 0A 95 01 E3 D0 "ÞRezervováno pro budoucí použití." 00
1 * 45 04 0A BA 01 E3 D0 "Þ미래에 사용하기위해 예약." 00
1 * 54 04 0A B0 01 E3 D0 "ÞZastrzeżone do zastosowania w przyszłości." 00
1 * 46 04 0A 9F 01 E3 D0 "ÞGereserveerd voor toekomstig gebruik." 00
1 * 43 04 0A A4 01 E3 D0 "ÞFenntartva későbbi használatra." 00
// Bauxite mine
1 * 134 04 0A FF 01 E4 D0 "ÞBauxite mine is prospected with 78% probability near other bauxite mines, with 25% probability far from other bauxite mines." 00
1 * 134 04 0A 82 01 E4 D0 "ÞEine Bauxitemine zu erkunden ist mit 78% Wahrscheinlichkeit nahe anderen Bauxitminen und mit 25% Wahrscheinlichkeit von ihnen entfernt erfolgreich." 00
1 * 223 04 0A 87 01 E4 D0 "ÞГеологическая разведка обнаруживает залежи бокситов с вероятностью 78% вблизи других шахт, с вероятностью 25% вдали от них." 00
// - Industry window texts -
// Bauxite mine
1 * 88 04 0A FF 01 DC D0 "Þ\90Bauxites left: \UE07B tonnes (\80 / \80)\nLevel: \UE07C% (\80)\nRemain: \UE07C months (0-undef)" 00
1 * 111 04 0A 87 01 DC D0 "Þ\90Залежи бокситов: \UE07B тонн (\80 / \80)\nУр-нь: \UE07C% (\80)\nСнос: \UE07C мес. (0-неизв.)" 00
// vehicles factory
1 * 53 04 0A FF 01 DD D0 "Þ\90Lines: \UE07C (\80)\nRemain: \UE07C months (0-undef)" 00
1 * 60 04 0A 82 01 DD D0 "Þ\90Montagelinien: \UE07C (\80)\nRest: \UE07C Monate (0-undef.)" 00
1 * 57 04 0A 83 01 DD D0 "Þ\90Lignes: \UE07C (\80)\nRestant: \UE07C mois (0=indéfini)" 00
1 * 67 04 0A 87 01 DD D0 "Þ\90Линий: \UE07C (\80)\nСнос: \UE07C мес. (0-неизв.)" 00
1 * 67 04 0A 90 01 DD D0 "Þ\90Ліній: \UE07C (\80)\nЗнос: \UE07C мес. (0-невяд.)" 00
1 * 61 04 0A A7 01 DD D0 "Þ\90Linee: \UE07C (\80)\nRimanenti: \UE07C mesi (0 = indefinito)" 00
1 * 58 04 0A B7 01 DD D0 "Þ\90Linhas: \UE07C (\80)\nRestante: \UE07C meses (0-não def)" 00
1 * 77 04 0A 95 01 DD D0 "Þ\90Linek v provozu: \UE07C (\80)\nUzavře se za: \UE07C měsíců (0-neurčito)" 00
1 * 61 04 0A BA 01 DD D0 "Þ\90생산 라인: \UE07C (\80)\n\UE07C 달 남음 (0-미정의)" 00
1 * 95 04 0A B0 01 DD D0 "Þ\90Taśmy produkcyjne: \UE07C (\80)\nDo upadłości zotało: \UE07C miesięcy (0-niezdefiniowano)" 00
1 * 70 04 0A 9F 01 DD D0 "Þ\90Productielijnen: \UE07C (\80)\nResterend: \UE07C maanden (0-oneindig)" 00
1 * 88 04 0A A4 01 DD D0 "Þ\90Gyártósorok: \UE07C (\80)\nHátralévő idő: \UE07C hónap (0 = nincs meghatározva)" 00
// iron ore mine
1 * 83 04 0A FF 01 DE D0 "Þ\90Ore left: \UE07B tonnes (\80 / \80)\nLevel: \UE07C% (\80)\nRemain: \UE07C months (0-undef)" 00
1 * 84 04 0A 82 01 DE D0 "Þ\90Erzreserve: \UE07B Tonnen (\80 / \80)\nLevel: \UE07C% (\80)\nRest: \UE07C Monate (0-undef.)" 00
1 * 95 04 0A 83 01 DE D0 "Þ\90Minéral restant: \UE07B tonnes (\80 / \80)\nNiveau: \UE07C% (\80)\nRestant: \UE07C mois (0=indéfini)" 00
1 * 111 04 0A 87 01 DE D0 "Þ\90Залежи руды: \UE07B тонн (\80 / \80)\nУр-нь: \UE07C% (\80)\nСнос: \UE07C мес. (0-неизв.)" 00
1 * 111 04 0A 90 01 DE D0 "Þ\90Залежы руды: \UE07B тон (\80 / \80)\nУзр-нь: \UE07C% (\80)\nЗнос: \UE07C мес. (0-невяд.)" 00
1 * 107 04 0A A7 01 DE D0 "Þ\90Minerale rimanente: \UE07B tonnellate (\80 / \80)\nLivello: \UE07C% (\80)\nRimanenti: \UE07C mesi (0 = indefinito)" 00
1 * 100 04 0A B7 01 DE D0 "Þ\90Minério restante: \UE07B toneladas (\80 / \80)\nNível: \UE07C% (\80)\nRestante: \UE07C meses (0-não def)" 00
1 * 111 04 0A 95 01 DE D0 "Þ\90Železné rudy zbývá: \UE07B tun (\80 / \80)\nÚroveň: \UE07C% (\80)\nUzavře se za: \UE07C měsíců (0-neurčito)" 00
1 * 84 04 0A BA 01 DE D0 "Þ\90광석 \UE07B톤 남음 (\80 / \80)\n레벨: \UE07C% (\80)\n\UE07C 달 남음 (0-미정의)" 00
1 * 105 04 0A B0 01 DE D0 "Þ\90Pozostało rudy: \UE07B ton (\80 / \80)\nPoziom: \UE07C% (\80)\nPozostało: \UE07C miesięcy (0-niezdefiniowano)" 00
1 * 100 04 0A 9F 01 DE D0 "Þ\90Resterende ijzererts: \UE07B ton (\80 / \80)\nNiveau: \UE07C% (\80)\nResterend: \UE07C maanden (0-oneindig)" 00
1 * 121 04 0A A4 01 DE D0 "Þ\90Hátralévő vasérc: \UE07B tonna (\80 / \80)\nSzint: \UE07C% (\80)\nHátralévő idő: \UE07C hónap (0 = nincs meghatározva)" 00
// steel mill
1 * 92 04 0A FF 01 DF D0 "Þ\90Furnaces on: \UE07C\nRemain: \UE07C months (0-undef)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 100 04 0A 82 01 DF D0 "Þ\90Hochöfen in Betrieb: \UE07C\nRest: \UE07C Monate (0-undef.)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 101 04 0A 83 01 DF D0 "Þ\90Fours en fonction: \UE07C\nRestant: \UE07C mois (0=indéfini)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 137 04 0A 87 01 DF D0 "Þ\90Используется печей: \UE07C\nСнос: \UE07C мес. (0-неизв.)\nВыплавка: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 145 04 0A 90 01 DF D0 "Þ\90Выкарыстоўваецца печаў: \UE07C\nЗнос: \UE07C мес. (0-невяд.)\nВыплаўка: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 103 04 0A A7 01 DF D0 "Þ\90Fornaci attive: \UE07C\nRimanenti: \UE07C mesi (0 = indefinito)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 101 04 0A B7 01 DF D0 "Þ\90Fornalhas acesas: \UE07C\nRestante: \UE07C meses (0-não def)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 113 04 0A 95 01 DF D0 "Þ\90Pecí v provozu: \UE07C\nUzavře se za: \UE07C měsíců (0-neurčito)\nVýroba: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 99 04 0A BA 01 DF D0 "Þ\90용광로 가동: \UE07C\n\UE07C 달 남음 (0-미정의)\n생산: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 140 04 0A B0 01 DF D0 "Þ\90Włączono wielkich pieców: \UE07C\nPozostało do zamknięcia: \UE07C miesięcy (0-niezdefiniowane)\nProd: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 106 04 0A 9F 01 DF D0 "Þ\90Hoogovens aan: \UE07C\nResterend: \UE07C maanden (0-oneindig)\nProductie: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
1 * 132 04 0A A4 01 DF D0 "Þ\90Bekapcsolt kazánok: \UE07C\nHátralévő idő: \UE07C hónap (0 = nincs meghatározva)\nTermelés: (\UE07C, \UE07C, \UE07C, \UE07C, \UE07C, \UE07C)" 00
</pre>

Tutorials

2011-08-28T06:15:44Z

Planetmaker: Add Link to (stump) of tutorial on how to use 3dsmax

== Playing OpenTTD and TTDPatch ==

* [[PreSignalsTutorial]]: How to use pre-signals

== Developing NewGRFs for OpenTTD and TTDPatch ==

* [[GRFTutorial|NFO Tutorial]]: How to make NewGRFs using NFO (under construction)
* [[NMLTutorial|NML Tutorial]]: How to make NewGRFs using the NewGRF Meta Language (NML)

== General sprite drawing ==
* [[DrawingSprites]]: How to draw new graphics
* [[Creating_new_Sprites_with_3dsMax|Using 3dsmax]]: Creating sprites using 3DSMax

Tutorials

2011-08-28T06:05:31Z

Planetmaker: add sections

MediaWiki:Sidebar

2011-08-28T06:03:08Z

Planetmaker: internal links work w/o ]] and [[

MediaWiki:Sidebar

2011-08-28T06:01:06Z

Planetmaker: Add link to tutorial overview page

NMLTutorial/Parameters

2011-08-27T21:51:02Z

Planetmaker: made clearer that the <num> for parameters is often optional

{{NMLTutorial}}

== Introduction ==
NewGRF Parameters in NML are part of the grf block
<pre>grf {
grfid: "NML\FF";
name: string(STR_GRF_NAME);
desc: string(STR_GRF_DESC);
version: 1;
min_compatible_version: 0;
param <num> {
<name> {
name: string(STR_PARAM_NAME_ECONOMIES);
desc: string(STR_PARAM_DESC_ECONOMIES);
<specifics>
}
}
}
</pre>

Where <code>name</code> is the name the parameter is referenced further within the grf to read this parameter. <num> is the number of this parameter. The <num> parameter is optional and not needed when parameters are not re-ordered throughout versions. It can be used to keep the meaning of a specific NewGRF parameter while re-ordering the code. The meaning of a NewGRF parameter should should remain constant throughout versions of the same NewGRF or the NewGRF might become incompatible with previous versions of the same NewGRF (thus you'd need to change min_compatible_version if you change the meaning of the parameters at <num>.

== Parameter types ==
NML knows three different types of parameters, boolean, numeric ones and enumerations:

=== Boolean parameter ===
The boolean parameter is the easiest as it requires no further definitions besides the name and description. Optionally a single parameter can contain several boolean parameter values, each using a single bit, thus saving in the number of externally visible NewGRF parameters.
<pre>
param 3 { // 3rd parameter of the NewGRF
param_bool_1 { // 1st boolean value
name: string(STR_PARAM_NAME_DEBUG);
desc: string(STR_PARAM_DESC_DEBUG);
type: bool;
bit: 1; // uses 1st bit
}
param_bool_2 { // 2nd boolean value
name: string(STR_PARAM_NAME_DEBUG);
desc: string(STR_PARAM_DESC_DEBUG);
type: bool;
bit: 2; // uses 2nd bit
}
}
</pre>

=== Numeric parameter ===

The numeric parameter allows to directly input an (integer) number. It needs to have a minimum and maximum value given and optionally - and usually a good idea - a default value for the parameter:
<pre>
param 1 {
param_depot_year {
type: int;
name: string(STR_PARAM_DEPOTYEAR);
desc: string(STR_PARAM_DEPOTYEAR_DESC);
min_value: 0;
max_value: 5000000;
def_value: 1975;
}
}
</pre>

=== Enumeration parameter ===

The enumeration parameter basically is a numeric parameter where the single values have (additionally) a string attached to describe their meaning. Not all values need a string description, but it usually is a good idea to do this consistently
<pre>
param 0 {
economy {
name: string(STR_PARAM_NAME_ECONOMIES);
desc: string(STR_PARAM_DESC_ECONOMIES);
min_value: 0;
max_value: 1;
def_value: 0;
names: {
0: string(STR_PARAM_VALUE_ECONOMIES_TEST_ECONOMY);
1: string(STR_PARAM_VALUE_ECONOMIES_HARD_ECONOMY);
};
}
}
</pre>

MediaWiki:Common.css

2011-08-27T21:18:46Z

Planetmaker: separate style templates for <pre> tag: example, pseudo and small (=max height 200px)

/* CSS placed here will be applied to all skins */

table.wikitable td, th {
border: 1px solid #CCCCCC;
padding: 0;
}
table {
border-collapse: collapse;
empty-cells: show;
}

td, th {
border: 1px solid #CCCCCC;
padding: 0px 5px;
}

code {
color: darkgreen;
}

pre {
color: darkblue;
white-space: pre-wrap
}
pre.example {
color: darkblue;
}
pre.pseudo {
color: black;
}
pre.small {
max-height: 200px;
overflow:scroll;
}

/* Pad Google AdSense box in portlet in sidebar */
#p-googleadsense .pBody {
padding-top: 5px;
text-align: center;
}

MediaWiki:Common.css

2011-08-27T20:03:31Z

Planetmaker: add colours to default code and pre tags

/* CSS placed here will be applied to all skins */

table.wikitable td, th {
border: 1px solid #CCCCCC;
padding: 0;
}
table {
border-collapse: collapse;
empty-cells: show;
}

td, th {
border: 1px solid #CCCCCC;
padding: 0px 5px;
}

code {
color: darkgreen;
}

pre {
color: darkblue;
}

/* Pad Google AdSense box in portlet in sidebar */
#p-googleadsense .pBody {
padding-top: 5px;
text-align: center;
}

NMLTutorial/Installation

2011-08-27T06:03:40Z

Planetmaker: /* Text editor */ add a linux and osx editor

{{NMLTutorial}}

NML is written in Python and therefore can be made to run on every operating system that can run Python. This includes the popular operating sytems Linux, MacOS and Windows. Below you'll find a description on how to install NML and how to use the command-line NML program on your operating system (MacOS description currently missing, as I don't have that, but please add it).

{{Note|The NML Documentation reflects the latest state of the NML program. Make sure to update your NML regularly, especially if you find something not working that should work according to the documentation.}}

== Linux ==
NML requires Python, the Python Image Library and PLY (Python Lex-Yacc). These three things are best installed from your package manager. If you're looking to compiling NML yourself, you also need the Python Setuptools. Note that NML currently only runs on Python 2.5 through 2.7, but not 3.x. Look for the following in your package manager:
* python (you might already have this)
* python-imaging (pil)
* python-ply
* python-setuptools

=== Installing NML as precompiled binary (recommended) ===
The latest version of NML is available as RPM package from the #openttdcoop DevZone. You can find it here: http://bundles.openttdcoop.org/nml/nightlies/LATEST/rpms/. This package is known to work on openSUSE and Red Hat (including Fedora and CentOS) distributions.

You can use the terminal to install this package through your package manager (make sure to run it as superuser). For example on Fedora:

sudo bash
yum install <nowiki>http://bundles.openttdcoop.org/nml/nightlies/LATEST/rpms/nml-rXXXX-suseYYYY.noarch.rpm</nowiki>

Make sure to replace XXXX and YYYY in the url with the actual version numbers you found via the link above. Enter "y" when asked and when done don't forget to <code>exit</code> sudo again, preventing yourself from doing stupid things from this point.

=== Compiling NML yourself ===
The other option to get NML is to compile it yourself. First you need to get the source from http://bundles.openttdcoop.org/nml/nightlies/LATEST/ or via Mercurial checkout from http://hg.openttdcoop.org/nml (<code>hg clone <nowiki>http://hg.openttdcoop.org/nml</nowiki></code>).

Also this time you need the terminal as superuser. Then change directory to the (extracted) NML source and run <code>python setup.py install</code>. For example:

sudo bash
cd ~/Downloads/nml-rXXXX
python setup.py install
exit

=== Using NML ===
As said before, NML is a command-line program and therefore doesn't have a GUI; much like GRFCodec in fact. That means you need to run it from a terminal window. The NML program itself is called <code>nmlc</code> and the general usage is <code>nmlc [options] <filename></code>. First change directory to the directory which has your nml file. Then run the nmlc program to compile your grf. For example:

cd ~/grfs/mygrf
nmlc -c --grf mygrf.grf mygrf.nml

This will encode the nml file ~/grfs/mygrf/mygrf.nml into the grf file ~/grfs/mygrf/mygrf.grf. The -c option is not mandatory, but crops extraneous blue from sprites, reducing the filesize of the grf file.

All command-line options available to NML are available via the <code>nmlc -h</code> command and are also [[#NML Command-line Options|listed]] on this page. Now that you have NML and know how to use it, you can continue this tutorial to learn how to create an actual grf file using NML.

== Windows ==
NML is available as pre-built (32 bit) Windows executable from the #openttdcoop DevZone, so there is no need to compile it yourself.

=== Installing NML ===
Go to http://bundles.openttdcoop.org/nml/nightlies/LATEST/ and download nml-rXXXX-windows-win32.zip, replacing XXXX with the actual version number of the package. The zip file contains a number of files that all need to stay together, so extract the zip file entirely into a single folder, for example D:\grfs\nml.

If you leave it at this, you can already start to use NML, but only from that folder. This makes compiling grfs a bit more difficult as you have to write full paths when encoding a grf file. If you want to run NML from any directory, you need to add the directory containing the nmlc.exe executable to your PATH environment variable. As this can break Windows if you don't do this properly, we'll not be explaining this here and go for the long route instead. You're of course free to change your PATH yourself; if you do, you're probably also smart enough to know how to change the commands as explained in the section below.

=== Using NML ===
As said before, NML is a command-line program and therefore doesn't have a GUI; much like GRFCodec in fact. That means you need to run it from a command prompt window. You can start the command prompt from Start > Programs > Accessories > Command Prompt. Or by entering <code>cmd</code> into the Run dialog or the Start menu search bar.

Next, you need to change directory to the folder where you have nmlc.exe in. Then you can run NML from there. For the example below we'll be assuming the following:
* nmlc.exe and related files are in D:\grfs\nml
* The nml file you want to encode is D:\grfs\mygrf\mygrf.nml
* The grf file to be created needs to go into D:\grfs\mygrf\mygrf.grf

From the command prompt you can now run the following commands, one at a time, confirm with Enter after each line:

D:
cd D:\grfs\nml
nmlc -c --grf D:\grfs\mygrf\mygrf.grf D:\grfs\mygrf\mygrf.nml

This will encode the nml file D:\grfs\mygrf\mygrf.nml into the grf file D:\grfs\mygrf\mygrf.grf. The -c option is not mandatory, but crops extraneous blue from sprites, reducing the filesize of the grf file. Note that if you have any spaces in a folder or file name, you need to enclose the complete path in double quotes, e.g.: <code>nmlc -c --grf "D:\grfs\my grf\mygrf.grf" "D:\grfs\mgrf\mygrf.nml"</code>. It is therefore recommended not to have any spaces.

All command-line options available to NML are available via the <code>nmlc -h</code> command and are also [[#NML Command-line Options|listed]] on this page. Now that you have NML and know how to use it, you can continue this tutorial to learn how to create an actual grf file using NML.

== NML Command-line Options ==
''From the NML readme''

Usage: nmlc [options] <filename>
Where <filename> is the nml file to parse

Options:
--version show program's version number and exit
-h, --help show this help message and exit
-d, --debug write the AST to stdout
-s, --stack Dump stack when an error occurs
--grf=<file> write the resulting grf to <file>
--nfo=<file> write nfo output to <file>
-c crop extraneous transparent blue from real sprites
-u save uncompressed data in the grf file
--nml=<file> write optimized nml to <file>
-o <file>, --output=<file>
write output(nfo/grf) to <file>
-t <file>, --custom-tags=<file>
Load custom tags from <file> [default:
custom_tags.txt]
-l <dir>, --lang-dir=<dir>
Load language files from directory <dir> [default:
lang]
-a <dir>, --sprites-dir=<dir>
Store 32bpp sprites in directory <dir> [default:
sprites]
--default-lang=<file>
The default language is stored in <file> [default:
english.lng]
--start-sprite=<num> Set the first sprite number to write (do not use
except when you output nfo that you want to include in
other files)
-p <palette>, --palette=<palette>
Force nml to use the palette <pal> [default: ANY].
Valid values are 'DOS', 'WIN', 'ANY'

== Text editor ==
NML files and its language files are plain text files and should be edited in a plain text editor. Your operating system most likely comes with a text editor with limited functionality. As such it is recommended to choose an editor with more functionality:
; Cross-platform
* [http://www.geany.org/ Geany]
; Linux
* [http://kate-editor.org/get-it/ Kate]
; MacOS
* XCode
; Windows
* [http://notepad-plus-plus.org/ Notepad++]

If you use an editor which you think is quite good and not listed here, you're welcome to add it.

=== Syntax highlighting ===
Syntax highlighting adds some colour to NML code, which makes it easier to read.

At the #openttdcoop DevZone there are syntax highlighter extensions available for [http://dev.openttdcoop.org/documents/24 Notepad++] and [http://dev.openttdcoop.org/documents/26 Geany]. If you want to create your own syntax highlighter, there's a [http://dev.openttdcoop.org/documents/25 script] available as well that will help you create the keyword lists.

{{NMLTutorialNavbar||Graphic files}}

NMLTutorial/Parameters

2011-08-26T09:28:59Z

Planetmaker: /* Numeric parameter */ numeric parameter examples

{{NMLTutorial}}

== Introduction ==
NewGRF Parameters in NML are part of the grf block
<pre>grf {
grfid: "NML\FF";
name: string(STR_GRF_NAME);
desc: string(STR_GRF_DESC);
version: 1;
min_compatible_version: 0;
param <num> {
<name> {
name: string(STR_PARAM_NAME_ECONOMIES);
desc: string(STR_PARAM_DESC_ECONOMIES);
<specifics>
}
}
}
</pre>

Where <tt>name</tt> is the name the parameter is referenced further within the grf to read this parameter. <num> is the number of this parameter. The meaning of the <num> parameter should should remain constant throughout versions of the same NewGRF or the NewGRF might become incompatible with previous versions of the same NewGRF (thus you'd need to change min_compatible_version if you change the meaning of the parameters at <num>.

== Parameter types ==
NML knows three different types of parameters, boolean, numeric ones and enumerations:

=== Boolean parameter ===
The boolean parameter is the easiest as it requires no further definitions besides the name and description. Optionally a single parameter can contain several boolean parameter values, each using a single bit, thus saving in the number of externally visible NewGRF parameters.
<pre>
param 3 { // 3rd parameter of the NewGRF
param_bool_1 { // 1st boolean value
name: string(STR_PARAM_NAME_DEBUG);
desc: string(STR_PARAM_DESC_DEBUG);
type: bool;
bit: 1; // uses 1st bit
}
param_bool_2 { // 2nd boolean value
name: string(STR_PARAM_NAME_DEBUG);
desc: string(STR_PARAM_DESC_DEBUG);
type: bool;
bit: 2; // uses 2nd bit
}
}
</pre>

=== Numeric parameter ===

The numeric parameter allows to directly input an (integer) number. It needs to have a minimum and maximum value given and optionally - and usually a good idea - a default value for the parameter:
<pre>
param 1 {
param_depot_year {
type: int;
name: string(STR_PARAM_DEPOTYEAR);
desc: string(STR_PARAM_DEPOTYEAR_DESC);
min_value: 0;
max_value: 5000000;
def_value: 1975;
}
}
</pre>

=== Enumeration parameter ===

The enumeration parameter basically is a numeric parameter where the single values have (additionally) a string attached to describe their meaning. Not all values need a string description, but it usually is a good idea to do this consistently
<pre>
param 0 {
economy {
name: string(STR_PARAM_NAME_ECONOMIES);
desc: string(STR_PARAM_DESC_ECONOMIES);
min_value: 0;
max_value: 1;
def_value: 0;
names: {
0: string(STR_PARAM_VALUE_ECONOMIES_TEST_ECONOMY);
1: string(STR_PARAM_VALUE_ECONOMIES_HARD_ECONOMY);
};
}
}
</pre>

NMLTutorial/Parameters

2011-08-26T09:19:31Z

Planetmaker: parameters: boolean parameters explained.

NMLTutorial/Version check

2011-08-26T09:02:39Z

Planetmaker: add NMLTutoral menu

{{NMLTutorial}}

Version checks in NML are actually pretty straight forward.

NML provides the [http://newgrf-specs.tt-wiki.net/wiki/NML:General#General_variables global variables] <code>openttd_version</code> and <code>ttd_platform</code>. Concerning version checks the built-in [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function] <code>version_openttd</code> comes in very handy as it provides an easy means to specify the version instead of manually constructing the version number corresponding to a specific version.

Thus checking for the TTD platform is simply done by an if block:
<pre>
if (ttd_platform != PLATFORM_OPENTTD) {
error(FATAL, REQUIRES_OPENTTD, string(STR_MIN_OPENTTD_VERSION));
exit;
}
</pre>

as is the check for a specific OpenTTD (and similarily TTDPatch) version:
<pre>
/* Only define cargo_age_period when that property is available */
if (openttd_version > version_openttd(1, 2, 0, 22713)) {
item (FEAT_TRAINS, my_engine) {
property {
cargo_age_period: 200;
}
}
}
</pre>

It's also possible to combine these checks into a single block:
<pre>
/* Long date string codes require OpenTTD > 1.2.0 or r22780 */
if (ttd_platform != PLATFORM_OPENTTD || openttd_version < version_openttd(1, 2, 0, 22780)) {
error(FATAL, REQUIRES_OPENTTD, string(STR_MIN_OPENTTD_VERSION));
exit;
}
</pre>

NMLTutorial/Version check

2011-08-26T09:01:15Z

Planetmaker: use common style for <code>

Version checks in NML are actually pretty straight forward.

NML provides the [http://newgrf-specs.tt-wiki.net/wiki/NML:General#General_variables global variables] <code>openttd_version</code> and <code>ttd_platform</code>. Concerning version checks the built-in [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function] <code>version_openttd</code> comes in very handy as it provides an easy means to specify the version instead of manually constructing the version number corresponding to a specific version.

Thus checking for the TTD platform is simply done by an if block:
<pre>
if (ttd_platform != PLATFORM_OPENTTD) {
error(FATAL, REQUIRES_OPENTTD, string(STR_MIN_OPENTTD_VERSION));
exit;
}
</pre>

as is the check for a specific OpenTTD (and similarily TTDPatch) version:
<pre>
/* Only define cargo_age_period when that property is available */
if (openttd_version > version_openttd(1, 2, 0, 22713)) {
item (FEAT_TRAINS, my_engine) {
property {
cargo_age_period: 200;
}
}
}
</pre>

It's also possible to combine these checks into a single block:
<pre>
/* Long date string codes require OpenTTD > 1.2.0 or r22780 */
if (ttd_platform != PLATFORM_OPENTTD || openttd_version < version_openttd(1, 2, 0, 22780)) {
error(FATAL, REQUIRES_OPENTTD, string(STR_MIN_OPENTTD_VERSION));
exit;
}
</pre>

NMLTutorial/Version check

2011-08-26T07:58:24Z

Planetmaker: how to do version checks

Version checks in NML are actually pretty straight forward.

NML provides the [http://newgrf-specs.tt-wiki.net/wiki/NML:General#General_variables global variables] <code style="color:darkgreen">openttd_version</code> and <code style="color:darkgreen">ttd_platform</code>. Concerning version checks the built-in [http://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions function] <code style="color:darkgreen">version_openttd</code> comes in very handy as it provides an easy means to specify the version instead of manually constructing the version number corresponding to a specific version.

Thus checking for the TTD platform is simply done by an if block:
<pre>
if (ttd_platform != PLATFORM_OPENTTD) {
error(FATAL, REQUIRES_OPENTTD, string(STR_MIN_OPENTTD_VERSION));
exit;
}
</pre>

as is the check for a specific OpenTTD (and similarily TTDPatch) version:
<pre>
/* Only define cargo_age_period when that property is available */
if (openttd_version > version_openttd(1, 2, 0, 22713)) {
item (FEAT_TRAINS, my_engine) {
property {
cargo_age_period: 200;
}
}
}
</pre>

It's also possible to combine these checks into a single block:
<pre>
/* Long date string codes require OpenTTD > 1.2.0 or r22780 */
if (ttd_platform != PLATFORM_OPENTTD || openttd_version < version_openttd(1, 2, 0, 22780)) {
error(FATAL, REQUIRES_OPENTTD, string(STR_MIN_OPENTTD_VERSION));
exit;
}
</pre>

NMLTutorial

2011-08-22T19:18:24Z

Planetmaker: slightly update language comparison

{{NMLTutorial}}

==Introduction==
Since june 2010 a new coding language for creating TTDpatch/OpenTTD GRF's exists: Newgrf Meta Language or NML. It differs significantly from the old way of GRF editing and although [http://newgrf-specs.tt-wiki.net/wiki/NML:Main documentation] is available it may still be a challenge for people interested in using NML code. After all NML is still a form of programming language and not a GUI-based editor.

There will be detailed examples of how coding in NML works on this new TT-wiki. Make sure to check the progress of this NML tutorial regularly.

==NML vs. NFO==
===Background===
NML is a high-level NewGRF language compiler which compiles NML and LNG files into newgrf files (and NFO files, if asked to do so). Coding a NewGRF in NML is similar to writing in any other programming language except that there are no real sub-routines; you can use the usual definition and condition statements.

===Language support===
NML provides easy support for different languages in one GRF. This is achieved by creating language files (lng). These language files follow the convention used for OpenTTD translation files. When compiling NML files a search for language files will automatically be performed. Even without providing additional translations at least one language file must be specified, called default.lng.

===Image format support===
One of the conveniences of NML is the possibility to read various image formats. Remember though that those images still need to supply the proper 8bpp palette and are supported by the python image library.

===Example===
Does the above sound impressive, maybe even threatening to you? One illustration often says more than a thousand words so let's show the difference with two illustrations:

{| cellspacing="0" class="mainpagetable" text-align="left" style="background-color: #F8EABA; border: 1px solid #C0C090;"
|- valign="top"

|width="50%"|
'''NFO code snippet'''
:// Automatically generated by GRFCODEC. Do not modify!

:0 * 4 \d416
:1 * 92 08 07 "SER0" "ÞSwedish Rails nightly-r52M" 00 "ÞSwedish rails are a replacement for the default rails" 00
|width="50%"|
'''NML code snippet'''
:grf {
::grfid : "SER0";
::name : string(STR_GRF_NAME);
::desc : string(STR_GRF_DESCRIPTION);
:}
'''NML language file snippet'''
:<nowiki>##</nowiki>grflangid 0x01
:STR_GRF_NAME :Swedish Rails {VERSION}
:STR_GRF_DESCRIPTION :Swedish rails are a replacement for the default rails
|}

== How to read the NML tutorial ==
The NML Tutorial starts with the [[NMLTutorial/Installation|installation of NML]] and continues from there as single "story" if you like. The bottom of each tutorial page has a link to the next page (and the previous in case you missed something) and all pages from the tutorial are also listed in navigation box at the top right of each page.

Example NML code is displayed in a code box and a blue font colour (much like the NML documentation itself). Code syntax definitions and other code and command (snippets) are displayed in black, either in a code box or in line with the text.

<pre style="color:darkblue">
//example NML code
block {
//block definition
item: value;
}
</pre>

If you have any questions about the text and examples within the NML tutorial, you are welcome to post those in the [link_to_be_added NML Tutorial topic] at TT-Forums. If you see bugs in the tutorial, you of course fix them or discuss them in the topic linked above first. Expanding or changing the tutorial should only be done by people who actually know NML and don't need this tutorial to code their NML files.

{{NMLTutorialNavbar||Installation}}

[[Category:NML]][[Category:Tutorials]]

NFO Foundations

2011-07-20T17:48:41Z

Planetmaker: Fix links

'''''How to get started on .nfo editing'''''

=NFO Files=

The fundamental files that control your new graphics are the .nfo and the .pcx file.  The .pcx file contains the actual drawings, and the .nfo file the instructions what to do with them.

==To get started==

To draw a new train, you first need a base from which to start working.  Since you probably aren't familiar with all the intricacies yet, it's best to copy one of TTD's vehicles and then draw your own graphics.  Basically, you follow these steps:
# Extract TTD's trg1r.grf (or trg1.grf for the DOS version or ogfx1_base.grf when using OpenGFX)
# Look through trg1r.pcx (TTD) or ogfx1_base.grf (OpenGFX) for a vehicle similar to the one you're going to make
# Copy the corresponding data from the .nfo file into your own file
# Encode and decode again your own file

Now to look at these steps in a bit more details. If you de-compiled OpenGFX's file, use the appropriate filenames instead in the subsequent text.

==1. Extract TTD's trg1r.grf / OpenGFX's ogfx1_base.grf==

First of all, you need to download [http://www.openttd.org/download-grfcodec grfcodec] and unzip it into your TTD folder. Then you open a DOS command window. If you are using Windows 2000 or Windows XP you can open a DOS command window by typing cmd in the execute option in the start menu. When you see the command window run grfcodec like this:

<pre>-+cd C:\TTD       +-(change to your TTD folder)

-+grfcodec -d trg1r.grf       +-(decode trg1r.grf; use trg1.grf for the DOS version of TTD)</pre>

This will make a new folder called sprites, and will put trg1r.pcx and trg1r.nfo in it.

You can also use [http://www.divxland.org/ttd/grfwizard.htm GRFWizard] with grfcodec. It will add a user interface to grfcodec. Just follow the options in the wizard to decode a .grf file, it will also add a sprites folder and generate the .nfo and .pcx files.

==2. Look through trg1r.pcx / ogfx1_base.pcx==

You now open trg1r.pcx from the sprites folder.  There are many graphics programs to view and edit .pcx files.

Look for a vehicle that is similar to the one you want to make. For example, if you want to make a train engine with 8 views, you can use the SH 125.  So you go looking for its graphics in trg1r.pcx.  For the SH 125, you'll find them at numbers 2941 to 2948 (those are the little numbers above the images).  Write down those numbers.  For example, this is what it might look like:

{picture file=img/wiki_up//sh125.png}

==3. Copy the corresponding data from the .nfo file into your own file==

So now that we know what sprites to base the graphics on, we need to copy those into a new file. Open the trg1r.nfo file in a text editor, for example Notepad. Also, open another .nfo file for your own graphics, say for example "mytrain.nfo".

Now, copy and paste the first three lines beginning with "//" to your mytrain.nfo file.  While they may look like comments, they are actually important.

In the next step, find the lines beginning with the sprite numbers you're written down in the previous step.  In the example above, we'd find the lines with numbers 2941 to 2948.  Copy those eight (or however many) lines to your mytrain.nfo file as well.

==4. Encode and decode again your own file==

Now we want to make our own .grf file.  Unfortunately, grfcodec is a bit picky and will complain loudly if your lines are not numbered properly. To make grfcodec shut up, you have to go through your .nfo file, and change the numbers at the beginning of the lines to go from 0 to 7.

At this point, your .nfo file should look something like this:

<pre>// Automatically generated by GRFCODEC. Do not modify!

// (Info version 6)

// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel

   0 C:\TTD\SPRITES\trg1.pcx 530 10664 01 18 8 -3 -10

   1 C:\TTD\SPRITES\trg1.pcx 546 10664 09 15 20 -14 -6

   2 C:\TTD\SPRITES\trg1.pcx 578 10664 01 12 28 -14 -6

   3 C:\TTD\SPRITES\trg1.pcx 626 10664 09 16 20 -4 -8

   4 C:\TTD\SPRITES\trg1.pcx 658 10664 01 18 8 -3 -10

   5 C:\TTD\SPRITES\trg1.pcx 674 10664 09 16 20 -14 -7

   6 C:\TTD\SPRITES\trg1.pcx 706 10664 01 12 28 -14 -6

   7 C:\TTD\SPRITES\trg1.pcx 754 10664 09 15 20 -4 -7</pre>

Now run grfcodec again, first to encode and then to decode your file. This creates mytrain.pcx and changes your .nfo to refer to that copy of the sprites:

<pre>-+grfcodec -e mytrain.grf +-(encode your mytrain.grf file)

-+grfcodec -d mytrain.grf -p 2 +-(decode your mytrain.grf file again)</pre>

Leave off the "-p 2" if you're working with the DOS graphics instead of the Windows graphics.

==Good job!==

Now you have your own mytrain.grf file with the corresponding mytrain.nfo and mytrain.pcx files. We'll use this as a base for making these graphics TTDPatch compatible.

Note that you can't yet take your mytrain.grf file and put it in TTDPatch's newgrfw.cfg file yet, because it doesn't have the necessary information to allow TTDPatch to know what to do with it.

However, you can go ahead and edit the graphics in mytrain.pcx to your liking and make them look like your train.

Once you're ready, go on to the [[TheFirstVehicle|next section]].

NFOTutorial

2011-06-19T16:49:24Z

Planetmaker: Include links to other tutorials

== Introduction ==

This section collects tutorials targeting at creating NewGRFs for TTDPatch and OpenTTD.

For authors: please write these in order and always explain changes from one step/page to the next. Also ideally each topic would have a downloadable demo file that shows these steps "in action")

== Available tutorials ==

=== [[NMLTutorial|NML]] ===
How to make new .grf files for TTDPatch and OpenTTD with Newgrf Meta Language (NML) (under construction)

=== [[DrawingSprites|Drawing Sprites]] ===
How to draw new graphics

=== Lakie's Tutorials ===
These are tutorials that Lakie from [http://www.tt-forums.net/| TT-Forums] wrote, these are on his website for the moment.

Please note these are being worked on, and are not fully complete.

This will be a step-by-step guide that teaches how to make new graphics sets, from the first simple train engine to the most sophisticated train sets with liveries that change in time and special effects such as wagon backlights.

While the tutorial will be mostly covering train vehicles, all the steps apply to other vehicle types as well, although with slight (but obvious) changes.

Some pages may have sections labelled "advanced concepts", in which the more advanced uses of certain features are explained. You should perhaps not try to understand these at the first reading, but keep them in mind and come back later if you're ready for a little more sophisticated graphics.

*;Train Refitting: [http://users2.tt-forums.net/lakie/NfoCoding.php?id=1| The Basics]

ECSTVTCKarlstein

2011-06-17T19:30:50Z

Planetmaker: fix header link

[http://en.wikipedia.org/wiki/Karl%C5%A1tejn||Karlštejn, Prague, Czech Republic]

Drawn by Darkwalker, snowed and company colours by George

Based on

==General data==

{|
!Tiles!!21

|-
|Usage||65%

|-
|Growth Factor||70%
|}

==Stockpile size==

{|
!Level!!Tourists

|-
|Very low||229

|-
|Low||328

|-
|Normal||468

|-
|High||669

|-
|Very high||956

|-
|Ultimate||1365
|}

==Location/Positioning Conditions==
*Build outside towns !Tz1, !Tz2, !Tz3, !Tz4 (Town zone 0 allowed)
*Build > 3 tiles from desert tile
*Build on terraformed land (certain tiles must be sloped) see image
*Build > FF FF FF FFh tiles from Tourists centre with the same layout (only one layout instance per map)
*Build > 31 tiles away from other layout of Tourists centre

[http://wiki.ttdpatch.net/tiki-index.php?page=LocationConditions| Description of Location/Positioning Conditions]

==Features==

Supports snow, different trees for different landscapes, company colours.

When built by the player during a game, the roofs will be in Company Colours of the builder. When generated by the game or built while in the scenario editor, the roofs will be Black.

ECSTVTCNeuSchwansteinCastle

2011-06-17T19:29:12Z

Planetmaker: fix header link

[http://en.wikipedia.org/wiki/Neuschwanstein_Castle|Schloß Neuschwanstein, Schwangau, Germany]=

Drawn by George, help by Oz, Zimmlock (road to entrance, shadows)

Based on

==General data==

{|
!Tiles!!31

|-
|Usage||81%

|-
|Growth Factor||70%
|}

==Stockpile size==

{|
!Level!!Tourists

|-
|Very low||422

|-
|Low||603

|-
|Normal||862

|-
|High||1231

|-
|Very high||1759

|-
|Ultimate||2513
|}

==Location/Positioning Conditions==
*Build outside towns !Tz1, !Tz2, !Tz3, !Tz4 (Town zone 0 allowed)
*Build > 3 tiles from desert tile
*Build on terraformed land (certain tiles must be sloped) see image
*Build > FF FF FF FFh tiles from Tourists centre with the same layout (only one layout instance per map)
*Build > 31 tiles away from other layout of Tourists centre

[http://wiki.ttdpatch.net/tiki-index.php?page=LocationConditions| Description of Location/Positioning Conditions]

==Features==

Supports snow, different trees for different landscapes, company colours.

When built by the player during a game, the roofs will be in Company Colours of the builder. When generated by the game or built while in the scenario editor, the roofs will be Black or Brown.

Supports industry animation.

ECS Houses. Banks Table

2011-06-16T10:35:52Z

Planetmaker: fix table

== Introduction ==

Banks are available when valuables, gold or diamonds cargo is defined (by [[ECSTownVector|Town vector]] or by some other GRF).

'''Note:''' The [[ECSHBanks|page]] is available in list form

{| |-
!<center>'''Image'''</center>!!<center>'''Drawn'''</center>!!<center>'''Size'''</center>!!<center>'''Eras'''</center>!!<center>'''Start year'''</center>!!<center>'''End year'''</center>!!<center>'''Zone'''</center>!!<center>'''Houses¹'''</center>!!<center>'''Distance²'''</center>!!<center>'''Min town populat. req.'''</center>!!<center>'''Citizens in service³'''</center>!!<center>'''Limit per town⁴'''</center>!!<center>'''Acceptance'''</center>!!<center>'''Prod⁵.'''</center>!!<center>'''Remove⁶'''</center>!!<center>'''Age⁷'''</center>!!<center>'''Snow'''</center>!!<center>'''CC'''</center>!!<center>'''Const. stages'''</center>

'''1x1'''
|-
| ||Oz||1x1||1||1920||1950||0-4||15||15||1024||1024||4||valuables,gold, diamonds||48/24||900||10 years||<center>+</center>||<center>-</center>||<center>3</center>
|-
| ||Zimmlock||1x1||1||1920||1950||0-4||15||15||1024||1024||4||valuables,gold, diamonds||48/24||900||10 years||<center>+</center>||16 CC||<center>-</center>
|-
| ||Oz||1x1||2,3||1950||2010||0-4||15||15||1024||1024||4||valuables,gold, diamonds||48/24||900||10 years||<center>+</center>||<center>-</center>||<center>3</center>
|-
| ||Zimmlock||1x1||2||1950||1980||0-4||15||15||1024||1024||4||valuables,gold, diamonds||48/24||900||10 years||<center>+</center>||16 CC||<center>-</center>
|-
| ||Oz||1x1||3,4||1980||<center>-</center>||0-4||15||15||1024||1024||4||valuables,gold, diamonds||48/24||900||10 years||<center>+</center>||<center>-</center>||<center>3</center>

'''2x1'''
|-
| ||Oz||2x1||1,2||1920||1980||0-4/3-4||15||15||2048||1024||4||valuables, gold, diamonds||96/48||900||15 years||<center>+</center>||16 CC||<center>3</center>
|-
| ||Zimmlock||2x1||1,2||1920||1980||0-4/4||15||15||2048||1024||4||valuables, gold, diamonds||96/48||900||15 years||<center>+</center>||<center>16 CC</center>||<center>3</center>
|-
| ||Oz||2x1||2,3||1950||2010||0-4/3-4||15||15||2048||1024||4||valuables, gold, diamonds||96/48||900||15 years||<center>+</center>||<center>-</center>||<center>3</center>
|-
| ||Zimmlock||2x1||2,3||1950||2010||0-4/0-2||15||15||2048||1024||4||valuables, gold, diamonds||96/48||900||15 years||<center>+</center>||<center>16 CC</center>||<center>3</center>
|-
| ||Oz||2x1||3,4||1980||<center>-</center>||0-4||15||15||2048||1024||4||valuables,gold, diamonds||96/48||900||15 years||<center>+</center>||<center>16 CC</center>||<center>3</center>
|-
| ||Zimmlock||2x1||3,4||1980||<center>-</center>||0-2||15||15||2048||1024||4||valuables,gold, diamonds||96/48||900||15 years||<center>+</center>||<center>-</center>||<center>-</center>
|-
| ||Zimmlock||2x1||3,4||1980||<center>-</center>||3-4/0-2||15||15||2048||1024||4||valuables, gold, diamonds||96/48||900||15 years||<center>+</center>||<center>16 CC</center>||<center>3</center>
|-
| ||Zimmlock||2x1||4||2010||<center>-</center>||0-2||15||15||2048||1024||4||valuables,gold, diamonds||96/48||900||15 years||<center>+</center>||<center>16 CC</center>||<center>-</center>
|-
| ||Zimmlock||2x1||4||2010||<center>-</center>||3-4||15||15||2048||1024||4||valuables,gold, diamonds||96/48||900||15 years||<center>+</center>||<center>-</center>||<center>3</center>
|} ¹ - Number of houses in town required to build the bank

² - Minimal distance between banks of any type

³ - Number of citizens above minimal town population required to allow next bank.

⁴ - Maximum number of the banks per town

⁵ - First value represents banks in service (valuables were delivered this or last months), second for others

⁶ - Minimal town rating required to remove the bank

Category:ECS-fix

2011-06-15T07:10:07Z

Planetmaker: Created page with "Pages in this category need review wrt table style. They have to be moved to ECS once the tables are fixed"

Pages in this category need review wrt table style. They have to be moved to ECS once the tables are fixed

ECS Machinery Vector

2011-06-15T07:08:07Z

Planetmaker: add category ECS-fix

'''''ECS Machinery Vector'''''

=ECS Machinery vector=

==General characteristics==

The GRFID is 4D656F94. The vector provides a couple of cargoes and industries, designed to supply other vectors with machinery (also one industry to supply towns with goods). Raw material industry supply the processing industry with material for producing steel. Materials from other vectors are used as a must material. If cargoes from other vectors are not defined, requirements are ignored.

==Parameters==

||Number|Meaning

<center>0</center>|General behaviour change [[(ECSVectorsGeneralInformation|Description]])||

==Industries==

{toc}

==Cargoes==

Default cargoes
* Iron ore (ID 08)
* Steel (ID 09)

New cargoes
* Vehicles or machinery (ID 18)

New cargoes planned
* Bauxite (ID 1A)

Payment for delivering 10 units (or 10 000 litres) of cargo a distance of 20 squares

==Cargo chains==
[[Category:ECS-fix]]

ECS Chemical Vector II

2011-06-15T07:07:21Z

Planetmaker: add ECS category

'''''ECS Chemical Vector II'''''

=ECS Chemical Vector II=

==General characteristics==

The GRFID is 4D656F9C.

==Parameters==

||Number|Meaning

<center>0</center>|General behaviour change [[(ECSVectorsGeneralInformation|Description]])||

==Industries==

{toc}

==Cargoes==

Default cargoes
* Oil (ID 03)

New cargoes
* Dyes (ID 14)
* Refined products (ID 17)
* Petrol (ID 19)

Planned cargoes
* Potash (ID 10)

Payment for delivering 10 units (or 10 000 litres) of cargo a distance of 20 squares

==Cargo chains==
[[Category:ECS]]

ECS Basic Vector II

2011-06-15T07:06:50Z

Planetmaker:

'''''ECS Basic Vector II'''''

=ECS Basic Vector II=

==General characteristics==

The GRFID is 4D656F9F. The vector provides a couple of cargoes and industries, designed to supply other industries with materials, like sand, glass, coal. Raw material industries supply the processing industries with material for producing cargo.

==Parameters==

||Number|Meaning

<center>0</center>|General behaviour change [[(ECSVectorsGeneralInformation|Description]])||

==Industries==

{toc}

==Cargoes==

Default cargoes
* Coal (ID 01)

New cargoes
* Sand (ID 11)
* Glass (ID 12)

New cargoes planned
* Building materials (ID 1C)

Payment for delivering 10 units (or 10 000 litres) of cargo a distance of 20 squares

==Cargo chains==
[[Category:ECS]]

ECS Houses

2011-06-15T07:06:16Z

Planetmaker: add ECS category

'''''ECS Houses'''''

=ECS Houses=

==General characteristics==

The GRFID is 4D656F9D. ECS Houses provides houses to support ECS cargoes on the towns side.

==Parameters==

||'''Number'''|'''Bit'''|'''Meaning'''

<center>0</center>|<center>0</center>|Disable (0, default) / Enable (1) houses of era 1 (1920-1950)

|<center>1</center>|Disable (0, default) / Enable (1) houses of era 2 (1950-1980)

|<center>2</center>|Disable (0, default) / Enable (1) houses of era 3 (1980-2010)

|<center>3</center>|Disable (0, default) / Enable (1) houses of era 4 (2010-...)|| When all bits are 0, "historical" (year based) appearance of houses is provided.

==Houses==

{toc}

==Cargo chains==
[[Category:ECS]]

NFO Foundations

2010-11-20T10:05:41Z

Planetmaker:

'''''How to get started on .nfo editing'''''

=NFO Files=

The fundamental files that control your new graphics are the .nfo and the .pcx file.  The .pcx file contains the actual drawings, and the .nfo file the instructions what to do with them.

==To get started==

To draw a new train, you first need a base from which to start working.  Since you probably aren't familiar with all the intricacies yet, it's best to copy one of TTD's vehicles and then draw your own graphics.  Basically, you follow these steps:
# Extract TTD's trg1r.grf (or trg1.grf for the DOS version or ogfx1_base.grf when using OpenGFX)
# Look through trg1r.pcx (TTD) or ogfx1_base.grf (OpenGFX) for a vehicle similar to the one you're going to make
# Copy the corresponding data from the .nfo file into your own file
# Encode and decode again your own file

Now to look at these steps in a bit more details. If you de-compiled OpenGFX's file, use the appropriate filenames instead in the subsequent text.

==1. Extract TTD's trg1r.grf / OpenGFX's ogfx1_base.grf==

First of all, you need to download [http://www.openttd.org/download-grfcodec|grfcodec] and unzip it into your TTD folder. Then you open a DOS command window. If you are using Windows 2000 or Windows XP you can open a DOS command window by typing cmd in the execute option in the start menu. When you see the command window run grfcodec like this:

<pre>-+cd C:\TTD       +-(change to your TTD folder)

-+grfcodec -d trg1r.grf       +-(decode trg1r.grf; use trg1.grf for the DOS version of TTD)</pre>

This will make a new folder called sprites, and will put trg1r.pcx and trg1r.nfo in it.

You can also use [http://www.divxland.org/ttd/grfwizard.htm|GRFWizard] with grfcodec. It will add a user interface to grfcodec. Just follow the options in the wizard to decode a .grf file, it will also add a sprites folder and generate the .nfo and .pcx files.

==2. Look through trg1r.pcx / ogfx1_base.pcx==

You now open trg1r.pcx from the sprites folder.  There are many graphics programs to view and edit .pcx files.

Look for a vehicle that is similar to the one you want to make. For example, if you want to make a train engine with 8 views, you can use the SH 125.  So you go looking for its graphics in trg1r.pcx.  For the SH 125, you'll find them at numbers 2941 to 2948 (those are the little numbers above the images).  Write down those numbers.  For example, this is what it might look like:

{picture file=img/wiki_up//sh125.png}

==3. Copy the corresponding data from the .nfo file into your own file==

So now that we know what sprites to base the graphics on, we need to copy those into a new file. Open the trg1r.nfo file in a text editor, for example Notepad. Also, open another .nfo file for your own graphics, say for example "mytrain.nfo".

Now, copy and paste the first three lines beginning with "//" to your mytrain.nfo file.  While they may look like comments, they are actually important.

In the next step, find the lines beginning with the sprite numbers you're written down in the previous step.  In the example above, we'd find the lines with numbers 2941 to 2948.  Copy those eight (or however many) lines to your mytrain.nfo file as well.

==4. Encode and decode again your own file==

Now we want to make our own .grf file.  Unfortunately, grfcodec is a bit picky and will complain loudly if your lines are not numbered properly. To make grfcodec shut up, you have to go through your .nfo file, and change the numbers at the beginning of the lines to go from 0 to 7.

At this point, your .nfo file should look something like this:

<pre>// Automatically generated by GRFCODEC. Do not modify!

// (Info version 6)

// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel

   0 C:\TTD\SPRITES\trg1.pcx 530 10664 01 18 8 -3 -10

   1 C:\TTD\SPRITES\trg1.pcx 546 10664 09 15 20 -14 -6

   2 C:\TTD\SPRITES\trg1.pcx 578 10664 01 12 28 -14 -6

   3 C:\TTD\SPRITES\trg1.pcx 626 10664 09 16 20 -4 -8

   4 C:\TTD\SPRITES\trg1.pcx 658 10664 01 18 8 -3 -10

   5 C:\TTD\SPRITES\trg1.pcx 674 10664 09 16 20 -14 -7

   6 C:\TTD\SPRITES\trg1.pcx 706 10664 01 12 28 -14 -6

   7 C:\TTD\SPRITES\trg1.pcx 754 10664 09 15 20 -4 -7</pre>

Now run grfcodec again, first to encode and then to decode your file. This creates mytrain.pcx and changes your .nfo to refer to that copy of the sprites:

<pre>-+grfcodec -e mytrain.grf +-(encode your mytrain.grf file)

-+grfcodec -d mytrain.grf -p 2 +-(decode your mytrain.grf file again)</pre>

Leave off the "-p 2" if you're working with the DOS graphics instead of the Windows graphics.

==Good job!==

Now you have your own mytrain.grf file with the corresponding mytrain.nfo and mytrain.pcx files. We'll use this as a base for making these graphics TTDPatch compatible.

Note that you can't yet take your mytrain.grf file and put it in TTDPatch's newgrfw.cfg file yet, because it doesn't have the necessary information to allow TTDPatch to know what to do with it.

However, you can go ahead and edit the graphics in mytrain.pcx to your liking and make them look like your train.

Once you're ready, go on to the [[TheFirstVehicle|next section]].

NewGraphicsSpecs

2010-01-31T16:30:52Z

Planetmaker:

'''''Tutorial and Specifications for the new graphics system'''''

These pages contain info on how to make new graphics sets. The reference on the Actions is up-to-date, whereas the tutorial is still under construction. Stay tuned.

A downloadable version of these pages, in the form of a zip file containing all individual pages as HTML files, is available at [http://wiki.ttdpatch.net/NewGraphicsSpecs.zip].

{toc}

NewGraphicsSpecs

2010-01-31T16:29:52Z

Planetmaker: