Times are UTC Toggle Colours
02:46:07 *** D-HUND has joined #openttd 02:49:29 *** debdog has quit IRC 03:29:49 *** keikoz has joined #openttd 03:31:40 *** EmeraldSnorlax[m] has quit IRC 05:56:52 <zephyris> petern: I've got two small kids... How did 23:52 happen! Leads to bad decisions about PR titles 🙂 06:49:27 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11017: Fix #10838 https://github.com/OpenTTD/OpenTTD/pull/11017#issuecomment-1594192140 06:51:05 <TrueBrain> made a change in your comment TallTyler , but `Fixes #` is better than `Closes #` 🙂 06:51:14 <TrueBrain> one implies an intention, the other an action 🙂 06:52:54 <TallTyler> I guess, although the issue is an enhancement and not really a bug, as discussed in the issue 🙂 06:53:11 <TrueBrain> it sure is a bug, that it doesn't show a dot 06:53:15 <TrueBrain> but that is splitting hairs 😛 06:53:46 <TrueBrain> but we are in the habit of fixing issues; not closing them 🙂 06:54:46 <TrueBrain> (and remember, one man's bug is another man's future) 06:54:57 <TrueBrain> future? Lol .. feature .. it is early morning 06:55:58 <Rubidium_> though... does the dot show with the original graphics and can it be considered a bug in OpenGFX? 06:56:25 <TrueBrain> `This is not base graphics set-dependent - the same behaviour happens with original windows, OpenGFX.` 06:56:30 <TrueBrain> one could also, you know, read the ticket 😛 😛 😄 06:57:21 <TrueBrain> anyway TallTyler , just please be careful to not classify everything as `Change`. As in the end everything can be classified as a change .. but that makes for shitty changelogs 🙂 07:14:58 <TallTyler> I’d classify it as a change because according to petern, they are not drawn in TTD 07:15:52 <TallTyler> I would consider it a bug that was present in TTD but 🤷 07:16:09 <TrueBrain> From a user perspective: when zooming out, I could not see the dot 07:16:18 <TrueBrain> I don't think a user actually cares if that was already in TTD or not 🙂 07:16:59 <TrueBrain> but that is just me 🙂 07:17:28 <TrueBrain> anyway, I am not saying Change is right or wrong here; just mentioning we always have to be a bit careful that we don't end up classifying everything as a Change 😄 We tend to fall in that habit from time to time 😛 07:17:51 <TrueBrain> Change (as with Closes) are neutral words; Fix is not 🙂 07:18:00 <TallTyler> Can I call #9832 a fix then? 😛 07:18:00 <TallTyler> https://github.com/OpenTTD/OpenTTD/pull/9832 07:18:17 <TrueBrain> It is an opinion to have, whether that is a fix or not 😄 07:19:50 <TrueBrain> (I always fucking hated the partial cargo behaviour, as it makes no sense and it is poorly executed; but that is my personal opnion on the matter 😄 ) 07:20:28 <TallTyler> That PR does have a lot of opinions, but mostly they led to bikeshedding 07:20:38 <TrueBrain> as does this discussion \o/ 😄 07:20:54 <TrueBrain> (well, I am bikeshedding, to be clear 😛 ) 07:21:14 <TrueBrain> but yeah, changing gamelogic is always more opinionated than changing UI behaviour 07:21:52 <TrueBrain> I think it is one of the more confusing parts of the game, the partial acceptance shit; I would hate to be a new player and figure that out 07:22:05 <TrueBrain> owh, I even wrote that in that PR, haha 07:22:51 <petern> No, #9832 is a mistake, not a fix. 07:23:22 <TrueBrain> You are entitled to your opinion (/me runs away really quick now) 😄 07:23:35 <TrueBrain> owh, I am in such a not serious mood lately ... I am sorry 🙂 07:24:21 <petern> That happens when you successfully migrate a complex infrastructure in like a week... 07:24:37 <TrueBrain> 😄 07:25:16 <TrueBrain> I think what for me is the case with 9832, that so many times I was like: "why isn't this station accepting wood?!" .. as yes, I don't actually read "Acceptance" .. I just eyeball it: it is a tile over the industry, LETS GO!!!!! 🙂 07:25:22 <TrueBrain> so it is pure frustration 😛 07:26:01 <TrueBrain> Another way of solving that problem for me would be to visual highlight what tiles accept stuff in the coverage area 07:26:16 <TrueBrain> so instead of having a blue square, have something on top of it to indicate the cargo it is accepting, or something like that 07:26:27 <TrueBrain> tldr: I don't like reading (ironic, not? :D) 07:28:40 <petern> Do we start making all town tiles 8/8 production as well? It's basically the same system. 07:29:32 <petern> Of course, we can do that as well. With a NewGRF. 07:29:57 <TrueBrain> Hence my other suggestion; me basically kinda agreeing with you, but the frustration is still winning 😛 07:33:21 <TrueBrain> 88GB miss, 18GB hit .. slowly it is browing, just not really fast 😛 07:33:39 <TrueBrain> either way it is fine btw; Cloudflare doesn't charge for bandwidth 🙂 07:37:15 *** Flygon has quit IRC 07:40:42 *** Kitrana has joined #openttd 07:48:12 *** Kitrana1 has quit IRC 07:49:49 <LordAro> TrueBrain: fun 07:50:53 <TrueBrain> hmm .. why is finding out how much memory a process consumes in peak so difficult? 07:52:06 <TrueBrain> GNU time seems to indicate it .. guess that will do 07:52:52 <Rubidium_> because it's unclear what memory you want to be counted and which you do not want to be counted? 07:53:07 <TrueBrain> that is very clear .. I want to know the peak RSS 07:53:22 <TrueBrain> but GNU time seems the only tool to tell me .. so it will do, but it was surprisingly difficult to find one 08:08:46 <andythenorth> OpenTTD Gold Edition 08:08:48 <TrueBrain> okay, for some images Pillow is more efficient, for others pyvips is .. that is not actually helping 😄 08:08:50 <andythenorth> we redo the mechanics 08:11:50 <CK2347> Hmm 08:12:02 <TrueBrain> ` colourspace(space, source_space=Union[str, Interpretation]) -> Convert to a new colorspace.` .. they cannot even be consistent in spelling! 08:12:02 <CK2347> Got my hand on a old patch 08:12:35 <CK2347> Now how to compile it idk (no instructions for compiling it) 08:18:27 <TrueBrain> mainly, pyvips consumes more memory to just load in, versus Pillow that consumes nearly none 08:20:00 *** esselfe_ has joined #openttd 08:23:17 *** esselfe has quit IRC 08:45:12 <andythenorth> hmm 09:00:51 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler closed pull request #9832: Change: Vanilla industry tiles have 8/8 acceptance https://github.com/OpenTTD/OpenTTD/pull/9832 09:01:11 <TallTyler> I don’t care enough to argue over it 🤷 09:03:49 <peter1139> Another on the rejected PR pile. 09:04:23 <peter1139> Maybe I will learn NML and make a NewGRF. 09:06:39 <TrueBrain> and I can't stand that Pillow seems to have no way to read images chunked, and pyvips is another can of works .. I can't even find how to access the palette of an PNG 😛 09:07:05 <TrueBrain> and we did some weird shit with heightmaps, not making any of this easier 🙂 (if you have a palette of size=16, each index means a height, and the color is irrelevant) 09:14:25 *** felix_ has quit IRC 09:19:25 <peter1139> Can that be generalized with "if palette.size is 16, replace palette with gradient" 09:20:15 <TrueBrain> currently I can't find any way to access the palette information with vips 09:20:17 <peter1139> Though that depends massively on the library's interface. 09:20:33 <TrueBrain> which can be a "me" problem btw 🙂 09:21:09 <peter1139> Urgh, managed to set up my Linux desktop (native!) to build and run my $work stuff, except it won't connect to the SQL server :( 09:29:40 <peter1139> Really wish I'd pushed for PostgreSQL originally :p 09:31:24 <TrueBrain> okay ... I can detect a 4bit palette is used, but I need to walk the image twice to see if they are grey-scaled (which is the second condition I forgot to mention) 09:31:41 <TrueBrain> as OpenTTD checks for that 09:31:45 <peter1139> :/ 09:31:54 <TrueBrain> who wrote this shitty heightmap implementation in OpenTTD? Owh, me ... 09:32:14 <peter1139> What happens if you ignore that? 09:32:26 <TrueBrain> https://github.com/OpenTTD/OpenTTD/blob/master/src/heightmap.cpp#L94 09:32:26 <TrueBrain> For reference 😛 09:32:35 <peter1139> Are there any heightmaps in existance that do it? 09:32:37 <TrueBrain> euh, if I ignore that, classification might be wrong .. not sure it is a big deal 😛 09:34:15 <TrueBrain> people did make maps with 16 palette colours and not all of them being gray 09:34:29 <TrueBrain> I doubt it was the intention ... but here we are 🙂 09:35:42 <TrueBrain> owh, wait, it is even reversed .. if the palette is 16 and it is non-gray, the index colour is used 09:36:41 <TrueBrain> it is such a weird condition ... 09:39:55 *** felix has joined #openttd 09:50:28 <petern> Well, I've given up and gone back to Windows, which spent another *AGES* finishing updates... 09:54:45 <petern> Hmm, new Sigur Ros wot? 09:55:10 <petern> ```static_assert(lengthof(_cursor.sprite_seq) == std::tuple_size<decltype(OpenGLBackend::cursor_sprite_seq)>::value);``` 09:55:15 <petern> That's a bit of a mouthful. 09:56:12 <petern> Can't static_assert on a std::array's `.size()` 10:01:26 <TrueBrain> right, so the solution seems to be: use vips to load the image, if it is a 16bit palette, use Pillow to get the index table, and use vips to load the rest of the image 10:01:32 <TrueBrain> bit weird, but a lot more consistent in memory usage 10:30:02 <LordAro> TrueBrain: ew 10:31:40 <petern> What do these libraries do that directly access with libpng or whatever doesn't? 10:32:15 <TrueBrain> that is the alternative, wrapping around libpng ourselves 10:32:18 <TrueBrain> it is just a lot more code 10:32:23 <LordAro> i mean, "direct access with libpng" in python isn't the easiest 10:33:46 <TrueBrain> lot of ffi magic it requires 🙂 10:34:17 <TrueBrain> but I might give it a try nevertheless ... as I have a CPU issue to solve .. turns out, fetching every pixel in Python is very slow 😄 10:34:49 <TrueBrain> so I have the suspicion that the correct solution is to make a small C library for doing this 🙂 10:35:56 <TrueBrain> lol, I only now spot that I doubt we can load RGBA heightmaps .. also makes no sense, but I think they would load pretty strange 🙂 10:46:47 <petern> Well, there's also the "why is it python?" question 🙂 10:47:25 <TrueBrain> Lately I asked that many times 😄 10:47:33 <LordAro> rewrite it in rust? 10:47:41 <TrueBrain> But rewriting BaNaNaS in rust is not an easy task :p 10:47:58 <TrueBrain> I have been toying with running wasm for edge computing 10:48:09 <TrueBrain> These services would be perfect for that 10:48:22 <TrueBrain> Lot better performance and better memory usage 10:48:32 <LordAro> compared to? 10:48:36 <TrueBrain> Python 10:48:45 <LordAro> interesting 10:49:03 <LordAro> cpython has done quite a lot of performance stuff in the last couple of releases 10:49:23 <TrueBrain> Yeah, and 3.13 wants to gain 50% performance increase 10:49:30 <TrueBrain> And lower memory footprint 10:49:35 <TrueBrain> So it is getting there 10:50:06 <petern> So should I default-value initialize things, or make sure the constructor initializes? 10:51:38 <TrueBrain> Member before ctor before ctor body, is the advise from "insert name of important C++ people here" .. not sure if that is worth anything for us 😄 10:53:14 <petern> I think by "default-value initialize" I mean member initialization. 10:53:37 <TrueBrain> I assumed you did 😛 10:53:47 <petern> I wasn't sure if I did! 10:54:12 <TrueBrain> Hahaha 10:54:24 <petern> IIRC some things don't need it as for them default-initialization is the same as value-initialization. 10:54:49 <petern> But, maybe it's better to do it for all members so we don't have to care about knowing which is which. 10:55:06 <petern> Like, std::array needs it, but std::vector does not. 10:56:13 <TrueBrain> Yeah .. I even do strings in my own projects.. just being explicit 😄 11:49:02 <petern> Hmm, `{}` or ` = 0`. Former means no need to think about what the type is... latter might be clearer. 11:49:33 <TrueBrain> personally I like `{}`, because you don't have to think 😛 11:49:41 <TrueBrain> but yeah, `= 0` is more clear 11:49:48 <TrueBrain> taste ... 11:49:52 <TrueBrain> we should update our styleguide 😄 11:50:03 <petern> I've done it all as {} so far :p 11:50:51 <petern> "all", I'm only changing things that used ZeroedMemoryAllocator. 11:51:03 <petern> For now. 12:25:25 <TrueBrain> I forgot how much I hated C interfaces 😛 12:25:38 <TrueBrain> for some reason my progressive PNG reader is failing .. and I have no clue why .. it is sad 12:26:04 <orudge> [10:53:24] <petern> Hmm, new Sigur Ros wot? <-- indeed, and tis not bad either 12:29:33 <TrueBrain> lol .. "info callback is optional" .. no it wasn't 12:35:50 <DorpsGek> [OpenTTD/OpenTTD] orudge opened pull request #11018: Remove: OS/2 port https://github.com/OpenTTD/OpenTTD/pull/11018 12:35:56 <petern> 😮 12:36:01 <LordAro> :o 12:36:06 <TrueBrain> You couldn't get it to compile? 12:36:18 <orudge> Well, I could get bits to compile 12:36:27 <orudge> strgen works :D 12:36:37 <orudge> It's more my build environment 12:36:49 <TrueBrain> lovely text btw 🙂 12:37:04 <orudge> but, as I document extensively in the PR, I don't currently feel the inclination to spend 0 or whatever on the current commercial incarnation of OS/2, on which it would probably be considerably more straightforward to get it to build 12:37:45 <orudge> Maybe one day I will, and then I can put all the code back again :D 12:37:57 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #11018: Remove: OS/2 port https://github.com/OpenTTD/OpenTTD/pull/11018#pullrequestreview-1483414244 12:38:12 <TrueBrain> Well, it is much appreciated you took a look at this 🙂 At least now we don't have to wonder anymore 🙂 12:39:41 <petern> That's a good ratio though, +14,-1693 12:39:46 <orudge> And to be fair, even if I did get it building again, the build environment would probably involve automatically firing up an OS/2 VM and waiting about an hour for it to build, which I imagine would not be appreciated by everyone else :) 12:40:13 <TrueBrain> I already hate on Mingw for its slowness 😛 12:40:16 <orudge> and it's been some years since I was able to build an OS/2-targetting GCC crosscompiler 12:41:06 <orudge> I do see, though, that we have an officially supported Haiki port still apparently, and a Haiku crosscompiler sitting on Docker Hub... :p 12:41:46 <TrueBrain> I await a PR to add the compiler to the CI 🙂 12:45:20 <LordAro> https://github.com/rust-lang/rust/blob/master/.github/workflows/ci.yml#L170 clearly we need to up our game 12:45:47 <TrueBrain> so .. who is going to pay? 😄 12:46:03 <TrueBrain> that is one expensive matrix 😄 12:46:08 <petern> LordAro can't, he wants new wheels. 12:46:18 <LordAro> hehe 12:54:45 <TrueBrain> seems that writing this module in C++ is a good choice .. 12:54:49 <TrueBrain> not only does it barely use memory 12:54:52 <TrueBrain> it is also very very quick 12:55:12 <TrueBrain> and ... I can reuse OpenTTD's code 12:55:15 <TrueBrain> so I know it does the same 😛 13:00:17 *** nielsm has joined #openttd 13:10:34 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11019: Codechange: Use std::vector for midifile's ByteBuffer. https://github.com/OpenTTD/OpenTTD/pull/11019 13:10:47 <TrueBrain> lol .. 60MB, instead of 400MB, to read ALL heightmaps available 13:10:53 <TrueBrain> yeah .. this is going to make a difference 🙂 13:12:44 <petern> Nice. 13:13:20 <glx[d]> huge reduction 13:13:29 <TrueBrain> also speed is a huge difference 😛 13:13:54 <petern> NML rewrite then? 13:14:24 <TrueBrain> in Rust? Yes 13:14:50 <TrueBrain> hmm .. Interlaced PNGs .. 13:14:53 <TrueBrain> how do I deal with those ... 13:15:14 <Eddi|zuHause> "import png" :p 13:16:02 *** virtualrandomnumber has joined #openttd 13:16:39 *** virtualrandomnumber has quit IRC 13:16:48 <TrueBrain> with interlazing you get the lovely effect the same row is drawn several times ... 13:18:02 <Eddi|zuHause> i have a feeling i won't get all Cities:Skylines DLCs until the next game comes out... 13:21:31 <glx[d]> ok let's test #11019 13:22:39 <TrueBrain> hmm, I was hoping the buffer was zero'd when it did interlacing, but it isn't ... 13:22:42 <TrueBrain> that is just shit 😛 13:29:18 <DorpsGek> [OpenTTD/OpenTTD] orudge merged pull request #11018: Remove: OS/2 port https://github.com/OpenTTD/OpenTTD/pull/11018 13:30:51 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11019: Codechange: Use std::vector for midifile's ByteBuffer. https://github.com/OpenTTD/OpenTTD/pull/11019#pullrequestreview-1483511031 13:36:21 <TrueBrain> owh, one map touched 70MB! 13:36:29 <TrueBrain> lol 13:37:02 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11019: Codechange: Use std::vector for midifile's ByteBuffer. https://github.com/OpenTTD/OpenTTD/pull/11019#pullrequestreview-1483531711 13:37:08 <TrueBrain> seems the classification is identical with this new code .. so that is good 13:50:00 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11019: Codechange: Use std::vector for midifile's ByteBuffer. https://github.com/OpenTTD/OpenTTD/pull/11019#pullrequestreview-1483558485 13:50:50 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11019: Codechange: Use std::vector for midifile's ByteBuffer. https://github.com/OpenTTD/OpenTTD/pull/11019#pullrequestreview-1483559846 14:01:10 <DorpsGek> [OpenTTD/bananas-api] TrueBrain opened pull request #391: Change: use a C-module to analyze heightmap https://github.com/OpenTTD/bananas-api/pull/391 14:05:26 <DorpsGek> [OpenTTD/bananas-api] TrueBrain updated pull request #391: Change: use a C-module to analyze heightmap https://github.com/OpenTTD/bananas-api/pull/391 14:05:28 <petern> Hmm, my WSL instance can no longer mount one of my Windows drives... :/ 14:05:48 <TrueBrain> 😮 14:07:48 <DorpsGek> [OpenTTD/bananas-api] TrueBrain commented on pull request #373: Fix: bring the image size limit of PIL in line https://github.com/OpenTTD/bananas-api/pull/373#issuecomment-1594742077 14:08:31 <TrueBrain> 😮 did the arm version just build ? I expected more issues with that ... 14:12:39 <TrueBrain> `32kx32k.png (2981 kB): Image is too large.` 14:12:42 <TrueBrain> there we go! 🙂 14:12:56 <TrueBrain> Preview works 😄 14:15:27 <TrueBrain> funny, yesterday the API spikes to 500+ MiB when uploading images .. now it doesn't go above 80MB 🙂 14:15:38 <TrueBrain> problem .. problem solved 😄 Well, if the review isn't finding weird shit 🙂 14:16:50 <DorpsGek> [OpenTTD/bananas-api] TrueBrain updated pull request #391: Change: use a C-module to analyze heightmap https://github.com/OpenTTD/bananas-api/pull/391 14:17:14 <TrueBrain> owh, and regression need the library ofc .. hmm .. what is installed on a runner? Let's find out! 14:18:01 <TrueBrain> ha, right first attempt, w00p! 14:19:54 <TrueBrain> `botocore.exceptions.IncompleteReadError: 64966656 read, but total bytes expected is 286603033` .. something isn't right with streaming from Cloudflare R2 .. so there are some issues with BaNaNaS .. TCP transfers aren't as stable as I would like. But also .. why don't these people use HTTP? 😄 14:38:37 <glx[d]> pre-http versions ? 14:40:49 <pickpacket> How long ago was that? 14:50:33 *** gelignite has joined #openttd 15:04:22 *** DDR has quit IRC 15:37:22 <DorpsGek> [OpenTTD/OpenTTD] zephyris updated pull request #11017: Fix #10838 https://github.com/OpenTTD/OpenTTD/pull/11017 15:47:23 *** nielsm has quit IRC 15:57:39 *** _aD has joined #openttd 16:04:50 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11019: Codechange: Use std::vector for midifile's ByteBuffer. https://github.com/OpenTTD/OpenTTD/pull/11019 16:07:55 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11020: Codechange: Use vector when migrating old savegame orders. https://github.com/OpenTTD/OpenTTD/pull/11020 16:23:28 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #11020: Codechange: Use vector when migrating old savegame orders. https://github.com/OpenTTD/OpenTTD/pull/11020#pullrequestreview-1483894691 16:37:07 *** Wolf01 has joined #openttd 16:38:35 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #11021: Fix: Crash when failing to load a game into a dedicated server at startup https://github.com/OpenTTD/OpenTTD/pull/11021 16:56:32 <petern> Hmm, using std::array::fill is kinda shorter. 17:15:23 *** HerzogDeXtEr has joined #openttd 17:20:01 *** Eddi|zuHause has quit IRC 17:22:20 *** Eddi|zuHause has joined #openttd 17:55:28 *** Eddi|zuHause has quit IRC 18:02:28 *** Eddi|zuHause has joined #openttd 18:38:58 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #11021: Fix: Crash when failing to load a game into a dedicated server at startup https://github.com/OpenTTD/OpenTTD/pull/11021#pullrequestreview-1484118104 18:40:28 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11020: Codechange: Use vector when migrating old savegame orders. https://github.com/OpenTTD/OpenTTD/pull/11020 18:41:31 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11021: Fix: Crash when failing to load a game into a dedicated server at startup https://github.com/OpenTTD/OpenTTD/pull/11021 19:03:53 *** Flygon has joined #openttd 19:07:47 <glx[d]> looks like someone managed to merge right when eints wanted to do it 19:07:48 <DorpsGek> [OpenTTD/OpenTTD] zephyris commented on issue #9031: Rivers going uphill are nearly impossible to distinguish from flat river https://github.com/OpenTTD/OpenTTD/issues/9031 19:09:53 <TrueBrain> Eints just takes to long .. but seems frosch is addressing that issue 😄 19:10:59 <peter1139> Oh 19:16:03 <glx[d]> it's hard to predict when eints will try to push 19:18:40 <TrueBrain> https://github.com/OpenTTD/bananas-api/pull/391 19:18:40 <TrueBrain> Who wants to review some C++? 🙂 19:28:44 <glx[d]> code seems fine 19:33:35 <TrueBrain> Good 🙂 it was a bit more code then I expected 🙂 19:41:16 <DorpsGek> [OpenTTD/bananas-api] glx22 approved pull request #391: Change: use a C-module to analyze heightmap https://github.com/OpenTTD/bananas-api/pull/391#pullrequestreview-1484226941 19:41:42 <glx[d]> at least can't be worse than pillow 19:42:13 <DorpsGek> [OpenTTD/bananas-api] TrueBrain merged pull request #391: Change: use a C-module to analyze heightmap https://github.com/OpenTTD/bananas-api/pull/391 19:42:18 <DorpsGek> [OpenTTD/bananas-api] TrueBrain closed pull request #373: Fix: bring the image size limit of PIL in line https://github.com/OpenTTD/bananas-api/pull/373 19:42:25 <TrueBrain> We can always improve 🙂 19:59:45 <pickpacket> I'm playing with this set now: https://bananas.openttd.org/package/newgrf/4a4b0101 and I thought (as I've mentioned before) that there's room for two or three more electrical rail engines in the game too, and I could fork this and add that 20:01:27 <pickpacket> and then I thought "I wonder what a good name would be. It's just a somewhat extended train set. Actually 'Somewhat Extended Train Set' is a decent name. Abbreviated..? 'SETS'? Maybe 'SXTS'? 'SExt...' errrh... uhm... 'SExTrainS'!" 20:02:00 * pickpacket adds this to his project list 20:20:17 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #11022: Fix #11016: Use after free in network invalid packet error path https://github.com/OpenTTD/OpenTTD/pull/11022 20:20:57 *** D-HUND is now known as debdog 20:41:44 *** HerzogDeXtEr has quit IRC 21:08:14 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11022: Fix #11016: Use after free in network invalid packet error path https://github.com/OpenTTD/OpenTTD/pull/11022#pullrequestreview-1484394542 21:12:57 *** Wolf01 has quit IRC 21:15:56 *** _aD has quit IRC 21:18:51 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #11023: Change: Add separate setting for server sent commands per frame limit https://github.com/OpenTTD/OpenTTD/pull/11023 21:26:44 *** tokai has joined #openttd 21:26:44 *** ChanServ sets mode: +v tokai 21:30:05 <DorpsGek> [OpenTTD/OpenTTD] zephyris commented on issue #9031: Rivers going uphill are nearly impossible to distinguish from flat river https://github.com/OpenTTD/OpenTTD/issues/9031 21:53:24 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #11024: Fix #10993: Crash log when font caches not initialised https://github.com/OpenTTD/OpenTTD/pull/11024 22:00:13 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11024: Fix #10993: Crash log when font caches not initialised https://github.com/OpenTTD/OpenTTD/pull/11024#pullrequestreview-1484478013 22:07:06 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11024: Fix #10993: Crash log when font caches not initialised https://github.com/OpenTTD/OpenTTD/pull/11024#pullrequestreview-1484482654 22:28:57 *** keikoz has quit IRC 23:05:41 *** DemonBigj781 has joined #openttd 23:06:02 <DemonBigj781> hay is there a music manager for openttd 23:09:26 <debdog> even win95 bragged about multitsking 23:35:21 *** gelignite has quit IRC 23:51:15 *** tokai|noir has joined #openttd 23:51:15 *** ChanServ sets mode: +v tokai|noir 23:58:03 *** tokai has quit IRC