IRC logs for #openttd on OFTC at 2023-04-29
β΄ go to previous day
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:17:56 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:20:56 *** Wormnest has quit IRC (Quit: Leaving)
04:19:08 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
04:19:34 *** WormnestAndroid 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: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:25 <axet> my train track cover entier map
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:31:58 <TrueBrain> I wonder if Steam Workshop gets these requests too π
07:45:41 *** HerzogDeXtEr has joined #openttd
07:49:02 <Brickblock1> Bananas subscription model when?
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: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: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:08:03 <TrueBrain> I am guessing our autoclean functionality needs a bit of work π
08:21:17 <Rubidium_> LordAro: care to have another look at 10727?
08:24:32 <TrueBrain> pickpacket: a random "huh?" appears π
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: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: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: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?"
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:04:24 <Eddi|zuHause> sure. but it would identify some hotspots, which could allow us to make educated guesse
09:04:43 <Eddi|zuHause> i feel like my s key is on the brink of collapse
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: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: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: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: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: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:06 <TrueBrain> well, ofc, there is no GUI on the screenshot in those cases π
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: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: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:17 <andythenorth> so wait, I have to pay to distribute my content to users who get it free?
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: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:10:26 <TrueBrain> pickpacket: I always ask, I never receive π’
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:54:49 <TrueBrain> I wonder if OS/2 works at all still .. we have no CI running it π
10:55:22 *** Guest12506 has quit IRC (Ping timeout: 480 seconds)
11:00:46 <TrueBrain> happened out of nothing!
11:04:13 <petern> LordAro, the hills hate me π¦
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:14:04 <LordAro> among other things, i'd quite like to stop coughing
11:14:12 <LordAro> so i could actually do hills
11:31:39 <andythenorth> so what are we porting from JGRPP?
11:31:50 <andythenorth> * spacing of buses
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: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> I think those last two are pretty far outside of the vanilla design goals
11:41:12 <andythenorth> but they're worth seeing
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: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:28:46 *** lobstarooo has joined #openttd
12:36:49 *** lobstarooo has quit IRC (Ping timeout: 480 seconds)
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:51:51 <petern> I think a recent changes has broken hotkey loading, so they get wiped.
13:02:46 <andythenorth> enough tank games
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: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: bjorn.warmedal@gmail.com 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:47:09 <glx[d]> what's your system ttdplanner ?
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:55:07 <glx[d]> installing python and `pip install nml` should work
13:55:58 <andythenorth> nmlc, but in an AWS Lambda? π
13:57:47 <glx[d]> IverCoderviaGitHub: nice try π
13:58:30 *** ttdplanner has quit IRC (Quit: Page closed)
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: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: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: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:09 <andythenorth> cargo subtypes for starters π
14:45:11 <petern> Cargo subtypes aren't relevant.
14:45:36 <andythenorth> nah but vehicle sets define their own cargo sometimes
14:45:57 <andythenorth> ok I have some regrets about certain design choices π
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: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:41 <andythenorth> I wonder if a faster laptop can solve it
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: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: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: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: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: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: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: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: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: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: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: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: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: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:56:06 <andythenorth> I tried changing the order of parameters to cmake
15:57:04 <glx[d]> oh now, another reservation bug
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:12 <glx[d]> like `-- Found Iconv: /Applications/Xcode_13.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib/libiconv.tbd`
15:59:58 <andythenorth> 13.1 SDK, but yes
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:07:15 <andythenorth> `No packages are installed. Did you mean `search`?`
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:12:11 <Eddi|zuHause> also i'm not finding what package i'm missing there...
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:16:00 <andythenorth> ok that looks pretty similar
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:54 <andythenorth> still failing on broken header stuff
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:48 <andythenorth> it's probably broken by Apple
16:18:52 <andythenorth> which SDK do we compile against?
16:20:24 <andythenorth> googling suggests stdlib is broken on macOS
16:20:52 <glx[d]> -- Check for working CXX compiler: /Applications/Xcode_14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
16:22:47 <andythenorth> remains puzzling π
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:34:56 *** gelignite has joined #openttd
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: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: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: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: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: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: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: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:13 <glx[d]> I mean bit 8 of feature => read flags
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: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: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: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/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/math.h` but command line uses `-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include`
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: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/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include`
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:33:40 <andythenorth> ok I can build grfs again π
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: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> # 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: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:15 <petern> Have you started reinstalling yet?
19:01:43 <petern> Hmm, shall I use stdint types...
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:05:01 <andythenorth> might need some cmake flags or so
19:05:28 <TrueBrain> `-DCMAKE_OSX_ARCHITECTURES=arm64` might help
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: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: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: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:45 <TrueBrain> that is why they are in the same sentence, yes π
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: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 COMPILING.md .. 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: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: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: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: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: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:05 <TrueBrain> but CentOS's libicu-devel does
19:33:14 <TrueBrain> ah, no, version difference ofc
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 libicui18n.so.67 => /usr/lib/x86_64-linux-gnu/libicui18n.so.67 (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: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
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:10:25 <TrueBrain> owh boy, now we have 2 people doing these conversions ........ π
20:18:08 <andythenorth> hmm wonder if I can hash my game settings somehow to identify myself in the survey π
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: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: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: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:53:00 <TallTyler> Builds properly now π
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: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:27 <TrueBrain> yeah ... still the same question π
21:00:37 <TrueBrain> owh, I got a popup with an error
21:01:02 <TrueBrain> so yeah ... ICU-lx isn't there
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: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: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:46 <TrueBrain> I blame Rubidium for showing me we were still using an old ICU π
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: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: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: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: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:05 <michi_cc[d]> Is there even any standard solution for IME language input for Linux?
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: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: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: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: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: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: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: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:20:10 <glx[d]> why make install for nml ?
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: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:15 <andythenorth> I just built 10.0.0.dev0
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:45:07 <glx[d]> and `pip install pillow --no-binary` (don't forget to `pip uninstall pillow` first)
22:46:55 <michi_cc[d]> TrueBrain: As far as I can tell (using somewhat old sources like e.g. <http://mces.blogspot.com/2009/11/pango-vs-harfbuzz.html>), 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:34 <michi_cc[d]> We have arabic and mixed directional content, so yes.
22:48:22 <andythenorth> hmm, no dice on pillow
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: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: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:33 <TrueBrain> that sounds rather doable with harfbuzz and ICU .. just painful to figure out the details
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: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: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: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: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 <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: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:39 <michi_cc[d]> Yes, mankind really didn't think about computers when laguage was invented π
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:29 <andythenorth> yeah brew just breaks stdlib stuff or something
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: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:29:26 <michi_cc[d]> Like that Γ€ and aΜ 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:51 <glx[d]> yeah it shows the same
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:34:05 <andythenorth> I unset lots of things, then restarted Terminal.app
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:53 <glx[d]> and that also removed a dep for windows, win-win π
continue to next day β΅
