IRC logs for #openttd on OFTC at 2024-03-11
⏴ go to previous day
00:10:12 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
01:30:31 *** xertov has quit IRC (Quit: User went offline on Discord a while ago)
01:50:03 *** Wormnest has quit IRC (Quit: Leaving)
02:57:06 *** Leopold_ has quit IRC (Remote host closed the connection)
02:59:47 *** Leopold has joined #openttd
03:33:19 *** Leopold has quit IRC (Remote host closed the connection)
03:36:01 *** Leopold has joined #openttd
03:41:11 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:42:25 *** gnu_jj_ has joined #openttd
03:45:57 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:42:21 <DorpsGek> - Update: Translations from eints (by translators)
05:25:02 <rau117> xarick: amateur guess: maybe it's just to not_make error message too wide?
05:25:02 <rau117> 1 super long line at least will take more space on screen...
06:42:10 *** Leopold has quit IRC (Remote host closed the connection)
06:45:37 *** Leopold has joined #openttd
07:12:34 <DorpsGek> - Add: summary for week 10 of 2024 (by OpenTTD Survey)
07:25:30 *** pickpacket3 has joined #openttd
07:29:52 *** pickpacket has quit IRC (Ping timeout: 480 seconds)
07:29:52 *** pickpacket3 is now known as pickpacket
07:33:55 <andythenorth> 'create random industries' in scenario editor is deterministic?
07:34:08 <andythenorth> seems to get repeatable results?
07:34:19 <andythenorth> or I'm just noticing co-incidences
08:11:22 <peter1138> Hmm, so is the audio buffer size on macOS?
09:15:21 <orudge> Nice, we are on the front page of slashdot
09:25:44 <peter1138> Slashdot is still a thing? 😄
09:26:42 <peter1138> They pretty much did.
09:30:32 <truebrain> Haha, OO is not KISS, nice 🙂
09:30:54 <truebrain> As they say: you do you, as long as you are having fun 🙂
09:31:55 <kamnet> I was just getting ready to comment on the CPU reduction. That seems interesting.
09:36:12 <truebrain> The part about wanting code without classes scares me a bit if it is upstreamable 🙂
09:42:54 <truebrain> btw, for those that wonder: I benchmarked all OpenTTD nightlies for the last .. 18? 24? months. There is no such CPU spike as described in the post. So I wonder if this isn't a debug vs release or something along those lines 🙂
09:42:56 <peter1138> Fortunately there is already a comment about upstreaming, so I don't need to wade in 🙂
09:43:20 <peter1138> You'll need to benchmark 12.2 though.
09:43:56 <truebrain> well, he says the memory went from 450MB to 900MB in 13 -> 14. I do not observe such jump in any of the games
09:45:09 <peter1138> Also just noticed LordAro's link is "comments.pl", and Discord thinks it's a download.
09:45:31 <truebrain> yeah, it made me laugh 😄
09:52:01 <_jgr_> Upstreamable seems unlikely given that it's just periodic zips on the forum without any source control that I can see
09:53:04 <_jgr_> That and it being stuck on 12.2, of course
09:53:24 <peter1138> Is it actually on the forum?
09:55:19 <peter1138> Now it makes sense.
09:58:05 <peter1138> "Enabled all industries from every climate"
09:58:25 <peter1138> Bet that doesn't cause issues with NewGRF 😄
10:02:48 <peter1138> His archive includes .swp files from nano.
10:03:25 <SigHunter> I want those other industries on temperate too, how?
10:04:55 <peter1138> And it's been through a linter so every file is different.
10:05:26 *** drludde has joined #openttd
10:08:29 <truebrain> Not everyone is good with version control systems or with C++; and that is fine 🙂 Might give some cool inspiration 🙂
10:09:05 <drludde> I saw the birthday post the other day and figured I could come in and say hi
10:10:50 <truebrain> drludde: welcome. Look at what you did. 😛
10:11:58 <drludde> 🙂 good to see it's going so well
10:12:39 <truebrain> The "well" depends on who you ask 😛
10:12:51 <drludde> i wonder if i would recognize any of the code if i looked at it
10:13:08 <truebrain> there is still some old stuff in there, whole parts are still plain C
10:13:47 <truebrain> sadly, because we lost the SVN history in 2004 somewhere, not sure if your name is actually on any commit .. so that makes looking for that a bit harder
10:14:20 <truebrain> 46 commits with your name on it .. let's see if we can find some code 😛
10:15:30 <truebrain> `(svn r2601) Fix: Added TIC,TOC macros do be able to do profiling easier.`
10:15:37 <truebrain> lol .. didn't know those were that old 😄
10:15:44 <LordAro> can't be all that many lines remaining from (the new) r1 at this point
10:15:58 <peter1138> They only recently got removed...
10:18:26 <aperezdc> drludde: thanks for both openttd and scummvm - and to everyone else involved, too
10:20:36 <_zephyris> Totally. Thanks for dropping by, nice to be able to say hi and thank you.
10:21:30 <drludde> np glad both of them are still alive
10:22:42 <drludde> seems like i don't have the initial source code around either, it probably got lost in some computer migration
10:24:38 <truebrain> we have sources back to 0.1.0
10:24:43 <truebrain> orudge did some gravedigging a while ago 😛
10:29:31 <truebrain> it is a bit silly how much information we retained .. every version released, chat-logs back to 2007 .. 😄
10:29:52 <truebrain> sadly, the sourceforge project is gone; there isn't any backup of that 😛
10:30:40 <LordAro> not like it takes up any real amount of space though :p
10:31:06 <truebrain> 104GB of stored artifacts
10:35:32 <drludde> I got around 10MB of IRC logs from 2004 🙂
10:36:07 <truebrain> I kinda lost those logs ... I still don't know when I made the first patch. Somewhere before Jun 2004, but .. I have no info from earlier 😛
10:36:17 <reldred> I probably would have been in just #tycoon back then
10:36:32 <reldred> (probably causing problems for everyone)
10:36:57 <drludde> your nick was TrueLight?
10:38:26 <emperorjake> drludde: Here, have a special role 🙂
10:39:42 <drludde> [18:22:32] <TrueLight> What I most like about amd64 and winxp64, is the fast opening of dirs and stuff... amazing 🙂
10:39:47 <andythenorth> drludde: just wanted to say thanks for the original conversion, this has given me a very fulfilling hobby for 15 years
10:39:54 <drludde> still using winxp64? 😄
10:40:05 <truebrain> haha, owh shit, I forgot that existed 😄
10:40:26 <truebrain> I did use that for months ... was such a thing, 64bit Windows .. lolz
10:40:31 <LordAro> fast opening of dirs definitely a big feature
10:40:50 <truebrain> even then I used smileys 😛
10:42:19 <drludde> does openttd still use the arrays with 6 bytes (or so) of data per tile
10:42:28 <truebrain> a few more bytes these days, but yes
10:42:57 <truebrain> many attempts have been done to rewrite the map structure, but none ever were fast enough or practical enough 🙂
10:43:07 <truebrain> so we still have m3, m4, ... 😛
10:44:20 <truebrain> LordAro: those globals have been removed a while ago 🙂
10:50:23 <reldred> jgrpp has some more as well
10:52:44 <peter1138> Yeah, they were separate arrays originally. They got merged when we reached 8 bytes, and then split into two when we went larger.
10:54:36 <peter1138> Is it lunch yet? Getting hangry...
10:55:04 <andythenorth> I recommend stem ginger cookies
11:01:24 <_jgr_> reldred: Nah, the map is still the same size and shape in my branch
11:02:13 *** Leopold has quit IRC (Remote host closed the connection)
11:02:35 <LordAro> truebrain: i lose track
11:02:48 <truebrain> I do too; it was only that I read the code and was like: owh! 😛
11:02:51 <reldred> _jgr_: i thought you had more bytes in the map array? or was it that there were unused bits we nicked for more newhouses?
11:02:54 <truebrain> those pesky C++-ifying patches
11:02:58 <truebrain> classes are the worst!
11:04:18 <_jgr_> reldred: There are plenty of spare bits, I haven't made it bigger
11:04:56 <peter1138> I added loads of space with NRT. Nobody complains and the game was(n't?) ruined...
11:06:15 <locosage> funnily I have some extra bytes on map array to cache zoning
11:07:27 <LordAro> i thought cmclient was client-side only?
11:07:40 *** Leopold_ has joined #openttd
11:07:42 <locosage> yeah, they're not saved, just map-sized cache
11:09:31 <truebrain> for shit and giggles I ran an estimate how much it costs to have a Cassandra cluster managed by Azure ... that monthly bill was a bit high 😛 Guess I will be doing it myself 😦
11:12:19 <reldred> anything on azure is normally an expensive prospect
11:13:14 <truebrain> meh; that is pretty much okay
11:13:25 <truebrain> in this case only it wanted to setup a 16-core cluster of 3 machines, with each 2x 1TB disks
11:13:35 <truebrain> I do not have that much data 😛
11:16:22 <LordAro> i'm sure you could if you tried
11:23:04 <truebrain> but I don't want to!!! 😛
11:24:37 <drludde> why did you move to C++ anyway
11:27:46 <truebrain> not sure there was actually a moment in time that was a delibrate decision .. but others know that better. I do remember it started to become more C++ at the time YAPF (a much faster pathfinder) got added .. and that developer also brought in a whole folder with his "personal helper classes", with various of C++ classes to make things easier
11:31:14 <LordAro> i find string handling in C a pain
11:31:25 <LordAro> and resizable containers
11:31:32 <truebrain> memory management 😛
11:31:42 <LordAro> so generally I use C++ just for std::string and yeah, auto memory management
11:31:49 <LordAro> it's not that i can't, it's more that i don't want to :D
11:31:57 <truebrain> I am happy to see we are finally starting to use actual C++ 🙂
11:32:14 <LordAro> no ranges just yet though :p
11:32:15 <truebrain> still a few mallocs left 😛
11:33:04 <truebrain> `# Setting listen_address to 0.0.0.0 is always wrong.`
11:33:10 <truebrain> guess what this boy is going to do!
11:34:45 <truebrain> `# For security reasons, you should not expose this port to the internet. Firewall it if needed.` Yeah .. opening a database to the internet is a terrible idea
11:34:48 <truebrain> /me does it anywy 😛
11:40:09 <peter1138> public read/write access to allow clients to update their data, yes.
11:40:30 <peter1138> (I've heard of people trying to do that, because they have no idea what they're doing...)
11:41:40 <peter1138> LordAro: clang-15 doesn't like ranges, so...
11:41:53 <peter1138> (Replying to LordAro there)
11:42:15 <peter1138> Oh yes, the bridge does at least add his nick 🙂
11:42:45 <peter1138> And clang-16 doesn't like libstdc++'s <=> operators.
11:43:35 <LordAro> (or maybe i don't, because reply threads)
12:13:05 <peter1138> Breakfastlunchtimeyay
12:15:08 <peter1138> Okay, so now MT-32 support is crucial.
12:20:03 *** pickpacket5 has joined #openttd
12:23:51 *** pickpacket has quit IRC (Ping timeout: 480 seconds)
12:23:51 *** pickpacket5 is now known as pickpacket
12:47:40 <johnfranklin> I think, OpenTTD can be considered as a "miracle"
12:48:23 <drludde> Orudge: I read your birthday post the other day and felt a bit nostalgic and just came in here to say hi 🙂
12:48:44 <johnfranklin> An Odyssey, a piece of symphony
12:50:49 <johnfranklin> Is Sweden still cold and dark?
13:10:20 <kuhnovic> They do have heartwarming children story books which bear the same name 🙂
13:15:27 <xarick> static void SetCurrentRoadType (RoadType road_type), I expected this to be a bool
13:21:00 <peter1138> It doesn't really do anything except remember it for future commands.
13:42:18 <peter1138> No, it's far too dull & muted.
13:51:35 <LordAro> i wonder if it's your recording software that doesn't do HDR properly rather than anything else
13:59:07 <truebrain> _glx_: what do you think about my ci-nightly solution? Would that work you think?
14:11:29 <truebrain> cool; tnx 🙂 Sadly, it breaks all current PRs, so I guess ... "merge now or rebase later" 😛
14:19:12 <_glx_> typical workflow changes problem 🙂
14:19:26 <peter1138> Hmm, backport #12265?
14:19:53 <_glx_> maybe, to prevent useless complains
14:20:07 <peter1138> Yeah, it's pretty minor, just added the tag.
14:24:10 <peter1138> `9047 Mar 21 2006 magic.diff`
14:24:16 <peter1138> Let's guess what's in this... 😄
14:24:50 <truebrain> I spend today trying to find my old backup of my OpenTTD patches, but I failed to locate anything older than 2007 😛 Think I never made a backup of my WinXP64 machine 😦
14:25:13 <peter1138> `7298 Sep 2 2005 freighttrains4.diff`
14:25:24 <peter1138> That's the earliest I have in this directory.
14:26:51 <peter1138> `2234 Mar 18 2006 vrfrev.diff` some very bad version of ctrl-click-in-depot-to-reverse-vehicle.
14:27:18 <peter1138> (It did not use a command, just changed the flag from within the gui...!)
14:28:23 <_glx_> it works, just don't do it in MP 🙂
14:43:04 <_glx_> it's even better than the description says
14:43:13 <truebrain> there is a high variance 😛
14:44:51 <truebrain> right, that should allow for more PRs/hr 🙂
14:52:57 <peter1138> So now we need to rebase 15+ PRs at once? 😄
14:54:39 <truebrain> And to be more clear: no, please no. It is rather likely someone comments on it anyway, you can rebase when you fix those comments
14:58:13 <orudge> drludde: well it's certainly nice to hear from you again, hope all is good with you?
15:20:38 <_zephyris> Bug? Looks like the 4x zoom roof recolour mask is aligned 2px too high. I'm pretty certain the sprites are correct...
15:22:23 <_zephyris> No, but you're right, I think it's a sprite size issue
15:22:39 <_zephyris> Ok, it's my problem 🙂 Must be an NML templating thing
15:24:28 <_zephyris> Ach, silly mistake. Thanks anyway!
15:25:23 <peter1138> In the 1x version the monorail canopy is missing two pixels of shading.
15:25:46 <peter1138> But that's in the current version, you might have fixed that. (It also might affect the non-Hi Def set)
15:26:04 <_zephyris> You're on the right track 😉
15:26:26 <_zephyris> I updated the templating to fix the missing bottom pixels, didn't update the size of the transparency/mask sprite
15:28:11 <_zephyris> `64*z` -> `64*z+z-1` Sorting the multiple zoom levels is a right pain
15:28:57 <peter1138> Tried providing only the 4x versions?
15:29:05 <peter1138> Let the game do the rest.
15:29:23 <peter1138> Just, might not look so good.
15:29:42 <_zephyris> Yeah, it doesn't look great
15:30:37 <_zephyris> Looks _OK_, but as a 1x zoom set is useful then its worth the effort of doing both
15:56:06 *** Wormnest has joined #openttd
16:25:28 <Rubidium> truebrain: the vcpkg change has caused quite a few code scanning warnings (CodeQL). Looks like it has picked up vcpkg compilation bits as well, which I find weird as vcpkg is compiled before codeql is configured
16:25:57 <truebrain> Indeed. I thought I checked that .... grrrrr
16:26:51 <truebrain> That does make sense
16:27:01 <truebrain> We should put them on the ignore list I guess 🙂
16:27:48 <Rubidium> yeah, I was also thinking about adding vcpkg/** or something to there
16:28:54 <truebrain> Or possibly we can install vcpkg somewhere else .. that might also help
16:30:14 <xarick> I'm getting a weird crash with BorkAI, and only seems to happen with Wallclock time
16:30:32 <_glx_> AI crash or game crash ?
16:31:18 <xarick> seems to be about getting production tiles
16:31:24 <xarick> but that makes no sense
16:32:07 <_glx_> maybe unexpected empty array
16:33:39 <xarick> return _acceptance[cargo];
16:34:47 <xarick> does any of this looks suspicious?
16:36:04 <_glx_> it probably never execute the if
16:36:51 <drludde> xarick: What language is this?
16:37:27 <_glx_> it's our AI/game script language
16:53:40 <peter1138> Feels like vcpkg is in the wrong place, tbh 🙂
16:54:13 <peter1138> Wonder if that will take any time off the task.
16:54:53 <peter1138> Hmm, my VS Code is broken when debugging dotnet, it can no longer continue after a breakpoint 😦
16:58:00 <_glx_> hard to put it somewhere else
16:58:06 <truebrain> peter1138: It kinda is ... ugh, more effort 😛
16:58:23 <truebrain> We can just put it in /vcpkg
17:00:26 <_glx_> truebrain: ah yes, like release-linux
17:00:52 <truebrain> Yeah .. and let's do that for all targets, so they are the same
17:01:01 <peter1138> I didn't mean you should change it!
17:03:18 <truebrain> Going to eat it instead, okay? 🙂
17:12:02 <xarick> I have no idea what yield does in sqirrel
17:16:13 *** gelignite has joined #openttd
17:29:28 <xarick> I don't understand the code in borkai, seems too advanced for my liking
17:31:39 <peter1138> Afraid you might learn something? 😄
17:34:24 <xarick> he's putting functions as arguments
17:34:35 *** HerzogDeXtEr has joined #openttd
17:34:36 <xarick> toying with them like nothing
17:34:45 <xarick> and I just can't follow
17:35:18 <xarick> therefore, I don't know why the script crashes
17:35:47 <LordAro> "toying with them like nothing" :D
17:36:03 <LordAro> you wouldn't like scheme
17:37:00 <_glx_> it crashes because `_acceptance[cargo]` doesn't have the value in `cargo` as index
17:37:24 <_glx_> which means `this._acceptance[cargo] <- tiles;` was not executed
17:38:03 <xarick> somehow it's related to wallclock being the cause
17:38:04 <_glx_> which means `now - prev > OLD_DATA_THRESHOLD` was false
17:38:35 <_glx_> and `now` used GetCurrentDate
17:41:34 <xarick> now is 362, prev is 0, OLD_DATA_THRESHOLD is...
17:42:19 <xarick> I don't even know where it is
17:42:43 <LordAro> have you tried searching for it?
17:42:53 <_glx_> line 91, just above the failing function 🙂
17:43:48 <xarick> ah found it, sorry I'm slow
17:44:17 <LordAro> but something to search in all files would probably be better generally speaking
17:45:03 <xarick> interesting then the issue is economy date starting at such low values
17:45:28 <_glx_> it starts near 0 in wallclock
17:45:39 <LordAro> presumably you'd see similar issues if you started the game in year 1 ?
17:46:04 <_glx_> yeah it's equivalent to year 1 in 13.4
17:48:15 <xarick> you're only useful in Calendar mode
17:48:27 <xarick> yes, but is the author alive?
17:50:21 <_glx_> it's not surprising if old stuff doesn't fully work with new features
18:10:59 <truebrain> owh, right, permission issues
18:12:48 <_glx_> of course it works in docker runners but not here
18:19:42 *** Leopold_ has joined #openttd
18:20:56 <truebrain> I CAN DO THIS (some day)
18:21:55 <truebrain> very happy with how vcpkg uses GitHub Cache
18:21:59 <truebrain> makes partial runs a lot faster 😛
18:23:08 <_glx_> yeah way better than the old way, which was not caching anything on fail
18:23:27 <truebrain> whoho, finally all targets like my change \o/
18:23:31 <truebrain> only took, what, 5 attempts?
18:23:43 <peter1138> Hmm, the things I make you do, accidentally...
18:23:52 <truebrain> no, when you are right, you are right
18:23:58 <truebrain> no need to take it back 😛
18:27:05 <truebrain> (yes, I changed the title 😛 )
18:28:52 <kuhnovic> _zephyris: Can I ask you with puppy eyes to make an announcement image for RC2? 😇
18:34:30 <truebrain> ghehe, funny, with the new MacOS M1 hosts, MacOS isn't the slowest release build anymore 🙂
18:34:34 <truebrain> in fact, it is now the quickest 🙂
18:34:43 *** Leopold_ has joined #openttd
18:35:11 <truebrain> from 19m to 14m .. that is a nice speed-up
18:36:01 <peter1138> Any chance we can get the ttf updated for RC2?
18:36:39 <peter1138> And maybe merge more things marked as backport.
18:36:41 <_glx_> and macos build is not parallelised
18:37:55 <truebrain> peter1138: that would be 1 PR 🙂
18:48:09 <peter1138> Ah they are not unflagged yet.
18:48:37 <peter1138> Oops, I was thinking about going out on the MTB tonight... and forgot.
19:15:43 <peter1138> Silly, you can eat dinner at the keyboard!
19:16:17 <truebrain> peter1138: Yeah, backport PR is pending. Needs an approval and stuff 😛
19:25:49 *** Leopold_ has joined #openttd
19:29:37 <truebrain> owh, kuhnovic introduced the `_random.Next()`. So that is just an oversight of not knowing not to do that 😄
19:30:21 <truebrain> you used `_random.Next(l)` instead of `RandomRange(l)`, bypassing the `RANDOM_DEBUG` stuff 😄
19:30:44 <truebrain> the reviewer (me) should have seen that 😄
19:33:05 <michi_cc> truebrain: That can be partly fixed.
19:35:26 <michi_cc> kuhnovic: If you do merge it, a) rebase, not squash, and b) you need to run `backport.py --mark-done 12246` to get the proper tracking of the tags on the PRs.
19:35:27 <kuhnovic> truebrain: That doesn't explain much tbh 😛
19:35:42 <truebrain> look at the PR otherwise? 🙂
19:35:57 <truebrain> also, not important; I was more curious how long it has been in our code. Not long, was the answer 🙂
19:36:16 <truebrain> michi_cc: then repeat it again if you plan to release today \o/ 😄
19:36:29 <kuhnovic> Oh there's a PR already. TrueBrain working at light speed as always
19:36:39 <truebrain> I was talking about the PR I made, yes 😛
19:37:06 <michi_cc> truebrain: WinXP 64-bit was nice. There's a reason why I turned up with some 64bit patches to OTTD 🙂
19:37:25 <truebrain> I switched to Getoo at some point, for some reason
19:37:33 <truebrain> also the moment my history of logs and projects start
19:38:06 <kuhnovic> Would be nice if we somehow made it impossible to use _random directly. But that might be difficult
19:38:26 <kuhnovic> michi_cc: Let's see if I can get this done
19:38:33 <michi_cc> I think I had played some OTTD (but mostly TTDPatch though), and was like: All my software is still 32-bit, is there anything that I can run 64-bit native? And well, OTTD could (with some patches) 🙂
19:39:10 <truebrain> I spend a good part of my day trying to find the first ever patch I made, but .. history of 2004 is not complete 😛
19:39:27 <truebrain> my memory suggests it had to do with company president faces
19:41:46 <truebrain> owh, and kuhnovic , just so you have some appreciation of the script you are using ... normally this was done manually. Find the PRs, cherry-picking them, marking them .... just saying 😉
19:43:22 <truebrain> a lot of projects make a single PR per "to backport PR", automated when you mark it as "to backport" and after merge. Sounds very loud to me, but I have seen many use it.
19:44:01 <kuhnovic> That must have been so time consuming and error prone!
19:44:15 <kuhnovic> I have to say, the level of automation you guys have achieves is impressive
19:44:18 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
19:44:30 <truebrain> fall and learn, etc 😛
19:44:37 <truebrain> 20 years of experience 😄
19:44:42 <michi_cc> Blood, sweat and tears ❤️
19:45:04 <kuhnovic> Haha yeah. For the love of trains 😉
19:45:40 <michi_cc> Of course, all the CI/CF stuff of GitHub does help. We had some Azure stuff before, but that was more limited (or would have cost a lot more).
19:45:44 <truebrain> back "in the old days", we had a developer that worked as a university, and they had a big cluster there .. he allocated 1 of those nodes to be the CI of OpenTTD. We used that for years 😛 Still mind boggling that was even possible 🙂
19:46:19 <kuhnovic> Oh man, that shit can get you fired!
19:46:40 <kuhnovic> michi_cc: it wouldn't hurt to double check if I did it right 😉
19:47:09 <truebrain> was an improvement over asking individual developers to build for target XXX
19:47:41 <michi_cc> Looks fine, I just checked a couple PRs, but the proper tag was applied so a new run of the script won't pick up the same things.
19:48:06 <Rubidium> oh... the weeks (if not months) spent on trying to get Mac OS X to cross-compile...
19:48:30 <truebrain> I wrote a whole blog about how to cross compile for OSX .. was popular for more than a few years 😛
19:48:48 <michi_cc> #12274 is marked as well though, even if not yet merged. So that would need a second backport script run before a release could be done.
19:48:51 <kuhnovic> The self torture you guys impose on yourself sometimes 😛
19:48:54 <_zephyris> kuhnovic: If you still need it! Looks like it's been the same BG for each beta/RC, so I just changed it to the OpenTTD font.
19:49:05 <truebrain> michi_cc: also for last-minute translations 🙂
19:49:06 <michi_cc> And don't forget the changelog date 🙂
19:49:47 <michi_cc> _zephyris: Is there anything new on the font front to pick up for 14?
19:50:01 <Rubidium> last minute translations? Are you going to wait on tonight's eints run? ;D
19:50:15 <truebrain> no, but shockingly, last night eints also did a run 🙂
19:51:07 <Rubidium> ah, okay... if that counts as last minute... then yes :D
19:51:30 <truebrain> Rubidium: sometimes, if we are really nice to the translators, we manually kick off the job just before the final backport for a release
19:51:33 <kuhnovic> So just as a heads up: I have family over from Norway, and I'm feeling a little under the weather at the same time. I'm not sure how much I'll be able to spend openttd stuff the next few days...
19:51:37 <truebrain> but as this is just an RC .. not that bothered by it 🙂
19:51:50 <_zephyris> michi_cc: Yeah, a couple of tiny fixes. I can do a push, if now's the right time.
19:52:20 <michi_cc> Better with a RC than a final release I'd say.
19:52:39 <truebrain> kuhnovic: personal life always comes first 🙂 No worries 🙂
19:52:45 <michi_cc> And we have to backport anyway.
19:53:10 <kuhnovic> truebrain: I know, I just wanted to inform you guys since I'm working on the release 🙂
19:54:10 <michi_cc> Thankfully, if backports are done and an annoucement is prepared, the rest ist literally mostly watching paint dry (i.e. stare at GitHub actions) 🙂
19:55:32 <truebrain> `2008-12-09 00:56 openttd-web/home/truebrain/public_html/mapgen/` .. working on heightmaps based on real world data back in 2008. Ironically, now it is my dayjob 😛
19:56:28 <kuhnovic> What a lazy job, working with heightmaps in the Netherlands...
19:56:41 <truebrain> for the Netherlands; rarely in 😛
19:57:16 <kuhnovic> NL heighmap: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... until you hit the Vaalserberg
19:57:40 <truebrain> the most height differences are underwater (within Dutch borders)
19:57:41 <kuhnovic> truebrain: Ok fair enough 😛
19:59:04 <kuhnovic> truebrain: I can imagine. The dutch waterworks and shipping infrastructure are fascinating.
19:59:48 <truebrain> and creating islands etc 😛
20:01:15 <peter1138> 4x slower sounds is amusing.
20:01:20 <peter1138> But then, I'm easily amused.
20:01:46 <peter1138> Everything sounds like far away heavy machinery.
20:04:39 *** Leopold_ has quit IRC (Read error: Connection reset by peer)
20:05:25 <kuhnovic> Is this something I should follow up on?
20:05:41 <truebrain> it wants you to make a PR from release/14 to master
20:06:06 <kuhnovic> That's what I thought haha
20:06:15 <andythenorth> peter1138: is it The Bristol Hum?
20:07:18 <truebrain> right, let's run some more performance tests over the last few weeks, see if we had some last minute issues 🙂
20:07:46 *** Leopold_ has joined #openttd
20:11:08 <peter1138> My screen recorder doesn't capture sound 😦
20:18:55 <truebrain> Awh, because of sourceline thingy I have to upgrade the compiler for the performance test, which strictly seen means I would have to rerun everything 🙂
20:19:49 <truebrain> Guess for now I run up till that commit 🙂
20:25:09 *** gelignite has quit IRC (Quit: Stay safe!)
20:26:07 <_glx_> truebrain: I have an svn clone of that somewhere
20:26:47 *** Leopold has joined #openttd
20:33:23 <_zephyris> michi_cc: I'll double check all the current translations then do a PR tonight
20:35:44 <truebrain> hmm .. with MacOS building OpenTTD in ~3 minutes, I wonder if I can use that to do performance measuring .. which means the main question is, does MacOS have a tool that counts CPU instructions executed 🙂
20:41:51 <truebrain> in the last few weeks, there was something that influenced memory 🙂
20:42:02 <truebrain> need to run it longer for finding out which day that happened 😛
20:42:13 <truebrain> CPU-wise also something happened
20:46:26 <_glx_> truebrain: most likely one of the fixed length to dynamic length of some data
20:46:41 <truebrain> that should reduce memory; not increase it 😛
20:47:13 <truebrain> over all games it is a ~8% increase in memory 🙂
20:49:55 <peter1138> Is it "I had to use a different compiler?" 😉
20:51:03 <_glx_> no need to switch compiler until very recent changes
20:51:13 <truebrain> I can't do the last 2 days, indeed
20:51:18 <truebrain> but I can do everything else
20:51:32 <peter1138> Ah, just the last 2 days.
20:52:01 <peter1138> Well, now I'm wondering what I've done that's very bad 😮
20:52:26 <Rubidium> wasn't some hash changed recently?
20:53:32 <Rubidium> (or I am imagining remembering something related to that?)
20:54:04 <peter1138> No, I did look at the hash but didn't actually change it. With Xarick's saves it does improve performance, but normal saves... not that much.
20:54:19 <peter1138> Pool bitmap would add memory, but not all that much.
20:54:33 <peter1138> Also unit id bitmap, but also not that much.
20:54:37 <truebrain> after 2023124 and before (or on) 20240118 .. but my script is bisecting 🙂
20:55:05 <peter1138> But they're all things that trade memory for CPU, not add both.
20:55:35 <truebrain> I really want to make this a daily job, so we just see these things sooner 🙂
20:55:49 <locosage> on small games there may not actually be any cpu gain
20:55:52 <truebrain> there are even workflows that do it on PR 🙂
20:56:00 <truebrain> but that sounds excessive 🙂
20:56:18 <_glx_> oh maybe vehicle numbers, they are now cached
20:56:24 <peter1138> True, normal saves not a huge gain, but also not really a huge hit either.
20:56:40 <truebrain> main issue with benchmarking for us is, that the compiler+dependencies actually matter
20:57:11 <peter1138> _glx_: That's Feb 25th, so after.
20:57:34 <peter1138> Pool bitmap is Feb 17th, so after as well.
20:57:35 <Rubidium> Jan 16 we went to C++20
20:58:08 <peter1138> Shall we carry on speculating or just let TrueBrain's script do its magic? 😄
20:59:28 <peter1138> CargoID changes right?
21:00:36 <peter1138> Is it the switch from C to C++?
21:01:22 <truebrain> hmm .. the M1 runners are kinda useful for benchmarking, as you know exactly what CPU it is running on. I wouldn't be so sure for the other runners we know. So if I can find out how to know how much CPU instructions are executed on MacOS, that would kinda work
21:01:50 <truebrain> also a small reminder that these are a random collection of games I execute with `-vnull`; so actual performance may vary 🙂
21:02:31 <peter1138> Just needs some results from cross-over of versions and then data can be roughly extrapolated. Or just retest everything again...
21:04:12 <peter1138> _zephyris: not brave enough for the Hebrew?
21:05:25 <truebrain> building on MacOS is ~4 minutes .. so doing 2 years only takes 2 days .. that is not bad 🙂
21:05:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:06:25 <truebrain> sometimes, you have reasons 🙂
21:06:56 <_glx_> yeah better support macos-14 before it becomes latest and breaks stuff
21:07:07 <truebrain> and macos-14 has arm64 🙂
21:07:18 <_zephyris> peter1138: I'm brave enough, just haven't had time!
21:11:33 <truebrain> between 20240105 - 20240118 .. the window is shortening 🙂
21:12:48 <frosch123> rb's prediction still holds
21:13:22 <peter1138> So we revert C++20? 😄
21:15:29 <truebrain> hmm, seems I am compiling on a single core
21:15:52 <truebrain> did tell it to use 10
21:16:57 <Rubidium> you didn't sample the number of cores when it was doing the linking, right?
21:20:39 <frosch123> smatz used to track compilation time. you could tell he was a gentoo user
21:21:18 <truebrain> I wish there was a more deterministic method of measuring CPU usage
21:21:28 <truebrain> I now use the instruction count, which is stable within a few percent
21:22:03 <truebrain> hmm .. I did plan to experiment with WASM for that, as there it is easier to measure instructions-executed
21:22:19 <frosch123> doesn't the kernel track process time?
21:22:33 <truebrain> with `perf stat` you can track instruction count
21:22:41 <truebrain> but depending on branch prediction etc, that varies a tiny bit
21:22:44 <truebrain> enough that you see it
21:22:50 <truebrain> not enough that trends go unnoticed 🙂
21:22:57 <_jgr_> How long a single instruction takes to complete can by vary by more than 2 orders of magnitude though
21:23:17 <_jgr_> It's not quite the same as CPU usage
21:23:25 *** Leopold has quit IRC (Remote host closed the connection)
21:23:45 <truebrain> this is the variation with instruction count
21:23:53 <truebrain> so all within 1% of each other
21:23:58 <truebrain> so stable enough for these kind of measurements
21:24:05 <truebrain> and better than CPU time etc, at least: much more stable
21:24:34 <truebrain> _jgr_: in some WASM engines it defines an estimate of each instruction, and adds that up
21:24:41 <truebrain> still not perfect, but it is an estimation
21:24:51 <truebrain> (mostly means for things we do with Squirrel, interrupt if they take too long 😛 )
21:26:32 *** Leopold has joined #openttd
21:26:50 <truebrain> okay, both CPU and memory didn't happen on a single day
21:29:31 <_jgr_> For memory use, the first bump could be water regions, the cost is proportional to the map size?
21:30:00 <truebrain> is that 5MiB of RAM?
21:30:47 <truebrain> would mean ~80 byte per region, if my math is right
21:32:02 <peter1138> WaterRegion is 280 bytes.
21:34:00 <truebrain> memory and CPU spikes between 2024-01-05 and 2024-01-08
21:34:01 <peter1138> I can reduce it by 4 bytes by shuffling it around, which is... perhaps not worth it 😄
21:34:14 <truebrain> (2024-01-05, 2024-01-08]
21:34:27 <_jgr_> You can reduce it by ~256 bytes by making the label array optional
21:34:43 <_jgr_> It's not needed most of the time
21:35:03 <truebrain> that sounds something worth doing 🙂
21:35:54 <peter1138> Then it's 32 bytes.
21:36:52 <truebrain> for a 4k x 4k map there are, what, 64k regions?
21:38:38 <truebrain> there is one game, that went up with 200% in CPU. But that got fixed in a later commit 😛 Still funny 🙂
21:40:09 <_jgr_> I've got WaterRegion down to 24 bytes, the tile area doesn't need to be in there either
21:41:26 <truebrain> right, let's see if the CPU and memory spiked at the same day ..
21:41:43 <truebrain> as I would not expect the CPU to go up with the water regions tbh 🙂
21:44:43 <truebrain> hmm .. I should also add some metadata about what the savegames are, map-size, unit-count, etc
21:45:06 <truebrain> although I know `lordaro_biggest_town_ever.sav` has no ships 😄
21:46:09 <truebrain> owh, CPU changes btw can also be loading of the game, afterload, etc
21:47:09 <andythenorth> are there M3 runners yet? 😛
21:47:22 <_glx_> there was water region stuff in savegame, removed very soon
21:47:46 <truebrain> sadly, memory only increased 😛 So it is not that 😄
21:47:58 <truebrain> andythenorth: not even M2 runners 😦
21:48:48 <peter1138> Are we really that unapproachable?
21:48:57 <xarick> there's a spike of cpu load at the beginning of a load, I notice it on my 70k ships savegame example, it's water regions filling the cache
21:50:32 <truebrain> peter1138: in what context? 🙂
21:51:45 <truebrain> no, we do not skip unknown chunks
21:51:50 <truebrain> we abort if we see an unknown chunk
21:52:34 <truebrain> (I know, as you are not the first to suggest that 😄 )
21:53:34 <frosch123> hmm, okay, i guess we usually convert old savegame data
21:53:47 <frosch123> so maybe there is no precedent of removing something without using
21:53:57 <frosch123> though, maybe original ai stuff
21:54:17 <truebrain> okay, the first mem/cpu spike is indeed on the 8th of Jan
21:54:45 <truebrain> so _jgr_ 's idea would most likely fix the memory, but the CPU needs a bit more looking into
21:54:50 <truebrain> now onto finding where the second spike happens 🙂
21:55:31 <truebrain> for the CPU, games with only one single massive town, and almost no water, consumes 3% more CPU
21:56:17 <truebrain> and if someone wants to look into the, the 1.0 title game is a good game for that, it seems 🙂
21:56:36 <_glx_> water region invalidation by town changing tiles ?
21:56:38 <frosch123> wow, there is a crapton of code to load and discard old AI data
21:57:05 <truebrain> _glx_: we can guess all day, or someone just runs a profiler over a 20240107 and a 20240108 with the same game 🙂
21:57:05 <_glx_> it just sets a flag, but can do it a lot
21:57:10 <truebrain> dates are btw "end of day" dates 🙂
21:57:15 <truebrain> so last commit of that day, in UTC
21:57:34 <truebrain> (so not nightlies 😛 )
21:59:55 <andythenorth> 2x zoom for cargo icons? 😛
22:00:03 <andythenorth> not that I want to draw cargo icons ever
22:00:13 <peter1138> I've been saying that for months
22:00:19 <truebrain> _glx_: well, so only the first 2 commits 🙂
22:00:41 <michi_cc> truebrain: macOS has dtrace, which should be able to trace a lot of stuff. Unfortunately, it seems that it won't really work if the normal system protection is on, and its probably unlikely you can change that on a shared runner.
22:00:56 <truebrain> no "perf stat" on MacOS?
22:02:48 <truebrain> overnight I will fill in the rest of the blanks; but these two dates are the ones with the most impact
22:03:11 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:04:10 <truebrain> the one of the 14th maybe font loading?
22:04:41 <truebrain> (Current way of measuring can be easily poluted by start-up time)
22:04:42 <michi_cc> For CPU, is the run you are doing drawing to somewhere?
22:04:59 <truebrain> `-vnull`, but it still draws
22:05:02 <michi_cc> I'd assume TTF drawing to be slower than the plain sprite drawing.
22:05:17 <michi_cc> Both from the font access and from running a much heavier layouter.
22:05:41 <truebrain> also uses ~2MB more RAM
22:06:01 <_glx_> glyphs bigger than sprite font
22:06:16 <truebrain> one game even 10MB more RAM
22:06:30 *** Leopold has quit IRC (Ping timeout: 480 seconds)
22:06:39 <truebrain> (33MB -> 43MB, for context)
22:07:03 <michi_cc> Can you give have custom openttd.cfg? If yes, a `[misc] prefer_sprite_font = true` should make a difference.
22:07:38 <truebrain> not easily; but that can be compared locally
22:08:09 <truebrain> anyway, even despite all this, the worst game in the set uses 5% less memory than 12.0, and most 30% less memory than 12.0 🙂
22:08:18 <truebrain> games like wentbourne even 40% less
22:08:35 <truebrain> (even compared to 13.0, as 12.0 and 13.0 don't differ that much 😛 )
22:10:00 <xarick> I noticed building openttd in visual studio was becoming slower
22:10:08 <xarick> is that what you're looking into?
22:11:11 <xarick> it's like, I change 1 file, and bam, 400 now needs to be rebuilt
22:11:26 <andythenorth> peter1138: I didn't play the game for months 😛
22:11:29 <andythenorth> only drawing trains
22:11:57 <truebrain> right, time to let this run over night, and watch some telly 🙂
22:12:16 <peter1138> truebrain: Oh the usual.
22:12:29 <truebrain> what website were you reading this time? 😄
22:13:53 <xarick> minimap fully zoomed out, all those white dots are the 70k ships
22:15:06 <peter1138> xarick: That just means 1 change affects lots of the code. It is not a concern.
22:15:35 <_glx_> usually a header or english.txt
22:16:22 <_glx_> if you only touch cpp files there's no need to rebuild everything
22:16:58 <xarick> I notice more when I add comments, or fix a typo on a comment, seems to trigger multiple files needing rebuild
22:17:06 <_glx_> one script hpp touched regenerates all API files
22:17:09 <xarick> when it's code, it's much faster
22:18:48 <_glx_> comments in API headers I guess
22:19:23 <peter1138> Yeah, that's not because you're touching comments, it's *where* you are touching comments.
22:19:56 <peter1138> Hmm, resampling down seems to not work :S
22:23:21 <peter1138> Ah no, I broke decoding of Opus files.
22:25:43 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:28:18 <truebrain> _jgr_: am I right to assume you are building or have a patch for the water regions memory usage? 🙂
22:31:01 <_jgr_> I changed various other things related to water region storage/types so it's not going to apply cleanly on vanilla
22:31:01 <truebrain> Mind upstreaming that? 🙂
22:31:22 *** Leopold has joined #openttd
22:31:36 <_jgr_> Sure, shouldn't take too long
22:32:31 <peter1138> Hmm, how do I get to this last secret...
22:33:11 <truebrain> _jgr_: Owh, you have that for a while already, lol. Always feel free to poke us when you discover these kind of things 😄
22:33:56 <xarick> I have too many PRs open 😦
22:38:54 <peter1138> Found it. It was a linedef.
22:39:14 *** Leopold___ has joined #openttd
22:42:20 *** Leopold has quit IRC (Ping timeout: 480 seconds)
22:43:12 <andythenorth> linedef glitch, run through walls
22:43:58 <andythenorth> this ellipsis is funky eh 🙂
22:44:21 <_zephyris> _zephyris: I had an nml mistake, but the nml fix didn't fix it... unless I'm missing something else. Is the sprite loading/padding process offset dependent?
23:00:33 <_glx_> andythenorth: there was a fix for that
23:00:53 <_glx_> it's not supposed to shade black
23:20:10 <peter1138> Such CPU instructions...
23:28:26 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:32:20 <peter1138> Heh. I saw 4096 and thought something page-size mitigating... and I wasn't far off 🙂
23:32:48 <LordAro> my solution was to increase the stack size
23:47:56 *** Artea has quit IRC (Ping timeout: 480 seconds)
23:53:07 <peter1138> Is it not working as intended?
23:55:38 <LordAro> peter1138: it only crashed in a release build, which didn't help
23:55:48 <LordAro> but there was nothing obvious i could remove from the stack either
23:56:18 <LordAro> the stack was ~95 functions deep due to a mildly recursive algorithm, but nothing i could really do anything about
23:56:50 <LordAro> (and only on Windows, which only has 1MB stack anyway)
23:57:40 *** Leopold___ has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
