planetmaker wrote: ↑21 Jun 2019 14:02
This simple concept is already broken by station NewGRF specs - but that has no impact on the game functionality itself but is (in my mental model) more a consequence of wanting some bigger building which does come in a package but doesn't fit on a single tile.
Concept prototypes in this topic and the
further improvement don't restrict more than 1 tile platforms, directly adjacent to a bridge or tunnel, to increase their "platform length" parameter (or, actually, their platform(s)). Player can build stations platforms as long as game Settings allow. So, there's no additional limitations to the size of station.
planetmaker wrote: ↑21 Jun 2019 14:02
Concerning stations on bridges: Conceptually I'd expect station specs to be extended such that the permissible ground is extended from certain slopes towards bridges. Then NewGRFs can query the ground and provide special bridge graphics. Problem to be solved: bridges have no ground, they're just wormholes with graphical sugar. And as such they already have their own graphics with foundations, pylons, foreground guard rail, background guard rail and tracks... which would break when overdrawn by stations which in turn consist of ground, tracks background, and building. So that will need systematically solving and finding acceptable solutions.
Making bridges non-wormholes might make this whole thing easier. Thus maybe it needs something like or some parts of the "
new map array" as pre-requisite as developed by michi_cc some years back to allow different height levels for a single tile to co-exist.
Only entrances of the existing bridges or tunnels are considered as station tiles (
in this prototype) with corresponding coverage areas (look at pictures
there). This means simulation of that fact, that entrances to such bridge-platform can be only at the entrances to bridge or tunnel... or player have to build some additional (joined) station tiles, simulating some additional entrances to this station (this last is more realistic for tunnel-platforms than for bridge-platforms).
Graphics of bridge-platform can be implemented as usual graphics of existing bridges, as, for example, some new types of bridges, for example, with bigger width.
I agree, that the current implementation of bridges or tunnels make a set of limitations to these objects. The main is: only straight bridges and tunnels are allowed. Some aspects of implementation of bridges still wonder me: how it works? A bridge has some "shadow" on the (any) ground (in the data of the map) - this are 2 bits in Tile->type, which indicate IsBridgeAbove(..) this Tile or not and direction of bridge above (if it is). But there's no data about the height of this bridge! But program somehow can determine its height! (I need to see the corresponding functions more times - maybe, I will come to understanding of them.) This is possible by tracking to the ends of bridge (its foundations), but this needs some run-time. This 2 bits "shadow" means also that
only 1 bridge can be stored in the map data (for every tile).
I noticed that fields of farms can be under the bridges in OpenTTD of version 1.9.1. This is good. But why trees or station tiles can not? Or even houses under a bridge? Yes, these objects are high, but their height is limited... I tried to allow to build a bridge over trees or station tiles (if the height of the bridge is +2 or +3 levels higher than ground with forest or that station tiles)...
Code: Select all
CommandCost CmdBuildBridge(TileIndex end_tile, DoCommandFlag flags, uint32 p1, uint32 p2, const char *text)
{
...
switch (GetTileType(tile)) {
...
case MP_TREES: // new
if (GetTileMaxZ(tile) + 3 > z_start) goto not_valid_below;
break;
case MP_STATION: // new
if (GetTileMaxZ(tile) + 2 > z_start) goto not_valid_below;
break;
case MP_CLEAR:
break;
default:
not_valid_below:;
/* try and clear the middle landscape */
ret = DoCommand(tile, 0, 0, flags, CMD_LANDSCAPE_CLEAR);
if (ret.Failed()) return ret;
cost.AddCost(ret);
break;
}
if (flags & DC_EXEC) {
/* We do this here because when replacing a bridge with another
* type calling SetBridgeMiddle isn't needed. After all, the
* tile already has the has_bridge_above bits set. */
SetBridgeMiddle(tile, direction);
}
...
}
and then I saw, why: because graphics of trees or station tiles doesn't allow to draw graphics of bridge (above).
So, I need to find how to fix this restriction (to switch it to off).
I can not find description of the concept of the "
new map array" as pre-requisite as developed by michi_cc. But I think, that some kind of
CACHE may help to improve bridges and tunnels in OpenTTD.
This means to store some pointer to the set of bridges and tunnels for each tile of the map, so the size of data to store this pointer will be the same for every tile regardless to the size of the set of bridges above the tile or tunnels under it and their z-positions and directions. But this will allow program to find all the bridges above without tracking to their ends. Such cache will help to control vehicles in tunnels too, for example, their speed when braking in the tunnel-platforms or bridge-platforms - faster find the ends of corresponding tunnel or bridge (but,
even now this is good enough and for this purpose it may be easier to store some pointer to data of current tunnel or bridge in data of vehicle, because map size is bigger than maximum number of vehicles). Or... to create some dedicated database of bridges and tunnels (somehow pre-sorted by TileIndex), that will allow to get all such objects without any direct pointer from the tile of map - just by the TileIndex. But, I assume, that without direct pointer from tile this would work much slower then the program does now. Except of case, if this will be implemented as plots of some functions (some curve lines or surfaces).