IRC logs for #openttd on OFTC at 2023-06-16
            
02:46:07 *** D-HUND has joined #openttd
02:49:29 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:29:49 *** keikoz has joined #openttd
03:31:40 *** EmeraldSnorlax[m] has quit IRC (Quit: Client limit exceeded: 20000)
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 (Quit: A toaster's basically a soldering iron designed to toast bread)
07:40:42 *** Kitrana has joined #openttd
07:48:12 *** Kitrana1 has quit IRC (Ping timeout: 480 seconds)
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 (Ping timeout: 480 seconds)
08:45:12 <andythenorth> hmm
09:00:50 <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:48 <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:40 <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:44 <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:48 <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:36 <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:49 <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 $100 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:04 *** gnomechomsky has quit IRC (Quit: User went offline on Discord a while ago)
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 (Remote host closed the connection)
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:30 <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:49:59 <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 (Remote host closed the connection)
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 (Ping timeout: 480 seconds)
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:06:22 *** Kuhnovic has quit IRC (Quit: User went offline on Discord a while ago)
17:15:23 *** HerzogDeXtEr has joined #openttd
17:20:01 *** Eddi|zuHause has quit IRC (Read error: Connection reset by peer)
17:22:20 *** Eddi|zuHause has joined #openttd
17:55:28 *** Eddi|zuHause has quit IRC (Remote host closed the connection)
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 (Read error: Connection reset by peer)
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 (Quit: Once again the world is quick to bury me.)
21:15:56 *** _aD has quit IRC (Quit: leaving)
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:21:19 *** frosch has quit IRC (Quit: User went offline on Discord a while ago)
22:28:57 *** keikoz has quit IRC (Ping timeout: 480 seconds)
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 (Quit: Stay safe!)
23:51:15 *** tokai|noir has joined #openttd
23:51:15 *** ChanServ sets mode: +v tokai|noir
23:58:03 *** tokai has quit IRC (Ping timeout: 480 seconds)