IRC logs for #openttd on OFTC at 2023-04-21
ā“ go to previous day
00:45:47 *** Eddi|zuHause has joined #openttd
01:49:46 *** esselfe has quit IRC (Quit: rebooting)
01:53:47 *** esselfe has joined #openttd
02:01:43 *** Wormnest has quit IRC (Quit: Leaving)
02:06:08 *** Flygon has quit IRC (Read error: Connection reset by peer)
02:44:37 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:54:58 *** D-HUND is now known as debdog
03:45:10 *** iSoSyS has quit IRC (Remote host closed the connection)
03:45:10 *** petern has quit IRC (Remote host closed the connection)
03:45:10 *** Brickblock1 has quit IRC (Remote host closed the connection)
03:45:10 *** GeorgeVB has quit IRC (Remote host closed the connection)
03:45:10 *** osswix has quit IRC (Remote host closed the connection)
03:45:10 *** jfs- has quit IRC (Remote host closed the connection)
03:45:10 *** dP has quit IRC (Remote host closed the connection)
03:45:10 *** Azusa has quit IRC (Remote host closed the connection)
03:45:10 *** Orang has quit IRC (Remote host closed the connection)
03:45:10 *** EmperorJake has quit IRC (Remote host closed the connection)
03:45:10 *** discord_user_f4a0790 has quit IRC (Remote host closed the connection)
03:45:10 *** michi_cc[d] has quit IRC (Remote host closed the connection)
03:45:10 *** ag has quit IRC (Remote host closed the connection)
03:45:10 *** Merni has quit IRC (Remote host closed the connection)
03:45:10 *** TallTyler has quit IRC (Remote host closed the connection)
03:45:10 *** sittinbythefire has quit IRC (Remote host closed the connection)
03:45:10 *** Gwyd has quit IRC (Remote host closed the connection)
03:45:10 *** glx[d] has quit IRC (Remote host closed the connection)
03:45:10 *** TrueBrain has quit IRC (Remote host closed the connection)
03:45:10 *** Xarick has quit IRC (Remote host closed the connection)
03:45:10 *** JohnFranklin has quit IRC (Remote host closed the connection)
03:45:10 *** Kuhnovic has quit IRC (Remote host closed the connection)
03:45:10 *** wao has quit IRC (Remote host closed the connection)
03:45:10 *** JGR has quit IRC (Remote host closed the connection)
03:45:10 *** andythenorth has quit IRC (Remote host closed the connection)
03:45:10 *** DorpsGek_v has quit IRC (Remote host closed the connection)
03:45:10 *** iskazain has quit IRC (Remote host closed the connection)
03:45:10 *** CharlieAtlasff03k64 has quit IRC (Remote host closed the connection)
03:45:10 *** JustANortherner has quit IRC (Remote host closed the connection)
03:45:31 *** DorpsGek_v has joined #openttd
06:09:59 *** sla_ro|master has joined #openttd
06:11:23 *** sla_ro|master has quit IRC ()
06:40:23 <petern> Yeah, when it's automatic it's not really a problem that it takes a bit longer.
07:43:40 <petern> Hmm, might have to have a morning breakfast.
08:59:04 <petern> Okay, this column algorithm needs more work...
09:43:55 *** TrueBrain has joined #openttd
09:43:55 <TrueBrain> petern: done; added a bunch to the list .. let me know if it is more trouble than worth š
09:44:12 <TrueBrain> I also made CodeQL for example mandatory .. not sure that is the right call š
09:48:28 <petern> Do we often (deliberately) ignore the result of that?
09:57:40 <Rubidium_> not that often, but it running and not failing horribly is something else than it mentioning some things
10:48:06 <petern> Ooh, nearly food time.
10:49:37 *** andythenorth has joined #openttd
10:49:44 <andythenorth> been out every day this week, so eh, continues
10:51:58 *** WormnestAndroid has quit IRC (Remote host closed the connection)
10:52:41 *** WormnestAndroid has joined #openttd
11:00:48 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:02:53 *** WormnestAndroid has joined #openttd
11:12:58 *** JohnFranklin has joined #openttd
11:12:58 <JohnFranklin> Is andythenorth British? And has UK started DST?
11:41:35 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:42:09 *** WormnestAndroid has joined #openttd
11:44:08 <glx> And it's supposed to be the last time, like every year
11:44:11 *** glx is now known as Guest11776
11:44:12 *** Guest11776 is now known as glx[d]
11:58:28 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:59:31 *** WormnestAndroid has joined #openttd
12:07:39 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:07:44 *** WormnestAndroid has joined #openttd
12:11:48 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:12:26 *** WormnestAndroid has joined #openttd
15:11:56 *** TallTyler has joined #openttd
15:11:56 <TallTyler> LordAro: I rebased #10613 and it dismissed your approval. Care to re-approve? š
15:20:11 *** gelignite has joined #openttd
15:32:03 <TallTyler> No, I was waiting for you š
15:32:11 <TallTyler> Thanks for the approval š
15:34:18 <TallTyler> So many abandoned PRs š¦
15:34:39 <TallTyler> Trying to tidy, without just closing stale PRs...
15:46:00 <LordAro> a far cry from when andy got us down to <100
15:49:17 <andythenorth> don't think I made it < 100
15:49:22 <andythenorth> but it was a goal
15:52:04 <TallTyler> So many issues are really feature requests or little quirks, which are not truly resolved but aren't bugs either. #7941 is a good example.
15:54:53 <dP> despite it's mild description 7941 is a major path signal bug
15:55:08 <petern> Heh, and I referenced it by mistake. Hmm.
15:56:13 <dP> it blocks entrance to the whole station if some train leaves at unfortunate moment
15:58:37 <petern> Perhaps undesirable behaviour.
15:58:37 <dP> so path signals suck by design? :p
15:58:56 <FLHerne> what I'm puzzled by about #7941 is that it doesn't fail if there's a junction after the station before the next signal
15:58:57 <petern> The platform it chose it not yet usable.
15:59:06 <petern> That's not a path signal but.
15:59:37 <FLHerne> so there's clearly *some* handling for special-casing beyond the destination
16:00:02 <dP> 7941 is pretty much the reason coop uses block signals on stations
16:00:16 <dP> as they don't disrupt the flow
16:00:28 <FLHerne> phrased better: the reservation takes account of the following destination after passing the current one
16:01:01 <FLHerne> petern: that it chose the currently-unusable platform and overlooked the penalty of a train within the path reservation it needs is the bug
16:01:23 <ag> Never noticed this feature before
16:01:48 <ag> You can ping discord profiles via IRC bridge
16:02:40 <petern> It's not path-signals that choose which platform a train will use. Ergo it's not a path-signal bug.
16:04:22 <dP> block signals don't reserve so they'll just won't let a train into an occupied block
16:04:37 <FLHerne> fair enough, it's a bug that can only manifest with block signals :p
16:05:32 <FLHerne> with block signals, the train is never "committed" to a platform that's not yet clear
16:06:11 <petern> No, with block signals it would never attempt to enter the block because the block isn't free.
16:06:28 <petern> WIth path signals it doesn't enter the block but could potentially do so if it chose another platform.
16:07:04 <dP> it's doesn't matter how you put it, end result is using path signals leads to random jamming on entrance
16:08:29 <dP> block is only one extra tile in roro stations
16:08:42 <dP> and that's exactly the tile that causes problems with path signals
16:09:19 <dP> if train ends on any other tile everything works fine
16:10:17 <dP> I mean you can not put signals after platform ofc but that's meaningless
16:10:28 <petern> If you want to be inexact about it, you can just call it an OpenTTD bug.
16:14:28 <petern> yapf_rail.cpp:71 `ReserveRailStationPlatform` possibly needs to fail if it can't reserve up to a safe waiting point, not just up to the end of the platform. Of course finding the next safe waiting point in all conditions sound tricky.
16:15:43 <glx[d]> it fails, that's why train is waiting for free path
16:16:22 <glx[d]> the issue is PF should select the other platform in this case
16:17:11 <petern> Hmm, right. Add a penalty if it fails . Dunno.
16:23:06 <glx[d]> there's also #9954 and #9609 with some PF weird decisions
16:29:31 <FLHerne> glx[d]: 9954 seems wrong
16:32:56 <petern> hmm, increase platform penalty if occupied by wait-loading train? Dunno if that's possible.
16:50:57 <petern> YouTube has decided I want to watch everything in 360p today.
16:52:22 <Eddi|zuHause> 360p ought to be enough for anyone
16:52:25 <Rubidium_> yeah, they do that to see whether people are really interested in having the 8k content, or whether they can't be bothered with some worse quality content
17:03:08 *** Eddi|zuHause has quit IRC (Remote host closed the connection)
17:03:39 <petern> Potentially it could stay down if the window is open, and be used to toggle it. Dunno.
17:04:02 <TallTyler> Then we could have multiple buttons in the same toolbar lowered at once, like Objects and Trees
17:04:08 *** Eddi|zuHause has joined #openttd
17:04:09 <TallTyler> I don't think any of our toolbars do that
17:05:02 <TallTyler> I'd happily review a PR to change it, but I don't think it's worth a bug tracker entry š¤·
17:05:17 <TallTyler> There are so. many. issues requesting features
17:05:30 <petern> I wonder if something changed with compilation concurrency. I dropped it to 6 threads, but it's still using all 12 (half-)cores
17:06:11 <petern> Or maybe something else is just sitting in the background also hogging cores š
17:06:31 <andythenorth> TallTyler: "Thanks for contributing. We prefer to close feature requests as history shows most of them are unlikely to be implemented. However we do read them all, and thanks for taking the time to share your idea."
17:07:33 <glx[d]> petern: probably youtube in 360p š
17:07:57 <petern> Hmm, might be why its in 360p...
17:08:27 * Rubidium_ wonders wheter #10686 is going to get 34 annotations as well
17:09:12 <TallTyler> For just changing english.txt? I hope not
17:09:34 <petern> Maybe I should persevere and switch to Linux.
17:10:34 <andythenorth> do a year with macOS
17:10:36 <andythenorth> it would be amusing
17:15:16 <Rubidium_> TallTyler: well, on #10684 it does on files I haven't touched
17:15:48 <glx[d]> strgen warnings are not reported as annotations
17:17:15 <glx[d]> nice, every action is waiting on #8480
17:18:12 <petern> Joining the queue š
17:18:31 <petern> If it was possible to donate processing time to this...
17:25:43 <Eddi|zuHause> hm... forum is ded
17:43:47 <petern> Hmm, that definitely has some issues.
17:49:02 <TrueBrain> petern: that in theory is possible; just not worth it š
17:54:00 <TallTyler> TrueBrain: Could you perhaps weigh in on the discussion in #9577 and #10689 about splitting up a big PR? I repeated your wisdom from my calendar PR, but I'm worried that I didn't communicate it properly, since #10689 doesn't stand alone like the split I proposed in #9577.
17:55:44 <petern> If it's only used by a later PR it should be included in that PR.
17:56:03 <petern> OR perhaps now that we have unit tests, if you can also include unit tests for it, it could stand alone.
17:56:34 <petern> (Just IMHO, and talking generally about this sort of thing,)
17:56:59 <petern> I once added things to be used in future, and it got reverted š
17:57:07 <petern> So the future thing never came.
17:57:14 <TallTyler> Yes, that's my understanding too, I just feel like I'm nagging at this point š¬
17:57:20 <petern> That was back in the SVN days though, without easy branches.
18:08:31 <andythenorth> goes it something?
18:09:33 *** Wormnest has joined #openttd
18:20:26 <TrueBrain> TallTyler: sadly, not much time to delve into that PR. But I think you are on the right track. Just help him too in finding what are (user-facing) features that can be separate. 90% of the time they can be found .. just a matter of pointing them out š
18:22:41 <Rubidium_> is this weekend's goal 100 open PRs?
18:23:35 <Eddi|zuHause> should i join in?
18:25:11 <TallTyler> No! Iām making issues go away!
18:29:58 <Eddi|zuHause> i have a branch called "tgp-tweaks", whatever that means?
18:36:00 <Eddi|zuHause> doesn't look like it contains any commits, though
18:37:59 <TallTyler> Anything stashed locally, maybe?
18:42:24 <DorpsGek> - Update: Translations from eints (by translators)
18:51:07 <TallTyler> TrueBrain: Thanks, think I figured out how to say it š
18:52:59 <Eddi|zuHause> i don't find any traces of any actual work being done on this topic
19:00:42 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:00:43 *** WormnestAndroid has joined #openttd
19:01:50 <petern> Oh yeah, cos it wasn't in the commit message. Oh well.
19:02:39 <dP> release crashes, relwithdebinfo stuck in an infinite loop, debug works flawlessly š
19:03:42 *** michi_cc[d] has joined #openttd
19:03:43 <michi_cc[d]> That's usually called undefined behaviour. The best part of the C++ standard.
19:04:54 <petern> `#define AMD(x, y, flags, dir) { x, y, flags, dir }`
19:04:58 <petern> That seems like a fairly useless macro...
19:05:58 <Eddi|zuHause> saves typing {} :p
19:06:47 <petern> Trying to summon Belugas?
19:06:54 <glx[d]> Not sure but I think belugas used these macros
19:20:50 <Rubidium_> such a macro is great if you ever want to reorder the fields for more efficient storage or something
19:26:16 <petern> Time for some static_casts?
19:27:18 <petern> Although I'd be surprised if that's the only ones.
19:30:23 <dP> michi_cc[d]: undebugable behaviour :/
19:34:26 <petern> Hmm, I ran out of salad.
19:34:55 <Eddi|zuHause> dP: just write correct code, and you don't need debugging
19:58:33 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:15:10 <petern> Hmm, switching things to use vector when you have long arrays for default data is a bit annoying.
20:16:42 *** gelignite has quit IRC (Quit: Stay safe!)
20:17:14 <petern> constexpr std::vector coming in C++2a... oh dear.
20:26:47 *** Wormnest has joined #openttd
20:33:48 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
20:37:35 *** WormnestAndroid has joined #openttd
20:41:38 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
20:43:23 *** WormnestAndroid has joined #openttd
20:52:14 *** m3henry has joined #openttd
20:53:39 <m3henry> pertern: would std::array or std::span be suitable>]
20:54:33 <petern> No because the structs are also filled at runtime with NewGRF data, so can be variable.
20:57:52 <petern> Lots of initialization needs to be changed.
20:58:16 <petern> -- or we can keep using pointers *shrug*
20:59:08 <m3henry> you could use a std::list for init, then std::copy to a vector after building the whole list
21:01:29 <petern> Yeah, but it's all static initialization right now. I can initialize a vector with `{ std::begin(x), std::end(x) }`, there's just so many places to do that, and it's probably (but not sure) creating another copy of the data.
21:05:04 <michi_cc[d]> vector has a constructor that takes `std::initializer_list` which is in turn mostly constexpr-ish. Maybe one can make something out of this?
21:05:07 <m3henry> is `x` a struct T[] ?
21:06:04 <petern> But also, lots of times x is reused in different places.
21:06:24 <petern> I just wanted to avoid malloc/free or new/delete but maybe not š
21:06:24 <m3henry> initializer list might work
21:07:24 <m3henry> can the malloc be avoided without using std::pmr:: ?
21:10:25 <m3henry> Thinking about it, if x is not static and accessed by something else, then the compiler can't avoid a copy
21:10:56 <petern> Yeah, it works right now because it's just pointers.
21:11:24 <m3henry> Perhaps just pointers is the way to go
21:14:43 <m3henry> On another note, I was playing with variants, and I noticed that hiding the parent vehicle doesn't hide the variants, which surprised me. Is this intended?
21:15:21 <TrueBrain> from std:: to variants .. it took me a while to understand these were not std::varaints š
21:16:03 <petern> So it's possible for the parent engine to not be visible for some reason (expired life usually), and yet you want the variants to be visible still.
21:16:16 <petern> In that case the variants are forced by visible.
21:16:26 <petern> I guess I just didn't take account of hidden engines š
21:18:12 <petern> Ah my breakpoints aren't triggering because this code is optimized away (or probably inlined...)
21:18:31 <m3henry> I've seen std::variant, gone "that's neat" and have not yet found a need for it
21:27:01 <petern> Just bugs me that we need to explicitly store the length of array pointed to, and can't use the simple iterator syntax.
21:36:44 <m3henry> why not just make the declaration of x vector<T> instead of initialising from x[] ?
21:41:36 <m3henry> I guess perhaps x is needed for future initialisations when starting another game
21:43:46 <Eddi|zuHause> is that just me or were 4 out of the 5 last xkcd space themed?
21:51:14 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:54:12 <petern> Weird, I haven't looked at any web-comics for a couple of years now.
22:02:03 <petern> Also wow that cast š
22:02:27 <TallTyler> Yeah, I have no idea what's going on there
22:03:02 <petern> But turns out the fix is even shorter, nice š
22:04:50 <TallTyler> Yeah, actually a bug fix instead of a missing feature
22:14:03 *** WormnestAndroid has quit IRC (Remote host closed the connection)
22:14:04 *** WormnestAndroid has joined #openttd
22:19:11 <petern> That cast is basically a C-style callback and data parameter.
22:20:36 <petern> Or simply replaced with a call to the function instead of using a callback at all...
22:21:14 <petern> This is the only user of the window so a generic callback is not needed. Future expansion that never expanded...
22:22:39 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:28:37 <petern> Haha, it was crashing... because I forgot I'd rebased away from another commit that was vital.
continue to next day āµ
