IRC logs for #openttd on OFTC at 2022-08-04
⏴ go to previous day
00:42:55 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
00:43:00 *** WormnestAndroid has joined #openttd
01:27:46 *** Elouin has quit IRC (Quit: Ping timeout (120 seconds))
02:16:30 *** tokai|noir has joined #openttd
02:16:30 *** ChanServ sets mode: +v tokai|noir
02:16:57 *** Wormnest has quit IRC (Quit: Leaving)
02:23:04 *** tokai has quit IRC (Ping timeout: 480 seconds)
02:42:30 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:13:56 *** wallabra_ has joined #openttd
03:18:02 *** wallabra has quit IRC (Ping timeout: 480 seconds)
03:18:02 *** wallabra_ is now known as wallabra
06:27:44 *** sla_ro|master has joined #openttd
07:25:22 *** sla_ro|master2 has joined #openttd
07:25:36 *** sla_ro|master2 has quit IRC ()
07:32:01 *** sla_ro|master has quit IRC (Ping timeout: 480 seconds)
08:19:17 *** sla_ro|master has joined #openttd
09:01:48 *** D-HUND is now known as debdog
09:42:06 *** wallabra has quit IRC (Ping timeout: 480 seconds)
10:13:12 *** sla_ro|master has quit IRC ()
12:41:01 *** sla_ro|master has joined #openttd
13:43:47 *** Flygon_ has joined #openttd
13:50:42 *** Flygon has quit IRC (Ping timeout: 480 seconds)
14:03:35 *** virtualrandomnumber has joined #openttd
14:18:16 *** berndj has quit IRC (Ping timeout: 480 seconds)
14:20:56 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
14:40:24 *** Eddi|zuHause has quit IRC (Remote host closed the connection)
14:44:03 *** Eddi|zuHause has joined #openttd
15:12:46 *** wallabra has joined #openttd
15:25:49 *** debdog has quit IRC (Quit: Initiating getting-the-hell-out-of-here maneuver!)
15:36:23 *** frosch123 has joined #openttd
16:06:27 *** ufo-piloot has quit IRC (Ping timeout: 480 seconds)
16:10:51 *** ufo-piloot has joined #openttd
16:28:25 *** Wormnest has joined #openttd
16:33:17 *** Flygon__ has joined #openttd
16:40:14 *** Flygon_ has quit IRC (Ping timeout: 480 seconds)
16:41:40 *** HerzogDeXtEr has joined #openttd
16:51:56 *** Eddi|zuHause has quit IRC (Read error: Connection reset by peer)
16:54:19 *** Eddi|zuHause has joined #openttd
17:26:03 *** gelignite has joined #openttd
17:28:26 *** sundriedpotato has joined #openttd
17:34:16 <sundriedpotato> Hey, can a dev or someone knowledgeable give a quick explanation of why "realistic bi-directional track" was never implemented? Was there a technical difficulty with weak reservations? Performance issue? Or was it deemed just not necessary or fun, or "too good"?
17:36:47 <frosch123> no idea what you digged up :) "realistic bi-directional track" does not ring any bell
17:37:02 <nielsm> do you mean single-track sections with multiple signals in both directions, where the first train to enter the single-track section reserves the entire section ahead?
17:37:32 <frosch123> however, with two-way pbs you can do bidirectional tracks, and jgrpp has even more signals with secondary pbs reservatons
17:37:33 <nielsm> but only in a "soft" way so another train could follow it in the same direction
17:38:01 <Rubidium> I reckon the quick explanation is: nobody implemented an acceptable/maintainable version (this include the case: nobody implemented it)
17:38:20 <nielsm> you can split a single-track section into two with the current PBS in main, but you can't split it into more than two in a non-deadlocking way
17:38:41 <frosch123> sundriedpotato: ok, that page is 15 years old or older. it refers to a time before the current path signals were implemented
17:39:07 <frosch123> so i guess the answer to your original question is: it has been implemented, more than 10 years ago
17:39:24 <sundriedpotato> hm, what I'm talking about is more to do with bi-directional on TWO parallel tracks, to allow overtaking by faster trains, but without deadlocks
17:39:54 <sundriedpotato> I don't think that's possible in the current game, or are you saying jgrpp does this?
17:41:39 <frosch123> what you linked is possible in vanilla with regular path signals
17:41:54 <frosch123> it just looks different than on the old mockup, obviously
17:42:14 <nielsm> A will work but B will not
17:43:14 <frosch123> jgrpp has signals, where trains can reserve multiple path sections in advance, so you can probably have better decisions on what overtaking means
17:43:50 <nielsm> I've wanted to port the programmable path signals from JGRPP but it's a huge detangling work
17:44:21 <sundriedpotato> frosch123: really? I just assumed it's not possible without trying it because AFAIK the current path signals are very similar to Factorio's chain signals which do not allow it, because there's no concept of a "weak reservation" which is apparently necessary.
17:44:58 <sundriedpotato> and the YAPP page says "but without realistic bi-directional double track" but I guess it's outdated because that page itself was last updated in 2011?
17:45:35 <frosch123> vanilla pbs has not changed since 2008, but the wiki is written by random people, it's not universally true :)
17:48:14 <sundriedpotato> not sure, I'll have to check it out in more detail later, but I guess it could be made to work that way if it's programmable
17:48:40 <nielsm> this shows exactly how it can be built with the JGRPP feature
17:52:22 <sundriedpotato> huh ok, I don't understand it right now but it looks extremely powerful so I'll give it a try later :)
17:54:39 <nielsm> oh, that kind of bidirectional working
17:55:13 <nielsm> if you have crossovers at every signal then that works with vanilla just fine
17:58:14 <sundriedpotato> really? but there are no weak reservations (without using the logic programming) right? because without that I think it would cause either deadlocks in certain situations (if an overtaking train is too greedy) or an overtaking train cutting off a slower train unnecessarily
17:59:31 <nielsm> oh yeah you're right, you can get two pairs of trains staring each other down
18:00:27 <sundriedpotato> the idea of the weak reservation is that a strong reservation can push it away. without that ability the overtaking train has to either reserve its optimal route at the getgo (which seems infeasible) or it may cut off slower trains
18:02:20 <sundriedpotato> (however if an oncoming train wants to make a strong reservation, then the overtaking train is forced back into the right lane, ahead of any slower train already in that lane)
18:04:16 <nielsm> the solution in this case would be the "Reserve through" action of the Routefinding restrictions in JGRPP
18:04:26 <sundriedpotato> ((unless it can see that there's +1 free block which can fit the slow train, in which case the overtaking train may wait at the signal and go after the slow train, according to that article, but that sounds a bit much to me))
18:04:48 <nielsm> that will force the train that has chosen to go to that signal to also reserve a route past that signal
18:05:06 <nielsm> so it will be required to find a route that does not have it potentially stop and wait on the wrong-side track
18:06:02 <nielsm> and the result would also be that it will (presumably) reserve the path back to the right-side track, which will make the slow train have to potentially stop at the signal for the overtaking train
18:08:46 <nielsm> (based on a real-world line in denmark)
18:13:52 <sundriedpotato> is it still true that as soon as a fast train moves into the opposite lane it has already chosen its exit signal (with a strong reservation)? because if yes, then that sounds like it'd be very difficult to choose the optimal route as you'd have to predict the movement of every other train that could come the opposite way, even far away, instead of just letting the train move back into its lane as needed
18:14:14 <sundriedpotato> (using only a small lookahead to ensure there's always one free block available to accommodate it if necessary)
18:15:41 <sundriedpotato> I mean it sounds to me like it would definitely be POSSIBLE to do it optimally with the programmable signals / routefinding restrictions, but it'd have to be tailored to specific sections of track
18:17:13 <sundriedpotato> but I should probably get some experience with it before saying more...
18:17:32 <nielsm> you can do some things with long reservations, reserve through, and pathfinding penalties to make it deadlock-free
18:18:43 <nielsm> at least it feels like that to me, but it'd be a long argument and require a bunch of graphics and stuff to show it working
18:18:53 <nielsm> not really convenient to do on IRC
18:20:33 <nielsm> the main thing is: if you can guarantee that the train that moves into the wrong-way track to pass another train, will also reserve a path back to the right-way track, then it should be deadlock-free, because that guarantees that trains don't have to stop on the wrong side of the track
18:22:48 <sundriedpotato> yeah, that I agree with. my concern is that this path (which is reserved at the outset and be adjusted dynamically if I understand correctly) won't necessarily (or even most of the time) be optimal
18:23:49 <sundriedpotato> it'll either be very long and thus block oncoming trains a great distance away, or it'll be too conservative and block slower trains unnecessarily, or perhaps randomly somewhere in the middle
18:24:03 <nielsm> no the reservation of a train can't change once it's set, the only thing that could undo the reservation is if the train crashes or you manually stop and reverse it
18:24:43 <nielsm> and it can't reserve through a signal that's red at the time of reservation
18:26:39 <sundriedpotato> yeah, by block I mean "force to wait until that overtaking train is out of the way", not deadlock
18:26:51 <sundriedpotato> preventing deadlocks seems easier to me
18:27:29 <sundriedpotato> weaving the optimal path around a slow train seems the tricky bit
18:29:34 <sundriedpotato> although even with the system I was describing I'm not sure there wouldn't be cases where it cause undesirable behavior such as a train attempting to overtake only to have to file back in line before it's able to actually overtake, causing overall slowdown to oncoming traffic
18:29:57 <nielsm> you can do some things with long reserves, but it does get more tricky yes if you don't want either train to stop and wait
18:30:03 <sundriedpotato> (which is partly why I came here to ask, thinking maybe this had come up during testing)
18:31:25 <nielsm> and btw no, the "maybe works in vanilla" setup above does not work
18:31:38 <sundriedpotato> but with these very advanced features in JGRPP it might be possible to do it even more optimally, I mean what you showed me just looks so powerful and I didn't know that existed, but I feel like it's going to require a lot of fiddling on a per-track-section basis
18:33:22 <nielsm> I think it would be possible to build the rules for the signals so they can be shared between the signals, instead of having to program each one individually
18:40:04 <sundriedpotato> fantastic, I'm looking forward to playing around with it :) thanks for the friendly chat!
18:52:56 *** sundriedpotato has quit IRC (Remote host closed the connection)
19:49:33 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
20:02:37 *** Flygon__ has quit IRC (Read error: Connection reset by peer)
20:08:34 *** gelignite has quit IRC (Quit: Stay safe!)
20:32:36 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:31:27 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:41:32 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:03:13 *** ufo-piloot has quit IRC (Remote host closed the connection)
22:03:25 *** ufo-piloot has joined #openttd
22:14:22 *** Samu has quit IRC (Ping timeout: 480 seconds)
22:15:44 *** sla_ro|master has quit IRC ()
22:16:38 *** Wormnest has joined #openttd
22:28:52 *** WormnestAndroid has joined #openttd
22:51:33 *** debdog has quit IRC (Ping timeout: 480 seconds)
22:52:24 *** D-HUND is now known as debdog
23:36:55 *** esselfe has quit IRC (Remote host closed the connection)
23:45:25 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:51:00 *** esselfe has joined #openttd
continue to next day ⏵
