Log for #openttdcoop on 9th October 2020:
Times are UTC Toggle Colours
06:00:01  *** coopdiscord has quit IRC
06:00:14  *** coopdiscord has joined #openttdcoop
07:35:46  *** happpy has joined #openttdcoop
07:35:46  *** ChanServ sets mode: +o happpy
09:24:45  *** happpy has quit IRC
13:50:40  *** happpy has joined #openttdcoop
13:50:40  *** ChanServ sets mode: +o happpy
14:15:20  *** happpy has quit IRC
15:45:58  *** Afdal has joined #openttdcoop
15:48:22  <Afdal> How do you guise handle those rare occurrences where a train is in a depot just long enough for a signal to show green when it shouldn't (or pathfinding to read "all clear ahead") and let another train on a path you don't want it on?  It's enough to completely disrupt the traffic on an otherwise well-balanced refit station.  Is there anything that can be done?
15:49:41  <coopdiscord> <happpy> do you meen  overflow
15:52:40  <Afdal> not sure
15:52:55  <Afdal> You know... when you've got a path leading to a depot, and you only one one train to use that path at a time
15:53:23  <Afdal> but for a split second a train gets inside a depot and in that moment it tells another train it's clear to use that path too
15:54:05  <coopdiscord> <happpy> that's sound to me a overflow
15:54:11  <coopdiscord> <happpy> do you have a screen shot
15:56:19  *** happpy has joined #openttdcoop
15:56:19  *** ChanServ sets mode: +o happpy
15:56:39  <Afdal> I geuss
15:56:41  <Afdal>
15:56:42  <Webster> Title: Screenshot - 3acb0e633c147b50539b5611f000c3dc - Gyazo (at
15:56:48  <Afdal> hard to capture in a still image though
15:56:57  <Afdal> see that green exit signal
15:57:16  <Afdal> that's only green for a split second right now because a train is in the depot below it
15:57:33  <coopdiscord> <happpy> hnn
15:57:35  <Afdal> just long enough for the train entertain the station splits to make the wrong decision
15:57:42  <Afdal> I really don't want it in that lane yet
15:57:52  <coopdiscord> <happpy> hmm
15:57:54  <Afdal> the train enterting*
15:58:00  <Afdal> ENTERING
15:59:05  <coopdiscord> <LugnutsK / Hazzard> Hey
15:59:55  <coopdiscord> <happpy> afdal tel  hazzard  about that
15:59:59  <Afdal>
16:00:00  <Webster> Title: Screenshot - 1bd3097ba1fa1b85589a5d996ca802aa - Gyazo (at
16:00:03  <Afdal> another example of the same problem
16:00:12  <coopdiscord> <happpy> he mite can help you
16:00:26  <Afdal> there's a train about to leave that depot but it was in it just long enough to make that other train choose a busy lane
16:00:58  <Afdal> Hazzard, what do D:>?
16:01:18  <coopdiscord> <LugnutsK / Hazzard> I would let the train enter the station platform. i.e. replace the exit signal with a normal signal*
16:01:51  <coopdiscord> <LugnutsK / Hazzard> The train may have to wait at the station after it unloads, but that can be fine
16:02:11  <Afdal> in those examples, then it just ends up entering a lane too close to another train, causing traffic disruption at the loading station
16:02:46  <Afdal> that's why I'm using those signals in the first place
16:02:50  <coopdiscord> <LugnutsK / Hazzard> Are you trying to prevent trains from stacking in the depot? (Do you have full load orders?)
16:02:54  <Afdal> yeah
16:03:08  <Afdal> no, not full load orders
16:03:40  <Afdal> trains are loading whatever is there made from what they dropped off and then leaving
16:03:48  <coopdiscord> <LugnutsK / Hazzard> And thats where the * comes in, instead replace the exit signal with an entry signal, and replace the signal leaving the station with an exit signal
16:03:50  <Afdal> leading to fairly consistent train time on the platforms
16:04:20  <Afdal> uhhhh
16:04:35  <Afdal> will that solve anything
16:05:16  <coopdiscord> <LugnutsK / Hazzard>
16:05:19  <coopdiscord> <LugnutsK / Hazzard> Maybe
16:05:31  <Afdal> the issue here is allowing a train on a platform too tightly with another train
16:05:45  <coopdiscord> <LugnutsK / Hazzard> so in a setup like this, trains on the unload platform will wait for the load platform to clear before it enters the depot
16:06:16  <coopdiscord> <LugnutsK / Hazzard> it does means trains will be closer to eachother will in the station complex, but they're stopping anyway. just will have to stop for slightly longer to wait for the way out to clear
16:06:18  <Afdal> the tightness causing the station to unbalance itself with a small disruption
16:06:37  <Afdal> Yeah I don't want any trains to have to stop to wait on a clear
16:06:42  <Afdal> that's what I'm trying to eliminate
16:07:39  <Afdal> lemme show you one possible solution to what I"m talking about actually
16:08:46  <coopdiscord> <LugnutsK / Hazzard> Well, the overall throughput should be the same, the per-train delay will be higher. in my solution
16:08:54  <Afdal>
16:08:55  <Webster> Title: Screenshot - 25668f3df687504de3f0ccf07f65b717 - Gyazo (at
16:09:29  <Afdal> extending the track to and from that refitting station just a smidge prevents those two tight trains from bumping into each other at the platforms and causing a disruption cascade
16:10:05  <coopdiscord> <LugnutsK / Hazzard> Sweet
16:10:17  <Afdal> but that's not really a solution to the big problem I'm asking about :)
16:10:23  <Afdal> it's just uh
16:10:35  <Afdal> segregating the problem with spaghetti track
16:11:11  <Afdal> I guess it's something to do with acceleration time between the platforms and depot
16:12:16  <Afdal> Notice with this solution I didn't actually stop the train from entering the same platform path as the other one when they're real tight
16:13:09  <Afdal> the problem of temporary wrong pathforming during the instance a train is going in and out of a depot remains...
16:13:18  *** Progman has joined #openttdcoop
16:15:05  <Afdal> I've tried using path signals for this setup
16:15:28  <Afdal> but as we all know, there's too slow sometimes and allow a train to enter a split before it's ready and force a slowdown
16:16:19  <Afdal> The only solution I can think of to this is to use a logic gate to store the memory of a train entertain that refit track
16:16:25  <Afdal> entering
16:17:06  <Afdal> but that's not going to work in tight spaces like this and I would need a logic gate connected to every single one
16:19:54  <coopdiscord> <LugnutsK / Hazzard> I mean as long as you keep the same things and the exits don't back up, it does't really matter that its timing based
16:20:12  <coopdiscord> <LugnutsK / Hazzard> *same trains
16:21:25  <Afdal> It matters because I'm trying to make a perfectly-flowing station here
16:21:38  <Afdal> any little event of one train bumping into another is intolerable
16:44:27  <coopdiscord> <LugnutsK / Hazzard> Well anyway I don't know of a way to solve your problem besides logic
16:44:46  <coopdiscord> <LugnutsK / Hazzard> personally I care a lot more about the throughput than the latency
16:48:22  <Afdal> you don't think disruptions affect throughput?
17:01:16  <coopdiscord> <LugnutsK / Hazzard> In this case no
17:01:26  <coopdiscord> <LugnutsK / Hazzard> I think it will result in more trains in the station at a given time
17:01:40  <coopdiscord> <LugnutsK / Hazzard> but the overall rate that trains enter and leave I would think would be the same
17:01:49  <Afdal> well...
17:01:56  <Afdal> I've tested such things before >.>
17:02:55  <Afdal> if you've got a high-speed network that's close to maximum density, any little disruptions massively reduce its throughput
17:03:05  <Afdal> because they cascade
17:09:05  <Afdal> I suppose you openttdcoopers don't focus on speed all that often though
17:09:25  <Afdal> there's been a few prozone games around that I think
17:09:37  <Afdal> but usually you don't mind starting trains from a stop
17:09:48  <Afdal> with yer hubs and such
18:12:08  *** happpy has quit IRC
19:11:25  *** happpy has joined #openttdcoop
19:11:25  *** ChanServ sets mode: +o happpy
22:24:30  *** happpy has quit IRC
23:43:50  *** Progman has quit IRC

Powered by YARRSTE version: svn-trunk