IRC logs for #openttd on OFTC at 2023-06-03
⏴ go to previous day
02:39:11 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:11:29 *** D-HUND is now known as debdog
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: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: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: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:57:09 <TrueBrain> who would have thought, that you can track a user based on their "memory installed" 😛
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:09:04 <TrueBrain> down to 4 MiB of RAM can be represented now 🙂
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:38:18 <Brickblock1> weird bug I found
09:06:27 <TrueBrain> The nesting becomes a bit much 😛
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:15 <petern> But also, it's in that thread...
10:05:38 <TrueBrain> shows how much I read that 😄
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: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: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:37 <TrueBrain> a typical of: one more thing, that should make it work
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:33:54 <TrueBrain> petern: anything we can do to help #10884 along?
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: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: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: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: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: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: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:22 <Eddi|zuHause> because the situation will repeat, and the wait time will be high every time
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
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:11 <TrueBrain> Previews build binaries 🙂
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:53 <TrueBrain> so providing binaries is simple 🙂
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 (Read error: Connection reset by peer)
13:42:09 *** gelignite has joined #openttd
13:42:11 <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: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:21 <TrueBrain> not even sure why the current limit exists .. 😛
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:51:40 <TrueBrain> petern: that would kill all current GSes 🙂
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:51 <petern> Does it suspend the GS?
13:57:14 <petern> Not sure if it should or not
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: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: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:17:18 *** Johngi[d] has joined #openttd
14:17:53 <TrueBrain> someone is in need of an alter-ego .. wait, they found it!
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:33 <Johngi> nothing illegal, I swear
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 (Closing Window)
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:40 <petern> Discord has its flaws though :/
14:24:04 <JGR> Discord is still vastly more usable than IRC
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: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: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:49 <petern> Company GUI... company GUI...
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: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: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:58 <TrueBrain> the idea of the code is that those buttons are of equal size
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: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: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? 🙂
15:00:16 <petern> The default size for the "Hostile takeover" button is the string width + padding width.
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: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: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:10 <TrueBrain> just see if you agree with that approach 😛
15:12:03 <petern> "all places" -> 5 files, seems unlikely 😉
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: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: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: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: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: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:31:01 <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: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: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: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: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: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: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: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: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:47:13 <TrueBrain> pfff, how are we suppose to know what SDL does and doesn't support 😛
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: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:20:17 <TrueBrain> and at the same time we do an FcInit
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:39 <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:25:38 <TrueBrain> LordAro: feel free to test that out yourself 😛
17:25:41 <TrueBrain> you give a finger ...... 😄
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> 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: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: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:39:03 <TrueBrain> this is silly, almost weird
17:39:47 <TrueBrain> `static FcBool _FcConfigHomeEnabled = FcTrue; /* MT-goodenough */`
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: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: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: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: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: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: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:47 <Rubidium_> TrueBrain: thanks for the reviews
18:18:27 <TrueBrain> the most academic PR in ages
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: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: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: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: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: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 <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:52 <petern> (Yeah, that broken link is on that page...)
18:44:28 <TrueBrain> these hints always pussled me
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: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: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: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 🙂
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: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:10 <petern> Does WSLg itself support it?
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:13:30 *** nielsm has quit IRC (Remote host closed the connection)
19:13:37 <TrueBrain> okay, so `CreateWindow` works, but it doesn't have a surface
19:15:44 <TrueBrain> ah, lol, it does start on a clean config
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: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:24:21 <petern> 114GB free, I guess I could just about install WSL...
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:31:01 <JGR> Brake pads are not really an area where you want to go cheap and cheerful 😛
19:38:26 <sittinbythefire> Eh, back in my day when my pads wore out I just used my shoe 😛
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:48:08 <TrueBrain> You don't pay my subscription!
19:57:47 <TrueBrain> English sucks ..... can we all start speaking ........ I dunno 😛
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: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:08:14 <sittinbythefire> sorry grammar 😛
20:08:27 <TrueBrain> darn it, a bit too late 😛
20:09:10 <TrueBrain> also added that you have to pay for negative balance 🙂
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: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:13 <pickpacket> TrueBrain: should maybe clarify that all the AI company's bikesheds are part of the fixed assets?
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: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: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:17 <TrueBrain> I was thinking about giving every city the AI was located in a penalty, so they don't like you
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: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:17 <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: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: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: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: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: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 <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:01:25 <petern> Ooh #10918 builds, I wonder if it works though.
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:07:16 <TrueBrain> petern: something like 10920, would that be smart? I really don't know 😄
21:10:52 <TrueBrain> and ^^ now in 3 readable commits 😄
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:58 <TrueBrain> ugh, copy/pasting blocks removes that space
21:20:53 <frosch> TrueBrain: DoAcquireCompany transfers both the current money and loan to the new owner. CalculateHostileTakeoverValue seems to contradict that?
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: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: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 (Read error: Connection reset by peer)
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: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: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: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: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:35 <frosch> oh, and 10920 does not work for me
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 (Ping timeout: 480 seconds)
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:28 <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:19 <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> 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:25 <TrueBrain> there is also a WarpMouseGlobal, so we have that going for us
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:43 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
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: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:44 <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:26 <TrueBrain> here, a version that does it only the first time you enter the window
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: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 (Ping timeout: 480 seconds)
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:42 <frosch> petern: while i was typing 🙂
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 (Quit: Stay safe!)
22:27:15 <frosch> i added the mousestate to MOUSEMOTION
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: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> <- 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: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: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: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:12:14 <TrueBrain> and does it give you the right event?
23:13:42 <TrueBrain> so you do get the event of the new location?
23:13:55 <frosch> SDL_GetMouseState is correct after the sdl_pumpevents
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 (Quit: A toaster's basically a soldering iron designed to toast bread)
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: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: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: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: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:25:03 <TrueBrain> for emscripten it was already RMB, so I went with that
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:47 <TrueBrain> or Linux only for now?
23:28:47 <frosch> hmm, android port porably has a different default already
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: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: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
continue to next day ⏵
