IRC logs for #openttd on OFTC at 2024-01-16
⏴ go to previous day
00:07:33 <truebrain> reldred: You are right, that might for now be a better goal. Won't be 14.0, but no need to complicate things more than needed 🙂
00:16:00 <truebrain> No FFI, so no 😛 I tried 😄
00:25:52 <reldred> truebrain: I was kinda being facetious, I know some people see distributing executable binary code in that fashion a Bad Thing (TM), me I’m not really bothered 🤷🏻♀️
00:38:40 <peter1138[d]> Well that's fun. Template-based NWidgetPart array allowing both colour and caption to be specified.
00:39:19 <wensimehrp> About the "use traditional sprite font" thingy, can I modify the string a bit to warn players that this setting won't work if they are not using English or Russian?
00:40:56 <wensimehrp> I mean, the translated string, not the original English string.
00:40:57 <peter1138[d]> It's a bug that turning it off doesn't switch back to autodetected fonts.
00:41:49 <peter1138[d]> Modify the English string, or the English tool-tip.
00:42:12 <wensimehrp> That would need a pr
00:43:29 <peter1138[d]> The setting will work fine for Italian. So I don't think you mean "not using English or Russian"
00:44:32 <peter1138[d]> I would wait for the bugs to be fixed.
00:45:08 <wensimehrp> Non-Latin or Non-Cyrillic, I mean
00:45:14 <peter1138[d]> It might be that it is fixed by having the button disabled for languages that the sprite font can't support.
00:59:19 <wensimehrp> I modified the string to this:
00:59:19 <wensimehrp> {BLACK}Check this box if you prefer to use the traditional fixed-size sprite font.{}(This setting is only for languages based on Latin or Cyrillic characters.)
00:59:19 <wensimehrp> Should I make a pull request now?
01:01:46 <peter1138[d]> As I said, wait for the bugs to be fixed.
03:10:10 *** bryjen has quit IRC (Remote host closed the connection)
03:26:05 *** Wormnest has quit IRC (Quit: Leaving)
03:45:11 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:15:48 *** Smedles has joined #openttd
06:01:06 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
06:23:10 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:32:09 *** tokai|noir has joined #openttd
07:32:09 *** ChanServ sets mode: +v tokai|noir
07:33:42 <truebrain> well, guess he changed his mind directly after opening that ticket 😛
07:35:51 *** Flygon has quit IRC (Read error: Connection reset by peer)
07:38:50 *** tokai has quit IRC (Ping timeout: 480 seconds)
08:04:00 <truebrain> right .. yesterday I knew we shouldn't be doing it, but was lacking the details to explain why. Now I know \o/ 🙂
08:04:15 <truebrain> and now, day-job. Money has to be made!
08:23:38 <truebrain> sorry, I don't allow for publish listing
08:30:30 <LordAro> truebrain: you can't catch specific types due to ABI etc, but catch(...) should suffice at least for C++ exceptions as far as i'm aware
08:30:40 <truebrain> hmm ... my Javascript application can have negative values like -0 .. which are rather annoying 😛
08:30:51 <truebrain> LordAro: did you follow the link I added? 😄
08:31:02 <LordAro> no, i read the email :p
08:31:12 <truebrain> in the email too, there was a link 😛
08:31:18 <truebrain> so I am not sure how that changes my question 🙂
08:31:33 <truebrain> anyway, their example is MSVC vs MinGW
08:31:42 <truebrain> MSVC uses SEH for exceptions, which MinGW is unaware off
08:32:21 <LordAro> ah yes, you're quite right
08:32:36 <LordAro> i was thinking purely on GCC (/MinGW) lines
08:32:44 <truebrain> that is the mistake many make 🙂
08:33:00 <truebrain> but as C++ doesn't define ANY of its ABI, even a `catch` might not be compatible, if I read this right
08:33:18 <truebrain> or, ofc, we can drop MinGW, but .. yeah 😛 😄 😛
08:33:25 <truebrain> (sorry, couldn't resist 😄 )
08:33:39 <LordAro> i was once caught out by the GCC std::string ABI change in 4.9(?), so catch (std::string) didn't catch a std::string thrown by the library compiled with the older compiler
08:34:07 <truebrain> yeah ... everywhere I read: DO NOT ATTEMPT TO DO THIS 😛
08:34:58 <truebrain> even with `setjmp` there is a possibility we cannot roll back the stack to a known good state
08:35:00 <truebrain> so even that is iffy
08:35:28 <truebrain> but yeah, as I wrote, as we are changing that plugins are absolutely 100% written by us, I think we should just consider it an extension of our codebase, and not try to capture any of this 🙂
08:36:24 <peter1138[d]> Lots of hoops to step through to 'avoid' licensing issues...
08:36:28 <_zephyris> peter1138[d]: Or I can extend the extra newgrf to include the Cyrillic and Greek ranges in the sprite font?
08:36:39 <truebrain> peter1138[d]: and shipping DLLs to people that don't want them
08:37:09 <peter1138[d]> Make a generic plugin system so anyone can make a plugin, we just happen to also make some -> add signing so that only our plugins can load.
08:37:44 <peter1138[d]> _zephyris: Yes, I believe so.
08:38:01 <truebrain> for MacOS that currently already is true btw; MacOS refuses to load libraries that aren't signed by the same certificate as the application 🙂
08:38:43 <truebrain> peter1138[d]: honestly, I did consider what if we just integrate the plugins in the game and be done with it. But then you have the issue you would ship Discord / GOG Galaxy / Steam SDKs with all our games .. which also feels bad
08:39:09 <truebrain> as those cannot be statically linked (not by license; just by how they are designed)
08:39:56 <truebrain> alternatively, we can just not do this at all 😉
08:41:02 <truebrain> that ... is actually allowed?! 😮
08:41:14 <truebrain> that is really cool
08:41:28 <peter1138[d]> It is when I modify all of NWidgetParts to allow constexpr creation.
08:41:36 <peter1138[d]> Which isn't actually a huge job.
08:41:51 <truebrain> which would be a smart move either way
08:41:55 <peter1138[d]> Currently all NWidgetPart arrays are built by code at runtime, because they are not constexpr.
08:42:17 <peter1138[d]> Making it all constexpr means just array is stored.
08:42:32 <peter1138[d]> And also prevents using the wrong scaled vs unscaled thing 🙂
08:42:48 <peter1138[d]> (There was a reason to that random PR)
08:45:38 <truebrain> anyway, about social integration, I am open for alternatives, but this seems to be where things are leading us .. just a bit of an unexpected place 🙂
08:46:13 <truebrain> btw, strictly seen the plugins don't need to be authored by us; we just need to sign off on them being "real". So in reality they will be authored by us (or for example someone like JGR)
08:48:45 <peter1138[d]> Rolling our own binary signing -- is there a standard for this that can be follow to ensure we avoid mistakes.
08:48:59 <peter1138[d]> Would signing be enforced, or a big fat warning.
08:49:20 <truebrain> Public Key Signing is the standard there; which that library supports. So if we follow that, we should be fine
08:49:26 <truebrain> I would say we enforce it for non-development builds
08:49:43 <truebrain> but in theory we could make a big fat warning on startup: this plugin is not authenticated; are you sure you want to load it?
08:50:12 <reldred> So, I play with this defence/gov software called ATAK right, it’s got a plug-in system. Way it works is the release binaries can only load plugins signed by the TAK product centre, but plug-in developers can load unsigned plugins in a debug build, and once they’re happy with functionality they submit their plug-in to the TAK product centre for signing.
08:50:49 <peter1138[d]> With a bit of config editing which requires a specific phrase in some key 😉
08:51:32 <reldred> And even in developer/debug builds loading an unsigned plug-in carries a BIG fat warning and then permanently leaves a red shield icon in the bottom corner of the screen
08:51:53 <peter1138[d]> Because normal users don't habitually enable the developer tools to allow them to bypass the NewGRF-changing restriction, of course.
08:52:17 <truebrain> I say we can go either of two ways
08:52:30 <truebrain> either only allow non-signed plugins to work wehn you compile with `-DALLOW_UNSIGNED_PLUGINS`
08:52:35 <truebrain> which no normal user would be able to do
08:52:54 <truebrain> or, the plugin is listed in the list as: Not Authorized, and you have to click "Overwrite" in the GUI for it to load
08:53:32 <peter1138[d]> Will the plugin system be able to support "join my friend's game" at some point?
08:53:49 <reldred> I’d go former of the two
08:54:54 <reldred> So yeah, this plug-in signing system this other vendor does, they then do automated testing of the plug-in/codebase to make sure the plug-in isn’t trying to do anything dumb/overtly malicious
08:55:36 <truebrain> the thing about OpenTTD, the chances of anyone other than us building a plugin is already low, and then wanting to have it signed is even lower. But we could facilitate signing of 3rd-party plugins
08:56:04 <truebrain> I am not even against it; just I don't expect it to happen. But we can create the facility on first request, so it is also not a worry 🙂
08:56:28 <truebrain> (for surveys a similar thing happened; but there I did anticipate we would get the request, so I already created the facilities; and I am happy I was not wrong 😄 )
08:56:38 <reldred> I dunno dude, plug-in/dll based extenders are now becoming common for modding in most bethsoft games, and now even games like Cyberpunk, etc
08:57:03 <truebrain> reldred: there just aren't that many social platforms to integrate with 😄
08:57:21 <reldred> truebrain: I’m talking beyond the scope of just social plugins
08:57:34 <truebrain> there isn't anything beyond the scope of social platforms for this plugin system 🙂
08:57:46 <truebrain> for anything else, I would strongly suggest to sandbox it via WASM for example, if performance is a thing
08:57:58 <truebrain> the only reason I am not using WASM here, is because we need FFI
08:58:14 <reldred> Just giving some context based on my experience elsewhere 🙂
08:58:34 <truebrain> appreciated 🙂 I just hope we can avoid binary distribution as much as possible 😛
08:58:45 <truebrain> I wouldn't install a mod for Cyberpunk if it was a DLL, for example
08:59:23 <reldred> You’d be missing out, unfortunately. Same with the bethsoft games.
08:59:53 <truebrain> that said, I do install Java packages with Minecraft, so maybe I should get over myself 😛
09:00:10 <reldred> The engine based mods for those games are where the real hotness lies
09:10:48 <_zephyris> truebrain: FWIW, I like this, but I'm no expert. I might have the wrong end of the stick, but current malicious payload attacks can come from malicious modified OTTD builds, and using plug in signing and dissalowing unsigned plugins at compile time puts plugins under the existing warnings to users about unofficial builds.
09:11:19 <truebrain> it is the most safe route, but also the most restricted
09:12:05 <truebrain> which brings us back to the comment peter1138[d] made, that we build all this to "bypass" licensing, then restrict it to only us .. which feels a bit .. pointless 😄 Still think it is the right thing to do, but it is good to see if there aren't better ways
09:12:25 <truebrain> if we would allow unsigned plugins to run on any build, but with big fat warnings etc, it would be more "open" in that sense
09:12:46 <truebrain> we just know from NewGRF stuff, that people will just disregard any warning you send to them, and they are going to click it anyway .. and as these are binaries, maybe we should protect users a bit more
09:13:03 <truebrain> but, as mentioned by reldred , many other games start to do binary mods anyway, which people just open left and right ..
09:13:16 *** DorpsGek_vi has quit IRC (Remote host closed the connection)
09:13:17 *** DorpsGek_vi has joined #openttd
09:14:54 <peter1138[d]> It's being cold again.
09:15:18 <truebrain> did peter1138[d] just manage to crash the IRC bridge? 😄
09:15:27 *** DorpsGek_vi has quit IRC (Remote host closed the connection)
09:15:27 *** DorpsGek_vi has joined #openttd
09:15:53 <truebrain> luckily enough I build it resiliant, but nice work peter1138[d] , you found a bug 😄
09:16:06 <truebrain> by saying nothing, you said everything 😄
09:16:13 <peter1138[d]> Awesome, glad to be of assistance.
09:16:29 <truebrain> anyway, what are you thought on the matter peter1138[d] ? As you mostly have some good insights 🙂
09:24:35 <LordAro> hmm, computer just crashed (again) and dumped me straight into the bios with no boot options
09:24:37 <peter1138[d]> Heavy lifting there.
09:26:13 <LordAro> it came back again after another reboot, but...
09:26:19 <LordAro> any CPU/MB recommendations?
09:27:40 <peter1138[d]> truebrain: Compile-time allow/deny is strongest safety of course. But does it feel like protecting users or locking in to our code...
09:27:52 <peter1138[d]> Something AMD these days I guess.
09:27:57 <truebrain> LordAro: Gigabyte X670 AORUS ELITE AX with a AMD Ryzen 9 7950X .. but that cost you a penny 😛
09:28:28 <truebrain> peter1138[d]: so you are also tempted to just allow a user, after a warning and pressing buttons, to load any plugin?
09:28:34 <peter1138[d]> That'll cost more than a pair of carbon bicycle wheels!
09:28:35 <truebrain> and if they want to shoot themselves in the foot .....
09:29:15 <truebrain> compared to the RTX 4070 I added to the same system, it is nothing! 😛
09:31:03 <LordAro> i was thinking a Ryzen of some description
09:31:16 <LordAro> just so i can say i've got an AMD CPU & an Intel GPU
09:31:22 <truebrain> a 7950X is a bit ... on the high-end, but there are cheaper ones 😛
09:31:59 <LordAro> clearly should just get one of the new Threadrippers
09:32:22 <peter1138[d]> truebrain: No, just bothsides-ing 🙂 In terms of safety it probably makes sense to go the whole way.
09:32:48 <truebrain> I am really on the fence what is the right way here .. user flexibility vs absolute security
09:33:02 <peter1138[d]> For Minecraft you can of course install java plugins etc with a mod-loader, but that isn't built in to Minecraft, and they don't intend for you to do that. They just don't stop you.
09:33:50 <peter1138[d]> Hmm, yeah, flexibility.
09:45:24 <truebrain> it is ironic, how for OpenTTD I used to work a lot with heightmaps, 20 years ago, and now for my dayjob I am working on tooling to easier process heightmaps 😛
09:45:30 <truebrain> just the resolution is "slightly" different
09:55:48 *** thelounge345 has joined #openttd
09:58:43 <xarick> 21.6 ºC with the looks like it's raining
09:59:16 *** karoline[m] has quit IRC (Quit: Client limit exceeded: 20000)
10:01:40 <peter1138[d]> What is it in °C ?
10:02:16 <peter1138[d]> truebrain: Partial tile heights patch?
10:07:52 <peter1138[d]> Today is project stop-what-youre-doing-we-need-you-to-work-on-a-new-feature-for-a-demo day
10:09:50 <xarick> today's goal is to "fix" costs from going from a water region to another
10:10:18 <xarick> treat a region as a zoomed out (or in?) tile
10:10:46 <xarick> then give it the same curve costing rules as a trackdir
10:12:01 <xarick> 70 for a diagonal "trackregiondir"
10:12:12 <xarick> 100 for a axis "trackregiondir"
10:20:12 <peter1138[d]> Hmm, more MikroTik updates.
10:32:44 <reldred> Yes, suspiciously many
10:32:54 <reldred> 7.13.2 dropped today or yesterday
10:33:12 <reldred> I’ve got one deployment on 7.8 and another on 7.12
10:33:21 <reldred> Waiting for MVRP on 7.14
10:34:36 <LordAro> those are some letters
11:01:02 <truebrain> and I am dealing with artifacts
11:01:38 <truebrain> GEBCO dataset has some odd entries from time to time 🙂
11:12:09 <peter1138[d]> Time for a `Ctrl-F2 r`
11:15:58 <peter1138[d]> truebrain: Bet it looks good in game 😉
11:16:29 <truebrain> I would still love to make a tool to quickly make heightmaps from the world ... but it is so difficult ... so little good sources 😦
11:28:04 <truebrain> always be a bit afraid of those that carry a hammer 🙂
11:35:37 <peter1138[d]> Heh, you also need an Origin account to play that game.
11:36:08 <truebrain> the discussion is just over the wrong axis; spyware or misusing GS is not the solution. But there are plenty of other possible solutions
11:36:23 <truebrain> that is the downside of starting a discussion with 2 solutions; people only talk about those solutions 😄
11:36:40 <truebrain> why are you sorry? 😄
11:36:50 <peter1138[d]> Because I perpetuated the downside.
11:37:26 <truebrain> hmm .. now GDAL tells me the southern hemosphere is no longer there.
11:37:31 <truebrain> I guess that is also an option
11:37:43 <peter1138[d]> Would that explain why it's so cold?
11:37:50 <peter1138[d]> Or is that just "winter"
11:37:52 <truebrain> we are missing parts of the Earth, so yeah
11:38:02 <LordAro> peter1138[d]: not in the southern hemisphere
11:38:18 <peter1138[d]> Correct, I am not in the southern hemisphere.
11:38:32 <truebrain> you flushed the toiler, and it was spinning the right way? 😄 😛
11:42:37 <reldred> peter1138[d]: I look at that grieving discussion and the only suggestion I can think of is ‘disable all open lobby games in OpenTTD and make them invite only’… I’m sure that won’t be popular though.
11:43:12 <Eddi|zuHause> isn't the toilet spinning an urban myth, because at that scale the form of the toilet massively outnumbers the coriolis force?
11:44:34 <reldred> truebrain: automatic heightmap generator for OpenTTD based off lat/long? 😛
11:45:10 <reldred> (Yes yes I know day job)
11:45:20 <reldred> Still, that would be neat.
11:47:41 <locosage> reldred: it would help a lot if gamescript (or smth else) could actually stop actions
11:47:57 <locosage> I rarely need to do any moderating on citymania as most of game rules are controlled by the server
11:48:14 <truebrain> reldred: 15 years ago I tried that many times, but it is really hard .. heightmap is not land coverage 😦 so true heighmaps look really odd for many countries
11:48:32 <locosage> So, say, "stealing" resources is just not a thing that can even happen
11:48:52 <reldred> truebrain: Yeah, and even accurate real world heightmaps aren’t necessarily ‘good for gameplay’.
11:49:06 <reldred> (And good gameplay for whom?)
12:31:04 <peter1138[d]> ```print &WidgetDimensions::unscaled
12:31:04 <peter1138[d]> error: Couldn't lookup symbols:
12:31:04 <peter1138[d]> WidgetDimensions::unscaled```
12:31:20 <peter1138[d]> I guess that means it got compiled out... which is nice.
12:45:38 <peter1138[d]> Oh well, that's fantastic. My return key strikes again.
12:47:19 *** D-HUND is now known as debdog
12:56:02 <peter1138[d]> Hmm, NWidgetPart might work better as a std::variant.
13:05:09 <peter1138[d]> Hmm, not really, saves having the union constructor but that's about the only benefit.
13:11:05 <_zephyris> truebrain: Survey results are super useful. Knowing 65% see 1x, 18% see 2x and 0.2% see 4x zoom GUI icons is really informative.
13:11:37 <truebrain> who knew, that insights in usage is helpful 😄
13:13:35 <peter1138[d]> _zephyris: the stats for last week are very different from the first week.
13:14:10 <truebrain> oh-oh ... I see a request incoming to be able to compare weeks 😛
13:14:41 <peter1138[d]> Also "-1" is a bit ambiguous, as that depends on the OS scaling.
13:15:14 <peter1138[d]> truebrain: Trends would be useful though 🙂
13:15:33 <truebrain> yup; also not sure if week-resolution is useful, or that it should be month
13:15:53 <peter1138[d]> 10% of players increase the window limit to 100. That might be painful to navigate.
13:18:42 <_glx_> I wouldn't have enough space on screen for that
13:39:34 <_glx_> strange, sentry started to send me emails 2 days ago
13:47:50 <locosage> with some providers it's very simple to change ip
13:48:19 <locosage> I don't think the only person that have been IP banned on openttd infra even noticed that :p
13:51:42 <_glx_> I have a static IP since 2007 (well it changed in 2022 but it's still static)
13:52:34 <peter1138[d]> Anyone can use a "VPN" (one of the not-actually-a-VPN "VPN"s) too.
13:53:07 <peter1138[d]> But, casual griefer... might not bother.
13:53:24 <truebrain> and if they bother, they will also bother with other ways to get back in the game
13:53:36 <peter1138[d]> I don't fancy running a centralised account system 🙂
13:53:59 <truebrain> we parted away from that years ago, and I am so happy with it 😄
13:54:10 <locosage> I used to have a provider that changed ip on every connection or every 24 hours
13:54:11 <truebrain> storing passwords is just a shitty job
13:54:38 <_glx_> I remember eddy being disconnected every night or something
13:54:38 <truebrain> thankfully OIDC exists
13:55:18 <truebrain> issue with griefing is that it can be very objective
13:55:31 <peter1138[d]> "Stealing from my factor!"
13:55:41 <truebrain> yeah ... seen enough of those complaints on Discord alone
13:55:50 <truebrain> "They made a station in MY TOWN"
13:56:29 <locosage> that what gs(or smth else) is supposed to handle
13:56:29 <_glx_> in the last test game I stealed from the AI, but only after I noticed it was broken
13:56:50 <truebrain> yeah, I know, the AI wrote me a long and strong letter about your behaviour
13:56:57 <truebrain> they did NOT appreciate it, I can tell you that
13:57:14 <_glx_> and we were both sending oil to the refinery anyway
13:58:44 <peter1138[d]> GameScripts can set exclusive rights on industries I believe.
13:59:14 <peter1138[d]> So I guess they can assists with gameplay rules about 'stealing' already.
13:59:58 <_glx_> yes and they can split exclusivity between input and ouput
14:00:24 <peter1138[d]> Odd that it is it a CompanyID instead of a CompanyMask, but there we are.
14:06:04 <locosage> you mean split between multiple companies?
14:06:30 <locosage> I kinda found that one company covers all the usecases I can think of
14:08:19 <locosage> splitting between multiple is kind of weird when you think of how these companies are even selected
14:08:37 <locosage> with one it's something simple like first to come gets exclusivity
14:10:48 <locosage> with, say, two it's like what? so while first company interacts with industry it's still ffa but when second comes it gets exclusivity for two?
14:13:43 <locosage> basically, all competitors are kind of equal so it's usually either all are allowed to use industry or none.
14:15:02 <peter1138[d]> "I can't see a use" is not the same as "nobody could have a use"
14:16:52 <locosage> you can't possible cover all the uses anyone can come up with is the future
14:17:16 <_glx_> ideally it would be exclusive per industry and per cargo type
14:17:21 <locosage> besides, it's pretty clear for me that if multiple companies are allowed to interact with the industry there needs to be a way to specify their share
14:17:26 <locosage> so it's not just company mask
14:18:43 <locosage> so, yeah, share per industry and cargo type
14:19:09 <locosage> I was thinking something like that when making PR but then I realized that only one company is really needed
14:19:39 <locosage> all other uses are entirely hypothetical
14:22:51 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
14:26:46 <truebrain> weird, doing `console.log` 8x8x256x256 times kinda hangs a browser
14:27:47 <truebrain> it has a hard time recovering from it 😄
14:27:53 <peter1138[d]> Hmm, don't think I can store a template argument in NWidgetPart 😦
14:28:32 <peter1138[d]> So I think NWidgetFunction() is the only way to create custom widget.
14:48:10 *** Smedles has joined #openttd
15:01:34 <xarick> I can't do maths with TileIndexes?
15:08:35 <xarick> why are the errors generated by visual studio such a mess to understand
15:17:31 <xarick> '/': illegal for struct .... TileIndex is a struct?
15:27:02 <talltyler> You want X and Y coordinates for any math, not tile indexes.
15:27:57 <xarick> much lesser complexity
15:30:21 <peter1138[d]> tile = TILE_ADDXY(tile, x, y);
15:30:49 <peter1138[d]> Multiplication/division does not make sense for TileIndex.
15:33:02 <xarick> im making use of distance manhattan for distance between x and y axis
15:33:47 <xarick> saves me the trouble of having to do it by splitting the tile into tilex and tiley
15:34:23 <peter1138[d]> Sure but you need to split, so...
15:34:53 <xarick> the tiles are always appart in the same axis
15:36:34 <truebrain> why did I ever wanted to align this multi-widget thing .. so much code to make that happen 😛
15:36:49 <xarick> INVALID_TILE.base() this works, but it sure is ugly
15:36:53 <truebrain> right ... signature validation ... "fun" ... 😄
15:43:22 <truebrain> ugh peter1138[d] you are right; doesn't mean I like it, but you are right 😛 I always forget how silly long translations can be 🙂
15:43:36 <truebrain> mostly, I just wanted things to align nicely
15:43:43 <truebrain> I doubt it really would become multiline btw
15:44:29 <truebrain> in reality I now push the width of the window till the translation fits 😄
15:45:49 <peter1138[d]> You don't have to do it, it's just my opinion 🙂
15:46:01 <truebrain> the code just became very shitty
15:46:05 <truebrain> which I really don't like 🙂
15:46:24 <peter1138[d]> I'd also like to make the widget system more aware of these long wrappable strings.
15:46:28 <truebrain> but I didn't want to ignore it like many other windows do 😄
15:46:39 <peter1138[d]> So that the OnResize() stuff is done automatically.
15:49:52 <peter1138[d]> There are also already loads of places where we only use the current selection string instead of the longest string.
15:50:09 <truebrain> yeah; and I didn't want to be "that guy" and do the same 😄
15:50:38 <truebrain> as the window size can't be changed after creation anymore, I guess (well, not via the widget .. the human can, ofc)
15:51:12 <peter1138[d]> I kind of want to be able to throw a list of all possible strings for the widget at the system and let it do the hard work.
15:51:25 <truebrain> that is kinda what I now custom-wrote
15:51:30 <truebrain> so yeah, that would be lovely 🙂
15:51:34 <peter1138[d]> But making a list of all possible strings is not exactly light.
15:51:48 <truebrain> I just wonder if I should be using `std::pair` or `std::map` here 😛
15:52:12 <peter1138[d]> So many things... "just use unity" right?
15:52:19 <truebrain> like it is easier in unity
15:52:22 <peter1138[d]> Or is it dogot that is the thing now...
15:52:44 <peter1138[d]> Easier, just your game will use 16GB ram...
15:52:56 <truebrain> UI design in Unity I found horrible
15:53:00 <truebrain> in Godot it is a tiny bit better
15:53:14 <truebrain> in general, I found Godot easier to work with
15:53:19 <truebrain> more my way of thinking 😄
15:54:04 <truebrain> sorry Rubidium, I should have been more careful with my wording regarding certificates; mostly people don't actually care, so I tend to be a bit lazy 😄 But that wasn't useful in this case 🙂
15:55:54 <_glx_> what matters for macos is the notarization done at build time I think
15:55:55 <_jgr_> Doing 2D UIs in Unity is painful
15:56:14 <_jgr_> The current widget system is absolutely fine compared to any of that
15:56:25 <truebrain> _glx_: Notarization is just creating a ticket in their backend that says: I have seen this binary, and I saw nothing wrong with it. It isn't actually much.
15:57:18 <truebrain> Most OSes / AVs do it the other way around: on the client system it goes: I never seen this hash of the binary before, better send the binary to <insert scanner here>, and see if there are issues!
15:57:46 <truebrain> MacOS, with notarization, does it once per binary, the other solution does it once per client executing it
15:58:04 <truebrain> well, not really true; the result is cached for the other OSes / AVs too
15:58:24 <truebrain> so it is more about when it is done ... when the author says so, or when the first user starts it .. really tomato tomato, if you ask me 😄
16:02:04 <talltyler> Right, there’s an option with no pitchforks 😄
16:02:44 <talltyler> Don’t worry, I’ll get you some pitchforks with NotDaylength 😛
16:03:00 <talltyler> (As many as can be expected with an optional feature, anyway)
16:03:09 <truebrain> meant to ask: ND, when I start the game in its default configuration, I see NOTHING of ND, right?
16:03:17 <truebrain> it is only when I enable a setting, that I start to see its effects?
16:03:54 <talltyler> Yes, it was originally in world gen but now it’s just in settings
16:04:06 <truebrain> cool; so they can shove those pitchforks where the sun doesn't shine
16:04:16 <truebrain> we can iterate over features, but a feature behind a feature-toggle can never hurt anyone
16:06:35 <talltyler> There’s still a fair bit of iterating after these current PRs, I think. I still don’t know what GRFs should know of the calendar speed or cargo scale factors
16:09:00 <_jgr_> If you expose those to GRFs, it's just asking for GRF authors to try to undo the scaling, or to refuse to work if the player chose the wrong values
16:09:29 <_jgr_> Better to make the interface as scaling-agnostic as possible
16:09:33 <andythenorth> Such grf authors
16:09:49 <andythenorth> Also GS authors 😛
16:10:16 <truebrain> Only tell both the economy date, and that is that 🙂
16:11:19 <locosage> truebrain: you see it running 12% faster :P
16:13:03 <peter1138[d]> Wow, 12% is a big performance improvement for a new feature.
16:13:29 <peter1138[d]> Might be enough to offset path signals.
16:14:42 <peter1138[d]> I just loaded a Tetris-ish browser game and it took over a minute to load... assets... decompressing... urgh, What is this hell.
16:14:59 <xarick> Let's see who reaches destination first... who has the best node costs
16:15:39 <locosage> peter1138[d]: from performance pov it's more of a degradation than improvement :p
16:16:52 <talltyler> _jgr_: Yes, but it might be possible to give them some string codes for helptexts, like the new {TKM “months” “minutes”} and {UNITS_MONTHS_OR_MINUTES} and the like
16:17:21 *** Wormnest has joined #openttd
16:18:02 <talltyler> The unit codes take a number as a DParam and does unit conversion if needed (for days->seconds)
16:18:38 <peter1138[d]> You just said it's 12% faster.
16:18:51 <locosage> peter1138[d]: simulation faster, that's not performance
16:18:54 <peter1138[d]> 12% faster compared to vanilla would be surprising.
16:18:59 <xarick> NPF lost already! even with a npf_max_search_nodes maxed out
16:19:08 <locosage> performance is that you can now have 12% less vehicles in the game with same hardware
16:19:26 <truebrain> talltyler: btw, did you see glx comment about you breaking scripts with a rename? 😄 Am I right to assume that is on your todolist?
16:20:22 <_glx_> well the rename is skipped for scripts in current way
16:20:42 <truebrain> I used to have 10 vehicles in my game. And now I read I can only have 9. I will see which one to sell .. no issues further, but Discord tells me this 😦
16:20:51 <_glx_> my comment was about how to do it
16:21:14 <truebrain> _glx_: Owh, then I misread your comment 🙂
16:21:26 <peter1138[d]> If you're still complaining about 27ms vs 30ms, that ship has sailed, implemented in vanilla 9 months ago and now nothing to do with any daylength changes.
16:21:49 <locosage> daylength was the main reason for that change
16:21:51 <truebrain> Let talk about block signals now
16:21:51 <peter1138[d]> I notice all of the complaints about that come from one person.
16:22:43 <_jgr_> It would be simple enough to make it a setting in cmclient/your server
16:22:54 <locosage> well, I'll be sure to tell everyone that they can have less vehicles now so you can have more complaints :P
16:23:18 <peter1138[d]> I actually had that patch long before DL appeared, and 2TallTyler was trying to work without it.
16:23:40 <peter1138[d]> So it's entirely unfair to blame it on ND.
16:23:54 <peter1138[d]> Or whatever the abbreviation is at the moment 🙂
16:24:14 <talltyler> Wallclock mode is the current string for it 😉
16:24:17 <truebrain> At least now we have time like TTD 🙂
16:24:28 <truebrain> I sold my 10th train
16:24:42 <truebrain> No difference in how much ms a tick takes
16:24:48 <truebrain> But the 12% cut had to be made
16:25:11 <_glx_> scripts have more effect on ms/tick than vehicles 🙂
16:25:32 <truebrain> Do I now have to cut 12% of the scripts too?
16:25:38 <truebrain> I will remove some lines from each
16:25:50 <_jgr_> Scripts are easier to throttle as you can just reduce the ops limit
16:25:53 <locosage> cut from your chat :p
16:26:18 <xarick> i just noticed openttd 13.4 simulation is slower
16:26:54 <truebrain> Just don't cut 12% of my max windows please, I like my 100
16:27:15 <talltyler> The motivation was ND, but “following TTD” is a pretty strong justification, I think 🙂
16:27:30 <peter1138[d]> And if the game struggles on 27 but didn't with 30, it was marginally playable at full speed anyway. And when it slows down it'll slow down the same. In fact if you have the right number of vehicles you could slow it down to your fabled 30ms/tick.
16:28:20 <truebrain> What, 30 -> 27?! That is not 12%! That is just 10%! I am buying back my 10th trainA
16:28:52 <talltyler> Can I slow it down to 60ms/tick and claim I improved performance by 200%? 😛
16:29:20 <talltyler> It’ll still line up with ND, I just need to change my unit conversions… 😄
16:29:51 <locosage> truebrain: 1/30 -> 1/27 is 12% :p
16:30:00 <xarick> it says here 33.33 fps to 37.00 fps
16:30:42 <peter1138[d]> It's more like 11.111% but somebody's rounding.
16:30:45 <truebrain> 30 -> 27 is 10%! Fake news!
16:31:40 *** virtualrandomnumber has joined #openttd
16:32:09 <locosage> peter1138[d]: there is a certain point at where game becomes unplayable and vehicle amount is the main limiting factor. So that now happens with less vehicles.
16:32:12 *** virtualrandomnumber has quit IRC ()
16:32:43 <peter1138[d]> Only if you define "unplayable" as "the point where game ticks no longer keep up"
16:32:59 <locosage> actually, not even 12% of vehicles as world tick takes some, so TB may need to sell a few more depending on map size :P
16:33:02 <peter1138[d]> It's still actually going to run at the same speed.
16:34:20 <locosage> peter1138[d]: the point where lag is too much to enjoy the game
16:34:31 <locosage> or half of the clients can't join the server anymore :P
16:35:06 <peter1138[d]> There's lots of 1s there, if you add two of them together, you get a 2. Maybe that's how you get 12%.
16:35:58 <talltyler> Peter, did Bing Chat teach you that math? 😛
16:35:58 <locosage> I just didn't bother and used 33 and 37
16:36:53 <locosage> so, yeah, 11%, if TB had 10 times more vehicles he could've saved one :p
16:39:32 <locosage> talltyler: following TTD could be done with a setting
16:40:30 <locosage> it's ND that only works on 27tps
16:41:30 <xarick> tea time, leaving this on
16:50:19 <talltyler> locosage: Well, open a PR and we can debate it there, I guess. 🙂
16:58:26 <truebrain> Nah. Following TTD is in our manifest 🙂
16:59:46 <xarick> my custom costs are worse than master
17:00:26 <xarick> 346 days vs 338 days, still waiting for the yapf 13.4
17:01:12 <peter1138[d]> Although, build-on-slopes is a bad feature...
17:02:37 <xarick> yapf 13.4 wins with best path
17:06:03 <xarick> complete round results:
17:06:23 <xarick> to sum it up, I failed somewhere
17:06:32 <Rubidium> that's with breakdowns enabled, right? ;)
17:08:40 <locosage> truebrain: best advertisement for jgrpp ;p
17:09:26 <_jgr_> You could do that too if you wanted, you don't have to be network-compatiblewith vanilla
17:09:55 <xarick> btw, houses grow in this test sample
17:10:03 <locosage> the moment I'm not net-compatible I may as well move to your fork
17:10:09 <xarick> so maybe... maybe they could have a tiny influence on the path
17:10:30 <locosage> even if that doesn't do much for goal there is no point in having two incompatible forks
17:18:21 <xarick> uint32_t instead of TileIndex, because I can't use maths on TileIndex :/
17:25:43 <truebrain> Brrr, that is unreadable 😦
17:39:55 <xarick> I think I found a bug regarding connectivity bits between regions
17:42:50 <peter1138[d]> Hmm, named struct initialization is non-standard in C++17 isn't it?
17:43:50 <locosage> why are sprite drawing coordinates like this? this is a sawmill graphics replaced with ground sprites
17:43:58 <locosage> they all seem to have some random offset
17:45:27 <peter1138[d]> Only the groundsprites are... groundsprites.
17:46:00 <locosage> but where does this random offset come from?
17:47:38 <truebrain> peter1138[d]: Sadly. But only according to MSVC that is actually an issue
17:49:05 <locosage> peter1138[d]: does that mean that basically original baseset not only has xofs yofs for every sprite in grf but in code too?
17:49:30 <peter1138[d]> No, it has tile layouts for every layout in tables.
17:49:53 <peter1138[d]> Tile layouts define the bounding boxes (Ctrl-B)
17:50:16 <locosage> yeah, and in those layouts are offset that basically just combine with sprite offsets
17:50:19 <peter1138[d]> (They are not xofs & yofs, they are 3D boxes.)
17:50:42 <_zephyris> locosage: See my previous comment that basesets aren't (usefully) templateable...
17:50:58 <locosage> so it's essentially on offset relative to 3d box...
17:51:36 <_zephyris> You'll notice that ogfx2 positions sprites within the images so they're (approximately) correct relative to the ground tile, and x/y offsets set as necessary to make that the case.
17:51:44 <peter1138[d]> I'm surprised you get can as far as you have with grf-py without knowing about tilelayouts :p
17:53:08 <locosage> encoding/decoding them and understanding how they work is a slightly different thing :p
17:53:22 <locosage> also newgrf industries and vanilla industries work kinda differently
17:53:28 <peter1138[d]> The sawmill layouts are in table/industry_land.h:96-114
17:53:55 <peter1138[d]> They are linked differently but it's essentially the same.
17:55:10 <locosage> _zephyris: well, in python I have options xD can just parse industry_land.h and undo these offsets for example
17:55:27 <peter1138[d]> _zephyris: ideally the bottom north corner aligns approximately with the bounding box.
17:55:42 <peter1138[d]> You shouldn't undo the bounding boxes, you should create sprites that fit them.
17:55:49 <peter1138[d]> If you want different layouts, you need to use NewGRF industries.
17:56:46 *** HerzogDeXtEr has joined #openttd
17:57:04 <_zephyris> Ogfx2 imitates building shape/size closely, so that's fine, and IIRC I reverse engineered the offsets by making where the ground tile would be line up with the actual ground tiles.
17:57:15 <locosage> it's still much easier to work with uniform spritesheets than individual mismatched sprites
17:57:58 <locosage> _zephyris: at least for sawmill I don't think you did
17:58:05 <locosage> unless I missed these offsets
17:58:45 <_zephyris> _zephyris: "approximately"
17:58:48 <locosage> locosage: also bounding box doesn't really mean shit in most cases
18:00:18 <locosage> if some plaen is flying through the industry it's not gonna look right regardles of its bbs xD
18:29:43 <xarick> the new font 0 and O are nearly indistinguishable
18:33:43 <_zephyris> Original sprite and font
18:36:27 <xarick> hard to tell from that hex number if it was O or 0. Then I realized, it's a hex, so it couldn't be O
18:39:47 <DorpsGek> - Update: Translations from eints (by translators)
18:41:06 <_zephyris> The issue is using a font which is designed for normal text readability in an application which is scientific/programming.
18:41:44 <_zephyris> I'm probably going to add a barred/dot zero to the monospace font, might be nice to use that in strings which are for programming debug. Probably breaks a lot of string layout code though!
18:47:35 <peter1138[d]> Xarick is probably used to OpenGFX where the 0 is a different shape.
18:58:09 <_zephyris> Yeah, I see it's 1px narrower there... There is an argument for changing the sans font to have lining figures, but change = danger!
18:59:56 <_jgr_> It might be nice to have a change to improve the 'A' character, at least
19:01:07 <_jgr_> Even in in-game debug windows I doubt that the 0/O distinction is really that important
19:03:58 <peter1138[d]> A looks fine to me 😮
19:05:45 <_jgr_> The width/kerning is off so it ends up overlapping the next glyph
19:08:30 <peter1138[d]> I think that's been fixed -- we'll need to update the font of course.
19:09:04 <truebrain> did _zephyris make a new release for that yet? 😄
19:09:13 <truebrain> no preasure, just .. hurry up! 😛
19:09:25 <truebrain> peter1138[d]: named initialized looks much better
19:09:38 <peter1138[d]> VS Code with clangd does this 😉
19:09:54 <peter1138[d]> (If I don't name them it fills them in too)
19:10:09 <peter1138[d]> So, switch to C++20 right? hehehe
19:10:13 <truebrain> too bad MSVC doesn't allow: only do this part of C++20
19:10:15 <truebrain> it is all or nothing
19:11:00 <truebrain> well, we can at least make steps
19:11:03 <truebrain> shit like `warning: bitwise operation between different enumeration types ('FiosType' and 'AbstractFileType') is deprecated` is just bad 😛
19:11:37 <peter1138[d]> I have some patches but not many.
19:11:49 <truebrain> it is just a disaster
19:11:58 <truebrain> finish migration to std::string helps a bit
19:12:32 <truebrain> I was kinda hoping they would reverse it in C++23, but it seems not
19:12:34 <peter1138[d]> Hmm, -pedantic-errors... is pedantic.
19:12:40 <Rubidium> it doesn't really help much, as you'd need to migrate to std::u8string
19:18:49 <_zephyris> truebrain: No worries, I'll do it now. I was just waiting to ...borrow... the work printer to do some printed test sheets, it's the best way to spot character spacing/kerning/geometry errors.
19:19:03 <truebrain> no worries, just teasing you a bit 🙂
19:19:10 <truebrain> we got something great, now it needs to become EVEN GREATER 😛
19:20:42 <truebrain> `call to consteval function 'fmt::basic_format_string ...' is not a constant expression`
19:27:35 *** gelignite has joined #openttd
19:30:16 <truebrain> okay, we do not have -that- many `u8""`
19:30:28 <talltyler> Yeah, I opened the nightly and it was really nice to see the new font in-game 😄
19:32:41 <Rubidium> going u8string is essentially a no-go, as there's no std::stringstream nor std::format (nor fmt::format) variant that supports it (or u8/char8_t at all)
19:33:44 <truebrain> I hope I did that correctly 🙂
19:33:57 <truebrain> Rubidium: yeah, but I also don't see a point in upgrading to the `u8` variants
19:34:04 <truebrain> we have very few `u8""` strings
19:34:20 <truebrain> LordAro: yes; it fixes an issue! I was considering `Update`, but I liked `Fix` more 😛
19:34:26 <truebrain> open for suggetions, ofc
19:34:39 <LordAro> definitely more Update than Fix
19:34:57 <truebrain> it fixes an issue, it is why we update
19:35:07 <LordAro> you could say that about translations too
19:35:13 <truebrain> I could also say: `Fix: misalignment with certain chars in OpenTTD TTF` 🙂
19:35:24 <truebrain> you could say every commit is an update too! Such choices 🙂
19:35:46 <_jgr_> I suppose fonts are a kind of code, it must be a Codechange
19:36:11 <LordAro> "Change: Update the code"
19:36:30 <LordAro> "Change: Update the code to fix a feature"
19:36:33 <truebrain> Change: Update an Addition to Fix a Feature that Revert some Docs
19:36:50 <truebrain> now you fix my title to what-ever you want, and call it a day? 😄
19:40:40 <truebrain> LordAro: better title? 😄
19:40:45 <truebrain> (I can be such a troll, I am sorry)
19:42:16 <truebrain> haha, some of our CI runners are too old to compile C++20 correctly 😄
19:43:06 <truebrain> `error C2385: ambiguous access of 'Blitter'` MSVC also came up with something new 🙂
19:44:27 <truebrain> okay, the other targets do manage to compile; that is somewhat surprising
19:47:54 <LordAro> truebrain: you're a funny man
19:52:20 <truebrain> you don't read binary? Pff
19:58:30 <peter1138[d]> TrueBrainviaGitHub: I like the "it-doesn't-compile-just-comment-it-out" style 😄
19:59:27 <truebrain> if it works, it works!
20:00:31 <peter1138[d]> IIRC it does not like runtime selection of format string.
20:00:54 <truebrain> yeah, but not all cases are trivially fixed
20:00:57 <truebrain> `fmt::runtime` does a lot
20:02:19 <Rubidium> I'm figuring out the best solution to the fmt issues
20:02:23 <truebrain> but some statements we created ... awesome
20:02:32 <truebrain> not all fmt issues are equal; I am fixing a bunch
20:02:43 <truebrain> `IConsolePrint` has some .... "misuse" 😛
20:03:18 <xarick> version of openttd is the most time consuming part of a bug report...
20:03:32 <peter1138[d]> Hmm... what did I call my branch? C++20 would've been too obvious.
20:04:04 <peter1138[d]> xarick: copy & paste from first line of openttd -v?
20:04:36 <xarick> not that version, because I detected it on my branch, but I know it's also on master
20:04:38 <truebrain> we have a few ```ZOOM_LVL_MIN < _settings_client.gui.zoom_min ?
20:04:38 <truebrain> "The lowest zoom-in level allowed by current client settings is {}." :
20:04:38 <truebrain> "The lowest supported zoom-in level is {}.",```
20:04:41 <truebrain> which is just bad code
20:04:55 <peter1138[d]> I think I just expanded them out.
20:05:02 <truebrain> so I am fixing a bunch of these first
20:05:18 <peter1138[d]> Ahh, I called by branch "uhh"
20:05:32 <truebrain> (as I already changed IConsolePrint to actually check for formatting 😛 )
20:05:45 <peter1138[d]> DumpDebugFacilityNames gains a "{}" 😄
20:06:10 <peter1138[d]> New method of distributing patches... I'm lazy.
20:06:44 <andythenorth> GPT can probably parse that
20:09:36 <truebrain> this will be many many many many many recompiles 🙂
20:10:29 <truebrain> with C++20 we can also change a lot of `inline` and `constexpr` to `consteval` 😄
20:10:41 <truebrain> also shows a healthy amount of "this doesn't actually do what we thought it did" 🙂
20:11:37 <truebrain> I am going to do them one by one
20:12:36 <peter1138[d]> Some of these commits are also good without switching to C++17.
20:12:47 <peter1138[d]> (I know at least one of mine already got merged :D)
20:15:28 <truebrain> also so many enum weirdness to fix 😛
20:15:40 <truebrain> not sure what the best approach is there
20:16:01 <truebrain> a lot of casting is also annoying to read
20:16:05 <truebrain> but `enumA + enumB` is a bit weird
20:17:21 <truebrain> Rubidium: if you like to help out, I do not understand what is wrong with `GetOutputFilename`. The `{%Y%m%d-%H%M}` seems no longer valid.
20:18:14 <Rubidium> for the enums I fear casting is the only thing, unless you want to define a lot of operators
20:18:20 <Rubidium> ... and do the casting in there
20:18:58 <peter1138[d]> StrongType & .base()? 😉
20:19:34 <peter1138[d]> Or operator overloads maybe.
20:20:04 <peter1138[d]> If that's possible then it also ensure you only add the correct things together.
20:20:41 <truebrain> for some things overloads would make sense
20:20:46 <truebrain> for other things wrapper functions
20:20:50 <truebrain> but there are a lot of them! 😛
20:21:08 <Rubidium> most seem to be the TFT constants that get added to widget numbers
20:22:10 <peter1138[d]> Oh that's nicer than what I did.
20:23:05 <peter1138[d]> Main thing I noticed is that there's only half-a-dozen callers, so I just added fmt::format() to each 🙂
20:23:23 <truebrain> it was just poorly forwarding 😛
20:23:31 <peter1138[d]> Saves that whole template function, heh.
20:23:50 <peter1138[d]> I can delete my patch now, that's about as far as I got ;D
20:25:43 <Rubidium> truebrain: for the GetOutputFilename, add a : before %Y
20:27:10 <truebrain> yeah, very odd comment of Rubidium _glx_ 🙂
20:29:49 <truebrain> peter1138[d]: see, my VSCode is also being an ass, and removing spaces!
20:31:59 <truebrain> okay, that were all fmt issues 🙂
20:32:38 <truebrain> I love VSCode regex search&replace 🙂
20:32:46 <peter1138[d]> It is good isn't it.
20:34:34 <_glx_> shows how used NewGRFProfiler is 🙂
20:35:07 *** gelignite has quit IRC (Quit: Stay safe!)
20:39:40 <truebrain> I think I have a relatively clean solution to the `u8` issue
20:39:48 <truebrain> then it is not all that bad, honestly
20:39:54 <truebrain> still leaves me puzzled by the MSVC issue 😄
20:42:30 <xarick> looks like the optimization needs to be undone
20:42:38 <xarick> that one comparing number of patches
20:42:42 <frosch123> why do we use u8"" at all?
20:42:57 <truebrain> easier to write `\u..` than to figure out the `\x..\x..\x..`
20:43:05 <truebrain> we used to have a lot of mistakes with the latter
20:45:14 <frosch123> "/utf-8" or "-finput-charset=utf-8"
20:46:13 <truebrain> and you want to teach that to all our editors too? 😛 😄
20:46:56 <frosch123> what have editors to do with that?
20:47:14 <truebrain> owh, it is still `\u`
20:47:28 <truebrain> otherwise, ^^ is always a solution
20:48:39 <frosch123> i was not even aware u8"" was c++11, i thought that was c++20 only 🙂
20:48:54 <truebrain> we switched to that long long ago, as ... issues 😄
20:49:03 <truebrain> we used to have utf-8 encoded chars in the code, that was also fun
20:49:05 <peter1138[d]> constexpr auto &operator""_as_char() ... what an operator.
20:49:21 <truebrain> but it is a clean solution for the few usage we have
20:49:26 <truebrain> now let's try frosch123 's idea
20:53:25 <truebrain> _glx_: you happen to have any idea what MSVC is talking about with the `Blitter` thing being ambigious?
20:55:42 <truebrain> frosch123: it is a bit ironic, that for weeks / months, on and off, we are bitching about the inability to use C++20 due to the `u8` .. and you are like: euh, dudes, why not just do this
20:55:55 <truebrain> happy you are here 🙂
20:56:51 <_glx_> my guess is because `class Blitter_32bppSSE4_Anim FINAL : public Blitter_32bppSSE2_Anim, public Blitter_32bppSSE4 {` both derivates from `Blitter`
20:57:59 <truebrain> mind looking for what a solution might be here?
20:58:26 <frosch123> well, in this case... I seem to have missed some stuff 🙂 at work multiple people are waiting to finally use u8string when c++20 is available somewhen. noone seems to be aware (including me) that std::format and a whole lot more stuff does not support it
20:58:32 <frosch123> I just learned that today from here :p
20:58:49 <truebrain> there are so many rants about the u8 stuff in C++20
20:58:55 <truebrain> especially the backwards incompatibility
20:59:00 <truebrain> (not rants here, but on the interwebs)
20:59:17 <truebrain> I am also still not sure what it actually offers, that we would like to use it
20:59:24 <truebrain> but that is because I never got passed the rants people give 😛
20:59:31 <frosch123> yes, i found them now, years old, still never saw them at cppcon or HN or ...
20:59:45 <truebrain> owh, they have been on HN 😄
21:00:03 <_glx_> randomly tried with `inline void Blitter_32bppSSE4_Anim::Draw(const Blitter_32bppAnim::Blitter::BlitterParams *bp, ZoomLevel zoom)`
21:00:11 <truebrain> wth is CodeQL smoking?
21:01:46 <truebrain> _glx_: tried as in, that works?
21:02:18 <_glx_> but I think any other parent could work too
21:02:52 <truebrain> right, this clang issue ... I had it before, and I fixed it .. hmmm
21:03:07 <truebrain> ah, yes, clang version
21:03:08 <_glx_> `inline void Blitter_32bppSSE4_Anim::Draw(const BlitterParams *bp, ZoomLevel zoom)` works too
21:04:18 <_glx_> and I didn't touch the header at all
21:04:20 <truebrain> let's see what that does .... 🙂
21:04:44 <peter1138[d]> I make one gist comment that uses C++20 feature and TrueBrain goes all out 😉
21:04:52 <truebrain> been bugging me for months
21:04:57 <truebrain> the Social plugins are C++20
21:05:16 <truebrain> just this named initializer for structs .. SO much more readable
21:05:34 <truebrain> so many places in OpenTTD would improve because of that
21:05:54 <_glx_> isn't span in c++20 too ?
21:06:20 <truebrain> anyway, not saying we should switch to C++20
21:06:30 <truebrain> but it does show minor issues with our code, we might as well address 🙂
21:07:00 <_glx_> yeah switching would be another funny thing for linux generic 🙂
21:07:08 <truebrain> the social plugins build fine
21:08:18 <truebrain> right ... `WID_.. + <integer>` ..
21:09:58 <Rubidium> this will help for many of those `WID_ + ` cases, though not all
21:13:11 <truebrain> Rubidium: seems you miss like 5 or 6 more of those declerations to cover most
21:13:19 <truebrain> shall I make a commit and add it to your PR?
21:14:50 <Rubidium> I wasn't really sure about the other declarations yet, but sure
21:15:03 <Rubidium> if you're at it, change the C-style cast as well ;)
21:16:58 <truebrain> some enums have `NNN_BEGIN,`, others `NNN_BEGIN = 0,`
21:17:03 <truebrain> identical, but .. make up your mind!
21:22:38 <truebrain> okay, that fixes 90% of the warnings
21:22:43 <truebrain> few silly ones left
21:23:52 <truebrain> Rubidium: the only one I doubt about, using your macro, is with `SmallMapWindow::SmallMapType`
21:24:44 <peter1138[d]> I... didn't know we had an HDR option.
21:25:16 <_glx_> we don't directly, the OS manages it and we tell it we understand
21:25:40 <_glx_> but fullscreen is not borderless, it's real
21:27:04 <peter1138[d]> Are you thinking of high dpi?
21:27:46 <Rubidium> truebrain: it looks like a candidate for it, just need to swap the order
21:28:03 <truebrain> yeah, but it is an class-enum .. let's try if that works 😄
21:28:19 <_glx_> ah yeah high dpi, but fullscreen disabling HDR doesn't surprise me
21:29:14 <truebrain> tons of topics about similar issues with Windows, with various of suggestions to fix it
21:29:17 <truebrain> I doubt we are causing it
21:29:55 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:30:08 <_glx_> HDR is broken in many way anyway
21:30:18 <_glx_> screeshots can have random colours
21:32:20 <truebrain> Rubidium: seems it can only be fixed by moving the enum outside the class
21:32:40 <truebrain> as otherwise the compiler things it is an operator for the class 😄
21:33:20 <truebrain> yeah, let's go for that ...
21:33:47 <Rubidium> truebrain: just to check, there are still some warnings in direction_func.h after this, right? Those are the ones where I would definitely not make them generally addable, as in those cases it makes little sense to add them. Except in those hacky functions
21:34:12 <truebrain> Rubidium: already done, yes (via `static_cast`)
21:34:16 <truebrain> I only applied this to WID additions
21:36:25 <truebrain> and all of a sudden, only 1 warning remaining ... 😄
21:36:33 <Rubidium> #11808 looks okay to me
21:36:55 <truebrain> could use an approval of another dev, as both me and Rubidium wrote it 🙂
21:37:00 <_zephyris> I assume this isn't the intended behaviour? Switching from TTF -> sprite font when using a language not supported by the sprite font doesn't trigger fallback to a system font.
21:37:14 <truebrain> _zephyris: is a bug-report about that already yes 🙂
21:37:25 <truebrain> only michi_cc[d] can answer the "intended" part 😛
21:38:02 <truebrain> hmm .. could use suggestions for `(rail_track & ~::TRACK_BIT_ALL)`
21:38:04 <truebrain> that one is just odd
21:38:14 <truebrain> static cast both to their base type?
21:41:26 <truebrain> that ^^ should be warning-free now.
21:44:15 <truebrain> not that much work after all 😛 😛 😛 (I looked at this so many times .....)
21:45:21 <peter1138[d]> Ready for merge then 😉
21:45:31 <truebrain> removing custom `span` first
21:49:00 <truebrain> there are many more "flipped" .. I picked up those I saw 🙂 But will add thisone too 🙂
21:51:36 <truebrain> `for (uint c = 0; c < MAX_COMPANIES; c++) {`
21:52:40 <_glx_> not the only occurence I fear
21:52:49 <truebrain> fixed those involved with `WID_` 🙂
21:53:08 <peter1138[d]> I've been slowing switching things to range-for...
21:53:46 <peter1138[d]> Not everything though, sometimes an index is needed as well.
21:53:58 <truebrain> can't find one 1-2-3
21:54:48 <truebrain> all `for (CompanyID ` are old-style 🙂
21:55:54 <truebrain> owh, you meant iterating over `Company` , not `CompanyID`? 😄
21:56:02 <peter1138[d]> No, I wouldn't use a range-for in this instance either, sorry.
21:57:00 <truebrain> okay, all our CI targets seem to process C++20 just fine
21:57:10 <truebrain> LordAro will be happy with that 😛 (hihi, sorrrryyyyy ....)
21:57:28 <truebrain> you know I love you 🙂
21:57:36 <peter1138[d]> constexpr NWidgetPart was the "oh that reminds me" from last night.
21:58:29 <truebrain> undrafted #11800 😛 Not sure we have a good enough argument, but the PR itself is done 🙂
21:58:55 <michi_cc[d]> _zephyris: No, that is not intended behavior. There's obviously a call to some function missing, now we just need to figure out which 🙂
21:59:17 <truebrain> I am sure OpenTTD Only has a handful of functions 😄
21:59:29 <peter1138[d]> Well, is there a reason not to go with C++20?
21:59:29 <truebrain> clearly I am in a mood today 😛
21:59:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:59:34 <peter1138[d]> Maybe we should just go to C++23...
21:59:36 <michi_cc[d]> truebrain: Forgetting about OpenTTD-font.md really didn't take long 😜
21:59:47 <truebrain> that is just terrible
22:00:02 <truebrain> well .. so .. yes ...
22:00:12 <peter1138[d]> commit hook: if fonts updated, updated .md ;D
22:00:30 <truebrain> it is really bad; I mean, I ask for it, I am the first to update, and I do not update it ...
22:00:33 <truebrain> it is wrong in so many levels
22:01:06 <truebrain> now it is a `Fix` right? 😄
22:01:10 <peter1138[d]> And some twit approved it.
22:03:30 <truebrain> forgetting that fits my mood perfectly
22:04:00 <truebrain> C++23 he says ... let's just try and see if that actually compiles 😛
22:04:51 <truebrain> 0 warnings, 0 errors. That is ... anti-climatic
22:05:26 <peter1138[d]> That was a quick compile...
22:05:40 <truebrain> 7950X does that for you
22:06:57 <truebrain> just because I want to know
22:07:48 <_glx_> when I want to test CI I do it on my fork 😉
22:08:03 <truebrain> where is the fun in that
22:08:28 <peter1138[d]> Does this make the game 12% faster?
22:10:16 <frosch123> c++23 compile probably only fails after we use some c++23 feature
22:10:29 <frosch123> the compilers may only pretend they know everything
22:10:55 <truebrain> at least not a C++20 nightmare
22:11:03 <truebrain> CMake ass `std=c++2b` 🙂
22:11:22 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:14:09 <michi_cc[d]> Quick poll regarding the sprite font switch: What should happen if somebody checks to option on an unsupported language? If I unconditionally add the `CheckForMissingGlyphs` call, it will just select the fallback font. This might be surprising, but OTOH, it would be the same like on startup.
22:14:38 <truebrain> could you prevent clicking the button? Or is that weird too?
22:15:34 <michi_cc[d]> Well, how do I know that it won't work before reloading the fonts? Our font searcher only looks at the loaded fonts, but the non-loaded fonts.
22:16:15 <truebrain> but yeah, I would expect it to pick the next best font
22:16:24 <michi_cc[d]> Or rather, not impossible, but a much bigger task than one added function call 🙂
22:16:40 <frosch123> not sure, but doesn't the button only make sense if either no ttf is active or the ttf font is active. if any other ttf is loaded, it should be disabled
22:17:24 <frosch123> i.e. the button should only be active, if the sprites would be used, not if a real external font is configured anyway
22:18:40 <frosch123> or the lang-files could have an info "ottd font is sufficient" instead of the auto detection
22:18:48 <michi_cc[d]> Well, how many people have a font configured for small, normal, large and mono?
22:19:11 <michi_cc[d]> Is that already in the survey?
22:19:12 <peter1138[d]> fallback detection should probably be fixed to work per font size, tbh.
22:19:14 <frosch123> it has been recommended and linked on forums for years
22:19:38 <peter1138[d]> (But most strings are normal-only)
22:19:59 <michi_cc[d]> Yes, but I don't think mono is mentioned that often, and strictly speaking the button only does nothing if all four fonts are set.
22:20:11 <truebrain> let that sink in ... less than 50% use the sprite font
22:20:26 <truebrain> (this is the actual font used btw; not the one requested)
22:20:51 <truebrain> so based on that small sample, I would even argue we can just remove the button 😛
22:21:35 <truebrain> (don't you just love I can slap survey results around? 😄 )
22:22:23 <frosch123> 30% are russian, korean, chinese, japanese
22:22:31 <truebrain> yeah ... JGRPP; curious what 14.0 will show 🙂
22:22:38 <peter1138[d]> michi_cc[d]: Unconditionally would at least make fonts work. Maybe the button state could reflect that it is not actually using sprite fonts.
22:22:59 <peter1138[d]> Leaving users with ???????????? is not too friendly 🙂
22:23:29 <truebrain> but are there actually users that want to use the sprint font?
22:23:41 <truebrain> can't we just leave it as a setting in the ini-file?
22:23:45 <truebrain> (wondering out loud)
22:24:18 <Rubidium> wow, an average of (almost) 5 hours playing. That feels like a lot to me
22:24:22 <peter1138[d]> Best way to find out: remove it and dodge the pitch forks.
22:24:25 <frosch123> i bet on: everyone who cares about the sprite font uses the original graphics, and is very vocal about it 🙂
22:24:40 <peter1138[d]> I resemble that remark.
22:25:25 <truebrain> Rubidium: lot of paused games I am sure 🙂
22:25:27 <michi_cc[d]> Well, let's fix the obvious bug first. Any further refinements can increase out commit count and let's us pretend to be busier than we are 🙂
22:25:30 <frosch123> still, the JGRPP demographics are weird, 35% non-latin users
22:26:01 <truebrain> michi_cc[d]: I helped with making a PR for C++23! 😛
22:26:14 <truebrain> I am kinda surprised most compilers accept it
22:26:25 <truebrain> I expected MSVC to go: NO
22:26:47 <peter1138[d]> Okay, let's try it here.
22:27:15 <_jgr_> frosch123: It wouldn't surprise me if the vanilla results are equally high
22:27:22 <truebrain> but yeah, switching to C++23 without using it, is pointless; still, was hoping for more fireworks on the CI 😛
22:27:41 <_jgr_> Non-English speakers aren't going to hang out on these English-speaking discords/forums/ec
22:28:06 <peter1138[d]> What are -MD and -MT compile options...
22:28:20 <truebrain> dynamic vs static, if I remember correctly
22:28:21 <michi_cc[d]> static and DLL c runtime
22:29:19 <michi_cc[d]> There even used to be multi-thread and non multi-thread versions of the runtime, but that might have been dropped somewhere along the way.
22:29:32 <peter1138[d]> Nah, that's /MD and /MT.
22:29:42 <peter1138[d]> -MD, --write-dependencies.
22:30:06 <truebrain> so we have to ask: what software? 😛
22:30:12 <peter1138[d]> It's just clang stuff, but yes the similarity confused me 😄
22:30:30 <_glx_> and that's a preprocessor flag I think
22:30:59 <truebrain> ` -MT <value> Specify name of main file output in depfile`
22:31:02 <peter1138[d]> Well, the CI failed anyway 🙂
22:31:10 <truebrain> ` -MD Write a depfile containing user and system headers`
22:31:13 <truebrain> that is just funny as fuck 😄
22:31:56 <peter1138[d]> (failed for C++23 that is)
22:33:50 <truebrain> now with only commits that are (still) relevant to that PR \o/
22:33:54 <truebrain> can't believe how small it got 🙂
22:36:15 <frosch123> the statistics are funny. some settings offer a lot of options, so you can add your personal "ending_year" to the statistics, which noone else uses
22:36:46 <frosch123> yet some weird values are used by mutliple people
22:37:42 <peter1138[d]> frosch123: Or the same person playing lots of games.
22:38:20 <peter1138[d]> 11811 worked with my clang at least 😄
22:38:51 <frosch123> oh... so it's not that all preteens like the numbers 420 and 69. it's just one person playing a lot
22:40:36 <truebrain> frosch123: If people are going to do that, I am going to bucket the values btw. But was hoping nobody would be that annoying 🙂
22:41:57 <truebrain> _jgr_: wow, you managed to fix that -very- annoying bug? Nice! I didn't know where to start every time I looked at it 😄
22:42:07 <peter1138[d]> frosch123: "Add ALL the NewGRFs"
22:43:02 <_jgr_> truebrain: I was trying to use those graphs just now and it was doing my head in 😛
22:44:31 <truebrain> So ... anyone against C++20 upgrade, or see any risk?
22:45:04 <_zephyris> michi_cc[d]: A parallel improvement is to add rasterised Greek and Cyrillic to the sprite font - if there's parity in characters in the sprite and ttf fonts then this won't pop up as an issue.
22:45:11 <peter1138[d]> Will it affect the 2014 generic Linux build?
22:45:28 <truebrain> Good point; will start a build on my fork to check
22:46:17 <_glx_> and the other generic one
22:47:45 <xarick> closest ship depot finally deals with aqueducts properly and gets the real closest depot in case of multiple depots in the destination region
22:47:53 <truebrain> frosch123: No? All fields that could contain user-identifiable information is only skipped
22:48:15 <truebrain> Driver options I saw little risk in
22:48:24 <peter1138[d]> server_port and admin_port could be removed.
22:48:36 <frosch123> extmidi may contain a filesystem path?
22:48:48 <frosch123> not sure, never used it :p
22:48:57 <xarick> Now I need to add the boring stuff like comments and such...
22:48:59 <truebrain> Basically, all settings that are not in private are sent
22:49:10 <peter1138[d]> It could but nobody except me uses extmidi 😄
22:49:16 <truebrain> There is no further filtering
22:49:42 <truebrain> Anyway, I can always filter fields during analysis if they turn out to contain such info
22:49:47 <truebrain> Let's wait and see 🙂
22:50:14 <Rubidium> hmm... too bad that std::format is only supported from GCC 13 and I'm still at 12 :(
22:50:44 <frosch123> yeah... custom currencies may be a problem...
22:51:22 <truebrain> We can worry about anything, or wait if it is actually a problem. But a good reminder that all info here is also in a crashlog
22:51:28 <peter1138[d]> game.settings.support8bpp: no 100.0%
22:51:34 <truebrain> So if it is a problem, it already was
22:52:06 <truebrain> (And so would require action :D)
22:52:12 <frosch123> it may be better to remove all strings from the public website. servers with offensive names are already a problem but the stats are kind of permanent?
22:52:45 <truebrain> Can't we wait to see if it is actually an issue?
22:53:09 <truebrain> As many useful settings are strings
22:53:26 <truebrain> So it seems a bit of overreacting 😄
22:53:51 <frosch123> sure, it also depends in what places the existence of such page is posted 🙂
22:54:14 <truebrain> Where you see it now, and on GitHub repo
22:57:19 *** Wormnest has joined #openttd
22:57:19 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:08:13 <wensimehrp> michiccviaGitHub: Shouldn't the tooltip be tweaked to tell the players whether their language js supported by the font?
23:10:28 <wensimehrp> Say, If I use English, the tooltip would be "......The font supports the current language" and if I use Chinese the tooltip would be "the font doesn't support the current language"
23:10:42 <xarick> English question for a comment!
23:10:42 <xarick> > * Tests the provided callback function on all tiles of the current region, and determines which tile
23:10:42 <xarick> > * reached from the neighboring water region patches is the closest by pathfinding standards.
23:11:00 <wensimehrp> wensimehrp: Making it language specific would be better imo.
23:14:57 <truebrain> frosch123: Btw, other code I prepared removes any option that is used by <1%, and names it "(other)", under the assumption such small numbers aren't interesting, and avoids the simplest forms of abuse. But the too, I was like, let's first see a bit what happens 🙂
23:15:00 <peter1138[d]> It isn't language specific at all.
23:15:09 <peter1138[d]> It's available font and language specific.
23:16:33 <peter1138[d]> The sprite font is part of the baseset, different basesets can have different results.
23:17:45 <wensimehrp> I don't think that you quite get what I mean...
23:21:12 <xarick> is it @return or @returns ?
23:21:25 <_glx_> check other functions 🙂
23:23:00 <xarick> I see both methods being used
23:24:45 <truebrain> peter1138[d]: All green! So merge? 😄
23:24:56 <peter1138[d]> Might as well tbh 🙂
23:25:45 <peter1138[d]> Crap now I have to redo that patch...
23:44:00 *** Planarity has joined #openttd
23:44:00 <Planarity> I got really into OpenTTD some years ago--loved it. Amazing game.
23:44:00 <Planarity> The thing I always wanted was an easy way to just simply spread the introduction dates way out, so that I could use an early start and build and tune a whole network with early vehicles, then eventually get a few vehicle upgrades and have plenty of time to adjust/re-plan/re-tune all before the next set of incremental upgrades comes along, and repeat.
23:44:00 <Planarity> I just randomly decided to check in after some years away, and I see that there's a handful of pull requests that (if I understand them correctly) seem to accomplish exactly what I always wanted, so I wanted to express my excitement about that and extend my gratitude--thanks y'all!
23:47:08 <_glx_> there's even a test build for that feature if you want
23:50:38 <talltyler> Vehicle aging is totally broken in the test build, but I will work on fixing it this week 🙂
23:50:57 <Planarity> I'm a patient person, but I might poke around and see how the testing/feedback process works and whether I could help with that.
continue to next day ⏵
