[Patch][WIP] YAAM - Yet Another Acceleration Model

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

User avatar
supermop
Tycoon
Tycoon
Posts: 1104
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by supermop »

Few things, starting with a crash report:
[+] Spoiler

Code: Select all

*** OpenTTD Crash Report ***

Crash at: Sat Nov 12 23:17:16 2016
In game date: 1993-10-15 (65)

Crash reason:
 Exception: E1212012
 Location:  7707C54F
 Message:   Assertion failed at line 91 of C:/MinGW/msys/1.0/home/Palo/trunk-r27505_yaam/src/pathfinder/yapf/../../tile_map.h: tile < MapSize()

OpenTTD version:
 Version:    r27505M YAAM v3 (2)
 NewGRF ver: 16006b71
 Bits:       32
 Endian:     little
 Dedicated:  no
 Build date: Nov  8 2016 10:57:38

Registers:
 EAX: 0028ADC4 EBX: 00000016 ECX: 00000000 EDX: 0008E3C8
 ESI: 752D3180 EDI: 00000000 EBP: 0028AE14 ESP: 0028ADC4
 EIP: 7707C54F EFLAGS: 00000246

 Bytes at instruction pointer:
 C9 C2 10 00 CC CC CC CC CC 8B FF 55 8B EC 56 8B 75 08 83 FE F4 72 18 83

Stack trace:
 E1212012 00000000 00000000 7707C54F 00000000 0028ADF8 7576FD81 000E0252
 752D64A8 752803E0 00012010 00000000 FFFFFFFF 0028AE14 7576FDC6 000E0252
 774DFAFA 774FB176 FFFFFFFF 00000024 0028AE80 005332C7 E1212012 00000000
 00000000 00000000 752D0290 0028AE80 75295E89 75295E8F 00000016 15F6769F
 0028B479 FFFFFFFF 0028B1D0 774DFAFA 774F977C 00000000 00000024 005332A0
 00000001 0028AE40 0028A968 0028FFC4 75258CD5 60F786A7 FFFFFFFE 0028B1B8
 75298EA2 00000016 FFFFFFFF 00610628 01126EA0 011290D8 00180014 00000037
 00000000 010002A7 00000000 000001B8 01010000 0028ADF0 7573DA6C 0028FFC4
 775358C5 00531A7A FFFFFFFE 774F2FDD 774F2BD5 00000000 01126EA0 00010003
 00000000 0028B0FC 01126E98 0028AF98 7576F808 010C0000 00000000 01126EA0
 00000001 0028B0FC 00000001 00000024 00000014 00000000 00E053C0 00000010
 000E0252 28970AC0 00000006 00000000 00000000 00000780 00000408 00000000
 000001AB 0028B0FC 000002AB 00000000 00007F01 00000000 00000001 0000003C
 50022080 00000040 00000028 00000000 00000000 00000229 752398DA 01126EA0
 014611D8 00000000 01126F04 01461244 00000192 0028B0F0 7576FAAC 00000010
 0028B479 FFFFFFFF 7576FAE4 00000001 0028AFCC 774EE0A3 2BF83CF8 00000291
 00000000 01460E04 00000000 7FFFFFFF 0099EB49 00000000 00000000 7576FAFC
 00000000 00000001 00000016 7FFFFFFF 00000000 752D2BD0 012D1950 7523A53A
 00000000 0028B038 7524A8C1 012D245C 0099EB49 00000016 0028B028 7FFFFFFF
 00000000 752D2BD0 012D1950 012D07D0 00000000 0028B068 7524A9C8 012D245C
 0000000A 00000016 00000000 012D1BEC 012D245D 752D2BD0 00000009 00000000
 0028B082 0028B080 006C5053 00000009 00000000 0000000A 00000000 00283931
 0028B479 0028B1D0 00000000 0028B09C 0000007F 0028B1D0 00E053C0 00000200
 0028B254 0028B0CC 770A59EA 00E053C0 00000000 0028B0C8 00E054BA 00E057C0

Operating system:
 Name:     Windows
 Release:  6.1.7601 (Service Pack 1)
 Compiler: GCC 4.6.2 "4.6.2"

Configuration:
 Blitter:      32bpp-anim
 Graphics set: OpenGFX (5580)
 Language:     C:\Users\D\Downloads\openttd-yaam-r27505_v3\openttd-yaam-r27505_v3\openttd-yaam-r27505_v3-win32\lang\english_US.lng
 Music driver: win32
 Music set:    NoMusic (0)
 Network:      no
 Sound driver: win32
 Sound set:    NoSound (2)
 Video driver: win32

Fonts:
 Small:  Arial
 Medium: Arial
 Large:  Arial
 Mono:   sprite

AI Configuration (local: 0):
  0: Human
 GS: Villages Is Villages (v9)

Libraries:
 FreeType:   2.4.10
 LZMA:       5.0.4
 LZO:        2.06
 PNG:        1.5.16
 Zlib:       1.2.8

Module information:
 C:\Users\D\Downloads\openttd-yaam-r27505_v3\openttd-yaam-r27505_v3\openttd-yaam-r27505_v3-win32\openttd.exe handle: 00400000 size: 11340247 crc: F4E437F3 date: 2016-11-08 10:00:11
 C:\Windows\SysWOW64\ntdll.dll handle: 774c0000 size: 1314112 crc: 93608EE0 date: 2016-10-07 15:15:47
 C:\Windows\syswow64\kernel32.dll handle: 75530000 size: 1114112 crc: 9E44F1CD date: 2016-10-07 15:12:57
 C:\Windows\syswow64\KERNELBASE.dll handle: 77070000 size: 275456 crc: 45A14613 date: 2016-10-07 15:12:57
 C:\Windows\syswow64\ADVAPI32.DLL handle: 76980000 size: 644096 crc: 86E352AD date: 2016-10-07 15:12:38
 C:\Windows\syswow64\msvcrt.dll handle: 75230000 size: 690688 crc: DAB48B3A date: 2011-12-16 07:52:58
 C:\Windows\SysWOW64\sechost.dll handle: 76af0000 size: 92160 crc: 80F53C42 date: 2015-05-25 18:01:39
 C:\Windows\syswow64\RPCRT4.dll handle: 74fc0000 size: 666112 crc: C5251337 date: 2016-10-10 15:16:24
 C:\Windows\syswow64\SspiCli.dll handle: 74db0000 size: 96768 crc: 068503D6 date: 2016-10-10 15:16:24
 C:\Windows\syswow64\CRYPTBASE.dll handle: 74da0000 size: 36352 crc: B815AC8B date: 2016-10-10 14:50:02
 C:\Windows\syswow64\GDI32.dll handle: 74e70000 size: 312832 crc: BC8F8159 date: 2016-05-18 16:10:23
 C:\Windows\syswow64\USER32.dll handle: 75700000 size: 833024 crc: DE2CD237 date: 2016-08-16 02:48:15
 C:\Windows\syswow64\LPK.dll handle: 75520000 size: 25600 crc: A9496E96 date: 2016-11-02 15:16:31
 C:\Windows\syswow64\USP10.dll handle: 74f00000 size: 627712 crc: A1594BC1 date: 2015-11-03 18:56:18
 C:\Windows\syswow64\IMM32.DLL handle: 76a40000 size: 119808 crc: 38DB5163 date: 2010-11-20 09:08:52
 C:\Windows\syswow64\MSCTF.dll handle: 76d40000 size: 829952 crc: F2BFEE17 date: 2016-10-11 15:18:29
 C:\Windows\syswow64\SHELL32.DLL handle: 759f0000 size: 12880384 crc: 6B0A3230 date: 2016-08-29 15:12:50
 C:\Windows\syswow64\SHLWAPI.dll handle: 76b40000 size: 350208 crc: 23E05F73 date: 2010-11-20 09:21:20
 C:\Windows\system32\WINMM.DLL handle: 71fd0000 size: 194048 crc: 849223C7 date: 2010-11-20 09:21:38
 C:\Windows\syswow64\WS2_32.dll handle: 75150000 size: 206336 crc: E20C855A date: 2016-05-11 15:19:26
 C:\Windows\syswow64\NSI.dll handle: 75130000 size: 8704 crc: 2ACE9671 date: 2009-07-14 01:16:11
 C:\Windows\system32\AirfoilInject3.dll handle: 717f0000 size: 166504 crc: C8F88409 date: 2013-03-02 22:17:34
 C:\Windows\syswow64\ole32.dll handle: 76640000 size: 1414144 crc: CE83A8C6 date: 2016-03-17 22:28:21
 C:\Windows\system32\uxtheme.dll handle: 64a30000 size: 245760 crc: 60C5C746 date: 2009-07-14 01:11:24
 C:\Windows\system32\dwmapi.dll handle: 65120000 size: 67584 crc: 0A7DEB75 date: 2015-07-09 17:42:54
 C:\Windows\syswow64\CLBCatQ.DLL handle: 75640000 size: 522240 crc: 6C130B8A date: 2009-07-14 01:15:03
 C:\Windows\syswow64\OLEAUT32.dll handle: 75800000 size: 581632 crc: 8B0C095A date: 2016-10-07 15:12:49
 C:\Windows\system32\mswsock.dll handle: 717b0000 size: 231424 crc: DD4CB3EB date: 2016-05-11 15:19:16
 C:\Windows\System32\wshtcpip.dll handle: 711d0000 size: 9216 crc: BA963A19 date: 2009-07-14 01:16:20
 C:\Windows\system32\MMDevAPI.DLL handle: 739c0000 size: 213504 crc: 93C0AA4F date: 2010-11-20 09:19:40
 C:\Windows\system32\PROPSYS.dll handle: 68ac0000 size: 988160 crc: 888D0BCB date: 2010-11-20 09:20:58
 C:\Windows\system32\wdmaud.drv handle: 56f70000 size: 172032 crc: D5B9F5FA date: 2010-11-20 09:16:52
 C:\Windows\system32\ksuser.dll handle: 73ed0000 size: 4608 crc: 1A5CD26B date: 2015-12-08 21:53:47
 C:\Windows\system32\AVRT.dll handle: 73ff0000 size: 14336 crc: 9818237B date: 2009-07-14 01:14:58
 C:\Windows\syswow64\SETUPAPI.dll handle: 76ba0000 size: 1667584 crc: 1D0104E8 date: 2010-11-20 09:21:16
 C:\Windows\syswow64\CFGMGR32.dll handle: 756d0000 size: 145920 crc: 377B5190 date: 2011-05-24 10:39:38
 C:\Windows\syswow64\DEVOBJ.dll handle: 74fa0000 size: 64512 crc: 66B02A5A date: 2011-05-24 10:40:05
 C:\Windows\system32\AUDIOSES.DLL handle: 73ac0000 size: 195072 crc: E762B1EF date: 2016-06-14 15:21:18
 C:\Windows\system32\msacm32.drv handle: 5b640000 size: 20992 crc: 73923147 date: 2009-07-14 01:14:08
 C:\Windows\system32\MSACM32.dll handle: 73f00000 size: 72192 crc: ABA25814 date: 2009-07-14 01:15:42
 C:\Windows\system32\midimap.dll handle: 59cf0000 size: 16896 crc: C000494C date: 2009-07-14 01:15:40
 C:\Windows\System32\wship6.dll handle: 6dd30000 size: 10752 crc: 99DFC9DA date: 2009-07-14 01:16:20
 C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live\WLIDNSP.DLL handle: 62e50000 size: 145280 crc: C6B238E9 date: 2010-09-21 19:03:14
 C:\Windows\syswow64\PSAPI.DLL handle: 76820000 size: 6144 crc: 25B988F9 date: 2009-07-14 01:16:12
 C:\Program Files (x86)\Bonjour\mdnsNSP.dll handle: 62e20000 size: 121704 crc: 8E29B27A date: 2011-07-12 15:20:50
 C:\Windows\system32\Iphlpapi.DLL handle: 71220000 size: 103936 crc: E8D425A2 date: 2010-11-20 09:19:24
 C:\Windows\system32\WINNSI.DLL handle: 71210000 size: 16896 crc: 484CAF17 date: 2009-07-14 01:16:19
 C:\Windows\system32\DNSAPI.dll handle: 71110000 size: 270336 crc: 93875418 date: 2011-03-03 05:38:01
 C:\Windows\system32\rasadhlp.dll handle: 71100000 size: 11776 crc: C799823B date: 2009-07-14 01:16:12
 C:\Windows\System32\fwpuclnt.dll handle: 62de0000 size: 216576 crc: 881C7EC0 date: 2013-10-12 02:01:25

---- gamelog start ----
Tick 0: new game started
Revision text changed to r27505M YAAM v, savegame version 197, modified, _openttd_newgrf_version = 0x16006b71
New game mode: 1 landscape: 2
Added NewGRF: GRF ID 4E480102, checksum 8D15ADBA3E86C6B5B22A088CF929F02B, filename: nhfoundationsw.grf (md5sum matches)
Added NewGRF: GRF ID 4A430002, checksum 93EAC5F5396584B92D4C5F0AAAF3F6C5, filename: industrial_stations_renewal-1.0.2\indstatr.grf (md5sum matches)
Added NewGRF: GRF ID 504A0103, checksum F4056FECA93218E2B1FC015B0C7844A2, filename: isrstyle_dock-1.3\isrdock_v1_3.grf (md5sum matches)
Added NewGRF: GRF ID 415A0301, checksum 8667797182D6F6C670D7BE5D677ACB45, filename: american_road_replacement_set-2.0.0\americanroads.grf (md5sum matches)
Added NewGRF: GRF ID 44440A80, checksum A930B079A5B8985E94EA823604CC276B, filename: av9.8-0.83\av9point8.grf (md5sum matches)
Added NewGRF: GRF ID 43485053, checksum 3C4699AA326D6397DA937AD436DE8906, filename: chips_station_set-1.7.0\chips.grf (md5sum matches)
Added NewGRF: GRF ID 4D4C0100, checksum 1E2A243600434194FB100E72E507D5EF, filename: dutch_catenary-1\dutchcatenary.grf (md5sum matches)
Added NewGRF: GRF ID F1250006, checksum 05978AF75D1A1ACC8D8FBEE2BC5061C9, filename: firs_2-2.1.5\firs.grf (md5sum matches)
Added NewGRF: GRF ID 4341121E, checksum 79EDFD5CAF3A893A1B0FB7A223039EF4, filename: iron_horse-1.9.1\iron-horse.grf (md5sum matches)
Added NewGRF: GRF ID 45530500, checksum D9BE5AFA481FC3E0A96E6EB72B455612, filename: japanese_stations-3.6\jpstations.grf (md5sum matches)
Added NewGRF: GRF ID 46727806, checksum BBE029FCDD7A16F85876D417FF318D23, filename: opengfx_trees-0.8.0\opengfx+trees.grf (md5sum matches)
Added NewGRF: GRF ID 4F472B34, checksum 136D889FDAEAA3491F8320248A04425C, filename: opengfx_landscape-1.1.2\ogfx-landscape.grf (md5sum matches)
Added NewGRF: GRF ID 4F472B31, checksum 4E0B2D42462F295F36AFBA90D239A323, filename: opengfx_trains-0.3.0\ogfx-trains.grf (md5sum matches)
Added NewGRF: GRF ID 414E0201, checksum 0DA3A80B986BC3C17C20CA4CE9CA26AA, filename: fish_2-2.0.3\fish.grf (md5sum matches)
Added NewGRF: GRF ID 41533031, checksum B21E7D6ADD69B1C07643939764FB4878, filename: swedish_houses-1.1.2\swehouses.grf (md5sum matches)
Added NewGRF: GRF ID 53455230, checksum D521E0541BD3353797A13F4C4B20C6D2, filename: swedish_rails-0.8.1\swedishrails.grf (md5sum matches)
Added NewGRF: GRF ID 9787EAFE, checksum D84B6167FFE0E22A1C5A994617E2ED0F, filename: road_hog-1.1.0\road-hog.grf (md5sum matches)
Tick 65147: settings changed
Setting changed: construction.train_signal_side : 1 -> 0
Tick 65147: settings changed
Setting changed: construction.train_signal_side : 0 -> 2
Tick 65147: settings changed
Setting changed: construction.train_signal_side : 2 -> 1
---- gamelog end ----

*** End of OpenTTD Crash Report ***

Game crashed as I over built a station tile with a different style platform. Station was attached to an airport. Not sure if that is helpful.

Other things I have noticed:

The YAAM accelleration model is very slow, even with modern, powerful trains. This is probably intended, for realism or otherwise, but it poses some scale problems on smaller maps (512 and below). If playing an original, 256^2 sized map, with a normal town and industry density, distances between junctions or stations are small enough that trains will spend a large amount of their time accelerating or decelerating. I understand this is part of the challenge, but it becomes extreme to the point of un-fun on compact maps. Not sure if a setting to change acceleration strength would help or not.

Compounding the above; when industries or towns are closer together, branches off the mainline become closer together. Due to OpenTTD's scale, we can't really space junctions several miles apart. With a long reservation ahead, more and more of the track near a junction becomes 'interlocked', with distant trains able to reserve a path that blocks traffic in both ways on the mainline, and delays cascading to affect other junctions. As trains take longer to re-accelerate from a red or yellow, busy trunk lines trend towards speeds stuck between 40-70 km/h. This can be partially relieved by making all junctions grade separated, but the point where this becomes necessary arrives much sooner than normal. Furthermore, it seems sort of contrary to the spirit of careful, realistic track design intended by this patch. It also means that mixed traffic or branching service is discouraged, whereas one of the dreams of having yellow signals in game is smoother integration of slow and fast trains.

It is still very difficult to run single track sections of any kind. A completely isolated single line with a single train will run at 15 km/h the entire time. It is not the end of the world to fill such a line with signals, but it does feel odd. Simple branches off the mainline are awkward both for trains entering or leaving, as the train will slow to yellow speed before it leaves the mainline and proceed along the entire branch as if about to stop. Even when the branch is small compared to the distance traveled on mainline, it can have a huge impact on journey time (see attached image)
Branch line.PNG
Branch line.PNG (98.3 KiB) Viewed 8865 times
Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.

Lastly, at stations; trains try to reserve a long path ahead if able, even when stopping at a station. At certain types of terminus, or where two tracks merge just past the station, this means a train can block a significant distance ahead for a long time while it loads. This can lead to a stopped local train blocking an express passing through, or a loading train blocking the station entrance at end of line.
Reservation beyond platform.PNG
Reservation beyond platform.PNG (89.53 KiB) Viewed 8865 times
In the attached image, the northern DMU has reserved track out onto the station throat, and will prevent the other DMU and scrap metal train from leaving, as well as a hypothetical train from entering. Additionally it is possible that one of these trains arriving from the north could trap a train in the depot. I'd suggest enforcing that reservations end at visited stations, and further reservations are not requested until the train departs.

An observation: diesels produce a ton of smoke while braking - hopefully they are not trying to use thrust reversers!

I still don't know how to treat block signals... unlimited speed at your own risk? two-aspect red/yellow only?

I hope this is helpful input, please don't take it as a complaint! Let me know if you want me to draw more signal types!
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

xZise wrote:
Karn wrote:[…]Key here is, the green/doubleyellow/yellow extending isn't universal, it would be actually too hard if you wanted one more block or color.[…]
Is that a basic part of OpenTTD or what makes this hard?
The way how I implemented this. There is nothing like simple logic. PBS and track reserving in trunk is one huge spaghetti code. YAAM and yellow PBS are built on pillars of this mess.

If you change something without thinking about every possibility, you will break something else. And here are too many things to break. Or that's just programming.

If you know something about programming, check the source code and try to think how to implement ETCS2. First step is preventing stackoverflow in that crazy recursion. Then if you want more colors, you need to solve how to put more than 4 colors into 2 bits (you can't). Etc. etc.

I don't wanna spend hundreds/thousands hours on implementing ETCS2, I have other things to do.
xZise wrote:
Karn wrote:[…]Also braking distance isn't predictable before reserving track with simple math (think about hills).
Okay I was assuming there is a way to change the reservation. If you could reserve more track later (aka block by block) you could increase the reserved paths until there is no free path left (or you reached another stopping point like a station) or you don't need any more track because the train can accelerate anyway. It does not require you to temporarily reserve track.
And there goes algorithmic complexity. If you compute something many times, it can have performance impact.
supermop wrote:Game crashed as I over built a station tile with a different style platform. Station was attached to an airport. Not sure if that is helpful.
Can't reproduce this, I'd need more details.
supermop wrote:Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.
Hmm what should happen if I place more distant signals in a row?
supermop wrote: Lastly, at stations; trains try to reserve a long path ahead if able, even when stopping at a station. At certain types of terminus, or where two tracks merge just past the station, this means a train can block a significant distance ahead for a long time while it loads. This can lead to a stopped local train blocking an express passing through, or a loading train blocking the station entrance at end of line.
OH **** , I swear I fixed this before posting v3, seems like there is more to fix.
supermop wrote:An observation: diesels produce a ton of smoke while braking - hopefully they are not trying to use thrust reversers!
So do electric trains, I hoped nobody will notice :D Ik why, changing that is just TMWFTLB.
supermop wrote:I hope this is helpful input, please don't take it as a complaint! Let me know if you want me to draw more signal types!
Nah you seem to be nice :D Well, I don't need it yet, for testing purpose are reused PBS sprites enough. I don't have done anything yet and I don't know when it will be done. Your work has value only if there will be working code. I think it's good idea to wait if I can make new meaningful signal type. Then there will be place for drawing. Thanks anyway. :)
User avatar
supermop
Tycoon
Tycoon
Posts: 1104
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by supermop »

Karn wrote:supermop wrote:Game crashed as I over built a station tile with a different style platform. Station was attached to an airport. Not sure if that is helpful.Can't reproduce this, I'd need more details.
In case the crash report wasn't sufficient, I am attaching the other crash files here:
YAAM Crash.7z
(528.7 KiB) Downloaded 164 times
As far as I can tell, it may have been caused by overbuilding a station tile that had a path reserved through it.
Karn wrote:Hmm what should happen if I place more distant signals in a row?
It seems to me that there are two basic functions to signals, in game and also in life: 1) don't let trains crash into one another, and, more importantly in most games; 2) by careful configuration to prevent a train obstructing another in it's movement. All of the consideration that goes into placing pre-signals and path signals in game is in pursuit of minimizing trains getting blocked, or worse, stuck. This patch adds another function, also found in the real world, to give trains information about when to reduce speed.

ON the single track branch problem, we want out train to be aware of the end of the line and be able to brake appropriately. We also do not want our train to slow to a low speed while still on the mainline when it has plenty of distance left to travel. Leaving the branch un-signaled will cause the train to brake prematurely,y proceeding slowly down the line and possibly slowing other trains on the mainline. Signaling the branch, however, could permit a second train down the line that ends up trapping the first train. What we need is a way to provide the information to brake without providing the 'safe waiting point' function of a PBS. I envision that such signals would essentially be yellow or green only: regardless of how many are placed, the 'starter signal' will only admit a train to the branch if it can reserve all the way to a safe waiting point, the yellow/green only signals simply tell when the train starts to brake. Otherwise I guess the look-ahead function would need to be changed to behave differently on long single tracks somehow? Or some type of path based pre-signal that will only go to clear or caution if there is a string of green or yellows all the way to the next safe stopping point?
Karn wrote:OH **** , I swear I fixed this before posting v3, seems like there is more to fix.
No problems - that's the reason I am testing weird station configurations, to find bugs.


Question: will the yellow signals still work on realistic acceleration instead of YAAM? In case someone wants the functionality but their play-style is more fun with stronger brake performance?

Thanks!
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

supermop wrote:As far as I can tell, it may have been caused by overbuilding a station tile that had a path reserved through it.
Station overbuilding is fine, it just re-reserve tracks. Block signal in wrong direction after station is the real reason. (see image) I'll try to fix this soon with other things (I hope this week). Thanks for report.
crash.png
crash.png (516.95 KiB) Viewed 8766 times
supermop wrote:It seems to me that there are two basic functions to signals, in game and also in life: 1) don't let trains crash into one another, and, more importantly in most games; 2) by careful configuration to prevent a train obstructing another in it's movement. All of the consideration that goes into placing pre-signals and path signals in game is in pursuit of minimizing trains getting blocked, or worse, stuck. This patch adds another function, also found in the real world, to give trains information about when to reduce speed.

ON the single track branch problem, we want out train to be aware of the end of the line and be able to brake appropriately. We also do not want our train to slow to a low speed while still on the mainline when it has plenty of distance left to travel. Leaving the branch un-signaled will cause the train to brake prematurely,y proceeding slowly down the line and possibly slowing other trains on the mainline. Signaling the branch, however, could permit a second train down the line that ends up trapping the first train. What we need is a way to provide the information to brake without providing the 'safe waiting point' function of a PBS. I envision that such signals would essentially be yellow or green only: regardless of how many are placed, the 'starter signal' will only admit a train to the branch if it can reserve all the way to a safe waiting point, the yellow/green only signals simply tell when the train starts to brake. Otherwise I guess the look-ahead function would need to be changed to behave differently on long single tracks somehow? Or some type of path based pre-signal that will only go to clear or caution if there is a string of green or yellows all the way to the next safe stopping point?
And do you want signal type for this one side track situation? Or do you want something more general? For this situation would be enough if previous PBS would be always green. No reservation extending after distant signal, one signal color (red is not necessary in my opinion). I think it's easy to do it, but I'm not sure if this implementation uses whole potential of "not safe waiting position".
supermop wrote:Question: will the yellow signals still work on realistic acceleration instead of YAAM? In case someone wants the functionality but their play-style is more fun with stronger brake performance?
Atm nope, I kept realistic acceleration intact. Maybe there is inconsistent behaviour somewhere, because I forgot to separate something but generally it works exactly like in YPS patch (no braking).
In the future will be more reasonable to make parameter for accelerating speed in the yaam. Or I don't know. I wanted to avoid changing old trunk behaviour. When someone likes instant stopping with realistic AM, why to take it away from him.
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

Version 4 in first post.

I decided to separate 1 block reservation and 3 block reservation path signals. Hopefuly this can help in certain configurations. Also added parameter for acceleration speed. It brings question if it shouldn't be in Yellow Path Signals patch too.
supermop wrote:Let me know if you want me to draw more signal types!
If you are still interested, would be cool to have different graphics for 3 block reservations signals. (I can't use basic path signals graphics, i still need yellow there for consistency(not just visual))
User avatar
supermop
Tycoon
Tycoon
Posts: 1104
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by supermop »

Karn wrote: If you are still interested, would be cool to have different graphics for 3 block reservations signals. (I can't use basic path signals graphics, i still need yellow there for consistency(not just visual))
I'd be up for drawing some more - can you tell me a bit more about what you are thinking, and how the 1-block differs from vanilla PBS?
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

supermop wrote:
Karn wrote: If you are still interested, would be cool to have different graphics for 3 block reservations signals. (I can't use basic path signals graphics, i still need yellow there for consistency(not just visual))
I'd be up for drawing some more - can you tell me a bit more about what you are thinking, and how the 1-block differs from vanilla PBS?
Here is explanation picture and ofc you can try in game :D
Attachments
vis.png
vis.png (22.6 KiB) Viewed 8482 times
User avatar
supermop
Tycoon
Tycoon
Posts: 1104
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by supermop »

Ok - can the 1-block yellow signal ever show a green aspect? Or does it it only show yellow and red (I can't test at the moment).
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

Technically it can show green. If you turn off the patch, it should show green. And there is that optimalization with block signals/stations which use every color (I can change that though).

In normal cases it should be just yellow/red.
User avatar
supermop
Tycoon
Tycoon
Posts: 1104
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by supermop »

Would you prefer a 2-lens look for just yellow and red (we have a few like this on the NYC subway on speed restricted areas and in the midpoints of stations), and then the 'yellow' is 'green' when YAAM is turned off?

Or a 3-lens version with the green lens always dark?
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

I was thinking more about this. And i realised that with 2 more signals we cant turn off yellow color. Probably it will be only yellow/red.

2-lens NYC sounds cool.
marinesciencedude
Engineer
Engineer
Posts: 3
Joined: 25 May 2017 18:42

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by marinesciencedude »

Karn wrote:
supermop wrote:Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.
Hmm what should happen if I place more distant signals in a row?
If this is a problem then they would need to require a stop signal as well to function (like pre-signals; https://en.wikipedia.org/wiki/Railway_s ... nt_signals). Also, the semaphore path signal appears to have the distant/stop signals the wrong way round (https://en.wikipedia.org/wiki/Railway_s ... nt_signals), and the rest of the UK (EDIT: 'Drive on Left Side' Option) semaphores are also lower quadrant as opposed to this mod's upper quadrant (despite the fact that the latter replaced them in the '20s [https://en.wikipedia.org/wiki/Railway_s ... r_quadrant] - three decades before TTD's starting date and 10 years before TT's starting date). Then again, I'm probably in the wrong place to talk about consistency with real life (even though I'm pretty sure I am).
User avatar
MinchinWeb
Traffic Manager
Traffic Manager
Posts: 225
Joined: 01 Feb 2011 12:41
Contact:

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by MinchinWeb »

It's an interesting problem so I'm glad you're thinking about it.

As I think about this in regards to my own gameplay, I think it could be useful to solve two particular issues I run into:
  • on merges, to give priority to the train currently running at speed, and
  • on congested mainlines, to allow trains to flow at reduced speed rather than fits of starts and stops.
Alberta Town Names - 1500+ real names from 'Acme' to 'Zama City'
MinchinWeb's Random Town Name Generator - providing 2 million plus names...
WmDOT v13 - An AI that doubles as your highway department
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

marinesciencedude wrote:
Karn wrote:
supermop wrote:Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.
Hmm what should happen if I place more distant signals in a row?
If this is a problem then they would need to require a stop signal as well to function (like pre-signals; https://en.wikipedia.org/wiki/Railway_s ... nt_signals). Also, the semaphore path signal appears to have the distant/stop signals the wrong way round (https://en.wikipedia.org/wiki/Railway_s ... nt_signals), and the rest of the UK (EDIT: 'Drive on Left Side' Option) semaphores are also lower quadrant as opposed to this mod's upper quadrant (despite the fact that the latter replaced them in the '20s [https://en.wikipedia.org/wiki/Railway_s ... r_quadrant] - three decades before TTD's starting date and 10 years before TT's starting date). Then again, I'm probably in the wrong place to talk about consistency with real life (even though I'm pretty sure I am).
So I almost implemented distant signal (1 block PBS), except it has red aspect and reserve path one tile later. I see flaw in current implementation too, because it still reserve too far and too soon. I'll try to change it to distant signal, which can be more useful.

This patch has goal of making TTD more consistent with real life, place is right :D But I'm not the person who can answer this.
MinchinWeb wrote:It's an interesting problem so I'm glad you're thinking about it.

As I think about this in regards to my own gameplay, I think it could be useful to solve two particular issues I run into:
  • on merges, to give priority to the train currently running at speed, and
  • on congested mainlines, to allow trains to flow at reduced speed rather than fits of starts and stops.
Those 2 problems are actually even worse. Yellow can bring solution to this, but every magic comes with a price. The price can be track performance. Basic concept I haven't realise before is, that yellow increase distance between trains. Although trains will move more fluent, their frequency is reduced. Lower throughput appears to be cost of braking and realism. But I didn't test this much, I can be wrong.
Seph
Engineer
Engineer
Posts: 16
Joined: 28 Mar 2012 14:17

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Seph »

Karn wrote:Those 2 problems are actually even worse. Yellow can bring solution to this, but every magic comes with a price. The price can be track performance. Basic concept I haven't realise before is, that yellow increase distance between trains. Although trains will move more fluent, their frequency is reduced. Lower throughput appears to be cost of braking and realism. But I didn't test this much, I can be wrong.
I think it depends on the train. The faster trains accelerate, the better the current model.

But for more realistic, slowly accelerating trains, not coming to a complete stop as often should increase throughput.

Of course, a system with one signal per piece of track will work optimally for both cases with the current braking system, but it's pretty ridiculous.
marinesciencedude
Engineer
Engineer
Posts: 3
Joined: 25 May 2017 18:42

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by marinesciencedude »

Karn wrote: So I almost implemented distant signal (1 block PBS), except it has red aspect and reserve path one tile later. I see flaw in current implementation too, because it still reserve too far and too soon. I'll try to change it to distant signal, which can be more useful.

This patch has goal of making TTD more consistent with real life, place is right :D But I'm not the person who can answer this.
Good to hear it, let's move on!

The problem with the distant signal having a red aspect (stop) is that it would be more like the combined signals, but you haven't mentioned the green aspect (clear) yet. I'll have to deal with this compromise until consistency with real life is eventually achieved or when I can help with the patch (which I'm not sure will happen any time soon).
User avatar
Leanden
Tycoon
Tycoon
Posts: 2613
Joined: 19 Mar 2009 19:25
Location: Kent

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Leanden »

Any more progress on this Karn?
Image
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

Progress is slow, fixed few bugs, I'll make version 5 when there will be more content.
I also decided to put it on github https://github.com/Palo123/openttd_yaam
Video showing what's about unsafe version (it's just demo-hack, doesn't work in other cases yet)

User avatar
Valle
Transport Coordinator
Transport Coordinator
Posts: 284
Joined: 15 May 2007 11:35
Location: Germany

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Valle »

I really like the concept of this acceleration model, because I think that it would increase player focus towards choosing vehicles that are well-suited for their actual operations and ensuring that the infrastructure supports the speeds they aim for. With the excessive acceleration across the board in the current "Realistic" model (augmented by the fact that the launch tractive effort is maintained as continuous tractive effort), passenger trains are mainly purchased based on their top speed properties, because they almost universally offer strong acceleration and spend most of their time cruising at top speed. This leads to services with very frequent stops being operated with vehicles capable of high top speeds, even if they would rarely be achieved on such a service realistically, rendering other vehicle types that are technically better-suited in real life obsolete due to this distorted focus.

Seeing that you're also active with Realistic Train Shunting, Karn, I'd like to ask you: has any more work on this acceleration model happened since the last update?
Karn
Traffic Manager
Traffic Manager
Posts: 128
Joined: 02 Oct 2011 18:56

Re: [Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Karn »

Valle wrote: Seeing that you're also active with Realistic Train Shunting, Karn, I'd like to ask you: has any more work on this acceleration model happened since the last update?
Currently I'm too busy with personal life. Both yaam and rts are on hold until I find free time for it.

When it comes to priorities, I would like to finish shunting patch first and after it's done, then work on yaam again. Shunting patch is more rewarding to develop.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 10 guests