IRC logs for #openttd on OFTC at 2024-01-14
⏴ go to previous day
00:19:04 <_glx_> ok I found the cause for broken WITH_ASSERT on MacOS, precompiled headers
00:23:24 <_glx_> but disabling pch helped to get a hint
01:08:26 <talltyler> Hmm, I guess I could have reopened #10119 instead, oops
01:20:07 *** gelignite has quit IRC (Quit: Stay safe!)
02:57:32 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
03:18:38 *** Wormnest has quit IRC (Quit: Leaving)
03:30:24 *** Tirili has quit IRC (Remote host closed the connection)
03:47:31 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:52:38 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
07:31:59 *** tokai|noir has joined #openttd
07:31:59 *** ChanServ sets mode: +v tokai|noir
07:38:45 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:50:02 *** D-HUND is now known as debdog
08:30:33 <andythenorth> Cleared coast tiles aren’t coast tiles?
08:31:12 <andythenorth> Happened with grf industry previously
08:31:32 <kuhnovic> I guess they aren't until they are flooded
08:43:52 <Eddi|zuHause> that sounds correct
08:44:40 <Eddi|zuHause> because cleared tiles aren't water tiles, they can't be coast tiles
08:53:05 <_zephyris> On the subject of possible coastline bugs, an object that can be built (cheaply) on water and land gets the large water clearing charge for diagonal coastlines
08:54:30 <kuhnovic> That seems excessive 😆
09:10:54 <peter1138[d]> I think if you run a train down such a rail tile it might crash.
09:13:13 <Eddi|zuHause> old TT had a cool bug that trains could run on diagonal shorelines
09:29:38 *** gelignite has joined #openttd
09:49:01 <truebrain> say hi to three new repositories 🙂
09:51:33 <truebrain> hmm .. CI doesn't trigger yet ... I forgot that you first need a workflow before it does that .. rather annoying
09:51:40 <truebrain> guess I will make 2 PRs out of this then
09:54:18 <peter1138[d]> std::max_element doesn't quite fit the bill, as a comparator would need to GetStringBoundingBox() both sides, and that results in way more calls than desirable.
09:55:21 <jfs> random thought I just had: a way to "rotate" orders lists, moving the first order to the last position, or last order to the first position
09:55:21 <jfs> with the idea being that sometimes you discover that the station you put as starting point for the list is no longer the logical end of the route
09:56:05 <peter1138[d]> Sorry we don't take suggestions... 😉
09:56:08 <emperorjake> JGRPP has a "reverse order list" function
09:57:43 <Eddi|zuHause> jfs: select an order, and have a "declare as start point" button
09:57:53 <truebrain> as we really need more buttons
09:58:23 <Eddi|zuHause> the order gui isn't overloaded enough yet
09:58:34 <Eddi|zuHause> we need to go all in
09:59:40 <truebrain> let's see if this fixes the issue ...
09:59:59 <Eddi|zuHause> if you have a departure board, you might also want one or more "use this as destination" marker for orders
10:00:16 <peter1138[d]> So a new repo whenever a new social presence plugin is wanted? Hmm.
10:00:32 <Eddi|zuHause> repos are cheap? :p
10:00:55 <truebrain> they are; their bugs are unique to that repo, and the maintenance burden would otherwise be high 😛
10:01:04 <jfs> Eddi|zuHause: I do like that idea better
10:01:28 <emperorjake> I find JGRPP's "append reversed order list" very useful as well
10:04:27 <truebrain> right ... and now to fix what-ever it is I did wrong in the configuration of those repos ...
10:04:33 <truebrain> ugh, didn't you wish people made less mistakes? 😄
10:06:00 <Eddi|zuHause> technically, making mistakes is the primary driver for evolution
10:06:02 <truebrain> owh .... I forgot a rather essential thing with GitHub Workflows ..... you do not have access to secrets when creating a PR ...
10:06:06 <truebrain> that .... is an issue
10:06:07 *** HerzogDeXtEr has joined #openttd
10:06:23 <truebrain> but surprisingly, you also don't have access to variables
10:06:27 <Eddi|zuHause> because ever so rarely, the mistakes turn out to be not-mistakes
10:06:31 <truebrain> those are just public, so I expected that to "just work" ..
10:07:05 <truebrain> yeah, even in a single repository this would be an issue
10:07:10 <truebrain> so not sure what your point is here 🙂
10:07:43 <truebrain> it would be 3x the burden how ever you slice it, as GitHub doesn't allow this 😛
10:08:26 <truebrain> ugh, it is nicely documented, but I did not expect variables, which are public viewable, to not be available from a fork ... hmmmmmmm
10:09:12 <peter1138[d]> Hmm, right, can I reimplement my split-pickers patch as custom widgets.
10:13:10 <truebrain> lol, some of those GitHub restrictions ... I get it, but pfffff
10:13:21 <truebrain> basically, they force everyone to be "secure", without the ability to create exceptions
10:13:38 <truebrain> so you get annoying repetition all over the place
10:14:07 <truebrain> an easy solution is to not accept PRs from forks, but .. that is another problem on its own
10:15:16 <truebrain> well, at least this works .. and I can do this for 2 out of the 3 plugins .. the 3rd ... hmmmmmmm .. the SDK is not public, so that is not easy 😦
10:16:03 <peter1138[d]> I think I can't, there are window events that aren't widget calls. Hmm.
10:23:07 <truebrain> `Since there are so many IP address ranges for GitHub-hosted runners, we do not recommend that you use these as allowlists for your internal resources. `
10:23:30 <truebrain> what other creative way exists to make the Steamworks SDK available to the runners, but not make it public, and not have access to secrets ...
10:25:12 <truebrain> `use and locally reproduce the SDK in source code form, solely to develop the Licensee Software; and ` .. that "locally" is the issue .. (quote from license of Steamworks SDK)
10:26:06 <peter1138[d]> Is "a copy of it inside the repo" considered local? 😄
10:26:23 <truebrain> one could kinda debate that, I guess 😛
10:26:32 <truebrain> what a lot of other GitHub projects do, is have it available in an internal repository
10:26:55 <truebrain> but that also doesn't make things any easier 😦
10:30:45 <truebrain> lolz; with `wget` I can download the SDK from Steam directly
10:30:47 <truebrain> but not with `curl`
10:30:51 <truebrain> so .. User-Agent whitelisting?
10:31:16 <truebrain> hmm, although, it now also works with curl. That really didn't work 2 weeks ago ..
10:36:34 <truebrain> owh, wow ... I searched for that, but didn't find anyone having it public
10:37:48 <truebrain> well, downloading it from their URL now also works .. so we will see .. if that starts failing, we just make a public repo 🙂
10:39:14 <truebrain> anyway, the real reason these are different repositories has to do that it means we can release them individually, with their own version number, using GitHub flows 🙂 As I expect some plugins to get more updates than others 😛
10:40:02 <peter1138[d]> It's fine, I was mostly joshing.
10:40:17 <truebrain> okay, these PRs are huge ... but I am very unsure if I can make them smaller
10:40:21 <truebrain> the actual code is like 20 lines of code
10:40:23 <truebrain> the rest is all ... bla
10:41:08 <truebrain> lol, and I broke the CI on one repo ... couldn't cancel the job, it wasn't starting, and a new push didn't help at all 😄 Bugs? In GitHub? 😄
10:41:47 <truebrain> right, next step is to get this to publish on our CDN .. and I kinda forgot how I did that with keys etc 😛
10:43:05 <truebrain> ha, I documented that rather well in the infra repo \o/
10:44:37 <truebrain> I wanted to call these plugins `social-steam`, but that turned out to be rather complicated in the code, to locate them .. so it now is `steam-social`, but it still annoys me 😛
10:45:20 <truebrain> (in OpenTTD it is much easier to search for `*-social.dll` than the other form)
10:48:36 <xarick> visual studio detects that!?
10:50:42 <truebrain> okay, adding signing keys was very easy .. I am happy with our infra-as-code 😄
10:52:27 <jfs> xarick: well yes, it tries to get debugging symbols for all modules that get loaded into the process, to be able to give the most useful stack traces regardless of where the program might break
10:52:59 <jfs> debugging symbols here meaning a way to translate memory addresses to names of functions, classes and variables
10:53:50 <xarick> interesting, so this is how anti cheat software detect malignous processes?
11:00:33 <truebrain> ``` template <typename T>
11:00:33 <truebrain> std::string &GetLongest(T SocialIntegrationPlugin::*member) const```
11:00:45 <truebrain> peter1138[d]: I never knew that was valid C++ syntax, but that kinda works to avoid duplication 😛
11:02:48 <truebrain> `GetStringBoundingBox(plugin->*member).width;`
11:02:50 <truebrain> that looks so weird
11:04:17 <peter1138[d]> Yes, that IS weird.
11:04:30 <truebrain> pff, my PR fixes a part of your PR! 😛
11:04:38 <truebrain> I should have PRd that; so tnx for doing this 🙂
11:04:38 <peter1138[d]> Well actually...
11:05:25 <truebrain> owh, you wrote that even in the description 😄
11:06:35 <peter1138[d]> I was looking at how you handled state in your custom widget and saw my code smell 🙂
11:06:44 <truebrain> the if-statement was funny 🙂
11:07:38 <peter1138[d]> If by funny you mean "temporary code that should never have made it in"... yeah.
11:07:58 <truebrain> `* @return The plugin that has the longest member.`
11:08:05 <truebrain> I think I am going to rewrite that sentence
11:08:52 <truebrain> longest -> widest, I guess
11:09:35 <peter1138[d]> And look, my environment added an included automatically again 😦
11:09:58 <truebrain> owh, I thought that was delibrate
11:10:01 <truebrain> but now you mention, it makes no sense 😛
11:10:56 <peter1138[d]> Although I am confused... where IS it included?
11:11:29 <truebrain> still can't believe you can pass a member to a template function .. so often I wanted to do that, but always assumed you couldn't
11:12:17 <peter1138[d]> And I need to turn off that feature.
11:14:14 <peter1138[d]> Is it included via script_window.hpp somehow? If so that seems odd.
11:14:25 <truebrain> we have such weird include-trees
11:14:29 <truebrain> we should prune that some day
11:15:03 <truebrain> but for that we need some kinda of convention ... should a header-file work on its own?
11:15:10 <peter1138[d]> Hmm, that would explain why so many files get recompiled when widgets are changed.
11:15:32 <reldred> did the increased newobjects limit per grf make it to openttd trunk or is that just a JGRPP only feature? (trying to get Fridaemon sorted with OpenTTD compatible releases)
11:15:42 <truebrain> I once, years ago, wrote a script to prune includes as much as possible; that was fun .. lot of recompiling 😄
11:15:44 <peter1138[d]> It is in vanilla, yes.
11:15:47 <truebrain> but yeah, script-stuff includes a lot of things
11:16:00 <truebrain> subversion called, they want their name back 😛
11:16:02 <reldred> peter1138[d]: awesome thanks.
11:16:04 <peter1138[d]> (It made it to JGRPP from master, yes...)
11:16:24 <reldred> peter1138[d]: Yeah wasn't sure what direction that one happened.
11:16:59 <peter1138[d]> Also stations, etc, at the same time.
11:17:03 <reldred> Awesome. I should be able to get him squared away then. Only major feature disparity between versions will just be road waypoints then.
11:17:13 <peter1138[d]> The only issue is it's not 13.4 compatible.
11:17:35 <reldred> Yeah, when's the expected 14.0 release? April fools?
11:17:38 <xarick> do you know of a free online no need to register website that allows me to create a diagram?
11:17:59 <reldred> has a downloadable version too.
11:18:11 <reldred> I do all my network designs in yed
11:18:31 <peter1138[d]> Not sure. 2TallTyler is doing a good job making sure we remember we need to make releases 🙂
11:18:53 <truebrain> test-game, merge, beta, right? 😛
11:20:00 <Eddi|zuHause> merge early, merge often :p
11:22:04 <peter1138[d]> Do you need pre-signals for that?
11:22:53 <michi_cc[d]> No no, only the godly path signals 🤣
11:24:02 <michi_cc[d]> truebrain: Sorry, but that should be "test-game, crickets, merge, crickets, beta, crickets, release, %"§J$%KJ"§KREJ"
11:24:34 <reldred> Hmmm, there are still some JGRPP specific flags for road stops though, RST_GENERAL_FLAG_BUILD_MENU_DRAW_DISABLED_VIEWS has just tripped me up doing a test compile
11:25:11 <truebrain> okay, broke it up into 5 commits
11:26:09 <truebrain> now to do that 2 more times 🙂
11:26:15 <truebrain> merge in a single repo after all? 😛
11:27:15 <reldred> This ring any bells for anyone?
11:27:36 <reldred> This is out of the JGRPP specification for roadstops, not recognised by NML
11:28:21 <reldred> I'm checking to see whether fridaemon is using it for anything specific
11:29:20 <peter1138[d]> Hmm, seems odd to me.
11:30:31 <peter1138[d]> Not sure if is that. It makes little sense to define graphics for something that can't exist.
11:30:31 <_jgr_> I expect that the only user of that is the GRF author who asked me to add it
11:30:37 <truebrain> so doing a curl on the Steamworks SDK worked a moment ago, and fails now. It is like it is randomly available, but closes soon after, or something odd ... lol
11:33:27 <_jgr_> reldred: Road stop GRFs which comes out of my NML branch should work fine in vanilla
11:33:39 <_jgr_> It's not necessary to maintain two GRFs
11:34:17 <emperorjake> so all Fridaemon needs to do is remove the version check?
11:34:26 <_jgr_> That said, that flag is not particularly important, you could just remove it
11:35:02 <reldred> _jgr_: Wasn't planning to, I was going to get Fridaemon back on upstream NML if it's got what he needs now.
11:36:47 <truebrain> and now curl does work again .. wth are they doing there, with their SDK download .. Steam is a bit silly
11:37:01 <truebrain> brownouts or something 😛
11:43:54 <truebrain> hmm .. possibly their nginx is just configured wrong, and if the entry is in the cache, it serves that
11:43:57 <truebrain> if not, you have to login
11:44:09 <truebrain> so when ever someone downloaded the SDK, it is in the cache for the next 30min, and you don't need authorization
11:44:42 <truebrain> that seems more likely than delibrate brownouts
11:46:50 <truebrain> hmm, no, at least, it doesn't seem to be the full story
11:47:01 <truebrain> okay, maybe I should not be debugging issues in their infra, and rather find a way that works for us 🙂
12:08:58 <truebrain> so indeed after the cache time runs out, the file is not available anymore
12:32:08 <xarick> is there a similar alternative that "it just works" by copy pasting code into it?
12:32:33 <xarick> this one has a limit, then it asks for money or an account
13:56:58 <truebrain> okay, right, what was I fixing .. ah, yes, the silly Steamworks SDK .. hmm
14:01:26 <peter1138[d]> Hmm, the widget_lookup stuff of #11628 is awkward.
14:02:26 <peter1138[d]> By design you have multiple widgets with the same WidgetID, which means the WidgetID to NWidget* lookup won't be correct.
14:02:47 <peter1138[d]> It might be better to not fill widget_lookup.
14:03:21 <truebrain> I removed the dropdown, so things are a bit easier now
14:03:30 <peter1138[d]> You are effectively using WidgetID to identify the child widget type.
14:04:11 <truebrain> it takes a bit more work to make this actually look pretty; but that is not the focus of this PR 😛
14:04:20 <truebrain> but ideally there is some more deligation going on
14:04:44 <peter1138[d]> Yeah, to be clear I'm not saying this is right or wrong or even needs to be addressed.
14:05:02 <truebrain> haha, if you remove it now, pressing on the text crashes the game 😄
14:05:09 <peter1138[d]> I'm copying the design for myself and trying to work out the best waY 🙂
14:05:20 <truebrain> I remember that is why I added it
14:05:31 <truebrain> the Window system makes an assumption that if there is a WID_, it can look it up safely
14:05:44 <peter1138[d]> Yes indeed it does.
14:05:46 <truebrain> so you need to register all WIDs, even if it is not pointing to the actual correct widget
14:06:12 <peter1138[d]> I have enough patch that ensures the WidgetID doesn't already exist, which would fail with this.
14:06:21 <peter1138[d]> But it also fails with another window in the game 🙂
14:06:41 <peter1138[d]> One that nobody except dP uses.
14:07:19 <truebrain> well, I could avoid registering duplicated widgets, by only giving the first iteration
14:07:27 <truebrain> so all WIDs would point to the first entry
14:08:18 <truebrain> `this->children[0]->FillWidgetLookup(widget_lookup);` basically
14:09:12 <peter1138[d]> I think it's easier to say that widget_lookup will point to *a widget* with that WidgetID, but there may be others...
14:09:26 <peter1138[d]> (i.e. it works like it does now :))
14:09:44 <truebrain> what it does now, is point to the last entry
14:09:46 <truebrain> as they just overwrite 😛
14:09:58 <peter1138[d]> And that's fine, it keeps it simple.
14:10:10 <truebrain> possibly; but also less clear
14:10:16 <truebrain> ``` /* Only register the WIDs of the first child; otherwise we register duplicated WIDs.
14:10:16 <truebrain> * Later on this is handled properly, as all WID activity is sent to this class,
14:10:16 <truebrain> * which does know what child exactly is being called. */
14:10:16 <truebrain> this->children[0]->FillWidgetLookup(widget_lookup);```
14:10:23 <truebrain> that might give more indication what we actually do?
14:11:11 <truebrain> makes it a bit more clear maybe that this is in fact a hack, and not a proper solution 😄
14:12:02 <peter1138[d]> You can already register multiple widgets with the same WidgetID just with _window_desc.
14:12:25 <truebrain> what is `_window_desc` ... 😛
14:12:41 <peter1138[d]> The place where you define the NWidgetParts.
14:13:00 <peter1138[d]> goal_gui.cpp:435
14:13:00 <truebrain> but I assume you meant you were working on a change that would trigger a problem when we register the same widgetID twice
14:13:05 <truebrain> as most likely it is a reason for a bug
14:13:09 <peter1138[d]> That defines WID_GQ_BUTTON_1 3 times.
14:13:32 <truebrain> lol .. does that actually do what is expected?
14:13:50 <truebrain> as no matter what the selection is, it always points to the last entry, not?
14:14:13 <peter1138[d]> Depends. DrawWidget(int WidgetID) will work the same for all 3.
14:14:28 <truebrain> but the push-state, I would expect that doesn't work in the first 2
14:14:37 <peter1138[d]> It only fails if you try to GetWidget<>(WidgetID)
14:14:42 <truebrain> unless WWT_PUSHTXTBTN doesn't actually use GetWidget 🙂
14:14:53 <truebrain> okay, so it works by luck 😛
14:14:58 <peter1138[d]> Not sure. I've never seen this window because nobody uses it 😉
14:15:17 <truebrain> okay, I will leave me code as it is for now
14:15:26 <peter1138[d]> Yes, it's not wrong at the moment 🙂
14:16:05 <truebrain> okay, the SDK can be downloaded again ... this URL is so weird ... I can't find what triggers it being added to the cache ...
14:16:07 <peter1138[d]> Also in that goal_gui, there are 4 identical windows, except just the colour changes.
14:16:12 <peter1138[d]> And maybe a string id.
14:16:42 <peter1138[d]> IMHO it's a candidate for being built by a function.
14:16:56 <peter1138[d]> With the colour, and number of buttons, as parameters.
14:17:05 <truebrain> I still have this weird tendency to try and move all the window declarations outside of the C++ code, like in a YAML or what-ever ... but I will not! I am first going to finish social integration 🙂
14:17:32 <truebrain> peter1138[d]: yeah, that would make much more sense; I think there are more windows that would be easier to understand when they are build up by components
14:18:15 <peter1138[d]> Advantage the way it is is you can't put non-existant string IDs in, etc.
14:18:32 <peter1138[d]> If it gets compiled to an intermediate file I guess it would get caught, but.
14:18:43 <truebrain> yeah, I was still thinking compile-time
14:19:13 <truebrain> I have to say, the tabs and EndContainer do already help a lot in understanding the structure of a window
14:19:27 <truebrain> so maybe having the ability to use components would be a better step in making things more understandable 🙂
14:19:43 <peter1138[d]> Maybe I should fix all current widgets...
14:19:51 <truebrain> so .. SDK .. just make a public repo under OpenTTD and slap the zip-file in there?
14:20:01 <peter1138[d]> WWT_PANEL is a pain, becuase usually the EndContainer() is hidden on the same line.
14:20:12 <peter1138[d]> What's the worst that could happen?
14:20:43 <truebrain> GitHub doesn't really like using repos like that 😛
14:20:51 <truebrain> but I guess for 22MB it isn't an actual issue
14:21:02 <merni> I have seen repos that just have pdf books in them
14:21:16 <truebrain> the fact you see it doesn't mean it is okay or allowed 🙂
14:21:32 <truebrain> being a good citizen takes a bit more effort 😉
14:21:41 <merni> No, but it does say something about the likelyhood of GH doing something about it :p
14:22:04 <truebrain> I always hope people don't think like that when it comes to stuff we host on openttd.org
14:22:18 <truebrain> like: owh, I can download all NewGRFs, I just need 5, but this is easier
14:22:35 <merni> what benefit does anyone get from downloading every newgrf though
14:22:44 <truebrain> yet people did, several times a day
14:22:46 <merni> it would just take a lot of time
14:22:53 <truebrain> I am just saying: just because you can, doesn't mean it is the right thing to do
14:23:00 <truebrain> so the argument: I see other people also do it
14:23:08 <truebrain> is just ... well ... I rather not work like that 🙂
14:25:44 <truebrain> wow, the SDK is 1.5MB of header-files
14:30:41 <peter1138[d]> Hmm, is this a bug? The warning window is all yellow. The error window is red caption but the rest is yellow.
14:30:54 <peter1138[d]> I think that is probably meant to be all red.
14:35:57 <michi_cc[d]> One thing to keep in mind with non-unique widget IDs is the "tutorial" GS stuff. Not really relevant for the game options window, but something to keep in mind generally.
14:36:25 <truebrain> good reminder; forgot that even exists 😄
14:39:03 <truebrain> okay, this will have to do for now; not ideal, but I also ran out of better ideas
14:39:21 <truebrain> now all it needs is reviews 😄
14:40:01 <truebrain> and a leason: commit before push, wouldn't hurt either
14:43:39 *** axet has quit IRC (Remote host closed the connection)
14:45:56 <peter1138[d]> Oh, you can't pass information to an NWidgetFunction :/
14:46:01 <peter1138[d]> I guess I need to fix that too.
14:46:17 <truebrain> down the rabbit hole you go!
14:46:38 <peter1138[d]> I could cheat with file-scope statics...
14:47:21 <peter1138[d]> I wonder if this can be done nicely with templates, or if I need to pass a void *userdata...
14:48:03 <peter1138[d]> part.u.func_ptr = func_ptr
14:48:08 <peter1138[d]> Yeah, I think not for templates.
14:49:16 <truebrain> ideally all widgets are just components, and can be created with NWidgetFunction 😛
14:50:07 <peter1138[d]> It's more like a state-machine right now.
14:53:14 <truebrain> okay, administrative-wise, I think I connected all the dots for social integration plugins .. once we start releasing, most of the other things should just follow easily.
14:53:18 <truebrain> will be interesting 😄
14:55:14 <peter1138[d]> Hmm, fluent-style with std::unique_ptr seems to be awkward.
15:00:57 <peter1138[d]> michi_cc[d]: I don't think that would allow different parameters though.
15:02:36 <peter1138[d]> I can't really see a way to get those parameters to MakeWindowNWidgetTree/MakeNWidgets/MakeWidgetTree.
15:03:58 <peter1138[d]> (Nor is there a way to get void *userdata through either, right now.)
15:22:59 <xarick> I'm going to need a TWaterRegionTraversabilityBits that also includes aqueducts
15:25:43 <xarick> there are 16 edge tiles per side
15:26:14 <xarick> meaning there's also 16 aqueducts possible per side
15:29:19 <xarick> wondering if I need to store information about the other region on the other side of aqueduct
15:30:41 <peter1138[d]> Hmm, that yellow window's text.
15:31:54 <peter1138[d]> Oh, same in master so it's not me.
15:33:28 *** Smedles has joined #openttd
15:41:23 <_glx_> The only user of yellow window
15:42:13 <frosch123> haha, inserting linebreaks in emojis is unexpected
15:43:39 <truebrain> we don't talk about linebreaks here anymore
15:43:42 <truebrain> everyone has nightmares
15:44:32 <peter1138[d]> Ah, they need {NBSP} 🙂
15:45:07 <frosch123> i have no idea whether ":{ZWNBSP}(" would work
15:45:12 <peter1138[d]> But yes, it was the text itself I was talking about, not the fact it's a yellow window 🙂
15:45:32 <frosch123> the text ":(" is correct, just unfortunate 🙂
15:45:35 <peter1138[d]> Oh right, I assumed there was a space.
15:45:52 <truebrain> not using smilies helps a lot 🙂
15:47:02 <peter1138[d]> Yeah there's no space. Hmm.
15:47:28 <peter1138[d]> A very sad gamescript.
15:47:45 <truebrain> even more sad with linebreaks! 😛
15:47:54 <frosch123> does the new ottd-font support emojis?
15:48:07 <truebrain> I am sure _zephyris doesn't mind adding 😛
15:48:30 <frosch123> yeah, there are hardly twice as many emojis as sprites in the baseset
15:49:47 <peter1138[d]> Hmm, colour emoji rendering...
15:50:26 <frosch123> probably a bad idea with our colourful window backgrounds
15:51:15 <peter1138[d]> Our fallback layouter doesn't consider 😦 to be breakable.
15:51:29 <peter1138[d]> Thanks Discord. Not.
15:52:43 <peter1138[d]> Maybe line-breaking for centred text could be improved to try splitting half-way instead of as much as possible on the first line.
15:53:25 <peter1138[d]> (Assuming there's enough vertical space for the whole thing, hmm...)
15:53:44 <truebrain> or maybe we shouldn't optimize for sentences that end with a smiley 😛
15:58:57 <peter1138[d]> truebrain: Turns out I accidentally fixed that, not long ago, with #11641.
15:59:39 <peter1138[d]> RaiseButtons() used to have the widget, but call RaiseWidget(index) anyway.
16:00:02 <peter1138[d]> In that change I made it do wid->SetLowered(false) instead.
16:02:40 <peter1138[d]> Hmm, that's for raising, anyway, not sure about lowering.
16:04:18 <peter1138[d]> Don't think it actually matters in this case because the window will disappear the moment it's pressed anyway.
16:12:15 <_zephyris> truebrain: I was tempted to add some transport related ones... And code {train} and similar as ligatures...
16:14:24 <_zephyris> Ligatures aren't enabled though 😦
16:20:02 <peter1138[d]> Turns out putting hot water into the mug, as well as a tea bag, is helpful.
16:20:55 <LordAro> random idea: StrongType is only a thing for debug builds, and just gets stubbed out for release builds
16:21:13 <LordAro> or does it already compile away to nothing?
16:22:09 <peter1138[d]> Basically yes. It's all templates.
16:23:15 <LordAro> how much is "basically" ?
16:32:35 <truebrain> LordAro: it smells like your suggestion is already a premature optimization 😄
16:32:48 <truebrain> but given TileIndex is a StrongType
16:32:59 <truebrain> I am pretty sure there is very little we can convert to a StrongType that would have a bigger impact 😛
16:33:36 <LordAro> truebrain: oh i'm sure
16:33:49 <peter1138[d]> On a debug build, ,base() exists and is quite heavy.
16:34:05 <peter1138[d]> With an optimised build (-O1) it's gone.
16:35:03 <truebrain> so yeah, more StrongTypes! 😄
16:35:31 <peter1138[d]> This is .base() on godbolt.org
16:35:55 <Rubidium> well... the u8 "strong" type has a bigger impact :(
16:36:15 <peter1138[d]> As in "nothing compiles any more"?
16:36:56 <peter1138[d]> An yes, I did happen to already have strongtype in godbolt.org for some other trialling 🙂
16:38:19 <Rubidium> if you change your compiler to C++20 or C++23, then basically yes... nothing compiles anymore
16:39:31 <_glx_> yeah even plain C is broken with 23 IIRC
16:39:41 <truebrain> Yeah .. Still can't believe they fucked up chars that much...
16:40:43 <truebrain> peter1138[d]: Can't we force inline it or something, I wonder. Or do we like this in debug builds? 🙂
16:42:10 <peter1138[d]> inline doesn't change anything.
16:42:57 <truebrain> All that for a more readable cast 😛
16:45:20 <peter1138[d]> It's the same even as the cast.
16:45:45 <truebrain> Huh? That is unexpected.
16:48:43 <peter1138[d]> The only difference is the function signature is `StrongType::Typedef<...>::operator unsigned int() const` instead of `StrongType::Typedef<...>::base() const`.
16:50:17 <peter1138[d]> In both cases, with -O1 it's all compiled away.
17:17:25 <_jgr_> That is the suggested optimisation level for debugging
17:18:02 <_jgr_> Codegen with -O0 is so abysmal that it's not even worth it for debugging IMO
17:18:14 <peter1138[d]> That compiles it away.
17:18:36 <_jgr_> Well, yes it's a do-nothing wrapper
17:19:34 <peter1138[d]> With clang, -Og is the same as -O1.
17:20:49 <peter1138[d]> Hmm, with gcc it is basically optimized away even without optimizations.
17:21:05 <peter1138[d]> No it's not, I misread it.
17:24:36 <peter1138[d]> I'm fine with it being there, and being not there when optimized.
17:25:16 <peter1138[d]> I think LordAro was concerned it was still there and doing things even when optimized.
17:46:24 <jfs> talltyler: there is definitely a weird bug in the wallclock PR
17:49:45 <talltyler> Didn’t we already do that bug? Can you reproduce in nightly?
17:50:08 <talltyler> Last time it was to do with tileindex somehow, I wasn’t following closely
17:55:17 <jfs> no, doesn't happen in nightly 20240113 (from steam)
17:55:50 <_glx_> build is from last week
17:57:37 <talltyler> Test game is live, if anyone wants to join
17:58:57 <peter1138[d]> I don't remember a recent vehicle aging bug fix.
18:00:53 <talltyler> Well, it's happening to my road vehicle 1 in the test game
18:03:11 <peter1138[d]> Is date_fract progressed every tick?
18:04:27 <talltyler> When time is frozen, date_fract is never incremented
18:04:54 <peter1138[d]> That is kinda the point, yes 🙂
18:05:26 <peter1138[d]> But in RunVehicleDayProc() we use date_fract to decide which vehicle indexes to age, it seems.
18:06:18 <peter1138[d]> It's another "spread it out over time" use of it 🙂
18:06:33 <xarick> I remember recently I used date_fract to fix excessive pathfinding calls
18:07:13 *** Wormnest has joined #openttd
18:07:25 <peter1138[d]> Yes, if there's another tick that progresses (and wraps) every 74 ticks then that can be used for that one.
18:07:32 <talltyler> xarick: That will be changed to the economy date_fract, which keeps ticking normally
18:08:06 <peter1138[d]> But for vehicle aging it should be calendar time so not quite the same 🙂
18:08:17 <talltyler> Right, I'll need to handle that specially
18:08:46 <peter1138[d]> Yeah, it's an interesting one. We spread out the day ticks over the day.
18:09:12 <peter1138[d]> If time is frozen, they shouldn't get old, so that is simple.
18:09:20 <peter1138[d]> But if time is faster or slow... it needs to do ... something.
18:09:23 <talltyler> Aging doesn't seem connected to the date, if they are still aging with the date never changing
18:09:29 <talltyler> So yes, I'll need to investigate that
18:09:54 <peter1138[d]> They are aging because it's handled in CallVehicleTicks()
18:10:15 <xarick> why wouldn't vehicles age?
18:10:26 <xarick> also what happens to breakdowns?
18:10:37 <talltyler> Yeah, I thought I'd solved that when I switched it to economy time, but my tests were probably wrong because of this bug
18:10:49 <peter1138[d]> e.g. if daylength ends up being 148 ticks (2x) then should it spread out over 2 days? And how to ensure there are no missing or duplicated agings...
18:13:56 <xarick> I need a typename for x_or_y thingy
18:19:21 <peter1138[d]> Hmm, group_all is split by vehicle type, but sometimes we need bus vs truck, or road vs tram.
18:37:06 <locosage> this looks so weird....
18:37:32 <peter1138[d]> Long title plus larger-than-normal font size.
18:38:12 <talltyler> Yes, that threw me off when I first saw it -- I was trying to figure out what button was missing or being drawn wrong 😛
18:38:28 <locosage> I'd say cut off title but make a tooltip
18:38:51 <peter1138[d]> I'd say prevent using larger-than-normal font size.
18:39:04 <talltyler> Or remove the word Construction, it's not really needed
18:39:15 <locosage> it's perfectly normal font size
18:39:18 <DorpsGek> - Update: Translations from eints (by translators)
18:39:23 <locosage> any less and I can't read
18:39:27 <peter1138[d]> Or more realistically: if users want to use a larger-than-normal font size, don't care if the window layouts look odd.
18:40:47 <peter1138[d]> The standard way is to increase interface size so that everything is scaled in proportion.
18:41:16 <peter1138[d]> talltyler: It's part of the string provided by the NewGRF.
18:41:21 <locosage> font size doesn't matter when title is blow up by newgrf string
18:41:58 <peter1138[d]> What NewGRF is it btw
18:43:57 <peter1138[d]> I guess you need a vehicle set to make all the types appear
18:44:03 <wensimehrp> I have a suggestion: displaying the economic period and the current year together.
18:44:33 <talltyler> Yes, try Mop's Generic Road Vehicles -- and enable electrified road vehicles in NewGRF parameters
18:44:44 <peter1138[d]> Is that daylength? If so economic period is separate from calendar time.
18:46:01 <wensimehrp> It is separate from calendar time, but I think that including calendar time is better.
18:46:47 <peter1138[d]> Mop's Generic Road Vehicles doesn't seem to exist on bananas.
18:47:05 <peter1138[d]> Expanded exists.
18:47:05 <talltyler> Oh sorry, Mop Expanded Road Vehicles
18:47:13 <peter1138[d]> Ah, it's a parameter to enable electric road vehicles.
18:47:16 <talltyler> Generic was the old name
18:47:31 <talltyler> I have no idea why all vehicles are disabled by default
18:47:32 <peter1138[d]> What a weird way of doing things.
18:48:03 <peter1138[d]> Hmm, still doesn't enable it.
18:48:32 <peter1138[d]> It's a RattRoads option too, duh.
18:48:44 <peter1138[d]> parameter for speed units... oh dear.
18:49:43 <talltyler> If you give a NewGRF author a property...
18:49:57 <peter1138[d]> Looks fine with font size proportional to gui scaling.
18:50:05 <peter1138[d]> Slightly wider but not massively.
18:50:30 <xarick> `this->SetAqueductTraversabilityBit(aqueduct_dir, this->GetSideXorY(tile, aqueduct_dir));` a bit of repetition 😐
18:51:46 <peter1138[d]> Cropping text and using tooltips was a big no-no for the station picker window, no reason to think it'd be any different for these captions.
18:52:11 <peter1138[d]> Anyway, you can do what you like in your own fork 😄
18:52:55 <locosage> yeah, I don't play these grfs so I probably won't bother xD
18:53:09 <locosage> ah, no, I'll just remove the whole title one day
18:54:28 <locosage> I may not care about weird grfs but shit constantly eating my screen space annoys me to no end xD
18:54:50 <peter1138[d]> Oh I found a bug with the station cargo patch.
18:54:58 <peter1138[d]> It shows More... even if everything is displayed anyway 😄
18:55:08 <locosage> half of the time I can see where I want to click below all the windows :/
18:55:33 <peter1138[d]> That's a bit like hating RAM being used...
18:55:53 <peter1138[d]> (But only a bit)
18:56:59 <locosage> it's a bit like any other annoying thing :p
19:00:58 <talltyler> wensimehrp: The problem with this is that the year and period don't necessarily line up
19:01:13 <talltyler> Some periods might span multiple years, or vice versa
19:04:37 <wensimehrp> talltyler: I mean just using it as a point of reference, thus they don't have to be aligned.
19:06:01 <talltyler> Where would you draw the year?
19:06:02 *** gelignite has quit IRC (Read error: Connection reset by peer)
19:06:19 <locosage> peter1138[d]: btw, you can change units to tiles/day for extra width xD
19:06:33 <peter1138[d]> Yes but I'm not crazy.
19:06:56 <locosage> compared to wallclock this is nothing :p
19:07:12 <locosage> makes more sense than km/h even
19:07:24 <locosage> considering hour actually means something in wallclock
19:07:28 *** gelignite has joined #openttd
19:07:29 <peter1138[d]> What does "tiles per day" become anyway...
19:07:51 <locosage> and it even divides by 2 correctly by the looks of it
19:08:09 <peter1138[d]> That is hard to do for sure.
19:08:38 <talltyler> But what if a period includes two years?
19:09:48 <locosage> wensimehrp: idk, this seems to only add confusion
19:10:20 <wensimehrp> the one in tpf2 is more confusing though
19:48:29 <talltyler> Anything interesting?
19:48:42 <locosage> yeah, but likely not your fault
19:48:49 <locosage> Reason: NOT_REACHED triggered at line 267 of /__w/OpenTTD/OpenTTD/src/gfx_layout.cpp
19:49:32 <locosage> now, what I even did to cause this...
19:49:39 <locosage> I accidentally pressed something xD
19:50:35 <peter1138[d]> Haven't you learned? Don't press anything!
19:55:58 <locosage> does this count as a bug? xD
19:56:37 <talltyler> truebrain: The only bug we found (that I created) is that I totally broke vehicle aging. 😛
19:56:37 <talltyler> I will fix that this week and update the PRs, then ping you when ready for reviews. 😄
19:57:02 <locosage> locosage: though I guess that's just regular vanilla window redraw issue
19:57:15 <talltyler> Although #10606 is independent of my time changes and has been ready for months 🙂
19:57:27 <truebrain> talltyler: sounds good!
19:57:55 <talltyler> The new survey data from JGRPP helps demonstrate how people are using the similar settings in the patchpack though, which is very nice data to have 😄
19:58:50 <truebrain> hopefully someone dares to approve my Social Integration PRs soon too; after that, beta1! 😄
19:59:04 <talltyler> Yes, we found the bugs and I have to run errands 🙂
20:00:48 <locosage> locosage: hm, this is actually because the value is changing to ffff periodically for some reason...
20:01:52 <_jgr_> The evaluation of those variables depends on 0x100+ temp storage, which probably aren't being cleared before evaluation
20:02:12 <locosage> so, basically, just a debug window bug?
20:07:18 <truebrain> Rubidium: lol, yeah, I guess the network was never written to be on 24/7 😄
20:07:32 <truebrain> why do we have TCP redirect for debug anyway?
20:13:13 <truebrain> peter1138[d]: kind reminder #11648 is approved and ready for merge 🙂
20:22:56 <truebrain> michi_cc[d]: you add `fallback` to `MapCharToGlyph`, but for the life of me I cannot find where that is ever used? Am I missing something, or am I just blind?
20:23:27 <truebrain> ah, no, nevermind, hiding in one place there is actually a `false`
20:26:25 <truebrain> I have been wondering a bit if venderoing those fonts is the right way to go. We could also add them to BaNaNaS or bootstrap .. on the other hand .. this is probably fine. Maybe not complicated things more than they have to 😄
20:28:28 <truebrain> haha, I was wondering who added the debug redirect stuff, as it sounds like a stupid idea. It was me. I added it. To be able to develop for the PSP 😛
20:28:36 <_glx_> oh the '?' in console for chat messages is most likely LRM or RLM
20:32:56 <peter1138[d]> Unfortunately the source for those fonts isn't all the svg files, it's the fontforge files.
20:34:12 <peter1138[d]> It is possible to make a build script that imports them all from scratch but it loses all the information for has been manually altered afterwards.
20:34:41 <truebrain> sorry, what is the context of those sentences? Not sure who you are saying it to 😄
20:34:56 <peter1138[d]> Myself really :p
20:35:45 <peter1138[d]> It would've been nice to have a reproducible build from all the svg fiels, but it's not possible.
20:35:53 <truebrain> michi_cc[d]: ninja-edits; I liked your initial comment better 😛 Anyway, tnx for explaining 🙂
20:36:07 <truebrain> peter1138[d]: no? Awh 😦
20:37:21 *** gelignite has quit IRC (Quit: Stay safe!)
20:37:47 <LordAro> truebrain: i didn't know you had anything to do with the PSP port, thought it was entirely 3rd party
20:38:04 <truebrain> LordAro: nope; I did that all. But that was back in 2007 😄
20:38:12 <truebrain> when I was thinking: porting to handhelds can be good!
20:38:18 <truebrain> I no longer have that opinion
20:38:35 <michi_cc[d]> To expand a bit on the comment (just for anybody interested), CoreText does more than the other libs. For example what for Uniscribe is a 100+ line function is just a call to `CTTypesetterCreateLine` in CoreText. But for this to work we need to do more stuff to get it to treat the sprite replacement glyphs properly.
20:38:54 <truebrain> so CoreText is just better?
20:40:06 <truebrain> I remember MacOS had more places where it needed mor information; something about the cursor or something?
20:40:23 <michi_cc[d]> truebrain: Yes and no. It has fewer functions that do more, but at the same time this means less customization options for when you want to do stuff not exactly like sombody at Apple though.
20:40:35 <truebrain> ah, yeah, that is fair
20:40:50 <truebrain> I am rather happy you manage to get this to work on MacOS, I have to admit 🙂
20:41:25 <michi_cc[d]> Well, one thing definitely speaks for CoreText: the docs are a lot better than the almost non-existant docs for Uniscribe.
20:42:34 <andythenorth> macOS users appreciate it 🙂
20:43:05 <peter1138[d]> Don't you use the sprite font anyway? 😄
20:48:32 <truebrain> in other words: we should clean up the MacOS code 🙂 Fine, not for this PR 🙂
20:48:58 <michi_cc[d]> truebrain: Not exactly the cursor, but the whole IME key input on OSX works quite differently from how Windows does it.
20:49:18 <truebrain> yeah, just remember there was this code there too, only used by MacOS, for the layouter and crap
20:49:22 <peter1138[d]> Hmm, having to manually build the window layout just to change colour is a pain 😦
20:49:57 <michi_cc[d]> truebrain: Well, maybe the to-be-written Linux IME code would need it too 😛
20:50:10 <andythenorth> peter1138[d]: might change 😛
20:50:18 <andythenorth> much as I love the sprite font
20:50:37 <peter1138[d]> _zephyris: has done a fantastic job 😄
20:54:07 <_glx_> colour codes where removed, they are now replaced with question marks
20:55:41 <Rubidium> _glx_: easy to try, just set the second parameter of StrMakeValidInPlace
20:56:37 <truebrain> michi_cc[d]: I assume you tested it on all 3 OSes? Or does it need any specific validation on any OS first?
20:57:45 <truebrain> too bad this doesn't work on Emscripten, so Previews don't help 😛
20:58:08 <truebrain> in fact, that really really is a shame .. meh .. well, not for this PR 🙂
20:58:11 <michi_cc[d]> I did in fact tested Windows, OSX and Linux. Linux just on one distribution though (and not with whatever exact libs Steam build is done).
20:58:55 <truebrain> yeah, that shouldn't be an actual issue
20:59:27 <xarick> I made a smart function! I am so proud!
20:59:27 <xarick> * @returns Whether the water region contains aqueducts that cross the region boundaries.
20:59:27 <xarick> bool HasCrossRegionAqueducts() const
20:59:29 <xarick> return std::any_of(std::begin(this->traversability_bits), std::end(this->traversability_bits), [](TWaterRegionTraversabilityBits traversability_bits)
20:59:31 <xarick> return traversability_bits >> WATER_REGION_EDGE_LENGTH != 0;
20:59:35 <xarick> It only took me 3 hours to figure how to do it.
20:59:37 <truebrain> I am very tempted to just approve it .. the code looks good, although I don't understand most of it 😛
21:00:31 <truebrain> peter1138[d]: do you want to validate/check anything on #11593 first? (given you did things with fonts in the last few months too)
21:02:16 <truebrain> the nitpick of all nitpicks 😄
21:03:16 <truebrain> owh, in 2 places there is a `maybe_unused` I don't think should exist 🙂
21:03:29 <peter1138[d]> No, not really. I had a font selector but it felt really out of place and preview didn't work well. This mostly obsoletes that 🙂
21:03:59 <truebrain> except for languages like Chinese etc 😛
21:04:24 <peter1138[d]> That's a very busy Zephyrus 🙂
21:08:56 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:09:47 <truebrain> owh, euh, no, I guess one thing is missing
21:09:59 <truebrain> michi_cc[d]: you mentioned you updated it to version 0.3 of these fonts, but nowhere in our code we say what version it is
21:10:03 <truebrain> might be useful to have that somewhere?
21:10:11 <truebrain> so we know when to update and not 😄
21:10:47 <truebrain> maybe even include the link to Zephyris's GitHub
21:10:57 <michi_cc[d]> Probably. Any suggestion for a good place that will not be forgotten right away?
21:11:07 <truebrain> That is a big ask 😄
21:11:36 <truebrain> in `media/baseset` possibly?
21:11:52 <truebrain> `OpenTTD-fonts.md` in `docs`?
21:11:58 <truebrain> meh, that people will forget instantly
21:15:28 <xarick> how do I do a param [out], I still don't know
21:18:00 <_glx_> pointer or reference xarick
21:20:51 <xarick> _glx_: `static inline bool IsCrossRegionAqueductTile(TileIndex tile, TileIndex &other_end_tile = INVALID_TILE)
21:20:51 <xarick> if (IsBridgeTile(tile) && GetTunnelBridgeTransportType(tile) == TRANSPORT_WATER) {
21:20:51 <xarick> other_end_tile = GetOtherBridgeEnd(tile);
21:20:51 <xarick> return GetWaterRegionIndex(tile) != GetWaterRegionIndex(other_end_tile);
21:21:07 <xarick> it complains in INVALID_TILE
21:21:43 <_glx_> yes it wants a reference to a variable
21:22:26 <michi_cc[d]> More specifially, a `bool` + a return value is actually a `std::optional`.
21:23:59 <truebrain> hmm, how did you force SDL to Wayland again .. I always forget ...
21:24:16 <truebrain> `SDL_VIDEODRIVER=` ..
21:24:34 <xarick> std::optional? gonna check it out
21:26:30 <truebrain> ```dbg: [driver] SDL2: Mouse is at (0, 0), use display 0 (-1475174160, 32767, -1475174128, 32767)
21:26:30 <truebrain> dbg: [driver] SDL2: Mouse is at (0, 0), use display 1 (2560, 510, 2560, 1440)
21:26:30 <truebrain> dbg: [driver] SDL2: Mouse is at (0, 0), use display 2 (0, 510, 2560, 1440)```
21:26:40 <truebrain> wayland thinks I have a monitor in Canada
21:27:13 <truebrain> (the first display is left of my primary; I think WSL has a bug in those setups 😛 )
21:27:15 <peter1138[d]> Is that bit flags stuffed in there?
21:27:39 <_glx_> and OpenTTD defaults to display 0 for some stuff, but not for others
21:28:06 <peter1138[d]> And I have an nVidia GPU so no Wayland for me.
21:29:33 <xarick> why does it work in GetSlope for example
21:35:43 <xarick> `static inline bool IsCrossRegionAqueductTile(TileIndex tile, TileIndex *other_end_tile = nullptr)
21:35:43 <xarick> if (IsBridgeTile(tile) && GetTunnelBridgeTransportType(tile) == TRANSPORT_WATER) {
21:35:43 <xarick> *other_end_tile = GetOtherBridgeEnd(tile);
21:35:43 <xarick> return GetWaterRegionIndex(tile) != GetWaterRegionIndex(*other_end_tile);
21:35:47 <xarick> TileIndex other_end_tile;
21:35:49 <xarick> if (!IsCrossRegionAqueductTile(tile, &other_end_tile)) continue;`
21:38:43 <xarick> it shouldn't be null at that point anymore
21:38:51 <_zephyris> truebrain: Yeah, that'd be a challenge! I did look at Korean as it's alphabetic, but not (easily) possible in a 10px heeigh.
21:40:23 <_glx_> `*other_end_tile = GetOtherBridgeEnd(tile);` should be `if (other_end_tile != nullptr) *other_end_tile = GetOtherBridgeEnd(tile);`
21:41:04 <_zephyris> truebrain: It would be possible to get that set up... It'd require quite a lot of metadata about character widths, how to assemble composite sprites (eg. composing semicolon from period and comma, where to anchor accents, etc.), and the scripting to handle that. Not really worth the effort IMO
21:43:08 <truebrain> _zephyris: fair; but I dislike systems that are not reproduceable. They are bad! (just a purist point of view; nothing to worry about)
21:43:13 <truebrain> okay, #11353 is a rabbithole ++
21:43:24 <truebrain> 5 bugs in a single ticket; no wonder I couldn't figure it out on first read
21:43:45 <xarick> _glx_: it didn't work for some reason...
21:45:12 <_zephyris> truebrain: Totally understandable, and I'd have preferred a nice reproduceable too! Maybe one day...
21:45:16 <xarick> if (IsCrossRegionAqueductTile(tile)) {
21:45:27 <truebrain> _zephyris: nothing to worry about for now 🙂 It just surprised me 🙂
21:45:34 <_glx_> then it's nullptr and *nullptr is invalid
21:46:15 <truebrain> okay, Wayland on WSL is actually buggy when it comes to Display info 🙂
21:46:46 <peter1138[d]> I started work on a reproducible build but I needed to touch every single .svg. So a big job already 🙂
21:46:52 <truebrain> it really doesn't handle 90-degree rotated screens 😄
21:47:05 <peter1138[d]> Wayland is just buggy.
21:47:17 <truebrain> yeah ... but so is X11 😛
21:48:22 <_zephyris> peter1138[d]: The fontforge/sfd format is quite readable - I suspect it'd be possible to extract all of the necessary width/position info semi-automatically, then reverse that to make a build pipeline. If you feel like a challenge 😜
21:48:30 <truebrain> so what was the best way to remove duplicates from a vector?
21:48:37 <truebrain> (I actually need it 😛 )
21:49:00 <xarick> how do I do this to work the way I want 😐
21:49:20 <truebrain> `std::unique`, Internet tells me
21:49:24 <peter1138[d]> If sorting it is no problem, yes.
21:49:36 <truebrain> so it is excellent 🙂
21:49:51 <peter1138[d]> The one I was dealing with was not sorted, nor sortable 🙂
21:50:12 <locosage> how does nightly versioning work? it's `20240114-master-ga6873ef7dd` but there is no commit with ga6873ef7dd
21:50:48 <truebrain> Also pretty sure `g` is not part of hex-code 🙂
21:51:06 <truebrain> locosage: was how many years old when he figured out hex only goes till `f`? 😄
21:51:25 <truebrain> `g` stands for `git` 😛
21:51:38 <truebrain> gratz michi_cc[d] ; really nice work 🙂
21:52:24 <michi_cc[d]> Thank _zephyris , not me. Pretty sure making the font in the first place was a lot more work.
21:52:53 <truebrain> I think our users will have a lot of joy from this addition 🙂
21:54:00 <peter1138[d]> I'm sure we'll only hear complaints 😄
21:54:17 <michi_cc[d]> Now we only need fractional GUI icon scaling 😛
21:54:34 <peter1138[d]> I have a patch for that.
21:56:37 <andythenorth> fractional dock scaling?
21:56:53 <andythenorth> LC has proposed a Dock Variant Types Spec
21:57:13 <peter1138[d]> Doesn't it involve a setting to switch type of dock? Seemed strange.
21:57:30 <andythenorth> I read it on my phone, so I missed that bit 😛
21:57:44 <truebrain> I stopped reading after LC
21:58:02 <andythenorth> I made this wagon quite refittable
21:59:06 <peter1138[d]> andythenorth: definitely refittable.
21:59:30 <andythenorth> didn't do any subtypes
22:00:31 <_zephyris> michi_cc[d]: It was a fun challenge. I've dabbled in font making before, so nice to have a good application.
22:01:03 <xarick> I wanna try the new fonts!
22:01:33 <locosage> truebrain: ```$ SDL_VIDEODRIVER=wayland ./openttd -ddriver=2
22:01:33 <locosage> dbg: [driver] Successfully loaded blitter '32bpp-anim'
22:01:33 <locosage> dbg: [driver] Probing video driver 'sdl-opengl' skipped due to earlier crash
22:01:33 <locosage> dbg: [driver] Probing video driver 'sdl' failed with error: wayland not available
22:01:33 <locosage> Error: Couldn't find any suitable video driver
22:01:35 <peter1138[d]> Hmm, OpenTTD-Mono doesn't get selected.
22:01:38 <locosage> on both builds interestingly...
22:01:58 <peter1138[d]> Ah, it's the delayed font-cache issue.
22:03:38 <truebrain> our toggling of fullscreen is interesting, at best 😄
22:04:36 <xarick> _glx_: This did it! Finally works!
22:05:04 <xarick> I had to have a separate tile
22:05:43 <truebrain> okay .. so we need to figure out on what display the window currently is, to know the resolution for fullscreen to use ... great
22:05:46 <_glx_> WSL often renders unreadable windows for me
22:06:13 <locosage> lol, fullscreen fixed itself somehow for me xD
22:06:23 <locosage> it no longer bugs out even on nightly
22:07:36 <xarick> optical illusion, there's 2 aircraft in the airport
22:13:07 <truebrain> right .. those two combined should fix #11353 sufficiently
22:15:49 <truebrain> okay, the mouse position is not supported in wayland, but recent SDLs fake it sufficiently; I just don't run a recent SDL 😛
22:16:10 <truebrain> I am at 2.0.20, while upstream uses 2.28.5 😄
22:22:56 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:23:03 <_glx_> at least it will be better
22:23:15 <truebrain> `Wayland only provides applications with the cursor position within the borders of the application windows.`
22:24:32 <peter1138[d]> Wayland is full of weird decisions.
22:25:56 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:26:06 <truebrain> `default-features`: `wayland` .. hmm
22:28:45 <peter1138[d]> Something got lost in this rebase 🙂
22:32:19 <truebrain> owh, once again, let's install OpenTTD in a very old docker ..... 😛
22:32:30 <truebrain> like I haven't done that enough 😄
22:35:51 <truebrain> most of these issues wouldn't exist if we add borderless fullscreen .. but time .. TIME is such an issue 😛
22:36:11 <peter1138[d]> Hmm, 32bpp works slightly better, still cursor trails though.
22:36:45 <peter1138[d]> Think it's just using the power-of-two size.
22:37:57 <truebrain> ah, you too have a case of "who has the longest widget" 😄
22:38:15 <reldred> You have to swing it around to click on things
22:39:52 <peter1138[d]> "I can't aim it properly" "We know"
22:39:59 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:42:55 <peter1138[d]> Anyway this a nasty horrible hack, and only works with the two 'simple' blitters.
22:43:05 <peter1138[d]> So merge it already, yeah?
22:49:48 <truebrain> owh, that is horrible
22:50:26 <truebrain> grrr .. so I install wayland dependencies, as mentioned in the SDL documentation .. and still the resulting binary does not have wayland support 😛
22:52:20 <truebrain> `-- Requested 'wayland-client >= 1.18' but version of Wayland Client is 1.15.0`
22:53:43 <truebrain> so I think .... adding wayland support will be problematic 😄
22:54:40 <xarick> the font looks like it's doing waves of bold, not bold
22:56:06 <truebrain> hmm, and upgrading to a newer libc means Ubuntu 20.04 won't work anymore
22:56:09 <truebrain> which feels like a bad move
22:58:07 <reldred> Yeah still a lot of 20.04 out there
22:59:27 <truebrain> also still supported
22:59:38 <truebrain> so ... I need to find a way to get a newer wayland on this image 🙂
23:04:37 <peter1138[d]> Ah, toggling traditional sprite font doesn't quite work correctly 🙂
23:07:47 <truebrain> let's try compiling wayland via vcpkg ...
23:14:11 <xarick> `return WaterRegionDesc { GetWaterRegionX(tile), GetWaterRegionY(tile) };`
23:14:11 <xarick> `func(WaterRegionPatchDesc { (uint8_t)nx, (uint8_t)ny, unique_label });`
23:14:11 <xarick> question: what's the code-style for thesee brackets?
23:16:42 <truebrain> _glx_: "fun" fact, reinstall vcpkg packages with a `vcpkg.json` turns out to be ... difficult 😛
23:18:35 <_glx_> if it's in your working dir yes
23:20:56 <truebrain> just easier to remove the vcpkg.json when testing; ironic 😄
23:25:31 <truebrain> hmm, the vcpkg `egl` isn't sufficient for SDL to detect `egl`, which is needed to support wayland
23:25:44 <truebrain> the system `egl` drags in `wayland` ..
23:25:51 <truebrain> chicken .. egg ... anyone?
23:33:52 <truebrain> `-- SDL_WAYLAND (Wanted: ON): ON`
23:33:54 <truebrain> getting somewhere ...
23:34:27 <truebrain> it just requires changing `vcpkg.json` in a way that wouldn't work for anyone else 😛
23:35:17 <truebrain> but even then, it says that wayland is not available ...
23:36:50 <truebrain> paint me yellow and call me a banana
23:38:28 <_glx_> anyway our `vcpkg.json` is very specific to the CI
23:39:05 <_glx_> I think most linux users building themselves don't even use vcpkg
23:40:12 <truebrain> it is not CI specific at all
23:40:24 <truebrain> it correctly lists all dependencies on Linux
23:40:42 <truebrain> the CI might be the only user; that might be true. But anyone on Linux could use it 🙂
23:40:44 <_glx_> yeah and we disable it unless it's a release 😉
23:40:56 <truebrain> for the CI, yes, as we don't want to depend on vcpkg for Linux 🙂
23:41:02 <truebrain> but there is a difference 🙂
23:41:28 <truebrain> anyway, this is odd ... SDL says: WAYLAND support enabled
23:41:33 <truebrain> our binary says: nah bro
23:44:46 <truebrain> alternatively, we make 2 generic linux binaries ... version #old (2014 and older) and version #new (2020 and older)
23:45:23 <truebrain> euh, "and older" -> "and newer" 😄
23:45:45 <truebrain> as I do not think I am going to get this to work
23:46:06 <_glx_> and distribute #new in steam
23:46:33 <truebrain> would need to check what Steam has as lower glibc
23:47:04 <truebrain> we currently compile against 2.17
23:47:49 <truebrain> the next step up is 2.28
23:48:35 <truebrain> I know they have a runtime that has 2.17 (or even 2.14?)
23:48:41 <truebrain> but no clue how used that is
23:49:22 <truebrain> yeah, but it is the 28% that is interesting 🙂
23:52:05 <truebrain> lol, still amazes me we need `perl-IPC-Cmd` 😄
23:52:49 <truebrain> libc 2.28 is from 2018
23:52:58 <truebrain> (and Ubuntu 20.04 doesn't have it, from what I read ... ironic)
23:53:27 <truebrain> we would go from a libc from 2012 to one from 2018 .. 6 years 😛
23:54:14 <peter1138[d]> Approved before I added the screenshot 😄
23:56:11 <truebrain> okay, the screenshot is funny 😄
23:56:16 <truebrain> glad you mention it 😛
23:56:30 <truebrain> ```./../src/c-74_1-src-8ca76704fa.clean/source/configure: line 4620: syntax error near unexpected token `0.20'
23:56:30 <truebrain> ./../src/c-74_1-src-8ca76704fa.clean/source/configure: line 4620: `PKG_PROG_PKG_CONFIG(0.20)'```
23:56:34 <truebrain> I have seen that error before ...
continue to next day ⏵
