TTWiki - User contributions [en-gb]

NMLTutorial/Starting an NML file

2011-08-22T18:38:36Z

Ammler: /* Line 5: version: ; */ first commit is r0

{{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>
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: 1;
min_compatible_version: 1;
}
</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 -u --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.

=== OpenTTD targeted NewGRFs ===
* 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.

=== TTDPatch targeted NewGRFs ===
TTDPatch doesn't have a concept for <code>grf { min_compatible_version }</code> (or <code>grf { version }</code> for that matter). The only way to indicate broken compatibility in TTDPatch is to bump the GRFID. This means that you increase the last byte of the GRFID by one. So if your initial GRFID is <code>"SF\01\01"</code>, change it to <code>"SF\01\02"</code> for the next release.

As a consequence, both NewGRFs can be used separate from each other and in OpenTTD both will show up in the NewGRF window.

In order to avoid loading both the old version and the new version in the same game, you have to add a [[NMLTutorial/Version check|version check]] to the NewGRF in order to disable itself (or the older version).

{{NMLTutorialNavbar|NML Syntax|Road vehicle}}

NMLTutorial/Starting an NML file

2011-08-22T18:36:47Z

Ammler: /* Line 6: min_compatible_version: ; */ 0, not 1 (example)

{{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>
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 1 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: 1;
</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: 1;
min_compatible_version: 1;
}
</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 -u --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.

=== OpenTTD targeted NewGRFs ===
* 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.

=== TTDPatch targeted NewGRFs ===
TTDPatch doesn't have a concept for <code>grf { min_compatible_version }</code> (or <code>grf { version }</code> for that matter). The only way to indicate broken compatibility in TTDPatch is to bump the GRFID. This means that you increase the last byte of the GRFID by one. So if your initial GRFID is <code>"SF\01\01"</code>, change it to <code>"SF\01\02"</code> for the next release.

As a consequence, both NewGRFs can be used separate from each other and in OpenTTD both will show up in the NewGRF window.

In order to avoid loading both the old version and the new version in the same game, you have to add a [[NMLTutorial/Version check|version check]] to the NewGRF in order to disable itself (or the older version).

{{NMLTutorialNavbar|NML Syntax|Road vehicle}}

NMLTutorial/Installation

2011-08-22T18:27:08Z

Ammler: /* Linux */ typos

{{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 commandline 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 Pyton, the Python Image Library and Ply. 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 commandline 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 -u --grf mygrf.grf mygrf.nml

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

All commandline options available to NML are available via <code>nmlc -h</code> and are also listed at the end of 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 prebuilt (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, which 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 we'll be explaining the long route here. 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 commandline 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 follow commands, one at a time, confirm with Enter after each line:

D:
cd D:\grfs\nml
nmlc -u --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 -u 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 of file name, you need to enclose the complete path in double quotes, e.g.: <code>nmlc -u --grf "D:\grfs\my grf\mygrf.grf" "D:\grfs\mgrf\mygrf.nml"</code>. It is therefore recommended not to have any spaces.

All commandline options available to NML are available via the <code>nmlc -h</code> command and are also listed at the end of 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 Commandline 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'

{{NMLTutorialNavbar||Graphic files}}

ECS Compatibility list

2009-09-26T21:20:20Z

Ammler:

'''''ECS Compatibility list'''''

=ECS Compatibility list=

The ECS is known to be supported by the following sets

==Vehicles==

===Train sets===
* [http://users.tt-forums.net/2cc|2cc Train Set]
*[http://www.tt-forums.net/viewtopic.php?f=26&t;=36419&start;=0|Canadian Trains Set v0.3c]
* [http://www.tt-forums.net/viewtopic.php?t=12078|Serbian rail set]
* [http://www.pikkarail.com/ttdp/ukrs/download.htm|UK Renewal Set]
* [http://www.ttdpatch.net/newgrf.html#25|DBSetXL 0.82] with [http://www.tt-forums.net/viewtopic.php?p=681507#p681507|DBXL ECS extension]
* [http://www.as-st.com/ttd/newusa/|US Train Set v0.87.3] with ECS adapter for the US Set
* [http://grfcrawler.tt-forums.net/details.php?do=details&id;=221|Old Wagons, New Cargos] (refits all default waggons, also monorail and maglev)

===Road vehicles===
* Long vehicles v4 ([http://george.zernebok.net/newgrf/downloads.html|Site], [[LongVehicles|Wiki]])
* [http://www.tt-forums.net/viewtopic.php?f=26&t;=34744|Refit default rvs to new cargoes]
* [http://www.tt-forums.net/viewtopic.php?f=26&t;=33415|Generic road vehicle and tram set (GRVTS)]

===Plane sets===
* PlaneSet
* Aviators Aircraft (av8)
* Russian Planeset

===Ship sets===

==House sets==
* Total town replacement set v3 ([http://users.skynet.be/florisjan/ttd/ttrs.html|Site], [[ECSTTRS3|TTRS v3 ECS support data]])
*[http://www.tt-forums.net/viewtopic.php?f=26&t;=35458|North American Cities Set v0.1c]

==Station sets==

ECS Compatibility list

2008-06-02T18:17:06Z

Ammler:

'''''ECS Compatibility list'''''

=ECS Compatibility list=

The ECS is known to be supported by the following sets

==Vehicles==

===Train sets===
*[http://www.tt-forums.net/viewtopic.php?f=26&t;=36419&start;=0|Canadian Trains Set v0.3c]
* [http://www.tt-forums.net/viewtopic.php?t=12078|Serbian rail set]
* [http://www.pikkarail.com/ttdp/ukrs/download.htm|UK Renewal Set]
* [http://www.ttdpatch.net/newgrf.html#25|DBSetXL 0.82] with [http://www.tt-forums.net/viewtopic.php?p=681507#p681507|DBXL ECS extension]
* [http://www.as-st.com/ttd/newusa/|US Train Set v0.87.3] with ECS adapter for the US Set
* [http://grfcrawler.tt-forums.net/details.php?do=details&id;=221|Old Wagons, New Cargos] (refits all default waggons, also monorail and maglev)

===Road vehicles===
* Long vehicles v4 ([http://george.zernebok.net/newgrf/downloads.html|Site], [[LongVehicles|Wiki]])
* [http://www.tt-forums.net/viewtopic.php?f=26&t;=34744|Refit default rvs to new cargoes]

===Plane sets===
* PlaneSet
* Aviators Aircraft (av8)
* Russian Planeset

===Ship sets===

==House sets==
* Total town replacement set v3 ([http://users.skynet.be/florisjan/ttd/ttrs.html|Site], [[ECSTTRS3|TTRS v3 ECS support data]])
*[http://www.tt-forums.net/viewtopic.php?f=26&t;=35458|North American Cities Set v0.1c]

==Station sets==

RealMaglevs

2007-08-26T00:11:00Z

Ammler:

'''''If you want to know what Maglevs are.'''''

=Real Maglevs=

If you want to know what Maglevs are.

So, you've been building maglev routes and buying maglev trains all the time in TTD.  Did you know that there are actual maglevs running, that you can even test ride?  One of them is the German "Transrapid" system, which uses static magnetic levitation (maglev) to travel without any moving parts.  There is more information about it at the [http://www.transrapid.de/cgi-tdb/en/basics.prg|Transrapid home page],  and even though it resembles TTD's monorail more than its maglev, it is in fact a maglev.

Since version 2.0 of TTDPatch, you can actually ''play'' with the Transrapid too, by loading the "DB Set", available as a new graphics set.

Another maglev train that is still under development is the Japanese MLX, which you can find at the [http://www.rtri.or.jp/rd/maglev/html/english/maglev_frame_E.html|home page]. This one relies on dynamic magnetic levitation, which means that it will only levitate once it is fast enough.  It appears that this is what TTD's maglev is modelled after, because it also has the guide rails at the side of the tracks, and TTD's Chimera seems to be very similar to the MLU002N test vehicle.