IRC logs for #openttd on OFTC at 2021-04-28
⏴ go to previous day
00:50:58 *** JamesRoss[m] has quit IRC (Quit: Client limit exceeded: 8192)
01:18:43 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
01:56:59 *** lobstarooo has joined #openttd
02:03:33 *** lobster has quit IRC (Ping timeout: 480 seconds)
02:03:40 *** lobstarooo is now known as lobster
02:10:39 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:41:13 <milek7> oh, d3d probably returns different pitch for video and animation buffers, and that's why it doesn't work without extra alignment
02:50:56 *** Wormnest has quit IRC (Quit: Leaving)
03:33:18 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
03:34:24 *** WormnestAndroid has joined #openttd
04:06:56 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
04:07:31 *** WormnestAndroid has joined #openttd
04:47:43 *** ChanServ sets mode: +v tokai
04:52:37 *** snail_UES_ has quit IRC (Quit: snail_UES_)
04:54:39 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
05:05:19 *** HerzogDeXtEr has joined #openttd
05:47:01 *** tokai|noir has joined #openttd
05:47:02 *** ChanServ sets mode: +v tokai|noir
05:53:54 *** tokai has quit IRC (Ping timeout: 480 seconds)
06:25:16 *** sla_ro|master has joined #openttd
07:51:59 *** ChanServ sets mode: +v tokai
07:58:48 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
08:02:19 *** andythenorth has joined #openttd
08:43:29 *** andythenorth has left #openttd
08:59:25 *** jottyfan has joined #openttd
08:59:56 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9127: Codechange: allow Connect() to bind to a local address https://git.io/J3JnE
09:00:12 <TrueBrain> a PR that changes absolutely nothing for the current code, but I need C++ experts telling me whether this is okay :)
09:01:56 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9127: Codechange: allow Connect() to bind to a local address https://git.io/J3JnE
09:02:39 *** jottyfan has joined #openttd
09:08:40 <TrueBrain> at least the CI seems to be okay with this
09:09:36 <LordAro> looks fine, not that i'm particularly happy with adding unused code :p
09:10:35 <_dp_> yeah, loooks fine as long as NetworkAddress &bind_address needs to live until the lambda runs
09:10:45 <TrueBrain> honestly, no need to accept this PR LordAro :) I can embed it in another one
09:11:05 <TrueBrain> _dp_: given it is synchronized code, that sure should be the case :D
09:11:44 <TrueBrain> LordAro: honestly, could have PR'd it to my own repo and avoid the noise on the main, looking back :P
09:12:14 <_dp_> yeah, it's unclear from this pr and having hidden lifetime requirements isn't good in general
09:12:25 <TrueBrain> _dp_: it is unclear from this PR?
09:13:04 <TrueBrain> the only reason the lifetime would be an issue, if "func" is handed off to somewhere else in Resolve()
09:13:06 <TrueBrain> which it clearly is not?
09:13:22 <_dp_> well, I don't see you calling Connect anywhere...
09:13:44 <_dp_> I may be missing something as I'm not sure how that even works...
09:14:00 <TrueBrain> lifetime is only an issue if any of the variables would be handed off to somewhere else
09:14:03 <TrueBrain> but this is contained code
09:14:09 <TrueBrain> even stack variables will be valid
09:14:48 <_dp_> yeah, it's kind of ok in C++ I guess
09:14:53 <TrueBrain> so the lifetime of bind_address outside Connect is irrelevant :P
09:15:03 <_dp_> just payng more attention to lifetimes after Rust :p
09:15:12 <TrueBrain> even in Rust this would be valid
09:15:17 <TrueBrain> as the lifetime of "func" would be well defined
09:15:28 <TrueBrain> it might be more clear that it is valid, but that is about it :)
09:20:43 <_dp_> oh, right, there is no asynchronicity there
09:20:53 <TrueBrain> that is what I said earlier, yes :)
09:20:54 <_dp_> kind of expected that from callbacks in network code xD
09:21:19 <TrueBrain> the whole thing is threaded, if that makes you feel any better :)
09:23:05 <peter1138> Tron isn't around to revert unused code.
09:24:37 <peter1138> That is literally what halted my custom-bridge-heads code back in the day.
09:25:06 <peter1138> I did a preliminary code saparation to prepare, and... it got reverted.
09:25:25 <peter1138> (Not straight away mind)
09:25:52 <peter1138> git PRs with multiple commits are nicer in that respect, I guess.
09:27:06 <peter1138> It was long before bridges-over-anything though (which was Tron's work and what caused him to leave...)
09:27:20 <Rubidium> even git PRs with single commits would have been nicer, as it would at least required someone else to agree with the changes
09:27:45 <TrueBrain> we tried so many things for reviews in SubVersion time
09:27:49 <TrueBrain> but some people just didn't care ..
09:28:02 <TrueBrain> so yeah, PRs are a nice increase in avoiding people doing what-ever-the-fuck-they-want :D
09:28:26 <TrueBrain> Tron especially was known for just reverting when he didn't see the point in -something-
09:28:41 <TrueBrain> mostly without telling the original author, ofc :)
09:29:03 <TrueBrain> anyway, another C++ thing .. this time in the form of a: which one is better, does it matter?
09:30:19 <TrueBrain> first makes a lot of code a lot easier to write :P As I can just use AF_INET and AF_INET6 as keys
09:30:45 <TrueBrain> guess memory-wise it really doesn't matter, as it is rare there is anything in this map
09:31:00 <Xaroth> I have no idea what-so-ever on the actual implications, but the first form looks a lot more readable.
09:31:02 <Rubidium> the other doesn't seem to be equivalent
09:31:24 <TrueBrain> Rubidium: it doesn't? I can store 2 values in there per token, not?
09:31:54 <_dp_> TrueBrain, those maps aren't the same
09:31:59 <_dp_> and you can use pair as a key
09:32:06 <Rubidium> that feels like misusing pair
09:32:19 <TrueBrain> Rubidium: that it is, I guess
09:32:33 <Rubidium> as you'd basically say: okay, the first one is IPv4 and the second IPv6
09:32:58 <peter1138> When IPv8 comes out, whatcha gonna do?
09:33:05 <peter1138> Maybe you need to support IPX?
09:33:18 <TrueBrain> peter1138: std::tuple! :P
09:33:27 <LordAro> pretty sure IPv8 is already a "thing"
09:33:34 <Rubidium> maybe have it more explicit with a struct TBN { SomeClass *ipv4; SomeClass *ipv6; } and use std::map<std::string, TBN>
09:33:45 <peter1138> It's not misusing a pair really, a pair is just holding two values.
09:33:53 <TrueBrain> Rubidium: fair; codewise a nag .. :D
09:34:01 <peter1138> But yes, a struct like that would be nicer.
09:34:03 <TrueBrain> but you are right, explicit is better, so a struct would be better
09:34:08 <TrueBrain> I still rather use the map :D
09:34:12 *** lobstarooo has joined #openttd
09:34:20 <peter1138> Is there anything wrong with the map way?
09:34:20 <TrueBrain> otherwise I need a ton of if() statements around "family"
09:34:28 <TrueBrain> not that I know, but that is kinda why I ask honestly :)
09:34:51 <peter1138> I think it's preferable to use std classes
09:35:06 <_dp_> what is misusing is having a map for 2 values :p
09:35:06 <Rubidium> LordAro: IPv7 and IPv8 are even proposals from the previous millenium
09:35:22 <TrueBrain> k, tnx, enough input for me to continue work :)
09:35:26 <peter1138> It's probably safe to assume they've been test more than any custom code :)
09:35:54 <LordAro> a map does seems a bit much for 2 values indeed
09:37:07 <TrueBrain> I have to look how efficient std::map is memory, wise .. but really .. for the 2 values per client connecting at the same time to a server .. maybe I should not worry so much :D
09:38:41 <_dp_> not sure map will use rb-tree for just 2 values but it's a massive overkill anyway
09:38:51 *** lobster has quit IRC (Read error: Connection reset by peer)
09:38:53 *** lobstarooo is now known as lobster
09:40:01 <peter1138> Is std::map<std::pair<int, std::string>, SomeClass *> worse?
09:40:11 <peter1138> (Or even possible...)
09:40:16 <TrueBrain> I need to be able to remove all entries based on a token :)
09:40:49 <LordAro> peter1138: as long as the type can be passed to std::hash, i think you can use whatever
09:40:57 *** tokai|noir has joined #openttd
09:40:57 *** ChanServ sets mode: +v tokai|noir
09:40:58 <_dp_> map<string, pair/struct> looks like the most logical solution here
09:41:10 <_dp_> LordAro, since when does rb-tree need hash? :p
09:41:13 <TrueBrain> but it is okay, I know what to do for now :) At least it is good to read I am not missing something obvious here :)
09:41:18 <LordAro> there's a specific exception in the standard about "you're allowed to override namespace std {} in this particular case"
09:41:28 <LordAro> _dp_: i might be getting my containers confused
09:42:38 <_dp_> LordAro, yeah, unless I'm forgeting smth map should only need operator<
09:42:45 *** andythenorth has joined #openttd
09:42:49 <_dp_> hash is for unordered_map or whatever hasmap is called in c++
09:43:13 <_dp_> well, mb operator== as well
09:43:26 <TrueBrain> this->stun_handlers[token][family] <- looks pretty at least :)
09:46:41 <_dp_> TrueBrain, also creates an empty element if there wasn't one ;)
09:47:48 *** tokai has quit IRC (Ping timeout: 480 seconds)
09:48:43 <_dp_> [] on map is pretty but hardly ever useful in reality xD
09:49:00 <_dp_> since it's not efecient neither for getting nor for setting :p
09:51:04 <peter1138> Hmm, is there anything I can do with a SHeevaplug...?
09:52:09 <peter1138> Isn't getting by key the entire point of a map?
09:52:09 <_dp_> LordAro, [] calls default constructor which is hardly ever desirable
09:52:10 <orudge> I have one of those kicking about too I think
09:52:13 <orudge> It's about 10 years old tohugh
09:52:15 <orudge> no idea if it still works
09:52:22 <_dp_> not a big overhead in some cases I guess but still
09:52:27 <orudge> Also a first-gen Raspberry Pi
09:52:29 <LordAro> _dp_: for creating, sure
09:52:34 <LordAro> that's almost never desirable
09:52:52 <LordAro> but getting/setting is fine
09:52:52 <peter1138> I have a Pi 1B, I believe is significantly more powerful than a Sheevaplug.
09:53:43 <_dp_> LordAro, for getting it will add T() if element does not exist which is harly ever useful
09:54:10 <_dp_> and if you run find() before you already have an iterator
09:54:50 <peter1138> Oh, 1.2GHz ARM, not that bad then.
09:55:23 *** andythenorth has left #openttd
09:59:34 <_dp_> with [] map is basically a python defaultdict
10:08:53 <_dp_> lol, on a second thought, python is more effecient because it has __setitem__ and doesn't need to call T()
10:29:09 <peter1138> Rewrite OpenTTD in Python when?
10:34:34 <LordAro> Alberth? is that you?
10:35:07 <LordAro> (he was always a fan of games where all the logic was written in scripts)
10:35:21 <peter1138> Okay, so with centre vs center, it's obvious that centre is correct. But centring just looks odd.
10:35:23 <TrueBrain> it has proven to be a solid approach to games :)
10:36:56 <peter1138> That's higher than I expected.
10:37:47 <peter1138> LordAro, it rained on me yesterday ;(
10:38:07 <peter1138> Only for about 4 minutes though. I hid under a tree.
10:38:29 <LordAro> i got snowed on a couple of weeks ago
10:38:38 <peter1138> But it's good to remind me that light rain doesn't have to mean stay indoors...
10:38:41 <LordAro> disappeared quite quickly though
10:38:52 <peter1138> Also far less saddle sore this time.
10:40:03 <LordAro> TrueBrain: are you looking for general correctness, or typos etc?
10:40:19 <TrueBrain> nah, you can do that when I PR this; I am more interested if you can follow what this does
10:40:26 <TrueBrain> you wanted me to document the STUN stuff; this is it :P
10:40:58 <TrueBrain> now I need to know if this is enough words, or if I need more :D
10:41:19 <LordAro> it's very high level, but i think it makes sense
10:41:35 <TrueBrain> its protocol level :)
10:46:56 <TrueBrain> okay, lets add TURN support to the clients too .. we can always decide not to roll that out in the GC
10:47:09 <TrueBrain> but at least means we don't have to create a new build if we decide it is okay :)
10:50:29 *** jottyfan has joined #openttd
10:51:22 *** jottyfan has joined #openttd
10:59:03 <orudge> Hey look, apparently Microsoft has introduced what are basically 'fat binaries' on ARM64 Windows to support AMD64 emulation. TrueBrain will be pleased :D
10:59:12 <orudge> Doesn't affect OpenTTD since we have an ARM64-native version anyway
10:59:53 <orudge> but instead of having a c:\windows\system32 and a c:\windows\system32amd64 type thing, they've made the DLLs 'ARM64X', which appear to be some kind of hybrid ARM64/AMD64 DLLs
11:03:13 <TrueBrain> Bandwidth and diskspace is free after all, right? :p
11:03:33 <orudge> Also seems to be referred to as "ARM64EC", and it looks like .exes can be built that way too
11:03:43 <orudge> So we could have a universal OpenTTD ARM64/AMD64 binary... ;)
11:03:58 <TrueBrain> Uuuugggggghhhhhhhhhhhhhh
11:04:14 <orudge> TrueBrain: to be fair, from an OS perspective, this in theory ought to take up less space than having two duplicated system32 directories (three if you include x86 too)
11:04:30 <TrueBrain> With emulation, very true
11:05:14 <orudge> Presumably just the code segments are duplicated, with data and resources being stored in a single copy, but who knows
11:20:19 <peter1138> It would be nearly salad time, but I don't have any lettuce :(
11:20:26 <peter1138> Maybe it's pizza time instead?
11:38:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #9127: Codechange: allow Connect() to bind to a local address https://git.io/J3JnE
11:38:27 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9127: Codechange: allow Connect() to bind to a local address https://git.io/J3Jpu
11:55:03 *** argoneus has quit IRC (Quit: Ping timeout (120 seconds))
11:55:14 *** argoneus has joined #openttd
12:00:12 *** andythenorth has joined #openttd
12:03:00 <TrueBrain> okay, so what is the next problem .. ah, yes, "by-ip" connect or "by-joinkey" connect
12:03:04 <TrueBrain> and coding that in a clean way ..
12:03:36 <andythenorth> oof python OpenTTD
12:04:10 <andythenorth> also what is lunch?
12:07:37 <andythenorth> cheese, it's a bit more vegetarian than chicken I think?
12:27:55 <peter1138> Step 2: prepare release
12:28:19 <TrueBrain> where is ??? and profit?
12:28:22 <peter1138> Step 4: holy shit that was 291 commits, 364 change files, 364 changed files
12:28:39 <peter1138> No idea what that was split on new lines :(
12:28:44 <peter1138> That's a lot of changes :p
12:29:19 <peter1138> Quite a lot of file-moving I think, rathern than actual changes, though.
12:30:00 <peter1138> TrueBrain, explict "join by id" or "join by key", or try to detect?
12:31:16 <TrueBrain> I made it a class with 2 subclasses and a type
12:31:21 <TrueBrain> I want for a classic approach :)
12:31:30 <TrueBrain> means we can also add Steam and Discord if we want :P
12:31:39 <peter1138> So my scrolling-panel "hack" is actually working quite well now.
12:31:55 <peter1138> But making it scroll in both directions is a little fiddly with the window layout.
12:32:43 <TrueBrain> static_cast<ServerAddressDirect &>(this->server_address).address;
12:32:47 <glx> I quickly tried 1.11.1 steam version on an old laptop (i3+GT520MX), too bad it didn't crash
12:32:49 <TrueBrain> guess there is a cleaner way to do this, but what-ever
12:32:57 <peter1138> I'm wondering if I could/should make the extra container and scrollbar widgets be implicit, i.e. automatically created instead of having to be explicitly in the tree.
12:33:36 <TrueBrain> peter1138: everything is explicit atm, maybe better keep it that way?
12:33:44 <peter1138> TrueBrain, it's actually not.
12:33:53 <peter1138> There's an implicit vertical container on every window!
12:34:18 <TrueBrain> but if you make it implicit, the caption also scrolls, I guess? :P
12:34:49 <peter1138> No I added a specific widget that scrolls, anything outside that widget is static like normal.
12:35:12 <TrueBrain> ah .. well, in that case, shrug :D
12:35:17 <peter1138> It is actually possible to make any widget with a scrollbar scroll the contents, but of course none of the existing code is geared for that.
12:35:50 <peter1138> I looked at adding iterator methods to make doing the scrollbar stuff eaiser
12:36:04 <peter1138> But so much of the code is slightly different and custom for each instance... pain in the ass.
12:36:53 <peter1138> But I can do `for (auto &it : this->vscroll->Iterate(this->list)) {` and it'll go through only the visible items.
12:38:12 <TrueBrain> in many cases that could already be an improvement
12:38:26 <TrueBrain> but that forces a list, I guess
12:38:31 <glx> in many cases the differences are very minor
12:38:33 <TrueBrain> I can also imagine vscroll being used for more free-form stuff
12:38:36 <TrueBrain> or is your new widget for that?
12:39:00 <TrueBrain> well, hmm, nevermind what I just said
12:39:07 <TrueBrain> I forgot you cannot draw a string partial, can you?
12:39:10 <TrueBrain> (as in, height-wise)
12:39:43 <TrueBrain> yeah, "About OpenTTD" also just "appears"
12:39:52 <glx> in theory it should be possible to partially draw strings
12:39:54 <TrueBrain> one of the weirder quirks of the Window system :P
12:40:03 <peter1138> TrueBrain, not a list, any container with a indexed iterator.
12:40:08 <peter1138> So, er, yeah, I guess a list :p
12:40:17 <glx> but would need an intermediate buffer for the string
12:40:22 <TrueBrain> peter1138: yeah, but what I was thinking that it means a resize_height > 1, basically
12:40:29 <TrueBrain> I forgot that our system works like that
12:40:31 <glx> draw, in the buffer, crop, blit
12:40:43 <TrueBrain> I always assume you draw on a widget buffer, and it just crops out what is out-of-bounds
12:41:14 <peter1138> DrawPixelInfo can and does crop
12:41:21 <peter1138> (And it's what I use)
12:42:31 <peter1138> TrueBrain, if you want smooth scrolling of any scrollable list, yes, that would need something else, although it wouldn't be hard to make a similar construct that returns the visible range at a pixel level.
12:42:39 <peter1138> Assuming all items are the same size.
12:43:18 <TrueBrain> we had some talks about using a buffer-drawn window system a few weeks back
12:43:33 <TrueBrain> means you can basically make textures out of the windows
12:43:36 <TrueBrain> and moving them around is trivial
12:43:40 <peter1138> There are cases currently where there are two lists. The capacity is both put together, when it gets to the end of one, it continues with another. Code is simple, but turning that into a simple iterator operation is not.
12:43:41 <TrueBrain> (and doesn't require a lock on the game-state)
12:44:10 <peter1138> That's a pretty separate concern though, I think?
12:44:19 <TrueBrain> it could go hand-in-hand with scrolling
12:44:24 <TrueBrain> as basically you draw the whole widget once
12:44:27 <TrueBrain> as if there is no scrollbar
12:44:29 <TrueBrain> and apply that after-the-fact
12:44:52 <TrueBrain> only horrible for huge long lists, I guess
12:44:58 <peter1138> If you have 1000 vehicles that might not be so optimal.
12:45:22 <peter1138> But still, have a separate buffer so you only ever need to update things when they change, rather than because something else changed...
12:45:40 <peter1138> Windows as separate buffers does make sense.
12:46:11 <TrueBrain> just mentioning there was chat about that :P nielsm brought it up I think
12:46:20 <TrueBrain> hmm ... NOT_REACHED when joining a server, oh-oh
12:46:31 <TrueBrain> peter1138: that would be pretty awesome :D
12:46:43 <glx> new enum value not used ?
12:47:08 <peter1138> Heck, all windows could be pop-out, tbh.
12:47:09 <TrueBrain> hmm ... NetworkAddress that is neither AF_INET nor AF_INET6
12:47:12 <_dp_> oh, btw, I noticed minimap window is redrawn as vehicles move under it
12:47:28 <peter1138> _dp_, because that bit of the screen gets marked dirty.
12:48:06 <_dp_> does it not matter that it's completely covered with another window?
12:48:24 <peter1138> I don't think the window system cares currently.
12:48:38 <glx> ah yes there are more possible values than AF_INET and AF_INET6
12:48:50 <TrueBrain> glx: I think in this case I just forgot to initialize some memory somewhere :D
12:49:20 <glx> because usually they are zero initialised
12:51:07 <peter1138> Me: "Too many games on Steam, bloody humble bundle". Also me: doesn't cancel subscription...
12:51:47 <peter1138> I'm surprised we still have any FOR_ALL_... stuff left.
12:55:42 <TrueBrain> lol, sometimes it is fun to see what random shit can be in a buffer
12:55:52 <TrueBrain> hostname = "\000\000DC\000\000\000\000\061\000\000\000\000\000\000\000The server you joined last time:\000\000\000\000\000\221\001\000\000\000\000\000\000\340\317lXUU\000\000\020\200DXUU\000"
12:56:09 <TrueBrain> pretty sure that isn't valid :D
12:56:26 <peter1138> Starts with \0, so it probably is.
12:56:41 <TrueBrain> address_length = 1059205166
12:57:24 <glx> missing stuff in constructor ?
12:59:03 <_dp_> when building a desktop after 10 years on laptops I though I'd finally play some modern games
13:00:29 <Timberwolf> GPU shortage due to Ethereum, storage shortage due to Chia... truly it is the age of the OpenTTD PC.
13:00:37 <glx> depending on where I look it says 415 (in profile) or 449 (in library)
13:01:23 <glx> and gog galaxy says 819 (regrouping almost all stores)
13:02:49 <_dp_> I deliberately built a pc while crypto was down
13:03:00 <_dp_> didn't expect covid ofc but worked out well enough xD
13:03:23 *** andythenorth has quit IRC (Quit: andythenorth)
13:06:48 <peter1138> My i7 is old now :(
13:06:56 <peter1138> My GPU is obsolete...
13:07:04 <peter1138> Clearly I need a new PC?
13:07:44 <_dp_> peter1138, just optimize the game more ;)
13:07:51 <glx> I did a small upgrade on my outdated PC, but it's still outdated
13:08:48 <peter1138> 64GB was almost excessive...
13:09:14 <TrueBrain> right .. found where memory wasn't copied ... oops :D
13:09:22 <TrueBrain> now how do you do this correctly in C++ .... pam pam pammmm
13:10:16 <peter1138> I have a VM that kept running out of memory. Turns out it was just because it had dynamic memory scaling on, and it was never giving up memory.
13:21:49 <TrueBrain> hmm ... C++ still confuses me sometimes :P
13:23:13 <TrueBrain> and in this case specific, when an instance is copied
13:23:21 <TrueBrain> and which ctor is used for that, when using subclasses
13:27:40 <_dp_> constructors aren't virtual
13:30:08 <glx> are you copying subclass object into parent class object ?
13:31:20 <TrueBrain> glx: I do not understand what you ask there :D
13:31:51 *** snail_UES_ has joined #openttd
13:32:56 <TrueBrain> ah, after some trickery finally found the source of my issue .. pff, took long enough .. had to add a virtual function to the parent class that wasn't set, to see where I was making a copy :P
13:33:48 <TrueBrain> which was not intended to do in the first place
13:44:18 <peter1138> I wonder if this old machines that have issues with OpenGL (probably OpenTTD's bug) actually support DirectX 11.
13:53:47 <TrueBrain> random lego images? That the new thing? :D
13:54:18 <peter1138> It's significant for Lego fans ;)
13:55:40 <peter1138> Also wasn't someone making a brickland baseset?...
14:02:26 *** ChanServ sets mode: +v tokai
14:03:25 <TrueBrain> the main issue I am having, ServerAddress has nothing to do with how it is used (so having functions and overload that in ServerAddressDirect will be a nightmare)
14:04:24 <TrueBrain> and I didn't want to store NetworkAddress in ServerAddress, as there will be 1 or 2 more subclasses of it, each with their own storage
14:06:44 *** Speeder has joined #openttd
14:07:30 <LordAro> TrueBrain: you need some const specifiers on your member functions
14:07:36 <LordAro> other than that, seems fairly normal
14:07:44 <TrueBrain> LordAro: I have no clue what you mean :P
14:07:51 <TrueBrain> owh, just adding "const"?
14:07:59 <TrueBrain> yeah, haven't done that yet
14:08:14 <TrueBrain> well, mainly the std::unique_ptr is a bit painful..
14:08:24 <LordAro> you got as far as adding a separate function with dirty const_cast rather than just adding it to CompareTo :p
14:08:46 <TrueBrain> LordAro: ironically, a copy/paste of code slightly above ;)
14:09:00 <TrueBrain> I am a hero in copy/paste :D
14:09:03 <TrueBrain> but I will take care of that :)
14:09:14 <LordAro> yeah, that does horrendous caching stuff, which breaks things
14:09:17 <LordAro> i've looked at that before
14:09:19 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
14:09:26 <LordAro> s/caching/lazy resolving/
14:09:34 <TrueBrain> NetworkGameList *item = NetworkGameListAddItem(std::move(ins_item->address)); <- just these things
14:09:42 <TrueBrain> scare me a bit .. made me wonder if this is a valid solution
14:09:59 <LordAro> as long as you don't use ins_item afterwards, is fine
14:10:10 <TrueBrain> ins_item is used, ins_item->address isn't
14:10:21 <TrueBrain> but it is free'd, so I have to double-check it is not also still freeing the memory
14:11:02 <TrueBrain> if you have moved an unique_ptr, does it automatically know that? or do I need to release it or something?
14:14:11 <_dp_> hm, TCPBindConnector and TCPServerConnector in comment but TCPBindConnect_e_r and TCPServerConnect_e_r for actual type :p
14:14:51 <LordAro> TrueBrain: might want to call release()
14:15:15 <TrueBrain> LordAro: yeah, that part wasn't really clear to me, but yeah, will do :)
14:15:29 <TrueBrain> not even sure this works btw .. but I was hoping to trigger a: no, you can also just do this
14:15:39 <LordAro> but having an object that's partially valid is ...weird
14:15:48 <TrueBrain> it is free'd at the end of that function
14:16:05 <TrueBrain> so it is pretty contained
14:16:09 <TrueBrain> but yeah, it still is meh :)
14:22:20 <_dp_> doesn't unique_ptr become null after it's moved?
14:22:58 <_dp_> like, that't kind of the whole point of unique_ptr
14:26:01 <TrueBrain> for GCC this also holds true
14:37:15 <TrueBrain> peter1138: that moment you add a debug in DrawWidget, and realise HOW OFTEN we redraw, even with no change :P
14:37:20 <TrueBrain> just because .. dirty-markers
14:40:45 <peter1138> There's some places where a whole window is SetDirty instead of just a widget.
14:41:35 <peter1138> I will split up #9087 at some point, as lots of that is actually stuff that can be a separate fix.
15:55:30 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TEL
15:56:01 * Rubidium awaits build failures
15:57:07 <peter1138> Ordered a €30 part for my rudder pedals. Plus €20 shipping via DHL. I wonder how much I'll be stung with import duty...
15:59:40 <LordAro> ooh, std::string_view
15:59:59 <peter1138> Weather's a bit meh.
16:00:28 <LordAro> i *think* that's supposed to be used "as is", rather than const & - as it can use move semantics and copy ellision without it
16:00:33 <LordAro> and complicated things like that
16:14:48 *** Progman has joined #openttd
16:24:08 <peter1138> Does the textfile viewer support other fonts?
16:24:48 <LordAro> mono font in the config file, iirc
16:24:59 <peter1138> I mean, other than FS_MONO.
16:25:18 <nielsm> it should be able to use the others too
16:26:24 <nielsm> I haven't tested but at least with my changes in the help window PR it should be possible to use another font
16:27:04 <peter1138> Where can I find an example of a readme file that breaks the window?
16:27:47 <peter1138> How do I even view that in game?
16:27:53 <peter1138> Or does it need that PR?
16:28:33 <LordAro> copy it into some existing download item
16:28:33 <nielsm> you can just put a newgrf package with a huge textfile and view it from the newgrf window
16:30:24 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TEL
16:30:40 <nielsm> my help window PR hacks around it by just limiting the number of lines read in from changelog...
16:33:29 <LordAro> and my #8006 does... things
16:33:50 *** frosch123 has joined #openttd
16:34:02 <peter1138> Obvious solution is to scroll by lines, not pixels.
16:34:22 <peter1138> But... still breaks :D
16:34:28 <LordAro> until you get someone with a file with 65k lines :p
16:34:38 <nielsm> that gets a bit more troublesome when you have line breaking on too
16:34:50 <peter1138> The changelog is only ~6000 lines
16:35:25 <Rubidium> just load the executable as text file and see how that goes
16:35:55 <LordAro> an interesting sort of fuzz test
16:37:45 <peter1138> WrapText on changelog.txt in debug mode is... longwinded.
16:37:59 <peter1138> Oh jesus rendering is... no.
16:38:18 <peter1138> Abhout 2 seconds per frame.
16:38:32 <peter1138> I mean, it does render the whole file every draw.
16:41:55 <nielsm> yeah that's one of the things I improved in my PR
16:42:09 <nielsm> it caches the broken height of each line
16:44:42 <peter1138> Ah but the relevant change is merged with other stuff.
16:51:41 <TrueBrain> ah, right, forgot why I wanted to refactor GameList ... it uses calloc :)
17:01:21 *** gelignite has joined #openttd
17:03:42 <TrueBrain> [net] [tcp/game] received illegal packet type 6 from client 2
17:03:49 <TrueBrain> Client #2 is dropped because it took longer than 100 ticks to start the joining process
17:03:53 <TrueBrain> eeeuuuhhhh .... lol?
17:04:09 <TrueBrain> I expected the socket to be closed if there was an illegal packet
17:06:30 <TrueBrain> there are 2 flows to deal with invalid packets .. 1 closes the connection, the other does not
17:11:24 *** lobstarooo has joined #openttd
17:13:18 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:14:21 <peter1138> Oof, it compiled...
17:15:45 *** lobster has quit IRC (Read error: Connection reset by peer)
17:15:54 *** lobstarooo is now known as lobster
17:17:30 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3Tdu
17:20:59 *** andythenorth has joined #openttd
17:23:26 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3Tb7
17:24:36 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TNt
17:26:21 *** Wormnest has joined #openttd
17:31:22 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TAw
17:33:36 *** Gustavo6046_ has joined #openttd
17:33:38 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9129: Fix b3003dd1: swap SERVER_GAME_INFO with CLIENT_GAME_INFO https://git.io/J3TAx
17:34:46 *** Gustavo6046 has quit IRC (Remote host closed the connection)
17:34:46 *** Gustavo6046_ is now known as Gustavo6046
17:38:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9130: Change: use TCP for everything except for master-server and initial server scan https://git.io/J3Txp
17:38:55 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TpT
17:43:30 <Rubidium> frosch123: regarding the ReadDWordAsString, I guess I should just copy 4 bytes from the reader into the buffer and it's big endian aware, right? Or does it then need to be reversed?
17:45:51 <frosch123> "just copy" should be fine
17:49:32 <andythenorth> Timberwolf can I abandon my ship grfs without guilt now? :D
17:49:34 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #9131: Fix: 'Cache' top and bottom lines of textfile viewer to avoid overdraw. https://git.io/J3TjR
17:49:54 <peter1138> andythenorth, stop it. Get some 1x5 Lego instead.
17:53:35 <DorpsGek> - Update: Translations from eints (by translators)
18:04:59 *** andythenorth has quit IRC (Quit: andythenorth)
18:05:10 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TEL
18:08:59 *** andythenorth has joined #openttd
18:11:18 *** tokai|noir has joined #openttd
18:11:18 *** ChanServ sets mode: +v tokai|noir
18:13:19 *** andythenorth has quit IRC ()
18:14:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9130: Change: use TCP for everything except for master-server and initial server scan https://git.io/J3Txp
18:15:17 <peter1138> Loading a 52.7MB text file takes a while.
18:18:18 *** tokai has quit IRC (Ping timeout: 480 seconds)
18:18:35 <TrueBrain> you sound surprised :D
18:19:28 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #9131: Fix: 'Cache' top and bottom lines of textfile viewer to avoid overdraw. https://git.io/J3TjR
18:20:04 <TrueBrain> its funny we have last_host and last_port as setting
18:20:10 <TrueBrain> why not just last_server as "ip:port" :D
18:22:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9130: Change: use TCP for everything except for master-server and initial server scan https://git.io/J3kLk
18:22:50 <TrueBrain> owh, because of the way it is used .. that is just lazy
18:24:13 <TrueBrain> shouldn't be too difficult to make pretty
18:25:29 <frosch123> we should use std::regex more often :p
18:25:46 <TrueBrain> the rabbithole that is called network code is endless deep ... but tomorrow is another day
18:25:53 <TrueBrain> frosch123: add more problems, you say? :D
18:31:05 <frosch123> [20:25] <TrueBrain> frosch123: add more problems, you say? :D <- everytime you ask that, i want to make a real insane statement. but then i get scared of getting kicked like some X
18:31:29 <TrueBrain> if it happens more often, you will never know what happens till you try it
18:31:30 <DorpsGek> TrueBrain: TrueBrain
18:31:39 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #9131: Fix: 'Cache' top and bottom lines of textfile viewer to avoid overdraw. https://git.io/J3TjR
18:31:55 <peter1138> Dear cl.exe, please give me at least some warnings...
18:31:55 <frosch123> i think we should port the gui to qt, with html text formatting
18:32:20 <TrueBrain> that second part .. lol
18:32:54 <TrueBrain> at least they solved 90% of your current issues
18:33:25 <TrueBrain> frosch123: I already have the first part of HTML if you like :)
18:33:43 * TrueBrain is happy with his sketching tool for OpenTTD widgets :)
18:35:28 *** andythenorth has joined #openttd
18:35:38 <_dp_> can you embed your tool to let the game do widget spec parsing in runtime? xD
18:37:01 <frosch123> i wonder what that "world machine" is usually used for
18:37:52 <frosch123> export for unity and unreal engine, i see
18:38:47 <frosch123> "simulate instead of sculpt" <- oh yeah, i wonder whether someone would sculpt a landscape from clay, 3d-scan it, and then play it in ottd
18:43:42 <TrueBrain> so .. someone emailed abuse@ to promote their localization business
18:44:41 <frosch123> again? i already deleted two of those
18:45:37 <frosch123> TrueBrain: the bananas-migration mail from yesterday was funny
18:45:59 <frosch123> the link to the github profile linked to somewhere else than the text said, and i just clicked it :p
18:46:23 <TrueBrain> so you are now phished? :D
18:46:49 <frosch123> i guess so, noone warned me about clicking it
18:47:03 <TrueBrain> seems something sensored the URL for you
18:47:09 <TrueBrain> would it be his password? :D
18:47:13 <TrueBrain> that is auto-masked it :P
18:47:18 <frosch123> no, i think it's from our template
18:47:56 <frosch123> so the mail program converted it to an url first, and then they only edited the title
18:53:08 <TrueBrain> best crash report evah
18:53:28 <TrueBrain> I will let James take care of this
18:54:24 <_dp_> well, it does have dmp though
18:54:34 <TrueBrain> it didn't when he opened it
18:54:38 <TrueBrain> so that is an improvement :)
18:58:29 <TrueBrain> still nobody answered if the nightly fixes their issue :P
18:58:31 <TrueBrain> which is annoying :D
19:10:19 <glx> yeah, it's a simple question
19:11:02 <TrueBrain> I mean, I am happy they report bugs
19:11:06 <TrueBrain> just ... without follow up ..
19:11:23 <TrueBrain> we should complain more :P
19:11:28 <frosch123> it's also funny that noone on irc dares to admit they have a intel card :p
19:11:44 <TrueBrain> so 1.11.2 this weekend? :)
19:12:19 <frosch123> oh, they edited their comment again
19:12:32 <glx> well I tried on the laptop (i3 and GT520MX, but 1.11.1 just worked for me)
19:12:33 <frosch123> does starting the nightly once disable opengl, so that the stable also runs then?
19:13:25 <TrueBrain> to not give the nag screen every startup
19:14:56 <glx> ah it was a boostrap related crash
19:15:32 <glx> so maybe opengl is not disable in the end
19:16:06 <_dp_> "i have to use an older version for multiplayer, because the net code is broken in the latest version and cause constant drops"
19:17:25 <glx> the option already exists
19:17:47 <glx> not a direct option, but an effect of -c
19:18:50 <glx> and net code didn't change, so I guess it's a "too big" map issue
19:19:45 <peter1138> There's his "report" about the network issue.
19:21:06 <andythenorth> players gonna player
19:22:33 <glx> no useful info in the report
19:24:07 <_dp_> there is some, just not enough :(
19:25:06 <glx> no indication of error messages
19:25:59 <_dp_> I understood it as client gets "no data received from server in x seconds" counter and then disco
19:28:11 <_dp_> can someone summon James to forum? xD
19:31:01 <glx> and I checked the dmp to be sure :)
19:31:16 <TrueBrain> so we close all the duplicates now? :D
19:31:58 <TrueBrain> I mean, if one is confirmed fix ... so should the others, not? :D
19:38:51 <Timberwolf> andythenorth: but 2x!
19:41:43 <frosch123> i mean, not sure what's there to check :p
19:41:44 <TrueBrain> doesn't happen often :D
19:41:57 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain merged pull request #95: Change: migrate OpenTTD user rsprta to GitHub user radek-sprta https://git.io/J3enQ
19:42:01 <frosch123> TrueBrain: it's fine, you had a free day yesterday :)
19:42:16 <TrueBrain> and yeah, not much to check .. it just means we are both responsible I guess :D
19:42:34 <frosch123> i have a dutch guy in my team at work, i don't miss any dutch holidays anymore :)
19:43:38 *** andythenorth has quit IRC (Quit: andythenorth)
19:45:08 *** andythenorth has joined #openttd
19:46:30 <peter1138> I have an British guy in my team. Unfortunately it's me. Last week was my first week off...
19:48:51 *** erle- has quit IRC (Quit: Leaving)
19:50:49 *** heffer__ is now known as felix
19:51:22 *** felix is now known as Guest2591
19:52:12 *** Guest2591 is now known as felixka
19:55:10 *** felixka is now known as felix
20:02:27 *** felix has quit IRC (Quit: felix)
20:05:00 <milek7> does blitters have any row pitch alignment requirements?
20:07:54 <peter1138> andythenorth, it makes the massive changelog I wrote alarming...
20:08:03 <peter1138> All those fixes... after for things I got wrong? :/
20:09:17 <frosch123> milek7: uint32 are aligned, otherwise drawing with clipping implies that there are no other alignment requirements
20:10:03 <frosch123> hmm, my reasoning is wrong. but i still doubt there is any larger alignment on the pitch
20:20:58 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:24:46 <andythenorth> so Tyler might patch base vehicles to have refittable classes
20:24:52 <andythenorth> to prevent me nerfing FIRS
20:26:30 <frosch123> i also considered that, but didn't do it yet
20:27:51 <andythenorth> Tyler is prepared to take the forum flak
20:28:02 <andythenorth> which is the main reason I didn't want to try it
20:28:35 <frosch123> i am not on forums :p
20:28:46 <frosch123> but irc whining is also strong
20:29:17 <andythenorth> yes but somehow it doesn't matter :)
20:29:20 <andythenorth> can engage or ignore
20:30:33 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #9133: Fix: Incorrect vertical alignment of icon and text in DropDownListIconItem. https://git.io/J3kzW
20:30:54 <andythenorth> did I finish my var 4E patch yet?
20:31:11 <andythenorth> maybe it needs docs for copy-paste-to-wiki
20:33:03 <andythenorth> writing docs is ugh
20:34:09 <frosch123> andythenorth: jgr had a valid comment on MAX_YEAR
20:34:29 <frosch123> grep for date_of_last_service, and apply the same logic to the new var
20:34:30 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #9133: Fix: Incorrect vertical alignment of icon and text in DropDownListIconItem. https://git.io/J3kzA
20:35:59 <andythenorth> looks like L214 in date.cpp
20:37:17 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
20:39:36 <DorpsGek> [OpenTTD/OpenTTD] andythenorth updated pull request #9093: Feature: [NewGRF] vehicle var 0x4E, 'date of last station departure' https://git.io/JOScW
20:40:48 <DorpsGek> [OpenTTD/OpenTTD] andythenorth commented on pull request #9093: Feature: [NewGRF] vehicle var 0x4E, 'date of last station departure' https://git.io/J3kg1
20:43:02 <milek7> hm, opengl fullscreen is glitched
20:48:48 <nielsm> IMO at least accelerated video drivers should use windowed fullscreen rather than true fullscreen
20:49:01 <nielsm> (exclusive fullscreen?)
20:50:03 <milek7> yeah, I don't think exclusive fullscreen have any benefits anymore on modern compositors
20:50:06 <michi_cc> milek7: With our without vsync?
20:50:59 <nielsm> I guess vsync is a reason you might want exclusive fullscreen, but iirc the DWM supports vsync in regular windowed apps since windows 8.1 or possibly earlier
20:51:20 *** jottyfan has joined #openttd
20:52:07 <nielsm> the only other reason for exclusive fullscreen I can think of is if you (for some reason) want to run in native 8 bpp mode (with non-accelerated video)
20:53:15 <milek7> I don't think windows allows that anymore
20:53:45 <milek7> "Apps that you design to target Windows 8 and later can no longer query or set display modes that are less than 32 bits per pixel (bpp); these operations will fail. These apps have a compatibility manifest that targets Windows 8. Windows 8 still supports 8-bit and 16-bit color modes for desktop apps that were built without a Windows 8 manifest; Windows 8 emulates these modes but still runs in 32-bit color mode."
20:55:04 <nielsm> okay so stop supporting 8 bpp surfaces in win32 entirely imo, simplify the code
20:55:20 <glx> hmm our manifest targets all windows version explicitely IIRC
20:57:11 <milek7> look at eg. station roof at 0:16
21:03:59 <glx> oh nice mingw fails to build
21:04:46 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9133: Fix: Incorrect vertical alignment of icon and text in DropDownListIconItem. https://git.io/J3kwP
21:05:16 <glx> but on a line touched 2 years ago
21:05:22 *** sla_ro|master has quit IRC ()
21:06:12 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9129: Fix b3003dd1: swap SERVER_GAME_INFO with CLIENT_GAME_INFO https://git.io/J3kwA
21:06:52 <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #9124: Codechange: Use __attribute__ access none to silence GCC 11 -Wmaybe-uninitialized warnings https://git.io/J3eaW
21:08:15 *** Samu has quit IRC (Quit: Leaving)
21:09:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9129: Fix b3003dd1: swap SERVER_GAME_INFO with CLIENT_GAME_INFO https://git.io/J3TAx
21:12:28 <peter1138> That is probably not actually added 2 years ago ;)
21:12:44 <peter1138> It was written that long ago...
21:12:51 <glx> blame says 2 years ago ;)
21:17:34 <LordAro> running bisect, just for fun...
21:17:52 <glx> but the include trace is weird
21:18:14 <peter1138> Shttps://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-gestureconfig
21:18:15 <LordAro> "in file included from windows.h"
21:18:26 <peter1138> I think GF_END is a namespace conflict for you.
21:18:56 <peter1138> Maybe not anthing to do with that link, but it mentions GF_END.
21:21:08 <LordAro> been a while since i did a bisect that was clean enough that i could just do "git bisect run ..."
21:23:18 <peter1138> Merge 6 days, which is why it's new.
21:25:14 <glx> let's compare mingw and msvc headers to see how they are guarded, and why MSVC builds fine
21:32:47 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #9133: Fix: Incorrect vertical alignment of icon and text in DropDownListIconItem. https://git.io/J3kzW
21:33:11 *** gelignite has quit IRC (Quit: Stay safe!)
21:33:43 <peter1138> glx, seems nicer than macros, might be more code though, heh
21:34:29 <glx> 6 files changed, 107 insertions(+), 106 deletions(-) <-- not that much :)
21:36:01 <peter1138> ^ And speaking of which.
21:37:27 <peter1138> No screenshots for this one :p
21:40:55 <peter1138> Eurf, €1250 for a force-feedback joystick. Maybe not.
21:47:45 <LordAro> c56fce70b440a95914bf374f68ac045ca97b3610 is the first bad commit
21:47:54 <LordAro> peter1138: you were right :p
21:50:03 <glx> ha this part is disabled for MSVC
21:50:35 <glx> both mingw and msvc protect it with WINVER >= 0x0601
21:55:25 <glx> hmm but it is disabled for mingw too, if intellisense is correct
21:56:14 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9134: Cleanup: Remove some FOR_ALL_xxx helpers https://git.io/J3kDv
22:02:39 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:09:47 *** andythenorth has quit IRC (Quit: andythenorth)
22:10:25 <peter1138> Also you're wrong. It is all cases :p
22:29:07 <glx> ok mingw somehow default to 0x601 because we don't set WINVER for mingw it seems :)
22:30:19 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:43:43 <milek7> what happened there? at 0:10
22:44:34 *** Progman has quit IRC (Remote host closed the connection)
22:53:36 *** ChanServ sets mode: +v tokai
22:56:00 <peter1138> In VS Code, milek7's commit has "attribute" in bold... :/
22:57:01 <peter1138> Ah, it's an add-on anyway.
23:00:29 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:06:06 *** Wormnest has quit IRC (Quit: Leaving)
23:17:55 *** tokai|noir has joined #openttd
23:17:56 *** ChanServ sets mode: +v tokai|noir
23:24:51 *** tokai has quit IRC (Ping timeout: 480 seconds)
23:30:39 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #9135: Fix: [MinGW] Set minimum OS version to Windows XP https://git.io/J3kjc
23:38:46 *** arikover has joined #openttd
continue to next day ⏵
