IRC logs for #openttd on OFTC at 2023-04-29
01:23:26 *** geli has joined #openttd
01:30:51 *** gelignite has quit IRC (Ping timeout: 480 seconds)
01:59:07 *** geli has quit IRC (Quit: Stay safe!)
02:13:48 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
02:14:34 *** D-HUND has joined #openttd
02:17:56 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:20:56 *** Wormnest has quit IRC (Quit: Leaving)
03:33:18 *** keikoz has joined #openttd
04:19:08 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
04:19:34 *** WormnestAndroid has joined #openttd
04:52:20 *** keikoz has quit IRC ()
05:02:37 *** keikoz has joined #openttd
05:07:03 *** D-HUND is now known as debdog
05:48:05 <petern> Oh whoops, more functions I changed. Bah!
06:29:17 *** axet has joined #openttd
06:31:45 <axet> Hi! I have really big train network with central hub (power plant) to unload coal. 150 trains causing traffic issues. I have enter / exit queue depos. As result only 10% of trains used due to traffic. To solve the issue I guess I need increace train load time, so trains stays loading instead staying in queue depo. Can I increase cagro load time?
06:32:15 <axet> I tried build 1 cell train station - but loads still very fast.
06:33:49 <axet> Another problem - competitors roads / bridges. I can remove competitor trains and rail ways got removed by AI. But roads stays - I unable to do anything with roads. Can AI also remove roads when bus stations removed?
06:42:03 <Rubidium_> do you use full load orders at the coal mines? Alternatively timetable the stop at the coal mine
06:42:14 <axet> sure. full load.
06:42:25 <axet> my train track cover entier map
06:43:09 <axet> 512x512
06:44:20 <andythenorth> Have fewer trains. If only 10% are used, you only need 15
06:44:41 <andythenorth> This will ease congestion
06:44:58 <axet> The idea was - trains have to load at coal mines, not wait in queue depo.
06:47:07 <andythenorth> Capacity issues are best solved by using ships, as they have infinite capacity per tile
06:49:03 <axet> I'm using trains because it most fun!
06:49:24 <axet> building two way tracks, bridges, tunels
07:00:18 *** nielsm has joined #openttd
07:05:20 *** Wolf01 has joined #openttd
07:15:19 <DorpsGek> [OpenTTD/OpenTTD] silpol started discussion #10737: feature needed - Can a "select all" option be added please?
07:18:56 <LordAro> nope
07:31:58 <TrueBrain> I wonder if Steam Workshop gets these requests too πŸ˜„
07:41:56 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on discussion #10737: feature needed - Can a "select all" option be added please?
07:45:41 *** HerzogDeXtEr has joined #openttd
07:49:02 <Brickblock1> Bananas subscription model when?
07:49:41 <DorpsGek> [OpenTTD/OpenTTD] axet started discussion #10738: Auto remove roads buid by AI
07:55:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on discussion #10737: feature needed - Can a "select all" option be added please?
07:55:23 <TrueBrain> Brickblock1: 1 euro a month to get access to BaNaNaS? πŸ˜„
07:55:52 <Brickblock1> No only download all
07:56:12 <TrueBrain> awh 😦 I wanted to get rich!
07:56:32 <axet> torrent downloads?
07:56:55 <axet> +speed limit
07:59:08 <TrueBrain> no way to get rich from torrents either 😦
08:00:01 <axet> here is only one way to be happy - no money
08:00:42 <TrueBrain> pretty sure that is not how it works
08:00:54 <DorpsGek> [OpenTTD/OpenTTD] silpol commented on discussion #10737: feature needed - Can a "select all" option be added please?
08:01:32 <axet> by free / a lot of money you mean taking someone work for free?
08:01:46 <axet> here a word for that - slavery
08:02:18 <TrueBrain> wtf? How did you manage to get the conversation to slavery .. well, this conversation is over for sure. Brr.
08:03:11 <axet> sure. take your money, and do not call it slavery. for sure.
08:07:45 <TrueBrain> Lol, I was snooping on GitHub what people have been building for OpenTTD, and found this:
08:08:03 <TrueBrain> I am guessing our autoclean functionality needs a bit of work πŸ˜›
08:16:54 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10709: Remove: buying/selling/owning company shares
08:17:30 <LordAro> heh
08:21:17 <Rubidium_> LordAro: care to have another look at 10727?
08:21:28 <TrueBrain> 5 euroes!
08:23:45 <pickpacket> TrueBrain: huh?
08:23:46 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10727: Codechange: introduce C++ string accepting case insensitive string comparisons
08:24:32 <TrueBrain> pickpacket: a random "huh?" appears πŸ˜›
08:25:29 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10727: Codechange: introduce C++ string accepting case insensitive string comparisons
08:27:16 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 dismissed a review for pull request #10730: Fix: FormatArrayAsHex returns gibberish instead of a hex array
08:27:19 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10730: Fix: FormatArrayAsHex returns gibberish instead of a hex array
08:28:38 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10730: Fix: FormatArrayAsHex returns gibberish instead of a hex array
08:33:05 <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #10695: Fix #8177: Ships with max speed overflow to near-zero speed
08:33:09 <DorpsGek> [OpenTTD/OpenTTD] LordAro closed issue #8177: Ships with max speed overflow to near-zero speed
08:33:17 <LordAro> nice old issue
08:33:20 <TrueBrain> I tried understanding that PR, and just gave up.
08:33:30 <LordAro> it looked reasonable.
08:33:31 <TrueBrain> I think I will never understand vehicle movement code πŸ˜›
08:33:37 <LordAro> soon find out if not
08:33:58 <TrueBrain> hihi, YOLO πŸ˜›
08:34:13 <TrueBrain> I am looking over old PRs and issues .. somewhat tempted to close a bunch, as they are not going to happen etc
08:34:25 <LordAro> i've definitely taken a "fix it in post" approach to things recently
08:34:37 <TrueBrain> yeah, I noticed; not saying that is a bad thing πŸ™‚
08:35:28 <TrueBrain> LordAro: regarding #10623, I guess it only needs adding the setting frosch mentions?
08:35:43 <LordAro> well, possibly others too
08:35:49 <TrueBrain> yeah, but those too, can be done post πŸ™‚
08:36:43 <TrueBrain> about the station passthrough, you can argue if that shouldn't be default anyway πŸ˜›
08:37:19 <TrueBrain> but making that a setting is easy enough I guess ..
08:37:22 <LordAro> hmm
08:37:40 <LordAro> now i'm wonder if there's a feasible way to make the settings "constants" for release builds, but retain the settings for debugging purposes
08:37:51 <LordAro> probably not, realistically
08:37:58 <TrueBrain> there also really isn't a point, honestly
08:38:00 <LordAro> possibly a load of defines?
08:38:10 <TrueBrain> when was the last time these values got changed?
08:38:30 <LordAro> apparently, a lot more regularly than we thought!
08:39:00 <LordAro> idk though, i definitely never touched them when fiddling with the road pathfinding a few years ago
08:39:56 <TrueBrain> 2 years ago I split the PF away from the main settings, so history is a bit tricky .. let's see when the last actual change was ..
08:40:06 <TrueBrain> so ofc the firstred_twoway_eol we flipped "recently"
08:42:16 <TrueBrain> 4 years ago we added 2 PF settings for ship curves
08:42:28 <TrueBrain> all other settings never (!) got changed in 13 years
08:43:51 <Eddi|zuHause> i still don't think "these values were meant for debugging" is a valid statement
08:44:12 <TrueBrain> as for keeping it as settings for debug purposes .. there are only very few of us that actually use it like that .. a recompile works fine for that too, in my experience
08:45:31 <TrueBrain> I mostly changed values to force a certain behaviour to identify a bug .. but those cases are so rare and far between .. not really a reason to keep these settings around
08:46:29 <Eddi|zuHause> anyway, we should wait for a survey of which settings are actually changed by users before doing anything
08:46:31 <TrueBrain> and I like your solutions LordAro, where you just made a list of consts with these penalties. Makes it easy enough for us to work on
08:47:03 <LordAro> i do agree with Eddi|zuHause on that front
08:47:07 <TrueBrain> I do not
08:47:16 <TrueBrain> we have talked about this for years now, and we are just too scared
08:47:17 <LordAro> better for us to have some data to point at to say "look, we told you so"
08:47:34 <TrueBrain> we know those settings are bad, we have seen it many times
08:47:41 <TrueBrain> we know we don't want those settings to be there
08:48:16 <Eddi|zuHause> i haven't seen any of those discussions
08:48:22 <TrueBrain> it really comes down to: these are the wrong kind of settings. They should been functional, not technical
08:49:12 <Eddi|zuHause> yes. and the survey would point us in the direction of what function people need
08:50:05 <TrueBrain> no it won't, as we lack context to give it any meaning
08:50:42 <TrueBrain> it would just collect random data which we might or might not use to fence with, but that is all it is: fencing with. It wouldn't actually tell us anything
08:51:03 <TrueBrain> and sadly, as we found out, putting out an actual survey to collect information how people use the game also doesn't get much response
08:51:19 <Eddi|zuHause> so you'd rather do this with no data because you're scared the data wouldn't tell us anything useful?
08:51:21 <TrueBrain> well, LordAro, that might work with Discord, to just ask a few basic questions about how people use PF settings πŸ™‚
08:52:50 <TrueBrain> That would allow us to ask the "why" πŸ™‚
08:53:23 <Eddi|zuHause> but asking this on any platform is too narrow of a target audience
08:55:39 <TrueBrain> LordAro: another approach would be to add code in 14.0 which detects if people use custom PF settings, and give a popup: "this game uses modified PF settings; did you make those? Mind filling out a survey to make us understand how to improve the game?"
08:59:58 <LordAro> heh
09:01:28 <TrueBrain> I guess those are two paths to walk: either remove them, and wait for people asking for legit cases to add, or see if we can collect the "why" from people before we remove it. The latter would be more of a deprecation approach
09:02:00 <Eddi|zuHause> i really don't see the urgency to remove them RIGHT NOW.
09:03:10 <TrueBrain> but just to set expectations: the opt-in automated survey would only tell whether someone changed the PF settings. If nobody did, sure, clear case. But if people did, it doesn't actually tell us why. So we are not much wiser as we are now, as we know some people change them.
09:03:19 <TrueBrain> in other words: these kind of automated surveys work best for functional settings
09:03:21 <TrueBrain> not for technical
09:04:24 <Eddi|zuHause> sure. but it would identify some hotspots, which could allow us to make educated guesse
09:04:27 <Eddi|zuHause> s
09:04:43 <Eddi|zuHause> i feel like my s key is on the brink of collapse
09:05:22 <TrueBrain> in totally different news .. and I almost don't dare to ask ... LordAro: ? πŸ˜„
09:05:51 <LordAro> haha
09:06:00 <TrueBrain> it was SO CLOSE
09:07:37 <LordAro> it was, but then nielsm pointed out that it was all just hacks
09:07:48 <TrueBrain> just make it signed πŸ˜›
09:08:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10730: Fix: FormatArrayAsHex returns gibberish instead of a hex array
09:08:48 <LordAro> i like the idea of just letting SetPosition do the clamping for us
09:08:57 <LordAro> it would simplify a lot
09:09:39 *** NGC3982 has quit IRC (Ping timeout: 480 seconds)
09:11:48 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 dismissed a review for pull request #10728: Codechange: introduce C++ string accepting natural string comparison
09:11:51 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10728: Codechange: introduce C++ string accepting natural string comparison
09:12:45 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10728: Codechange: introduce C++ string accepting natural string comparison
09:12:52 *** NGC3982 has joined #openttd
09:13:45 <TrueBrain> Rubidium: for the \0 fix, did you also check the other instances of MultiByteToWideChar?
09:15:21 <TrueBrain> (and mostly I mean OTTD2FS)
09:17:14 <TrueBrain> well, guess there it is a `std::string`, so that should be fine πŸ˜›
09:17:32 <TrueBrain> just not sure `name_len` includes the `\0` πŸ™‚
09:19:27 <Rubidium_> it seems to be "fine". Not fine though... the "len includes terminating null" comments are not technically true, but making a std::string of 100 characters secretly allocated 101 and sets the last character to '\0' to aid with c_str()
09:20:12 <Rubidium_> so in the end it'll function the intended way, although not the way its documented
09:20:26 <TrueBrain> hahaha, this answer .. I just love it πŸ™‚
09:21:01 <TrueBrain> but good, tnx for checking πŸ™‚
09:25:20 <LordAro> Rubidium_: think it's worth adding the old functions to safeguards ?
09:26:21 <Eddi|zuHause> "safeguards" is the "we don't use that kind of function in this project" notification?
09:27:09 <LordAro> yeah
09:29:20 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10739: Codechange: remove need for stredup/free from GRFConfig/GRFFile
09:29:40 <andythenorth> what shall we charge for?
09:29:51 <andythenorth> truegrf, subscription?
09:30:01 <andythenorth> we should charge for using 32bpp / EZ
09:30:10 * andythenorth prejudiced much?
09:30:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10733: Codechange: use standard int types
09:30:22 <Rubidium_> LordAro: you mean for strcasecmp? On Windows compiling will fail because that does not know strcasecmp and we used to #define strcasecmp to stricmp for Windows
09:30:29 <Eddi|zuHause> when trueGPT? :p
09:30:42 <Rubidium_> for strnatcmp, that function was renamed and is gone
09:30:49 <TrueBrain> charging for 32bpp? how about removing it .. 4x is such a bandwidth drain πŸ˜›
09:32:15 <LordAro> Rubidium_: fair enough
09:33:31 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10739: Codechange: remove need for stredup/free from GRFConfig/GRFFile
09:33:38 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10739: Codechange: remove need for stredup/free from GRFConfig/GRFFile
09:34:39 <andythenorth> removing 32bpp eh
09:34:56 <TrueBrain> I am sometimes still amazed to see a screenshot and not noticing it is OpenTTD
09:35:04 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10733: Codechange: use standard int types
09:35:06 <TrueBrain> well, ofc, there is no GUI on the screenshot in those cases πŸ˜›
09:35:06 <andythenorth> I wonder
09:35:18 <andythenorth> there would be big rage about such a change
09:35:27 <andythenorth> but who of the enraged would turn up and help support?
09:35:34 <andythenorth> would they be prepared to fork?
09:35:44 <andythenorth> do they care enough, or is it just performative rage?
09:36:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10733: Codechange: use standard int types
09:37:41 <Eddi|zuHause> "BaNaNaS Premium: download files larger than 10MiB"
09:38:18 <TrueBrain> with 14.0 I can migrate the CDN to Cloudflare, which means from a backend point of view I am going to care a lot less about size πŸ˜›
09:38:26 <TrueBrain> but currently .. it is just expensive as fuck
09:38:50 <andythenorth> hmm
09:38:51 <TrueBrain> not a complaint against 32bpp or EZ, to be clear; just a reality I have to deal with πŸ™‚
09:38:56 <andythenorth> Horse is 21 MB though
09:39:01 <andythenorth> WOULD I PAY?
09:39:17 <andythenorth> so wait, I have to pay to distribute my content to users who get it free?
09:39:19 <andythenorth> SLAVERY
09:39:27 <andythenorth> DOUBLE SLAVERY
09:39:33 <Eddi|zuHause> that's not what i said
09:39:39 <andythenorth> first I pay with time, then I pay with money
09:39:44 <andythenorth> this is just a slave system
09:40:06 <Eddi|zuHause> can we just not make jokes about slavery?
09:40:16 <andythenorth> we can just not yes
09:40:39 <andythenorth> it references something from about 09.03 in my time zone
09:40:55 <Eddi|zuHause> i've seen that, yes.
09:41:15 <Eddi|zuHause> it wasn't funny 3h ago either.
09:41:41 <andythenorth> well let's talk about trains instead
09:42:10 <andythenorth> so we're not going to delete 32bpp / EZ?
09:42:22 <andythenorth> ok
09:42:31 <TrueBrain> ofc not you silly bean πŸ™‚
09:42:35 <Eddi|zuHause> i was eager to try out my new ticket that lets me take virtually every train. but on holidays there's no bus that leaves the village before noon
09:43:07 <Eddi|zuHause> (and 1st may is a holiday)
09:57:16 *** imlostlmao[m] has joined #openttd
10:04:13 <pickpacket> TrueBrain: as a response to a random ”5 euros!” πŸ˜„
10:07:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10728: Codechange: introduce C++ string accepting natural string comparison
10:10:26 <TrueBrain> pickpacket: I always ask, I never receive 😒
10:34:13 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10667: Codechange: Use more std::string in fios land
10:36:37 <TrueBrain> Rubidium: does it need any testing on MacOS / Windows?
10:39:23 <Rubidium_> testing on Windows would be fine, MacOS probably isn't needed as I didn't touch anything specific to that. OS/2 on the other hand...
10:40:53 <TrueBrain> Codewise it looks fine
10:53:35 *** Wolf01 is now known as Guest12506
10:53:37 *** Wolf01 has joined #openttd
10:54:49 <TrueBrain> I wonder if OS/2 works at all still .. we have no CI running it πŸ˜›
10:54:55 <TrueBrain> or releases
10:55:22 *** Guest12506 has quit IRC (Ping timeout: 480 seconds)
10:58:05 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10667: Codechange: Use more std::string in fios land
11:00:30 <petern> Hi
11:00:34 <petern> Midday eh
11:00:46 <TrueBrain> happened out of nothing!
11:01:25 <petern> Such surprise!
11:04:13 <petern> LordAro, the hills hate me 😦
11:06:58 <LordAro> :(
11:12:05 <LordAro> petern: "Hills are the best part [of cycling]. It is a biological fact, you cannot be bored when you are praying for death."
11:13:17 <petern> Yes, but the sadist who put all the hills in the second half...
11:13:33 <petern> Ah well, still alive.
11:14:04 <LordAro> among other things, i'd quite like to stop coughing
11:14:12 <LordAro> so i could actually do hills
11:15:29 <petern> That would help
11:16:07 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10739: Codechange: remove need for stredup/free from GRFConfig/GRFFile
11:23:39 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10667: Codechange: Use more std::string in fios land
11:31:39 <andythenorth> so what are we porting from JGRPP?
11:31:50 <andythenorth> * spacing of buses
11:32:02 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10732: Fix: Linkgraph legend assumes strings are small.
11:36:15 <TrueBrain> decent (functional?) time scheduling? πŸ˜„
11:36:16 <petern> I don't play JGRPP so I couldn't tell you what it has.
11:36:37 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10739: Codechange: remove need for stredup/free from GRFConfig/GRFFile
11:37:30 <petern> But, salad time πŸ˜„
11:37:43 <andythenorth> the main things I remember are the bus spacing, and the "PBS isn't always red" signals
11:38:26 <andythenorth> there's a through-loading patch also which allows stations to be 1 tile, but trains to be n tiles
11:40:12 *** JGR has joined #openttd
11:40:12 <JGR> I think those last two are pretty far outside of the vanilla design goals
11:41:04 <andythenorth> I tend to agree
11:41:12 <andythenorth> but they're worth seeing
11:46:40 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10740: Fix 4dd5f994: hotkey parsing was broken
11:47:22 <EmperorJake> Auto separation is probably the thing I miss most when I play vanilla, it should definitely be considered to be added
11:50:13 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10740: Fix 4dd5f994: hotkey parsing was broken
11:52:46 <TrueBrain> orudge: would you mind logging in to Cloudflare, going to R2 and hit that Purchase R2 Plan for me? I don't have permissions πŸ™‚ And "Purchase" is a big word; most of what we will be doing is part of the free monthly usage πŸ™‚
12:07:26 <TrueBrain> lol, that is actually funny .. I cannot purchase the R2 plan, but I can purchase the workers plan .. RBAC on Cloudflare is sometimes a bit hard to understand πŸ™‚
12:23:03 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on discussion #10738: Auto remove roads build by AI
12:25:24 <DorpsGek> [OpenTTD/OpenTTD] andythenorth commented on discussion #10738: Auto remove roads build by AI
12:28:46 *** lobstarooo has joined #openttd
12:36:49 *** lobstarooo has quit IRC (Ping timeout: 480 seconds)
12:40:35 <DorpsGek> [OpenTTD/OpenTTD] axet commented on discussion #10738: Auto remove roads build by AI
12:41:18 <DorpsGek> [OpenTTD/OpenTTD] axet commented on discussion #10738: Auto remove roads build by AI
12:42:21 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on discussion #10738: Auto remove roads build by AI
12:48:26 <petern> Hmm, what have I done... my console key isn't opening the console.
12:49:05 <petern> Not in 13.1 either. Hmm.
12:50:07 <DorpsGek> [OpenTTD/OpenTTD] andythenorth commented on discussion #10738: Auto remove roads build by AI
12:51:51 <petern> I think a recent changes has broken hotkey loading, so they get wiped.
12:54:47 <DorpsGek> [OpenTTD/OpenTTD] axet commented on discussion #10738: Auto remove roads build by AI
12:56:45 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10740: Fix 4dd5f994: hotkey parsing was broken
12:57:11 <petern> Oh I see πŸ™‚
12:59:38 <LordAro> heh
13:02:40 * andythenorth -> grf
13:02:46 <andythenorth> enough tank games
13:10:06 <andythenorth> lunch though?
13:11:32 <petern> Bit late now
13:12:08 <andythenorth> some mistakes may have been made
13:14:12 * pickpacket is dying from sugar overdose
13:16:41 <pickpacket> I want multi-story stations. I.e. Station tiles in tunnels
13:17:10 <pickpacket> because I just don’t know what to do about my overflowing staitons
13:17:18 <pickpacket> +spelling
13:28:48 *** ttdplanner has joined #openttd
13:32:20 <ttdplanner> Could somebody convert a .nml file to a .grf file for me please? I would really appreciate it as I am unable to do so on my system.
13:32:20 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:32:43 *** WormnestAndroid has joined #openttd
13:34:45 <pickpacket> ttdplanner: how much in a hurry are you? I may be at my computer tonight or tomorrow.
13:34:45 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:35:05 *** WormnestAndroid has joined #openttd
13:35:31 <ttdplanner> Hello pickpacket, I'm in no hurry at all. How would you like me to send you the file?
13:36:30 <pickpacket> ttdplanner: works πŸ™‚
13:37:16 <ttdplanner> Okay will do. Thank you so much.
13:41:30 <ttdplanner> I have just sent the email. You may need to check your spam folder if it doesn't show up.
13:43:25 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10733: Codechange: use standard int types
13:47:09 <glx[d]> what's your system ttdplanner ?
13:48:29 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10726: Fix: Moving cargo definition slots prevents normal town/industry behaviour.
13:54:29 <ttdplanner> glx[d], it is MacOS. The NMLTutorial wiki section for MacOS installation is completely blank and even the instructions for other operating systems include things that quite frankly go beyond my computer knowledge i.e. library packages, compiling, binaries etc.
13:54:45 <DorpsGek> [OpenTTD/team] IverCoder opened issue #419: [fil_PH] Translator access request
13:55:07 <glx[d]> installing python and `pip install nml` should work
13:55:58 <andythenorth> nmlc, but in an AWS Lambda? πŸ˜›
13:55:59 <andythenorth> oof
13:57:47 <glx[d]> IverCoderviaGitHub: nice try πŸ™‚
13:58:30 *** ttdplanner has quit IRC (Quit: Page closed)
13:59:20 <DorpsGek> [OpenTTD/team] IverCoder commented on issue #419: [fil_PH] Translator access request
14:02:11 *** Flygon has joined #openttd
14:02:54 <DorpsGek> [OpenTTD/team] glx22 commented on issue #419: [fil_PH] Translator access request
14:04:18 <petern> How is that done? πŸ˜„
14:04:55 <TallTyler> Today I rebase #10700. Should be a great time. πŸ˜›
14:05:03 <glx[d]> at least a new txt in src/lang
14:05:36 <glx[d]> then maybe also some changes in eints
14:07:13 <petern> TallTyler: Sometimes it's easier to rewrite (at least some commits) πŸ™‚
14:09:18 <glx[d]> <-- looks like we never expected smart users
14:10:52 <TallTyler> petern: Yeah, I put all the commits in a new branch and will be either rewriting or cherry-picking from there
14:12:52 <petern> Uh, what's that? πŸ™‚
14:13:28 <petern> For glx[d] that is
14:14:07 <glx[d]> that's dorpsgek failing to run on Teams#419
14:19:18 <TrueBrain> well, smart .. at least ka_GE was smart in the sense that they made a bug-ticket πŸ™‚
14:19:35 <andythenorth>
14:19:35 <andythenorth> such
14:19:43 <andythenorth> picking a complement to the company colour πŸ˜›
14:19:49 <andythenorth> now to randomise πŸ˜›
14:24:46 <petern> That's look great with RGB CC.,
14:24:58 <TrueBrain> the illusive RGB CC πŸ™‚
14:25:02 <petern> When you've limited to whatever 16 colours exist πŸ˜„
14:26:19 <andythenorth> piss πŸ˜› BaseException: randomised_piece_goods_car_pony_gen_5B has more than 32 entries in randomised_candidate_groups, and will run out of random bits; reduce the number of candidates
14:26:52 <andythenorth> petern: we can just import a colour library and shift colours πŸ˜›
14:27:00 <andythenorth> that's how it's done in CSS πŸ˜›
14:27:16 <petern> TrueBrain: I wrote it before any of the fancy blitters existed!
14:28:03 <andythenorth> goes it I compile the extra vehicle random bits PR?
14:28:12 <andythenorth> slight issue that my build is broken with master πŸ˜›
14:28:18 <andythenorth> I'm stuck building older versions
14:28:30 <andythenorth> today was not the day to reinstall my OS
14:28:30 <petern> Oh, my PR doesn't touch industry tiles, only industries. Oops.
14:37:19 *** WormnestAndroid has quit IRC (Remote host closed the connection)
14:37:20 *** WormnestAndroid has joined #openttd
14:37:56 <petern> Hmm, is it safe to assume that if an industry sets one cargo type, it'll set them all (lol, of course it's not safe...)
14:42:00 <andythenorth> lol no
14:42:09 <andythenorth> cargo subtypes for starters πŸ˜›
14:42:14 <andythenorth> for liveries
14:45:11 <petern> Cargo subtypes aren't relevant.
14:45:36 <andythenorth> nah but vehicle sets define their own cargo sometimes
14:45:47 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #10725: Codechange: [CMake] Switch GRF generation from NFO to NML
14:45:57 <andythenorth> ok I have some regrets about certain design choices πŸ˜›
14:45:58 <andythenorth> nvm
14:46:20 <petern> Vehicles are already mapped.
14:46:36 <petern> This is just about houses/industries.
14:47:17 <TallTyler> Tea Tea Deluxe is an example of only defining some cargos
14:47:27 <TallTyler> Unless that’s not what you mean
14:48:52 <petern> No, I mean defining an industry, but relying the on default values from the overridden type instead of setting them.
14:50:06 <glx[d]> like when fixing acceptance of original industries ?
14:50:41 <andythenorth> I regret this:
14:50:54 <petern> Perhaps.
14:51:24 <petern> It's fine, I've decided to use a uint16_t for each cargo slot, as there are only 16 slots that can be set, it's simple enough to just do it right.
14:56:14 <petern> Damn, now that I need an index I can't use a nice simpler iterator 😦
14:56:47 <andythenorth> uuf I am making Horse compile slower 😦
14:56:55 <andythenorth> adding variants has increased compile time by about 0.5s
14:57:00 <petern> Is it now 10 seconds?
14:57:05 <andythenorth> nearly 17s
14:57:41 <andythenorth> I wonder if a faster laptop can solve it
14:58:02 <petern> Apple M2 pro plus?
14:58:14 <andythenorth> not sure it's faster
14:58:24 <andythenorth> Pro Max Ultra Elite Ultimate
15:02:18 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:03:27 *** WormnestAndroid has joined #openttd
15:06:32 <petern> Or I can use pointer arithmatic... Hmm.
15:11:23 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:12:06 *** WormnestAndroid has joined #openttd
15:12:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
15:13:53 <TrueBrain> right, created the survey collector; it doesn't analyze it, but it does collect it. That means I can receive survey results with the above PR ... now I need some diversity .. so who is up for compiling the above PR, and loading in a few of their games for me? πŸ™‚
15:16:08 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:16:34 *** WormnestAndroid has joined #openttd
15:17:30 <TrueBrain> it also collects a survey when the game crashes, so feel free to throw those in the mix too πŸ™‚
15:17:31 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:17:37 *** WormnestAndroid has joined #openttd
15:18:03 <Eddi|zuHause> dunno if i find a way to crash the game on the spot :p
15:18:26 <Eddi|zuHause> we once had a "crash the game" button in debug builds, right?
15:18:38 <glx[d]> alt-0
15:19:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10719: Feature: opt-in survey when exiting a game
15:20:50 <andythenorth> do I need to install new deps?
15:20:50 <andythenorth> `Findnlohmann_json.cmake`
15:21:23 <TrueBrain> yes, `vcpkg install nlohmann-json`
15:21:35 <andythenorth> nah don't have vcpkg πŸ˜›
15:21:42 <TrueBrain> what-ever package manager you use πŸ˜›
15:24:50 <TrueBrain> the thing that is mostly tricky I noticed, is how to prevent abuse .. I put some things in place, but .. it is hard to do properly πŸ™‚ Will have to see what I can do more πŸ™‚
15:25:10 <andythenorth> wonder if today is the day I have to reinstall my OS
15:25:30 <TrueBrain> `brew install nlohmann-json` will work fine too andythenorth
15:25:38 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
15:26:12 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10726: Fix: Moving cargo definition slots prevents normal town/industry behaviour.
15:26:52 *** WormnestAndroid has joined #openttd
15:26:53 <glx[d]> maybe transmission should be disabled for debug builds
15:27:24 <TrueBrain> glx[d]: yeah, I initially planned that it would only send surveys when you know a certain secret
15:27:31 <TrueBrain> the issue there a bit is with Linux distros
15:27:47 <TrueBrain> they build from source .. so they can't participate?
15:28:27 <petern> Participate but not authenticated as official build. But that probably doesn't add anything.
15:28:32 <TrueBrain> so I am kinda assuming the amount of development builds are far far less than anything else
15:28:40 <TrueBrain> petern: well, that is what I did now
15:28:54 <TrueBrain> official builds have a secret, so we know that survey is produced by a build we made
15:29:02 <TrueBrain> and all others have a default value there
15:29:13 <TrueBrain> but I didn't want to actual disable it
15:29:29 <TrueBrain> it just does mean it will also capture surveys we make, as developers πŸ™‚
15:29:47 <TrueBrain> but as long as we don't use an official version while we aren't, that should be fine πŸ˜›
15:30:56 <TrueBrain> the biggest abuse I worry about, is some ... not-so-nice-person to run a `curl` in a loop, posting tons of surveys
15:31:03 <TrueBrain> we will filter them out in the analytic, that isn't the issue
15:31:30 <TrueBrain> but ideally I also make the collector refuse those survey results .. but this is tricky πŸ™‚
15:32:31 <andythenorth> fail2ban
15:34:54 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
15:35:00 <petern> Hmm, I need to purchase more salad materials again.
15:36:16 <andythenorth> yair build fails for me
15:36:23 <andythenorth> might be time to reinstall
15:36:26 *** WormnestAndroid has joined #openttd
15:36:30 <TrueBrain> fails how?
15:37:09 <glx[d]> do you want a step by step guiding for vcpkg ?
15:37:16 <andythenorth> `/opt/homebrew/include/nlohmann/detail/conversions/to_chars.hpp:1071:14: error: expected unqualified-id
15:37:16 <andythenorth> if (std::signbit(value))`
15:37:18 <andythenorth> etc
15:37:26 <Eddi|zuHause> what am i supposed to be doing to send the survey?
15:37:35 <glx[d]> first step being do remove anything from your current setup
15:37:47 <TrueBrain> meh, nlohmann fails to build? That is annoying ...
15:38:00 <andythenorth> TrueBrain: assume my build env doesn't work
15:38:03 <glx[d]> seems to be the same issue you have with format.h
15:38:07 <andythenorth> it's been relying on patches for a long time
15:38:08 <TrueBrain> Eddi|zuHause: open savegames, play the game, exit (in what-ever-way) .. it will auto-transmit whenever you leave a game
15:38:11 <petern> TrueBrain: it's the same error he has with fmt, it's his system πŸ™‚
15:38:19 <TrueBrain> okay, I will walk away then πŸ˜„
15:38:22 <andythenorth> yes
15:38:32 <Eddi|zuHause> TrueBrain: and where's the opt-in part?
15:38:44 <glx[d]> it's brew doing nasty stuff with include folders I think
15:38:55 <TrueBrain> Eddi|zuHause: read the PR description?
15:39:16 <Eddi|zuHause> why would i do that? next thing is you ask me to read the manual :p
15:40:38 <Eddi|zuHause> can i somehow verify if my survey was sent?
15:41:08 <TrueBrain> if you enable `-dnet=1` you see if it sends and if it is successful
15:41:13 <TrueBrain> but it is meant to be mostly invisible
15:42:00 <glx[d]> andythenorth: should be fine to start
15:42:19 <TrueBrain> okay, added a rate-limit .. you can only send 1 survey every 10 seconds now πŸ™‚
15:42:32 <TrueBrain> that was far easier than I expected πŸ˜„
15:42:42 <glx[d]> oh that's a high frequency
15:43:17 <Eddi|zuHause> i'm not a DDoS expert :)
15:43:36 <TrueBrain> Eddi|zuHause: and ofc make sure you install nlohmann-json; it mentions this during CMake, but without it, it currently silently opts out of the survey
15:43:57 <Eddi|zuHause> i did install, and ran cmake again
15:44:05 <andythenorth> ok so to confirm, vcpkg will provide an isolated build environment, and I don't first need to remove all the brew / Apple Xcode crap?
15:44:17 <glx[d]> exact
15:44:37 <glx[d]> vcpkg stuff is contained inside vcpkg folder
15:44:48 <glx[d]> and you tell cmake where to look
15:45:23 <glx[d]> you explicitely use vcpkg
15:45:29 <andythenorth> ok so I have vcpkg from last time I tried this
15:46:50 <glx[d]> just rerun cmake with `-DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake` and the usual flags you may need
15:47:03 <glx[d]> like CMAKE_BUILD_TYPE πŸ˜‰
15:48:54 <TrueBrain> okay, made the rate limit 1 request per minute .. that alone is more than sufficient
15:49:11 <DorpsGek> [OpenTTD/team] IverCoder commented on issue #419: [fil_PH] Translator access request
15:50:14 <andythenorth> hmm
15:50:24 <andythenorth> yeah no build fails
15:50:36 <andythenorth> how do I test if it's using vcpkg?
15:50:52 <andythenorth> it's getting crap from the XCode SDK
15:50:58 <andythenorth> so it's not using vcpkg?
15:51:00 <DorpsGek> [OpenTTD/team] TrueBrain commented on issue #419: [fil_PH] Translator access request
15:51:03 <DorpsGek> [OpenTTD/team] TrueBrain closed issue #419: [fil_PH] Translator access request
15:51:14 <andythenorth> might need a separate system for building OpenTTD, without xcode?
15:51:24 <glx[d]> you should see vcpkg in cmake output
15:51:33 <DorpsGek> [OpenTTD/team] TrueBrain commented on issue #415: No ka_GE language for translation/Georgian addition
15:51:36 <DorpsGek> [OpenTTD/team] TrueBrain closed issue #415: No ka_GE language for translation/Georgian addition
15:54:10 <andythenorth> hmm
15:54:15 <glx[d]> lines like ` -- Found ZLIB: optimized;/usr/local/share/vcpkg/installed/arm64-osx/lib/libz.a;debug;/usr/local/share/vcpkg/installed/arm64-osx/debug/lib/libz.a (found version "1.2.13")`
15:54:26 <andythenorth> nah it's using homebrew
15:54:30 <andythenorth> and XCode
15:54:52 <andythenorth> I've removed the build dir several times and rerun cmake
15:54:53 <andythenorth> `cmake -DCMAKE_TOOLCHAIN_FILE=../../vcpkg/scripts/buildsystems/vcpkg.cmake ..`
15:55:16 <andythenorth> var isn't used by cmake
15:55:28 <andythenorth>
15:56:06 <andythenorth> I tried changing the order of parameters to cmake
15:56:28 <glx[d]> try with full path
15:56:44 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #10741: [Bug]: Train crash within station platform does not unreserve entire platform following wreck removal
15:57:04 <glx[d]> oh now, another reservation bug
15:57:20 <TrueBrain> remove PBS? πŸ˜›
15:57:29 <JGR> I expect that this is an old one, not anything new
15:57:46 <glx[d]> biggest issue is reservation is not tied to a vehicle
15:57:50 <andythenorth> glx[d]: it doesn't throw the warning about manual var now, but still using brew / Xcode
15:58:11 <andythenorth> nothing about vckpg
15:58:13 <glx[d]> using xcode is fine (the compiler is there)
15:58:56 <andythenorth> but the broken format headers are due to XCode I think
15:59:00 <andythenorth> Apple have broken them
15:59:01 <DorpsGek> [OpenTTD/team] IverCoder commented on issue #419: [fil_PH] Translator access request
15:59:04 <andythenorth> afaict
15:59:12 <glx[d]> like `-- Found Iconv: /Applications/`
15:59:41 <andythenorth> yes
15:59:44 <DorpsGek> [OpenTTD/team] TrueBrain commented on issue #409: [it_IT] Translator access request
15:59:47 <DorpsGek> [OpenTTD/team] TrueBrain closed issue #409: [it_IT] Translator access request
15:59:58 <andythenorth> 13.1 SDK, but yes
16:00:27 <DorpsGek> [OpenTTD/team] TrueBrain commented on issue #361: [ro_RO] Translator access request
16:00:48 <glx[d]> the issue you have (without vcpkg) I think is brew adding an unwanted includedir flag
16:01:39 <glx[d]> not brew directly though, but a lib it provides
16:03:40 <glx[d]> what do you get for `vcpkg list` ?
16:03:49 <Eddi|zuHause> dbg: [net] Survey: sending survey results
16:03:50 <Eddi|zuHause> dbg: [net] Survey: failed to send survey results
16:04:30 <andythenorth> glx[d]: nothing, command not found
16:04:36 <andythenorth> I'm going to reinstall vcpkg
16:04:48 <glx[d]> you need to run it from vcpkg dir probably
16:05:39 <DorpsGek> [OpenTTD/team] NorwayFun commented on issue #415: No ka_GE language for translation/Georgian addition
16:06:27 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
16:07:15 <andythenorth> `No packages are installed. Did you mean `search`?`
16:07:55 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
16:08:49 <glx[d]> andythenorth: expected if it's a clean install
16:10:08 <TallTyler> lol, build before push
16:10:21 <TallTyler> Broke some #includes
16:10:50 <Rubidium_> and don't forget to run the tests ;)
16:11:12 <glx[d]> `vcpkg install liblzma libpng lzo zlib`
16:11:12 <TallTyler> Unit or regression?
16:11:17 <Eddi|zuHause> -- Could NOT find CURL (missing: CURL_LIBRARY CURL_INCLUDE_DIR)
16:11:24 <Eddi|zuHause> not sure if that's the problem...
16:11:28 <Rubidium_> TallTyler: both, e.g. ctest
16:11:57 <TallTyler> Will do πŸ™‚
16:12:11 <Eddi|zuHause> also i'm not finding what package i'm missing there...
16:12:51 <glx[d]> it's curl
16:13:05 <glx[d]> added as a dep some times ago
16:13:10 <Eddi|zuHause> i think i found it
16:13:26 <andythenorth> ok vcpkg install is failing with brew errors
16:13:26 <glx[d]> (not needed for windows though)
16:13:28 <andythenorth> quite long ones πŸ˜›
16:14:23 <andythenorth> ok it's asking me to install things via brew
16:14:30 <andythenorth> expected?
16:15:01 * andythenorth reads about it
16:15:28 <glx[d]> for CI we do <> then <>
16:16:00 <andythenorth> ok that looks pretty similar
16:16:09 <glx[d]>
16:16:24 <TrueBrain> Eddi|zuHause: Time to go to net=4 πŸ™‚ or even 6!
16:16:52 <TrueBrain> Owh, you found it already πŸ˜‰
16:17:37 <Eddi|zuHause> well... i'll try again and see
16:17:45 <glx[d]> curl is needed since https addition
16:17:46 <andythenorth> ok cmake is now using vcpkg not brew
16:17:52 <glx[d]> good
16:17:54 <andythenorth> still failing on broken header stuff
16:17:58 <andythenorth> includes
16:18:09 <andythenorth> ok, so reinstall my OS time?
16:18:13 <Eddi|zuHause> i probably didn't compile in over a year
16:18:39 <glx[d]> weird if it's also fail with vcpkg
16:18:45 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
16:18:48 <andythenorth> it's probably broken by Apple
16:18:52 <andythenorth> which SDK do we compile against?
16:18:59 <glx[d]> 10.13
16:20:24 <andythenorth> googling suggests stdlib is broken on macOS
16:20:52 <glx[d]> -- Check for working CXX compiler: /Applications/
16:21:00 <glx[d]> that's what CI uses
16:22:47 <andythenorth> remains puzzling πŸ™‚
16:25:07 <glx[d]> <> <-- that's all stuff present by default in the CI
16:25:40 <andythenorth> thanks
16:25:49 <andythenorth> might just have to wait for Apple to unbreak it
16:26:52 <Eddi|zuHause> dbg: [net] Survey: sending survey results
16:26:53 <Eddi|zuHause> dbg: [net] HTTP request succeeded
16:26:55 <Eddi|zuHause> dbg: [net] Survey: received survey results
16:27:11 <glx[d]> it really seems local to your system
16:28:19 <andythenorth> all I have is brew and XCode
16:28:32 <andythenorth> both had to be reinstalled last time I tried to use vcpkg, so they're recent
16:32:50 <glx[d]>
16:34:18 <andythenorth> looks relevant
16:34:56 *** gelignite has joined #openttd
16:35:51 <glx[d]> and also <>
16:37:12 <andythenorth> some of these issues are not new
16:37:57 <andythenorth> I had a previous fix in 2021, with comment ""it seems two things can break OSX: homebrew via /usr/local/include, or CMake because of bad broken library detection inserting too many -isystem in the wrong places""
16:38:17 <andythenorth> fix then was passing some flag to clang
16:39:04 <andythenorth> hmm some of the 'fixes' seem to involve creating symlinks to dirs
16:39:12 <andythenorth> this is generally how future me regrets previous me
16:39:14 <andythenorth> not doing that
16:39:40 <glx[d]>
16:39:44 <Eddi|zuHause> i wonder if you can circumvent the 255 varactions limit with procedures
16:39:56 <glx[d]> this answer looks sane
16:40:12 <andythenorth> Eddi|zuHause: no
16:40:31 <glx[d]> possibly, but each procedure will reserve some ids
16:40:52 <andythenorth> nmlc can't do it
16:41:07 <andythenorth> it will fail trying to span action 2 IDs across the entire parse tree
16:41:38 <glx[d]> nmlc tracks used ids
16:41:49 <glx[d]> ie referenced
16:42:14 <glx[d]> but once they go out of scope they're free
16:42:39 <glx[d]> main issue is nmlc doesn't reorder
16:43:19 <glx[d]> so if you define procedures way before first use it will eat IDs even when not really needed
16:44:00 <andythenorth> switching SDK produces different errors πŸ™‚
16:44:16 <glx[d]> I call that a progress πŸ™‚
16:45:32 <petern> Steal a bit from the feature byte and use it to indicate that IDs are words instead of bytes.
16:45:42 <petern> Or... bump grf version πŸ˜„
16:46:14 <andythenorth> petern: Nooooooooo
16:46:21 <andythenorth> then this function wouldn't be needed 😦
16:46:23 <glx[d]> extended byte would be nice, but FF was not reserved
16:46:27 <andythenorth> "all my work wasted"
16:46:58 <glx[d]> and the "fun" part IIRC is varact2 ranges use 16 bits
16:47:32 <glx[d]> well 15
16:47:46 <glx[d]> because bit 15 has special meaning
16:47:54 <petern> Even the default group is a word, not a byte.
16:49:05 <glx[d]> hmm bit 8 of feature to say id is 15 bits could work
16:49:38 <petern> Ah yeah, bit 15 means callback.
16:50:06 <glx[d]> but 7 more bits for IDs would be a lot πŸ™‚
16:50:11 <petern> Yes
16:50:50 <petern> What was it we were looking at last time, with the sprite group type byte?
16:51:20 <petern> Something about using type values between 0x80 and 0xFF, but I can't remember what.
16:54:31 <glx[d]> but using feature allows to more basic action 2 too, while type is specific to varact2
16:55:06 <petern> Yes, that was a different proposal for something else, not the ID limit. I can't remember anything else about it...
16:55:28 <glx[d]> oh it was for stations IIRC
16:57:24 <petern> Anyway, if we use a bit of feature, I'd suggest not directly using it to mean load 15 bit IDs.
16:58:08 <petern> Like make it load another bit of byte/word/etc of flags that then tell it to do that.
16:58:46 <petern> Or just replace it all with an .ini file πŸ˜„
16:59:14 <glx[d]> like if bit 8 read flags before reading set-id
16:59:32 *** Eddi|zuHause has quit IRC (Remote host closed the connection)
17:00:10 <petern> Something like that.
17:00:12 *** Eddi|zuHause has joined #openttd
17:00:32 <glx[d]> so 1 stolen bit gains many more info bits
17:00:51 <petern> Otherwise you steal 1 bit and then hit a wall if you ever need to add something later.
17:00:58 <petern> However unlikely πŸ™‚
17:01:23 <glx[d]> you never know whan newgrf limits will hit you πŸ™‚
17:01:58 <glx[d]> oh and this mecanism could be applied to all actions
17:02:24 <petern> Yeah, although "set-id" is sometimes an extended byte.
17:02:31 <glx[d]> well all actions using feature
17:02:45 <petern> I guess you set the same flag and then it could make it be a word instead, for whatever.
17:03:00 <petern> (Consistency)
17:03:13 <glx[d]> I mean bit 8 of feature => read flags
17:03:29 <petern> Yes
17:03:33 <glx[d]> then flags can have a different meaning depending on action
17:04:19 <glx[d]> but that give room for many future ideas
17:04:56 <petern> Also, are we numbering bits from 0-7 or 1-8 now? πŸ˜„
17:05:14 <glx[d]> well
17:05:29 <glx[d]> it's 8th bit πŸ™‚
17:06:30 <glx[d]> main advantage is full backward compatibility
17:08:08 <petern> I just noticed that NewSpriteGroup is quite odd in that you can only define 1 ID at a time.
17:08:18 <glx[d]> disavantage might be the need to touch renum or grfcodec πŸ˜‰
17:08:23 <petern> Most other actions allow defining multiples
17:10:24 <glx[d]> oh with a flag you can allow a different behaviour
17:11:22 <glx[d]> first-id, number of sets, list of loading/loaded
17:14:25 <glx[d]> basically with just stealing one bit of feature, it's possible to redefine many action format
17:15:53 <JGR> How is that better than defining a v9 format where set-id is a word and any such things?
17:16:59 <glx[d]> with a flag you could have different basic action 2 for stations, one for the cargoes, one for the spritelayouts
17:18:55 <andythenorth> "now we release often, we could grf v9"
17:19:02 * andythenorth connects unconnected things
17:19:14 <JGR> I'm not really sure I follow why that should be encoded through the feature byte
17:20:46 <JGR> Or how that maintains full backwards compatibility?
17:21:37 <glx[d]> it won't change anything for existing newgrfs
17:24:06 <andythenorth> ach, reinstalled XCode tools, still fails
17:24:14 <andythenorth> think this is unsolvable πŸ˜›
17:24:29 <glx[d]> fully uninstalled XCode first ?
17:26:01 <andythenorth> no, that's the next step
17:26:06 <andythenorth> install is quite long
17:26:58 <glx[d]> is homebrew up to date ?
17:27:07 <glx[d]>
17:30:56 <andythenorth> says so
17:31:07 <andythenorth> waiting for reinstalls currently on the Apple tools
17:32:01 <glx[d]> could also be an env var set a long time ago
17:34:19 *** TdMast has joined #openttd
17:34:33 *** TdMast has quit IRC ()
17:34:59 <andythenorth> yup
17:35:04 <glx[d]> <> <-- this answer seems to be the most aggressive one
17:35:06 <andythenorth> might be a way to print env vars?
17:35:14 *** NGC3982 has quit IRC (Ping timeout: 480 seconds)
17:35:31 <andythenorth> think I tried `sudo rm -rf /usr/local/include` last time but eh
17:36:44 <JGR> That seems like a bit of an aggressive fix
17:40:24 <andythenorth> I don't think it will fix it TBH, but we'll see
17:40:34 <andythenorth> I suspect we just can't build on M1 any more
17:41:06 <andythenorth> or at some point I've made an ln or env var to fix a failing compile, and now it's a source of problems
17:43:31 <glx[d]> oh I did a second look at #10325
17:44:41 <glx[d]> error says `/Applications/` but command line uses `-isystem /Applications/`
17:45:03 <glx[d]> seems it's using different SDK at the same time
17:45:25 <andythenorth> ok so `sudo rm -rf /usr/local/include` leaves brew quite broken
17:45:40 <glx[d]> not surprising
17:46:08 <glx[d]> the answer should have been uninstall, rm includes, install
17:50:45 <andythenorth> ok removing everything
17:50:56 <andythenorth> I think this ends in blanking my mac and reinstalling though
18:01:47 <andythenorth> `CPATH=/Applications/`
18:01:48 <andythenorth> suspicious?
18:04:37 <andythenorth> ha I found legacy path 'fixes' in .zshrc πŸ™‚
18:04:41 <andythenorth> this might be promising
18:04:55 <andythenorth> but currently I deleted all dev tools, so I can't test for about 1 hr πŸ˜›
18:15:44 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
18:16:03 *** WormnestAndroid has joined #openttd
18:20:08 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
18:24:54 *** WormnestAndroid has joined #openttd
18:26:35 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10519: Feature: Filter engine build menu by name and NewGRF extra text
18:33:40 <andythenorth> ok I can build grfs again πŸ˜›
18:33:40 <andythenorth> oof
18:35:32 <pickpacket> Yay!
18:42:16 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
18:42:17 <DorpsGek> - Update: Translations from eints (by translators)
18:43:05 <glx[d]> andythenorth: I think you found the responsible
18:43:21 <andythenorth> I now have quite a broken environment though
18:43:29 <andythenorth> I need to fix some things πŸ˜›
18:43:50 <andythenorth> brew won't stay added to the path
18:43:56 <andythenorth> so nothing installed with brew is found
18:44:04 <andythenorth> grfcodec
18:46:06 <andythenorth> ok, many warnings but master openttd built
18:46:06 <andythenorth> I think this might be the culprit for build
18:46:06 <andythenorth> `# make headers work on Catalina
18:46:06 <andythenorth> # export CPATH=`xcrun --show-sdk-path`/usr/include`
18:46:16 <andythenorth> was in my .zshrc, I've commented it
18:46:30 <andythenorth> but also I completely removed some legacy brew paths
18:46:39 <andythenorth> could be either
18:49:33 <glx[d]> This Catalina fix seems mentioned as causing problems on the stackoverflow page
18:51:53 <andythenorth> fixes always cause trouble later
18:55:56 <andythenorth> at the risk of problems later, can I make the path to vcpkg permanent, instead of having to pass the cmake parameter every time?
19:01:02 *** Wormnest has joined #openttd
19:01:04 <andythenorth> lol my OS is now reporting itself broken
19:01:05 <andythenorth> but eh
19:01:15 <petern> Have you started reinstalling yet?
19:01:39 <andythenorth> no
19:01:43 <petern> Hmm, shall I use stdint types...
19:02:12 <TrueBrain> duh
19:02:57 <andythenorth> so many clang warnigns
19:03:04 <andythenorth> wonder if I can suppress them
19:03:06 <andythenorth> `clang: warning: argument unused during compilation: '-mno-sse4' [-Wunused-command-line-argument]`
19:03:20 <andythenorth> for almost every single file
19:03:52 <TrueBrain> oeh, let's see if building custom binaries via CI still works ..
19:03:56 <TrueBrain> haven't tried that in a long time πŸ™‚
19:04:44 <TrueBrain> andythenorth: should be skipped for arm64 .. you have arm64, not?
19:04:54 <andythenorth> yes
19:05:01 <andythenorth> might need some cmake flags or so
19:05:28 <TrueBrain> `-DCMAKE_OSX_ARCHITECTURES=arm64` might help
19:07:03 <andythenorth> thanks I'll try
19:07:11 <andythenorth> meanwhile, I've got 10719 built and running
19:07:22 <andythenorth> do I need to do anything to send results?
19:07:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10742: Fix: [CI] typo in Windows release jobname
19:07:44 <TrueBrain> andythenorth: play the game! As by PR description, every time you leave a game, in what-ever way, it will send the survey result
19:07:48 <TrueBrain> assuming everything compiled correctly πŸ˜„
19:07:52 <andythenorth> yup
19:10:38 <TrueBrain> you forgot to install nlohmann-json, didn't you? πŸ˜›
19:10:48 <andythenorth> yes, but it didn't error on first build
19:11:04 <TrueBrain> no, these libraries are optional
19:11:07 <TrueBrain> so it just builds
19:12:04 <TrueBrain> I might add the `ENCOURAGE` flag to curl and nlohmann-json, so it is a bit more visible you will be missing out πŸ˜›
19:12:15 <TrueBrain> but by no means either of those libraries are mandatory
19:12:28 <TrueBrain> which, as with our other dependencies, can be a bit annoying πŸ™‚
19:12:33 <glx[d]> you need curl too
19:12:45 <TrueBrain> that is why they are in the same sentence, yes πŸ™‚
19:13:06 <glx[d]> now I see it πŸ™‚
19:13:09 <TrueBrain> πŸ˜„
19:13:43 <glx[d]> but the json lib having a long name it hid curl πŸ˜‰
19:14:33 <petern> `uint16 GetID(uint16_t grf_local_id, uint32 grfid) const override;`
19:15:01 <petern> So I converted `byte grf_local_id` to `uint16_t grf_local_id`. Should I touch the others too?
19:15:13 <glx[d]> anyway we fixed andy's broken env, that's a good thing
19:15:43 <TrueBrain> that is a party on its own
19:15:50 <TrueBrain> CELIBRATION TIME, COME ON!
19:15:53 <TrueBrain> let's celebrate
19:16:43 <TrueBrain> ah, curl was already encouraged
19:16:54 <andythenorth> no more format patch πŸ˜›
19:16:55 <TrueBrain> in my next push, so will nlohmann-json .. Tyler is going to use it in his PR anyway πŸ™‚
19:16:58 <petern> `./vcpkg install nlohmann-json:x64-windows-static`
19:17:21 <TrueBrain> (and I will also update .. I forgot .. :D)
19:17:34 <andythenorth> I will forget, but typing `env` is a much faster way to find problem causes than _reinstalling the entire dev env_
19:17:34 <petern> I don't remember if it needed to be static or not, that's what the rest are.
19:17:35 <andythenorth> πŸ˜›
19:17:55 <TrueBrain> petern: static; as otherwise it is in a different folder
19:18:07 <TrueBrain> but the library itself is a header-only one, so it doesn't actually matter πŸ˜„
19:18:19 <TrueBrain> but vcpkg is really picky about all packages being in the same triplet πŸ˜›
19:18:29 <petern> I also have arm64-android, but never got as far as actually building with those...
19:18:46 <TrueBrain> still can't believe people play OpenTTD on mobile / tablet
19:18:48 <glx[d]> non static for all libs works too, just the resulting exe will only run locally
19:18:52 <TrueBrain> still feels weird πŸ˜„
19:19:13 <petern> Plug a mouse & keyboard in, it'll be fine πŸ˜„
19:19:16 <andythenorth> do I actually need Allegro or Doxygen?
19:19:21 <glx[d]> no
19:19:22 <petern> No
19:19:22 <TrueBrain> no
19:19:32 <andythenorth> echo in here? πŸ™‚
19:19:38 <TrueBrain> at least we all agree πŸ˜›
19:22:06 <andythenorth> lot of these, but eh, built `vcpkg/installed/arm64-osx/debug/lib/liblzma.a(index.c.o)) was built for newer macOS version (12.6) than being linked (11.0)`
19:23:08 <glx[d]> installed vcpkg libs before fixing the env stuff ?
19:23:29 <andythenorth> yes, I can clean them probably
19:23:31 <andythenorth> let's see
19:25:02 <glx[d]> ah and you build a debug openttd it seems πŸ˜‰
19:25:38 <glx[d]> as it links to the debug version of the libs
19:26:03 <andythenorth> yes, I didn't set release flag
19:26:15 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
19:26:30 <TrueBrain> TallTyler: that PR really is so much easier to read now πŸ™‚
19:27:08 <andythenorth> ha ha so many warnings about legacy strings for share buying πŸ™‚
19:27:42 <TrueBrain> Rubidium: sad news .. a release build tells me this:
19:27:45 <TrueBrain> `OpenTTD/src/string.cpp:793:47: error: cannot convert β€˜std::string_view’ {aka β€˜std::basic_string_view<char>’} to β€˜const icu_50::StringPiece&’`
19:28:03 <TrueBrain> (at least, I assume that is because of a recent change πŸ˜› )
19:28:39 <glx[d]> natural compare I guess
19:29:24 <glx[d]> ah yes it's even mentioned in the log
19:29:41 <TrueBrain> lol, and I was running the release-flow from `master`, so they all didn't actually install `nlohmann-json`, hihi .. silly me; so I am glad it failed πŸ™‚
19:30:16 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #10742: Fix: [CI] typo in Windows release jobname
19:30:52 <andythenorth> oh, still got linker warnings after reinstalling the vcpkg deps
19:30:58 <TrueBrain> guess Rb doesn't have icu-i18n installed .. can't blame him .. brr πŸ˜›
19:31:07 <TrueBrain> but also means our CI doesn't have it installed .. which is a bit more odd
19:31:32 <glx[d]> it's not available in debian ?
19:31:57 <TrueBrain> debian's libicu-dev doesn't seem to contain it
19:32:02 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10519: Feature: Filter engine build menu by name and NewGRF extra text
19:32:05 <TrueBrain> but CentOS's libicu-devel does
19:32:29 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10519: Feature: Filter engine build menu by name and NewGRF extra text
19:33:14 <TrueBrain> ah, no, version difference ofc
19:33:22 <glx[d]> the joy of icu
19:33:41 <TrueBrain> Rubidium: it does work with ICU 66.1, but not with 50.0
19:33:49 <Rubidium_> ldd openttd|grep icu => /usr/lib/x86_64-linux-gnu/ (0x00007f1394f2c000)
19:34:00 <TrueBrain> euh, 50.2. Sadly, we need 50.2 support for our generic linux binaries 😦
19:34:23 <TrueBrain> hmm .. let me check first if vcpkg ICU works these days .. as that might give us a newer version of ICU
19:37:44 <andythenorth> one more build πŸ˜›
19:37:50 <andythenorth> will it work without linker warnings?
19:38:38 <TrueBrain> takes a while to compile all vcpkg dependencies, so I will get back to you Rb πŸ™‚
19:39:28 <andythenorth> meh, still got linker warnings πŸ™‚
19:39:34 * andythenorth aborts that project
19:40:07 <glx[d]> the warnings are not a big problem
19:40:42 <andythenorth> just hides possible real errors
19:42:20 <andythenorth> TrueBrain: getting any results from me? πŸ˜›
19:42:34 <TrueBrain> I have 3 new entries in the last 20 minutes
19:42:49 <TrueBrain> wouldn't be able to tell you whos even if my life depended on it
19:43:29 <glx[d]> ah we set MACOSX_DEPLOYMENT_TARGET: 10.13 for all CI, so vcpkg and openttd target the same version
19:44:13 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
19:45:09 <glx[d]> and openttd cmakelists.txt uses set(CMAKE_OSX_DEPLOYMENT_TARGET 10.13)
19:45:20 <glx[d]> might explain your warnings
19:46:26 <glx[d]> I guess 10.13 target limits to 11.0
19:48:49 <glx[d]> but as long as it links I think it's ok, even with the warnings
19:49:38 <glx[d]> it just means your build might not work on a non 12.6 machine
19:51:50 <andythenorth> can I change any flag to eliminate them? just quite noisy
19:52:33 <TrueBrain> `src/c-72_1-src-deba61ed52.clean/source/configure: line 4548: syntax error near unexpected token '0.20'`
19:52:41 <TrueBrain> ah, yes, that was why `icu` was failing via vcpkg
19:53:07 <andythenorth> ok so now I can try modern patches πŸ˜›
19:53:15 <andythenorth> PRs from last 3 months or so πŸ˜›
19:53:27 <glx[d]> yes, you can vcpkg uninstall the libs, add an env var MACOSX_DEPLOYMENT_TARGET: 10.13 and install the libs
19:54:47 <glx[d]> the env var doesn't need to be permanent, just for installing openttd deps
19:59:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10742: Fix: [CI] typo in Windows release jobname
20:00:15 <glx[d]> IIRC we added this env var to the CI for the exact same reason
20:02:17 *** WormnestAndroid has quit IRC (Remote host closed the connection)
20:02:30 *** WormnestAndroid has joined #openttd
20:02:32 <TrueBrain> hmm, for once I found a package that is outdated on vcpkg .. `libuuid` is 1.0.3 on vcpkg, but 2.38.1 on most distros .. that is just 2 versions btw, the number is a lot bigger than the reality of it all πŸ˜„
20:05:09 <TrueBrain> hmm, seems `autoconf` kinda fails with ICU on `vcpkg`.. what can be the cause of that .. hmm
20:07:10 <TrueBrain> anyone with some decent knowledge about autconf here? πŸ™‚
20:07:51 <glx[d]> the thing that checks a lot of weird things magically ?
20:09:08 <TrueBrain> ah, when you install pkg-config, it installs autoconf rules
20:09:12 <TrueBrain> and those are not working
20:09:24 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #10743: Codechange: Pass more std::string to StringFilter::AddLine()
20:10:06 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10519: Feature: Filter engine build menu by name and NewGRF extra text
20:10:25 <TrueBrain> owh boy, now we have 2 people doing these conversions ........ πŸ˜›
20:16:49 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10743: Codechange: Pass more std::string to StringFilter::AddLine()
20:18:08 <andythenorth> hmm wonder if I can hash my game settings somehow to identify myself in the survey πŸ˜›
20:18:09 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10743: Codechange: Pass more std::string to StringFilter::AddLine()
20:22:02 <glx[d]> TallTyler: wondering if you compiled before push πŸ˜‰
20:22:29 <Rubidium_> maybe in the wrong folder? ;)
20:22:58 <petern> It's approved anyway πŸ˜‰
20:23:02 <LordAro> shipit
20:23:56 <glx[d]> well the diff looked fine without the CI fails
20:23:57 *** WormnestAndroid has quit IRC (Remote host closed the connection)
20:24:53 *** WormnestAndroid has joined #openttd
20:26:35 <DorpsGek> [OpenTTD/OpenTTD] TheMowgliMan commented on discussion #10738: Auto remove roads build by AI
20:29:44 <TrueBrain> yippie, fixed the ICU issues .. which means we might be able to update to a more recent ICU πŸ™‚ Let's confirm that first ...
20:30:56 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:33:21 <TrueBrain> so `aclocal` looks in `/usr/local/share/aclocal` first. If that doesn't exists, it tries `/usr/share/aclocal`. But by default both locations exists on CentOS 7, and the latter is used for everything important
20:33:24 <TrueBrain> that is just great πŸ™‚
20:37:38 <TrueBrain> didn't know how autoconf worked, didn't want to know .. and I am scared. Happy we never went for that, and that we are now using CMake πŸ™‚
20:38:29 <glx[d]> yeah and it's so easy to write stuff with cmake
20:40:05 <TrueBrain> owh, the nightly is now broken too ofc πŸ˜„ Well, I think I have a PR to fix that after I confirmed it actually works πŸ˜„
20:41:21 <glx[d]> I though you noticed the nightly failure
20:41:33 <TrueBrain> no, I started my own build for my survey PR πŸ™‚
20:41:39 <glx[d]> lol
20:47:06 <TrueBrain> compiling vcpkg + OpenTTD takes FOR EVER
20:47:35 <TrueBrain> anyway, received 7 surveys so far; much appreciated πŸ˜„
20:47:58 <TrueBrain> will need many more to create proper analytics, but at least now I can build something to get started πŸ™‚
20:49:28 <TrueBrain> `Unknown ICU component: data`
20:49:30 <TrueBrain> hmmmmmmmmm
20:52:44 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler dismissed a review for pull request #10743: Codechange: Pass more std::string to StringFilter::AddLine()
20:52:47 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10743: Codechange: Pass more std::string to StringFilter::AddLine()
20:53:00 <TallTyler> Builds properly now πŸ˜‰
20:53:09 *** dP has joined #openttd
20:53:09 <dP> wonder if there is a way for survey to find how many players couldn't find how to create the new company...
20:53:17 <dP> I'm getting tired of answering that question...
20:53:37 <dP> considering to add that to server welcome
20:53:44 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:53:48 <dP> on citymania hardest server no less 🀣
20:54:46 <TallTyler> Not sure if there's a better alternative to my change to `strings.cpp` but 🀷
20:55:09 <TallTyler> TrueBrain: I'm done with these now, I think πŸ˜›
20:55:21 <TrueBrain> that aint fun!
20:55:29 <TallTyler> I have other places to make a mess of
20:55:57 <TallTyler> Once the calendar/economy split is merged, it's time for Real-Time Mode!
20:56:21 <TallTyler> Hopefully I can start on that tomorrow πŸ™‚
20:56:46 <TrueBrain> yeah, I will take a better look if I agree with your choices of Timer tomorrow πŸ˜„
20:56:48 <glx[d]> TallTyler: doing it the sane way is a rabbit hole πŸ™‚
20:56:51 <TrueBrain> requires a less sleepy brain πŸ˜„
20:57:01 <TallTyler> For sure, no rush πŸ˜„
20:59:38 <TrueBrain> how do I know if ICU is actually working correctly? Hmm
21:00:02 <glx[d]> change language
21:00:27 <TrueBrain> yeah ... still the same question πŸ˜„
21:00:37 <TrueBrain> owh, I got a popup with an error
21:00:39 <TrueBrain> guess that πŸ˜„
21:01:02 <TrueBrain> so yeah ... ICU-lx isn't there
21:01:13 <TrueBrain> i18n is
21:01:26 <glx[d]> lx is for the layout
21:01:29 <glx[d]> IIRC
21:01:32 <TrueBrain> yup
21:01:37 <glx[d]> the thing they removed
21:02:19 <TrueBrain> right, harfbuzz I guess I need to install before icu to get that working .. at least .. I think that might do the trick ..
21:02:21 <glx[d]> some harfbuzz thing replaces it I think
21:03:57 <glx[d]> for some reason it reminds me of <> πŸ™‚
21:04:22 <TrueBrain> it just never happens πŸ˜›
21:05:39 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:08:22 <glx[d]> there's a circular dependency between harfbuzz and icu IIRC
21:08:55 <TrueBrain> yeah .. and normally that isn't a real problem
21:08:59 <TrueBrain> but it seems I didn't install harfbuzz
21:10:01 <TrueBrain> vcpkg disables it
21:10:03 <TrueBrain> meh πŸ˜›
21:10:04 <glx[d]> vcpkg has harfbuzz[icu]
21:10:25 <TrueBrain> owh, that might do the trick, nice
21:10:48 <glx[d]> harfbuzz[icu] icu support for harfbuzz
21:11:46 <TrueBrain> and this is how all of a sudden you spend an whole evening looking at CI results .. ugh πŸ˜›
21:12:31 <glx[d]> just blame ICU πŸ˜‰
21:12:46 <TrueBrain> I blame Rubidium for showing me we were still using an old ICU πŸ˜›
21:12:48 <TrueBrain> πŸ˜„ πŸ˜„ ❀️
21:13:18 <glx[d]> ICU breaks whenever a new version is out
21:13:26 <TrueBrain> it hasn't for a while now
21:13:28 <TrueBrain> which is nice
21:13:59 <glx[d]> because we stopped making .deb πŸ˜‰
21:14:17 <TrueBrain> and I celebrate that every day πŸ™‚
21:15:02 <glx[d]> if we had so many deb builds it was because ICU
21:15:17 <glx[d]> and versioning in function names
21:16:35 <glx[d]> it's just annoying to need to rebuild exe because a lib is updated
21:18:21 <TrueBrain> `Could NOT find ICU (missing: data) (found version "72.1")`
21:18:27 <TrueBrain> that `data` is always a bit of a PITA too
21:18:47 <TrueBrain> anyway, still no ICU-lx
21:19:15 <TrueBrain> as that command installs `harfbuzz-icu`
21:21:06 <TrueBrain>
21:21:49 <petern> :/
21:24:03 <TrueBrain> owh, yeah, right ... harfbuzz needs ICU to compile, and ICU-lx needs harfbuzz .. I see why this is a bit of an issue for vcpkg to do properly πŸ™‚
21:24:52 <glx[d]> it's an issue for most package managers
21:30:06 <Rubidium_> TrueBrain: well, we're also targetting an old OSX
21:30:34 <TrueBrain> sorry, I miss the context to understand that remark?
21:30:55 <glx[d]> support of outdated things πŸ˜‰
21:31:02 <Rubidium_> you blamed me for making you aware we are using an old ICU
21:31:42 <TrueBrain> meh; I never really looked into this whole ICU issue, but boy, it is .. worse than I expected πŸ˜„
21:31:47 <Rubidium_> so, just to let you know... the 10.13 target does not support all features of C++17; I've hit that problem twice the last few weeks
21:32:07 <glx[d]> switch back to 10.14 then πŸ˜‰
21:33:07 <TrueBrain> we only have it on 10.13 because "there was no reason not to"
21:33:37 <TrueBrain> I am sure you can convince michi_cc easily to increase that number if you run into clear issues πŸ˜„
21:33:58 <glx[d]> we switched to 10.14 for std::variant, and someone later said it was fine with 10.13 too
21:34:20 <glx[d]> it was 10.9 before that
21:34:46 <petern> #10253
21:35:16 <TrueBrain> so, the main thing ICU(-lx) gives that harfbuzz doesn't, is multiline support
21:35:53 <Rubidium_> glx[d]: need 10.15, or at least that's what the error message said
21:37:46 <Rubidium_>
21:39:10 <glx[d]> oh std::filesystem
21:39:32 <Rubidium_>
21:39:33 <TrueBrain> OSX and std::filesystem .. I believe there were some ... "minor" issues with that πŸ˜„
21:42:11 <TrueBrain> okay, I give up, I won't be able to compile icu-lx without losing my sanity via vcpkg
21:42:22 <TrueBrain> so we will need to see if we can fix up the compile-error I guess πŸ™‚
21:42:54 <TrueBrain> ideally we remove icu-lx and switch to harfbuzz + icu, but .. yeah .. might be a bit much πŸ™‚
21:45:44 <TrueBrain> guess putting it in a `std::string` would solve it for now
21:46:15 *** axet has quit IRC (Quit: Leaving.)
21:47:50 <Rubidium_> TrueBrain: it should, just selectively do that for ICU < 65
21:48:19 <TrueBrain> I wouldn't know how to do things selectively for a certain ICU version πŸ™‚
21:48:25 <TrueBrain> so if you know how, please make it so πŸ™‚
21:49:52 <TrueBrain> I am trying to understand how our layout process works, but ... brrrrrrrr
21:53:58 *** michi_cc[d] has joined #openttd
21:53:58 <michi_cc[d]> All this ICU layout jiggery-pokery was the main reason I sat down to figure out Uniscribe and CoreText for layout.
21:54:13 <TrueBrain> yeah, that was a good move
21:54:23 <TrueBrain> guess there are no other solutions on Linux?
21:56:25 <michi_cc[d]> No idea. I think most browsers (well, Chrome and Webkit/KHTML, nothing else really left) use something like self-rolled layout with maybe Harfbuzz. Lot's of other software might just not handle layout proberly.
21:56:26 <TrueBrain> hmm ... icu-lx doesn't seem to exist on Ubuntu anymore πŸ˜›
21:56:53 <glx[d]> well it doesn't exist in ICU itself
21:56:58 <TrueBrain> `found components: i18n missing components: lx`
21:57:00 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10744: Fix c8299304: retain support ICU < 65, even though at a small performance penalty
21:57:05 <michi_cc[d]> Is there even any standard solution for IME language input for Linux?
21:57:31 <TrueBrain> doubtful
21:57:47 <TrueBrain> Rubidium: just to check-validate, do you have icu-lx on Linux?
21:58:57 <TrueBrain> I installed the `le-hb` package, but OpenTTD looks for lx, and doesn't find it
22:00:35 <TrueBrain> haha, official Debian release doesn't support it either πŸ™‚
22:00:57 <TrueBrain> it does work on our official releases, because we build against a really old ICU πŸ˜›
22:01:46 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10744: Fix c8299304: retain support ICU < 65, even though at a small performance penalty
22:02:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10744: Fix c8299304: retain support ICU < 65
22:03:13 <Rubidium_> oh, I changed it...
22:03:19 <TrueBrain> I know; I tested that version
22:03:36 <TrueBrain> the other one .. I was about to comment you can just use the std::string
22:03:40 <TrueBrain> no need to go to c_str πŸ™‚
22:03:43 <TrueBrain> but this is better πŸ˜„
22:04:37 <TrueBrain> but okay .. it means most distros don't support RTL already .. so we really should fix this properly πŸ˜„
22:05:23 <glx[d]> no issue reported about that
22:05:35 <TrueBrain> because we have So MaNy LiNuX users πŸ˜›
22:05:36 <TrueBrain> πŸ˜„
22:05:54 <TrueBrain> and the Steam users don't have this issue πŸ™‚
22:06:02 <Rubidium_> TrueBrain: I doubt I have icu-lx, because openttd is complaining it's missing the RTL support
22:06:15 <TrueBrain> tnx
22:06:22 <TrueBrain> assumed as much, but assumptions .... πŸ˜„
22:06:29 <glx[d]> only reports from linux users are flatpak users
22:07:10 <glx[d]> and they have more than RTL problems
22:07:18 <TrueBrain> owh, now I get why we get the reports ... flathub says we are the owner of the upload
22:07:35 <Rubidium_> but then, not having the issue with compiling means I have >= 65 and lx was removed in 58
22:08:34 <andythenorth> oops pillow is brooken
22:08:48 <andythenorth> maybe that 'fix' I removed from my dev env is needed πŸ˜›
22:09:04 <glx[d]> but if you readd the fix you break openttd
22:09:11 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10672: Change: Remove limit of objects per NewGRF.
22:09:13 <andythenorth> "this is development"
22:09:30 <andythenorth> nah missing brew deps, might be fixed
22:09:47 <glx[d]> ah yes you cleaned brew
22:10:08 <glx[d]> and only reinstalled pkg-config
22:10:27 <andythenorth> hmm still broken
22:10:32 * andythenorth investigating further
22:12:14 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:12:30 <andythenorth> oh here we go πŸ˜› circularity πŸ˜›
22:12:43 <TrueBrain> can't find the buildlogs of flatpak, so no clue against what ICU they build .. if they build against any ICU
22:13:28 <TrueBrain> not even sure they have lzma build
22:14:02 <petern> Flatpak eh...
22:14:35 <TrueBrain> ah, finally, found it
22:15:02 <TrueBrain> by some magic lzma seems to work; wouldn't have guessed based on the yaml
22:15:10 <TrueBrain> but they too don't have icu-lx
22:15:23 <glx[d]> andythenorth: but 3.7 is quite old
22:15:33 <andythenorth> same on pypy3.9
22:15:36 <andythenorth> I think
22:16:50 <glx[d]> put the error in a gist, so I know what to look for πŸ™‚
22:18:25 * Rubidium_ is going too look for his pillow :D
22:18:31 <TrueBrain> enjoy
22:19:07 <andythenorth> glx[d]:
22:19:58 <andythenorth> seems
22:20:10 <glx[d]> why make install for nml ?
22:22:25 <andythenorth> not sure
22:22:30 <andythenorth> it's just how it's setup
22:28:17 <TrueBrain> okay, Google Lens does a great job showing our layout is rubbish for Arabic without icu-lx πŸ˜„
22:28:23 <TrueBrain> no real surprise, but fun to see πŸ™‚
22:28:59 <glx[d]> well it was mentioned in the layout issue
22:29:35 <andythenorth> might have to build pillow locally
22:32:14 <glx[d]> all I can find says it's a pillow 9.0.1 issue
22:33:13 <TrueBrain> michi_cc[d]: so if I understand this correctly, and my knowledge is low here, we could use harfbuzz to create the layout for a single line, and use something similar as you did for Windows to find line-breaks
22:33:23 <TrueBrain> (basically removing characters till it fits :P)
22:33:46 <TrueBrain> by using ICU
22:33:56 <TrueBrain> the BreakIterator seems to indicate fine where you can break
22:34:24 <TrueBrain> so it is a bit like ... harfbuzz says it is too big, remove the last thing BreakIterator says, check with harfbuzz if it fits now, etc etc
22:34:57 <glx[d]> what's your pillow version andythenorth ?
22:35:07 <andythenorth> it was 9.5.0
22:35:15 <andythenorth> I just built 10.0.0.dev0
22:35:18 <andythenorth> same issue
22:35:23 <andythenorth> this is only with pypy3
22:35:33 <andythenorth> python 3.11 does not seem to have this problem
22:39:11 *** ChanServ sets mode: +v peter1138
22:39:11 *** ChanServ sets mode: +v DorpsGek
22:39:11 *** ChanServ sets mode: +v michi_cc
22:41:47 <andythenorth> changing CPATH in env doesn't resolve this issue
22:41:50 <andythenorth> which is fortunate
22:41:59 <andythenorth> maybe I need to rebuild pypy3
22:42:19 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10744: Fix c8299304: retain support ICU < 65
22:45:07 <glx[d]> and `pip install pillow --no-binary` (don't forget to `pip uninstall pillow` first)
22:45:09 <glx[d]> ?
22:46:55 <michi_cc[d]> TrueBrain: As far as I can tell (using somewhat old sources like e.g. <>), the full-on solution would be Pango, but not very friendly to use in custom-UI scenarios. Shaping can be done by Harfbuzz, bidi stuff with fribidi, and sorting and word/char-breaking with ICU.
22:47:18 <TrueBrain> do we have bidi?
22:47:34 <michi_cc[d]> We have arabic and mixed directional content, so yes.
22:47:48 <TrueBrain> hmm ..
22:48:22 <andythenorth> hmm, no dice on pillow
22:48:23 <andythenorth> ok
22:48:24 <TrueBrain> I don't understand enough of this yet to know how that influences the result πŸ˜›
22:48:30 <andythenorth> maybe it just doesn't work on macOS on pypy3
22:49:31 <glx[d]> and 9.4.0 was fine ?
22:49:46 <andythenorth> I don't know what the previous version was πŸ™‚
22:51:39 <glx[d]> depends on when you did the previous setup
22:52:23 <glx[d]> <> and check the dates
22:53:07 <michi_cc[d]> Using Uniscribe terminology, first the text is itemized. This divides the text into logical chunks using e.g. directional changes or script (in the lingusitic sense) changes. This is where you also incorporate additional breaks for style changes.
22:54:50 <michi_cc[d]> Next step is to breaking the text into lines. This is usually done iteratively as a break might require re-doing the following steps so you don't want to waste the work too much.
22:56:54 <michi_cc[d]> Line breaking also requires you to know the resulting line width, which requires shaping the logical chunks first. Unfortunately, if you break a chunk, you have to re-shape it.
22:57:43 <michi_cc[d]> After you have a line, you reorder the logical chunks and the corresponding glyphs according to the bidi state of the line into the physical glyph layout.
22:58:08 <michi_cc[d]> Give or take various details, this is text layout 101.
22:58:15 <TrueBrain> ❀️
22:58:33 <TrueBrain> that sounds rather doable with harfbuzz and ICU .. just painful to figure out the details
22:58:59 <glx[d]> and fribidi
22:59:15 <michi_cc[d]> Yeah, I'm not sure if fribidi is needed ot not, but at least the Pango stack seems to use fribidi and not ICU for the bidi handling.
22:59:56 <TrueBrain> I need to read up what bidi actually does
23:00:01 <TrueBrain> as in my head that is really simple πŸ˜›
23:00:16 <TrueBrain> (as in, our strings already tell you that information)
23:03:55 <glx[d]> not when you mix english and arabic in the same string without markers
23:04:13 <michi_cc[d]> It doesn't, as soon as you consider user input. There's a unicode document somewhere that assigns each Unicode code point a bidi class. Many classes are dependent on the adjacent code points and not necessarily explicit. This document also has the rules in it. Most complexity is around handling punctuation, braces, numbers and so on (e.g. a "." can be a sentence end or part of a number. How you have to treat it depends on the bid
23:04:13 <michi_cc[d]> codepoints.)
23:05:14 <michi_cc[d]> The fun gets even better of you nest multiple levels (e.g. arabic (latin (arabic) latin) arabic).
23:05:36 <TrueBrain> where do we have that in-game? πŸ˜„
23:05:38 <glx[d]> and that easily happens with our string system
23:05:43 <TrueBrain> do you have an example of where it gets complex, bidi?
23:06:17 <glx[d]> multiplayer and custom train names
23:06:25 <glx[d]> or just newgrf
23:06:49 <andythenorth> glx[d]: changed xcode-select path, pillow works πŸ˜›
23:06:56 <michi_cc[d]> If you want to do it right, you implement the standardized Unicode algorithm. Fribidi does, and ICU does something, too. I don't know which implementation is easier to use, but ICU seems to be the unloved step-child right now.
23:07:00 <glx[d]> ah, and openttd ?
23:07:07 <andythenorth> testing
23:07:23 <TrueBrain> yeah, will have to see what ICU does
23:07:27 <TrueBrain> but I am looking for an example of bidi
23:07:34 <TrueBrain> not broad categories; I can imagine them myself
23:07:49 <TrueBrain> but I don't actually understand how user-input has such a big influence on that for OpenTTD
23:08:04 <TrueBrain> most times, we show user-input as a standalone string
23:09:01 <glx[d]> {RAW_STRING} can be included in other strings via {STRING1}
23:09:21 <michi_cc[d]> Well, eints input is user-input as well in that sense. Something has to process it, and line-breaking can change the physical ordering of logical segments, so you can't pre-calculate it.
23:09:49 <TrueBrain> yeah, but it is specifically bidi which I have issues understanding in the context of OpenTTD
23:09:54 <michi_cc[d]> For an example, just look at the base set description strings in the images in <>
23:11:10 <glx[d]> perfect example yes, translator could have use markers, but there's no obligation
23:11:35 <michi_cc[d]> Also basically any text that can include NewGRF or GS text will mostly result in mixed bidi text.
23:11:54 <TrueBrain> it seems it is obvious to you two, but I am still clueless πŸ˜›
23:12:18 <glx[d]> you see "OpenTTD" in the middle of arabic text
23:12:32 <andythenorth> ok looks like pillow deps break openttd compile
23:12:33 <andythenorth> now failing
23:12:33 <michi_cc[d]> The latin chars are LTR segments embedded in an RTL arabic text.
23:13:01 <TrueBrain> owh, so when writing in arabic, they actually mix LTR and RTL by the letter?
23:13:20 <michi_cc[d]> The way it is render is NOT the way it is stored in the raw "ASCII" text.
23:13:21 <TrueBrain> as in, an "A" is always LTR, and .. well, I can't type it, but one of those thingies is always RTL?
23:13:32 <glx[d]> IIRC they write numbers as LTR
23:13:52 <andythenorth> looks like I have to do the full uninstall dance again πŸ˜›
23:14:29 <glx[d]> andythenorth: no, just switch xcode stuff depending on what you want to do
23:14:47 <michi_cc[d]> What each codepoint is depends on the assigned bidi class. But yes, some code points have an explicitly assigned bidi state. So arabic chars are always RTL and latin chars are LTR. But many other code points depend on the context, mostly symbols, numbers and punctuation characters.
23:14:51 <andythenorth> openttd build is now broken for all xcode SDK paths
23:15:05 <andythenorth> since installing deps for pillow via brew
23:15:05 <TrueBrain> oof, they didn't make this easy πŸ˜„
23:15:06 <TrueBrain> haha
23:15:30 <michi_cc[d]> Full story:
23:15:48 <TrueBrain> okay, one last question for the night: fontMapping, the thing the layouter gets; what is that exactly?
23:16:14 <glx[d]> that maps to freetype / sprites
23:16:20 <glx[d]> I think
23:16:39 <michi_cc[d]> Yes, mankind really didn't think about computers when laguage was invented πŸ˜€
23:17:13 <andythenorth> ach
23:17:26 <andythenorth> might have to reinstall entire dev environment from scratch again
23:17:27 <michi_cc[d]> TrueBrain: Logical segments of colour and text size changes.
23:17:29 <andythenorth> this is getting boring
23:17:38 <TrueBrain> ah, okay, from our string system
23:17:47 <michi_cc[d]> They are part of the itemize step as you have to break a run at e.g. a colour change.
23:17:50 <TrueBrain> I somehow assumed bidi was already in there, as I assumed it was only by explicit markers
23:17:57 <TrueBrain> but okay .. we also have a lot of context-depending shit going on ..
23:18:19 <michi_cc[d]> Markers is really the rarer case, and only if you have really good translators.
23:19:01 <michi_cc[d]> Oh, and where bidi of course also comes into play is string iteration for cursor movement πŸ™‚
23:19:23 <glx[d]> oh yes of course
23:19:29 <andythenorth> yeah brew just breaks stdlib stuff or something
23:19:31 <andythenorth> this is fucked
23:19:42 <TrueBrain> haha, yeah, editing text .. ugh πŸ˜›
23:19:50 <TrueBrain> too bad ICU doesn't deliver this (anymore)
23:19:58 <TrueBrain> weird that you have to collect three libraries to make it happen
23:20:13 <TrueBrain> how Windows now does it, that is correct?
23:20:17 <glx[d]> guess it was a hell to maintain
23:20:23 <TrueBrain> or are there sharp edges there?
23:20:39 <glx[d]> windows uses native windows stuff
23:21:19 <glx[d]> maybe with some ICU code hidden internally though
23:23:15 <michi_cc[d]> It should be mostly correct. Uniscribe used to be the layout engine of Word before it was made available for all. The more recent stuff is DirectWrite, but that is a lot more GUI-integrated. Nevertheless any difference (if there are even any) will only be related to the tiny incremental changes that are sometimes made in newer Unicode standard revisions.
23:24:04 <TrueBrain> and the implementation of OpenTTD of uniscribe? No known issues or "we couldn't solve that"?
23:25:31 <michi_cc[d]> I don't think there are known implementation issues, but I think some translations tried to work around layout issues with really old ICU stuff which do not render as intended for a Unicode conforming layouter.
23:25:44 <TrueBrain> lol
23:25:47 <TrueBrain> as that goes πŸ˜„
23:27:10 <michi_cc[d]> Like e.g. intentionally using )( instead of () as some ICU things didn't (or maybe still don't) properly handle the required bidi shaping.
23:27:11 <andythenorth> pff, ok so no openttd compile, no grfs, nothing works
23:27:16 <andythenorth> think I go to sleep
23:27:36 <TrueBrain> tnx a lot for all this info; I think I somewhat grasp what is going on now πŸ˜›
23:28:04 <michi_cc[d]> Natural language processing is HARD. And we didn't even touch Unicode normalization forms yet πŸ™‚
23:28:07 <andythenorth> 8 hours reinstalling and now I can't build anything 😦
23:28:24 <glx[d]> can't you revert the latest change ?
23:28:26 <TrueBrain> well, I had enough for now πŸ˜› Sleep well πŸ™‚
23:28:40 <andythenorth> glx[d]: no, something in brew poisons the Apple Xcode tools
23:28:52 <andythenorth> I have to remove everything and reinstall again
23:28:56 <andythenorth> piece by piece
23:28:57 <glx[d]> probably a lib
23:29:26 <michi_cc[d]> Like that À and ä are the logical same text but do not have the same code points.
23:29:33 <andythenorth> the only solution I found previously was to remove everything and start again
23:30:11 <glx[d]> integrated vs Β¨ over a ?
23:30:32 <michi_cc[d]> If Discord doesn't fuck up, you should see two identical characters, except that the first one is \u00E4 and the second one \u0061 \u308.
23:30:46 <michi_cc[d]> Yeah.
23:30:51 <glx[d]> yeah it shows the same
23:30:52 <TrueBrain>
23:31:21 <glx[d]> same goes for most accented chars
23:31:57 <michi_cc[d]> And if you do natural string comparison, they should compare as equal. So a byte-wise compare is out for that, too. (Which is excatly one of the things OpenTTD does use ICU for).
23:32:58 <glx[d]> the part that was broken for today's nightly
23:33:12 <andythenorth> ok `evn` before uninstalling everything πŸ˜›
23:33:35 <andythenorth> I'm not sure what is getting poisoned, might be CPATH, might be PATH
23:33:49 <glx[d]> yeah check the env
23:34:05 <andythenorth> I unset lots of things, then restarted
23:34:58 <michi_cc[d]> And just to not make potential people angry, while arabic is the most obvious script regarding complex text processing, the brahmic (indic) scripts require it, too.
23:37:14 <glx[d]> and above that you have the font which does some magic to make text look prettier depending on succession of characters
23:37:37 <glx[d]> like merging f and i if fi
23:37:55 <michi_cc[d]> Indeed, but that at least is just making it "prettier" and not making it correct at all.
23:44:19 <andythenorth> openttd and grf seem to build πŸ˜›
23:44:26 <andythenorth> definitely quitting time πŸ˜›
23:44:54 <andythenorth> mac build issues -> check `env` (note to self)
23:45:04 <andythenorth> brew might have some bad habits with CPATH
23:53:34 <glx[d]> next time andy complains about build fail, remind him to check `env` πŸ™‚
23:54:04 <michi_cc[d]> TrueBrain: One thing that used to be a sharp edge with Uniscribe was the old Freetype font rendering, as font data is inherently part of glyph shaping and Freetype and Windows don't always agree. But I wrote the GDI font rendering especially to get rid of this sharp edge.
23:55:08 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #10325: [Bug]: macOS build fails due to [problems I don't understand] format.h
23:55:11 <DorpsGek> [OpenTTD/OpenTTD] glx22 closed issue #10325: [Bug]: macOS build fails due to [problems I don't understand] format.h
23:55:53 <glx[d]> and that also removed a dep for windows, win-win πŸ™‚