IRC logs for #openttd on OFTC at 2025-10-13
⏴ go to previous day
02:01:27 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:04:24 *** WormnestAndroid has joined #openttd
02:24:41 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:13:39 *** Zathras has joined #openttd
03:17:01 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
04:25:13 *** yiffgirl has joined #openttd
04:25:13 <yiffgirl> talltyler: been thinking; would it make sense to store the different facets contributing to station rating in a struct ? that way you could pass it to a - oh lmao that's literally the first thing you did in station-rating-why. nvm lol
06:17:43 *** gelignite has joined #openttd
07:06:15 <DorpsGek> - Add: summary for week 41 of 2025 (by OpenTTD Survey)
09:14:53 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
09:25:48 <LordAro> well that's not great
09:29:20 *** dwfreed sets mode: +b *!*@219-88-69-86.adsl.xtra.co.nz
09:29:55 <dwfreed> seriously, powernap is the worst, and textual should do a better job of detecting it and keeping itself disconnected
09:41:25 *** forgenet has joined #openttd
09:45:01 *** kuhnovic has joined #openttd
09:45:01 <kuhnovic> Looks like my docking station likes to kill laptops now....
09:48:04 <peter1138> £3,499.00 RRP: £3,499.99
10:02:59 <dwfreed> peter1138: I hope you didn't mind me using my network hat to make that stop
10:03:47 <dwfreed> with the join/quit flapping
10:03:51 <peter1138> Oh. No of course not.
10:04:16 <peter1138> I only (mildly jokingly) object to the unicode thing ;)
10:05:09 <dwfreed> one day all my triggers will be in a nice bot instead of running out of a perl script in my client, and then it'll be a lot easier for me to make them handle long-time users better
10:05:47 <peter1138> Maybe all ban users who start messages with "all: " and a link to media.discordapp.net.
10:06:17 <dwfreed> That's not a terrible idea
10:06:21 <LordAro> feels like something dibridge should do tbh
10:06:29 <LordAro> prevent it getting this far
10:07:23 <dwfreed> dibridge should just ignore messages pings to all and here unless they come from someone with elevated permissions
10:07:57 <LordAro> peter1138: one of my latest work MRs has reduced memory usage of a particular from 750MB to 550MB by removing an entirely unused std::string member
10:08:02 <dwfreed> (no sane discord server allows everyone to use all/here pings)
10:08:03 <LordAro> particular execution*
10:08:35 <dwfreed> that's an excellent savings
10:08:43 <peter1138> There are a few structs I can reorganise to save memory. But they're generally in things which only have a few dozen rather than thousands of instances.
10:09:24 <peter1138> pahole is useful, but doesn't quite understand C++ properly. Enough to work but the results can be odd with some types of inheritance.
10:10:36 <LordAro> it's even worse with Ada ;)
10:10:41 <LordAro> (but this particular bit was all C++)
10:11:06 <LordAro> somewhere next on my list is to replace the godawful custom string type that's somehow 96 bytes
10:11:37 <LordAro> (well, "somehow" = "small string optimisation is more like medium string optimisation")
10:12:32 <peter1138> I guess it's more efficient if all your strings are medium length...
10:13:42 <peter1138> I've considered using std::basic_string for small-string optimisation for non-strings.
10:14:06 <peter1138> Like lists of pool IDs, or whatnot.
10:14:23 <peter1138> But in the end it seems like overly-specialising and confusing.
10:17:37 <LordAro> speaking of, i've just tried swapping out std::unordered_map<std::string, ..> with storing the hash directly and using std::map<size_t, ..>
10:17:46 <LordAro> ...but the runtime has just quadrupled
10:18:23 <peter1138> Yeah, std::map is generally worse for performance due to all the allocations.
10:18:53 *** ahyangyi has joined #openttd
10:18:53 <ahyangyi> std::map is also just O(log N) times slower asymptotically
10:19:25 <LordAro> i'm sure i got some numbers for one of the types that suggested it was better
10:19:30 <LordAro> but might have misread
10:20:13 <peter1138> Depending on the size and number of records, a sorted vector can be quicker.
10:20:54 <peter1138> OpenTTD has std::map where the order of elements matters for multiplayer.
10:22:52 <peter1138> (And sometimes it uses it unnecessarily.)
10:23:39 <LordAro> also, a hash map to store hashes seemed somewhat redundant
10:24:01 <LordAro> (yes yes, wrong data structure all round, etc etc)
10:48:26 <peter1138> LordAro, if I get a turbo trainer... will I use it?
10:55:46 <peter1138> Hmm, can I refactor code while pedalling...
11:09:29 <LordAro> i know under-desk pedals do exist, but they're not exactly turbo trainers
11:09:42 <LordAro> quite similar to recumbent positioning, i suppose
11:10:05 <LordAro> and Linus has a treadmill desk
13:17:06 <peter1138> If only there was a way to submit a correction.
13:17:38 <LordAro> some way of requesting the developers to pull in a particular change
13:53:27 *** talltyler has joined #openttd
13:53:27 <talltyler> yiffgirl: Indeed, but I broke something while refactoring. Probably need to write some unit tests if/when I get back to that project.
14:27:13 <peter1138> It's that time of year again.
14:35:48 *** toktik has quit IRC (Remote host closed the connection)
14:46:55 <rito12_51026> Is the mapgen multithreaded?
15:07:39 <xarick> that's a lot of rebases
15:32:57 <LordAro> guess where my home internet comes from
16:12:36 <peter1138> Bourbons? Or custard creams?
16:19:38 <xarick> each rebase triggering 800+ files rebuild
16:20:08 <LordAro> strings are used by most files
16:20:47 <LordAro> and if you're checking out the original branch before rebasing, then it's applying every change to every file as well
16:21:12 <LordAro> `git rebase origin/master my-old-branch` would skip that initial step
16:23:54 <ahyangyi> or use `git fetch origin master:master` to update the local master branch
16:24:31 <LordAro> sure, but i always never have that branch checked out
16:39:32 *** Wormnest has joined #openttd
16:51:14 <LordAro> depends how much of that you've written
16:51:40 <LordAro> there was definitely some changes (and subsequent fixes) around use of instantiated objects like that
16:52:32 <_glx_> it's just a message, used to kill the AI 😉
16:52:56 <_glx_> but yeah these are pure static classes
16:54:27 <peter1138> The phrasing of that is a bit ambiguous :)
16:54:43 <peter1138> It's just a warning message, before the message was added it used to kill the AI.
16:54:59 <peter1138> It means the script is doing something it shouldn't, "but whatever".
16:57:35 *** virtualrandomnumber has joined #openttd
16:57:53 *** virtualrandomnumber has quit IRC ()
16:58:58 <LordAro> peter1138: lol, took me several attempts to reread that before it actually clicked
17:00:13 <peter1138> I did as you told me. How long should a pack last...
17:00:14 <xarick> okay, it's also happening in 15.0-beta3, so it's not a me problem
17:00:31 *** virtualrandomnumber has joined #openttd
17:00:34 <xarick> warnings should be in yellow... but k
17:00:34 <peter1138> It's a script-is-mildly-broken problem.
17:00:37 *** virtualrandomnumber has quit IRC ()
17:00:45 <LordAro> peter1138: depends how close to dinner time it is
17:01:31 <LordAro> peter1138: i'm not saying which direction the line on the graph goes
17:06:04 <xarick> woahh... river gen code changed drastrically again
17:13:06 <_glx_> so it reports an error for scripts using <15 api, but with 15+ script will be killed
17:33:45 <xarick> yapf_river_builder, hehe
17:44:21 <jfkuayue> peter1138: An upcoming extra long weekend by an hour?
17:48:56 <vondpc> i think they meant hacktoberfest 😛
18:05:17 <kuhnovic> xarick: Moved into a yapf implementation. No need to keep multiple A* pathfinders around.
18:06:47 *** Flygon has quit IRC (Remote host closed the connection)
18:11:31 <peter1138> kuhnovic, silly, we should have had a choice of river pathfinder options :D
18:13:08 <kuhnovic> That would certainly keep Xarick occupied
18:25:08 <andythenorth> everyday is a winding road
18:26:08 <andythenorth> map layers, but only one underground, and town buildings have foundations / basements filling it? 😛
18:37:20 <peter1138> "Let's design limits that nobody wants"
18:37:46 *** mmtunligit has joined #openttd
18:37:46 <mmtunligit> andythenorth: hell
18:51:17 <peter1138> Hmm, my OS drive is 69% full.
19:15:05 *** SigHunter has joined #openttd
19:18:56 *** ChanServ sets mode: +v tokai
19:22:05 <xarick> 4249737, 16007155, seed 3179865484
19:22:16 <xarick> okay, problem still persists
19:25:46 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
19:49:46 <kuhnovic> I'm not surprised, the logic hasn't changed. It was only moved to a new place.
19:58:02 *** belajalilija has joined #openttd
19:58:02 <belajalilija> xarick: It’s an ox bow lake
19:59:27 *** jo_ has quit IRC (Quit: Page closed)
20:04:56 <belajalilija> xarick: Oxbow lakes are the geography equivalent of “the mitochondria is the powerhouse of the cell”
20:17:19 <rito12_51026> got 262 148 rivers from that
20:19:07 <rito12_51026> wow release build is significantly faster that debug one
20:39:51 <xarick> need to benchmark rivergen again
20:40:08 <xarick> wondering if with yapf it's any faster
20:50:37 <xarick> too bad i can't build with clang
20:52:12 <xarick> some bug in microsoft's clang compiler version stuff... i dunno
20:53:28 <_glx_> the issue is only present for "Release" and "MinSizeRel"
20:53:54 <_glx_> "Debug" and "RelWithDebInfo" are fine
21:35:55 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:40:18 <xarick> oh, it was worse before the move to yapf
21:43:29 <xarick> i need to compile these results into a table, for a clearer view
21:56:11 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:05:34 <xarick> that 3rd configuration has the most deviation
22:06:51 <xarick> i think it's the one where the pathfinder fails more often to get a path
22:07:22 <xarick> either yapf failing is faster or... something else is going on
22:10:52 <xarick> the very flat rough terrain with a forced 1% sea one
22:15:08 *** Zathras_4 has joined #openttd
22:15:09 <xarick> gonna take a better look at this tomorrow
22:49:47 <peter1138> Only caveat to changing from FlatSet to std::unordered_set is the generation could be unpredictable.
22:50:10 <peter1138> The order doesn't actually matter, as we pick a random entry.
22:52:38 *** Tirili has quit IRC (Quit: Leaving)
continue to next day ⏵
