Page 1 of 2

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

Posted: 11 May 2019 23:51
by TopTechDreamer
[Edited 20190607 21:33 : This TASK is SUCCESSFULLY IMPLEMENTED (as prototype) :!: - to DOWNLOAD .exe files
openttd 1.9.1 + 1 of 2 tunnels and bridges increase platform length OK++.exe.zip
openttd 1.9.1 + 2 of 2 tunnels and bridges increase platform length OK++.exe.zip
and for more detailed description of RESULTS - look at 20th post in this topic - viewtopic.php?p=1222681#p1222681 ]

Suggestion is: To add to Settings +1 option ('On' by default) :
Allow existing tunnels and bridges to increase "platform length" parameter for directly adjacent (existing) station tiles (of corresponding type and axis-direction).
Purpose is: to make "softer" limitations of loading-unloading speed for short platforms (with platform length < train length) by including the length of a bridge or a tunnel (with both its entrances) into the platform length parameter for directly adjacent ordinary station platform tile(s).

It means tunnels and bridges can be not stations, but they can work like a part of a station platform just due to the platform length parameter.
So bridges and tunnels can be not stations, but they can continue the station platforms.

This way we don't need to change anything in the logic (and the code) of the pathfinder algorithms, because they will work "as is" with existing station tiles.

It seems it is enough to modify functions, that describe limitations of loading-unloading speed depending on vehicle length and platform length.
Maybe, additionally those functions, that describe physics when train arrives to the station of destination and decreases speed to stop there (I think, it (the last) may be not necessarily).

What will be a consequence, what effects we will have as result? - It's easy to see: this option will allow players to use bridges and tunnels as parts of stations platforms, that in practice means the ability to build stations on bridges and in tunnels!


( With 1-side adjacent station tile the coverage area is significantly less then with 2-sides case --> the third picture: )

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

Posted: 12 May 2019 04:55
by kamnet
You can use the distant build feature (ctrl+leftmouse) to build a station linked on both ends of a bridge or tunnel.

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

Posted: 12 May 2019 11:05
by odisseus
To my understanding, this request is not about building disjoint pieces that belong to the same station (a. k. a. station walking). This is about treating a bridge attached directly to a platform as an extension of that platform. For example, a single tile platform next to a 4 tile bridge should work as a 5 tile long platform.

Unfortunately, this won't work right away and will require changes to the pathfinder. Currently a train approaching from the direction where the station tile is located will stop at the outer edge of that tile, and won't advance onto the bridge at all.

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

Posted: 12 May 2019 11:18
by Eddi
the changes needed to achieve this aren't actually that big. however, this is a complete dead end approach that, if actually implemented, would probably block a more flexible and appropriate re-implementation of the way that bridges are constructed (like, actual, real, signals on bridges, flexible bridge heads, or even crossings and bends on bridges)

thus, if you try to implement this, be aware that the likelyhood of that approach as presented here being included in master is near 0.

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

Posted: 12 May 2019 11:37
by acs121
odisseus wrote:To my understanding, this request is not about building disjoint pieces that belong to the same station (a. k. a. station walking). This is about treating a bridge attached directly to a platform as an extension of that platform. For example, a single tile platform next to a 4 tile bridge should work as a 5 tile long platform.

Unfortunately, this won't work right away and will require changes to the pathfinder. Currently a train approaching from the direction where the station tile is located, will stop at the outer edge of that tile, and won't advance onto the bridge at all.
The example you give in the picture can be easily achieved through a small patch - if you delete the platform length penalty for loading speed, then you simply have to give the train these orders :
"Go non-stop through X"
"Go to X"
IIRC Quast65 did a patch deleting the loading speed penalty, but I don't know if he shared it.

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

Posted: 12 May 2019 17:38
by TopTechDreamer
odisseus wrote:To my understanding, this request is not about building disjoint pieces that belong to the same station (a. k. a. station walking). This is about treating a bridge attached directly to a platform as an extension of that platform. For example, a single tile platform next to a 4 tile bridge should work as a 5 tile long platform.
Exactly! Right!
acs121 wrote:The example you give in the picture can be easily achieved through a small patch - if you delete the platform length penalty for loading speed. ...
Yes! But suggestion is not to delete the platform length penalty for loading speed at all, but only for platform tiles joined directly with adjacent bridge or tunnel (as special objects) to simulate complex stations (existing in real world). And it is very important, that such possibility will make 3D-world of OpenTTD much more rich, because it will allow players to build stations in fact in tunnels and on bridges. Pictures above show: it allows to build stations one above another (this is ++ 3D topology of the world of game) and above or under other objects of the OpenTTD world. For example, it will give much more place for cities to grow. Even more place for farms, industries, rivers and rain-forests... For any objects. :)

And... it would make OpenTTD even more beautiful then it is now. :)

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

Posted: 12 May 2019 19:10
by Transportman
But what would be the real gameplay value? I don't really see it.

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

Posted: 12 May 2019 20:02
by odisseus
For example, it would allow to build underground metro lines without demolishing half the city just to place the stations.

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

Posted: 12 May 2019 21:29
by acs121
Transportman wrote:But what would be the real gameplay value? I don't really see it.
There is a lot of value.
That means you can virtually build a station in many places : over a road, a river (like London Blackfriars), as an underground suburban / metro station, under the same road, or in airports.

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

Posted: 14 May 2019 16:14
by TopTechDreamer
Eureka!
Procedure UpdateLoadUnloadTicks(...) determines the platform length penalty for loading speed. It is in economy.cpp :

Code: Select all

/**
 * Update the vehicle's load_unload_ticks, the time it will wait until it tries to load or unload
 * again. Adjust for overhang of trains and set it at least to 1.
 * @param front The vehicle to be updated.
 * @param st The station the vehicle is loading at.
 * @param ticks The time it would normally wait, based on cargo loaded and unloaded.
 */
static void UpdateLoadUnloadTicks(Vehicle *front, const Station *st, int ticks)
{
	if (front->type == VEH_TRAIN) {
		/* Each platform tile is worth 2 rail vehicles. */
		int overhang = front->GetGroundVehicleCache()->cached_total_length - st->GetPlatformLength(front->tile) * TILE_SIZE;
		if (overhang > 0) {
			ticks <<= 1;
			ticks += (overhang * ticks) / 8;
		}
	}
	/* Always wait at least 1, otherwise we'll wait 'infinitively' long. */
	front->load_unload_ticks = max(1, ticks);
}

Here we can see:
"penalty" is obtained via: int overhang --> if (overhang > 0) {ticks <<= 1; ticks += (overhang * ticks) / 8; } --> front->load_unload_ticks = max(1, ticks);
/* where "front" is a Vehicle object with " if (front->type == VEH_TRAIN) ". */
Result is stored in the Vehicle object's property front->load_unload_ticks .
We can switch this "overhang-penalty" at all right here, for example, by the next modification (inside static void UpdateLoadUnloadTicks(...) ) :

Code: Select all

-		if (overhang > 0) {
+		if ( false && (overhang > 0) ) {
But, if we want do it not "at all", but for station platform tiles directly adjacent to bridge or tunnel entrances, then we need to modify (one of two virtual variants of) function GetPlatformLength(TileIndex tile) in station.cpp :

Code: Select all

/* virtual */ uint Station::GetPlatformLength(TileIndex tile) const
{
	assert(this->TileBelongsToRailStation(tile));

	TileIndexDiff delta = (GetRailStationAxis(tile) == AXIS_X ? TileDiffXY(1, 0) : TileDiffXY(0, 1));

	TileIndex t = tile;
	uint len = 0;
	do {
		t -= delta;
		len++;
	} while (IsCompatibleTrainStationTile(t, tile));

	t = tile;
	do {
		t += delta;
		len++;
	} while (IsCompatibleTrainStationTile(t, tile));

	return len - 1;
}
This function determines not only the economical interaction of train and station (platform), but also their physical interaction (via functions
int GetTrainStopLocation(StationID station_id, TileIndex tile, const Train *v, int *station_ahead, int *station_length)
and
int Train::GetCurrentMaxSpeed() const
from train_cmd.cpp :

Code: Select all

int GetTrainStopLocation(StationID station_id, TileIndex tile, const Train *v, int *station_ahead, int *station_length)
{
   const Station *st = Station::Get(station_id);
   *station_ahead  = st->GetPlatformLength(tile, DirToDiagDir(v->direction)) * TILE_SIZE;
   *station_length = st->GetPlatformLength(tile) * TILE_SIZE;
...

- this was already noticed in viewtopic.php?p=1221523#p1221523 ).

That's why it sets some limitations on station platform layout. The main limitation is check:
assert(this->TileBelongsToRailStation(tile));
/* This limitation can be avoided, but it is not so easy (it must be done much more accurately than the easiest variant). */
It means that the head of train must to be stopped on the station's railway platform. Else it will not work.
It means that the easiest way to achieve our goal is:

* Create stations with "2-sides platform tiles", i.e. at the first stage temporarily do not use the "1-side" layout (white stations layout - from pictures #2 and #3 in the first post of this topic - will not work some-like new at the easiest stage of modification because one of its ends is not a station platform tile but it is an entrance of bridge or tunnel, so the head of the train will not stop on the station tile).

* More: that's why train can stop only at the [far end] of platform, which includes bridge or tunnel object (else its head will not be on a station platform tile).

* First stage is - to change the loops (cycles) "do .. while" (in function Station::GetPlatformLength(...)) by inserting inside them some additional code, that will check if a bridge or a tunnel is included inside the station platform directly adjacent between two platform tiles ("2-sides" layout).


I think this all is easy to see and to understand for OpenTTD Developers.
And the main message is: there exist (the easiest variants of) modification, that do not break any other part of OpenTTD but allow players to build stations partially in tunnels or on bridges (that will change the game in revolutionary way).

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

Posted: 15 May 2019 12:27
by TopTechDreamer
It seems many troubles come from the illusion, that OpenTTD-world is a 2D-space (appealing to tile). But it is really a 3D-space!
This means if we will use not only X and Y coordinates of tile, but also Z coordinate (z_pos -ition) of train, then it can help to simplify procedures, that check and describe connection and further interaction between train (vehicle) and station, even if this station is not on the ground.

Actually, there are not so many variants, where may be train (or any ground vehicle) in case, when their z_pos-ition is different from the Z coordinate of tile (Tile->height). Most probably such situation may mean, that vehicle is in a tunnel under the ground (for example, when v->z_pos < Tile->height - 1) or on a bridge above the ground (for example, when v->z_pos > Tile->height + 1).
Additionally ground vehicles have so-called TRACK_BIT_WORMHOLE , for example, from tunnelbridge_cmd.cpp :

Code: Select all

static VehicleEnterTileStatus VehicleEnter_TunnelBridge(Vehicle *v, TileIndex tile, int x, int y)
{
...
	if (IsTunnel(tile)) {
		if (v->type == VEH_TRAIN) {
			Train *t = Train::From(v);

			if (t->track != TRACK_BIT_WORMHOLE && dir == vdir) {
				if (t->IsFrontEngine() && frame == TUNNEL_SOUND_FRAME) {
					if (!PlayVehicleSound(t, VSE_TUNNEL) && RailVehInfo(t->engine_type)->engclass == 0) {
						SndPlayVehicleFx(SND_05_TRAIN_THROUGH_TUNNEL, v);
					}
					return VETSB_CONTINUE;
				}
				if (frame == _tunnel_visibility_frame[dir]) {
					t->tile = tile;
					t->track = TRACK_BIT_WORMHOLE;
					t->vehstatus |= VS_HIDDEN;
					return VETSB_ENTERED_WORMHOLE;
				}
			}

			if (dir == ReverseDiagDir(vdir) && frame == TILE_SIZE - _tunnel_visibility_frame[dir] && z == 0) {
				/* We're at the tunnel exit ?? */
				t->tile = tile;
				t->track = DiagDirToDiagTrackBits(vdir);
				assert(t->track);
				t->vehstatus &= ~VS_HIDDEN;
				return VETSB_ENTERED_WORMHOLE;
			}
		} else if (v->type == VEH_ROAD) {
...
...
So, we always know if the vehicle is inside a tunnel or bridge (so-called "wormhole") or not.

A) So if it is inside, then we can let program cycle run along that "wormhole" until it comes to the end (entrance) or to both ends of the "wormhole", and further - to the directly adjacent station platform tile - to connect the vehicle with the station even if the vehicle's head (its front) is inside the "wormhole".
:roll:
Hm... It's not too elegant (to do it every time to connect the vehicle with the station), but it is relatively simple "patch". :?

B) Maybe, it will be more transparent way, if the vehicle can somehow write and store information about the station, who's part is the tunnel or the bridge? I mean to get and to write this information at that moment, when the vehicle is entering tunnel or bridge, and to store this information, while it stops and then while it is unloading and loading at this station. This means, while vehicle continue to interact with the station. After it can forget this information, when it leaves the station.
It seems it is not very simple to rebuild existing code this way. :?

But... both these ways are possible.

And the most easy case from my previous post stay possible.

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

Posted: 15 May 2019 20:17
by acs121
It's a bit simple to know for those who have played a lot of Minecraft like me, but X is for East-West, Y is for Up-Down Z is for North-South.
Yet the most used coordinates in OpenTTD are X and Z. Y coordinates are referred to as "altitude" rather than Y in OpenTTD.

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

Posted: 15 May 2019 20:22
by Eddi
acs121 wrote:It's a bit simple to know for those who have played a lot of Minecraft like me, but X is for East-West, Y is for Up-Down Z is for North-South.
Yet the most used coordinates in OpenTTD are X and Z. Y coordinates are referred to as "altitude" rather than Y in OpenTTD.
that is plain nonsense... there's no reason to use these silly minecraft coordinates, and that's why nobody does that.

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

Posted: 15 May 2019 21:15
by acs121
Eddi wrote:
acs121 wrote:It's a bit simple to know for those who have played a lot of Minecraft like me, but X is for East-West, Y is for Up-Down Z is for North-South.
Yet the most used coordinates in OpenTTD are X and Z. Y coordinates are referred to as "altitude" rather than Y in OpenTTD.
that is plain nonsense... there's no reason to use these silly minecraft coordinates, and that's why nobody does that.
What I meant is that this XYZ system is not just in Minecraft and that OpenTTD uses it too, but OpenTTD doesn't say something like Y : 50m or Y : 200m. While I can't cite a few games that use this system too in a few seconds, I recall many games using the XYZ system.

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

Posted: 16 May 2019 10:26
by Eddi
you have no clue what you're talking about. please stop.

3D coordinate systems are (usually) governed by the right hand rule, however, you can turn that hand any way you like. and OpenTTD does it different from Minecraft.

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

Posted: 16 May 2019 15:43
by acs121
I do have a clue what I'm talking about - you simply don't know what I'm saying.
The right-hand rule is used in OpenTTD as you said, but the terrain information tool does use this hand rule, with Y being the last coordinate (while it's normally XYZ).

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

Posted: 16 May 2019 22:26
by jfs
I can inform you that in the mother of all 3D games on the PC, Quake, "up" for the player is positive Z coordinates, and walking around on a floor moves the player in XY coordinates.
Which of Y or Z is considered "up" depends on the whim of the initial designer of that particular game engine, and in the case of OTTD the map is considered a 2D area with XY coordinates in the plane, and in the limited situations where height matters, the height is denoted Z. If you think this is abhorrent you should probably find a different game to concern yourself with, because this convention is not changing.

And since you like referencing Minecraft, you should probably also make yourself familiar with one of the other games that inspired Minecraft: Dwarf Fortress also considers Z as the up/down axis, and moving around on the ground is XY movement.

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

Posted: 17 May 2019 01:49
by kamnet
Okay, are we done with the posturing yet? I love you all, I really do, but let's stop. Thank you.

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

Posted: 17 May 2019 06:19
by andythenorth
kamnet wrote:Okay, are we done with the posturing yet? I love you all, I really do, but let's stop. Thank you.
Why don't we push pointless arguing as far as we can go?

https://xkcd.com/386/

Nobody has mentioned n-dimensional topographies yet.

https://xkcd.com/1166/

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

Posted: 07 Jun 2019 17:06
by TopTechDreamer
22nd Century Fox presents

Microsoft Visual Studios, Top Tech Dreams Community Editions, I'll Be Back Entertainment, Made In Ukraine production

in cooperation with... OpenTTD Developers Teem (somehow... it seems... maybe)


"On My Way" series (3D-Revolution of Stations)

Season 2, Epic episode 2


"Here they are! Again!"


Starring "station.cpp" and 2 modified /* virtual */ uint Station::GetPlatformLength functions, and... 2 .exe-s !

Based on true story of OpenTTD and its source code of version 9.1.1 [correction: 1.9.1]

With support of Windows XP SP3, Windows 8.1, Windows 10 (and so on) - all of 32 bit or 64 bit
(Tested with WinXP_SP3 32 bit, Win8.1 32 bit and Win10 64 bit.)

So, here they are :) :
[Edited 20190612: (These 2 .exe files - are simply "openttd.exe" v.1.9.1 renamed because they are some "patches". Just place these .exe files nearby your "openttd.exe" - in the same folder - and then run one of them instead of "openttd.exe".) ]
openttd 1.9.1 + 1 of 2 tunnels and bridges increase platform length OK++.exe.zip
Contains:
openttd 1.9.1 + 1 of 2 tunnels and bridges increase platform length OK++.exe
test19, 2277-02-28 test1of2 OK++ San Luis El Dorado Food Proc. 2.sav
(this .sav needs some NewGRF-s)
station.cpp (openttd 1.9.1 + modified 1 of 2 func. GetPlatformLength).cpp
(2.42 MiB) Downloaded 11 times
1 of 2 means: modified 1 of 2 func. Station::GetPlatformLength
This version works just like "openttd test NO PLATFORM PENALTY OK++.exe" from viewtopic.php?p=1222322#p1222322, but only with bridges, tunnels and platform tiles of other stations (1-tile-WayPoint-stations inserted inside the platform of the main station).
openttd 1.9.1 + 2 of 2 tunnels and bridges increase platform length OK++.exe.zip
Contains:
openttd 1.9.1 + 2 of 2 tunnels and bridges increase platform length OK++.exe
test19, 2277-02-28 test2of2 OK++ San Luis El Dorado Food Proc. 2.sav
(this .sav needs some NewGRF-s)
station.cpp (openttd 1.9.1 + modified 2 of 2 func. GetPlatformLength).cpp
(2.42 MiB) Downloaded 11 times
2 of 2 means: modified (both) 2 of 2 func. Station::GetPlatformLength
Therefore:
+++++ ( ! ) No need to insert 1-tile-WayPoint-stations inside the main station platforms to achieve correct stop position for trains by simple usual order "go-to <station>".
+ Trains brake more smoothly on complex platforms.
--- Path signals work not completely correctly with some complex platforms, so, that trains must wait sometimes more than needed. But... :)
++ Pre-signals work correctly for almost all cases with complex platforms. So, it may help - to use pre-signals instead of path signals in some such cases.
- Don't order trains to stop on WayPoint-stations inserted inside the main station platform, else they will stop and then will keep to stay there (infinitely) saying "Waiting for free path".

Both these versions have the "platform length penalty" back - for too short platforms, which are not combined with directly adjacent tunnels or bridges, or platform tiles of other stations - for example look at the station "San Luis El Dorado Food Proc. 2" in the attached .sav-es.

TASK: Existing tunnels and bridges increase "platform length" parameter for directly adjacent station tiles.
(Existing tunnels and bridges simulate continue of stations platforms!)
STATUS: IMPLEMENTED SUCCESSFULLY (except of not completely smoothly slowing on complex platforms and some inaccuracies in the functioning of the path signals, because pathfinder algorithms think, that train is already going out from platform, when train really doesn't do it yet, because real platform tiles are not directly adjacent between each other, but with other objects).

OpenTTD Developers, please, could you include into the OpenTTD stable (of the next versions) these 3 Settings:
1) A_SETTING_TBIPL (allow/enable TunnelBridge to Increase Platform Length).
2) A_SETTING_RUBIPL (allow/enable Rails Under Bridge to Increase Platform Length).
3) A_SETTING_OSIPL (allow/enable Other Station to Increase Platform Length).
( ...and, of course, + 1 more Setting "switch to OFF (to 0) penalty if(train->cached_total_length > station->GetPlatformLength())" (or, maybe, option to set custom value of parameter of "platform length penalty") :) )

ChangeLog:
Changes are ONLY in:
2 functions /* virtual */ uint Station::GetPlatformLength(..)
+ 2 additional strings in the beginning of "station.cpp":
#include "tunnelbridge_map.h"
#include "tunnelbridge.h"
---
That's all.


Thank you!