IRC logs for #openttd on OFTC at 2025-01-09
⏴ go to previous day
01:23:28 *** Speedy` has quit IRC (Read error: Connection reset by peer)
01:25:18 *** Speedy` has joined #openttd
02:06:05 *** gelignite is now known as Guest5378
02:06:09 *** gelignite has joined #openttd
02:13:28 *** Guest5378 has quit IRC (Ping timeout: 480 seconds)
02:16:54 <_glx_> wow a rare linux crash report
02:57:38 *** Wormnest has quit IRC (Quit: Leaving)
03:10:43 *** gnu_jj_ has joined #openttd
03:13:54 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:18:39 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:34:09 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
06:28:26 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:47:28 *** Flygon has quit IRC (Read error: Connection reset by peer)
06:55:05 <andythenorth> the video appears to incontrovertibly show that the block signals are much faster
06:55:15 <andythenorth> but I'm puzzled as to the root cause
06:57:19 <andythenorth> we have been really quite forceful about PBS being superior
06:57:34 <andythenorth> and a lot of the 'block signals are faster' advocates have been told they're wrong
06:57:44 <andythenorth> but the video is strong evidence they're correct
06:58:22 <andythenorth> block is very clearly outperforming PBS for plain line signals
06:59:12 <pickpacket> I noticed this morning that when company name is set from Unnamed to whatever town the first construction is in it doesn't use the company rename function. Would it be a good idea to do so?
06:59:30 <pickpacket> andythenorth: I'm gonna have to watch that today
07:03:01 <pickpacket> Huh. Just watched it. Strange indeed
07:32:47 <LordAro> i've seen this before somewhere, i'm sure there's an existing issue somewhere
07:44:00 <andythenorth> 'they have to run without orders'
07:44:02 <andythenorth> is that a thing?
07:44:10 <andythenorth> tempted to build the set up and try it
07:44:19 <andythenorth> didn't have coffee though
07:45:21 <LordAro> andythenorth: it would certainly match the reddit gif
07:45:45 <LordAro> as to why it may be the case... pass
07:50:24 <andythenorth> oof I need to be better at signalling 😦
07:50:38 <andythenorth> is there a one way block signal?
07:51:48 *** florafex has joined #openttd
07:52:46 <andythenorth> hmm now my PBS trains are all visiting depot
07:52:52 <andythenorth> but the block signal trains aren't
07:53:25 <andythenorth> pff someone else is going to be better at this 🙂
07:53:37 <andythenorth> all this stuff is so...complicated
08:02:49 *** Smedles has joined #openttd
08:08:58 <truebrain> andythenorth: They are? From what I remember they aren't being told that, only that the difference is so small, for 95% of the population it is irrelevant?
08:11:03 <andythenorth> I have told them 😛
08:11:34 <andythenorth> finding that I'm wrong about who is wrong .... would not be my first rodeo
08:16:03 <truebrain> Furthermore what the video shows lovely, is why we have traffic jams. If, for what-ever reason, a train is just slightly slower so the one after him has to break, there is a knock-down effect. One train breaks, causing the next train in line to break. And as acceleration is not instance, this propegates downstream. Mythbuster did a whole episode about this with a roundabound. It is a very good
08:16:10 <truebrain> the system cannot recover from that itself btw, at that point
08:16:11 <wensimehrp> tested. block signals also jams
08:16:54 <truebrain> so it could be the signal type, but it could also be the initial state
08:17:05 <truebrain> where one train is just not speedy enough, to start creating this knockdown effect
08:17:48 <truebrain> it is a very common problem in every day traffic: one car breaks for what-ever reason, and before you know it 10km down the road you have a major traffic issue
08:25:17 <truebrain> owh, and this only happens if your network is conjested, ofc. Which it is, in this case. Remove one train, and possibly the whole effect dissipates 🙂
08:26:06 <truebrain> (in non-congested networks this also happens, but only for a single cycle, after which the distance between everything is high enough to not cause this effect anymore)
08:30:12 <andythenorth> ok so I made some assumptions about the case in the video
08:30:17 <andythenorth> that all trains were identical
08:30:29 <andythenorth> and were started at the same time, using 'start all trains'
08:35:29 <andythenorth> seems the test case is jgrpp, which introduces another variable
08:37:41 <andythenorth> yeah the second video makes it obvious, block is just faster on plain line
08:41:03 <andythenorth> can't see why though
08:41:12 <andythenorth> does it just clear faster?
08:45:37 <andythenorth> I can't replicate yet
08:48:01 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
08:56:38 <truebrain> with the green-first change it might have dissipated 🙂
08:57:42 <andythenorth> I have a different test case, but similar outcome
08:57:56 <andythenorth> I'm measuring how many trains are blocked on a red signal consistently
08:58:03 <andythenorth> with PBS it's 3 out of 7 on my loop
08:58:09 <andythenorth> with block it's 2 out of 7
08:58:31 <andythenorth> on the one hand, that could be because PBS is faster, so trains arrive at red sooner
08:58:52 <andythenorth> or it could be that PBS is slower, and the train in front isn't clearing fast enough
08:59:15 <andythenorth> I suspect that conclusions based on observing specific test cases can't be generalised
08:59:31 <andythenorth> maybe we can teach an AI to build a million test cases, and scatter plot the results
09:01:12 <pickpacket> andythenorth: sounds like fun. Do it :D
09:02:02 <andythenorth> we could probably have a train counter logging
09:02:10 <andythenorth> what's the definition of 'faster'?
09:02:26 <andythenorth> number of trains passing a waypoint per second?
09:04:53 <truebrain> andythenorth: more to the point, for which part of our users is this relevant? As for most people, PBS really is the better choice. If you want to min/max stuff, it might shift slightly.
09:05:03 <truebrain> but that holds true for most defaults
09:06:00 <andythenorth> it's a curiousity for me
09:06:49 <andythenorth> probably not enough to learn how to instrument it though
09:09:10 <peter1138> In that first video, it's because the two trains on the bottom left of the path signal loop are close together. One stops, and that cascades.
09:09:27 <peter1138> On the right hand loop, the trains are equally spaced.
09:10:35 <andythenorth> ok, I've got a repro
09:10:42 <andythenorth> these all left the depot at the same time
09:11:09 <andythenorth> they have only run a few loops, the blue train on block is 1.5 tiles ahead of the blue train on PBS
09:11:31 <andythenorth> but the specifics of any given test case are so...specific
09:12:35 <peter1138> Also it's not vanilla, so the trains slow down differently for the signals.
09:13:28 <peter1138> In their later follow up video the block-signal stuff doesn't really 'recover', the trains are jamming on the bottom corner but not stopping 100%.
09:14:29 <andythenorth> ok first loop, the blue trains were in sync until they both got signal stopped due to trains still exiting the depot
09:14:48 <andythenorth> now block is ~0.5 tiles ahead
09:15:04 <andythenorth> but the preceding trains are both in sync
09:15:12 <andythenorth> so yeah, block is faster
09:16:15 <andythenorth> in both cases the line is over capacity anyway
09:17:04 <peter1138> _glx_, seems to be caused by having two different values for an invalid industry type. Strange.
09:19:04 <andythenorth> ok at this point the block signal has cleared for the blue train, the PBS signal has not
09:19:28 <andythenorth> so perhaps they just have different definitions of 'clear'?
09:20:13 <andythenorth> or (all trains have orders to go via the waypoint) it's just pathfinding delay?
09:21:05 <andythenorth> but the PBS signal doesn't clear conditionally on the waiting train? it clears on the preceding train yielding the reservation?
09:21:27 <andythenorth> how do reservations measure train length? 😛
09:25:51 <andythenorth> I turned on the visual displays of the reservations, that appears to be identical in respect of the end of the reservation (PBS obviously reserves further forward)
09:46:38 <andythenorth> ok so it's reproducible
09:47:56 <peter1138> path_backoff_interval?
09:49:58 <peter1138> Defaults to 20. You can change it to 1.
09:54:47 <andythenorth> that has a material impact
09:55:44 <andythenorth> the path is found sooner
09:56:38 <andythenorth> ok well I could probably try other settings one at a time, but eh
09:57:30 <peter1138> So found sooner, but still 'slower' (more delay).
09:58:12 <andythenorth> I'm not necessarily thinking this is fixable, just curious
09:59:29 <andythenorth> wonder what setting path_backoff_interval to 255 would do 😛
10:09:41 <andythenorth> I thought Timberwolf had a video about the PBS delay, but I can't find it 😛
10:13:14 <andythenorth> my bet is that this is not just 'PBS pathfinding is computationally intense'
10:13:51 <andythenorth> I don't think the multi-tick delay in clearing the signal is due to evaluation the small number of possible routes in this test case
10:14:20 <andythenorth> we would see the game crawl far more often if PBS pathfinding was that slow
10:20:19 <peter1138> The delay is not caused by the computational cost of anything. There are no multithreaded background tasks being waited on.
10:28:29 <andythenorth> I am reading train_cmd to see if we have any other intended delays
10:37:34 <andythenorth> restore the 'going up a slope' old behaviour
10:48:08 <peter1138> 16GB Raspberry Pi, hmm.
10:48:30 <andythenorth> is PBS faster on it?
11:06:05 *** gnu_jj_ has joined #openttd
11:06:43 <LordAro> peter1138: so why does that backoff setting exist?
11:07:49 <andythenorth> I'm not sure how reliable my tests are, they rely on pausing / unpausing the game
11:08:10 <andythenorth> it would be better to video capture it across multiple runs at 60 fps or something, then freeze frame
11:09:41 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
11:10:17 <peter1138> The backoff setting exists so that we don't try to find a path every tick.
11:12:48 <LordAro> peter1138: so it is only a problem for vehicles with no orders then?
11:13:48 <peter1138> I don't follow you.
11:15:33 <LordAro> we wouldn't try to find a path every tick if it had orders (well, wasn't lost)
11:17:52 <LordAro> because it's already got a path?
11:19:10 <LordAro> based on what you've said, the backoff setting is only relevant when the train has not got a path. So, the original problem is only relevant for trains without orders or those that are lost
11:19:52 <peter1138> Having a path isn't the same as having an order.
11:20:57 <peter1138> There is a path from the pathfinding result to where the train wants to go.
11:22:38 <peter1138> However, if that path is blocked, then the path cannot be reserved, the signal stays red, and the train does not move for the current tick.
11:23:05 <peter1138> Therefore, on the next tick, without the backoff interval, the train would try to find the path again.
11:24:01 <LordAro> ...could we add the same backoff interval to block signals? :D
11:24:11 <LordAro> just arbitrarily delay them
11:24:49 <peter1138> Well, I was going to suggest that if we can't improve the delay, we could remove the disparity by making block signals behave poorly :p
11:26:37 <peter1138> But it also seems, judging only by andythenorth's picture, that if you set the backoff interval to 1 (which means "every tick") then there is still a discrepancy.
11:26:59 <andythenorth> I set it to 0, and I don't trust my pause/unpause methodology either
11:27:07 <peter1138> 0 isn't a valid value.
11:27:14 <andythenorth> right, I'll try 1
11:27:36 <peter1138> There is a reason I said you can change it to 1. :-)
11:28:15 <andythenorth> one day I'll learn to read
11:28:39 <peter1138> For ships and road vehicles, we cache paths.
11:28:40 <andythenorth> anyway, it might make a difference, but it might just be noise and timing drift
11:28:51 <andythenorth> it *doesn't* remove the discrepancy
11:29:17 <peter1138> So perhaps we could cache the path, and then only invalidate the path on the backoff interval.
11:29:35 <peter1138> But in the case of multiple paths that still wouldn't match block signals.
11:29:54 <peter1138> So that's a poor idea that just makes things more complex.
11:30:44 <peter1138> If you set it to 0, it might clamp it to 1 anyway. Or it might not, I can't remember.
11:34:34 <andythenorth> I could probably learn to write logging or something
11:34:49 <andythenorth> or evaluate the stack calls with that apple tool I used once before
11:35:36 <andythenorth> not sure I care enough, but now I have a curiousity rabbit hole
11:58:02 *** gelignite has joined #openttd
13:34:42 *** kuka_lie has joined #openttd
13:44:44 <pickpacket> I like coding for this project. You guys are all so nice to me
13:44:58 <pickpacket> and I know that's challenging sometimes ;)
13:52:37 <truebrain> being nice, or being nice to you? 😛
14:16:41 <pickpacket> I don't know how much you struggle to be nice in general 😂
14:35:26 <johnfranklin> I now miss the cat appearance of peter1139
14:52:38 <peter1138> Nobody misses my appearance.
15:17:14 <pickpacket> xarick: that sounds no fun at all :(
17:00:30 *** Wormnest has joined #openttd
17:52:12 <_glx_> Having 2 different values for the same thing was just wrong
18:10:13 <pickpacket> I wanna use the format() function in my GS, for string formatting, but the script crashes because it can't find the function. It's part of the standard string library in squirrel. Do I need to import it somehow?
18:22:30 <_glx_> we include only aux and math
18:41:02 <pickpacket> _glx_: oh, of course. It's not my GS that needs to include something
18:41:50 <pickpacket> Not sure attempts at aligning text will make much sense if the storybook font isn't monowidth either way
18:42:34 <pickpacket> There's no such thing as printing a table, is there?
18:47:29 *** ChanServ sets mode: +v tokai
18:52:47 <michi_cc> peter1138: Indeed, without patch backoff some situations results in very, very low FPS. Back when it was still in development, somebody had (or made) something like a 20 track stations with 50 incoming tracks and a big fat everything tracks rectangle junction in front. With all tracks full of trains it had like 0,01 FPS. Next YAPP release had the path backoff to "solve" pathological cases like
18:53:36 <andythenorth> pickpacket: the storybook is very limited for formatting
18:53:48 <andythenorth> and non-performant
18:54:23 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
19:08:40 <pickpacket> andythenorth: how non-performant are we talking about?
19:27:23 <pickpacket> Sometimes I get the impression that some people (*cough* peter1138 *cough*) code for the game full time or even more 😄
19:58:27 *** kuka_lie has quit IRC (Quit: Lost terminal)
20:21:37 <truebrain> That is one way to overstate something 😛
20:22:48 <truebrain> "Non-performant when used way outside of the bounds it was meant to be used" would have been a more fair remark 😉
20:29:29 <truebrain> but there are so many to choose from!
20:32:20 <truebrain> I was more thinking about: 🤡
20:32:25 <truebrain> But that is just me 😛
20:34:19 *** notluke2578 has joined #openttd
20:44:06 <peter1138> Are your forks tuned?
20:44:25 <truebrain> sharp and ready to burn
21:25:56 <andythenorth> what's unfinished in FIRS 5?
21:26:02 <andythenorth> was it wallclock support in the grf spec?
21:42:56 <peter1138> We were there at the time.
21:48:27 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:59:30 <andythenorth> lives about 5 minutes from me
21:59:52 <andythenorth> don't know him, my friends do
22:02:17 <pickpacket> The badger badger creator?
22:05:12 <andythenorth> it's a small bizarre world I live in
22:16:12 <talltyler> andythenorth: Yes, I broke your helptext and still haven’t found a satisfactory solution yet 😦
22:27:17 <andythenorth> probably we just convert it to realtime
22:27:25 <andythenorth> realtime / wallclock /s
22:27:48 <andythenorth> industry production graph is 'last 24 minutes'
22:28:07 <andythenorth> [scaled to my wallclock setting]
22:28:32 <andythenorth> think FIRS production works on n periods anyway, not strict calendar month
22:29:21 <andythenorth> grf string codes for wallclock values?
22:38:33 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:47:31 <talltyler> Oh, the other issue was scaling industry production (not part of time, but was also in 14)
22:47:38 <talltyler> It scales how often the callback is run
22:48:23 <talltyler> I know you don’t do stockpiling, but the boost supplies in PIRS work perfectly with this 🙂
22:49:39 <talltyler> andythenorth: I used to have a {MONTHS_OR_MINUTES} string code that I planned to expose to GRF, but it got reverted due to being a translation nightmare
22:54:34 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:42:40 *** toktik has quit IRC (Remote host closed the connection)
continue to next day ⏵
