Bridge newgrf spec discussion

[eis_os]

Hello

I started adding some basic code for Action2 into TTDPatch, so I try explain now how the generally direction is, and what problems we have:

In #tycoon Belugas Peter1183 and me tried to get a general direction for the action2 system, so the specs will work on TTDPatch and OTTD. Resulting newbridges introduce the OTTD bridges to TTDPatch.

TTDPatch will support overwriting all old bridges (including OTTD ones).
The cost factor in TTDPatch was rewritten to be a word value, note the calculation code works different, so the results seem to be a bit different then before.

TTDPatch won't support bridgesprite tables outside TTD/OTTD bridges.

Bridge IDs outside the TTD/OTTD bridges are dynamical allocated, TTDPatch will support loading up to around 120 bridges.

We will try to use the cargoid in Action3 to select the right bridge part, discussion wasn't finished on that part.
(note this was only presented to peter1183 and Belugas, but peter1183 already has the specs in his newroutes action draft):

Action3:
CargoID -> PartID
0 = ramps
1 = flat ramps (ramps on a slope)
7 = icons
8.. bridge middle part ids as TTD uses, aka 8+x (see below)

Middle part ids:
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.

Default cid is used for middle parts to defined.
You have to define part ids 0,1,7 and default to get a working bridge, a simple one...

Action2:
The layout system should work in the way newhouses, still the pillar drawing is a big problem.


VarAction2:
Currently I have added:

> 40 W age -> in the specs as byte value currently, TTDPatch will handle 255 as max age.
> 41 B -> a byte of land info was: direction of bridge


We had as well as wishes:
> 42 B Bridge head information
> 43 B Type of bridge (rail, road, tram, rail+tram)
> 44 B Tt Land use under bridge -> split to
> 45 D Hhbbaall, Length, height, position
TTDPatch has no concept of bridge length, it would be very very expensive to calculate a length. (specially bridges have to redrawn a lot more often then stations)

> 46 B
> Terrain slope, as for ss in industry tile var 60 -> For the lowest pillar call, yes, otherwise flat.

> 47 B Owner/Builder, as for industry var A7
> 48 B Colour scheme (of owner), as for Cc in vehicle var 43 -> Should be doable
> 49 B random byte. -> Not sure how to do it, canals simply return 0 for bridges...

So any wishes, questions, additions, ideas for the pillars...

[michael blunck]

[...] questions [...]

Does it (resp is it intended to) work with Jonathan´s "advzfunctions", i.e. diagonal and junction rail tiles under bridges?

regards
Michael

[eis_os]

advzfunctions doesn't touch L8, at least I haven't seen it does so it should be pretty safe to use it. I am more interested in solutions for bridge pillar drawing...

[maquinista]

Bridge IDs outside the TTD/OTTD bridges are dynamical allocated, TTDPatch will support loading up to around 120 bridges.

120 bridges? Awesome!


I would allow viaduct like this?

[DaleStan]

Will the definition of bridge-specific variables break callback 33, event 10? Or otherwise do something undesirable?

[FooBar]

I would allow viaduct like this?

A viaduct similar to that is already possible. It's just that as soon as you've put it into a grf, it is not compatible with other bridge grfs. This spec is solving that problem while keeping the bridge layout system the same.

[frosch]

I did not follow the discussion between you, peter and belugas. But a note on this point:

Action2:
The layout system should work in the way newhouses, still the pillar drawing is a big problem.

Bridges interact a lot with other objects:

• Vehicles on it,
• Vehicles under it (parallel, perpendicular, diagonal)
• catenary wires, pylons, (on and under)
• tram catenary (on and under),
• signals (currently only under, but easy to imagine on)
• foundations and fences under it,
• tunnel entrys under it,
• bridge heads unter it
• ...

The past has shown that it is pretty hard to avoid glitches with all these combinations and esp. after diagonal tracks and signals under bridges a lot of glitches appeared. Most of them were solved in OTTD by heavily modifying the bounding boxes of the bridge sprites. Also tram and rail catenary on the bridge is combined with the bridge sprites into the same bounding boxes (similiar to childsprites).
I don't know about TTDP's state of diagonal tracks under bridges and which glitches it causes and which not.

So what I am heading for: It would be very hard for grfcoders to supply bounding boxes that work in both TTDP and OTTD, as the objects that the bridge interacts with have different bounding boxes. Also every grfcoder would need to reinvent the spritelayout that works. Though the grfcoder would still not know, whether his layout works with future improvements (e.g. signals on bridges, small houses under bridges, or whatever)

So I would like to suggest a fixed bounding box layout like vehicles have. Maybe slightly more flexible than the current bridges.

• Back (identical with back of original bridge layout)
• Floor (maybe some kind of overlay for different road/rail types)
• Front (identical with front of original bridge layout)
• Four pillars for every corner of the tile

I cannot imagine why a bridge shall need more flexibility. (though some would want to specify multiple child sprites per bounding box)

Regards

[athanasios]

Might I remind some suggestions, as they may need to be considered here to avoid extra effort later. If they are pointless ignore my post.

1. Curved bridges.
2. Limit some vehicles from passing under bridge if bridge hasn't a certain height (mainly useful for ships).

regards
athanasios

[eis_os]

The bridge layout giving in action2 won't have bounding boxes. (Still the parts will be defined by an action2 instead of an massive action0 layout table)
Instead using bit 31 only, bit 30 is used to allow calling drawing bridge surfaces. So there won't be any difference between rail types. (You can still use an VarAction2 to select certain layouts for special bridges) This flexibly is used as base so newroutes (newrails/newroads) won't be a nightmare anymore.
A bridge will work with a narrow gauge track set instantly without supporting a narrow gauge set.

So general we have 3 bridge sprites. (and here we get the pillar problem again)
Backsprite
Surfacesprite
Frontsprite

We will get some flags too, disabling pylons for catenary, in connecting with newroutes this will allow more interesting catenary on bridges.
Action2 sprite numbers will get automatically one added for the direction. (Ramps will use +3 max)

Again with flags you can set a killbit and the sprite number gets used as in the layout.
This means to use TTD sprites you will have to use an VarAction2 or when you want to do fancy layouts... When there is a better system let me know, but I think thats much easier to have the part id sprites together

The callback 33 will by definition only get the failback type. (As TTD currently still uses a lot times the failback type because not all parts are fixed yet). So well it won't break totally but isn't very usable anymore. A bridge surely will allow callbacks in the future so we may add it as bridge specific callback.

About diagonal rails, I have no idea how to support this in a way that a bridge is future proof.

Pillars, Pikkas Viaduct shows that it isn't possible to draw 4 pillars simply...

I don't think we can find a solution (sprite sorting wise) for all stuff, TTDs height was never designed in mind you can build all things under a bridge...

[eis_os]

*bump*

Still the pillar drawing system isn't found, so the progress is slowly. At least I could submit the first code for the action3 subid feature...

[frosch]

Pillars, Pikkas Viaduct shows that it isn't possible to draw 4 pillars simply...

When the 4 pillars could be specified with 4 different sprites, the grfauthor could decide which bounding box suits best.

IMO the advantage of four bounding boxes in the corners of the tile is that they clearly define whether they shall be drawn in front or behind of vehicles (driving in any direction). Also they can deal with slopes (which the original bridges cannot), and with foundations (i.e. non-continuous height between neighboured tiles). They just fail for non-continuous height inside a tile, e.g. halftile slopes.

I don't see any advantage to have some bounding box in the middle of an edge for bridges like the viaduct, as it does not specify the needed information how to sort it wrt vehicles.