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> https://gyazo.com/3acb0e633c147b50539b5611f000c3dc 15:56:42 <Webster> Title: Screenshot - 3acb0e633c147b50539b5611f000c3dc - Gyazo (at gyazo.com) 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> https://gyazo.com/1bd3097ba1fa1b85589a5d996ca802aa 16:00:00 <Webster> Title: Screenshot - 1bd3097ba1fa1b85589a5d996ca802aa - Gyazo (at gyazo.com) 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> https://cdn.discordapp.com/attachments/462933932619595776/764156537269911602/unknown.png 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> https://gyazo.com/25668f3df687504de3f0ccf07f65b717 16:08:55 <Webster> Title: Screenshot - 25668f3df687504de3f0ccf07f65b717 - Gyazo (at gyazo.com) 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