NMLTutorial/Cargotable

NML Tutorial

Installation

Graphics files

Language files

NML Syntax

Starting an NML file (grf block)

• Creating a road vehicle

Item blocks

• • Item definition

Spriteset & spritegroup blocks

• • Adding the graphics

Template blocks

• • Templating the graphics

Cargotable block

• • Cargo-dependent graphics

Callbacks and switch blocks

• Creating a tram

• • Make it articulated

• • Adding the graphics

• • Fix the purchase menu

• Creating a train

Railtypetable block

• • Single engine

• • Three part articulated

• • Four part refit

GRF Parameters

• • Real life recolour scheme

• Creating an object

Spritelayout blocks

• • Adding the graphics

Version checks

• • Objects on slopes

32 bit sprites

• Adding 32 bit sprites

Base graphics replacement

• 32 bit base graphics

Conclusion

Glossary

NML Documentation

Whenever you want to work with specific cargos, you need to teach NML about those cargos. The reason for this is that new cargos can be invented at will, so NML doesn't keep a list of existing cargo labels and therefore you have to provide this list yourself.

Cargotable

The cargotable is the means to let NML know about the cargo labels you want to use in your NML file. An NML file can have exactly one cargotable. The cargotable needs to be defined before you reference a cargo label in your NML code.

The cargotable itself is no more than a list of cargo labels. You need to look the cargo labels up for the cargos you want to do special things with. This is what the general syntax looks like:

cargotable {
	<cargo_label1> [, <cargo_label2> [, <cargo_label3> ... ]]
}

You can add as many cargo labels to the cargotable as you want/need.

First 32 cargo labels

When making a vehicle set for TTDPatch, the first 32 cargo labels should be selected with care. The reasons for this is that only the first 32 cargos can be used in the refittable_cargo_types property for vehicles. So stick cargo labels you use in that property into the cargotable first and add other cargo labels at the end.

If you're using more advanced features of NewGRF that only work in OpenTTD anyways, the order of labels in the cargotable doesn't matter. For OpenTTD-only vehicle sets you should not use the refittable_cargo_types property, but the cargo_allow_refit and cargo_disallow_refit properties instead.

Cargo labels or cargo classes?

When it comes to allowing cargos in a vehicle, you should always use cargo classes and not only cargo labels. That way your vehicle set will be compatible with cargos that don't even exist yet.

Use cargo labels only to deny or allow specific cargos in your vehicles that don't match the cargo classes you have set.

For OpenTTD-only vehicle NewGRFs, define all known cargo labels in the cargo_allow_refit and cargo_disallow_refit properties and provide the cargo classes additionally to that for compatibility with future cargoes that haven't been invented yet.

Furthermore, industries and houses don't work with cargo classes, so there you can only use the cargo labels. Also if you want specific graphics for specific cargoes, you have to use cargo types and not cargo classes.

Now that you know about the cargotable, let's add some cargo specific graphics to our example road vehicle.

« Road vehicle graphics template

NML Tutorial: Cargotable

Road vehicle cargo graphics »