IRC logs for #openttd on OFTC at 2024-01-27
⏴ go to previous day
00:23:07 *** gelignite has quit IRC (Quit: Stay safe!)
01:07:30 *** tokai|noir has joined #openttd
01:07:30 *** ChanServ sets mode: +v tokai|noir
01:14:16 *** tokai has quit IRC (Ping timeout: 480 seconds)
03:32:44 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:47:31 *** Wormnest has quit IRC (Quit: Leaving)
04:54:39 *** krushia has quit IRC (Quit: Konversation terminated!)
05:34:56 *** amal[m] has quit IRC (Quit: Client limit exceeded: 20000)
07:34:35 <andythenorth> ^ that's a nice catch
07:34:55 <andythenorth> I've seen the issue with FIRS GS, but had no headspace to look at it
09:00:06 <truebrain> right, what was I going to do today ...
09:05:18 <truebrain> that ticket is rather hard to decypher .. but I guess fundementally the issue is that Squirrel is not strongly typed 😄
09:05:53 <xarick> I'm jealous... #11768 is approved while it's inferior to #10544
09:10:49 <truebrain> Lol: `The following actions uses node12 which is deprecated and will be forced to run on node16`
09:10:50 <truebrain> `Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20`
09:11:52 <truebrain> first upgrading to node16, then complaining it isn't node20 😛
09:17:33 <xarick> is it because of the added complexity?
09:18:02 <truebrain> xarick: What you call "inferior" to me is completely unreadable code. It does so much in so many places, for no clear reason most of the time, that you need a PhD to get through it
09:18:17 <truebrain> we told you many times before, but if you want these kind of PRs to be accepted, you need to slim them down. Do one thing, and one thing only
09:19:29 <truebrain> in general you appear to be just typing code till it works; instead of actually figuring out how to do things simple, small and understandable
09:19:53 <truebrain> just compare your PR with #11768 .. even if it would actually be less inferior, the complexity of the code is drasticly lower
09:21:00 <truebrain> and I don't mean to be rude, but one way or the other people have told you this in more subtle ways; so I just want to be clear so you know what is going on
09:26:23 <truebrain> one of the things we use to make such complex PRs reviewable, is build them up via multiple commits. If you check any of the recent big PRs, you see that they have 10+ commits, every one doing a small thing
09:26:35 <truebrain> so it becomes possible for other people to understand what is going on
09:29:51 <xarick> hmm, splitting it at this point, oh well, will try
09:30:31 <truebrain> it is not about the splitting; it is about making it understandable
09:30:36 <truebrain> show that code is actually needed
09:30:55 <truebrain> why you need to add 500 (!) lines of code to do this
09:31:41 <truebrain> I mean .. the PR renames `INVALID_WATER_REGION_PATCH` to `WATER_REGION_PATCH_LABEL_NONE` without any reasoning as to why
09:31:53 <truebrain> randomly, by it seems
09:32:03 <truebrain> and I don't want to read "why" in this chat
09:32:08 <xarick> not randomly, I needed 255 to be the invalid one
09:32:10 <truebrain> I want the PR to be clear enough that I am not wondering about it
09:32:45 <truebrain> one of the ways to do that, is to have small commits that make these small changes, so the commit message can explain what is happening
09:33:40 <truebrain> but so many things in that PR just feel weird ... like, why does a depot-finder need so much code, and the normal pathfinder wouldn't? Why would finding a depot be so much more special than finding a dock. That can't be true.
09:33:54 <truebrain> and I can keep going, but the summary is: the PR does too darn much with too little context in too few steps
09:34:08 <xarick> it's because there is no destination set
09:34:24 <truebrain> and now compare it with the other PR, there you get a small simple change, that touches only a few lines of code
09:34:25 <xarick> and the original code doesn't have that
09:34:34 <truebrain> again, I don't want to hear the answers here. You ask why one is approved over the other
09:35:24 <truebrain> and what you do now, is focus on one of the things I mention, and you try to resolve that; but you miss the bigger picture in what I am telling you
09:38:47 <xarick> ok, the simple approach is rather... bad. I'm sure given the right conditions, it's not going to solve 8022
09:38:53 <xarick> i don't want to sound mean
09:39:19 <xarick> but using distance manhattan or distance square...?
09:39:24 <truebrain> I don't care if you sound mean. But your PR as it stands is just .. impractical to review. So if you want your approach accepted, you will have to figure out a way to get it more .. managable
09:41:10 <truebrain> Say you are building a car engine. And I give you a manual that says: this is a car engine, and that is all. I put the pieces for the car engines throughout your yard. Here and there I put a little note which says what the part is doing.
09:41:10 <truebrain> Would you be happy about that? Would you want to try to put the engine together?
09:46:11 <xarick> also the limitation to 80 tiles... that's 6 regions. I don't know, it doesn't feel natural. First you have the advantage of water regions only to not allow long distances? What about when higher speed ships become a thing? 80 tiles will feel a too short limitation
09:46:40 <truebrain> well, I tried at least.
09:47:58 <truebrain> okay, that action change took a lot of work to actually properly test, but I did found bugs because of it. Now to try it live .... pam pam pammmm
09:48:04 <xarick> I will try to do my best to add commits in-between
09:51:17 <truebrain> okay, time to deploy a new game-coordinator to staging ... in an ideal world, it doesn't need any changes to support the new game-info packet .. we will find out if that is actually true soon 😄
09:54:26 <truebrain> that seems to work \o/
09:55:05 <truebrain> and backwards (and forwards) compatible \o/
09:55:30 <truebrain> deploying to production!
09:56:39 <truebrain> owh, do I also need to deploy the old master-server? I guess ...
09:59:13 <truebrain> ah, no, master-server also doesnt support game-info v5 and v6
09:59:16 <truebrain> so this will be fine 🙂
10:04:37 <truebrain> lolz ... euh .. yeah, I made a tiny mistake. lolz
10:05:54 <truebrain> I just blame the reviewer
10:10:35 <truebrain> CodeQL, that is still bullshit
10:21:38 <truebrain> redeploying a new game-coordinator to production .. 2 interruptions on a single day .. baaddddd
10:34:20 <truebrain> okay; that should fix the partial listing of the in-game client as you see with my PR 🙂
10:41:38 <truebrain> to postfix string-names or not, now that is the question
10:42:12 <truebrain> `STR_NETWORK_SERVER_LIST_GAMESCRIPT :{SILVER}Game Script: {WHITE}{RAW_STRING} (v{NUM})` .. also required context to understand the `v`
10:42:16 <Eddi|zuHause> what's the opposite of postfix? postlose? :p
10:42:17 <truebrain> not an excuse not to start adding context now btw
10:42:41 <Rubidium> Eddi|zuHause: preloose then ;)
10:45:04 <Rubidium> truebrain: here it *might* be that {NUM}h {NUM}m is clear enough, but if it were "only" "Play time: {NUM}m", I would probably have interpreted the m as months
10:45:26 <truebrain> ha, lol, yes, but that would also have been terrible in english
10:45:38 <truebrain> but you absolutely have a point we give little context to translators
10:45:47 <truebrain> I am just wondering if this is the place to start that change 😄
10:46:32 <Eddi|zuHause> add translator hints to each string?
10:46:34 <truebrain> (or that we just make something different once, and have to fight that down the road again 😛 )
10:46:42 <Eddi|zuHause> like... comments?
10:46:49 <truebrain> eints doesn't support that
10:47:18 <Rubidium> with map size we do not give any units, so there's no units translate. With the script name + version there is indeed something to wonder about what the 'v' means
10:47:33 <truebrain> yeah, and in many more places it is just ... vague
10:47:58 <truebrain> the issue I kinda see happening with postfixing types, what if the string changes .. that would put it on the list of: rename this string when we can
10:48:21 <truebrain> kinda makes me wonder if we shouldn't make a string that does this Nh Mm formatting
10:48:23 <truebrain> and use that instead
10:48:42 <locosage> h/m/s notation would be pretty useful as a string code btw
10:48:47 <locosage> I'm already using it on citymania
10:48:52 <Eddi|zuHause> STR_TIME_HOURS_MINUTES?
10:49:18 <truebrain> that, or a `{COMMA}` variation
10:49:50 <Eddi|zuHause> but the {COMMA} means hardcoded time format for each language?
10:50:06 <truebrain> okay, better example, `{DATE_SHORT}`
10:50:14 <truebrain> there is a `STR_FORMAT_DATE_SHORT` to fix that
10:50:44 <Eddi|zuHause> that sounds plausible
10:50:44 <truebrain> but what to call it ...
10:51:41 <Rubidium> oh, {COMMA} tangent time... maybe the string should be "{COMMA}h {NUM}m", so it will be "16.588h 49m" instead of "16588h 49m"
10:52:12 <truebrain> `{TIME_SHORT}`, that kinda works for me
10:52:18 <truebrain> what do you think Rubidium?
10:52:36 <locosage> "{NUM}h {NUM}m {NUM}s",
10:52:36 <locosage> "{NUM} days {NUM} hours {NUM} minutes",
10:52:36 <locosage> "{NUM}m {NUM}.{NUM}s",
10:52:36 <locosage> "{NUM} hours {NUM} minutes{STRING}",
10:52:36 <locosage> "{NUM}m {NUM}.0{NUM}s",
10:52:37 <locosage> "{NUM}m {NUM}s{STRING}",
10:52:37 <locosage> "{NUM}m 0{NUM}s{STRING}",
10:52:39 <locosage> "{NUM}h {NUM}m 0{NUM}s",
10:53:10 <Rubidium> my gut says {TIME_SHORT} is something like 10:53
10:54:34 <Eddi|zuHause> there's also a difference between (time and timeframe
10:54:41 <truebrain> on the other hand, `DATE_SHORT` you also have to look up how it is actually rendered
10:54:41 <locosage> I called it DURATION
10:54:43 <Rubidium> maybe {DURATION_SHORT} ?
10:54:47 <truebrain> several interpertation you can have of that 😄
10:55:01 <Eddi|zuHause> the time is 11:54, but the timeframe since midnight is 11h 54m
10:55:04 <truebrain> the m ain issue I have with `SHORT` is that it is not clear there are no seconds 😛
10:56:52 <Eddi|zuHause> but is that important information at that point?
10:59:10 <Rubidium> sorry, my mind is going on yet another tangent. DURATION_SHORT is 1 value ({COMMA} days, {NUM}h, {NUM}m, {NUM}s) depending on the actual value. DURATION is 2 values ({COMMA}d {NUM}h or {NUM}h {NUM}m or {NUM}m {NUM}s), and DURATION_LONG is {COMMA}d {NUM}h {NUM}m {NUM}s or something along those lines
10:59:59 <truebrain> `{DURATION_HOUR}`, `{DURATION_DAY}` ...
11:00:03 <Rubidium> and what variant is chosen, depends on the value
11:00:06 <truebrain> so only `{DURATION_HOUR}` for now
11:01:52 <Rubidium> though... maybe not jump to conclusions on this brainstorm session just yet. If the current string name is clear enough for translators, the PR is still fine to me. The duration thing can then be a follow-up feature
11:02:03 <locosage> d/h/m/s can also be written without abbreviation
11:02:40 <truebrain> Rubidium: true; but it annoyed me that I used the same syntax twice 😛
11:02:45 <Eddi|zuHause> locosage: but that would be {DURATION_LONG}
11:03:03 <locosage> Eddi|zuHause: not in the way Rubidium sees it xD
11:03:16 <truebrain> but I do agree, let's not fix that issue in this PR; so in that case, I vote we just leave the name as it is now.
11:03:46 <Eddi|zuHause> locosage: it's a perfect example of bikeshedding :p
11:04:09 <Eddi|zuHause> everyone can have an opinion, but it's not affecting anything critical.
11:06:35 <truebrain> owh, I first have to fix workflow warnings ofc ..
11:14:52 *** welterde has quit IRC (Quit: Moving day)
11:27:34 <truebrain> right, social plugins .. that was what I was going to do. Lunch first.
11:32:39 <emperorjake> I know for a fact that this server's been up for more than 8 hours
11:34:22 <emperorjake> It was unpaused most days for the past week
11:36:21 <emperorjake> could JGRPP daylength be skewing the results somehow?
11:36:47 <truebrain> JGRPP will have to adjust to the new game info to present daylength servers correctly
11:36:57 <truebrain> Till then, it is an estimation for those
11:46:39 <truebrain> emperorjake: In a bit more detail, for servers that don't send their actually play time yet, we estimate it by looking at the calendar dates. So this is only an issue for daylength servers on JGRPP 🙂
11:47:14 <emperorjake> ahh that makes a lot of sense 🙂
11:48:13 <truebrain> Also why we are adding it, as with daylength looking at the calendar isn't giving you any info about how far along a game is 😄
11:49:15 <locosage> play time isn't telling much either as you don't know when it ends
12:32:59 <andythenorth> cdist: "cargo only goes where **you** build routes, but it ignores route capacity"
12:33:13 <andythenorth> something is strange
12:34:22 <truebrain> okay ... building test versions for all three, but this should be it .. I hope
12:37:44 <andythenorth> /me must fix that
12:42:40 <truebrain> owh, and the OpenTTD nightly failed on some automation .. ugh
12:44:48 <truebrain> `There is at least one repository that does not exist or is not accessible to the parent installation.`
12:48:36 <peter1138[d]> 20-25% climb in the big ring, such idiot
13:01:22 <_glx_> oh no, this fix was applied everywhere
13:02:04 <_glx_> (and it's a pain to test)
13:02:32 <truebrain> it really was a pain to test, yes
13:02:54 <truebrain> I am 90% sure I got it right now
13:03:11 <truebrain> luckily, only 2 places to fix
13:06:17 <truebrain> and let's try this again shall we?
13:07:44 <_glx_> the expected difference is output not only in artifacts ?
13:08:03 <truebrain> a non-failing MacOS 🙂
13:08:07 <truebrain> is the expected output 😛
13:08:17 <truebrain> after that, I am hoping for a succesful upload to our CDN 🙂
13:08:21 <_glx_> implies output in the right place
13:08:44 <truebrain> no, the other way around 😛 Output to the right place implies a working MacOS 😄 😄
13:08:54 <truebrain> I am so annoyed it needed icns file bla
13:09:32 <_glx_> silly they don't have basic icons for this case
13:09:43 <truebrain> I mean, I get it, apps need to look pretty
13:10:04 <truebrain> the new Artifacts btw are uploaded to Azure blob storage
13:10:12 <truebrain> seems they finally got it migrated 🙂
13:10:13 <_glx_> windows has a generic app icon
13:11:41 <_glx_> not super nice, but exists since the first windows version I think
13:12:18 <truebrain> also nice, the new artifacts become available at upload; not at the end of the workflow
13:12:24 <truebrain> so you see them being added while they are being added
13:12:47 <truebrain> `Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: Apple-Actions/import-codesign-certs@v2.`
13:12:57 <truebrain> there is a ticket open on that repo since november
13:13:03 <truebrain> but .. no action yet
13:13:38 <truebrain> okay ... uploading to the CDN seems to work ... now let's see if the CDN update job is going to work ..
13:13:42 <_glx_> problem matchers author is better on this task 🙂
13:13:50 <truebrain> yeah, that was shockingly fast
13:14:17 <truebrain> okay, trigger worked too
13:14:52 <truebrain> it made the folder, but clicking it gives a 404
13:18:25 *** virtualrandomnumber has joined #openttd
13:18:39 *** virtualrandomnumber has quit IRC (Remote host closed the connection)
13:21:51 <truebrain> nice; mostly scared about MacOS, I have to admit 😄
13:22:33 <truebrain> emperorjake: okay, first a check: app icons were working? Install script was working?
13:22:46 <emperorjake> Install and icons worked perfectly
13:22:58 <truebrain> please start with -dmisc=2, and let me know why it fails signature
13:23:19 <_glx_> so nice, 2 things fixed, and 1 broke 🙂
13:27:43 <truebrain> owh ... CDN release script does not appreciate my `v1.0.0` syntax .. it really wants `1.0.0` .. lol
13:27:58 <truebrain> and I kinda wanted to change to semver when possible 🙂
13:28:43 <truebrain> owh, `v1.0.0` is not semver .. so I guess I can get away with it 😛
13:28:48 <truebrain> but it looks so much betterrrrrr
13:28:59 <_glx_> ah so it's not directly the plugin failing, it's the lib it uses
13:29:41 <truebrain> yeah, but that lib too, is checksumed after making it universal
13:29:45 <truebrain> so it shouldn't happen
13:30:20 <LordAro> i'm getting lots of emails from truebrain today
13:30:32 <truebrain> not really .. administrative bla 😦
13:32:58 <truebrain> _glx_: signature of both files are wrong
13:33:50 <truebrain> (I want to know if it is a Discord specific issue or not)
13:36:24 <belajalilija> r24309: brickblock19280
13:36:31 <truebrain> just imagine joining a Discord for 6 months before starting to send spam messages .... that is just priceless
13:37:36 <Eddi|zuHause> i don't want to find out what kind of scam that is
13:38:18 <truebrain> owh, signing happens AFTER the checksum is calculated
13:38:22 <truebrain> ffs ...... CMake ....
13:38:26 <truebrain> I run on POST install
13:38:31 <truebrain> why are you doing something POST after my POST
13:38:52 <truebrain> (and signing changes the file itself with the signature)
13:38:58 <truebrain> ffs .... MacOS, I hate you
13:41:20 <truebrain> And it goes from signing directly to creating a dmg file .. so there isn't even a moment I can execute a script
13:43:53 <truebrain> so skip signing via CMake and do it ourselves, I guess
13:46:23 <emperorjake> truebrain: Steam is working yes, just had to track down that ID file again
13:46:38 <truebrain> that should have been fixed in that release? Odd
13:47:28 <truebrain> manual signing it is .. can I test this? Not really ... "fun"? sure.
13:47:35 <truebrain> (getting more and more grumpy about this 😛 )
13:49:57 <_glx_> everything is "simple" with MacOS 😉
13:52:34 <peter1138[d]> Feature: Social plugins for Windows & Linux.
13:52:36 <truebrain> let's hope I only need one try .... as otherwise this will be loud 😦
13:55:44 <_glx_> another option could be to disable signature validation for macos, they already require the files to be signed by openttd
13:55:44 <truebrain> just no idea if anything except libraries need signing
13:55:49 <truebrain> or if there is some other magic something going on
13:56:04 <truebrain> _glx_: That is an OS-level setting; so every user would need to do that
13:56:50 <_glx_> I mean our internal validation
13:57:21 <truebrain> meh; signing a MacOS DMG is more complicated than I was hoping
13:57:34 <_glx_> or is the error coming from MacOS check itself ?
13:57:44 <truebrain> no, this is our validation; but I rather not skip it for one OS
13:57:46 <truebrain> is asking for trouble
13:59:43 <truebrain> one more try .. I had a crazy idea ...
14:00:45 <_glx_> at least a test run is fast 🙂
14:02:21 <truebrain> it is mostly rust dependencies not being cached .. so annoying 😛
14:03:09 <truebrain> I didn't push my changes to the right branch
14:04:03 <kuhnovic> zephyrisviaGitHub: I hope I can find some time to look into this PR tonight. Although Rubidium seems to have picked up where I've been slacking 😇
14:04:06 <truebrain> I hate having to do this on the main repo .. but yeah ....
14:05:36 <kuhnovic> I think it can be merged. It's still not the most optimal way to search for depots, but it's a lot better than it was!
14:06:10 <kuhnovic> All part of my Make Ships Great Again campaign 😎
14:08:34 <Rubidium> kuhnovic: oh, I thought it was Make Ekroplanes Great Also ;)
14:09:32 <truebrain> hmmm ... notarizing keeps failing ... why ....
14:09:42 <kuhnovic> Rubidium: Those are ships too 🙂
14:09:57 <kuhnovic> Begin the flame war...
14:10:47 <truebrain> I need access to a Mac to debug this properly 😦
14:12:13 <truebrain> or a way to know why notarization says: nah bro
14:14:20 <truebrain> I was thinking something like this would do .. but clearly I am wrong
14:16:19 <Eddi|zuHause> kuhnovic: what are hydrofoils?
14:18:11 <kuhnovic> Eddi|zuHause: Not airplanes, I know that much 😆
14:21:55 <andythenorth> how do I unnest a group?
14:22:33 <talltyler> Drag it somewhere else
14:22:36 <Eddi|zuHause> drag it to ungrouped?
14:23:01 <Eddi|zuHause> drag it outside the environment.
14:23:15 <Rubidium> truebrain: just don't mess up spelling, as then it's going to cost a lot of resources
14:23:29 <truebrain> emperorjake: can you send me the result of `codesign -dv libdiscord-social.dylib` pretty please? 🙂
14:23:37 <truebrain> Rubidium: ghehehe 😄
14:28:04 <truebrain> very odd; so when I sign the library, notarizing fails, but when I let CPack do it, it works .. but I looked at their source how they do it, and I do the same
14:28:14 <peter1138[d]> Oh, I didn't do an SVG version of that up arrow. Hmm.
14:38:10 <truebrain> right .. attempt #6 .. I have some hope ... this is so much "fun" 😛
14:43:34 <talltyler> This is fun: my debug build sometimes takes so long to scan GRFs that the main menu starts panning across the game world, even though it’s still paused 😄
14:44:06 <talltyler> I have no idea why I have the 13.x intro game in my debug build 🤔
14:44:29 <peter1138[d]> Useful to test loading newer games sometimes 😉
14:45:26 <talltyler> Well, not "why" but "how" I guess
14:45:35 <talltyler> I never intentionally changed it
14:47:16 <truebrain> let's try this again
14:47:47 <truebrain> welcome to the correct group of people talltyler
14:47:56 <truebrain> (IRC people won't get it; sounds like a you-problem 😛 )
14:47:59 <talltyler> truebrain: I tried to make it obvious to distinguish signal groups with a divider (matching that of the landscaping menu), but... `NC_EQUALSIZE` strikes again. 😦
14:48:17 <truebrain> landscaping can do it, so can you!
14:48:34 <truebrain> I would also do one after PBS
14:48:45 <truebrain> but ... you might need peter1138[d] to tell you what is right and wrong 🙂
14:49:06 <talltyler> Landscaping does `SetMinimalSize(22, 22)` on every button
14:49:07 <truebrain> ugh, all the CI power is assigned to other projects, so my Discord plugin is not releasing 🙂
14:52:43 <peter1138[d]> talltyler: Split into groups properly. a 4x2 group on the left, and a 3x2 group on the right. With a full-height small divider in the middle.
14:53:11 <peter1138[d]> Or: if the user wanted to see all those signals, let them, that's their problem.
14:53:43 <truebrain> showing the signals wasn't the challenge; I was wondering if we can make visible what the "groups" are on the PR talltyler is working on 🙂
14:54:13 <truebrain> (with his PR, you can cycle through the group, but .. nowhere is defined what that "group" is 😛 )
14:55:49 <peter1138[d]> Oh I see. This is a too-many-spacebars issue...
14:56:00 <truebrain> aren't most problems? 😄
14:56:20 <truebrain> should really work now 😛
14:57:32 <Eddi|zuHause> jobposting: "remote windows 3.11 administrator"
14:57:40 <truebrain> okay, upload to the CDN worked, stuff is updated properly
14:59:08 <emperorjake> truebrain: it's fully functional 😁
14:59:30 <Eddi|zuHause> a fully functional battle station, you said? :p
14:59:50 <truebrain> tnx emperorjake , andythenorth , _zephyris for helping out with the MacOS bla 🙂
15:01:10 <peter1138[d]> I updated comments to not refer to multiple invalidations.
15:03:31 <peter1138[d]> Gah, bug reports in the forum...
15:04:03 <_glx_> if it's in the forum, it's not a bug report 🙂
15:04:32 <peter1138[d]> And there was one on IRC last night too.
15:05:04 <truebrain> peter1138[d]: I fixed that
15:05:17 <peter1138[d]> By deleting IRC?
15:05:35 <truebrain> I also have an open PR to fix hopefully the last smooth scrolling bug 😛
15:05:46 <truebrain> still wonder if there is a better way to calculate the distance traveled per ms
15:05:50 <truebrain> these loops annoy me
15:11:34 <truebrain> can only release these two if the website PR is merged; otherwise it will fail to deploy anyway 😄
15:12:59 <truebrain> owh, haven't seen that PR today before!
15:13:07 <truebrain> (add sarcasm where needed)
15:19:42 <peter1138[d]> Oh, the assertion failed. 😮
15:20:45 <talltyler> Heh, the two groups don't match each other...
15:21:05 <talltyler> Worth using SetMinimalSize?
15:21:06 <peter1138[d]> But not all builds 😮
15:22:13 <talltyler> Small menu is uglier, using the spacer to make space for the title instead of making the buttons wider
15:23:39 <_zephyris> How's the size of the titlebar buttons defined? The big/small window switch looks ugly without some padding
15:23:53 <talltyler> peter1138[d]: Not sure if you're trying signal spacing or something else, but want me to push my work to a branch somewhere?
15:26:19 <peter1138[d]> _zephyris: It's a "normal" img button, unlike the rest of the window decorations.
15:26:30 <peter1138[d]> So it needs padding on the sprite itself.
15:26:41 <peter1138[d]> 1 (scaled) pixel is all it needs.
15:30:40 <_zephyris> OK, so nocrop needed. So how's the base/original TTD window decoration sizes defined?
15:31:06 <peter1138[d]> Hard coded padding.
15:31:19 <talltyler> I've decided that I don't like the spacers at all. It just makes the window busier than it already is.
15:31:34 <peter1138[d]> Well, in original TTD it was hard coded widget sizes, and the image always fit.
15:31:44 <peter1138[d]> But that doesn't allow different size icons.
15:32:38 <peter1138[d]> wants to have the same size set for all signal widgets, but
15:34:23 <peter1138[d]> The selection widgets can be simplified now though.
15:34:38 <peter1138[d]> Does not need to be per icon, it can be for the whole group.
15:34:40 <emperorjake> How about a nice red warning box when you expand the signal selection 😅
15:34:49 <peter1138[d]> And the first space needs a selection widget too.
15:34:51 *** janciothor has joined #openttd
15:34:51 <janciothor> regarding the topic of semaphores, does anyone of you know why in JGRPP only 2x3 semaphores are shown and not 2x6 semaphores as above (or in version 13.4)
15:35:37 <talltyler> You probably have realistic braking enabled, which disables pre-signals and makes block signals act like path signals
15:35:39 <peter1138[d]> Because you haven't expanded the window.
15:36:50 <janciothor> talltyler: I have realistic braking, thanks for the quick answer
15:37:16 <peter1138[d]> truebrain: FML, i forgot to check for other functions passing gui_scope as a parameter. Sigh.
15:37:28 <peter1138[d]> void InvalidateWindowData(WindowClass cls, WindowNumber number, int data = 0, bool gui_scope = false);
15:37:33 <peter1138[d]> ^ they're all deferred. Oops.
15:37:36 <truebrain> it is not like I warned you 😛
15:37:48 <peter1138[d]> Good job for asserts, right.
15:38:48 <_glx_> the assert was indeed a good idea
15:40:14 <peter1138[d]> Well, std::unordered_set I guess, so that they appear in the same order they were pushed.
15:40:29 <peter1138[d]> Maybe I should just search
15:41:14 <_jgr_> unordered_set does not iterate in insertion order
15:41:19 <peter1138[d]> (Unless unordered_set means random...)
15:41:30 <truebrain> it is ... unordered 😛
15:47:44 *** Wormnest has joined #openttd
15:47:49 <merni> Well, there is a guide to directory structure in the openttd repo
15:47:56 <truebrain> I was just doing that!
15:48:38 <truebrain> the markdown in that document is only terrible
15:48:43 <truebrain> so it doesn't actually allow decent linking
15:50:16 <peter1138[d]> 1: + ERROR: Registering two scripts with the same name and version'
15:54:49 <truebrain> You are using your approve quota really fast this way 😛
16:00:35 <_glx_> peter1138[d]: maybe 1 day I'll filter these lines from the logs 🙂
16:01:10 <peter1138[d]> Or regression should ignore non-regression data (except the baseset) somehow...
16:01:30 <truebrain> and yes, very early, it is a draft, don't worry
16:03:13 <truebrain> rebase before push, ffs
16:04:03 <truebrain> did some stats, put them in the news article ... 2000 commits, 60 contributors, 40 features, 500 fixes, 200 changes .. and people claim OpenTTD is dead
16:04:31 <peter1138[d]> We did have a lull...
16:04:40 <peter1138[d]> Probably about 10 years ago.
16:05:03 <truebrain> sure; we have them from time to time. But ... yeah. Just saying 😛
16:05:17 <truebrain> (and I had to look up wtf `lull` meant 😛 )
16:05:33 <peter1138[d]> An actual word, yes 😄
16:05:38 <truebrain> yeah, I was surprised
16:05:43 <truebrain> the word for dick in Dutch is `lul`
16:05:52 <truebrain> so I had to look it up 😛
16:06:08 <peter1138[d]> (User was banned from the server)
16:06:10 <truebrain> it is pretty common for friends to say that to each other when they are being annoying 🙂
16:07:12 <truebrain> I -think- I copied all the right files to the right places
16:07:16 <truebrain> but it was hard to keep track of everything
16:08:10 <emperorjake> Sure, sleep first though 🙂
16:08:32 <truebrain> no worries; sleep well 🙂
16:08:42 <truebrain> _glx_: mind checking the Windows versions of those?
16:09:48 <truebrain> Linux versions load fine too 😄
16:10:03 <truebrain> what a struggle it has been ... pffff
16:10:17 <truebrain> after tonights nightly, I will attach the Steam plugin to the Steam nightly
16:10:53 <_glx_> guess I missing the special steam file
16:11:00 <truebrain> Steam only works via Steam
16:11:06 <truebrain> so that will happen tonight 🙂
16:11:07 <andythenorth> this bug took some time to figure out 😛
16:11:21 <andythenorth> first vehicle is reversed, but does not have random reverse on build
16:11:26 <andythenorth> autoreplace though
16:11:53 <andythenorth> flip state is inherited when replaced
16:14:49 <talltyler> Hmm, should it do that?
16:18:58 <truebrain> good point. I also need power-of math function
16:19:01 <truebrain> but .. yeah .. I might as well
16:19:08 <truebrain> makes it a lot simpler to read, instead of a for-loop 😛
16:20:10 <peter1138[d]> andythenorth: uh oh
16:20:19 <andythenorth> fix it in grf? 😛
16:20:32 <peter1138[d]> Is it ctrl-flippable?
16:20:51 <andythenorth> what if I set random reverse probability to 0? 😛
16:21:22 <peter1138[d]> I guess the issue is there's no difference between manually and auto-flipped.
16:21:46 <peter1138[d]> Should autoreplace keep flipped state anyway?
16:22:02 <peter1138[d]> (Autorenew, yes)
16:24:47 <xarick> extremely disappointment with that merge... 😦
16:28:13 <andythenorth> peter1138[d]: dunno 🙂
16:28:25 <andythenorth> flip a coin to decide? 😛
16:28:42 <xarick> getting depots via distancesquare and adding a range limit even for manual send to depot orders... how is that accepted!
16:30:14 <peter1138[d]> xarick: It's preferable to the situation before. It does not mean further improvements can't be made.
16:31:00 <merni> Also, even trains have limitation on their sending-to-depot
16:31:14 <merni> eg. if the route to a depot needs a reversal, it will not find a depot
16:32:30 <merni> just don't have insane distance to the depot :p
16:33:50 <xarick> you can have a rail depot in the other corner of the map, and if a rail can lead to it, it will find it
16:35:35 <merni> as others have been saying... if you feel your pr is still an improvement, you just need to make it into a reviewable form
16:45:23 *** gelignite has joined #openttd
16:55:37 <truebrain> Lol, silly bug 😛 bad reviewer
16:57:48 <truebrain> only a bug with scripts, so 'it is fine" 😛
17:01:06 <_glx_> a possible improvement for FindClosestShipDepot() is using step 2 to sort valid depots by distance, then check the actual paths
17:01:37 <truebrain> awh, std::pow can only use floats as second argument in C++23 ...
17:02:02 <_glx_> and stop on first not better path
17:03:03 <_glx_> good we don't use c++23 🙂
17:03:15 <truebrain> how is that good?! 😦
17:05:36 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:06:34 <_glx_> hmm it doesn't seem different to pre c++23 std::pow
17:07:09 <truebrain> second parameter, as I mentioned, can only be float in C++23
17:07:13 <truebrain> it is int in earlier versions
17:07:30 <truebrain> there is `powf`, so it is fine
17:07:55 <kuhnovic> xarick: I just wanted an easy fix for the problem of unreachable depots being selected. Your PR introduces an actual pathfinder-based approach to select depots more intelligently. These are two completely different things IMO
17:08:12 <truebrain> owh, you are right, I am misreading this ..
17:08:16 <truebrain> so used that it says "since"
17:08:21 <truebrain> but they also have an "until" ...
17:08:54 <_glx_> the only change I see with c++23 is the move to "floating point type"
17:09:07 <truebrain> in C++23 it is just: equal type in, equal type out
17:09:25 <truebrain> but yeah, I did not read the "until" .. I read it as "since"
17:10:28 <truebrain> hmm .. it seems someone fixed the DParam issue I was running into, causing a heap-use-after-free 😛
17:10:39 <wensimehrp> I don't have gog galaxy installed on my computer. Is it working as intended or it shouldn't be working like that?
17:10:54 <truebrain> give it 30s, it will drop down to not-working
17:11:03 <_glx_> kuhnovic: but it seems to be so much more complex than required
17:11:11 <wensimehrp> yeah it says unloaded
17:11:34 <truebrain> GOG has no detection whether it is running; the other platforms do 🙂
17:11:38 <truebrain> so slightly different behaviour there
17:12:16 <_glx_> like when during the tests you were still playing openttd in an area, and offline in another
17:12:21 <kuhnovic> _glx_: I completely agree, but that's a different discussion 🙂
17:13:27 <truebrain> peter1138[d]: the weird movement at the border is back 😄 But this time it is funnier. It reaches the destination .. hangs there for a bit .. the moves the final piece 😛
17:15:12 <truebrain> mostly happens when clicking far outside of the map
17:16:36 <truebrain> yeah, so it tries to move (2, 1), but it is bounced back constantly
17:17:31 <peter1138[d]> I still suggest you clamp to the viewport before applying the smoothing function.
17:17:51 <truebrain> it already does that, not?
17:18:19 <peter1138[d]> It clamps the destination, not the current position.
17:18:23 <truebrain> it is funny, it only happens on 2 sides, and only in 1 direction ... lol
17:18:37 <truebrain> the current position is clamped when being set; so I assumed that is the same?
17:18:42 <peter1138[d]> Move line 1968 to 1943
17:19:16 <peter1138[d]> Almost the same, it affects how the smoothing is applied.
17:19:41 <truebrain> yeah, but my point is, nobody else is changing viewport->scrollpos
17:19:46 <truebrain> and it is clamped after the smoothing
17:19:47 <peter1138[d]> Ah well. It probably solved some situation I encountered when testing with other changes 🙂
17:19:49 <truebrain> which is the same as before
17:19:52 <truebrain> as .. it is a circle 🙂
17:19:55 <peter1138[d]> Drag scrolling does.
17:20:06 <truebrain> ah, yes, I wasn't dragging 😄
17:20:55 <truebrain> the viewport remains a mistery
17:22:31 <truebrain> it is just weird ... and now because I use a more fine-grained timing, it surfaces again ..
17:22:50 <truebrain> but basically, you need to move (48, 24), so the smoothing says: do (4, 1) .. next round, you still have to move (48, 24)
17:26:40 *** gelignite has quit IRC (Read error: Connection reset by peer)
17:27:44 *** gelignite has joined #openttd
17:29:38 <truebrain> ah, okay .. a solution is to always move x with at least an even number
17:30:57 <truebrain> well, a tile is twice as wide as high
17:31:03 <truebrain> so I am still guessing this is due to rounding issues
17:32:11 <peter1138[d]> ClampViewportToMap probably needs to be adjusted to be unrelated to subtile units.
17:33:17 <truebrain> at this point I am just working around bugs in the viewport system, which is less then ideal 😄
17:38:11 <talltyler> peter1138[d]: I'm happy to create a WidgetDimension for spacers (I think there's just two: this one and terraform toolbar?), but...where would it go? Scaled or unscaled?
17:38:18 *** rain[m]1 has joined #openttd
17:39:11 <peter1138[d]> Hmm, terraform uses 2 pixels.
17:39:36 <peter1138[d]> rail toolbar and airport toolbar use 4 pixels.
17:40:18 <peter1138[d]> dock toolbars uses 5.
17:40:28 <talltyler> So, leave it as a magic number for now and make a separate PR to use a consistent constnat?
17:40:31 <peter1138[d]> station toolbar uses 5.
17:40:45 <peter1138[d]> Yes, separate PR for it. it soon becomes a larger scope 🙂
17:42:45 <peter1138[d]> And scaled/unscaled are two instances of the same struct -- one is constexpr and usable by NWidgetPart, the other is updated at runtime and not usable (since I made NWidgetPart lists constexpr)
17:42:55 <truebrain> talltyler: they are cute now!
17:43:10 <merni> That will satisfy some people to go bakc to before path signals :p
17:44:26 <talltyler> Ah, lost an `EndContainer()` somewhere
17:44:45 <peter1138[d]> The unittests should tell you that.
17:45:05 <peter1138[d]> Of course they don't know where it should be, only that it is missing.
17:45:09 <peter1138[d]> And you know that already 😄
17:45:53 <truebrain> hmmm ... 1 pixel vibrating screen ... pretty ....
17:46:42 <talltyler> We have unit tests for this? 👀
17:46:50 <talltyler> (we have unit tests? 😛 )
17:51:47 <truebrain> peter1138[d]: I just wrote a "I didn't actually move" if-statement to reset your position to destination
17:52:11 <truebrain> open to better ideas, but getting frustrated by this code 😄 😛
17:54:15 <andythenorth> can't enable wall clock on a running game yes?
17:55:55 <truebrain> on the flip-side, the clamping function became a lot easier by using `std::pow` 🙂
17:59:37 <talltyler> andythenorth: Correct
17:59:59 <talltyler> At least until the people who claim it's easy to switch modes and convert things make a PR 😛
18:06:26 <peter1138[d]> Now... why IS wrapping text so expensive 😒
18:11:23 <peter1138[d]> Fairly. The fallback layout is much simpler and doesn't suffer from this issue.
18:11:39 <peter1138[d]> (But this solution works for all "slow" resize events, not just layouting)
18:13:18 <peter1138[d]> And I have one font that absolutely trashes performance. Takes seconds to wrap the Changelog 🙂
18:13:29 <truebrain> tip: don't use that font 😛
18:13:37 <peter1138[d]> And then it did that for each resize step, even the invisible ones.
18:13:53 <peter1138[d]> It's the font I use in VS Code with absolutely no issues 🙂
18:14:02 <peter1138[d]> Although that's not wrapping I guess.
18:14:23 <truebrain> well, the ICU layouter does a poor job caching information
18:14:26 <peter1138[d]> I was 'happy' to reproduce this issue with the default OpenTTD font though 🙂
18:14:27 <truebrain> (as it is difficult to cache)
18:14:38 <truebrain> for example, harfbuzz always wraps around the freetype font for every text it needs to layout
18:14:53 <truebrain> so there are performance gains to be made there
18:20:48 <peter1138[d]> There's an h in that word.
18:21:42 <truebrain> correct, there is an h in `that`
18:22:58 <peter1138[d]> #11895 might be better if there was an explicit "initialize the layout" function call
18:23:16 <peter1138[d]> Then it wouldn't need to dance about with isocode.
18:24:06 <peter1138[d]> And there is already a Factory class.
18:24:17 <talltyler> Is there a way to constrain the maximum width of a widget, to make the spacer more aestetic?
18:25:10 <peter1138[d]> I recommend aesthetics.
18:25:32 <peter1138[d]> You will need to make the other buttons resize.
18:25:58 <peter1138[d]> And in that case, make the spacers NOT resize.
18:28:16 <peter1138[d]> Hmm, the layoutfactory classes are weird. They are standalone, not deriving from any other class, and access is determined by #ifdefs
18:34:44 <rau117> DefinitelyNotRau117v: like this (=
18:35:15 <peter1138[d]> Hmm, to be fair, I suppose the second spacer isn't really needed if the window is not expanded too.
18:37:08 <peter1138[d]> Oh, Win32 and MacOS already have layout initialization, just it's hidden away.
18:37:27 <rau117> Perhaps it is not needed in general? Separation is required specifically for subgroups of block/path signals. But density selector conversion itself stands out due to different icons
18:41:22 <wensimehrp> rau117: hehe Chinese use "信号" even after latinization it's still "Xinhao"
18:41:43 <peter1138[d]> xarick: Convert to uint32_t before multiplying...
18:42:23 <xarick> just wondering if I can copy from his code
18:42:41 <_jgr_> xarick: I don't see that I have done
18:42:44 <xarick> think he found more places
18:43:36 <truebrain> talltyler: anything else needs doing for a beta? 🙂
18:44:20 <truebrain> not something I can help with
18:45:24 <talltyler> So I am curious what users will think of it. And best way to find out .. is to just merge it :) Curious if other developers have a (strong) opinion one way or the other :)
18:45:24 <talltyler> Since then, it appeared no developers had a strong opinion one way or the other. 🤷
18:45:47 <talltyler> So, no pressure to help, but you asked what needs doing before a beta, and that PR is the answer 😉
18:45:50 <_jgr_> xarick: There is only one place that needs fixing, you don't need to look through my branch for it
18:46:13 <truebrain> talltyler: No pressure felt; but if that is all, nothing I can do 🙂 So I will do some other beta preparations 🙂
18:48:39 <truebrain> hmm ... making the changelog text will be tricky ... with this many backports that are done
18:48:42 <truebrain> owh well, that is for another day
18:48:58 <truebrain> but we should work towards a beta relatively soon, if we want to do a normal scheduled release
18:49:09 <truebrain> we are like 2 months late already, but okay
18:49:57 <xarick> I fear for the time features
18:50:14 <truebrain> did I ever write a script to create a changelog? Hmm
18:50:24 <truebrain> I did for backports
18:50:57 <truebrain> if Marvin can leave the chat, that would be appreciated
18:51:09 <truebrain> (referencing HHGTTG)
18:51:32 <truebrain> LordAro: do you remember if we ever scripted making changelogs?
18:53:13 <truebrain> talltyler: optionally, we could go for an RC1 (difference between beta1 and RC1 is basically "feature-freeze or not") instead of a beta1 "soon"
18:54:13 <truebrain> also, title game might need a start soon
18:54:24 <talltyler> I would go for a beta first, because I'm overly optimistic about getting a couple more PRs in first 😛
18:55:07 <talltyler> Specifically autoseparation -- I had a brainwave last night and am working on a simple approach that takes the excellent work in #8342 and makes it bulletproof
18:55:20 <truebrain> just so you know, there has to be a line some day
18:55:25 <truebrain> and there is always this "one more thing" 🙂
18:55:42 <truebrain> but the 4th month is approaching, whether you want to or not 🙂
18:56:08 <talltyler> beta1 now, RC1 at the end of February?
18:56:30 <truebrain> you were going to do this round you said, I am just reminding you you are cutting it close 🙂
18:56:35 <peter1138[d]> End of Feb is quite late.
18:56:57 <peter1138[d]> Save features for the next release, and release earlier/more often 😉
18:57:19 <talltyler> I'm happy to push the buttons this round, but #10606 is preventing me from doing it right now 🙂
18:57:24 <truebrain> peter1138[d]: like we say every year 😛
18:58:06 <truebrain> but if I am being honest, I would say, RC1 next week, and skip the beta
18:58:18 <truebrain> gives us 1 week to finish those feature we REALLY want to have
18:58:23 <talltyler> I wonder if kale91 would be interested in running the title game competition, to avoid the conflict of interest of me also submitting an entry
18:58:41 <truebrain> there is no conflict of interest, and voting is done in public, for everyone to see 🙂
18:58:50 <talltyler> emperorjake: Do you have a title game entry this year? (I think you usually do...?)
18:58:51 <truebrain> but you try your excuse 😛
18:58:58 <talltyler> I've paid my dues 😛
18:59:20 <truebrain> frosch123: am I right to understand you are still looking into the translation thingy with the new time mode? 🙂
18:59:24 <talltyler> truebrain: Sounds good to me
18:59:38 <merni> bah, tabs and trailing spaces
19:00:05 <talltyler> truebrain: Oh right, that is also standing in the way of a release 😬
19:00:09 <frosch123> truebrain: i am done with the first 90%, want to PR it tonight
19:00:17 <merni> now I have to figure out the git blah to edit a previous commit
19:00:33 <truebrain> frosch123: awesome; no rush, was just making sure nobody was like: frosch is doing it, and frosch was like: watching telly 😛
19:01:15 <peter1138[d]> ^ Accidental performance increase ;D
19:01:25 <peter1138[d]> But not massive enough to fix Iosevka.
19:02:25 <truebrain> I think caching harfbuzz instance also gives you a nice increase 😛
19:02:33 <peter1138[d]> It also fixes the memory leaks that someone once said were due to icu...
19:02:51 <truebrain> does it solve when you close OpenTTD it barks all those memleaks? 😄
19:03:19 <xarick> strange, I can't reproduce the bug now... must have been fixed sometime ago
19:03:24 <peter1138[d]> It's because we didn't delete the object we asked it to create. Not icu's fault.
19:04:06 <peter1138[d]> That was the purpose of the PR, not performance 🙂
19:04:58 <peter1138[d]> Okay, so ICURun::Shape() is the one that creates a reference of the font.
19:05:35 <truebrain> I wrote the current layouter to be able to upgrade ICU, as that was .. euh .. becoming a real issue. So very little optimization is done. Time preasure was ... real 😄
19:05:53 <truebrain> just so you look at the code from the right angle 😉
19:08:00 <truebrain> why the hell is grf_layout_icu included in the MacOS build
19:08:20 <Rubidium> I think it'd be better to do at least one beta, so we can fix the first bunch of issues without having to backport them. Followed by a RC a week or two later
19:08:45 <truebrain> Rubidium: You think people test betas? 😄 But that is fair 🙂
19:09:16 <truebrain> I assumed peter1138[d] was able to grep in our code, but it seems not 😄
19:09:34 <truebrain> tnx _jgr_ , for cleanup up after us 🙂
19:09:35 <Rubidium> alternatively... label the first one rc, but only branch at the second one
19:09:36 <peter1138[d]> Is the `: TextfileWindow` on a new line?
19:10:14 <peter1138[d]> No. Wonder why my "grep" skills failed there 😦
19:10:27 <truebrain> not saying you suck, but ... your ability to grep does! 😛 😄 😛
19:10:46 <truebrain> Rubidium: I am fine with a (short) beta first; as long as we don't keep going "one more feature" 😄
19:11:09 <_jgr_> Life would be boring if we didn't make errors
19:11:52 <peter1138[d]> Okay, it's another one where the result is wider than my search view, so I missed it.
19:12:09 <truebrain> "another one" ... so this happens more often?!
19:12:20 *** rain[m]1 has quit IRC (Ping timeout: 480 seconds)
19:13:43 <kale91> talltyler: title game competiton?
19:13:53 <kale91> ohhh I know what you mean
19:14:21 <truebrain> peter1138[d]: `gfx_layout_icu.*` is guarded by `defined(WITH_ICU_I18N) && defined(WITH_HARFBUZZ)`, as a FYI
19:14:27 <kale91> I don't need any more responsibility currently so if someone else could do it I wouldn't be upset
19:18:44 <peter1138[d]> truebrain: Tempted to move it to a function in gfx_layout.cpp where all the existing defines are already there...
19:18:47 <truebrain> so to build a changelog there are a few issues, but not the smallest ... some commits can be in the 13-release branch .. lol
19:19:17 <truebrain> the whole gfx_layout_icu should be called gfx_layout_harfbuzz
19:19:24 <truebrain> as its usage of ICU is .... only the linebreak?
19:19:33 <truebrain> so I can fully see you doing that
19:20:08 <peter1138[d]> icu::ScriptRun too.
19:20:21 <truebrain> and UnicodeString! 😮
19:20:41 <truebrain> but on the other hand, slapping an ifdef around there, is also an easy fix 🙂
19:25:36 <merni> Ok removing the red colour does feel like overkill on further reflection.
19:27:13 <truebrain> I would brand your PR as "infinite money", in which it would make sense to remove the money from the toolbar (it is infinite after all)
19:27:34 <truebrain> you brand it more like "no more bankrupcy", which is also a fine approach, but does mean it should do just that: don't go bankrupt
19:27:44 <merni> At the moment that is all it does :)
19:27:51 <truebrain> "infinite money" is more sandboxy
19:28:00 <truebrain> "no more bankrupcy" .. dunno .. personally, I am not feeling it
19:28:04 <peter1138[d]> Yes, I wouldn't mention bankruptcy.
19:28:13 <peter1138[d]> Which, IIRC, doesn't necessarily trigger?
19:28:40 <merni> Hm if you think the name infinite money is better I am open to that
19:28:56 <merni> I thought it was inaccurate as you don't actually get any more money
19:28:59 <truebrain> it makes things a bit easier .. like removing money from the toolbar makes a lot more sense if you call it like that 🙂
19:29:04 <merni> Just are allowed to rack up debts
19:29:15 <peter1138[d]> Infinite spending 🙂
19:29:39 <truebrain> I wouldn't call it like that btw 😛
19:29:51 <truebrain> "Infinite money" is very clear to all, I would think 🙂
19:30:00 <peter1138[d]> if you were looking to just not care about money... what would you look for.
19:30:07 <merni> The name is secondary anyway, if people feel infinite money is a clear description, I will go with that
19:31:11 <peter1138[d]> Turns out that `strings.cpp` also doesn't use `gfx_layout.h`, but it is a simpler inclusion 🙂
19:31:19 <truebrain> merni: it is not the name on its own, but also the intentions you want to put behind 🙂 You can take this as far as you want 😛
19:31:42 <merni> I am reluctant to always disable the display of the balance when this setting is on, though. I don't know either (1) do people really care about some red number in the corner? (2) is there some use-case which needs the money balance despite having infinite money/spending/whatever?
19:32:00 <merni> truebrain: The intention is just not to be blocked by the game ever due to lack of funds
19:32:24 <truebrain> some visual feedback that such mode is active does wonders; hence my suggestion to hide the money from the toolbar
19:32:31 <truebrain> it is very clear and efficient in bringing that message
19:32:44 <truebrain> "Why is there no money? Ah, yes, I can spend all I want!"
19:32:54 <truebrain> Games like City Skyline etc do exactly that 🙂
19:33:07 <merni> I guess desperate people can still look at the finances window
19:33:35 <truebrain> but there is a fundamental conflict if you want to spend all the money in the world, yet want to see how far in the red you are
19:33:42 <truebrain> those types of gameplays are in conflict with each other
19:34:04 <merni> I thought peter expressed it well:
19:34:04 <merni> > IMHO sandbox money just means you don't want the game to limit what you do because of money. A player might still want to make an cost-effective network at the same time.
19:34:24 <truebrain> yes; but that is money-per-line
19:34:34 <peter1138[d]> Hide total money on the status then.
19:34:47 <peter1138[d]> Or show a comedy value 😄
19:34:48 <truebrain> btw, as far as I am concerned, with this PR, the option from the Sandbox Options can be removed
19:35:14 <peter1138[d]> The "give money" option. Yeah.
19:35:31 <merni> I guess so. Is there anything special that needs to be handled with that for savegames etc?
19:35:32 <peter1138[d]> "But I don't want the AIs to have infinite money!"
19:35:50 <truebrain> you either play sandbox or you don't.
19:35:52 <merni> peter1138[d]: Yeah, I thought about a per-company setting but that would just be far too much work :p
19:35:59 <peter1138[d]> Yeah no, don't do that 🙂
19:36:05 <andythenorth> Can’t we just start with £100m?
19:36:12 <truebrain> Don't give players ALL POSSIBLE OPTIONS, it just ends in a settings nightmare 🙂
19:36:16 <peter1138[d]> If you want that level of control, a GameScript can just hand out money.
19:36:25 <truebrain> always remember we have to support every setting for the next .. 20? years 😛
19:36:34 <merni> merni: ^ regarding removing the money cheat
19:36:47 <truebrain> there is some stuff you need to remove, but you will find out
19:37:01 <merni> oh I will get nice red errors?
19:37:35 <_jgr_> truebrain: With the new savegame format, dropping settings is fairly painless
19:37:53 <truebrain> yeah, I wasn't thinking about savegames writing that 🙂
19:38:04 <truebrain> I remember we had issues with 10 settings being slightly overlapping with each other
19:38:10 <truebrain> so we had to do testing for all combinations of such settings
19:38:14 <truebrain> just a total nightmare
19:38:17 <peter1138[d]> But dropping cheats isn't.
19:38:32 <peter1138[d]> Sorry sandbox...es?
19:38:56 <truebrain> but so yeah, settings that do simple things are good. Settings that allow per company to control whether they have infinite money ... let's not 🙂
19:38:58 <peter1138[d]> Hmm, proposal. Move all sandbox stuff to settings in one go, so the cheat chunk can be dropped?
19:39:10 <truebrain> not all sandbox stuff can be moved to settings
19:39:11 <peter1138[d]> (Give Money doesn't need a setting)
19:39:14 <truebrain> give money, change time, change company
19:39:20 <peter1138[d]> Yes, they don't need a setting at all.
19:39:23 <truebrain> which is the circle we have been walking for months 😄
19:39:44 <truebrain> yeah, this came up more than once, people going: MOVE THEM ALL TO SETTINGS, then find out these 3 are an actual issue
19:39:49 <peter1138[d]> Sorry, by settings I mean in the savegame. Not in the UI.
19:40:19 <truebrain> Not even sure how the toggles are saved
19:40:28 <truebrain> cheats only have also this thing where they track toggled or not
19:40:38 <truebrain> that struct is a bit evil and mean
19:40:40 <peter1138[d]> Yes, but do we care anymore?
19:40:41 <truebrain> we can just drop it totally
19:40:47 <truebrain> not with infinite money
19:40:51 <peter1138[d]> Yes,t hat's my point 🙂
19:41:06 <truebrain> talltyler: did have a point about challenges that use it to see if someone cheated
19:41:12 <truebrain> but having it a setting solves that totally too
19:41:14 <peter1138[d]> Instead of making merni try to figure how to remove 1 cheat, we could just drop them all from that chunk.
19:41:36 <truebrain> I think the toggles are already settings
19:41:50 <xarick> I can't reproduce 10372 any longer, strange
19:42:01 <truebrain> so they would need migrating
19:42:04 <merni> peter1138[d]: that would be nice :)
19:42:20 <peter1138[d]> Either migrating, or cheaters ... sandboxers can set them again. Hmm.
19:42:30 <truebrain> migration is relatively easy ofc
19:42:53 <truebrain> for reference, we still support the TTO "game options" 😛
19:43:06 <peter1138[d]> Hmm, no_jetcrash would be mean to silently disable.
19:43:19 <truebrain> just in the `Load()` function migrate them to settings
19:43:26 <truebrain> nothing more than a few lines of code 🙂
19:43:30 <peter1138[d]> Looks like we added a cheat 3 months ago. What were we thinking.
19:43:43 <truebrain> stupid debates about silly things, mostly
19:44:06 <truebrain> but right, automated changelog is hard
19:45:33 <truebrain> ah, no, GitHub added a nice API endpoint for it .. that is nice 🙂 Let's try!
19:46:45 <peter1138[d]> I did wonder if I could avoid #11903 but forcing some order or construction or something.
19:47:18 <peter1138[d]> Basically... use a separate function to initialize the window and never have constructors do it.
19:47:24 <peter1138[d]> But that looked like a big task.
19:48:34 <peter1138[d]> "OnConstruct()" hee
19:51:33 *** rain[m]1 has joined #openttd
19:58:44 <merni> should this be Feature: instead?
19:59:12 <merni> Oh, I did a trailing space again. Great.
20:00:23 <peter1138[d]> ```dbg: [misc] [hbfont] 305 us [avg: 3.0 us]
20:00:23 <peter1138[d]> dbg: [misc] [hbfont] 295 us [avg: 3.0 us]
20:00:23 <peter1138[d]> dbg: [misc] [hbfont] 236 us [avg: 2.4 us]```
20:00:48 <peter1138[d]> Hmm, that part of harfbuzz doesn't seem to be particularly slow.
20:01:11 <truebrain> as it initializes a hb object every time 😄
20:01:12 <merni> I will look into the money display now
20:01:15 <truebrain> well, good for them 🙂
20:02:24 <peter1138[d]> hb_shape is the slow call, taking ~2.5ms per line with that particular font...
20:08:40 <peter1138[d]> Anyway, all that layouter and textfilewindow stuff was because I wanted to find out if my fractional scaling stuff is leaking memory.
20:08:47 <peter1138[d]> (It is, but it was being swamped by icu)
20:09:03 <xarick> 10490 is maybe not a bug
20:09:19 <peter1138[d]> In testing the icu memleak, I found the textfile window would randomly crash, such fun 😄
20:09:41 <merni> bah, everything has to be rebuilt when adding something to english.txt?
20:09:54 <peter1138[d]> StringIDs get changed.
20:10:05 <truebrain> I had weird crashes with SetDParam and error window, but I can't reproduce it with latest master anymore
20:10:14 <xarick> I don't think I'm gonna deal with a fix for that issue
20:10:47 <truebrain> now I wonder if it is something you did, or just my testing sucks 😄
20:11:46 <peter1138[d]> That uses CopyInDParam, so it is dependent on what previous strings might have used as parameters.
20:12:43 <truebrain> now first I am being surprised by how terrible GitHub GraphQL Explorer is
20:12:48 <truebrain> there are so many that are so much better
20:12:55 <truebrain> this is just horrible
20:14:13 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:15:09 <peter1138[d]> Checking with valgrind again 😄
20:15:23 <xarick> how do you link pull requests to issues?
20:15:32 <peter1138[d]> valgrind warns about something in in ship state.
20:16:17 <merni> xarick: In the PR text, use "Fix #12345" or "Closes #12345"
20:16:20 <merni> Exactly with that spelling
20:16:28 <peter1138[d]> ==2806277== definitely lost: 360 bytes in 4 blocks
20:16:28 <peter1138[d]> ==2806277== indirectly lost: 32 bytes in 1 blocks
20:16:32 <peter1138[d]> That is... better
20:16:40 <truebrain> the music driver for me leaks
20:16:42 <truebrain> never looked into it
20:16:55 <peter1138[d]> Probably depends which one.
20:17:11 <peter1138[d]> ==2806277== total heap usage: 3,032,858 allocs, 3,021,888 frees, 2,178,621,573 bytes allocated
20:17:45 <peter1138[d]> So line wrapping text is really slow with valgrind. So it's probably doing a lot of memory allocating.
20:18:01 <truebrain> so stupid GraphQL .. in a commit, I request `associatedPullRequests` .. and it just returns the latest PR that hit the master branch. Not useful
20:21:18 <truebrain> how many pushes per minute do you produce? 😛
20:21:29 <merni> The last was a rebase :p
20:21:48 <peter1138[d]> It is making the CI kinda busy.
20:22:07 <frosch123> is that savegame-version bump needed?
20:22:46 <truebrain> some people try to recycle SLVs, others just change it without using it 😄
20:23:05 <frosch123> are there docs about it? :p
20:23:18 <merni> > To allow the opposite (load old games using your build), you'll have tell OpenTTD that you've introduced a new feature, and increase the savegame version.
20:23:28 <merni> That made me think it was necessary
20:24:01 <frosch123> ah yes, someone should delete the "Archive" cruft
20:24:21 <merni> so, it's not necessary?
20:24:55 <merni> in that case do I just omit the `from` in the ini file?
20:25:19 <merni> Anyway that is for tomorrow, it is very very late
20:26:52 <peter1138[d]> ==2806705== Uninitialised value was created by a stack allocation
20:26:52 <peter1138[d]> ==2806705== at 0x6B17C0: NPFShipCheckReverse(Ship const*, Trackdir*) (src/pathfinder/npf/npf.cpp:1213)
20:27:50 <talltyler> That one has been bothering me for a while 😄
20:31:20 <peter1138[d]> I think "not owner" is a "typo" and actually means "not a refit order"
20:32:16 <peter1138[d]> It is meant to be a disabled widget that you can't press because it's not a refit order. But then, why doesn't it just show a disabled dropdown... hmm
20:32:45 <peter1138[d]> We do generally disable buttons when they're not pressable instead of hiding them.
20:33:29 <frosch123> iirc one of the buttons is for station refitting, the other for depot refitting
20:33:46 <talltyler> The Full Load button becomes the refit button that gets used in the depot
20:34:05 <talltyler> It is disabled when `(v->owner == _local_company)`, which matches the documentation
20:34:21 <talltyler> Uh, no, that's the opposite of the documentation
20:34:31 <talltyler> Which is even worse, but not what you said either 😉
20:34:54 <peter1138[d]> I did include an "I think" in both :p
20:36:52 <frosch123> talltyler: the "owner" check is just a complicated way to check whether "WID_O_EMPTY" exists in the layout
20:37:02 <frosch123> you could do GetWidget() != nullptr instead
20:38:02 <peter1138[d]> That could predate the nested array system, before that it was a direct access into the widget array and would always exist... albeit potentially a different widget.
20:38:48 <frosch123> is it ok to remove the SetFull?
20:39:28 <frosch123> otherwise it looks good. esp because it removes that weird "owner" comment :p
20:40:48 <peter1138[d]> As it's part of a selection widget it should probably match the other widgets settings.
20:41:33 <talltyler> The EndContainer() is correct, though?
20:43:03 <peter1138[d]> WWT_PANELs are containers, so they need to be closed.
20:48:43 <_glx_> at least we have a check for that now
20:54:00 <truebrain> pff, fetching 1876 commits from GitHub API .. this is going to take a while 😄
20:55:23 <truebrain> lol .. sometimes GitHub can't tell what PR dragged in a commit .. lovely 😄
20:55:57 <_glx_> dependes on squash vs rebase ?
20:56:13 <truebrain> no .. rebases I can lookup fine
20:56:32 <truebrain> It is a bit of a weird commit; very different from others
20:57:13 <truebrain> just 2 that are like: nah bro, I'm good
21:03:32 *** Wormnest has joined #openttd
21:03:53 <truebrain> too bad we suck at writing commit messages, so hard to sort the shit from the good 🙂
21:04:08 <truebrain> managed to prune the list down to 666 entries by automation
21:04:12 <truebrain> rest ... is manual work I am fraid
21:06:08 <truebrain> but, already did a lot of things for us .. like sorting, and clean up the string
21:07:47 <truebrain> and mostly, adding the PR number
21:07:56 <truebrain> that mostly always takes such a long time
21:10:59 <truebrain> maybe we should start a label "no-changelog" for PRs 😛
21:13:33 <truebrain> I see plenty of entries we should remove; but wondering if we can automate it a bit more
21:14:09 <truebrain> `Fix: Virtual call from constructor (#10317)` .. like ... yeah .... 😛
21:14:20 <truebrain> could I ask an LLM: is this a technical change? 😄
21:15:00 <xarick> I remember trying some years ago something similar to #10787 and there was a conflict with autosave + saving for someone joining the server. I don't remember details, but one of the saves would stall
21:16:17 <xarick> when autosave was in progress, I don't think anyone could join the server? or ... hmm let me dig my old code
21:18:27 <truebrain> hmm. CUDA support seems gone from my WSL, so LLMs are a bit slow
21:19:59 <xarick> the a) part, the rest you can ignore
21:20:58 <truebrain> no, LLM things all our statements are very technical .. as most are. But a different kind of technical 😄
21:23:08 <_glx_> oh actually #11892 could be done differently
21:53:37 <xarick> Script API has their own defined constants
21:55:09 <_glx_> some functions use non API ones for validation (like ScriptAirport::IsHangarTile() and many other there)
21:55:48 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:56:26 <_glx_> though in this case an API function doing exactly the same thing exists
21:57:22 <xarick> guess it doesn't hurt...
21:58:25 <_glx_> anyway I'm not a fan of putting all the values from the enum in a switch when a simple `return value < XXX_END;` can do the same
22:13:05 <xarick> technically wrong, but fine...
22:15:24 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:16:36 <xarick> those UINT32_MAX are actually returned as -1
22:16:44 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:17:11 <xarick> something squirrel Return do a conversion to int32
22:17:56 *** asymptotically2 has quit IRC (Remote host closed the connection)
22:18:05 *** asymptotically2 has joined #openttd
22:18:05 <_glx_> yeah unsigned max is signed -1
22:19:27 <_glx_> in 8bit world for example 0xFF can be 255 or -1 depending of unsigned or not
22:20:27 <locosage> how is nml dealing with signed/unsigned types btw?
22:20:36 <talltyler> How do I read and write to `Order->flags`? It seems like there should be free space, but I'm crashing with access violation errors and suspect I'm using `GB()` and `SB()` incorrectly
22:20:43 <_glx_> not very well, it's python 🙂
22:20:57 <locosage> I know there are different operations on nfo for signed and unsigned
22:20:58 <talltyler> I am trying to add a new flag for autoseparation behavior when leaving a depot
22:21:12 <locosage> but in nml its seems to be one type
22:27:27 <_glx_> seems Order->flags use accessors
22:28:48 <_glx_> yes and that's perfectly fine
22:29:31 *** tabytac has quit IRC (Quit: User went offline on Discord a while ago)
22:29:39 <_glx_> -1 is the usual error value
22:30:06 <_glx_> squirrel only knows integers
22:30:19 *** Wormnest has joined #openttd
22:30:52 <_jgr_> talltyler: This seems to imply that it only works when dispatching out of a depot?
22:32:12 <talltyler> _jgr_: Correct. The usual stumbling block for autoseparation PRs seems to be logjams when trying to delay/unbunch vehicles. Last night I realized the wormhole dimension is the perfect place to delay vehicles without interference.
22:32:34 <talltyler> I started with #8342 and used about half the code
22:33:02 <_glx_> flags bits have different meaning depending on order type
22:33:13 <talltyler> I don't think it will need such a complex unbunching algorithm, but as I crash the game when opening vehicle orders, I haven't had a chance to test yet 😉
22:34:00 <talltyler> _glx_: Right. I am trying to use the bit above `(OrderDepotActionFlags)GB(this->flags, 4, 3);`
22:35:11 <_glx_> I hate this variable being named "flags"
22:35:46 <_glx_> intellisense doesn't work very well when asking "find references"
22:36:48 <_glx_> and searching this->flags is not better
22:37:10 <talltyler> Yeah. Lots of things have `flags` 😦
22:37:17 <xarick> they're OrderFlags I think let me check
22:38:09 <_glx_> inline void SetTravelTimetabled(bool timetabled) { if (!this->IsType(OT_CONDITIONAL)) SB(this->flags, 7, 1, timetabled ? 1 : 0); }
22:39:40 <talltyler> Bit 3 seems to be used for a waiting time
22:39:46 <talltyler> Which is not implemented for depots
22:40:39 <_jgr_> You can just add more field to struct Order if you want
22:40:52 <talltyler> That might be best...
22:42:57 <peter1138[d]> It is... somewhat overloaded.
22:43:20 <xarick> it's like looking at the map array
22:43:25 <peter1138[d]> _glx_: vs code works fine looking for references of order flags.
22:43:34 <wensimehrp> This server used day length factor and the displayed played time is not correct. Are there any ways to fix this?
22:43:58 <peter1138[d]> Multiply it in your head.
22:44:05 <_glx_> VS gives me every "flags" it can find, even from windows headers
22:44:19 <peter1138[d]> That isn't... references, that's just searching by name 😮
22:44:36 <_jgr_> wensimehrp: The next release of my branch will report the played time directly
22:45:08 <truebrain> _jgr_: lol, sorry, I did not expect people would complain that a new version of vanilla reports a server of JGRPP "wrong" 😛
22:45:12 <_glx_> it can't know without an update
22:45:30 <_jgr_> truebrain: I'm not worried about it
22:45:41 <truebrain> it is surprising; not even the first person to mention it 🙂
22:46:02 <xarick> how many tiles in such map size....
22:46:28 <talltyler> It's a `EXCEPTION_ACCESS_VIOLATION` crash -- that wouldn't come from trying to read a bit that is already used, right?
22:46:50 <wensimehrp> xarick: and the map is like somewhere near 50mb
22:46:57 <_glx_> trying to read from nullptr
22:47:24 <xarick> gonna create a list and store it 😛
22:47:57 <xarick> and then make a savegame
22:48:28 <talltyler> Huh, I have no idea what do with that
22:48:36 <_jgr_> Have you got a stacktrace?
22:49:08 <talltyler> `Order::GetDepotAutoseparationType + 20`
22:49:19 <talltyler> What is the `+ 20` on the end, by the way?
22:49:27 <_jgr_> That's the offset from the start of the function
22:49:30 <peter1138[d]> Stacktrace is the whole thing, not just one line 🙂
22:49:54 <_glx_> if you have a dmp you can open it
22:50:27 <_jgr_> Line 960 of src/order_gui.cpp in the branch you posted looks wrong
22:52:18 <_glx_> const Order *order = this->vehicle->GetOrder(sel); <-- I think this is wrong if no order is selected
22:52:38 <_glx_> so accessing order after that...
22:52:42 <_jgr_> order is just nullptr, there are tests for that further down
22:53:15 <_glx_> line 960 is before the tests
22:53:54 <talltyler> Ah, 960 is definitely wrong
22:54:40 <talltyler> Should check for the existance of that widget? It only appears when a depot order is selected
22:55:34 <_glx_> well look at the big switch
22:56:17 <xarick> `this->SetWidgetLoweredState(WID_O_AUTOMATIC_SEPARATION, order != nullptr && order->GetDepotAutoseparationType() == ODASF_SEPARATE);` just a guess
22:56:25 <_glx_> it manages different widgets depending on airport type
22:57:20 <talltyler> ```if (GetWidget<OrderWidgets>(WID_O_AUTOMATIC_SEPARATION) != nullptr) this->SetWidgetLoweredState(WID_O_AUTOMATIC_SEPARATION, order->GetDepotAutoseparationType() == ODASF_SEPARATE);```
22:57:36 <locosage> lol, apparently automatic track type conversion was in the very first ttdpatch version
22:57:43 <locosage> still no solution in openttd :P
22:58:05 <talltyler> Heh, can't GetWidget like that...
22:59:17 <xarick> somewhere in case OT_GOTO_DEPOT:
22:59:29 <peter1138[d]> It wants a widget type, e.g. NWidgetBase
22:59:45 <xarick> move code to there, if I'm reading it correctly
23:00:13 <_glx_> yeah just put handling of the widget where it matters
23:01:44 <talltyler> Well, that did not work
23:02:07 <talltyler> `GetWidget != nullptr` I mean
23:02:18 <xarick> the widget expert is probably peter1138
23:02:35 <talltyler> Next step is commenting out that line and seeing if it still crashes
23:02:40 <peter1138[d]> Why do you think the widget might not exist?
23:03:01 <talltyler> ...does object permanence not apply to widgets? If we can't see it, it doesn't exist?
23:03:08 <talltyler> Oh, these ones might exist but be hidden
23:03:30 <_jgr_> There is more than one window definition for that window
23:03:30 <peter1138[d]> Hidden widgets still exist, yes.
23:04:04 <peter1138[d]> If it's from a different WindowDesc (well, NWidgetPart list) then it could not exist, yes.
23:04:45 <_jgr_> You'll probably need to add your new button to the two main ones (train and non-train), and handle it being missing from the third one (other company view)
23:04:56 <_glx_> `case OT_GOTO_DEPOT` handles the plane
23:06:00 <_glx_> and there are train/road and aircraft/ships
23:06:01 <talltyler> this->SetWidgetLoweredState(WID_O_AUTOMATIC_SEPARATION, order != nullptr && order->IsType(OT_GOTO_DEPOT) && order->GetDepotAutoseparationType() == ODASF_SEPARATE);
23:06:25 <xarick> I'm not sure that's the correct way to fix it, it was just a suggestion
23:07:01 <xarick> oh, I see, you added the type
23:07:25 <_glx_> but it really should work in the switch
23:07:59 <talltyler> Oh I finally understand what you're saying
23:08:24 <truebrain> wow frosch123 , that is .. a lot more than I expected 😄 (not a bad thing, just .. I can understand why the TKM was tempting 😄 )
23:09:10 <frosch123> yep, TKM made some thing easy, others not 🙂
23:09:50 <truebrain> I can understand this took a bit of time 🙂
23:11:26 <talltyler> Dinnertime, will be back to this tomorrow. It doesn't crash, but it doesn't work either 😉
23:11:41 <talltyler> Thank you frosch123 for cleaning up behind me ❤️
23:15:51 <frosch123> heh, who added black to eints?
23:16:04 <frosch123> that check wasn't there last week
23:16:57 <truebrain> no, you didn't rebase last week
23:16:59 <truebrain> there is a difference 😛
23:17:18 <truebrain> it got added 7 months ago 🙂
23:17:36 <_glx_> yeah we put black in all our python repos
23:18:00 <truebrain> it is now a single workflow stored in a single repo, that ALLLLL Python repos use
23:18:04 <truebrain> so much less maintenance burden
23:18:31 <frosch123> my PR is up-to-date
23:19:26 <frosch123> i don't think anyone ever ran black on eints, so the action probably also fails on main
23:19:40 <truebrain> 3 weeks ago it ran fine
23:20:04 <truebrain> more likely is that black had a new version, and now has some opinion different 🙂
23:20:20 <truebrain> but okay, you asked "who added". But I see you meant: my black now fails, WHY?! 😛
23:20:31 <truebrain> yeah, black is upgrade van v23 to v24
23:21:13 <_glx_> yeah black upgrades usually means source needs some fixing
23:21:43 <truebrain> but tnx for assuming we are not compitent frosch123 😛 😛
23:22:03 <_glx_> oh nice you tested the unused-string workflow 🙂
23:23:08 <truebrain> frosch123: btw, 4 days ago your PR, ZWSP, passed black. So it is really recent 😉
23:23:34 <_glx_> a lot of dependabot activity yesterday 😉
23:23:36 <frosch123> yes, that's what I remembered
23:23:41 <frosch123> so I was confused why it broke now
23:23:48 <truebrain> and you started to blame us! 😛
23:24:01 <truebrain> curious what in the codebase of eints makes it trigger
23:24:03 <peter1138[d]> Hmm, should "Highest resolution sprites to use" apply to svg sprites? hehe
23:24:06 <truebrain> most of the other projects seem fine
23:24:24 <_zephyris> peter1138[d]: Hah, yes, but I like the ridiculousness.
23:24:42 <truebrain> but not curious enough to actually check; time to get some zzzs
23:25:06 <frosch123> truebrain: yes, "everyone, but me"
23:25:51 <truebrain> also, eints needs node16 love
23:26:03 <truebrain> as .... why not! stupid GitHub runners ..........
23:30:12 <kuhnovic> _zephyris: Thanks a lot for bringing your Ekranoplan newgrf back to life, that was really helpful
23:33:08 <_zephyris> kuhnovic: No worries! I wasn't very motivated to do the final polish on it when the vehicle speeds were so far from reality. With higher speeds, accel and new sea vs. canal/river speeds it feels like a more polished newgrf.
23:33:43 <kuhnovic> And don't forget a new ship pathfinder 😇
23:35:09 <kuhnovic> Btw, it's hilarious to give that high acc ship a destination is can't reach. The new pathfinder will assign it a random path, and it just moves all over the place like a drunk fly.
23:36:30 *** Flygon has quit IRC (Read error: Connection reset by peer)
23:38:41 <peter1138[d]> Hmm, right, I broke min/max zoom level didn't I.
23:44:30 <frosch123> black wants many new-lines 🙂
23:51:36 <truebrain> frosch123: Haha, lol. It is not wrong btw, but that explains the volume of files 😛
23:54:25 <frosch123> uh, what does the annotations check want from me?
23:54:44 <_glx_> it wants us to upgrade the workflows
23:55:19 <_glx_> I can use my super power to ignore it 🙂
23:56:41 <frosch123> well, if you know what it means, use it 🙂
23:57:28 <truebrain> _glx_: Or, you could fix the issue 😉
23:57:34 <truebrain> This just leads to more issues
23:57:56 <_glx_> hmm first step would be a dependabot PR I guess
23:58:14 <truebrain> Yup. And that one you need to admin power 😛
23:58:58 <_glx_> ok let see how you did it on other repos 🙂
continue to next day ⏵
