IRC logs for #openttd on OFTC at 2024-03-16
โด go to previous day
01:48:31 *** tokai|noir has joined #openttd
01:48:31 *** ChanServ sets mode: +v tokai|noir
01:55:12 *** tokai has quit IRC (Ping timeout: 480 seconds)
02:09:46 *** gelignite has quit IRC (Ping timeout: 480 seconds)
02:16:22 *** tonyfinn has quit IRC (Quit: Client limit exceeded: 20000)
02:23:41 *** Wormnest has quit IRC (Quit: Leaving)
02:37:59 *** geli has quit IRC (Quit: Stay safe!)
03:09:02 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:19:09 *** Flygon has quit IRC (Remote host closed the connection)
03:35:35 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:03:30 *** gnu_jj_ has joined #openttd
04:06:42 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:41:31 <DorpsGek> - Update: Translations from eints (by translators)
05:58:06 *** keikoz has quit IRC (Remote host closed the connection)
06:49:23 <salut3585> When OpenTTD starts, sprites are loaded from the server.
06:49:23 <salut3585> Do I need a new sprite in OpenTTD or do I need to add a new sprite only in OpenGFX?
06:50:45 *** tramrider has joined #openttd
07:58:28 <truebrain> Vcpkg finally merged the PR .. seems nightly works again ๐
08:07:38 *** gelignite has joined #openttd
08:26:17 <truebrain> right, time to see if I can understand what Rb has been up to with his network changes ๐
08:49:05 <truebrain> using a pointer as boolean to indicate whether it is read or write .. now that is nasty ๐
09:02:39 <_zephyris> Word instead of byte for vehicle purchase and running cost multipliers?
09:04:28 <truebrain> these are serious hard to review; not your fault Rubidium, but pfff, our network protocol isn't the easiest to load in my human memory again
09:20:21 <truebrain> the mad man even wrote unittests ๐
09:33:30 *** SigHunter has joined #openttd
09:38:10 <truebrain> I forgot .. how do I make code suggestions in GitHub?
09:38:27 <LordAro> you click the suggestions button
09:38:39 <truebrain> and where might that be?
09:38:47 <LordAro> left side of the comment window
09:38:59 <LordAro> but not there at all if you're actually looking at the commit rather than the PR
09:39:14 <truebrain> glad you understand GitHub logic ๐
09:39:22 <truebrain> thank you! I thought I was going insane ๐
09:45:46 <truebrain> so first make it a comments in the commit
09:45:49 <truebrain> then go to the total overview
09:45:52 <truebrain> and change them in suggestions
09:45:56 <truebrain> the things I do for you Rb ๐
09:49:51 <truebrain> I still really dislike GitHub for now having "patchsets" of any kind, so I can see what changed in the PR changes
09:50:03 <truebrain> I understand from a git perspective why this is the case, but still .. would be nice ๐
10:19:54 <truebrain> Rubidium: wow, that Write() function for MAP_DATA is .. special ๐
10:21:13 <truebrain> it is much more complicated than it has to be .. but okay, not a problem for that PR ๐
10:27:59 <truebrain> LordAro: it is a bit weird that the suggestion button is not there in commits, given that it is just a markdown syntax to make it happen ๐
10:30:54 <LordAro> truebrain: except suggestions have to have a PR to apply to
10:31:05 <LordAro> otherwise where would the suggestions go?
10:42:31 <truebrain> LordAro: Fair. Still annoying ๐
10:50:34 <michi_cc> truebrain: Use `std::byte` for proper pain ๐
10:52:17 <truebrain> Also why I personally prefer uint8_t ๐
10:54:51 <tramrider> Anybody here familiar with road vehicles and how to check if they are moving or not? The RoadVehicleStates enum does not seem clear about whether it contains this information.
11:06:10 <michi_cc> tramrider: Most parts of the code just seem to check cur_speed, maybe combined with vehstatus VS_STOPPED.
11:07:43 <tramrider> thanks for the leads michi_cc !
11:08:22 *** gelignite has quit IRC (Quit: Stay safe!)
11:55:06 <merni> I wish github had a way to accept suggestions without creating a new commit
11:55:18 <truebrain> where should they go then?
11:55:49 <merni> They already have an option for rebasing for when the branch is out-of-date from master
11:55:54 <truebrain> ah, yes, the merge vs rebase debate; GitHub is "somewhere in between" ๐
11:56:05 <truebrain> indeed in some places they tailor towards the rebase workflow
11:56:11 <truebrain> in other places they only allow the merge workflow
11:56:13 <merni> truebrain: Well, openttd isn't, hence the issue :p
11:56:16 <truebrain> it is seemly a hard problem ๐
11:56:34 <Rubidium> truebrain: I agree about the separate PRs, but once you have stacked the third PR, adding any more only makes your work hard for no gain... until those earlier PRs get merged. Then it's time to split things up
11:56:51 <truebrain> I wish I could create a PR with: "I will squash this", so we can skip commit-check validations after the first commit ๐
11:56:55 <truebrain> would solve a lot of issues ๐
11:57:04 <truebrain> but we can't hook a script between GitHub and you pressing the merge button
11:57:15 <truebrain> that would be fantastic .. that we can reject merges because of X, Y or Z
11:57:27 <truebrain> there is a concept called "merge queue", which kinda does this
11:57:38 <truebrain> you add your PR to the queue for merging, and the CI first runs some check if it actually can, before doing so
11:57:48 <truebrain> but it is not the most clear etc
11:58:00 <truebrain> Rubidium: totally fine; at least we are on the same page there ๐
11:58:11 <merni> Hm, there are debug/release CI for clang, could that not be moved to Mac OS now that it is so fast?
11:58:28 <merni> Oh F I forgot to change the header file
11:58:51 <merni> OK, now I'm glad there is no "accept suggestion by rebase" button :P
11:58:52 <truebrain> merni: yeah, that could; mind PRing that?
11:59:08 <merni> truebrain: I know nothing about how CI stuff in github works, thogh
11:59:20 <merni> I'll take a look though
11:59:22 <truebrain> an opportunity to learn! ๐
11:59:25 <merni> after I fix this broken build
11:59:52 <truebrain> without joking, give it a go; but I can imagine it is a lot. Me or glx can look at that some other time, as it is a nice suggestion ๐
11:59:58 <truebrain> saves 7m on the PR-CI-time ๐
12:00:46 <truebrain> Rubidium: I also assumed this would hook into #11878 (admin port encryption)?
12:04:23 <Rubidium> well, admin port authorized keys as that PR did not perform encryption on the admin port. But yes these PRs grew out of there, so the amount of changes for #11878 should be significantly less after the game-socket stuff is done
12:04:39 <truebrain> I assumed as much, but good to check ๐ Tnx ๐
12:04:44 <Rubidium> but one hell of a conflict hell :(
12:06:25 <truebrain> hopefully easy to fix? ๐
12:07:09 <merni> Is there any way to test CI locally?
12:07:22 <truebrain> in your fork, by creating a PR to your own fork master
12:07:40 <merni> I've done that before ๐คฆ
12:08:01 <truebrain> means you know how to do it ๐
12:08:14 <merni> Well it wasn't CI related things
12:09:14 <truebrain> time to replace some `byte` and `short` entries with their alternative ๐
12:13:37 <truebrain> VSCode has a hard time reasoning over 327 files ๐
12:14:18 <michi_cc> Your call when you want to publish the blog, but I'll approve the PR whenever you are ready.
12:15:14 <michi_cc> Also, seeing that we can apparently compile again, shall we also do RC2?
12:15:27 <merni> Could Dedicated also be moved to macos?
12:16:31 <truebrain> merni: no, it runs some special things, which are better done on Linux, I think
12:16:36 <truebrain> from a workflow perspective
12:16:43 <truebrain> (no graphical driver, mostly)
12:16:47 <merni> Anyway that is not a particular slow one either
12:17:02 <merni> Other linux builds are slower
12:19:17 <Rubidium> truebrain: just one check question about "all the crypto stuff in one PR", would that include all the network_crypto things for authorized keys? Or shall we leave that as a separate PR for "later"?
12:19:32 <truebrain> What works best for you, honestly
12:19:39 <truebrain> I am fine with them merged in a single PR, or added later
12:19:46 <truebrain> it doesn't really matter, I think
12:20:40 <Rubidium> I'll think about it, and make the branch/PR later as I got to go now
12:23:04 <peter1138> Lots of scroll back to catch up on.
12:24:33 <peter1138> salut3585: Sprites are never loaded from the a server
12:24:35 <michi_cc> kuhnovic: You available to press some buttons later today? ๐
12:24:38 <truebrain> Discord + Steam done
12:24:52 *** tramrider has quit IRC (Quit: Page closed)
12:25:52 <michi_cc> Link on reddit as well.
12:27:37 <michi_cc> truebrain: Is the survey savegame size something for the changelog?
12:28:02 <truebrain> not really, honestly
12:32:03 <truebrain> they are queued? ๐
12:32:05 <merni> I was just impatient ๐
12:32:17 <merni> truebrain: No, they did not even appear in the list before
12:32:23 <truebrain> takes a bit of time ๐
12:38:13 *** gelignite has joined #openttd
12:41:21 <truebrain> see, you understand GitHub workflows just fine ๐
12:41:48 <merni> I didn't expect it was just a bunch of yaml files
12:41:55 <truebrain> if you like, you can name "extra-cmake-parameters" just "cmake-parameters", and make `-DCMAKE_BUILD_TYPE=Debug` explicit on the debug variant ๐
12:42:20 <merni> I just shifted what was there earlier in Clang to MacOS
12:42:30 <truebrain> I know; was already a bit odd ๐
12:47:33 *** siciuvatiresubumbras has joined #openttd
12:47:33 <siciuvatiresubumbras> made it way less ambitious ๐
12:47:38 <peter1138> Vector is the correct approach there, not smart pointers.
12:48:11 <siciuvatiresubumbras> If I'm reading correctly, it's using a manual allocation there to avoid initializing an `std::set` in all cases, right?
12:48:13 <peter1138> I looked at it previously but didn't make changes yet
12:48:42 <siciuvatiresubumbras> since `CargoDataSet` is an `std::set<CargoDataEntry *, CargoSorter> ` typedef
12:49:14 <peter1138> It's mainly just left overs of old C code from before we embraced std containers
12:52:42 <kuhnovic> michi_cc: "A wild Kuhnovic appears"
12:52:56 <kuhnovic> I don't have a whole lot of time today, but let's see how far we get ๐
12:55:01 <michi_cc> I haven't actually read through #12308, but long -> int isn't really a rename. Might of course be the all usages are totally safe anyway (not read yet, like I said ๐ )
12:55:42 <truebrain> michi_cc: which is the issue with `long` .. "it depends" ๐
12:55:54 <truebrain> but that is also why I was annoyed I didn't put it in its own commit
12:56:33 <truebrain> ugh, seems I can't do `long` anyway, as too many headers have macros that introduce them
12:57:13 <michi_cc> kuhnovic: Well, you could start by get to proper date on the website PR. Otherwise, the changelog PR needs an approval, and after that it's literally just pressing a couple buttons, waiting on CI, and then doing a website merge and a few announcements.
12:57:24 <andythenorth> hmm, my GS needs a lot more debug info in it
12:57:32 <andythenorth> the log stream is just too noisy
12:58:01 <michi_cc> truebrain: Is it expected that the preview label isn't doing anything on a release branch PR? Gues I really have to compile myself to check ๐
12:58:11 <truebrain> no, that should just work
12:59:00 <truebrain> ah, no, seems we made a boo-boo when rewriting that
12:59:03 <michi_cc> #12307 seems to disagree
12:59:05 <truebrain> these days it only works on master
13:04:31 <merni> The changed ones are not marked as "Required" and these are still around
13:04:40 <merni> So I did something wrong? ๐ค
13:05:50 <truebrain> merni: I will fix that when the PR is done, no worries ๐
13:05:56 <truebrain> that is a repo-thingy
13:06:30 <merni> do you have any other comments atm?
13:06:41 <truebrain> I added those I have
13:08:59 <merni> About the "not required" part... doesn't that also apply to Linux?
13:10:03 <merni> Also, I am curious... in which context is "extra" correct or wrong?
13:10:40 <merni> On Mac there are a few default cmake parameters in `ci-macos.yml` plus (now) the ones specified by the parameter. That sounds like "extra" to me
13:10:46 <truebrain> when making these kind of changes, try to limit what you change
13:10:55 <truebrain> that always helps ๐
13:11:26 <merni> Sure, hence I didn't change it at all initially :P
13:11:44 <truebrain> yes, and I never asked you to change it now ๐ I was asking about the newly added parameter ๐
13:11:59 <merni> Sure, but why is that not "extra"
13:12:09 <truebrain> has always been a bit silly
13:12:15 <truebrain> they are not extra .. they are cmake parameters
13:12:37 <merni> Well, they are parameters extra apart from the ones already defined by default...
13:13:31 <truebrain> it was a suggestion; do with it what you like ๐
13:14:20 <kuhnovic> michi_cc: Website post has the right date now. Can someone look at the changelog PR? (#12248)
13:14:38 <merni> Yeah, I'm thinking the simplest thing is to have the parameters for different OS parallel to each other
13:15:20 <merni> Perhaps if the extra needs to be removed it can be done separately
13:15:33 <merni> The default change makes sense though
13:19:50 <truebrain> there, did one thing, and one thing only
13:20:24 <truebrain> system was never designed for 2 posts in 1 day ๐
13:20:32 <truebrain> I have zero idea what order it uses
13:20:40 <truebrain> I would guess, sorted DESC by name
13:21:09 <merni> Just call it "ZOpenTTD 14.0-RC2" :P
13:21:21 <truebrain> anyway, not sure it actually matters which is on top ๐
13:22:12 <kuhnovic> So shall we move it to tomorrow then?
13:26:43 <michi_cc> Hmm, SO seems to suggest you can actually just add a time to the date field as well.
13:26:57 <truebrain> michi_cc: but again, what are we solving? ๐
13:27:05 <truebrain> if we make RC2 today, both posts are important today ๐
13:27:39 <truebrain> and in a week, nobody actually cares about the order ๐
13:28:14 <truebrain> only the devs in this channel ๐
13:28:15 <merni> And being correct in a week doesn't help
13:28:31 <truebrain> I mean, a normal user visiting the website, won't care which order those posts are, that are made on the same day ๐
13:28:43 <truebrain> they don't know better, in which order they were "released"
13:28:53 <kuhnovic> There's not really a right or wrong order, no matter if it's today or in a week
13:29:17 <truebrain> just an itch we have because "we released things in that order" ๐
13:29:19 <truebrain> also called OCD ๐
13:29:28 <truebrain> (ghehe, sorry ๐ )
13:31:49 <michi_cc> Anyway, for the record: Adding `date: 2024-03-16 13:00:00` to the posting header will change the sorting. No date/time seems to read as midnight.
13:32:42 <xarick> I'd like to test my AIs with unlimited airports
13:32:52 <truebrain> the itch being itchy ๐ So update the news post ๐
13:34:09 <truebrain> _glx_: what do you think .. if we only make the annotation step mandatory, nobody can (auto)merge before the CIs are done too, right? Which means I can remove the "required" part of the CI, and only leave it on the annotation step?
13:34:38 <truebrain> (and annotation always fails when a CI fails, right?)
13:34:40 <_glx_> as long as annotation depends on all other
13:35:18 <_glx_> annotation fails if there are any annotation, being warnings or errors IIRC
13:35:33 <truebrain> yeah, also what I was thinking. Okay, let's try removing the CIs then
13:35:42 <truebrain> if it breaks, I will say "sorry!!" ๐
13:35:54 <_glx_> I can easily check in my fork though
13:36:06 <truebrain> If you wouldn't mind doing that, that would be lovely ๐
13:36:36 <michi_cc> Okay, basic sanity check on the release branch completed. I had a short moment when I started a new game and it was just water visible, because that is usually a sign of trouble, but it was just the luck of a really big lake in the map ๐คฃ
13:36:57 <truebrain> so you know you have a hearth, I am guessing?
13:37:03 <truebrain> KABOOM KABOOM KABOOM for a moment? ๐
13:37:41 <michi_cc> Not that bad, but you do think for second "oops, backport messed up somewhere??" ๐
13:39:44 <michi_cc> Cross check on the changelog anyone?
13:40:33 <truebrain> owh, I fucked that up badly ๐
13:41:03 <truebrain> owh, that doesn't even work
13:41:22 <truebrain> sorry for the noise
13:41:32 <kuhnovic> michi_cc: I'm going to make the release on github now
13:41:51 <michi_cc> There's no changelog yet
13:43:17 <_glx_> truebrain: the joy of workflows
13:43:39 <_glx_> but it's hard to test preview on fork
13:43:57 <andythenorth> I have to know write GS
13:43:57 <andythenorth> please wish me luck
13:44:00 <michi_cc> kuhnovic: I can approve the changelog PR, but someone should cross-read it.
13:44:28 <kuhnovic> I read through it again and it looked good to me, but I might not have the most well trained eye ๐
13:44:32 <_glx_> `restart` is your friend andythenorth
13:45:53 <truebrain> merni: depends on the final time
13:46:55 <andythenorth> _glx_: maybe ๐ although the GS requires quite a lot of progress (routes, cargo delivery). Reloading the savegame seems to work
13:46:58 <michi_cc> kuhnovic: On the GitHub release, make sure to select the correct target (release/14), let it create a new tag with `14.0-RC2`, but in a title and the changelog text as the description. And don't forget to say pre-release.
13:47:33 <_glx_> `reload` or `restart` depending on what you used to start the game
13:47:37 <michi_cc> kuhnovic: No, the website post would be live the moment you merge it, so always do the tagging first and wait till there's actually a download before doing any announcements.
13:47:47 <andythenorth> my text editor doesn't know about squirrel, so I have to pretend it's php for syntax colours ๐
13:47:54 <michi_cc> Website PR will get approved ๐
13:48:05 <kuhnovic> Just need approval, not going to merge it ๐
13:48:13 <kuhnovic> As per the instructions
13:48:15 <michi_cc> And I always like to cross check the links anyway ๐
13:49:01 <kuhnovic> And "set as pre-release" is checked
13:49:01 <andythenorth> ok so I think I need to learn about wallclock and GS
13:49:12 <andythenorth> `GSDate.GetCurrentDate` no longer works as expected
13:49:26 <andythenorth> although it may be a logic problem, not a bug
13:49:34 <michi_cc> kuhnovic: Looks fine.
13:49:42 <_glx_> economy or calendar, default is economy
13:50:44 <truebrain> pff, testing #12310 was painful, but I now know it works as expected ๐ After it is backported .. so the next backport still won't have a working "preview", only the backport after will ๐
13:50:51 <michi_cc> Hmm, does the developer role include the announcement channel or is this an extra role?
13:50:53 <kuhnovic> What about the binaries, will they be created automatically?
13:51:15 <michi_cc> Just tag, and TB's magic will (hopefully) do everything else ๐
13:51:31 <truebrain> michi_cc: extra. Town Crier, I think
13:52:40 <truebrain> _glx_: yeah, you will need to make a PR out of it, to see what the CI does
13:52:44 <truebrain> but I am pretty sure it won't allow merging
13:52:59 <truebrain> it is about "can I merge or not" more than anything else ๐
13:53:36 <kuhnovic> Already had it open ๐
13:53:48 <michi_cc> And hope that vcpkg has just merged some new and exciting bug ๐คฃ
13:53:55 <truebrain> glad 12308 tells me `LIT_NONE` is unused. Such a useful piece of information ๐
13:54:27 <kuhnovic> Just wondering, why do we always use the latest and greatest vcpkg, instead of "a revision that we know works" and then just update every now and then?
13:55:05 <michi_cc> If we get that workflow through successfull, there's another workflow for the website update that should only take a few minutes to run.
13:55:15 <truebrain> kuhnovic: are you volunteering to do that "once in a while" job? ๐ It is a shitty job that is always forgotten. And although vcpkg sometimes makes our life more difficult, in 95% of the time it "just works".
13:55:36 <michi_cc> After than, I like to cross-check the announcement links and then we're set to tell world ๐
13:55:42 <truebrain> as an added bonus, free up-to-date dependencies \o/ ๐
13:55:43 <kuhnovic> I certainly am not ๐
13:56:10 <michi_cc> You should just have gotten permissions for Discord channel #announcements , so you are all set ๐
13:56:13 <kuhnovic> I guess small increments with the occasional pain is better than having to do large jumps where everything is broken
13:56:53 <kuhnovic> Alright, I'll write an announcement and will post it once the release is available
13:57:03 <kuhnovic> and the website PR is checked and merged
13:57:24 <michi_cc> You already wrote something in the website PR ๐
13:57:26 <truebrain> btw, if dependabot would support vcpkg, we could use that. But they do not currently
13:58:16 <merni> Warning: Failed to check available disk space: Error: Command failed: df -Pk -- /Users/runner/work/OpenTTD/OpenTTD
13:58:16 <merni> dyld[5817]: terminating because inserted dylib '/Users/runner/hostedtoolcache/CodeQL/2.16.4/arm64/codeql/tools/osx64/libtrace.dylib' could not be loaded: tried: '/Users/runner/hostedtoolcache/CodeQL/2.16.4/arm64/codeql/tools/osx64/libtrace.dylib' (fat file, but missing compatible architecture (have 'x86_64,arm64', need '')),
13:58:16 <merni> '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/hostedtoolcache/CodeQL/2.16.4/arm64/codeql/tools/osx64/libtrace.dylib' (no such file), '/Users/runner/hostedtoolcache/CodeQL/2.16.4/arm64/codeql/tools/osx64/libtrace.dylib' (fat file, but missing compatible architecture (have 'x86_64,arm64', need ''))```
13:58:32 <_glx_> and switching to manifest mode helped to get vcpkg updates too, in standard mode it never updated installed packages
13:59:41 <truebrain> merni: ah, yes, I remember. I did try MacOS on CodeQL. I failed ๐
13:59:59 <merni> They claim they have fixed it
14:00:24 <truebrain> maybe a slightly different bug ๐
14:00:35 <truebrain> I believe those lines showed, but it continued
14:00:43 <truebrain> owh, right, but compiling was SO INCREDIBLY slow
14:00:50 <truebrain> I tried this, what, 2 weeks ago? And I already forgot
14:00:55 <truebrain> I was horrified by how slow compiling was ๐
14:01:08 <kuhnovic> michi_cc: Do we just post that same one on discord?
14:01:14 <_glx_> I though you tried more recently than 2 weeks
14:01:30 <truebrain> _glx_: it might have been yesterday for all I know. It seems my memory is getting old ๐ฆ
14:01:38 <truebrain> I loaded the "network stack" module today; purged all other activities
14:01:48 <truebrain> merni: you are asking us, or are you looking into it? ๐
14:02:04 <merni> If you have any idea that would be nice
14:02:44 <truebrain> all I saw was that files compiled a lot slower than on Linux, so I was like: fuck this, not today, and switched to other improvements ๐
14:02:50 <kuhnovic> "Reddit / Discord // tt-forums" yeah it says so. Need more coffee...
14:02:53 <_glx_> codeql is not expecting to run on anything other than linux
14:03:10 <michi_cc> kuhnovic: It says "Reddit / Discord // tt-forums", so usually yes ๐ Not necessarily the website text, but the proposed social text (that's what it is for after all).
14:03:10 <michi_cc> You can always add some witty introduction line, like "Hey nottaggingeveryone, two announcements in one day, what this?".
14:03:20 <merni> _glx_: Right, but the compiling is done with the same command as for normal CI...
14:03:30 <merni> If the codeql analysis part was slow I could understand that
14:03:35 <truebrain> CodeQL installs traps
14:03:40 <truebrain> to track what is actually being compiled
14:04:10 *** Flygon_ has joined #openttd
14:04:12 <_glx_> you properly touched configure step and everything in your test merni ?
14:04:13 <truebrain> so you think you make a normal compile; you actually don't ๐
14:04:38 <merni> _glx_: I have no idea what is proper
14:04:48 <merni> I only learned about CI stuff today :)
14:05:32 <kuhnovic> Yeah that's fun. I also wanted to put I tiny announcement for myself if that's ok. Something like: you might be thinking "Who is Kuhnovic? Never seen that name before"... well I'm the newest the member of the OpenTTD development team, and I have the honor of bringing OpenTTD 14-RC2 to you ๐
14:06:26 <truebrain> kuhnovic: just make sure to spell 14.0-RC2 correctly ๐
14:06:28 <_glx_> yeas the changes look fine
14:06:55 <merni> but like TB said the compiling is incredibly slow
14:06:59 <truebrain> for some reason I never merged #12274 .. oops
14:07:35 <michi_cc> kuhnovic: What TB said, but otherwise, feel free ๐
14:09:14 <truebrain> _glx_: okay, annotation failed correctly; nice
14:09:46 <_glx_> yup, it only runs for PR
14:10:28 <michi_cc> Oh, and you are the newest part of the plague ruining the game, of course /s ๐คฃ
14:10:36 <_glx_> so our life will be easier if we only require annotations
14:11:11 *** Flygon has quit IRC (Ping timeout: 480 seconds)
14:11:36 <truebrain> means I can merge that, without any other PRs failing
14:12:32 <_glx_> and it removes forced update of PR from before macos-14
14:13:11 <michi_cc> So RC3 next week then? ๐
14:13:39 <truebrain> seems it could have been in RC2 ๐
14:19:34 <truebrain> with the exception of #12305, seems no other open crashes / PRs I expect to be fixed before 14.0 ๐ Which is nice ๐
14:20:27 <truebrain> well, the new MacOS jobs seem to help in time-for-release
14:20:57 <_glx_> we tend to quickly fix crashes ๐
14:21:13 <truebrain> from 18m on MacOS to 13m on MacOS, no longer making it the slowest ๐
14:21:35 <_glx_> and it's 2 builds in serie
14:21:51 <_glx_> while all other targets are parallel
14:22:05 <truebrain> not sure how that matters; it is no longer the slowest ๐
14:22:35 <_glx_> it means it could be the fastest if we had a way to parallelise it
14:22:49 <truebrain> I don't care about the fastest! I care about the slowest ๐
14:23:49 <truebrain> kuhnovic: so website next ๐
14:24:03 <michi_cc> kuhnovic: Website links checked, you are go for launch ๐
14:24:35 <truebrain> why does the Steam image not have the OpenTTD logo?
14:24:42 <truebrain> where did that go? ๐
14:25:18 <truebrain> not even in the xcf! ๐ฎ
14:25:46 <kuhnovic> Although I didn't occur to me for a second that that was missing...
14:26:01 <_glx_> isn't `โ<unnamed>.MidiFile::DataBlock::realtimeโ may be used uninitialized [-Wmaybe-uninitialized]` supposed to be fixed ?
14:26:13 <truebrain> _glx_: in master, yes
14:26:25 <truebrain> kuhnovic: when looking over all releases, that is more noticeable ๐
14:26:40 <_glx_> and the apple action still not being updated is annoying
14:29:02 <kuhnovic> Is there anyone who can change the logo?
14:29:04 <truebrain> 14.0-RC2 published on Steam
14:29:15 <kuhnovic> Oh well, now it's without a logo I guess ๐
14:29:41 <truebrain> kuhnovic: pff, you of little faith
14:29:59 <michi_cc> kuhnovic: Apparently we never added any image to the Discord release announcments, so you call there. Otherwise, Reddit and Xitter done.
14:30:13 <truebrain> I like that we started to do images on Discord ๐
14:30:31 <truebrain> although 2 messages on a single day was a terrible idea ๐
14:30:40 <kuhnovic> So, image or no image? I'm confused ๐
14:30:44 <truebrain> no no, wording differently: RC2 after my blog post is!
14:31:19 <truebrain> kuhnovic: "so your call there", how does this confuse you?
14:31:22 <truebrain> can't handle choices? ๐
14:31:35 <kuhnovic> michi_cc: I was more referring to this one ๐
14:31:51 <truebrain> you need glasses now too? ๐ ๐
14:32:07 <kuhnovic> Got those, still need coffee ๐
14:32:56 <michi_cc> Okay, edited the typo our ๐ (you/your)
14:32:57 <truebrain> (sorry, I am pissing my pants over here ๐ )
14:33:24 <truebrain> michi_cc: typo in a typo, nice ๐
14:33:43 <xarick> oh you approved something with conflicts
14:34:05 <_glx_> oh no, we are annoying people with a huge amount of `all`
14:34:08 <kuhnovic> ... aaand I hit enter instead of ctrl-enter and now it doesn't have an image, goddamnit
14:34:18 <truebrain> kuhnovic: worst part ... there is no way to fix that!
14:34:23 <truebrain> oneof the weird things of Discord ...
14:34:28 <kuhnovic> Yeah that's so weird!
14:34:32 <_glx_> can't edit announcements ?
14:34:40 <kuhnovic> You can, but you can't add an image
14:34:41 <michi_cc> kuhnovic: Now you can fully call yourself part of the team โฅ๏ธ
14:34:41 <truebrain> you can't add images with editing
14:35:29 <kuhnovic> Let's forget about it then, 3 announcements per day is a bit spammy ๐
14:35:40 <truebrain> yeah, don't spam just for an image ๐
14:35:48 <kuhnovic> ... like you did last time ๐
14:35:57 <truebrain> I didn't ping everyone for that image ๐
14:36:04 <truebrain> and I really disliked how it looked afterwards ๐
14:36:32 <kuhnovic> I hope Discord changes their policy on this some day, it's weird
14:36:51 <truebrain> still amazes me, how far we got in 20 years ... from a release taking days, poking various of people, collecting binaries .. to just have someone new pressing some buttons ๐ Automation is awesome ๐
14:36:53 <merni> I think it is less "policy", more "we didn't think of it"
14:37:38 <kuhnovic> I sure am happy with all that automation yes
14:37:53 <michi_cc> Or even, "for some obscure reason, that is twenty times more complicated than you think".
14:38:24 <kuhnovic> "That would require a large refactor of <library name>"
14:39:13 <_glx_> truebrain: and the local pdb storage in my dev webzone
14:39:48 <truebrain> or manually uploading binaries to the host, downloading them again and validating the checksum to make sure your upload didn't go corrupt
14:44:43 <kuhnovic> truebrain: I hear some trauma's ๐
14:44:59 <kuhnovic> xarick: Yup, too many people eagerly trying to improve the ship PF ๐
14:45:29 <xarick> that random trackdir function is hot
14:47:53 <kuhnovic> I wonder who worked on that ๐
14:52:00 <xarick> 12232 touches it again
14:56:16 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #12232: Fix #12228, #12231: Don't restrict path when checking ship reverse on first attempt, Pick a random trackdir if no path is found when force reversing https://github.com/OpenTTD/OpenTTD/pull/12232
15:02:22 <xarick> hmm 10544, not sure what to do with it yet
15:03:10 <xarick> depends on the direction 12206 goes
15:03:25 <xarick> multi dest tiles becoming a thing
15:06:50 <truebrain> so, we did enough for one day right? Now 2 weeks holiday for everyone? ๐
15:07:15 <michi_cc> Not for 2TT, there's a blog for next weekend ๐
15:08:39 <truebrain> the only person that needs to work in the next 2 weeks ๐
15:13:37 <truebrain> I still have no clue how to move performance measurements to GitHub Workflows ... meh
15:13:56 <truebrain> I could host a runner on my own hardware, just to make sure we have the same CPU every performance run
15:14:01 <truebrain> but that seems like a lot of trouble ๐
15:14:40 <truebrain> otherwise, maybe I can bribe michi_cc to look into kperf for MacOS .. but from what I have seen, it requires patching OpenTTD source to be useful
15:14:57 <_glx_> use andy's MBP as runner
15:15:11 <truebrain> that would reduce the bandwidth for BaNaNaS ๐
15:15:33 <michi_cc> I think I'm out for now. Haven't gotten anything over macOS 11 ro reliably run in a VM, and that is now too old for the Xcode we need.
15:15:54 <truebrain> I can't even get MacOS to run in a VM .. stupid AMD CPU ๐
15:15:59 <michi_cc> Probably doesn't help that I have AMD and not Intel with the VM.
15:16:08 <_glx_> oh yeah, even andy's MBP can't build recent openttd
15:16:32 <michi_cc> 11 and vmware does work if you add in a manuak cpuid override, but I've not been able to properly run anything newer.
15:17:21 <_glx_> and now they are mostly targetting arm it will be worse
15:17:41 <truebrain> kperf documentation is also ... non-existing ๐
15:18:04 <truebrain> I guess I could check in the GitHub workflow whether ubuntu-latest is starting on the CPU we expect, and abort otherwise
15:18:06 *** Wormnest has joined #openttd
15:18:13 <truebrain> just restart till it starts on a host we know
15:18:17 <truebrain> so we can compare performance ๐
15:18:37 <truebrain> or, alternatively, I can always run 2 performance benchmarks .. on N-1 and on N, so you can see the difference
15:18:43 <truebrain> means we can't compare N-10 with N easily
15:18:55 <truebrain> but at least it does allow comparing N-1 with N
15:19:06 <truebrain> (and via correlation, we can say something about N-10 vs N, I guess
15:19:10 <michi_cc> I got 11 running with this
15:19:32 <michi_cc> Basically pretending to be an Intel CPU ๐
15:19:42 <truebrain> yeah .. I tried that with MacOS 13
15:19:54 <michi_cc> Yep, 11 is the max I can get to work.
15:20:20 <truebrain> okay, so I guess the next question is: can I run "perf stat" on a GitHub runner ..
15:21:09 <truebrain> that way, I could build N, fetch the binary for N-1 from the archive, run both with "perf stat", and compare the results .. hmm
15:25:02 <_jgr_> xarick: Said project is pretty obviously not active any more
15:25:24 <xarick> why ppl quit openttd? ๐ฆ
15:26:09 <_jgr_> Why should people keep updating AIs forever?
15:26:30 <xarick> I had hopes he would fix some of the issues
15:27:29 <truebrain> should be fixed in 14 ๐
15:31:01 <merni> xarick: You can always fork
15:31:37 *** Smedles has joined #openttd
15:32:11 <truebrain> `<not supported>;;instructions;0.00%;0;100.00;;`
15:37:11 <xarick> what are the chances of implementing a SlowValuate?
15:38:01 <_jgr_> You can just use an ordinary for loop in Squirrel
15:38:21 <_glx_> anything in C++ is non interruptable
15:39:10 <xarick> can't force it to interrupt?
15:39:43 <_glx_> if it was possible it would be done already
15:41:04 <xarick> some AIs however use Valuate in the main initializers, slow valuate takes too long to initialize on them
15:41:29 <xarick> it's not bullet proof ๐ฆ
15:42:20 <xarick> "script took too long to start"
15:42:34 <truebrain> lol @ steps to reproduce .. those are not steps to reproduce ๐
15:43:29 <_glx_> using valuate in AI constructor feels so wrong ๐
15:43:54 <_jgr_> xarick: Many scripts are implemented very badly, that's not in itself a reason to change for valuate works
15:44:36 <_jgr_> To some extent lists and valuate encourages code patterns which perform badly
15:45:16 <_glx_> but we don't force people to use them
15:45:51 <_glx_> except when getting data from the API of course
15:46:27 <_glx_> some authors tends to use lists even for stuff not from the API
15:50:31 <LordAro> google translate said "towns" for me
15:50:40 <truebrain> blame it on the translator ๐
15:50:50 <truebrain> I cannot reproduce that issue ..
15:50:58 <truebrain> if I disable that setting
15:51:01 <truebrain> towns do not build roads
15:51:02 <xarick> even with slow valuate, some AIs have other hidden problems
15:51:38 <_jgr_> xarick: It's fine to simply not use AIs which aren't very good...
15:52:09 <xarick> NotPerfectAI is giving a hard time to triple A Hog
15:55:37 <xarick> is he using a game script?
15:56:13 <xarick> ask him for a savegame
15:57:14 <xarick> can newgrfs actually "build" roads?
15:59:28 <xarick> what the heck is this...
16:04:20 <truebrain> Shouldn't that go in a PR? ๐
16:09:34 <xarick> I don't understand what's the point of this gender switching as a test mode
16:10:20 <_jgr_> xarick: Again, it's fine to write off some AIs as not worth bothering with
16:10:54 <xarick> feels like it's a TODO that didn't get done
16:12:10 <xarick> i think the intention was to remove the already built track since it collided with somebody's else track, but this code is here instead, doing nonsense
16:15:27 <truebrain> I meant the settings value in the ini file
16:15:38 <truebrain> But that looks good too ๐
16:16:30 <_glx_> the GUI as already fine
16:16:56 <truebrain> Guess setting should even be an enum
16:17:16 <truebrain> But okay, small stuff to improve everywhere ๐
16:19:07 <_glx_> didn't check all existing CodeQL reports, but it's weird if it didn't report this before
16:20:10 <truebrain> It most likely did. We have many open reports ๐
16:21:51 *** gelignite has quit IRC (Quit: Stay safe!)
16:22:54 <truebrain> History is weird. Did it really get added 4 days ago? Seems unlikely
16:24:01 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #12232: Fix #12228, #12231: Don't restrict path when checking ship reverse on first attempt, Pick a random trackdir if no path is found when force reversing https://github.com/OpenTTD/OpenTTD/pull/12232
16:24:05 <_glx_> yeah #12163 doesn't even touch it
16:25:15 <truebrain> CodeQL isn't the best in finding the original introduction of issues
16:29:13 <merni> TrueBrainviaGitHub: maybe they mean they don't want roads at world generation time, either?
16:29:17 <xarick> i get 404 on those links
16:29:35 <merni> yes, those are not accessible to mere mortals :)
16:31:21 <_glx_> so your byte->uint8_t make it reappear
16:32:26 <truebrain> merni: But then towns don't exist ๐ but sure, possible. Feel free to ask them ๐
16:42:59 <truebrain> Tnx, nice reply ๐
16:55:23 <peter1138> They're replying by email instead of on the web interface. Attachments get ignored.
16:55:43 <merni> Oh I didn't know github dropped email attachments
17:00:17 <_zephyris> peter1138: Oh wow, loads of feedback!
17:01:27 <truebrain> Really a lot .. scary, that platform .. people actually participating in a constructive conversation ๐
17:01:39 <peter1138> Yeah... quite a bit of "looks good" and some of it is quite detailed "this could be improved"
17:02:06 <truebrain> Wow @ those screenshot... artsy
17:02:07 <peter1138> And just one that focuses on the translations rather than typeface ๐
17:02:16 <merni> Those are some interesting shapes
17:03:25 <peter1138> Oh there's a few that question the BiDi too. Not sure if that's the translation that's wrong or the mixing.
17:03:37 <merni> tibenasriviaGitHub: I don't get what the problem is here
17:04:31 <merni> esp as the second pair of screenshots seem to be unrelated to tje first
17:07:21 <peter1138> This the "expand town" button in the scenario editor.
17:07:34 <peter1138> That does ignore the towns can't build road setting.
17:07:43 <peter1138> I think it used to not be ignored.
17:08:51 <peter1138> That happens in 13.4
17:09:36 <peter1138> In master, the town grows with roads.
17:12:53 <merni> Somewhere I actually agree with Zorg ๐
17:13:54 <xarick> maybe the documentation was outdated
17:14:47 <merni> I personally find it fine that in scenario editor, if that setting is on -> towns expand with roads, if it is off -> they expand without building roads (if possible)
17:15:01 <merni> no reason why the setting should be overridden in editor imo
17:16:00 <merni> talltyler: what do you think?
17:23:09 <peter1138> So the web translator shows that.
17:23:28 <merni> lol {BLACK} is at the end
17:23:50 <peter1138> It's mixed LTR/RTL, it gets very confusing.
17:26:04 <frosch123> i blame the translation
17:26:06 <peter1138> In game it appears like this.
17:26:19 <frosch123> (NewGRF) is at the front (in logical order)
17:26:21 <peter1138> Same as the web translator.
17:26:54 <merni> but what shows in the edit box of the web translator? could that be different from the display?
17:27:07 <merni> and perhaps varies by browser?
17:27:22 <frosch123> yes, editbox and overview list may show different thing
17:27:46 <frosch123> there is a global textorder, which is set language-specific on the edit-string page, when strings are shown on their own
17:27:56 <michi_cc> Mixed writing directions are a sure-fire way to twist your brain ๐
17:27:59 <frosch123> but in the description list on the overview page, that is weird
17:28:03 <peter1138> I don't think I can see the edit-box version of it.
17:28:16 <merni> Clicking on the string doesn't show it?
17:28:29 <frosch123> either way, you can check the logical order in your editor by moving the cursor
17:28:46 <peter1138> Yeah, Access Denied on the web translator.
17:29:12 <peter1138> Yes, logical order is (NewGRF) first followed by the hebrew (which starts at the end)
17:30:42 <merni> So openttd has bidi issues, fun...
17:30:50 <frosch123> no, the translator has
17:30:58 <frosch123> the ottd display is correct
17:31:08 <frosch123> main language direction is RTL, so it starts printing from the right
17:31:22 <frosch123> first logical word is "(NewGRF)", which is put to the right
17:31:36 <frosch123> afterwards follows the rest in logical order from right to left
17:32:10 <frosch123> i do not know hebrew semantics but in english "(NewGRF) Graphics settings" would look weird
17:33:15 <frosch123> but who knows, "(NewGRF-)graphics settings" could be considered correct again
17:34:58 <peter1138> In English, "(NewGRF) Graphics settings" seems perfectly reasonable to me.
17:36:15 <frosch123> i edited the lang file to put (NewGRF) at the end in logical order:
17:36:22 <frosch123> so, ottd works just fine
17:36:46 <frosch123> just the translators disagree on whether they want to put (NewGRF) to the front or back of logical order
17:36:59 <peter1138> CodeQL lies to me :/
17:37:08 <peter1138> `The result of this call to GetFirstSharedVehicle is not checked for null, but 85% of calls to GetFirstSharedVehicle check for null.`
17:37:26 <peter1138> I checked. No caller of GetFirstSharedVehicle checks for null.
17:38:30 <frosch123> peter1138: well, the ``for`` loop checks ``nullptr`` as sentinel
17:40:30 <frosch123> i guess the message is inverted
17:40:43 <frosch123> there are 7 usages of it, and 1 of 7 checks (15%)
17:41:26 <peter1138> If it includes Vehicle::FirstShared(), then there's a lot which are in loops, so potentially that.
17:46:02 <merni> So do I need to use the same order as in English?
17:46:09 <merni> That will mean some contorted grammar...
17:48:26 <peter1138> With STRING you can change order by providing an index, is that not possible for COMPANY, VEHICLE etc?
17:48:56 <merni> so {0:COMPANY} and {1:VEHICLE}?
17:49:17 <frosch123> the other way around ๐
17:49:23 <frosch123> eints will tell you, if you do it wrong
17:50:03 <merni> now, how the heck do I translate "production callback"
17:50:42 <merni> previous translator has literally translated it as "return calling" or so
17:52:32 <xarick> peter1138: try assert(v != nullptr);
17:52:40 <_zephyris> Finally had a chance to look at the Hebrew feedback properly, genuinely very useful!
17:55:09 <xarick> first_shared(nullptr) it is initialized as nullptr actually
18:04:40 <peter1138> (Currently) an OrderList cannot exist without at least one Vehicle.
18:07:39 <peter1138> If it could (and that's the start of a fairly awesome feature) then... yeah.
18:11:24 *** gelignite has joined #openttd
18:34:11 <merni> Hm, "social integration" -> is that OK to translate as "social media integration"?
18:34:36 <merni> but just saying "social integration" sounds more like "connecting with the society" which is not what it's doing
18:48:55 *** nanapipirara has joined #openttd
18:48:55 <nanapipirara> Here's a thought: Wouldn't it look much better that when you buy a big plot of land. instead of putting the land ownership sign on every single tile. why not surround the plot with fences like the railroads, and put a single sign in the middle of the plot?
18:49:20 <nanapipirara> I rarely buy land because it looks very ugly when there's a pattern of signs on the land
18:55:33 <_zephyris> nanapipirara: :this: Though, surrounding fence is easy, just one sign in the centre is hard. The former just needs to know about neighbouring tiles, the latter needs connectivity.
18:56:00 <nanapipirara> even without the sign in the center, i would prefer fences around plots!
18:56:39 <_zephyris> Purchased land as a (special) object
18:56:56 <_zephyris> Or should that be special object for purchased land
18:57:03 <_zephyris> Objects for fields.
18:58:04 <nanapipirara> if you buy land next to your own train tracks, it already removes the fence next to the tracks
18:58:16 <nanapipirara> doesn't add new fences anywhere though
18:59:06 <_zephyris> That's general behaviour, no fences next to property of the same company IIRC
19:00:21 <nanapipirara> that's good, but it would be great if bought land next to 'not owned land' would generate a fence
19:00:49 <nanapipirara> i have no idea how the insides of ottd works though. just an idea
19:01:14 <nanapipirara> trying to design the sign, and whatever i do, it's ugly
19:02:13 *** Leopold_ has quit IRC (Ping timeout: 480 seconds)
19:02:16 <locosage> nanapipirara: it's not impossible to do and will surely look better but I kinda feel that are so many more important things in openttd to improve
19:02:29 <locosage> land owning isn't used that often and even less so for a good reason
19:02:45 <truebrain> when did that ever stop us doing silly shit? ๐
19:02:51 <nanapipirara> understandable ๐
19:03:00 <truebrain> it is just finding someone that is crazy enough to implement it ๐
19:03:18 <nanapipirara> A few times I tried to buy land within a big cloverfield rail junction. simply to remove all the fences on the inside of the clover
19:03:25 <nanapipirara> but got ugly signs in return ๐
19:04:29 <_zephyris> It's probably quite easy to code, just annoying that you'd need extra sprites (cc recolour fences with the correct offset).
19:04:56 <nanapipirara> the sprites could be the same fences that surround the rail tracks, i think
19:05:03 *** Leopold has joined #openttd
19:09:03 <peter1138> Hmm, how far do I go? :p
19:09:13 <merni> Welp, I made a typo in 12309
19:09:26 <truebrain> peter1138: Now that is the question, isn't it? ๐
19:09:29 <merni> `-DCMAKE_BUILD=Debug` instead of `-DCMAKE_BUILD_TYPE=Debug`
19:09:40 <truebrain> so make a PR to fix it!
19:09:43 <truebrain> stupid reviewers, they suck
19:09:55 <merni> to the first one, at least :p
19:11:03 <truebrain> there, giving you choices ๐
19:11:55 <peter1138> I have tried duffing it, and yes it is more readable, but it does obscure the actual change.
19:12:03 <truebrain> yeah, I realised that too
19:12:10 <truebrain> different commit? different PR? just not doing it?
19:12:33 <peter1138> I could do a separate PR of lots of different early-continue fixes...
19:12:59 <truebrain> they are so much more readable .. but error-prone too
19:13:53 <peter1138> `#define ifnot(x) if (!(x))` /bans self
19:14:43 <truebrain> peter1138: yes. Please wash your mouth now
19:32:51 <andythenorth> ok so dates don't work with wall clock like dates without wall clock
19:32:59 <andythenorth> this is unsurprising, but eh
19:34:06 <andythenorth> hmm, are there new docs?
19:37:12 <xarick> andythenorth: GSTimeMode
19:38:26 <xarick> 2TallTyler:tyler_ruins_time - sounds like an agenda
19:41:08 <andythenorth> hmm might have to read this twice ๐
19:41:44 <andythenorth> unclear which mode I need for date comparisons
19:42:14 <andythenorth> I'm in wall clock game, with calendar date 1933, and industry that was built in 1920
19:42:27 <andythenorth> but it's reporting construction date < 3 years ago
19:42:34 <andythenorth> I guess I print more stuff to log ๐
19:44:56 <_jgr_> Essentially there are two unrelated sets of dates
19:45:09 <andythenorth> so the industry was founded in the future
19:46:37 <_jgr_> You'll need to use the GSTimeMode thing to make GSDate return calendar dates, likely you can just do this at the start of the script and leave it active from there
19:49:35 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
19:58:38 <truebrain> `Remove: 32bpp-sse2 blitter`, right?
20:00:06 <_jgr_> That blitter isn't terribly useful, but it seems to work fine on Ubuntu here
20:01:04 <locosage> hm, weird, for me it only works in 13.4
20:01:54 <locosage> also, I've no idea if it's ever auto-selected, with animation it picks 32bpp-sse2-anim obviously but without it's just 32bpp-optimized
20:02:16 <frosch123> it also fails for me
20:02:33 <locosage> weirdly doesn't select sse4 even though it works fine
20:02:34 <andythenorth> _jgr_: let's try it ๐
20:02:50 <andythenorth> most of the existing GS are probably now broken ๐
20:02:57 <andythenorth> nvm, wall clock is a good thing
20:03:58 <xarick> what function was that
20:04:29 <xarick> don't think it has a calendar mode return
20:05:36 <_jgr_> locosage: No, none of the SSE-drawing blitters are auto-selected
20:06:37 <locosage> without hardware accel it uses 32bpp-sse2-anim
20:06:38 <_jgr_> The speed benefit is pretty marginal and the sprite encoding format gobbles more memory
20:06:56 <_jgr_> That only uses SSE for palette animation, not drawing
20:07:29 <andythenorth> I need to assign GSTimeMode to a var yes?
20:07:31 <peter1138> Which compilers are you using? clang-15 here.
20:07:49 <andythenorth> but `local timemode = GSTimeMode(true);` in main.nut doesn't seem to achieve the expected result
20:07:52 <locosage> g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
20:08:35 <frosch123> it works if i build as release
20:08:39 <frosch123> it's broken as debug build
20:10:36 <andythenorth> seems there was a backlog of increases due ๐
20:10:41 <peter1138> Hmm, so weird when Debian is more up to date than Ubuntu.
20:11:52 <locosage> frosch123: yep, same here
20:19:13 <peter1138> Broken for me with debug too.
20:19:28 <peter1138> Also, it's way more broken with zbase (presumablky 32bpp sprites)
20:19:50 <peter1138> Although not everything.
20:21:58 <_jgr_> Guessing a bit, but it wouldn't surprise me if this was related to the recent change to turn off -fno-strict-alisasing
20:23:21 <_glx_> xarick: because there's only one for it (and it's calendar time here)
20:23:40 <andythenorth> might be time to change port layouts, been avoiding it for 2 years ๐
20:23:47 <andythenorth> need more buildability
20:24:06 <frosch123> it's related to transparency
20:24:34 <frosch123> and it does some weird casting to bitstuff data
20:24:52 <peter1138> Encoding or blitting?
20:24:54 <_glx_> documentation could be improved to tell which calendar type is used by a given function
20:27:56 <peter1138> Hmm, that encoder is used by other blitters.
20:30:01 <frosch123> it's not ``-fno-strict-aliasing``. still broken
20:30:53 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
20:31:02 *** Wormnest has joined #openttd
20:40:02 <frosch123> oh, it's not related to encoding, but to clipping
20:41:02 <_glx_> oh I think I know why it's broken, probably related to ` : WidgetID`
20:42:07 <peter1138> Oh, script widget number generation. Hmm.
20:52:28 <xertov> guys kilo should be shortened as kg not as k right ?
20:52:49 <truebrain> a currency in kg sounds odd ๐
20:52:52 <peter1138> No, it's STR_CURRENCY...
20:52:57 <frosch123> it's the prefix for currency
20:54:45 <_glx_> kilogramme is kg, here it's just kilo so k
20:55:19 <_glx_> no it's for 10kโฌ for example
20:55:20 <peter1138> it's "kilo" as in 1000
20:55:33 <truebrain> the next one is mega, followed by giga ๐
20:55:41 <peter1138> TBH kilo is a bit of a weird name for it here, but it is what it is.
20:55:46 <xertov> guys what are u saying even
20:56:04 <frosch123> xertov: when you management shows you the business numbers
20:56:07 <_glx_> 10000โฌ is written 10kโฌ in some graphs
20:56:20 <peter1138> It's the translation for the "k" in ยฃ1,000k
20:56:25 <frosch123> how do they display money? as โฌ 123445678 or as โฌ 123M
20:56:38 <xertov> i ll just put k and hope my fellow greeks understand it
20:56:59 <peter1138> Before this translation it was hardcoded as 'k' with no way to change it.
20:59:25 <michi_cc> Well, some greek financial report would probably show the "correct" way.
21:03:20 <Eddi|zuHause> 1kg=1000g, 1kV=1000V, 1kโฌ=1000โฌ
21:04:23 <Eddi|zuHause> we should start measuring stuff in mโฌ and ยตโฌ Kappa
21:07:27 <peter1138> Hmm, I don't know how this regex works.
21:08:17 <peter1138> Trying to allow " : x " between ENUM_PATTERN and {
21:13:40 <_glx_> no won't work, no spaces allowed there
21:14:07 <peter1138> No, it does work. I was looking at the wrong autogenerated file ๐
21:14:14 <peter1138> if("${LINE}" MATCHES "^ *enum *${ENUM_PATTERN} (: .* )*\{")
21:14:48 <xertov> seperator for currency is the comma or dot in 1.000.000?
21:14:52 <_glx_> yeah I tested a simple `if("${LINE}" MATCHES "^ *enum *${ENUM_PATTERN} .*\{")`
21:14:53 <peter1138> Means any enum can include a type, it doesn't care.
21:15:19 <_glx_> (worked but not specific enough)
21:17:03 <_glx_> ideally I think it should be `if("${LINE}" MATCHES "^ *enum *${ENUM_PATTERN} *(:.*) *\{")`
21:23:42 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:34:19 *** wensimehrp has joined #openttd
21:34:19 <wensimehrp> andythenorth: The foundations doesn't seem quite right
21:34:27 <_glx_> now the question is do we want to keep the ": x" in the generated file or not ?
21:34:42 <andythenorth> wensimehrp: nml CHIPS conversion, the foundations are broken
21:34:56 <_glx_> as everything will be SQInteger in the end
21:38:51 <frosch123> broken by copy/paste refactoring ๐
21:39:02 <frosch123> or maybe bad regex search-replace
21:39:27 <xarick> hmm not the date I was expecting
21:39:54 <xarick> it already is calendar
21:39:58 <_glx_> don't try to change the type here, it will always be calendar
21:41:14 <xarick> seems I have no idea what to do
21:41:43 <frosch123> it claims to replace "static inline" with "static". but it actually replaces "static inline" with "inline"
21:41:57 <_glx_> mode is only used for ScriptDate, any other function returning Date are fixed to economy or calendar
21:42:48 <frosch123> ah, the commit message was wrong, the PR description is better ๐
21:43:20 <frosch123> do we have a file exension for inlined files like ".inl"?
21:43:36 <_glx_> do we have inlined files ?
21:43:56 <frosch123> yes, 32bpp_sse_func.hpp is compiled multiple times with different defines
21:44:45 <frosch123> #11695 turns some functions from that "header" into non-static, so they become ambiguous to the linker, which then mixes different sse blitters
21:45:27 <peter1138> Sounds like a job for... templates
21:46:17 <peter1138> Old-style C instead?
21:48:14 <xarick> I think a rename is in order
21:48:56 <frosch123> hmm, ok, you want me to replace the ``#ifdef`` with ``if constexpr`` ?
21:50:06 *** Wormnest has joined #openttd
21:50:41 <_zephyris> peter1138: Thanks for getting that feedback, subtle changes, but really helpful for designing the other fonts too.
21:54:36 <xarick> can't get my head around this... how am I supposed to get the economy date for the intro of something, like an engine, or industry
21:55:36 <frosch123> oh, templates won't work
21:55:51 <frosch123> it also ``#include``s different header files
21:56:07 <frosch123> so the template instantiations would also implicitly use different headers
21:57:10 <_glx_> xarick: you can't as it doesn't exist
21:57:57 <_glx_> some stuff is only economic, some is only calendar
21:59:32 <_glx_> documentation should be updated to specify the date type of each function
21:59:41 <peter1138> frosch123: Ah well, should be fine to reinstate the `static`s.
22:00:46 <xarick> an engine is released in 1975, but the game is in wallclock with 10080, returning 1975 is too vast, when I'm interested in the other type of date it happened to release
22:01:18 <xarick> can't make a conversion
22:02:08 <xarick> feels like there's something amiss
22:03:10 <_glx_> you can use AIDate.GetYear(engine release date) in the correct mode
22:03:49 <_glx_> but the doc doesn't tell which mode is the correct one for engine release date
22:04:46 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:07:52 <_glx_> economic and calendar are not supposed to be converted between each other
22:07:53 <frosch123> ah crap, one of the defines are even redefined to something different in the middle
22:08:17 <_glx_> because there's no relation between them
22:08:18 <truebrain> someone had fun writing that ๐
22:08:26 <frosch123> i'll just readd the ``static``, touching any of this may break anything
22:18:09 <Rubidium> maybe add a comment about them having to be static at the first one in each of those magic header files?
22:18:54 <_glx_> there's only one magic header file (I hope)
22:20:16 <_glx_> hmm maybe the static can be "hidden" in the GNU_TARGET macro
22:20:43 <xarick> 29 feb, 30 feb, 1 march all have the same GSDate.GetDate
22:20:59 <_jgr_> GNU_TARGET is not related to linker visibility
22:21:10 <_jgr_> Why does it need to be "hidden" at all?
22:22:01 <xarick> no conversion is possible ๐ฆ only an estimated conversion
22:22:14 <xarick> think im gonna drop my pr
22:22:25 <_glx_> yes you're not supposed to convert them at all
22:23:27 <_glx_> calendar pace is independant to economic pace
22:24:17 <xarick> i think economy date shouldn't start at 1/1/1
22:25:52 <xarick> unless before christ dates becomes a thing
22:25:56 <_glx_> maybe we could add an optional ScriptInfo field/function saying if the script supports wallclock mode
22:26:57 <_glx_> and not allow them to start in wallclock if they don't support
22:27:15 <frosch123> i hope the comment makes sense
22:28:04 <frosch123> c/c++ makes this extra difficult, because it is non-obvious that "static" means "internal linkage"
22:28:14 <frosch123> and can mean other things in other contexts
22:28:51 <_jgr_> _glx_: Likely that would mean that there are 0 enabled AIs or GSs in wall clock mode at release time (1st April)
22:29:12 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:29:22 <_glx_> probably better than broken AI/GS
22:30:26 <frosch123> are they likely to break?
22:31:11 <_glx_> they almost all break as soon as they use AIDate stuff
22:31:48 <xarick> i mixed AIDate with Vehicle.GetAge, it snoozes
22:31:57 <xarick> feels a very sleepy AI
22:32:02 <frosch123> goals usually involve some time span
22:32:33 <_glx_> but economy time and calendar time can't mix
22:32:58 <_glx_> and script needs to know about that
22:33:29 <xarick> I know, but that means I have to fix all the 300~ occurrences I used them
22:34:18 <_glx_> that's why I suggest script explicitely say they support wallclock mode
22:34:34 <xarick> was looking for a more "compat" way, but turns out it's not possible
22:35:11 <xarick> there are different expectations for what a date is used for
22:35:31 <xarick> i have to fix it case by case
22:35:57 <frosch123> looks like "economy time" is the default
22:36:02 <frosch123> i think that works for SV
22:36:22 <frosch123> why do AI/GS care about introduction of things?
22:36:57 <_glx_> it is the default, but a lot of script compare current date to introduction date for reasons
22:37:17 <xarick> know if an engine has been in circulation long enough to try it
22:37:20 <_glx_> so they compare economic with calendar and fail
22:37:34 <xarick> ie, "does it have good reliability by now?"
22:40:53 <frosch123> is ``ScriptEngine::GetDesignDate`` the problem?
22:41:35 <frosch123> the function only returns something, if the engine is available
22:42:12 <xarick> vehicle Age related functions, industry date stuff, that kind
22:42:22 <xarick> didn't fully investigate
22:43:34 <frosch123> none of the AI i ever downloaded use that method
22:44:20 <frosch123> GetMaxAge is not used either
22:44:38 <_glx_> there's one checking elapsed time with threshold to do stuff, and economy starting at 0 just breaks it
22:45:02 <_glx_> (but it was already broken if start date was 0)
22:45:44 <_glx_> they just assume a "normal" start date
22:46:38 <_glx_> wallclock mode just easily triggers some unhandled edgecases
22:49:05 <frosch123> hmm, SV shows the remaining time for the year
22:49:20 <frosch123> it says "years", but it's "periods" ofc
22:49:38 <frosch123> but even if i was to show "periods", you can't see the current period anywhere
22:50:31 <xarick> oh, right, that just adds to the confusion, the function names still using the pre-14
22:50:31 <_jgr_> The most common use of scripts seems to be for town growth, which should work fine with default economy dates
22:51:06 <frosch123> SV also works as intended, just the wording of the messages is difficult
22:51:21 <frosch123> or confusing to players, who do not know the history
23:02:45 <truebrain> marking as "backport requested", you say? ๐
23:08:22 <_glx_> it fails because year is "1" so it's less than the 2 characters it expected when doing ``` tmp = AIDate.GetYear(date).tostring();
23:08:22 <_glx_> local year = tmp.slice(2);
23:10:36 <xarick> removed ScriptEngine::GetDesignDate
23:10:58 <frosch123> if 2 macros cause problems, add a 3rd?
23:11:35 <_glx_> that's me trying to add a warning message in compat nut
23:15:20 <frosch123> hah, i remembered to set "backport squash", even though i only learned from backlog about its existence
23:15:54 <_glx_> oh it's not needed anymore ๐
23:17:15 <frosch123> i read backlog once, and then it's out of date
23:19:35 <_glx_> there's always 1 vehicle in a shared order
23:22:22 <xarick> if the last order is removed, orderlist is also deleted?
23:23:04 <xarick> CodeXL sometimes fails
23:24:15 <_glx_> CodeQL can't know everything
23:25:21 <_glx_> and it's not wrong here, it's safer to validate
23:25:45 <xarick> the change from byte to uint8_t is global?
23:26:02 <xarick> or are some things that still remain byte
23:26:08 <peter1138> I used an assert so that it disappears in a release build.
23:26:21 <_glx_> the idea is to "eradicate" byte
23:26:43 <xarick> got some bytes used in some PRs, gonna fix
23:49:06 <xarick> I want a 16 core cpu ๐
continue to next day โต
