Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Got an idea for OpenTTD? Post it here!

Moderator: OpenTTD Developers

BattlePeasant
Engineer
Engineer
Posts: 8
Joined: 15 May 2019 07:16

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by BattlePeasant » 12 Jun 2019 18:53

Why not spend 200 hours, but do it well? Why does everyone want to make the game cheap, but ugly?
Who wants to work - is looking for ways, who does not want - reasons.

User avatar
andythenorth
Tycoon
Tycoon
Posts: 4974
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by andythenorth » 13 Jun 2019 07:17

BattlePeasant wrote:
12 Jun 2019 18:53
Why does everyone want to make the game cheap, but ugly?
Not everyone does. Core developers get a fair bit of stick in these forums for not just committing any old thing. :twisted:

Bu there's nothing wrong with people making dirty hacks to try solving interesting problems. They just won't make get merged to OpenTTD master. :)

TopTechDreamer
Engineer
Engineer
Posts: 48
Joined: 22 Feb 2012 12:21
Location: Ukraine
Contact:

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by TopTechDreamer » 13 Jun 2019 11:47

andythenorth wrote:
13 Jun 2019 07:17
BattlePeasant wrote:
12 Jun 2019 18:53
Why does everyone want to make the game cheap, but ugly?
Not everyone does. Core developers get a fair bit of stick in these forums for not just committing any old thing. :twisted:

Bu there's nothing wrong with people making dirty hacks to try solving interesting problems. They just won't make get merged to OpenTTD master. :)
++ Had someone else implemented tunnel-stations and bridge-stations somehow? These "patches" of OpenTTD 1.9.1 work well. What may be ugly in them?
1) - Graphics of bridge-stations or tunnel-stations? - Of course, I didn't make any changes to graphics. It's not my task. I hope, some graphics developers will do a nice graphics for bridge-stations (especially) and for tunnel-stations... sometime.
(Existing tunnels and existing stations are looking good enough, when combined to a "complex" platforms, even "as is".)
2) - Some signals work not completely correctly with some complex platforms? - This was described nearby attached .exe files for downloading. I don't know by now, how the pathfinder algorithms are implemented, so, why don't they choose a free platforms in some cases, but wait until one of the busy platforms is released. And... Test station layouts are too "bad": one have test programs in the worst possible situations to see possible problems. But in more simple situations (with more simple complex platforms) these programs will work more correctly. Maybe. :)
3) - There is no new Advanced Settings added? - Yea. I didn't get there yet.
However, these Settings have to be stored in .sav files ("saves"), naturally, but changes to saves mean a new version of saves, i.e. they would be non-compatible with the current version of OpenTTD 1.9.1 stable, but saves from these "patches" are compatible (however there's no reason to use the "complex" stations inside OpenTTD 1.9.1 stable because trains on them will load and unload too-o-o long time).

My main purpose and task is to show to OpenTTD Developers, that this is easy enough to implement "complex" stations and tunnel-stations and bridge-stations in the existing code of OpenTTD, because they only can release these possibilities in a new version of OpenTTD. And, of course, I want very strongly to have these possibilities for myself.

User avatar
Wolf01
Tycoon
Tycoon
Posts: 2013
Joined: 24 Apr 2004 10:43
Location: Venezia - Italia
Contact:

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by Wolf01 » 15 Jun 2019 09:23

One of the problems isn't to show that's easy to add something, but it's the way that addition is presented, for example the guideline is to not touch the core gameplay, so it should be a feature which could be enabled or disabled, the code must be well written with the same style of the other code, and just don't push devs to add anything, last time I pushed the devs NRT was delayed for 2 years :D (just joking)

OTTD development board is filled with many interesting patches which IMHO should be added to the core game because make it more interesting, adding diversity to the gameplay or just eyecandy.

But the bigger problem is a bit more frustrating: should the new feature really work that way? Would it block more functions which could be added later? Could it be done differently?

My hopinion for this feature is this: it's interesting, I would use it in some situations, but I feel like it's not the right way to do it :roll:

Also with OTTD on github and all the compile farm revision, it should be possible to have your own OTTD version with your patch(es) to be tested by everyone, and if devs+community will find it really interesting and useful, it might be added soon or later

BW89
Engineer
Engineer
Posts: 80
Joined: 10 May 2015 11:42

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by BW89 » 21 Jun 2019 13:11

Wich Station should the Game expand in this example.
Or what is if you add a 9 Tile long bridge to station when the station limit is set to 7...
Unbenannt.png
Unbenannt.png (106.38 KiB) Viewed 1760 times

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9293
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by planetmaker » 21 Jun 2019 14:02

Just some random thoughts:

Currently I can build stations tile-by-tile. I expect that to remain, so that I can keep this (mentally) simple concept of just adding one more.

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.

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.

@BW89: good questions asked!

Eddi
Tycoon
Tycoon
Posts: 7415
Joined: 17 Jan 2007 00:14

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by Eddi » 21 Jun 2019 19:56

planetmaker wrote:
21 Jun 2019 14:02
Just some random thoughts:
to cut this short: none of that will be possible with this current approach, and it must be thrown away and started from scratch if any of these ideas are considered for implementation.
You might not exactly be interested in Ferion, but if you are, have fun :)

TopTechDreamer
Engineer
Engineer
Posts: 48
Joined: 22 Feb 2012 12:21
Location: Ukraine
Contact:

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by TopTechDreamer » 21 Jun 2019 20:01

BW89 wrote:
21 Jun 2019 13:11
Wich Station should the Game expand in this example.
Or what is if you add a 9 Tile long bridge to station when the station limit is set to 7...
Unbenannt.png
Both of these 2 stations. As You could read in the description to these 2 "patches" and in the discussion in this topic, a bridge or tunnel is not a part of any station - these objects only increase the "platform length" parameter of the directly adjacent platform (tiles). So, if one such platform belongs to the station A and the other - to the station B, this bridge will increase this parameter for each of these platforms, so, for both of them.

Bridge (or tunnel) doesn't increase the station, this mean the coverage area of station is determined by station tiles only. So, station with 9-Tile-long bridge can accept trains with train length = 9 (or 10) tiles without penalty to load-unload speed, but the coverage area of this station "B" is 9x9 tiles = the same, as for 1-tile railroad platform.

You can see this in action - just download and run 2 working prototypes of this "patch" from this post (07 Jun 2019 17:06) - viewtopic.php?p=1222681#p1222681 .

Maybe, You would prefer the more improved "patch" from this post (16 Jun 2019 23:01) - viewtopic.php?p=1222935#p1222935 . But there the bridge will become a parth of that station (will get the StationID of that station), where any train will come earlier.

Come on, better 1 time to see than several times to read about. :)

Bitte. :)

TopTechDreamer
Engineer
Engineer
Posts: 48
Joined: 22 Feb 2012 12:21
Location: Ukraine
Contact:

Re: Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent station tiles

Post by TopTechDreamer » 21 Jun 2019 23:05

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).

Post Reply

Return to “OpenTTD Suggestions”

Who is online

Users browsing this forum: Google Adsense [Bot] and 2 guests