Times are UTC Toggle Colours
00:42:55 *** WormnestAndroid has quit IRC 00:43:00 *** WormnestAndroid has joined #openttd 01:27:46 *** Elouin has quit IRC 01:27:52 *** Elouin has joined #openttd 02:16:30 *** tokai|noir has joined #openttd 02:16:30 *** ChanServ sets mode: +v tokai|noir 02:16:57 *** Wormnest has quit IRC 02:23:04 *** tokai has quit IRC 02:39:08 *** D-HUND has joined #openttd 02:42:30 *** debdog has quit IRC 02:47:27 *** glx has quit IRC 03:13:56 *** wallabra_ has joined #openttd 03:18:02 *** wallabra has quit IRC 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 08:19:17 *** sla_ro|master has joined #openttd 09:01:48 *** D-HUND is now known as debdog 09:17:52 *** Flygon has joined #openttd 09:24:15 *** Samu has joined #openttd 09:42:06 *** wallabra has quit IRC 10:13:12 *** sla_ro|master has quit IRC 12:12:16 *** glx has joined #openttd 12:12:16 *** ChanServ sets mode: +v glx 12:41:01 *** sla_ro|master has joined #openttd 13:43:47 *** Flygon_ has joined #openttd 13:50:42 *** Flygon has quit IRC 14:03:35 *** virtualrandomnumber has joined #openttd 14:18:16 *** berndj has quit IRC 14:19:16 *** berndj has joined #openttd 14:20:56 *** virtualrandomnumber has quit IRC 14:23:36 *** nielsm has joined #openttd 14:40:24 *** Eddi|zuHause has quit IRC 14:44:03 *** Eddi|zuHause has joined #openttd 15:12:46 *** wallabra has joined #openttd 15:25:49 *** debdog has quit IRC 15:36:23 *** frosch123 has joined #openttd 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 16:41:40 *** HerzogDeXtEr has joined #openttd 16:51:56 *** Eddi|zuHause has quit IRC 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:31 <sundriedpotato> sorry, this is what I'm taking about: it's from 2007 apparently, so quite old now... https://wiki.openttd.org/en/Archive/Community/Realistic%20Path%20Based%20Signalling#bi-directional-double-track-in-the-proposed-new-pbs-system 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:09 <nielsm> https://i.imgur.com/vu9x3Bk.jpeg 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:20 <nielsm> yeah 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:23 <frosch123> sundriedpotato: https://github.com/JGRennison/OpenTTD-patches/wiki/Signalling#slots <- is that what you are looking for? 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:29 <nielsm> https://github.com/JGRennison/OpenTTD-patches/wiki/Signalling#example-4-bidirectionally-signalled-lines 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:08 <sundriedpotato> doesn't look like quite the same track setup tho, what I meant is this specific situation: https://wiki.openttd.org/File/en/Archive/Community/Rpbs%20img12.png but I'm probably not seeing the underlying conceptual similarity 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:25 <nielsm> another thing that could be made to work would be bidirectional track like this: https://i.imgur.com/0mwwS9I.jpeg 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:22:57 <sundriedpotato> cannot be* 18:23:12 <nielsm> https://i.imgur.com/zITE3W7.jpeg this might actually work in vanilla... not entirely sure, but I think it might 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 18:54:02 <peter1138> Hmm 19:49:33 *** frosch123 has quit IRC 20:02:37 *** Flygon__ has quit IRC 20:08:34 *** gelignite has quit IRC 20:32:36 *** nielsm has quit IRC 21:31:27 *** Wormnest has quit IRC 21:34:11 <DorpsGek> [OpenTTD/OpenTTD] yhorndt opened issue #9962: [Bug]: 'server_advertise' is an unknown setting. https://github.com/OpenTTD/OpenTTD/issues/9962 21:39:05 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9962: [Bug]: 'server_advertise' is an unknown setting. https://github.com/OpenTTD/OpenTTD/issues/9962 21:41:32 *** WormnestAndroid has quit IRC 22:03:13 *** ufo-piloot has quit IRC 22:03:25 *** ufo-piloot has joined #openttd 22:03:27 <DorpsGek> [OpenTTD/OpenTTD] yhorndt commented on issue #9962: [Bug]: 'server_advertise' is an unknown setting. https://github.com/OpenTTD/OpenTTD/issues/9962 22:03:30 <DorpsGek> [OpenTTD/OpenTTD] yhorndt closed issue #9962: [Bug]: 'server_advertise' is an unknown setting. https://github.com/OpenTTD/OpenTTD/issues/9962 22:12:52 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9433: [Bug]: World generation seed from openttd.cfg is ignored https://github.com/OpenTTD/OpenTTD/issues/9433 22:14:22 *** Samu has quit IRC 22:15:44 *** sla_ro|master has quit IRC 22:16:38 *** Wormnest has joined #openttd 22:26:32 *** debdog has joined #openttd 22:28:52 *** WormnestAndroid has joined #openttd 22:48:06 *** D-HUND has joined #openttd 22:51:33 *** debdog has quit IRC 22:52:24 *** D-HUND is now known as debdog 23:36:55 *** esselfe has quit IRC 23:45:25 *** HerzogDeXtEr has quit IRC 23:51:00 *** esselfe has joined #openttd