IRC logs for #openttd on OFTC at 2024-03-09
⏴ go to previous day
00:00:22 *** Leopold has quit IRC (Remote host closed the connection)
00:01:48 *** Leopold_ has joined #openttd
00:05:44 *** andythenorth[m] has quit IRC (Quit: Client limit exceeded: 20000)
00:48:34 *** Leopold_ has joined #openttd
01:20:21 <xertov> shouldnt it be 12 months
01:20:59 <xertov> STR_NEWS_EXCLUSIVE_RIGHTS_DESCRIPTION_MINUTES is the name of the string but i ve never heard it being for 12 minutes it sounds wrong
01:27:51 <Eddi|zuHause> we now have a setting to decouple the calendar progress from the economy grogress
01:28:53 <Eddi|zuHause> and roughly 1 original month = 1 real time minute
01:55:32 <wensimehrp> Could someone please tell me what is transfer credits?
01:57:15 <Eddi|zuHause> when you use transfer orders, or enable cargo distribution, money only arrives on your bank account at the final destination. but for accounting purposes, transfer credits are added to vehicles making partial trips
01:57:42 <Eddi|zuHause> it's not real money, just there so intermediate vehicles don
01:57:49 <Eddi|zuHause> 't run at a loss
02:00:47 <_glx_> final leg can make a huge loss if previous transfer were too high
02:02:20 *** gelignite has quit IRC (Quit: Stay safe!)
02:14:22 <wensimehrp> Ah so they are fake numbers that only shows on vechicle stats.
02:14:22 <wensimehrp> I'll change the translation then, the current translation is wrong.
02:14:22 <wensimehrp> Also, what does "leg" mean?
02:14:35 <wensimehrp> (might be stupid to ask)
02:30:50 <emperorjake> Each time a cargo transfers to a different vehicle can be referred to as a new "leg" of a journey
02:40:29 *** Wormnest has quit IRC (Quit: Leaving)
03:43:14 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:45:01 *** gnu_jj_ has joined #openttd
03:48:12 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:41:27 <DorpsGek> - Update: Translations from eints (by translators)
07:07:39 <andythenorth> can we just connect eints to GPT?
07:07:55 <andythenorth> or do we like the community-building aspect of eints? 😛
07:08:40 <kamnet> I've never noticed this until just now. The name of my oldest NewGRF is mangled in Bananas because the length limit. Very frustrating. 😦
07:26:48 <peter1138> andythenorth: I like the "built by an actual human" aspect of eints.
07:32:53 <andythenorth> if I could get grfs from GPT
07:33:02 <andythenorth> that might be better for everyone
07:33:29 <andythenorth> by "GPT" I mean "generally magical", not specifically GPT
07:48:21 *** HerzogDeXtEr has joined #openttd
07:48:57 <andythenorth> not yet though 😛
07:49:07 <reldred> it's far too hot here to leave the house
07:56:05 *** gelignite has joined #openttd
07:58:15 <kamnet> reldred: Is it bake an egg on the tarmac hot?
07:58:36 <kamnet> dashboard cookie baking hot?
08:03:16 <reldred> eh, was only around 40°C
08:04:11 *** Extrems has joined #openttd
08:10:11 <kamnet> So not even halfway to hell. Not horrible. 🙂
08:10:52 <reldred> Oh it certainly isn't pleasant. If the UK saw these temperatures people would be dying on the sidewalk.
08:11:16 <reldred> This summer so-far has been relatively tame, though March always brings out a few last minute surprises.
08:38:18 <andythenorth> Did peter1138 go out? 😛
08:38:36 <andythenorth> I need 3cc for London tube trains 😛
08:46:00 <truebrain> peter1138: Huh? Indeed .. compiler bug?
09:19:43 <jfs> And now after reading that sausage making post again, one remaining common question strikes me: "why can't you just add X feature from jgrpp?"
09:20:12 <jfs> But that would likely also have extended the post much further to try to answer that
09:27:10 <reldred> I think it would be good to see a explanation of exactly why a particular feature may be cash money in JGRPP but not really 'suitable' for OpenTTD. It's something that I've kinda grown to accept more as years go on and kinda implicitly understand why these days, but I think it's a subject some folks would like to see expanded upon.
09:29:08 <michi_cc> jfs: Well, the practical answer is already given: "It is not included yet because nobody volunteered their time for it."
09:29:49 <michi_cc> IMHO there are a lot of features from JGRPP that I'd like very much conceptually, but need work to make them more accessible and discoverable.
09:30:16 <andythenorth> I have 2 observations 😛
09:30:17 <bendn> truebrain: i think compiler bug should be the last response, not the first 😅
09:30:33 <andythenorth> one theme is that JGRPP often says "this is not suitable for vanilla"
09:30:50 <michi_cc> reldred: Unless you've made a PR that was rejected, there is no JGRPP feature that is not suitable.
09:31:42 <michi_cc> Not every feature might be suitable straight up, but that comes back again to the time thingy.
09:32:16 <reldred> michi_cc: Hmm, perhaps I didn't word it correctly, probably that some of the features *as they're currently implemented* aren't suitable. The acceptable level of complexity is higher in JGRPP and that shows in how some features are implemented.
09:32:29 <reldred> OpenTTD proper needs to be a lot more polished, and approachable.
09:32:38 <truebrain> bendn: We have sufficient of experience and different compilers we work with that it won't be the first , let alone the last, compiler bug we find (and report and get fixed) .. and given the information, it is not as wild of a guess as you might think
09:33:39 <reldred> And no, I've buried the hatchet. I know I threw a lot of shade about PR's not being reviewed in a timely fashion but that's long since been resolved, but yes again comes back to the time thing
09:35:39 <andythenorth> my JGRPP experience is pretty limited, but I would guess it would be easy for people to make pet pony lists of JGRPP features
09:35:55 <andythenorth> would they cohere though? 😛
09:45:17 <Rubidium> truebrain: I think bendn is technically correct; the error message seems to be coming from cppcheck, not the actual compiler. I would consider the default member initializer being missed a bug in cppcheck though
09:47:14 <_zephyris> andythenorth: A git discussion with separate sections people can up/down vote on would be great. Like 2TT's default settings one.
10:04:30 <_jgr_> _zephyris: People will vote yes for headline features even if they wouldn't fit or aren't actually implementable
10:05:47 <_jgr_> Stunning like that could lead to problems with managing expectations
10:07:36 <truebrain> Rubidium: Splitting hairs now? 😄
10:09:16 <_zephyris> _jgr_: Depends how you ask the question - but expectation management in the description would be key
10:18:32 <truebrain> michi_cc: although I fully understand those goals, personally I never felt that attached to it. Sounds like very dull to me, with little possibility for more innovation. And yeah, looking at 14.0, it seems more developers think like that 😛
10:29:08 <truebrain> owh, lol, yes, 12242 is only possible after upgrading to macos-14 😄 I forgot 😛
10:34:09 <truebrain> and ofc something totally unrelated to what I am doing broke 😛
10:34:32 <Rubidium> I would've just made one PR with three commits and not squashed it upon merging
10:37:31 <xarick> Maximum number of non-sticky windows, isn't disabled supposed to be unlimited?
10:38:04 <andythenorth> Goals were goals, they could change
10:38:19 <andythenorth> They were mostly from frosch iirc
10:41:51 <truebrain> Rubidium: ghehehe 😄
10:44:31 <truebrain> okay .. so `dump_syms` fails to compile when installing via `cargo install`, but works fine if I do a git clone and build it
10:50:47 *** SigHunter has joined #openttd
10:55:19 <frosch123> all the news posts gave fresh content for AI generated spam mails
10:55:28 <frosch123> do we have a "Holger" on the team?
10:59:53 <truebrain> Rubidium: anyway, reason I make separate PRs out of it, as I need to make a release on my own fork for them, to see if it works. Doing everything at once means I might be looking at equal amount of bugs 😛 This just makes it easier to see which commit works, and which doesn't
11:00:03 <truebrain> tldr: maintaining this shit is a nightmare 😛
11:00:13 <truebrain> and a lot of waiting ... 😄
11:04:29 <truebrain> frosch123: what I found more amuzing, is that mister o got added to the Teams channel in Microsoft for the signing stuff 🙂
11:04:45 <truebrain> they are actually using their own product internally .. I wouldn't have guessed that, given the state of the product 😛
11:08:12 *** SigHunter_ has joined #openttd
11:12:49 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
11:13:23 <frosch123> what can i say, i am working for a corporation who does not use teams, because it considers it a competitor
11:14:02 *** gelignite has quit IRC (Quit: Stay safe!)
11:14:12 <frosch123> and every developer thinks... what? since when do we compete with that
11:29:46 <frosch123> i guess it started with the feature that users could comment on the work/stuff created by other users of the product. then someone patched on the inverse: something forum-like where you could attach the work/stuff to. then someone patched on something instant-messaging like. and then someone patched on voice calls.
11:30:24 <frosch123> i guess every step makes sonse on their own. but the patch-on-patch-on-patch only makes sense in context of the original product, and not as a product on its own
11:41:09 <truebrain> Owh, is working on IRC .. so Discord is being silly 🙂
11:41:37 <truebrain> frosch123: Sounds like all software that exists 😛 OpenTTD is also patch on patch on patch 😄
11:42:56 <truebrain> Owh, all Discord webhooks are not working .. lol
11:47:59 <kuhnovic> How do we feel about introducing the ability for ships to turn around whenever they want (with the right penalty to discourage this as much as possible)? The reason I'm asking is that ships in long canals have no way to turn around at the moment. This means they have to sometimes take massive detours to turn around, where "doing an Ever Given" by ramming it into the riverbank would allow the ship
11:47:59 <kuhnovic> to reverse. For example, and I know this is exagerrated, this ship has to go all the way to the end of the yellow line to turn around if it had to:
11:50:30 <truebrain> if it is just to avoid ships making huge detours, to me that sounds more like a player-issue than something the game should allow
11:50:39 <truebrain> you could argue the same why trains can't just reverse
11:50:47 <truebrain> (with an identical setup 😄 )
11:51:22 <kuhnovic> I had the same thought, and the same can be said for road vehicles. But then again, ships are not bound to any roads / rail...
11:51:51 <truebrain> they kinda are if you make layouts like yours 🙂
11:52:13 <truebrain> there needs to be some game in this game 😄 Can't make it stupidly simple for everyone 😛 😄
11:52:35 <kuhnovic> It's not that, it's more about fixing a pathfinder edge case that bugs me 😛
11:52:47 <truebrain> guess you asked the wrong question 😛
11:54:21 <kuhnovic> Well I do want to stay true to the original gameplay somewhat, I don't want to change everything just for the sake of fixing a bug. Just testing the waters here (pun intended)
11:59:12 <truebrain> sometimes you find these rare gems on the Internet. On https://www.mediawiki.org/wiki/Alternative_parsers, it notes: `many alternative parsers exist, almost no unofficial parser powers any wiki site, except for wikitextparser which powers the OpenTTD wiki through TrueWiki. `
11:59:34 <truebrain> in other words: nobody is crazy enough to build their own wiki server which supports mediawiki .. owh wait, there is one
12:16:44 <frosch123> lol, you should print that and put it on the wall of your bathroom
12:17:43 <truebrain> so I can shit on it? Or what is the link with the bathroom?
12:18:16 <frosch123> oh, just noticed... they deny the existence of gollum
12:18:49 <truebrain> gollum doesn't do mediawiki pages, does it?
12:19:02 <frosch123> i don't know... things you are proud of, you put over your bed. things which are funny, you put next to the toilet
12:19:31 <truebrain> ah, Gollum supports mediawiki via wikicloth
12:19:36 <truebrain> so yeah, they deny that existance 😛
12:19:45 <frosch123> truebrain: it does, that's what we started with, and then you decided its easier to write your own
12:20:37 <truebrain> meh; I wish it was easier to filter the pull request list
12:20:46 <truebrain> so many PRs I don't care about, but I can't filter them out 😦
12:47:48 <truebrain> Sorry Rubidium; but just now that the CI actually started to do my PR, I noticed a mistake 🙂
12:47:55 <truebrain> the CI queue is huge, sadly .. so this will take a while
12:49:51 <truebrain> hmm .. Discord webhook is giving a 403 .. that is not good
13:03:50 <truebrain> seems to be Cloudflare that no longer likes us 😄
13:05:12 <truebrain> ugh, this huge CI queue is annoying as fuck
13:05:51 <truebrain> happens when someone decide to update 15 PRs, all at once .. useful, etc
13:06:24 <Rubidium> ... especially when they do not have a conflict :(
13:06:48 <truebrain> or have any feedback, comments, reason-to-update
13:06:54 <truebrain> owh well ... guess we will sit on our ass instead 🙂
13:08:49 <truebrain> what I always forget, that the limit is per organisation
13:08:58 <truebrain> so my attempt to fix DorpsGek is also queued 😄
13:09:03 <truebrain> I understand why GitHub did that 🙂
13:09:39 <michi_cc> You mean we should hit cancel on all those PR actions? 😛
13:09:55 <truebrain> but that would make me the "bad guy" once again
13:10:37 <truebrain> GitHub does have the right attitude towards first-time contributors, where CI is not automatically started for them
13:10:41 <truebrain> sadly, that only works once 😛
13:20:50 <truebrain> I wonder if I can build the arm64 docker images for most of our software on the macos-14 .. as that is native arm64 .. might be a lot quicker than the qemu builds we currently do
13:38:39 <michi_cc> Well, I guess you need to exercise the CI even more. Apparently black said no to DorpsGek.
13:38:51 <truebrain> first waiting for my preview to be
13:38:55 <truebrain> don't want to be back in the queue AGAIN
13:39:08 <truebrain> CI is almost caught up, so there is that
13:39:36 <truebrain> that is a lot (to me)
13:39:42 <peter1138> That is a lot to me.
13:40:10 <truebrain> doing 5km is already like "PFFFFFF, that is far"
13:41:01 <truebrain> hmm .. okay, that does not fix DorpsGek
13:44:22 <truebrain> I guess the issue might be that I am forwarding it via a Cloudflare Worker ... but stupid Discord still doesn't support IPv6 😦
13:46:04 <peter1138> Oof legs are tingling
13:46:26 <peter1138> Also I need to lose weight, I get dropped going up hills 😦
13:55:11 <truebrain> okay, the error we get back is `"{\"message\": \"internal network error\", \"code\": 40333}"`
13:55:28 <truebrain> but it basically means we are blocked for one reason or another
13:56:02 <truebrain> if I would guess, it is because the Cloudflare Worker IP is blocked (it is a single IP for all workers, if I understand it correctly)
13:59:48 <truebrain> right; I have to go for the rest of the day. I doubt the GitHub messages on Discord will recover on their own. I have some ideas how to fix it, but that will be tomorrow 🙂
13:59:50 <peter1139> Well, back to IRC then right?
14:02:52 <Rubidium> truebrain: could some magic be done for #12244 to circumvent the commit message checker upon a squash?
14:03:29 <truebrain> why? Isn't it easier to just type `git commit --amend` and fix it?
14:04:03 <truebrain> Sadly, we can't hook into GitHub at the moment of merging, to validate if the commit message is valid; that would be ideal 😄
14:05:56 *** DorpsGek has joined #openttd
14:05:56 *** ChanServ sets mode: +o DorpsGek
14:05:59 <truebrain> so fix it in the upstream branch? 😄
14:07:35 <peter1139> So `-Weffc++` seems to want explicit constructor member initialisation, even for things like std::string members.
14:08:06 <peter1139> It barfs on fmt/format.h so I can't even check the rest of our code :D
14:08:22 <truebrain> it is not a bad thing, to be explicit about these things; but given our code base ... good luck! 😛
14:13:13 <peter1139> Yeah, I would totally do it on our code, but things in 3rdparty is a bit different.
14:13:31 <truebrain> with CMake you can have different rules for different folders
14:13:51 <_glx_> he it would be the perfect moment if we had to move some issues to discussions 😉
14:14:20 <truebrain> not for IRC people 🙂
14:14:28 <peter1139> Maybe but it's included everywhere, so I'm not sure.
14:14:36 <truebrain> but even without the spam on Discord / IRC, it also spams people via email. Still not nice.
14:15:10 <_glx_> ah yeah the emails github still can't send to me
14:15:45 <peter1139> Is that something I've turned off... :D
14:16:11 <_glx_> if you used your openttd.org email it's 'automatic'
14:16:28 <truebrain> I deduce some sarcasm 😛
14:17:16 <truebrain> but that is annoying; I only registered my email address, and use another to receive GitHub notifications .. but .. it is not ideal, that GitHub can't mail to OpenTTD.org mails
14:17:51 <truebrain> I hope that didn't ping anyone 😛
14:21:35 <FLHerne> I still don't see the point of discussions over issues
14:21:41 <FLHerne> it's the same, except less visible
14:28:01 <_jgr_> Less visible is to some extent a feature, not a bug
14:28:46 <_jgr_> Bug reports are generally higher priority than feature ideas
14:31:52 <xarick> hmm... there's still some missing conditions... I'm a bad reviewer confirmed
14:35:49 <_glx_> but you should look at this before it's merged, not after 🙂
14:48:47 <xarick> this would fix it, should I PR? or ... what do I do now?
14:51:39 <talltyler> Posting a screenshot of code certainly doesn’t fix it, especially since you haven’t explained what is broken
14:52:20 <talltyler> So yes, open an issue if you have a problem but no fix, or a PR if you have both a problem and a fix
14:53:47 *** gelignite has joined #openttd
14:54:45 <_glx_> the more important point is details 🙂
14:55:33 <xarick> checking with script_order what they are allowed to pass to CmdInsertOrder
14:57:00 <_glx_> script_order has some kind of validation too, CmdInsertOrder is just doing a final failsafe test
14:57:30 <_glx_> but CmdInsertOrder of course needs to be correct
14:58:19 <klote> Hi does any one know if its possible to edit landscape type from temperate to artic off a exist scenario?
14:58:53 <_glx_> climate must be decided as first step
14:58:57 <klote> i have a scenario but opengfx landscape doesnt work on it.
14:59:12 <klote> and all other snow grfs neither
14:59:54 <peter1138> Save as heightmap, and recreate it.
15:00:12 <klote> yeh did that that works but then map is ugly
15:00:28 <_glx_> map should be exactly the same
15:00:53 <klote> rivers are not the same neither are the montains
15:04:06 <xarick> that return CommandCost is somewhat resolved as ERR_UNKNOWN 😦
15:04:25 <xarick> return_cmd_error would work, hmm what can I do here?
15:05:34 <_glx_> I think in this case it would be better to just open an issue with the list of allowed combinations that should not be allowed
15:06:24 <xarick> `return CommandCost(STR_ERROR_CAN_T_ADD_ORDER, STR_ERROR_UNBUNCHING_ONLY_ONE_ALLOWED);`
15:06:24 <xarick> `return_cmd_error(STR_ERROR_UNBUNCHING_ONLY_ONE_ALLOWED);`
15:06:43 <xarick> how can it return 2 error strings
15:07:02 <_glx_> it's not 2, it error title and details
15:09:22 <_glx_> and I think using `return_cmd_error` looks wrong in this function
15:10:54 <xarick> StringID 4138 is the error string that's being passed to scripts, let's see what this is
15:13:55 <xarick> static const StringID STR_ERROR_CAN_T_ADD_ORDER = 0x102A;
15:16:41 <xarick> that one is a bit pointless to know, scripts need the reason why mostly
15:19:18 <peter1138> Probably by leaving it as it is, but then allowing scripts to also have access to the additional error text.
15:25:51 <xarick> seems the GUI part is already handling this...
15:26:11 <xarick> doesn't even reach CmdInsertOrder when ctrl clicking on depot
15:30:37 <xarick> is this supposed to happen?
15:30:49 <xarick> message is printed to console at the same time?
15:31:03 <xarick> is it because im running a debug build
15:31:16 <peter1138> I've never seen that before.
15:34:47 <_glx_> I don't remember seing errors in the console
15:35:06 <xarick> happens in release too
15:43:06 <_glx_> oh ShowErrorMessage prints everything above WL_INFO in the console
15:44:32 <_glx_> seems someone used the wrong level 🙂
15:49:07 <xarick> xarick: I confirm line 828 is required, scripts can send unbunch and halt flags
15:49:39 <xarick> until I actually add the unbunch to scripts, they can do it
15:51:24 <xarick> line 827 I was trying to be pedantic, not sure if it's required
15:52:18 <xarick> unbunch order that is not part of the orders, hmm is this even possible,
15:56:37 <truebrain> okay, on staging DorpsGek is fixed
15:56:41 <truebrain> ah .. also for production 😄
15:57:08 <truebrain> what is lost, is lost btw
15:57:58 <_glx_> else it would be quite spammy
16:00:42 <_glx_> I can imagine the "please rebase" without even checking 🙂
16:01:12 <Rubidium> I'm already working on the rebase, but it has some annoying conflicts
16:02:23 <_glx_> I remember all the conflicts during miniin "rebase"
16:02:44 <_glx_> it was often easier to do it in small steps
16:05:35 <merni> It needed to be said twice!
16:05:58 <truebrain> merni: Lies! There is no second! 😛
16:07:20 <merni> Well, in that case changing the extra-text window to also show the vehicle name is probably not very difficult at all
16:07:44 <merni> "window" I mean section or whatever
16:08:12 <peter1138> truebrain: What was lost?
16:12:16 <xarick> is it safe to say unbunch won't be in scripts for the time 14 releases?
16:12:21 <_glx_> I like the "reopen" emote
16:13:35 <_glx_> it should be possible to add stuff for 14 API
16:13:56 <_glx_> but not after the final release
16:14:43 <xarick> oh, so I need to hurry up
16:16:23 <Rubidium> s/release/release candidate/
16:20:48 <LordAro> nothing stopping additions
16:20:52 <LordAro> but certainly no changes
16:22:09 <xarick> API scripts has been already bumped to 15 though
16:22:41 <peter1138> `CI / Mac OS (x64) (pull_request) Successful in 4m`
16:22:45 <peter1138> 4m... what is this wizardry...
16:40:52 *** SigHunter has joined #openttd
16:48:32 <peter1138> LordAro, finally fitted tubeless to front. Got puncture on first ride :S
17:02:31 <xarick> I'm missing a regression test yet
17:03:05 <xarick> and then a PR + commit description, that's gonna take hours
17:05:00 <peter1138> So did we decide to use specific runner version instead of waiting for an update?
17:11:12 <_glx_> waiting would have been required some changes anyway
17:18:52 <_glx_> (auto merge on a CI change can't work, it requires super powers)
17:23:08 <Rubidium> just use those super powers to change the required checks and auto merge should do its thing. Just consider merging approved PRs before so those don't need to be rebased and reapproved
17:24:52 <xarick> hmm, are there Error messages regression tests?
17:26:43 <xarick> "someone" should add more of these tests
17:31:36 <xarick> ppl keep changing commands and any difference in the error returned can be doomsday for an AI
18:12:56 <LordAro> peter1138: not worth it
18:15:46 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
18:35:06 <xarick> kuhnovic is now handling merges? interesting
18:35:47 <kuhnovic> They made me a developer 🙂
18:37:04 <xarick> oh... big changes incoming
18:40:59 <kuhnovic> Well I wasn't planning on anything crazy. Just doing what I'm already doing, but with a new title 🙂
18:43:59 <peter1138> PRs prevent all that 😄
18:44:11 <peter1138> Not like "the good old days" of direct svn access.
18:45:02 <kuhnovic> I'm there's still people that will hold me accountable 😛
18:46:26 <_glx_> Yeah you can't approve your own PR
18:47:12 <michi_cc> People with merge access aren't that special anyway, or didn't you read todays blog post 😛
18:48:02 <_glx_> During SVN time it was often me committing "Fix: missing vcproj update" 🙂
18:48:03 <peter1138> It's pretty special.
18:49:20 <_glx_> It's so much better now
18:49:47 <peter1138> Don't go around making people "official devs" and then say it's not special 🙂
18:55:31 <xarick> dinner time now though
18:57:38 <merni> Hm, 11470 is still outstanding
19:04:55 <kuhnovic> I'm trying to use the backporting script now. I ran into a few conflicts which I've fixed. After that it seems to merge one commit and then fail. I wonder what I'm doing wrong.
19:16:09 <michi_cc> Looks like they all fail to cleanly apply. Did we change some fundamental thing somewhere? 🤔
19:17:14 <_jgr_> You don't need to change anything fundamental or even major at all to get merge conflicts
19:17:48 <kuhnovic> I don't see any comflicts popping up after the first two
19:32:25 <kuhnovic> I started from scratch, this time it seems to go better. But some of the conflicts are nasty
19:33:42 <michi_cc> kuhnovic: You should have just one single conflict, I just ran it.
19:33:54 <michi_cc> And it failed before because #12136 wasn't tagged proberly.
19:34:07 <kuhnovic> I got this one, among others
19:34:15 <michi_cc> Did you set the correct release branch on backports.py?
19:34:37 <kuhnovic> If you say that you only have one conflict then probably not 😛
19:35:37 <michi_cc> To be sure, just do a git --reset hard to master first and remove any other untracked files.
19:36:05 <kuhnovic> I started with a clean master checkout like the script says... but should it be release then?
19:36:06 <peter1138> Hmm, shame std::initializer_list doesn't have an indexer operator 😦
19:36:24 <michi_cc> Oh, and side note to everybody not listening: If you *squash* a PR with backport requested, also place the tag `backport squash`.
19:37:16 <michi_cc> kuhnovic: No, the script does the branch handling by itself as long as you have `RELEASE = "14"` in it.
19:37:51 <peter1138> Never heard of that tag.
19:38:18 <michi_cc> Well, do more backport PRs, then you'll know it 😛
19:38:37 <LordAro> i feel like the script should be able to tell
19:38:49 <michi_cc> It's some quick in the GitHub API that there's apparently no way to query rebase/squash for a PR.
19:38:52 <kuhnovic> I'm using windows btw, I don't know if that matters
19:39:00 <peter1138> It has been way more common recently to use squash.
19:39:13 <peter1138> To get that elusive PR number in.
19:39:17 <michi_cc> More exactly: If the PR has more than one commit.
19:40:45 <michi_cc> It doesn't matter for single commit PRs. It's only relevant if the amount of commits in the PR doesn't match the amount of commits that it resulted in in master.
19:40:58 <kuhnovic> As usual: reading is hard
19:42:53 <peter1138> I would say that yes, there have been major changes since 13 🙂
19:48:54 <merni> Hm, how do you trigger a "Game save failed" error
19:49:23 <merni> I guess "Game load failed" is easier maybe?
19:50:17 <Rubidium> just change some bits/bytes near the end of a valid savegame file I'd guess
19:50:19 <kuhnovic> Got a lot further this time. Fixed the merge confict in saveload.h, but now I'm getting this again. Did you see this too michi_cc ?
19:51:18 <_jgr_> merni: Insert a deliberate mistake into the saveload code somewhere and recompile
19:51:43 <_jgr_> That sort of thing is generally the easiest way to test these sorts of error handling
19:52:16 <michi_cc> kuhnovic: No, it just worked after that commit. I guess nobody uses that with plain Windows (no WSL, cygwin, msys or whatever).
19:53:12 <LordAro> unless git line endings isn't set up correctly
19:53:15 <michi_cc> But as long as it is still doing something, it's only two more PRs. So maybe you can just re-run a few times.
19:53:22 <Rubidium> might it be something weird like your master not being up-to-date or so?
19:53:47 <kuhnovic> I re-ran it a handful more times and now it's done. I'm just wondering if it skipped over anything?
19:53:49 <michi_cc> LordAro: I was more thinking that some conflict files aren't properly cleaned up.
19:54:08 <michi_cc> Merging #12237: Codechange: [CI] switch MacOS to the macos-14 runner
19:54:08 <michi_cc> Commit #0: ebd258b404e96da17efb64370bd1e23b987a81ea ...
19:54:08 <michi_cc> Merging #12244: Revert #11606: Don't auto-build past tunnelbridge ends
19:54:08 <michi_cc> Commit #0: e0e0d5f8fb7e92e5a3dfc766c3aab14a293a74b6 ...
19:54:08 <michi_cc> Merging #12245: Fix ab315d0: Don't show "insert order" errors in the console
19:54:10 <michi_cc> Commit #0: 82430a1086b92341ec914f3bd6a260ab74c8b3c4 ...
19:54:18 <michi_cc> That should be the ones after the conflict.
19:55:46 <kuhnovic> Those are indeed the ones I got
19:56:06 <michi_cc> kuhnovic: You're supposed to copy the part after "Your commit message" to the PR.
19:56:30 <michi_cc> That is used for the backport.py --mark-done command.
19:57:45 <michi_cc> And sorry, but the script really did seem to break.
19:58:03 <michi_cc> You've got some missing stuff.
19:58:48 <michi_cc> I'll force-push over if that is okay
20:00:20 <michi_cc> Oh, did you actually commit after the cherry-pick failure?
20:00:48 <michi_cc> You have to do the commit yourself with a cherry-pick in contrast to a rebase.
20:02:04 <LordAro> also make a PR improving the documentation of said script when you get to the end of it :)
20:03:19 <kuhnovic> michi_cc: I just ran the script again, it seemed to do all the work for me?
20:03:40 <michi_cc> No, that's unfortunately not how git cherry-pick works.
20:04:39 <michi_cc> So either make a manual commit or fix the conflict and then call `git cherry-pick --continue`
20:05:23 <kuhnovic> But I don't have any local changes other than the two backport scripts?
20:06:24 <michi_cc> After the saveload conflict, you had uncommited changes.
20:06:25 <kuhnovic> I'm still a bit of a git-noob, I've mostly worked with mercurial in the past. Just want that to be clear 😛
20:06:50 <michi_cc> And unless you actively do something with them, that commit will not be done.
20:07:54 <kuhnovic> Oh those had to be added as a separate commit? Right, I didn't do that. I thought fixing them and marking them as resolved / getting them stages was enough.
20:08:02 <michi_cc> I'm usually lazy for that part as I use Git Extension, which will suggest an action.
20:08:18 <michi_cc> Nope, either commit or cherry-pick --continue is needed.
20:08:32 <LordAro> git status will usually tell you what ... state the git repo is in
20:08:56 <LordAro> i.e. if there's an ongoing operation (like rebase, revert, cherry-pick, etc)
20:09:20 <kuhnovic> I use SourceTree, but it didn't suggest anything like that
20:10:36 *** marchnex has joined #openttd
20:10:38 <peter1138> Chucked in at the deep end.
20:10:45 <michi_cc> Never used that. Git Extentions will show a hint bar if you're in an active cherry-pick or rebase.
20:11:14 <kuhnovic> But is everything fixed now with your force push?
20:11:36 <michi_cc> Yes, it should be 🙂 Unless I messed up, too 🙂
20:12:09 <michi_cc> Someone should actually try to run the resulting binary though 🙂
20:12:14 <LordAro> presumably the description was correct regardless?
20:12:30 <michi_cc> Well, no, but I fixed that, too.
20:16:59 <_glx_> at least it's usable on windows now, last year it was not possible 🙂
20:18:04 <_glx_> and no label should be needed for squashed PR
20:21:10 <michi_cc> _glx_: Ah, yes, I apparently forgot that was fixed 🙂
20:21:23 <peter1138> Forums are funny. "I want to remove transmitters" "You can with cheats/sandbox mode" "But I want to remove transmitters without it being calling cheating!"
20:22:16 <_glx_> yeah usually when something depends on a most likely forgotten label being applied, someone manages to do things so the label is not needed 🙂
20:23:10 <Eddi|zuHause> isn't that the exact reason why it's now called "sandbox" instead of "cheat"?
20:23:58 <_glx_> but it still affects highscore IIRC
20:24:26 <merni> and the use of them is tracked unlike other settings
20:25:10 <kuhnovic> Do we have any documentation on what we keep or throw away in our changelogs?
20:26:02 <_glx_> mostly stuff visible to users (hence the recent Codefix and friends additions)
20:27:00 <_glx_> there should be a script for the changelog (in the same repo as backport)
20:41:37 <kuhnovic> Do I create the changelog PR in the release-backport branch?
20:49:50 <xarick> Should I create HasUnbunchingOrder, HasConditionalOrder, HasFullLoadOrder for scripts?
20:50:38 <xarick> at the time I don't think it's necessary
20:50:51 <_glx_> scripts don't need this kind of functions
20:51:35 <xarick> I have the branch ready, except for the description
20:53:52 <andythenorth> merni: used to be so slow 😛
20:56:49 <michi_cc> kuhnovic: I think we usually do a separate PR (which always means a separate branch).
20:57:10 <kuhnovic> Yeah that's what I figured by looking at RC1. I'm making it as we speak
20:57:12 <michi_cc> Base on release/14 though (and not on master).
20:58:00 <kuhnovic> SOmething is going wrong here
20:58:06 <michi_cc> Wrong branch (and you seem to have picked up some other commit) 🙂
20:58:29 <michi_cc> You made the branch from master I guess.
20:59:49 <kuhnovic> I thought I didn't, but yeah I messed something up. Just a moment
21:03:43 <Rubidium> I set the branch to merge to to 14 and that "extra" commit is now gone
21:06:10 <kuhnovic> So did I create it based on master?
21:06:51 <Rubidium> nah, you created it (locally) based on 14, but in github you didn't change the merge target from master to 14
21:07:36 <kuhnovic> Ah right, I didn't pay attention to that indeed. Live and learn!
21:14:34 <_glx_> you used the changelog script or did it by hand ?
21:17:23 <_glx_> oh of course commit checker failed because wrong target
21:25:08 <peter1138> Hmm, I guess `list.begin()[index]` would work.
21:25:19 <michi_cc> Oh, and maybe the changelog date is ambitious 🙂
21:30:12 <kuhnovic> michi_cc: I know 😛 I will change it when I address the review feedback
21:37:51 <kuhnovic> Alright, enough release stuff for now. Time for a whisky and then bedtime!
21:38:59 <kuhnovic> Thanks for the help, and putting up with me messing around. I'll get there eventually 😉
21:39:33 <Eddi|zuHause> who organizes the birthday party, btw? :p
21:44:10 <xarick> unbunch missed the train
21:53:24 *** marchnex has quit IRC (Quit: marchnex)
21:56:29 <peter1138> Oh right, someone did another blog post.
21:56:54 <LordAro> Eddi|zuHause: well volunteered
22:00:45 <peter1138> Hmm, branches, commits, and PRs, or... sleep.
22:05:46 <xarothbrook> sleep sounds good
22:15:31 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:15:47 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:24:38 <LordAro> sleep is for the weak
22:39:08 <xarick> airports with a hole, like the opengfx intercontinental
22:40:32 <xarick> at 180 degrees rotated, the top tile is now not even part of the airport
22:42:09 <xarick> how to solve... the whole point of this function was to facilitate adding orders to the airport
22:42:59 <andythenorth> peter1138: pixels
22:43:29 <xarick> if rotated airports once become a feature for AIs, they could place by top corner tile, but adding order with this tile will fail 😦
22:45:51 <xarick> Game Scripts can access human companies that may have this rotated airport
22:53:43 <xarick> so this is possible... lol
22:56:59 <_glx_> seems most ScriptAirport functions use tile as parameter
22:57:21 <_glx_> so it's a problem in many cases
22:59:49 <_glx_> I guess they should have precondition enforcing like ScriptAirport::RemoveAirport
23:00:38 <_glx_> but your ScriptAirport::GetTileOfAirport should probably use a stationID and not a tile as parameter
23:01:02 <xarick> the tile area seems to include holes
23:01:22 <xarick> I need to test by stationID too
23:02:06 <_glx_> yes area always include holes, it's just a (tile, width, height)
23:05:23 <_glx_> I understand why many functions work with tiles, but sometimes it seems to not be the best choice
23:06:10 <andythenorth> there's a lot of looking things up in GS
23:06:24 <andythenorth> can cache lookups, but it grows RAM quite fast
23:06:35 <andythenorth> and goes out of date WRT map 😛
23:06:39 <_glx_> for road/rail it makes sense to use tiles as they are fully modular
23:06:51 <_glx_> but airports are full blocks
23:07:11 <xarick> if (IsAirportTile(t) && !IsHangarTile(t) && ::Station::GetByTile(t)->index == st->index) return t;
23:08:21 <_glx_> for easier readability you could put each test on separate line
23:09:01 <_glx_> if (!IsAirportTile(t)) continue;
23:09:01 <_glx_> if (IsHangarTile(t)) continue;
23:22:06 <truebrain> _glx_: my only worry about enabling both x64 and arm64 is that we hog up the runners even more. Those 4m could have been spend on other things too 😛
23:22:41 <truebrain> Not an issue for a single push, but if like today someone pushes 15+ PR updates at once, it matters
23:22:42 <_glx_> macos release should be a lot faster to build now
23:22:58 <truebrain> They are equally fast as before, the numbers told me
23:23:26 <truebrain> But even if they weren't, still 4m that can be spend on something else 😄
23:23:51 <truebrain> Dunno .. I see the pros and cons, still find it tricky to pick either side 😄
23:24:11 <_glx_> wondering if we should drop mingw
23:24:40 <truebrain> I have been asking that for how many years now? 😛
23:25:46 <michi_cc> Maybe at least one of the two mingws?
23:25:56 <truebrain> I was kinda hoping it would fail on C++20, but it didn't 😛
23:26:38 <_glx_> having both is like x86 and x64 with MSVC, they don't complain on the same thing
23:27:03 <truebrain> But when is the last time the MingW builds gave us any extra information?
23:27:22 <truebrain> Similar with win2019 btw .. we should honestly just stop running that 🙂
23:27:32 <_glx_> they are quite silent since I fixed the last warnings
23:27:57 <truebrain> Maybe, as compromise, we can push all these to a nightly or weekly job
23:28:06 <truebrain> Just so we know they still run
23:28:17 <truebrain> But remove them from CI
23:28:31 <truebrain> Their added value is so low .... so so low 😛
23:28:57 <truebrain> Is MSVC2019 actually still useful btw?
23:33:09 <truebrain> MinGW and MSVC2019 are good for a wopping 70m CI time, damn
23:35:56 <xarick> GSTileList_StationType this actually works correctly!
23:37:38 <_glx_> this list just use the full station rect
23:40:00 *** gelignite has quit IRC (Quit: Stay safe!)
23:41:16 <truebrain> Hmm .. would we be able to run CodeQL on the macos runners? Would that be faster? 😄
continue to next day ⏵
