The m4nfo User manual and Technical Report

Functions for bridges

Using functions for bridges


At the time being, representation of bridges in TTD/TTDPatch/OpenTTD is rather rudimentary. Therefore, there is only one type of functions in m4nfo, namely for bridge layout definition. There are neither 'performance' functions for bridges nor callbacks.

Functions for bridge layout definition


For bridges, the layout defines what sprites should be displayed and where they are to be displayed. Each bridge middle segment needs six sprites (x/y front, x/y back, x/y pillars) for each of the four bridge types (rail, road, monorail, maglev), and each bridge end segment (bridge ramps) needs eight sprites (x/y front flat, x/y back flat, x/y front ramp, x/y back ramp) for each of the four bridge types.

Each bridge has 7 segments, though not all of them might have different graphics. The game itself builds bridges by using 5 possible fixed layouts:

Layout Description
_ _Bridge without middle part
_0_Bridge of length 3
_0(23)1_Bridge of even length
_0(23)4(23)1_Bridge of (uneven) lengths 5, 9, 13, 17 etc.
_0(23)253(23)1_Bridge of (uneven) lengths 7, 11, 15, 19 etc.

Where "_" indicates bridgeheads (as defined in segment 6), segment "0" is always at the farthest end from the viewer, and segments (23) are repeated n times as necessary, where n is any number equal or greater than 0.

Please note that bridges might introduce their own sprites, rather than to have to 'overwrite' TTD's original sprites, both methods are handled by use of function spriteblock(), but due to the different nature of pre-defined and newly allocated sprites, both use cases need a slightly different approach, see the bridge tutorial.

layout(<Bridge-ID>,[0 .. 6],
    <railbridge> | <railbridge_end>
    <roadbridge> | <roadbridge_end>
    <monobridge> | <monobridge_end>
    <mlevbridge> | <mlevbridge_end>

<[rail | road | mono | mlev]bridge> ::= [rail | road | mono | mlev]bridge(<front>, <back>, <pillar>)

<[rail | road | mono | mlev]bridge_end> ::= [rail | road | mono | mlev]bridge(<flat> <ramp>)

<front> ::= front(<x>, <y>)
<back> ::= back(<x>, <y>)
<pillar> ::= pillar(<x>, <y>)
<flat> ::= flat(<front>, <back>)
<ramp> ::= ramp(<front>, <back>)

<x> ::= (<TTD-sprite> | <sprite>) [+ <recolour>]
<y> ::= (<TTD-sprite> | <sprite>) [+ <recolour>]

<recolour> ::= recolour(<TTD-sprite> | <sprite>)

Layout term m4nfo function

layout(<Bridge-ID>, [0 .. 6], <block>)

This function defines the layout of a bridge, its ID given by the first parameter. It will overwrite one of the existing TTD bridges by (re-)defining its segments and, in turn, assigning new graphics. The second parameter denotes the start segment for the layout, which may include 1 .. 7 segments. Non-overwritten segments remain unchanged.


This function defines one bridge segment. First 6 segments of a bridge are middle segments, and the last one (segment 6) is a special bridgehead segment, probably a ramp. m4nfo will throw an error message (ERR_BADSEGMENT) in case a middle segment is attempted to be set as an end segment, or vice versa.

Segments can be defined individually, by defining the number of the start segment in function layout().

In each of the six middle segments, there must be four functions (for rail, road, monorail, and maglev) to specify the graphic sprites for this segment in the form:

[rail | road | mono | mlev]bridge(front(<x>, <y>), back(<x>, <y>), pillar(<x>, <y>))

The special segment 6 defines the bridgeheads and needs a different format for its functions:

[rail | road | mono | mlev]bridge(flat(front(<x>, <y>)), flat(back(<x>, <y>)), ramp(front(<x>, <y>)), ramp(back(<x>, <y>)))

rail/road/mono/mlevbridge(<front>, <back>, <pillar>)

These functions specify the graphic sprites for a bridge segment of a rail bridge, a road bridge, a monorail bridge, and a maglev bridge, respectively.

These functions will throw error messages ERR_NUMTYPE (wrong number of bridge types in function).

front/back/pillar(<x>, <y>)

These functions define which sprites to use for the bridge segment's front, back, or pillar graphics.

<front> and <pillar> may be 0, meaning no sprite to draw. Sprite numbers used may be any of TTD's sprite numbers, preferably those from toyland climate (or those from overwritten original bridges, if applicable), to not waste any valuable other sprites.

flat/ramp(<front>, <back>)

These extra functions have to be used for the last bridge segment to define the bridge's end pieces. Function flat() defines a flat end piece, and function ramp() needs to be used for a ramp end piece.

recolour(<TTD-sprite> | <sprite>)

Each sprite may be recoloured by simply adding a colour mapping to the sprite number:

railbridge(front(<x + recolour(_BBLUE>), <y + recolour(_BBLUE>)), back(<x + recolour(_BBLUE>), <y + recolour(_BBLUE>)), pillar(<x + recolour(_BBLUE>), <y + recolour(_BBLUE>)))

Colour mappings _BBLUE, _BBROWN, _BWHITE, _BRED, _BGREEN, _BGREY, _BYELLOW will map the "brownish red" colour, as used in the default bridges, to the specified colour. It is also possible to use company colour mappings (_CDBLUE .. _CWHITE), but these will only work if the bridge graphics have been drawn in "company blue" colour.

In the same way as using own sprites, own recolour maps may be used as well, defined in the same spriteblock() function as the bridge graphics. See tutorial.