Times are UTC Toggle Colours
00:11:18 <DorpsGek> [OpenTTD/OpenTTD] maaaaaaaaaad commented on issue #10681: [Crash]: Segmentation fault https://github.com/OpenTTD/OpenTTD/issues/10681 02:35:51 *** D-HUND has joined #openttd 02:39:11 *** debdog has quit IRC 03:11:29 *** D-HUND is now known as debdog 03:44:19 *** keikoz has joined #openttd 04:26:51 *** keikoz has quit IRC 04:38:23 *** keikoz has joined #openttd 06:05:05 *** nielsm has joined #openttd 06:59:30 <jfs-> the only reason I'm going by bus is because I'd rather spend 17 hours in a night bus than get up and to CPH airport at 5 am 07:00:08 <jfs-> anyway, one week to go! 07:00:51 *** HerzogDeXtEr has joined #openttd 07:37:44 <TrueBrain> well, I already have issues with the price of S3 + egress on AWS, and the reason we have 2 VPSes doing caching for us ... turns out, NixOS outdid us there ... 9000 dollar a month on S3 costs. Lol. They have about 10 times more bandwidth than we do, but I am happy we went for the VPS solution 🙂 07:38:00 <TrueBrain> hopefully soon Cloudflare R2 as solution .. but I am kinda hoping they want to sponsor us before I delve into that 😛 07:38:59 <petern> A plague, huh? 07:39:03 <dwfreed> Linode would probably sponsor 07:41:18 <TrueBrain> why do our header files in core end with `hpp` and most others with `h` .. I keep doing that wrong 😛 07:41:41 <LordAro> because templates, for the most part 07:41:47 <LordAro> and hysterical raisins 07:41:51 <petern> Nobody knows. 07:42:16 <dwfreed> the other C++ project I look through the codebase of is all .cc and .hh for c++ 07:42:54 <TrueBrain> lol, I was wondering why 16751108096 divided by 1024 was 3775592 07:43:00 <TrueBrain> but `CeilDiv` uses `uint` 😛 07:45:11 <TrueBrain> hmm, and templating it is a bad idea, as many uses have things like `uint16` .. so that would change their outcome too .. hmm 07:45:31 <TrueBrain> guess I could make it an explicit template, but that takes up a lot more letters .. CeilDiv64? 07:46:09 <TrueBrain> or just making it 64bit for everyone .. 07:47:09 <dwfreed> which would change the outcome of things expecting uint, but that's probably a bug anyway 07:53:19 <LordAro> TrueBrain: oof 07:56:48 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10910: Fix: track "memory installed" for surveys less precise https://github.com/OpenTTD/OpenTTD/pull/10910 07:57:09 <TrueBrain> who would have thought, that you can track a user based on their "memory installed" 😛 07:59:12 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10910: Fix: track "memory installed" for surveys less precise https://github.com/OpenTTD/OpenTTD/pull/10910#issuecomment-1574762367 07:59:56 <TrueBrain> if you say so! 😛 08:00:12 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910#issuecomment-1574763209 08:01:01 <petern> What about that pi 1 with only 512MiB 08:01:12 <TrueBrain> yeah, initially I wanted to do it per 0.5 GB 08:01:17 <TrueBrain> but then I was like ... do we actually care? 08:01:32 <TrueBrain> but it is a good point 08:02:27 <petern> Let's bring back the DOS port and run on a 4MB 486. 08:08:08 *** Wolf01 has joined #openttd 08:08:51 <TrueBrain> there, better? 🙂 08:08:53 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910 08:09:04 <TrueBrain> down to 4 MiB of RAM can be represented now 🙂 08:11:44 *** Flygon has joined #openttd 08:11:46 <TrueBrain> and yes, it means someone with 768MB or RAM becomes 1GB .. but really, that is okay 😛 08:12:31 <TrueBrain> hmm, I only now realise that dedicated servers will never enable this .. as they don't get to see this window 😄 08:13:37 <TrueBrain> hopefully their clients playing do, so it will be fine 🙂 08:23:01 <petern> Console prompt 🙂 08:38:18 <Brickblock1> https://cdn.discordapp.com/attachments/1008473233844097104/1114473119751606332/image.png 08:38:18 <Brickblock1> weird bug I found 08:45:34 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910 09:06:27 <TrueBrain> https://cdn.discordapp.com/attachments/1008473233844097104/1114480201053765642/image.png 09:06:27 <TrueBrain> The nesting becomes a bit much 😛 09:06:57 <petern> A plague 09:07:09 <TrueBrain> what is it with you and plagues today? Do you want to tell us something? 🙂 09:52:01 <andythenorth> he has the plague? 😮 09:55:21 <TrueBrain> I was more thinking he has it for sale, but okay 09:56:09 <TrueBrain> hmm .. I was copying a GitHub workflow from the Docker manual ... but it is clearly broken .. in multiple ways ... that is a bit annoying 😛 10:05:10 <petern> Actually yes, I do. 10:05:15 <petern> But also, it's in that thread... 10:05:34 <TrueBrain> ah 10:05:38 <TrueBrain> shows how much I read that 😄 10:22:41 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10904: Fix: Re-opening GRF/script settings windows not closing drop down windows https://github.com/OpenTTD/OpenTTD/pull/10904#issuecomment-1574842764 10:26:34 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10911: Fix: GRF Parameters not displayed due to scope issue. https://github.com/OpenTTD/OpenTTD/pull/10911 10:27:02 <TrueBrain> oops? 🙂 10:27:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10911: Fix: GRF Parameters not displayed due to scope issue. https://github.com/OpenTTD/OpenTTD/pull/10911#pullrequestreview-1459180823 10:27:56 <petern> It was wrong all along, but the switch to std::string made it visible broken. 10:29:15 <TrueBrain> lol, and regarding that thread .. I see I once again made the naughty list 🙂 It is someone different every release, so I guess I win this one? 😛 10:31:15 <TrueBrain> glx[d]: https://github.com/TrueBrain/sandbox/blob/main/.github/workflows/testing.yml <- I can make the workflow this small for all our Python services 😄 10:31:22 <TrueBrain> now to do the same for the releases 🙂 10:36:35 <glx[d]> Nice, and no longer referencing any action that may need bumping 10:36:49 <glx[d]> I like the move 10:37:07 <TrueBrain> all in a single place .. so we can also kill all flows with a single commit 10:37:09 <TrueBrain> but that is not the point 😛 10:46:44 <TrueBrain> oops, almost forgot lunch 😦 10:47:05 <petern> Never forget lunch. 10:47:37 <TrueBrain> a typical of: one more thing, that should make it work 11:08:04 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10911: Fix: GRF Parameters not displayed due to scope issue. https://github.com/OpenTTD/OpenTTD/pull/10911 11:15:44 <TrueBrain> right, what was I doing? 11:15:47 <TrueBrain> besides ruining the game, ofc 11:16:03 <TrueBrain> ah, yes, I somehow didn't have permissions to publish the container .. let's see .. 12:19:15 <TrueBrain> meh, too bad you can't do a rev-count on a shallow clone of a git repo 😛 12:19:24 <TrueBrain> it takes so long to fetch all history of a repo 😦 12:21:33 <TrueBrain> I guess in theory I could use the GitHub API for that .. but that is also tricky .. 12:30:18 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10899: Codechange: replace strecpy with string concatenation https://github.com/OpenTTD/OpenTTD/pull/10899#pullrequestreview-1459295113 12:32:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10898: Codechange: use C++ idioms for the clipboard handling https://github.com/OpenTTD/OpenTTD/pull/10898#pullrequestreview-1459295625 12:33:54 <TrueBrain> petern: anything we can do to help #10884 along? 12:34:01 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10912: Fix: Ensure dropdowns are closed when closing focus or parent is closed. https://github.com/OpenTTD/OpenTTD/pull/10912 12:34:23 <petern> Mainly I need to get well again. 12:34:37 <petern> (I do actually have covid right now :/) 12:34:52 <TrueBrain> oof ..... hopefully as just a cold 😦 12:34:57 <petern> Got it from cycling outdoors in the cycling group of all things... ffs. 12:35:31 <LordAro> petern: oh no 12:36:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10912: Fix: Ensure dropdowns are closed when closing focus or parent is closed. https://github.com/OpenTTD/OpenTTD/pull/10912#pullrequestreview-1459299690 12:36:11 <petern> When the guy in front you complains about hayfever... uh oh 12:36:25 <TrueBrain> it wasn't hayfever after all! 😛 12:37:17 <TrueBrain> LordAro: mind taking another look at #10871 and closing the answers to the questions if you agree? 🙂 12:37:37 <TrueBrain> owh, was yesterday, lol, sorry .. I just saw: last week on the PR opening 😄 12:38:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10810: Codechange: rewrite string formatting to C++ https://github.com/OpenTTD/OpenTTD/pull/10810#issuecomment-1574916783 12:39:56 <TrueBrain> tempted to close a lot of old PRs that either are not going to be finished or are seemingly abadonded by the author .. but I guess that will result in QQ or the awakening of mister S 😄 12:40:35 <petern> Some of mine look abandoned but aren't. 12:40:45 <TrueBrain> I can differentiate between those 😛 12:40:59 <Eddi|zuHause> you mean "rejected" PRs? :p 12:41:53 <TrueBrain> but we have things like "upload date in network content window" or "zstd" or "directX support", etc etc 12:42:02 <TrueBrain> just a long list of random PRs that haven't been touched in 2 years 🙂 12:42:21 <TrueBrain> or remember the capitalization debacle? 😄 12:43:27 <petern> Upload date would be nice 😉 12:43:38 <petern> Oh no, not more things to pick up :/ 12:44:01 <TrueBrain> lot of things are "nice" 😛 But the list is getting long 🙂 12:44:10 <JGR> Upload date is likely to lead to useless bumping of content in bananas 12:44:28 <TrueBrain> hehe, very true 🙂 12:44:55 <TrueBrain> Well, with survey, we are close to a more proper solution to give popularity score to GRFs; that might also solve the itch people have there 🙂 12:45:53 <TrueBrain> https://github.com/OpenTTD/OpenTTD/pull/10804 <- that looks like a rather proper solution for the problem. Does anyone have (strong) opinions against? Mostly looking at you LordAro, and maybe JGR has something similar in JGRPP (solved or not)? 12:46:44 <JGR> I've never really found this issue to be a big problem, I haven't done anything about it 12:46:47 <petern> The dynamic penalty feels odd. 12:47:27 <LordAro> ^ 12:47:39 <JGR> It's the sort of thing which really needs play-testing as there are likely to be second-order effects 12:48:07 <TrueBrain> so it will sit on our backlog till the end of time 😛 12:48:40 <petern> Hmm, what are the units of wait_counter... 12:48:53 <TrueBrain> I hope "ticks", but .. yeah, who knows 🙂 12:50:23 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10807: Change: [YAPF] Penalty for crossing a reserved segment is now constant https://github.com/OpenTTD/OpenTTD/pull/10807#issuecomment-1574926355 12:50:51 <petern> if (++v->wait_counter < 37) { 12:50:55 <petern> That's a nice magic number 😉 12:51:38 <TrueBrain> We could really use a voting system of sorts, to know a bit how other developers / players think about things 😄 12:53:46 <petern> Yeah so it's ticks of a sort. Okay, so directly use ticks (-37) as a penalty? Arbitrary units but then again it all kinda is arbitrary... 12:54:30 <TrueBrain> personally I like the simplicity of the solution; but JGR is right, that it needs playtesting to validate there are no other .. consequences 😛 12:54:33 <petern> I wonder what happens when 5 trains have been stuck waiting for 2 years do... 🙂 12:54:38 <dP> 10804 looks like a workaround rather than a solution, it might work ok. But the problem itself seems kinda niche and it's hard to tell with a glance whether it breakes something more important. One way to go about it may be merging it with a setting and then slowly moving it default off-> default on->remove setting. Once again some mechanism for setting deprecation can be useful for that. 12:55:43 <petern> It also means every train has to wait for x ticks before it considers a different route. 12:55:57 <Eddi|zuHause> i don't really like the wait time... it may hide underlying problems, leading to crazy inefficiency 12:56:23 <Eddi|zuHause> because the situation will repeat, and the wait time will be high every time 12:56:28 <petern> I've an idea. 12:56:39 <petern> Put all these comments in the PR so the OP can respond 😉 12:56:49 <Eddi|zuHause> rather the occupation penalty itself should be dynamic 12:57:15 <Eddi|zuHause> so it has some persistence 12:58:37 <TrueBrain> petern: What a novel idea! 😄 12:59:14 <TrueBrain> guess we really should do a livestream again, where we just go: this PR, vote, yea or nah 12:59:18 <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on pull request #10804: Fix #10467: [YAPF] Trains do not use all available tracks https://github.com/OpenTTD/OpenTTD/pull/10804#issuecomment-1574931534 13:03:50 <TrueBrain> take #10543 .. also a PR that just needs a bunch of testing ... 13:04:12 <TrueBrain> TallTyler: maybe a PR to use for the next multiplayer event on this Discord? 😄 13:04:54 <TrueBrain> Brickblock1: btw, if this is an actual bug in OpenTTD (I can never tell from the sillyness we post in this channel), please do make a bug report and how to reproduce it on GitHub 🙂 Tnx! 13:16:52 <TallTyler> TrueBrain: Yes, I like that idea. We’d need to provide an executable for people who don’t have a compile environment set up, and I also need to remember. I don’t get back home until June 24! 13:17:09 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10912: Fix: Ensure dropdowns are closed when closing focus or parent is closed. https://github.com/OpenTTD/OpenTTD/pull/10912 13:17:11 <TrueBrain> Previews build binaries 🙂 13:17:23 <TrueBrain> no, they don't 13:17:27 <TrueBrain> we can release binaries of a PR 13:17:41 <TrueBrain> Don't actually know why those aren't connected ... but okay 🙂 13:17:50 <TrueBrain> https://www.openttd.org/downloads/openttd-branches/pr10719/latest as example 13:17:53 <TrueBrain> so providing binaries is simple 🙂 13:17:57 <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on pull request #10804: Fix #10467: [YAPF] Trains do not use all available tracks https://github.com/OpenTTD/OpenTTD/pull/10804#issuecomment-1574941697 13:20:24 <TrueBrain> michi_cc[d]: I love the new command system; so much easier to add a parameter 😄 13:26:40 <michi_cc[d]> You seem to be the only one 🙃 13:27:06 <TrueBrain> now I have this Tayler Swift song in my head 13:27:24 <michi_cc[d]> But then again destroying things is all we do anyway 😛 13:28:01 <TrueBrain> funny, I did not know when a company went bankrupt, the money you have to pay for it freezes from the time of offering 13:28:11 <TrueBrain> even if the company all of a sudden does so much better .. it doesn't matter! 13:33:05 <TallTyler> I also quite like the new command system, for what it’s worth 🙂 13:33:20 <TallTyler> So much easier to understand and use 13:34:50 *** gelignite has joined #openttd 13:40:10 <dP> go try to understand how it works 😜 13:40:10 *** gelignite has quit IRC 13:42:09 *** gelignite has joined #openttd 13:42:12 <dP> citymania command system is as easy to use but also on top of that supports building previews, copy-paste and packet analysis 13:42:18 <dP> code is utter shit though because templates 13:42:44 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #10913: Add: GSAsyncMode(bool) class to set asynchronous mode of game script commands https://github.com/OpenTTD/OpenTTD/pull/10913 13:43:13 <dP> oh, yeah, and it supports instant command execution as well xD 13:43:37 <petern> TallTyler: Same. It's just one person who complains about it... 13:43:51 <TrueBrain> JGR: cool, you backported it 😄 13:44:15 <JGR> It's not a very big change really 13:44:39 <TrueBrain> didn't you also increase the queue length? 13:45:04 <JGR> Yes, I thought that that would lead to bike-shedding problems so I didn't include it in the PR 13:45:33 <TrueBrain> meh; I completely understood why you increased it 😄 13:46:01 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10904: Fix: Re-opening GRF/script settings windows not closing drop down windows https://github.com/OpenTTD/OpenTTD/pull/10904#issuecomment-1574960038 13:46:04 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed pull request #10904: Fix: Re-opening GRF/script settings windows not closing drop down windows https://github.com/OpenTTD/OpenTTD/pull/10904 13:46:21 <TrueBrain> not even sure why the current limit exists .. 😛 13:46:38 <petern> Rejected PR 😮 13:46:54 <TrueBrain> be careful, you will be next petern ! 😛 13:47:22 <JGR> I'm sure that all our names are already on naughty lists somewhere 😛 13:47:39 <TrueBrain> I am a bit surprised how simple your PR actually is 😛 13:47:44 <TrueBrain> it stays in the script-realm 13:50:10 <glx[d]> TallTyler: that's really easy to do 🙂 13:50:20 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10913: Add: GSAsyncMode(bool) class to set asynchronous mode of game script commands https://github.com/OpenTTD/OpenTTD/pull/10913#pullrequestreview-1459426216 13:51:21 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10913: Add: GSAsyncMode(bool) class to set asynchronous mode of game script commands https://github.com/OpenTTD/OpenTTD/pull/10913#issuecomment-1574962178 13:51:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10913: Add: GSAsyncMode(bool) class to set asynchronous mode of game script commands https://github.com/OpenTTD/OpenTTD/pull/10913#issuecomment-1574962188 13:51:40 <TrueBrain> petern: that would kill all current GSes 🙂 13:52:01 <petern> Would it though? 13:52:28 <JGR> Anything where the result of a command was piped to the next command would br broken 13:52:34 <JGR> e.g. storybook type of thign 13:52:45 <TrueBrain> build-vehicle & add-order will fail 13:52:57 <TrueBrain> owh, yeah, what JGR says 😛 13:53:10 <petern> GS build vehicles? Hmm 13:53:31 <TrueBrain> you get the point 🙂 Items don't actually exist yet, but you continue on as if they do 13:53:41 <petern> I supposed you can't test if the result is used or not 13:53:44 <TrueBrain> so the GS author needs to be aware 🙂 13:54:06 <TrueBrain> no; for that I originally designed features; so you can still get the actual result when you request it 13:54:09 <TrueBrain> but that is far more code 🙂 13:54:16 <TrueBrain> features? futures .. what-ever 13:54:46 <TrueBrain> JGR: what actually happens when the frame is full with commands, and you async execute the next? Does testing fail? 13:55:47 <JGR> Testing works the same whether the frame queue is full or not 13:55:59 <TrueBrain> so it silently fails? 13:56:10 <JGR> If the command can't be sent on the current frame it will be sent on a later one 13:56:18 <TrueBrain> ah, okay 🙂 13:56:51 <petern> Does it suspend the GS? 13:57:14 <petern> Not sure if it should or not 13:57:38 <petern> Such interrogation 13:58:00 <JGR> It's only necessary to suspend the GS to wait for the result 13:58:54 <glx[d]> async mode is basically fire and forget 13:59:06 <JGR> If _local_wait_queue has a backlog then when the script issues a non-async command it might have to wait a little longer 13:59:28 <TrueBrain> exactly what I would expect to happen; not sure what that is worth anymore, but 😛 13:59:34 <TrueBrain> (okay, enough QQ for one day :D) 13:59:54 <Brickblock1> Is it possible to sort the object build window? 14:00:05 <glx[d]> probably 14:00:30 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on pull request #10913: Add: GSAsyncMode(bool) class to set asynchronous mode of game script commands https://github.com/OpenTTD/OpenTTD/pull/10913#issuecomment-1574968508 14:00:39 <Brickblock1> it seams completely random to me but I might be doing something wrong 14:01:31 <TrueBrain> funny, if you give a company some money before it goes bankrupt, you have to pay the money you gave extra to the company 😄 14:01:44 <petern> It's by definition order 14:04:21 <Brickblock1> ok it seams that nml has a weird one of those for id above 255 14:04:31 <Brickblock1> they end up before the other ones 14:07:25 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10913: Add: GSAsyncMode(bool) class to set asynchronous mode of game script commands https://github.com/OpenTTD/OpenTTD/pull/10913#issuecomment-1574970408 14:08:55 <petern> I have a reworked station UI selector which I would also copying over to objects, but not happy with it yet. 14:09:23 <petern> It's searchable though 14:10:56 <glx[d]> nml should output them in the same order as the item blocks are declared 14:16:01 <petern> They are mapped to classes in local index order though. 14:16:22 <petern> So order within each file doesn't matter. 14:16:27 *** Johngi has joined #openttd 14:17:12 <Johngi> 'ello 14:17:18 *** Johngi[d] has joined #openttd 14:17:18 <Johngi[d]> it works! 14:17:53 <TrueBrain> someone is in need of an alter-ego .. wait, they found it! 14:17:54 <TrueBrain> 😛 14:18:00 <petern> Something works, great. 14:18:09 <Eddi|zuHause> TrueBrain: i don't think a share system is ever compatible with just giving money around. you'd have all kinds of economic investigations running against you 14:18:38 <Johngi> I decided to try adding a certificate to my client, which was a little hard since I'm on windows 14:18:51 <Johngi> I still need to figure out how to properly protect the certificate file 14:19:06 <Johngi> but I'm sure that's a problem I can deal with after I get myself some lunch 14:20:12 <dP> Johngi[d]: what are you doing that you need a certificate o_O 14:20:34 <Johngi> nothing illegal, I swear 14:20:39 <dP> xD 14:20:59 <dP> I'm just curious if there is another patchpack or smth I'm not aware of x 14:21:23 <Johngi> and today I learned to never underestimate just how useful chmod is, there's no easy windows equivalent 14:22:00 *** Johngi has left #openttd 14:22:37 <Johngi[d]> I should probably also add a bouncer at some point 14:22:48 <Johngi[d]> but like the discord exists so I don't really care 14:23:16 <Johngi[d]> you'd think that I'd add one of those before I ever bother touching certificates... 14:23:19 <glx[d]> discord is the bouncer 🙂 14:23:24 <Johngi[d]> precisely 14:23:40 <petern> Discord has its flaws though :/ 14:23:55 <Johngi[d]> this is true 14:24:01 <dP> irc flawless 🤣 14:24:04 <JGR> Discord is still vastly more usable than IRC 14:24:08 <JGR> Especially on mobile 14:24:20 <glx[d]> signing executable is not hard (we do it for every releases, including nightlies) 14:24:40 <JGR> I used to mess about with bouncers etc. but I really can't be bothered any more 14:25:05 <Johngi[d]> it wasn't really that hard, probably one of the easier things I've done this week 14:25:13 <petern> Discord just proves you only ever needed web-irc... 14:25:23 <Johngi[d]> of course the problem with touching things like these is that you always get anxious that you're going to do a big cryptography no no 14:26:10 <petern> What, like inventing your own? 14:26:48 <Johngi[d]> no no I meant what I was doing with a certificate earlier 14:27:01 <Johngi[d]> baseless fear, as long as you read the instructions 14:27:44 <TrueBrain> hmm .. company dropdown from main menu doesn't update when a company is added .. where is that code .... 14:27:52 <Johngi[d]> the biggest problem with discord (or perhaps the greatest thing about it, depending on who you are) is that you *can't* join with a bouncer or other bot 14:28:05 <Johngi[d]> you have to be a server owner or admin to invite one in 14:28:34 <TrueBrain> owh, that bug isn't easy to solve ... eeeuuuhhhhhh 14:28:37 <petern> Dropdown would need to be closed and reopened. Hmm. 14:28:42 <TrueBrain> nevermind! 😄 14:29:20 <petern> Or add support for hiding options, then just hide nonexistant companies. 14:33:28 <petern> I guess it is just a vector now so adding the ability to add/remove options shouldn't be too hard. 14:33:40 <TrueBrain> famous last words! 😄 14:33:45 <petern> 😄 14:38:01 <TrueBrain> there is this whole blob of code in the Company GUI to calculate the width of the buttons .. but it doesn't actually work 😛 14:38:12 <TrueBrain> some buttons are still weirdly shaped 14:41:14 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910#pullrequestreview-1459533080 14:41:49 <petern> Company GUI... company GUI... 14:41:50 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910#pullrequestreview-1459533851 14:41:54 <petern> Which one? 14:42:16 <TrueBrain> hmm, it now only happens with my new button, so that is something .. it was doing it for other buttons to, but that magically got solved 😄 14:44:56 <petern> There's some windows left which I haven't scaled properly yet 😉 14:45:24 <TrueBrain> owh, there is no scaling factor in these buttons yet 14:45:29 <TrueBrain> so by adding a new bigger button 14:45:31 <TrueBrain> I fixed the rest 😄 14:45:39 <petern> Maybe I'll get undistracted and finish that off. 14:45:43 <petern> Yeah but what buttons? 14:45:53 <TrueBrain> the view HQ, Give Money, Join buttons 14:46:09 <petern> Ah, those are automatically scaled by the text inside. 14:46:55 <TrueBrain> yup 14:46:58 <TrueBrain> to make all buttons the same 14:48:13 <TrueBrain> I guess it is missing those hsep thingies 14:48:18 <TrueBrain> but that alone didn't fix it 14:49:44 <petern> I don't really know what you are expecting with the layout. 14:50:42 <petern> There's a 4,2,4, that 2 should be a HSEP_NORMAL, probably. but those values are all scaled by interface scale so it's not hugely critical, just inconsistent. 14:50:59 <TrueBrain> let me rebuild master and send a screen 🙂 14:51:32 <petern> Anything in SetPadding, SetPIP, etc, is automatically scaled. 14:52:14 <petern> Probably a case of you're expecting a certain layout and I'm thinking "but it's designed to be the way it is" 🙂 14:52:45 <TrueBrain> no, it is bugged 😛 14:52:48 <petern> Never! 14:52:51 <TrueBrain> https://cdn.discordapp.com/attachments/1008473233844097104/1114567382107705435/image.png 14:52:58 <TrueBrain> the idea of the code is that those buttons are of equal size 14:53:00 <TrueBrain> they are not 🙂 14:53:03 <Eddi|zuHause> one person's bug is another person's feature 14:53:39 <TrueBrain> and now I added an even bigger button, it got even more broken 😛 14:54:30 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 14:54:46 <petern> Ah I see. 14:55:28 <petern> That's a bug in that window's UpdateWidgetSize 14:55:39 <TrueBrain> that is as far as I got 😄 14:55:49 <TrueBrain> but how to actually fix it .... 😄 14:55:51 <petern> *size already has padding, but GetStringBoundingbox doesn't include it. 14:56:44 <petern> Let me find an example that gets around it. 14:56:45 <TrueBrain> `size->width += padding.width;` alone doesn't fix it 😛 14:56:59 <petern> Nope, because the default size already includes padding. 14:57:19 <petern> The default size is going to be one of those strings + padding for each of the widgets. 14:57:34 <TrueBrain> efficiently what I did is the same 😛 14:57:42 <TrueBrain> but they are still too small 14:57:52 <TrueBrain> https://cdn.discordapp.com/attachments/1008473233844097104/1114568640394690660/image.png 14:58:13 <glx[d]> not using some kind of max(bounding_boxes) ? 14:58:25 <TrueBrain> efficiently? Effectively .. what-ever .. english .. hard 14:59:03 <TrueBrain> this "size = GetStringBoundingBox" is done in more places btw 14:59:30 <petern> Probably the easiest way is to set size->width = 0; first 14:59:43 <petern> Then add size->width += padding.width; after. 14:59:45 <TrueBrain> how is that helping as they are too small? 🙂 14:59:55 <petern> Trust me 🙂 15:00:16 <petern> The default size for the "Hostile takeover" button is the string width + padding width. 15:00:42 <TrueBrain> ah, like that 😄 15:00:43 <petern> Because it's only updating the width if it's larger every time, it's still the default size for that button. 15:00:47 <TrueBrain> and the padding is just silly small 15:00:50 <petern> And then you add the padding again. 15:00:57 <petern> It's the default padding for text buttons. 15:01:35 <TrueBrain> so what do we prefer ... = 0 and += padding, or + padding on each line? 15:02:17 <petern> Well you can change the first like so that it just takes the first string width instead of taking the max. 15:02:20 <petern> *first line 15:02:34 <TrueBrain> yeah, but we ahve many more instances of this 😄 15:03:25 <glx[d]> buttons are not in a container (and auto expand in it) ? 15:03:28 <petern> My prefered method is different, so... we'll see 🙂 15:04:02 <petern> No, the buttons are kinda unrelated, they are just sized the same to fit nicely. 15:04:42 <petern> The equalsize stuff only works when all the buttons are displayed together in one horizontal row. 15:05:49 <petern> At least padding.width is right now. Previously each window needed to know which padding to apply as well... 15:06:38 <petern> So it is almost possible to increase the horizontal padding for text buttons uniformly, but of course that would be a plague destroying the game. 15:07:38 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#pullrequestreview-1459589041 15:08:46 <glx[d]> I would think if buttons are in a vertical container they should use the width of the larger one 15:09:11 <glx[d]> as it determine the width of the container itself 15:10:05 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10915: Fix: when syncing width of GUI items, take padding into account https://github.com/OpenTTD/OpenTTD/pull/10915 15:10:10 <TrueBrain> just see if you agree with that approach 😛 15:11:20 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575012743 15:12:03 <petern> "all places" -> 5 files, seems unlikely 😉 15:12:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575013346 15:12:22 <TrueBrain> "similar pattern" 😛 15:12:33 <TrueBrain> so `size->width, GetStringBoundingBox` 🙂 15:12:57 <petern> Yes, that way works works, avoids adding double padding. 15:14:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 15:14:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#pullrequestreview-1459602251 15:14:24 <petern> And alternative would require a bit of a rewrite -- keep padding separate and add it after in the window code. TBH I probably should've done that originally. 15:14:37 <TrueBrain> many places already add padding manually now 🙂 15:15:02 <TrueBrain> but, to not get lost in another "oeh, pretty", I am going to leave it at this; and I am fine if we close the PR instead of this approach 😄 15:15:32 <petern> Nah, it's correct for now IMHO 🙂 15:16:40 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 15:17:13 <TrueBrain> well, that was fun 🙂 15:19:06 <TrueBrain> the amount of money you have to pay for the hostile takeover is hilarious 😄 15:19:15 <TrueBrain> much more in line with what I would expect from a decent share system 😛 15:21:07 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10915: Fix: when syncing width of GUI items, take padding into account https://github.com/OpenTTD/OpenTTD/pull/10915#issuecomment-1575016983 15:21:47 <petern> Is it not similar to the amount you'd pay in shares? 15:21:50 <TrueBrain> yeah, I did not validate any of the entries 😛 If you want me to, I will; I just grepped 😄 15:22:01 <TrueBrain> petern: no; that value was really weird 15:22:13 <TrueBrain> but I also added 2 years of profit 15:22:15 <TrueBrain> shares didn't do that 😄 15:22:30 <petern> Totally game breaking mate 15:22:35 <TrueBrain> I know right! 15:22:36 <petern> PLAGUE 15:23:28 <glx[d]> at least it makes use of the huge amount of data stored 🙂 15:23:43 <petern> Adding padding even if it's zero is probably correct, means the window doesn't need to know or care. 15:23:45 <TrueBrain> only the first 4 entries 😛 15:25:09 <petern> Does this feature need to wait a few weeks for player approval? 15:25:26 <petern> Maybe open a whole thread on the forums with a poll or something. 15:25:42 <petern> . /s 15:25:48 <TrueBrain> 😄 15:26:32 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910 15:26:41 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910#pullrequestreview-1459623718 15:27:57 <petern> Oh dear, one little comment and you made the patch huge :p 15:28:15 <TrueBrain> yeah, but the code was just silly ... 15:28:31 <TrueBrain> it is bad of the parent to assume things about the child like this .. asking for trouble 15:28:50 <petern> I didn't say that even if I did consider it slightly lazy to put data into json, to then take it out and replace it later 😉 15:29:11 <TrueBrain> well, I agree with you, even if you didn't say it! 😄 15:29:25 <petern> Of course now I have to be very careful about any such code I write. 15:29:45 <petern> But, uh, that's good I suppose. 15:29:55 <TrueBrain> nah; but leave me alone with my PRs long enough, and they keep on morphing like this 😛 15:30:11 <petern> Rewrite. Rewrite. Rewrite. 15:30:15 <TrueBrain> yup 15:30:25 <petern> Self-rejected PRs. 15:31:02 <TrueBrain> a few years ago I worked with gerrit, which showed every patchset you made (basically, every push you do to a PR) .. I got over 100 ... my colleages were a bit annoyed 15:31:10 <TrueBrain> but I can fiddle with code for a long long time if I want to .. 😄 15:31:30 <petern> Hmm, the problem with this hostile takeover PR is that nobody requested it. 15:31:33 <glx[d]> usually I start with the overly complex solution 15:32:16 <TrueBrain> petern: sorry, I will get you a request in writing, signed, processed, meditated about, signed again, and validated in the next 10 businessdays 😛 15:32:48 <TrueBrain> and I blame TallTyler for it! 😛 15:32:53 <TrueBrain> (just because I can) 15:32:54 <pickpacket> TrueBrain: in triple copies and with the cover sheet on? 15:32:59 <Eddi|zuHause> easy choice :p 15:33:08 <glx[d]> but people requested to buy others (like with shares) 15:33:16 <TrueBrain> pickpacket: no, I am not a Vogon 15:34:05 <petern> TrueBrain: I'm not sure I like 'rewarding' people who consider only complaining about things on a random forum as valid feedback... but it's done now. 15:34:06 <TrueBrain> (and if you don't get that reference, you are missing out on some good books) 15:34:47 <TrueBrain> petern: I did consider that too; but that would be childish. One of them was reasonable and explained how he would like to play the game. So I got over that emotional: I don't negotiate with terrorists, and got cracking 🙂 15:34:57 <glx[d]> oh doesn't mean it will work next time 15:35:28 <TrueBrain> taking the high road etc etc 15:35:29 <TrueBrain> ugh 15:35:35 <TrueBrain> I feel mature now ... I don't like it 15:35:37 <petern> Bah this laptop's power lead is so short :/ 15:35:51 <petern> Well you have been doing this for nearly 20 years. 15:35:51 <glx[d]> use an extension ? 15:36:10 <TrueBrain> no VSCode extension is going to make that power lead any longer! 15:36:15 <TrueBrain> (there, I fixed that feeling of being mature) 15:37:14 <TrueBrain> and in other news: dinner time! 15:37:31 <petern> Already. Hmm. 15:37:39 <TrueBrain> also btw honestly curious if you like this Hostile Takeover approach; the other solution I could think of was a button in the AI Debug Window that reads: Kill AI, or something 15:37:59 <glx[d]> yeah Dutch are crazt early with dinner 🙂 15:38:20 <TrueBrain> it is 1738 ... takes me till 1800 to prepare! That aint early ... 15:38:32 <petern> Gameplay-based is better imho. 15:38:39 <glx[d]> dinner time is 2000 for me 15:38:42 <petern> It's easier to justify the cost. 15:39:34 <TallTyler> I agree that company window is the place to put it 15:40:45 <TallTyler> I expect complaints about granularity and “but the game lets me cheat, I want an option to disable it because I have no self-control” but 🙉 15:41:57 <TrueBrain> I also did consider putting this in the cheat window, but what was more work 😄 15:42:22 <glx[d]> btw even if the PR is linked on the forum, you'll most likely won't get any comments about it before the merge 15:43:22 <TrueBrain> I honestly don't care about that forum thread. But one of those dudes in there had a point: play with AIs till you are sick of them. This addresses that point 🙂 15:43:32 <TrueBrain> the rest of that thread is just noise and "omg, you changed something" 15:43:55 <glx[d]> yeah the typical "you killed the game" 15:44:16 <TrueBrain> the funniest part of it is that I usually play like that too: with AIs till they annoy me 15:44:19 <TrueBrain> makes me feel less alone 😄 15:44:26 <petern> Stupid neighbour, your WiFi is stronger than mine because you turned it up to the max :/ 15:44:26 <TrueBrain> but I completely forgot that when removing shares 🙂 15:44:43 *** njml91 has joined #openttd 15:44:45 <glx[d]> if AI is that annoying I don't buy it, I just kill it 🙂 15:45:04 <TrueBrain> it also helps against closure of industries 15:45:10 <TrueBrain> AIs keep them alive for a lot longer 😄 15:45:23 *** njml91 has quit IRC 15:46:55 <dwfreed> petern: their router probably defaulted to that 15:49:14 <petern> Probably yes, infact probably not even an option. Moar is better! 15:51:03 <DorpsGek> [OpenTTD/OpenTTD] JohnTheCoolingFan commented on issue #10232: [Crash]: Black screen on startup and crash (flatpak build) https://github.com/OpenTTD/OpenTTD/issues/10232 15:57:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10232: [Crash]: Black screen on startup and crash (flatpak build) https://github.com/OpenTTD/OpenTTD/issues/10232 15:58:01 <glx[d]> main issue is official build usually works fine 15:59:45 <TrueBrain> If so, not really our problem honestly .. something for downstream to figure out then 15:59:51 <petern> Probably flatpak permissions issues, it's a terrible sandbox system... 16:00:08 <TrueBrain> We can't debug all the isolation software out there 😄 16:03:41 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #10681: [Crash]: Segmentation fault https://github.com/OpenTTD/OpenTTD/issues/10681 16:15:59 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10899: Codechange: replace strecpy with string concatenation https://github.com/OpenTTD/OpenTTD/pull/10899 16:41:58 <pickpacket> TrueBrain: hmm. Plane NewGRF with Vogon ships that float in the sky just like bricks never do… 16:42:35 <TrueBrain> They will just blow up the planet, bit boring :p 16:45:36 <DorpsGek> [OpenTTD/OpenTTD] JohnTheCoolingFan commented on issue #10232: [Crash]: Black screen on startup and crash (flatpak build) https://github.com/OpenTTD/OpenTTD/issues/10232 16:47:13 <TrueBrain> pfff, how are we suppose to know what SDL does and doesn't support 😛 16:50:16 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #10232: [Crash]: Black screen on startup and crash (flatpak build) https://github.com/OpenTTD/OpenTTD/issues/10232 16:50:24 <TrueBrain> the weird thing is that fontcache crashes 16:51:08 <TrueBrain> too bad I don't actually have a way to start anything under Wayland here 😛 16:52:14 <petern> Might be that we interface fontconfig incorrectly. 16:52:53 <petern> But after all these years... heh 16:56:34 *** Eddi|zuHause has quit IRC 16:57:44 <petern> Yeah, that crash occurs if multiple things call FcFini. 16:57:48 <TrueBrain> `SDL_VIDEODRIVER=wayland ./openttd -ddriver=1` look at that, just works with WSLg 16:57:57 <TrueBrain> so that makes it easily reproduceable 🙂 16:58:01 <petern> We try to call it, but some other library we link to is also calling it. 16:58:43 <TrueBrain> Other library being SDL, it seems 🙂 16:59:06 *** Eddi|zuHause has joined #openttd 17:00:23 <petern> Probably, but we never call any font rendering stuff within SDL. 17:01:54 <petern> You'd except `SDL_InitSubSystem(SDL_INIT_VIDEO)` to not init fonts? Dunno. 17:03:27 <petern> I wonder what would happen if we just assume SDL has initialized fontconfig... 17:05:12 <TrueBrain> SDL itself doesn't even seem to use fontconfig 17:05:16 <petern> Maybe you need to install libsdl-ttf2.0 to have it interfere? 17:05:57 <petern> Ah, just idle speculation, sorry 😦 17:06:32 <TrueBrain> time for some breakpoints, I guess 17:07:09 <TrueBrain> nothing to be sorry for; was just browsing the SDL source to see what can cause it 17:07:37 <petern> We do have two FcFini calls, maybe it's us calling it twice :p 17:08:20 <TrueBrain> how do I set a breakpoint in an external library .. 17:09:58 <TrueBrain> it is called twice, twice by us, on the same line 😛 17:10:52 <TrueBrain> but that is also the case with X11 17:11:11 <TrueBrain> called 3 times in total 🙂 17:14:28 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10232: [Crash]: Black screen on startup and crash (flatpak build) https://github.com/OpenTTD/OpenTTD/issues/10232 17:15:21 <TrueBrain> ah, okay, I misunderstood what the function does .. FcInit .... FcFini .. 17:15:43 <glx[d]> hmm could it be bootstrap related ? 17:16:04 <TrueBrain> still not a clue why it matters what SDL backend it selected 😄 17:17:15 <TrueBrain> ugh, valgrind doesn't work with clang binaries .. lol 17:17:47 <petern> Yes it could be bootstrap/fallbackfont related too. 17:19:24 <petern> Lol "who did `std::vector<std::vector<std::vector<byte>>> layouts;`???" "Oh it was me" 17:19:53 <TrueBrain> ah, Wayland does a `clone` 17:19:56 <TrueBrain> which calls FcInit 17:20:17 <TrueBrain> and at the same time we do an FcInit 17:20:20 <petern> A clone? o_O 17:20:43 <TrueBrain> at least, there is an extra FcInit call in Wayland that I don't get in X11 17:20:58 <TrueBrain> `Thread 7 "[pango] FcInit"` 17:21:12 <petern> Hmm. I wonder how we are meant to work around that. 17:21:35 <TrueBrain> why does it call pango? 17:21:41 <TrueBrain> I mean .. we went for the route to NOT use pango 17:22:36 <petern> Is it something about client-side window decorations... basically the window manager. 17:22:40 <TrueBrain> yeah, `SDL_CreateWindow` causes that call 17:22:57 <TrueBrain> a new thread that spins up, and just at that same time we are spinning up too 17:23:01 <TrueBrain> well, that is a bit annoying 17:23:21 <TrueBrain> wayland -> ffi -> decor -> pango 17:23:39 <TrueBrain> petern: but the window manager should handle that; not the client talking to it 17:24:43 <TrueBrain> ugh, duckduckgo has become terrible for searches 17:24:47 <TrueBrain> dunno what is up with that 17:24:55 <LordAro> TrueBrain: while you're in the area, there's also #10470 17:24:58 <petern> So is bing "oddly" 17:25:38 <TrueBrain> LordAro: feel free to test that out yourself 😛 17:25:41 <TrueBrain> you give a finger ...... 😄 17:26:24 <TrueBrain> https://mail.gnome.org/archives/commits-list/2020-August/msg07345.html 17:26:24 <TrueBrain> at least I found the cause of the issue 17:26:33 <LordAro> TrueBrain: no wayland to test with :p 17:26:35 <TrueBrain> no clue why I found that before I found the manual of fcinit 17:27:44 <TrueBrain> meh; I cannot call `wait_for_fc_init` 😛 17:27:51 <TrueBrain> stupid static functions 17:29:49 <TrueBrain> we could compile static against fontconfig; that possibly would solve the issue 😛 17:30:52 <TrueBrain> but it doesn't seem FontConfig is thread-safe 17:31:13 <glx[d]> for a thing intended to be used system wide 17:31:38 <TrueBrain> `static FcConfig *_fcConfig;` 17:31:43 <TrueBrain> that is set when you run `FcInit` 17:31:58 <TrueBrain> and if it is already set when you call it again, it returns the same pointer again 17:32:15 <TrueBrain> so `FcFini` is actually called twice on the same struct 17:33:05 <petern> ```Fontconfig 2.10.91 17:33:05 <petern> Make fontconfig thread-safe``` 17:33:21 <TrueBrain> owh, this is an older version .. so there might be some hope 17:33:30 <petern> No, that's 10 years ago. 17:36:13 <TrueBrain> https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/main/src/fccfg.c#L89 17:36:21 <TrueBrain> it might be thread-safe in the sense multiple threads can operate the library 17:36:38 <TrueBrain> but it doesn't seem thread-safe in the sense that every thread can have their own fcConfig 17:37:24 <petern> MT-safe lol 17:37:34 <TrueBrain> depends on how you define it, I guess 🙂 17:38:03 <TrueBrain> it is ref-counted; so in theory we shouldn't have the issue we are having 😛 17:38:44 <TrueBrain> owh, nevermind, that only refcounts when you use functions on the config 17:38:52 <TrueBrain> not FcInit calls 17:39:03 <TrueBrain> this is silly, almost weird 17:39:47 <TrueBrain> `static FcBool _FcConfigHomeEnabled = FcTrue; /* MT-goodenough */` 17:39:47 <TrueBrain> lol 17:41:06 <petern> I wonder, if it's Pango initializing it in a thread, does Pango have some safety... 17:41:22 <TrueBrain> they do, but all static functions 17:41:28 <TrueBrain> (see earlier link to the patch introducing it) 17:42:13 <petern> Could we link Pango and use that to initialize FontConfig, and thus not directly do it ourselves? 17:42:18 <petern> (Yuck) 17:42:54 <TrueBrain> https://github.com/GNOME/pango/blob/main/pango/pangofc-fontmap.c#L1363 btw 17:43:26 <TrueBrain> petern: no, we need stuff from inside FontConfig 17:44:35 <petern> Upstream bug report? heh 17:44:44 <TrueBrain> are they actually doing something wrong? 17:45:13 <petern> I don't know. Are we? 17:45:22 <TrueBrain> don't think so 17:46:19 <TrueBrain> check if there is a pango thread running and wait for it to go away? 17:46:24 <TrueBrain> but listing threads is also non-trivial I guess 17:47:14 <petern> Call FcInit once on start up before video is initilaized? 17:48:05 <TrueBrain> meh, if only there was a function to see if FontConfig was already initialized 17:48:20 <TrueBrain> petern: and no, that won't do any good from what I can tell 17:48:24 <TrueBrain> FcInit is not refcounted 17:48:28 <TrueBrain> so if pango does FcFini 17:48:30 <TrueBrain> it is gone 17:48:59 <petern> Hmm, so the issue is Fontconfig claiming to be threadsafe when it is no such thing. 17:49:07 <TrueBrain> in some definition it is 17:49:13 <TrueBrain> there are tons of mutex and locks 17:49:17 <TrueBrain> it just shares 1 instance 😛 17:49:17 <petern> In practice, it is not. 17:49:32 <TrueBrain> anyway, that is how I read the code; I could be wrong ofc 🙂 17:49:50 <petern> This is similar to library that calls exit() for some reason 🙂 17:50:18 <petern> (Okay, not similar at all, but just as useful) 17:50:46 <petern> Import fontconfig into 3rdparty and make it use our own instance... 17:51:02 <TrueBrain> well, if we compile static against fontconfig 17:51:04 <TrueBrain> we should be good 😛 17:51:16 <TrueBrain> as then we won't share the pointer with the shared library 😄 17:52:14 <petern> Worth a try...? 17:56:00 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10232: [Crash]: Black screen on startup and crash (flatpak build) https://github.com/OpenTTD/OpenTTD/issues/10232 17:56:14 <TrueBrain> first a write-up 🙂 17:59:57 <TrueBrain> I can fix it with a 90% chance it will work 18:00:00 <TrueBrain> but 100% .. is tricky 18:00:10 <TrueBrain> but basically FontConfig has some internal functions you can use to bypass this problem 18:00:13 <TrueBrain> but we cannot modify Pango 18:00:14 <petern> I just censored myself, oh dear. 18:00:18 <TrueBrain> so I depend on us finishing later 18:01:10 <TrueBrain> wait, where does Pango run FcFini ... 18:01:27 <TrueBrain> no no, we might be in luck ... 18:01:55 <TrueBrain> pango never calls FcFini 18:01:59 <TrueBrain> they call FcInit once 18:02:02 <TrueBrain> and keep it around 18:02:15 <TrueBrain> so your earlier suggestion does work .. but not in the way I expected 😛 18:02:30 <petern> I was wondering... they init it in a thread because it's slow, we init it every time we look for a font... 18:02:31 <TrueBrain> they just keep everything around, like: who gives a shit! 18:03:57 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10898: Codechange: use C++ idioms for the clipboard handling https://github.com/OpenTTD/OpenTTD/pull/10898#pullrequestreview-1459940769 18:05:36 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10898: Codechange: use C++ idioms for the clipboard handling https://github.com/OpenTTD/OpenTTD/pull/10898#pullrequestreview-1459945641 18:06:23 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10898: Codechange: use C++ idioms for the clipboard handling https://github.com/OpenTTD/OpenTTD/pull/10898#pullrequestreview-1459948118 18:06:49 <TrueBrain> I put it in a comment, but orudge wanted to keep maintaining OS/2. But with all the recent changes, I have no clue if it still actually compiles or does anything. Did anyone compile for OS/2 in the last year? 18:14:37 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10898: Codechange: use C++ idioms for the clipboard handling https://github.com/OpenTTD/OpenTTD/pull/10898 18:14:47 <Rubidium_> TrueBrain: thanks for the reviews 18:14:56 <TrueBrain> now do mine! 😛 18:17:32 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910#pullrequestreview-1459969814 18:18:20 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10916: Fix: Wayland crash on startup due to Pango also using FontConfig https://github.com/OpenTTD/OpenTTD/pull/10916 18:18:27 <TrueBrain> the most academic PR in ages 18:19:00 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910 18:20:54 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10470: [Bug]: Mouse click panning not working on Wayland https://github.com/OpenTTD/OpenTTD/issues/10470 18:20:57 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #10470: [Bug]: Mouse click panning not working on Wayland https://github.com/OpenTTD/OpenTTD/issues/10470 18:21:01 <TrueBrain> done LordAro. Now what? 😄 18:21:24 <TrueBrain> owh, right, that PR, that was blaming the SDL version 18:21:26 <TrueBrain> yeah, that is nonsense 18:23:07 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10810: Codechange: rewrite string formatting to C++ https://github.com/OpenTTD/OpenTTD/pull/10810#issuecomment-1575108536 18:24:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910#pullrequestreview-1459990553 18:24:11 <TrueBrain> tnx for the detailed explanation Rubidium; makes a bit more sense 😄 18:33:28 <TrueBrain> and wow, that PR claiming to fix the SDL mouse scroll issue on Wayland does .. weird shit 😄 18:33:37 <TrueBrain> it somewhat fixes it ... but just very somewhat 18:35:18 <TrueBrain> lol, and X11 is also kinda broken, compared to Windows 18:35:28 <TrueBrain> on Windows it is pretty easy to navigate .. on X11 .. not so much 😄 18:36:58 <petern> Oh, so the fontconfig fix is... us after all, Oh dear. 18:37:01 <TrueBrain> the further you get from the mouse, the faster it scroll .. that seems unintential 😄 18:37:11 <petern> That's because it's not warping the mouse... 18:37:12 <TrueBrain> yeah, semi "us" .. it is fine as long as we are alone 😛 18:37:27 <TrueBrain> petern: `SDL_WarpMouseInWindow(this->sdl_window, _cursor.pos.x, _cursor.pos.y);` suggests it should 😛 18:37:37 <TrueBrain> but it doesn't 🙂 18:37:46 <petern> Yes, that call doesn't work in lots of cases. 18:37:53 <petern> Remote displays etc... 18:37:58 <TrueBrain> question only is ... is that WSLg? 😛 18:37:59 <petern> WSLg 18:38:01 <TrueBrain> 😄 18:38:03 <petern> Wayland 18:38:15 <TrueBrain> Emscripten 18:39:19 <petern> Absolutely positioned trackpads... 18:39:36 <TrueBrain> by all means it is terrible 18:39:39 <TrueBrain> but am I allowed to change it? 18:39:42 <TrueBrain> checks project goals ... 18:39:55 <petern> Well we have plenty of compatible modes already 18:40:02 <petern> Just change the default. 18:40:10 <TrueBrain> for emscripten we already do 18:40:17 <petern> "Plenty" .. 1? 18:40:34 <petern> I always use the non-warping mode anyway, so never really notice it. 18:40:45 <petern> But dare you ruin the game? 18:40:51 <TrueBrain> I think we just remove the first two modes from Linux / Emscripten, honestly 18:41:11 <petern> Why? It works fine on Linux normally. 18:41:24 <TrueBrain> sorry, Wayland / Emscripten 18:42:31 <petern> <https://wiki.libsdl.org/SDL2/SDL_HINT_MOUSE_RELATIVE_WARP_MOTION> 18:42:37 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/7d6aff3a344d05ea3c7d05d619f1207ab56861e5 18:42:38 <DorpsGek> - Update: Translations from eints (by translators) 18:42:44 <petern> Mentions remote desktop of all things. I guess it's a bit old for wayland. 18:42:59 <petern> Huh 18:42:59 <TrueBrain> that URL doesn't work? 18:43:23 <TrueBrain> anyway, we normally enable `SDL_HINT_MOUSE_RELATIVE_MODE_WARP`, but it doesn't work for Emscripten and, as it turns out, Wayland 😛 18:43:23 <petern> <https://wiki.libsdl.org/SDL2/SDL_WarpMouseInWindow> 18:43:52 <petern> (Yeah, that broken link is on that page...) 18:44:27 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10916: Fix: Wayland crash on startup due to Pango also using FontConfig https://github.com/OpenTTD/OpenTTD/pull/10916#pullrequestreview-1460034665 18:44:28 <TrueBrain> these hints always pussled me 18:44:30 <petern> <https://github.com/libsdl-org/SDL/issues/5741> more relevant 18:46:49 <TrueBrain> `2.0.22 made warping in relative mode actually functional, which surprised many applications that weren't expecting the additional mouse motion.` 18:46:50 <TrueBrain> lol 18:47:11 <TrueBrain> my SDL is too old, let's update, and see if that is actually true for WSLg 🙂 18:48:23 <TrueBrain> reading libSDL code is always easier than any of their docs 😛 18:49:04 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910#pullrequestreview-1460043793 18:52:24 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10874: Fix #10831: Level crossing parts left barred after crossing tile removal https://github.com/OpenTTD/OpenTTD/pull/10874#pullrequestreview-1460050515 18:53:29 <petern> Odd way of writing `it = ...` to be honest: ```for (FlowStatMap::iterator it(ge.flows.begin()); it != ge.flows.end();) {``` 18:53:45 <TrueBrain> lol, bit unusual indeed 🙂 18:54:30 <petern> Gotta avoid a copy assignment, or something... 18:54:48 <TrueBrain> as if the compiler doesn't do away with that 😛 18:54:52 <petern> Quite. 18:54:58 <TrueBrain> premature optimization? 😄 18:55:35 <petern> I suspect it's just code converted from a previous way of doing something that originally used custom iterators. 18:56:27 <petern> 13" laptops are too small for coding on, that's for sure 😦 18:57:21 <TrueBrain> okay, zero difference with latest version of SDL .. meh 18:57:31 <TrueBrain> hard to test modes I cannot reproduce 🙂 18:58:39 <DorpsGek> [OpenTTD/OpenTTD] James103 opened issue #10917: [Bug]: Loan interest paid at end of quarter is accounted in next quarter's expenses https://github.com/OpenTTD/OpenTTD/issues/10917 19:00:36 <petern> Are you suggesting back-posting your payments!? 19:03:22 <TrueBrain> accounting .. you got to hate accounting 😛 19:05:25 <TrueBrain> `Error: SDL2: Couldn't get window surface: ` 19:05:31 <TrueBrain> wayland doesn't work with libsdl from vcpkg for me .. 19:05:33 <TrueBrain> how annoying 19:08:00 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10910: Fix: track "memory installed" for surveys less precisely https://github.com/OpenTTD/OpenTTD/pull/10910 19:08:20 <petern> Stupid bank account, they keep asking for my work phone number... I don't have a work phone. 19:08:41 <TrueBrain> hmm, it did build wayland support in SDL .. so why doesn't it launch? 19:09:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10916: Fix: Wayland crash on startup due to Pango also using FontConfig https://github.com/OpenTTD/OpenTTD/pull/10916 19:09:09 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #10232: [Crash]: Black screen on startup and crash (flatpak build) https://github.com/OpenTTD/OpenTTD/issues/10232 19:09:10 <petern> Does WSLg itself support it? 19:09:14 <TrueBrain> yup 19:09:21 <TrueBrain> can use it with the Ubuntu variant just fine 19:10:14 <petern> Hmm, dare I faff about installing WSL on this laptop... 19:10:24 <petern> 13" isn't enough for it either, I'm sure 😄 19:10:48 <TrueBrain> weirdly enough the SDL_GetError returns nothing 19:12:12 <TrueBrain> SDL has WSLg support these days; it explicitly test for WSLg and uses DirectX if it can (instead of OpenGL) 19:12:17 <TrueBrain> unrelated to my problem btw, but funny 19:12:36 <petern> ```const GoodsEntry *GE() const { return ge; } 19:12:36 <petern> const GoodsEntry *ge;``` 19:12:40 <petern> Such abstraction. Hmm. 19:12:43 <TrueBrain> good 19:13:30 *** nielsm has quit IRC 19:13:37 <TrueBrain> okay, so `CreateWindow` works, but it doesn't have a surface 19:13:37 <TrueBrain> lol 19:15:44 <TrueBrain> ah, lol, it does start on a clean config 19:15:45 <TrueBrain> go figure 😛 19:16:07 <TrueBrain> it even uses OpenGL 😮 19:18:05 <TrueBrain> okay, without modification it seems Wayland is pretty much doing the right thing with latest SDL 19:22:15 <TrueBrain> users claim it doesn't work with 2.26, but the code and my testing suggest it should .. odd 19:22:46 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10918: Codechange: Use std::reverse instead of custom implementation. https://github.com/OpenTTD/OpenTTD/pull/10918 19:22:57 <petern> Let's see if that builds... 19:23:36 <petern> (Genuinely, I just composed it via codespaces and no local compilers arounds) 19:23:43 <TrueBrain> haha 19:24:21 <petern> 114GB free, I guess I could just about install WSL... 19:25:56 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10918: Codechange: Use std::reverse instead of custom implementation. https://github.com/OpenTTD/OpenTTD/pull/10918#pullrequestreview-1460101724 19:27:49 <TrueBrain> okay, without actual access to Wayland on a system where on X11 mouse-wrapping does work, I cannot debug this 😛 19:28:13 <TrueBrain> so you will have to upgrade your computer LordAro! 19:29:14 <petern> He can't, his other hobby has taken all his money. 19:30:05 <petern> I spent something like £50 a couple of weeks ago on a set of brake pads. 19:30:07 <petern> For a bike. 19:30:15 <petern> With two wheels. 19:30:18 <petern> £50. 19:30:21 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10141: Fix #10140: [SDL2] Lock mouse while moving viewport https://github.com/OpenTTD/OpenTTD/pull/10141#issuecomment-1575148370 19:30:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #10141: Fix #10140: [SDL2] Lock mouse while moving viewport https://github.com/OpenTTD/OpenTTD/pull/10141 19:31:01 <JGR> Brake pads are not really an area where you want to go cheap and cheerful 😛 19:34:49 *** nielsm has joined #openttd 19:38:26 <sittinbythefire> Eh, back in my day when my pads wore out I just used my shoe 😛 19:38:31 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 19:38:32 <pickpacket> petern: what kind of brakes? 19:41:46 <TrueBrain> so slowly piecing things together ... we copied SDL1 to SDL2 ofc, but due to a bug in SDL2 they didn't actually queue a new mouse event move when warping .. they do now, but it is disabled by default as too many games failed because of it .. 19:42:06 <TrueBrain> but it was active for a short time in SDL2 for Wayland, causing the annoying behaviour people seem to report on Wayland 19:42:40 <TrueBrain> just one big clusterfuck of problems on top of each other 19:44:16 <TrueBrain> our mouse code became so weird ... 19:45:49 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575158655 19:46:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575158917 19:47:40 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575159138 19:48:08 <TrueBrain> You don't pay my subscription! 19:55:27 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #10889: Backport master into release/13 https://github.com/OpenTTD/OpenTTD/pull/10889 19:56:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575162329 19:57:08 <DorpsGek> [OpenTTD/OpenTTD] Andrew350 commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575164135 19:57:47 <TrueBrain> English sucks ..... can we all start speaking ........ I dunno 😛 19:58:17 <Rubidium_> Dutch? :D 19:58:33 <TrueBrain> I btw agree it is not all that clear jfs- , but really out of ideas how to make it better without getting really lengthy 🙂 20:00:25 <frosch> ban you pay more to make the takeover not look "hostile" to the media? 20:00:41 <TrueBrain> hahahaha, bribe the media while at it 😛 20:00:43 <jfs-> In the takeover you will purchase all fixed assets, pay off all loans, and pay two years of profits. 20:01:32 <TrueBrain> I can leave out `In the takeover` I guess, but purchase, that is nice 20:02:11 <jfs-> the "In the takeover" is to lead better into the final "and pay two years of profits" 20:02:11 <TrueBrain> is `fixed` needed? Other places also call it just `assets`? (honest questions; trying to be consistent or not, basically) 20:02:55 <jfs-> well, are you also buying their cash on hand? fixed assets would be vehicles and infrastructure, while all assets would also include liquid assets = cash balance 20:03:11 <TrueBrain> works for me 20:03:28 <jfs-> I think their cash on hand should just disappear, unless it's negative in which case you need to pay it off as a loan 20:03:45 <TrueBrain> I did the first; the latter is a nice addition 20:04:03 <TrueBrain> anyway, there is now too often `takeover` in that one screen .. 20:04:57 <TrueBrain> think just removing the first sentence is fine 20:05:14 <jfs-> "You will purchase all fixed assets and pay off all loans. Existing shareholders will be paid two years of profits." 20:05:14 <jfs-> inventing a new imaginary concept 20:05:33 <TrueBrain> yeah .... I don't want the flamewar about "which shareholders" 😛 😛 😄 20:06:23 <TrueBrain> `In the hostile takeover of {COMPANY} you will purchase all fixed assets, pay off all loans, and pay two years of profits.` is what I have now 20:06:32 <jfs-> okay, "You are about to do a hostile takeover of {COMPANY}. \n This will purchase all fixed assets, pay off all loans, and pay two years worth of profits." 20:07:12 <TrueBrain> `In an hostile takeover of {COMPANY} you will purchase all fixed assets, pay off all loans, and pay two years worth of profits.{}{}The total is estimated to be {CURRENCY_LONG}.{}{}Do you want to continue this hostile takeover?` 20:07:44 <jfs-> I like that 20:08:06 <sittinbythefire> In a hostile 20:08:14 <sittinbythefire> sorry grammar 😛 20:08:27 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 20:08:27 <TrueBrain> darn it, a bit too late 😛 20:08:40 <TrueBrain> tnx both 🙂 20:08:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 20:09:10 <TrueBrain> also added that you have to pay for negative balance 🙂 20:10:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575170401 20:11:55 <TrueBrain> ha, finally discovered why the SDL PR fix actually worked .. and not for the reasons everyone thought .. but `SDL_SetRelativeMouseMode` flushes all mouse movements from the event queue 20:12:20 <DorpsGek> [OpenTTD/OpenTTD] FLHerne commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575170890 20:13:20 <FLHerne> You're overthinking it, IMO (see comment on GH) 20:13:35 <TrueBrain> I was thinking the same about your comment 😄 🙂 (sorry) 20:14:21 <FLHerne> > You are about to buy Fast Transport Inc. | All infrastructure, vehicles and other assets will become part of your company, Anglian Logistics. | Estimated Cost: £131,445 | [Buy Company] [Cancel] 20:14:32 <FLHerne> (my proposal from GH) 20:15:09 <TrueBrain> yeah, this now became bikeshedding honestly 🙂 20:16:03 <sittinbythefire> Considering the AI has no say in the matter, it does seem appropriate to call it "hostile" 20:16:04 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 dismissed a review for pull request #10884: Remove: obsolete NewGRF text unprinting. https://github.com/OpenTTD/OpenTTD/pull/10884#pullrequestreview-1447446097 20:16:07 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10884: Remove: obsolete NewGRF text unprinting. https://github.com/OpenTTD/OpenTTD/pull/10884 20:16:13 <pickpacket> TrueBrain: should maybe clarify that all the AI company's bikesheds are part of the fixed assets? 20:16:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575172643 20:17:10 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10884: Remove: obsolete NewGRF text unprinting. https://github.com/OpenTTD/OpenTTD/pull/10884#pullrequestreview-1460144135 20:17:33 <TrueBrain> haha, well, that is one way to get things merged Rubidium 😄 20:18:46 <TrueBrain> okay ... I managed to get X11 do the same as Wayland .. not sure that is good or bad, but at least it is the same 😛 20:19:25 <FLHerne> We already use "Buy X" for everything else, why introduce new terminology to confuse players 20:19:44 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575174249 20:19:45 <TrueBrain> because it is something fundementally different? 20:19:48 <FLHerne> and no other cost estimate tries to give a detailed rationale; if you shift-click some bit of track, it doesn't say "this includes the cost of demolishing trees and rocks, partially raising some slopes, and an extra factor for coastlines" 20:19:52 <Rubidium_> TrueBrain: at least trying to get some progress in that PR 20:20:17 <FLHerne> it just says "Estimated Cost: £14,124" because the player really doesn't care where the number came from, just whether it's a number that's worthwhile for them 20:20:21 <TrueBrain> michi_cc[d]: lol .. yes, more bikeshedding 😄 But your comment lacks a suggestion .. what would you do? 20:20:46 <michi_cc[d]> "assets", i.e. just drop the fixed. 20:21:27 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575174786 20:21:57 <FLHerne> with michi_cc[d]'s suggestion (which I agree with) I think your latest proposal is ok 20:22:03 <FLHerne> it still seems over-thought to me 20:22:10 <TrueBrain> jfs-: yes, other PR 🙂 20:22:29 <TrueBrain> put it down on the big pile of "shit we could add to GS" 😄 20:22:44 <TrueBrain> FLHerne: I disagree it is over-thought, but that is why we have opinions 🙂 20:22:57 <FLHerne> incidentally, does buying a company preserve exclusive transport rights? :p 20:23:12 <FLHerne> bribes paid? 20:23:17 <TrueBrain> I was thinking about giving every city the AI was located in a penalty, so they don't like you 20:23:20 <TrueBrain> "hostile" 😛 20:23:21 <FLHerne> [it doesn't matter, the question just appeared in my brain] 20:24:18 <sittinbythefire> TrueBrain: Yeah but if the company sucked they might actually like you better for buying them out 😛 20:24:34 <TrueBrain> 😄 20:25:07 <FLHerne> TrueBrain: I guess my impression is that OpenTTD's text strings are consistently rather terse 20:25:16 <jfs-> hmm possibly vehicles also _can_ count as non-fixed assets because they may be possible to readily sell on a market, so just saying "assets" is fine 20:25:18 <FLHerne> it's one of very few things that *is* consistent about them 20:26:02 <jfs-> or maybe I'm just spouting nonsense 20:27:07 <petern> Abbreviate it to ass. 20:27:08 <FLHerne> this one is certainly more whimsical, but that doesn't fit my expectation of how OTTD interface reads 20:27:18 <FLHerne> I guess the warning about bribery is similar 20:27:28 <petern> And if you assemble assets, that could be ass. ass. 20:28:30 <petern> FLHerge, if it was a tooltip, it should be terse. But this is a gameplay message. 20:28:34 <michi_cc[d]> jfs-: OTTD is totally unrealistic here anyway; who buys vehicles instead of leasing anyway. Totally ruins your equity to asset ration otherwise 😜 20:28:45 <petern> It should still be concise but a little flourish is fine. 20:29:58 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919 20:30:16 <TrueBrain> LordAro (or any other Linux user): mind testing #10919 and see if mouse lock still works as expected? 20:30:24 <TrueBrain> I think I did it correct, but I cannot really test it ... 20:30:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 20:30:48 <jfs-> OTTD accounting is completely broken from the core, which is why the share purchasing/ownership was also broken 20:30:52 <TrueBrain> removed `fixed` from the sentences, by agreement in this channel 20:33:38 <TrueBrain> https://cdn.discordapp.com/attachments/1008473233844097104/1114653141133176923/image.png 20:34:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919 20:40:10 <sittinbythefire> I guess time will tell if certain people agree with the overall idea and the details involved, but as someone who does occasionally partake in this playstyle I generally like the idea and the way it's going so far 👍 20:40:40 <TrueBrain> Tnx 🙂 How refreshing, a positive remark 😄 It is appreciated 🙂 20:42:12 *** temeo[m] has joined #openttd 20:44:05 <FLHerne> TrueBrain: sorry, yes, I do think it's a great feature; thank you for implementing it 20:44:15 <TrueBrain> ❤️ 20:44:24 <FLHerne> I just like to bikeshed things :p 20:44:39 <TrueBrain> we sometimes get lost in the details 😄 20:48:26 <petern> > The total is estimated to be £373,944.231258375. 20:50:37 <petern> jfs-: We should implement a spreadsheet to let players simulate running their business. 20:51:09 <sittinbythefire> Getting lost in the details is not necessarily a bad thing, as long as the discussion remains civil and constructive 🙂 20:53:05 <TrueBrain> it was \o/ 20:53:05 <petern> Link OpenTTD into your Sage Online Accounts to heighten the realis,m 21:00:04 <TrueBrain> argh, something keeps changing my setting back ... who is doing this ... SHOW YOURSELF 21:00:42 <TrueBrain> after tick 8 or so the `_settings_client` is reloaded it seems 21:00:59 <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575193795 21:01:25 <petern> Ooh #10918 builds, I wonder if it works though. 21:01:48 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#issuecomment-1575193913 21:02:45 <TrueBrain> ah, after the GRFs are scanned the config is loaded again 21:02:50 <TrueBrain> so that is a bit in the game already .. hmm 21:04:29 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #10874: Fix #10831: Level crossing parts left barred after crossing tile removal https://github.com/OpenTTD/OpenTTD/pull/10874 21:04:32 <DorpsGek> [OpenTTD/OpenTTD] glx22 closed issue #10831: [Bug]: Multi-track level crossing parts left barred when middle part removed such that the result is two unrelated crossing sections https://github.com/OpenTTD/OpenTTD/issues/10831 21:05:29 <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#pullrequestreview-1460179257 21:05:40 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919 21:06:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#pullrequestreview-1460180232 21:07:05 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10920: Add: [SDL] change mouse mode if warping doesn't work https://github.com/OpenTTD/OpenTTD/pull/10920 21:07:16 <TrueBrain> petern: something like 10920, would that be smart? I really don't know 😄 21:10:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919 21:10:52 <TrueBrain> and ^^ now in 3 readable commits 😄 21:16:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 21:16:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10141: Fix #10140: [SDL2] Lock mouse while moving viewport https://github.com/OpenTTD/OpenTTD/pull/10141#issuecomment-1575198445 21:17:03 <TrueBrain> right, that rabbit hole was deep enough .... 😄 21:19:00 <TrueBrain> who else uses Linux ... Rubidium / frosch .. mind giving 10919 and 10920 a look? (if you use native Linux). One of the few things I really cannot test in my current setup 🙂 21:19:10 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919#pullrequestreview-1460185438 21:19:58 <TrueBrain> ugh, copy/pasting blocks removes that space 21:19:59 <TrueBrain> so annoying 21:20:26 <DorpsGek> [OpenTTD/OpenTTD] ghisvail commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 21:20:53 <frosch> TrueBrain: DoAcquireCompany transfers both the current money and loan to the new owner. CalculateHostileTakeoverValue seems to contradict that? 21:21:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 21:21:44 <TrueBrain> frosch: the loan too? Hmm, I did not spot that. I kinda didn't want that, as otherwise companies are really cheap to take over when they just started 21:21:52 <Rubidium_> TrueBrain: it going to take a while to compile 10919 (and 10920 after that)... 21:21:57 <DorpsGek> [OpenTTD/OpenTTD] ghisvail commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 21:22:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919#pullrequestreview-1460191578 21:22:09 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919 21:22:13 <TrueBrain> Rubidium_: sorry .... 21:23:00 <TrueBrain> frosch: ah, only if the bankrupt_value is zero .. hmmmm 21:23:19 <frosch> yeah, no idea why that check 21:23:32 <TrueBrain> because when you buy a bankrupt company you don't pay for the loan 21:23:37 <TrueBrain> it just disappears 21:24:00 <TrueBrain> so it makes no sense that piece of code is there 21:24:05 <TrueBrain> as it cannot be called before my PR 21:24:15 <frosch> hmm, yeah, also makes sense. the bank does not get their money back 21:24:30 <TrueBrain> so I can just remove that blob of code, I think 🙂 21:24:51 <frosch> isn't it used for bankrupt-buyout? no idea 🙂 21:25:12 <frosch> a company can go bankrupt and still have value in assets 21:25:45 <TrueBrain> but when you hav ea bankrupt buyout, the bankrupt_value is always 1 or higher 21:26:20 <TrueBrain> there is this lovely `assert(c->bankrupt_value > 0);` 21:26:41 *** HerzogDeXtEr has quit IRC 21:26:41 <frosch> `SetDParam(1, c->bankrupt_value == 0 ? STR_NEWS_MERGER_TAKEOVER_TITLE : STR_NEWS_COMPANY_MERGER_DESCRIPTION);` <- there is also that 21:26:53 <TrueBrain> owh, left-over from shares maybe? 21:27:27 <frosch> no idea, i did not review that 🙂 21:27:34 <TrueBrain> yeah, pretty sure that is the case 21:28:12 <TrueBrain> yes, that is the case 21:28:21 <TrueBrain> `c->bankrupt_value = 0; DoAcquireCompany(c);` 21:28:53 <TrueBrain> good catch there frosch 🙂 21:29:28 <TrueBrain> the only thing with my PR ... if you to a hostile takeover of a company that is going bankrupt, you pay the bankrupt price and it acts like you bought the company in bankrupt 21:29:32 <TrueBrain> that felt like the best thing to do 21:30:34 <TrueBrain> owh, I didn't commit that yet .. well, I will in a bit 😛 21:31:30 <TrueBrain> lol, so a buyout with shares could give you a loan higher than the max 🙂 Nice! 21:31:34 <TrueBrain> another share-related bug 😛 21:33:34 <TrueBrain> should be all fixed now 🙂 21:33:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 21:39:29 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919 21:39:42 <TrueBrain> (I am using the CI to get the SDLv1 driver to compile 😛 ) 21:40:19 <jfs-> actually, when a company goes bankrupt and does not get purchased by someone else, the on-map features owned by that company should only be removed if it would be profitable to do so, so actually only railroads. everything else should go to an ownerless state where things will slowly decay into rubble, but if anyone wants to build where those things stand, they would have to pay for its removal 21:40:30 <frosch> 10919 works with native x11 21:40:31 <jfs-> (that's a terrible idea btw) 21:40:46 <frosch> am i supposed to test 10920 separately or combined? 21:40:49 <TrueBrain> frosch: scrolling works as expected? No weirdness? 21:40:56 <TrueBrain> (and this is with mouse-lock?) 21:41:02 <frosch> yes, mouse-lock 21:41:06 <TrueBrain> awesome! 21:41:13 <TrueBrain> yeah, you can load 10920 on top of it if you like 21:41:26 <TrueBrain> the thing to watch for, is if you actually remain in mouse-locked mode 21:41:40 <TrueBrain> you don't happen to have Wayland I suppose? 21:41:47 <frosch> same weirdness as always: if you have the mouse near the screenedge, you can't properly scroll in that direction, because the mouse will be clamped at the screen edge before warped back 🙂 nothing new 21:42:01 <TrueBrain> good 🙂 21:42:09 <TrueBrain> as this code-path is far simpler than the old one 😛 21:42:18 <frosch> i had to google how to figure out whether i had x11 or wayland 21:42:24 <TrueBrain> `SDL_VIDEODRIVER=` 21:42:28 <TrueBrain> I could have told you 🙂 21:42:36 <TrueBrain> and `-ddriver=1` tells you 21:42:48 <TrueBrain> `dbg: [driver] SDL2: using driver 'x11'` 21:43:14 <Eddi|zuHause> jfs-: not sure how easy that would be, afair roads already behave this way, but stations might need additional handling for owner_none, because they should not behave like neutral oil rig stations 21:43:15 <frosch> ah, ok, at least -ddriver agrees 21:43:28 <TrueBrain> but yeah, I cannot believe someone changed the Windows driver to work in a non-relative-mode, but nobody did for SDL 😛 21:43:53 <TrueBrain> well, if 10920 also does what it should, I am a happy pupper 21:44:15 <frosch> hmm, 10919 is different 21:44:18 <frosch> it scrolls slower 21:44:35 <frosch> oh, and 10920 does not work for me 21:44:42 <frosch> it disabled locking 21:44:46 <TrueBrain> darn it ... 21:45:35 <TrueBrain> mind debugging that a bit for me frosch ? As code-wise it should really work 😛 21:45:50 <TrueBrain> maybe the change is not instant? Hmm 21:46:10 <TrueBrain> basically, I change the mouse position slightly to detect if that works at all 21:46:19 <TrueBrain> if not, it changes scroll mode 21:47:16 *** nielsm has quit IRC 21:47:37 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919#issuecomment-1575211515 21:47:37 <TrueBrain> as for the slower scrolling, that is interesting .. 21:47:54 <TrueBrain> Rubidium: for you too, mouse lock just works fine? 21:47:55 <frosch> i retested, scrolling is fine with 10919 21:48:01 <TrueBrain> ah, pfew 🙂 21:48:29 <TrueBrain> Rubidium has the weirdest UUID .. never saw that before 😛 21:50:08 <Rubidium_> TrueBrain: I'm not noticing any differences 21:50:18 <Rubidium_> between 10919 and 13.1 21:50:29 <TrueBrain> awesome; tnx a lot 🙂 So that means for X11 this works .. now let's hope that it also fixes stuff for Wayland 🙂 21:50:50 <TrueBrain> it really should, honestly; not using relative mode means all the bugs related to relative mode are gone 😛 21:51:17 <TrueBrain> now for 10920 .. as that is the actual problem with Wayland .. just people didn't notice they couldn't move past their screen 21:51:25 <TrueBrain> so on the movies you see people releasing their mouse, and moving again 21:51:37 <TrueBrain> oblivious that the game is not intended to be played that way 😄 21:52:03 <TrueBrain> but I also couldn't find another way to detect if WarpMouse actually works or not 21:52:35 <TrueBrain> Wayland does return an error when trying to change some mode, but X11 with a remote desktop (or WSLg) doesn't error .. it just doesn't work 21:53:05 <TrueBrain> maybe a `CSleep` between `WarpMouseInWindow` and `GetMouseState` frosch ? 21:53:17 <frosch> i think the 10920 call happens way to early 21:53:29 <frosch> it is done before the window is shown, and mouse position is reported as (0,0) 21:53:38 <TrueBrain> huh? Before it is shown? 21:53:40 <frosch> after the window is present, the mouse is actually at topleft corner 21:53:53 <frosch> yes, i see the debug output before the window is present 21:54:30 <TrueBrain> the window should already be long initialized 21:54:41 <TrueBrain> it is in the mainloop .. hmmm 21:55:02 <frosch> or well, before anything is rendered in it, there is the window border with transparent content 21:55:15 <TrueBrain> yeah, but that is fine 21:55:27 <TrueBrain> SDL is up and running; so mouse changes should already be handled 21:56:20 <frosch> anyway, it's the get-postion that fails 21:56:34 <frosch> it returns (0,0), when the mouse is normally not there 21:56:59 <TrueBrain> hmm .. might it be that the cursor is hidden? 21:58:15 <frosch> https://cdn.discordapp.com/attachments/1008473233844097104/1114674436839329862/image.png 21:58:15 <frosch> actually, in the second line it nows the position, later it does not know it 21:58:45 <TrueBrain> if you remove the `if` statement that is there; does that change anything? 21:59:33 <frosch> which if? the "RMB_FIXED" one? i already removed that to not always have to switch back 🙂 21:59:47 <TrueBrain> hmm, but it runs once ofc 22:00:08 <TrueBrain> the video driver really is up and running at that moment in time .. odd 22:00:09 <frosch> "x and y are set to the mouse cursor position relative to the focus window" <- maybe there is no focus window 22:00:39 <TrueBrain> the only thing that isn't done yet, is a `MakeDirty`call 22:00:42 <TrueBrain> so the window isn't drawn 22:00:52 <frosch> it propably works with SDL_GetGlobalMouseState, let's try 22:01:02 <TrueBrain> please do 🙂 22:01:25 <TrueBrain> there is also a WarpMouseGlobal, so we have that going for us 22:02:32 <frosch> https://cdn.discordapp.com/attachments/1008473233844097104/1114675514867728515/image.png 22:02:32 <frosch> <- yeah, okey, with the local warp it's silly ofc 22:02:56 <TrueBrain> can't believe the other function didn't work, but okay 😛 22:03:24 <TrueBrain> only issue .. then it doesn't detect WSLg 😛 22:03:48 <frosch> with SDL_GetGlobalMouseState and SDL_WarpMouseGlobal it works 22:04:05 <TrueBrain> it also works here, it says 22:04:07 <TrueBrain> haha 22:04:43 *** Wolf01 has quit IRC 22:05:04 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #10920: Add: [SDL] change mouse mode if warping doesn't work https://github.com/OpenTTD/OpenTTD/pull/10920#pullrequestreview-1460276956 22:05:51 <TrueBrain> lol, how can it report it works for me, while that is nearly impossible! 😄 22:06:28 <TrueBrain> reports 0,0 on wayland 22:06:36 <TrueBrain> ugh SDL .... why .... just .... why 22:06:39 <TrueBrain> or Linux 22:06:41 <TrueBrain> either one 22:06:54 <Rubidium_> it says my computer doesn't support warping 22:07:39 <sittinbythefire> Eddi|zuHause: Yes, roads, canals, locks, and aquaducts already return to a neutral state upon bankruptcy. All other infra disappears if not bought out. Making the abandoned infra something which can be purchased from "the state" to be reused or else it decays over time would definitely be interesting, but yeah obviously much more complicated and way out of scope for the changes in that PR 😛 22:08:11 <TrueBrain> okay, so I need another trick to detect if warping works or not ... 22:08:54 <frosch> ok, i checked getmousestate in the regualr gamr loop 22:09:06 <frosch> it remains (0,0) until i move the mouse into the window for the first time 22:09:36 <frosch> though it works if i start it with the mouse already inside the window 22:09:46 <TrueBrain> ah, okay, that kinda makes sense ofc 22:10:23 <frosch> so, two issues: it does not work when mouse is outside the window, and it does not work that early 22:10:55 <TrueBrain> if you move it inside `SDL_WINDOWEVENT_ENTER`? 22:11:16 <TrueBrain> that reports correctly here that warping does not work 22:13:51 <TrueBrain> (the non-global variant I meant btw) 22:14:55 <frosch> when i start ottd with the mouse inside the window, SDL_WINDOWEVENT_ENTER is called after the blitter is set up (so way later than the other place) and mousestate is correct 22:15:45 <frosch> i am not sure about detecting warping when moving the mouse into the window later, i mean you are moving the mouse in that moment 22:16:02 <frosch> wouldn't you need to empty the queue again or something? 22:16:16 <TrueBrain> hmm .. dunno .. you tell me, do you notice it? 22:16:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10920: Add: [SDL] change mouse mode if warping doesn't work https://github.com/OpenTTD/OpenTTD/pull/10920 22:16:26 <TrueBrain> here, a version that does it only the first time you enter the window 22:16:49 <DorpsGek> [OpenTTD/OpenTTD] ghisvail commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 22:18:36 <TrueBrain> the trick I use here, is that even in movement, I move the mouse 1 pixel; but then in handling of the events it finds the last "moved-to" event that happened, which contains an absolute position 22:18:45 <TrueBrain> so I think this would work fine 22:18:48 <frosch> SDL_WarpMouseInWindow does not work inside SDL_WINDOWEVENT_ENTER 22:18:56 <TrueBrain> darn it 22:20:25 <TrueBrain> okay .. so what if we move it inside SDL_MOUSEMOTION? 22:20:27 <TrueBrain> does it work there? 22:20:46 <TrueBrain> it fails here, so I have that going for us 22:21:00 <frosch> mind: it does warp the mosue, but the mousestate does not immediately report it 22:21:09 <TrueBrain> ah .. yeah, I cannot test that .. 22:21:21 <TrueBrain> it wouldn't surprise me if it doesn't work instantly 22:21:33 <TrueBrain> but that would make it even more difficult 22:22:25 <frosch> basically impossible, since the mouse is also moved by the user 22:22:34 <petern> Would it ruin the game to change the default to be the non-locking movement mode? 22:22:59 <frosch> what is the problem with the global state? does that not work with wayland? 22:24:08 <frosch> so, unpopular opinion: instead of 10920 change the default scroll setting 22:24:24 *** keikoz has quit IRC 22:24:26 <frosch> only old people expect the warping mode, no modern game does that, do they? 22:24:26 <petern> I... just said that :p 22:24:27 <TrueBrain> yeah, but that doesn't fix existing configurations 🙂 22:24:37 <TrueBrain> anyway, did you try moving it to SDL_MOUSEMOTION? Does that work? 22:24:39 <TrueBrain> or also not? 22:24:42 <frosch> petern: while i was typing 🙂 22:25:05 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10918: Codechange: Use std::reverse instead of custom implementation. https://github.com/OpenTTD/OpenTTD/pull/10918 22:25:19 <TrueBrain> frosch: from what I gather, you cannot warp a mouse on Wayland; just this is hard to explain to people, so it is difficult to gather the info about it .. but it seems that is the core of the issue 22:27:09 *** gelignite has quit IRC 22:27:15 <frosch> i added the mousestate to MOUSEMOTION 22:27:21 <petern> Poor kicad ... <https://gitlab.com/kicad/code/kicad/-/issues/9785> 22:27:39 <frosch> it does not report the succesful warp, so it looks like the window-local state is queued, and only the global state is immediate 22:28:31 <TrueBrain> meh ... and the global state also works here, and things start to act really weird 22:28:37 <TrueBrain> as it really cannot move the mouse 22:29:25 <frosch> oh, so sdl lies about the global state? 22:29:58 <TrueBrain> I dunno .. it is funny, when I use WarpMouseInWindow, I see the change back on the GetGlobalMouseState 22:30:03 <TrueBrain> ah, but not on Wayland 22:30:05 <TrueBrain> only on X11 22:30:31 <TrueBrain> so at the very least, this works to detect backends like Wayland 22:31:29 <TrueBrain> looking at the code, it indeed seems I cannot detect X11 didn't execute the warp this way 22:31:35 <frosch> https://cdn.discordapp.com/attachments/1008473233844097104/1114682824709111970/image.png 22:31:35 <frosch> <- all inside SDL_MOUSEMOTION 22:32:29 <TrueBrain> yeah, global state uses `mouse->x` 22:32:34 <TrueBrain> and warp changes that directly 22:32:39 <TrueBrain> for X11; for Wayland there is another codepath 22:35:44 <TrueBrain> inside the WINDOWENTER thingy it doesn't work at all for me 😛 22:36:10 <TrueBrain> or are my debug statements just shit? Yeah, that is more likely 😄 22:38:05 <TrueBrain> okay, this is not a good way to detect warping .. so yeah, change default? 🙂 22:39:17 <petern> It's simpler... 22:39:18 <TrueBrain> owh, I was wrong btw .. GetGlobalMouseState is deligated to the X11 backend, but GetMouseState is kept internal 22:39:36 <TrueBrain> I think how it works for X11, is that when the next event comes in from the X11 server, it updates 22:39:46 <TrueBrain> so it really doesn't know warping failed till it sees the next mouse move 22:39:57 <DorpsGek> [OpenTTD/OpenTTD] ghisvail commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 22:40:00 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919#pullrequestreview-1460340073 22:40:41 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 22:41:01 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10919: Fix: [SDL] unify the way X11 and Wayland handle mouse events https://github.com/OpenTTD/OpenTTD/pull/10919 22:42:16 <DorpsGek> [OpenTTD/OpenTTD] ghisvail commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 22:42:56 <DorpsGek> [OpenTTD/OpenTTD] ghisvail commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 22:43:52 <TrueBrain> okay, X11 is just weird ... what it does is when you change the location of the mouse, it syncs that to the X11 server 22:44:00 <TrueBrain> then when you request the position, it sends a QueryPointer to the server 22:44:02 <TrueBrain> that is what we get back 22:44:09 <TrueBrain> (for global stuff only btw) 22:44:27 <TrueBrain> so on WSLg the X11 server is actually the one that is lying 22:44:35 <TrueBrain> it might not even be aware something isn't working 😛 22:45:07 <TrueBrain> some NOT_IMPLEMENTED function .. and when the next mouse event happens, only then it notices the location is wrong 22:45:19 <TrueBrain> yeah, this is impossible to detect this way 🙂 22:47:02 <TrueBrain> one more thing to try ... one more; after that, we change the default 😛 22:47:13 <TrueBrain> but I rebased, so I have to do a full recompile 22:49:05 <TrueBrain> the Wayland implementation is totally different .. funny to see the amount of difference 22:51:02 <TrueBrain> frosch: if you add `while (SDL_PeepEvents(&ev, 1, SDL_GETEVENT, SDL_MOUSEMOTION, SDL_MOUSEMOTION)) { Debug(misc, 0, "EVENT: {} {} ", ev.motion.x, ev.motion.y); }` after WarpMouseInWindow 22:51:08 <TrueBrain> does it show a new event with the new coordinates? 22:51:50 <TrueBrain> I doubt it does, but it is the last thing I can think of to try 22:51:57 <TrueBrain> ideally btw in WINDOWENTER, if that is not too much to ask 🙂 22:56:43 <TrueBrain> ( I really do not know if a Warp fires an events at all .. possibly it never shows up in the event stream ) 22:57:06 <frosch> i may need to rebase, there are events, but they are the old position 22:57:20 <TrueBrain> yeah, but no new events in the list, the last one, basically? 22:57:30 <TrueBrain> and if you add a `CSleep(10)` before the for loop? 22:57:49 <TrueBrain> as if there isn't an event of the `x + 1` as last item on the list, it simply doesn't fire an event for Warps 22:59:17 <TrueBrain> owh, the docs say it should fire an event .. interesting .. 23:04:47 <frosch> inside SDL_MOUSEMOTION a csleep does not result in any new events 23:05:10 <TrueBrain> I experience the same .. which is a bit odd honestly 😄 23:06:57 <TrueBrain> I mean, there should be new events .. but even after 1 second there aren't .. lol? 23:07:39 <TrueBrain> even without us changing the mouse location, there should just be new events coming in, you would think 🙂 23:08:49 <frosch> same for SDL_WINDOWEVENT_ENTER 23:09:01 <frosch> looks like there are just no new events delivered, while events are processed 23:09:38 <frosch> meaning that the peepevents only peeps into some sdl-internal thing, and does not really fetch new events 23:10:28 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10920: Add: [SDL] change mouse mode if warping doesn't work https://github.com/OpenTTD/OpenTTD/pull/10920 23:10:30 <TrueBrain> so, a bit silly, but how about something like this? Does that work? 23:10:58 <frosch> let's add a SDL_PumpEvents 23:11:15 <TrueBrain> `As this function may implicitly call SDL_PumpEvents(), you can only call this function in the thread that set the video mode.` on the SDL_PollEvent 23:11:19 <TrueBrain> but yeah, try, let's see 🙂 23:11:49 <frosch> yes, that works :p 23:11:56 <TrueBrain> lolz 23:12:14 <TrueBrain> and does it give you the right event? 23:13:16 <frosch> https://cdn.discordapp.com/attachments/1008473233844097104/1114693313384165496/image.png 23:13:16 <frosch> yes 23:13:42 <TrueBrain> so you do get the event of the new location? 23:13:53 <TrueBrain> owh, I do too 23:13:55 <frosch> SDL_GetMouseState is correct after the sdl_pumpevents 23:13:55 <TrueBrain> lolzzzz 23:13:58 <TrueBrain> okay, this is just foobar 23:14:00 <frosch> it does not need the peepevents 23:14:52 <TrueBrain> well, at least I can detect wayland stuff like this 23:15:29 *** Flygon has quit IRC 23:15:51 <frosch> "SDL_GetMouseState + SDL_WarpMouseInWindow + SDL_PumpEvents + SDL_GetMouseState" seems to be enough, no need for peepevents 23:16:08 <TrueBrain> hmm, here on X11 I sometimes get the same x back 23:16:15 <TrueBrain> on startup most of the time 23:16:26 <TrueBrain> not always 23:16:29 <TrueBrain> so false positives 😦 23:16:56 <TrueBrain> `dbg: [misc] 1133 -> 1134` 23:16:56 <TrueBrain> `dbg: [misc] 1190 -> 1190` 23:16:56 <TrueBrain> `dbg: [misc] 1116 -> 1117` 23:16:57 <frosch> SDL_WINDOWEVENT_ENTER does not have the same queue-flush as you just added to SDL_MOUSEMOTION in 10219 23:17:00 <TrueBrain> old x -> new x 23:17:12 <frosch> so you get some events from before the warp 23:17:30 <TrueBrain> I still had a PeepEvents there 23:17:51 <TrueBrain> out of the 20 times, it happens once 23:19:49 <TrueBrain> anyway, at this point it is easier to just hardcode wayland in there 23:19:50 <TrueBrain> 😄 23:22:32 <frosch> i changed the windowenter-warp to 50 pixels to make it easier observable. sometimes the warp now leaves the window again :p impossible to enter 23:22:49 <TrueBrain> lol 23:24:28 <frosch> anyhow. i prefer changing the default, and extend the scrollmode setting description with something like "mouse-locking does not work on devices with absolute pointer positions" or something 23:24:46 <frosch> just unsure whether the default should be LMB or RMB scroll 23:24:51 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10920: Add: [SDL] change default scroll mode to non-mouse-lock https://github.com/OpenTTD/OpenTTD/pull/10920 23:25:03 <TrueBrain> for emscripten it was already RMB, so I went with that 23:26:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10920: Add: [SDL] change default scroll mode to non-mouse-lock https://github.com/OpenTTD/OpenTTD/pull/10920 23:26:16 <TrueBrain> something like this, as description? 23:26:28 <frosch> oh i thought change it for everyone, not just linux 23:26:45 <TrueBrain> we could do everyone, but I read enough ranting threads for one release-cycle 23:26:53 <frosch> mention "touchscreen" is the desc? 23:27:43 <TrueBrain> but, for all OSes? 23:27:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10920: Add: [SDL] change default scroll mode to non-mouse-lock https://github.com/OpenTTD/OpenTTD/pull/10920 23:27:47 <TrueBrain> or Linux only for now? 23:28:47 <frosch> hmm, android port porably has a different default already 23:30:23 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #10920: Add: [Linux] change default scroll mode to non-mouse-lock https://github.com/OpenTTD/OpenTTD/pull/10920#pullrequestreview-1460430651 23:30:29 <frosch> well, who cares, it's only a default setting 23:30:34 <frosch> no existing user should notice it 23:30:55 <TrueBrain> did that ever stop anyone? 23:32:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10140: [Bug]: SDL2 / Wayland: Move viewport with mouse position locked does not lock mouse https://github.com/OpenTTD/OpenTTD/issues/10140 23:33:02 <TrueBrain> well, that was interesting 23:33:09 <TrueBrain> tnx a lot frosch for the remote hands 🙂 23:33:57 <TrueBrain> happy we got all open Wayland bugs sorted now 🙂 23:35:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10889: Backport master into release/13 https://github.com/OpenTTD/OpenTTD/pull/10889#issuecomment-1575263277 23:36:15 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10889: Backport master into release/13 https://github.com/OpenTTD/OpenTTD/pull/10889#pullrequestreview-1460442288 23:36:22 <TrueBrain> I leave the choice to you glx[d] 🙂 23:37:38 <TrueBrain> I put 10920 on auto-merge; zzzz time for me now 🙂 23:43:47 <glx[d]> I'd prefer a new one, I had enough manual fixing in this batch