Since I do not expect everyone to read every NML commit message, here a quick overview of some recent NML features:
The most important one is that you can now define callbacks directly in the graphics block. You can also specify return values there, so simple callbacks no longer need any switch-blocks. A list of callbacks is included in the documentation of each feature (docs/
feature.html). Example:
Code: Select all
item(FEAT_ROADVEHS, some_articulated_tram) {
graphics {
cargo_capacity: return 20; // 20 per part, total = 80
/* tram is made up of 4 parts in total, so add 3 articulated parts */
articulated_part: return (extra_callback_info1 <= 3) ? some_articulated_tram : 0xFF;
sound_effect: sound_effect_switch; // sound effect callback handled by a switch (not included here)
MAIL: tram_graphics_mail; // special graphics when refitted to mail (not included here)
default: tram_graphics_pax; // default graphics for the passenger cargo (not included here)
}
}
This way of defining callbacks is the recommended way to go. The old style (reading the current_callback variable) is still supported for backwards compatibility only.
The main advantage is that allows NML to create a better abstraction of the various quirks and inconsistencies that are present in NFO, in order to provide a better coding experience.
For example, the new method automatically sets the callback_flags property for you, so you can't forget a bit there and wonder why your grf doesn't work.
Return values in graphics or [random]switch blocks can now also access variables, as well as the parameters of a produce(..) statement.
Advanced spritelayouts, a recent NFO feature, have also been included in NML. You can now access (temporary or persistent) registers and variables from inside a spritelayout. This way, you no longer have to define a separate layout for each slightly different tile.
Last but not least, it is no longer necessary to define spritegroups in many cases. A spritegroup is equivalent to a 'real' action2 that combines several spritesets. In all cases except vehicles with multiple loading stages, these were just boilerplate code. Therefore, it has now been made possible to refer directly from a switch/graphics block to a spriteset. This has made spritegroups completely obsolete for cargos, canals, railtypes and airports, so spritegroups for those features have been declared deprecated and support will be removed in the future.
Happy coding
If you have questions, suggestions or wish to help with development, feel free to post here or ask on IRC (#openttdcoop.devzone channel).
Portuguese
Belarusian
