IRC logs for #openttd on OFTC at 2023-06-16
โด go to previous day
02:49:29 *** debdog has quit IRC (Ping timeout: 480 seconds)
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: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: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: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: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: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)
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: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:54 <TrueBrain> who wrote this shitty heightmap implementation in OpenTTD? Owh, me ...
09:32:14 <peter1139> What happens if you ignore that?
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: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: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: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: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: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: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.
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:36:06 <TrueBrain> You couldn't get it to compile?
12:36:18 <orudge> Well, I could get bits to compile
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: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: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: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: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:13:29 <TrueBrain> also speed is a huge difference ๐
13:14:50 <TrueBrain> hmm .. Interlaced PNGs ..
13:14:53 <TrueBrain> how do I deal with those ...
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: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:36:21 <TrueBrain> owh, one map touched 70MB!
13:37:08 <TrueBrain> seems the classification is identical with this new code .. so that is good
14:05:28 <petern> Hmm, my WSL instance can no longer mount one of my Windows drives... :/
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: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: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: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:47:23 *** nielsm has quit IRC (Ping timeout: 480 seconds)
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
19:07:47 <glx[d]> looks like someone managed to merge right when eints wanted to do it
19:09:53 <TrueBrain> Eints just takes to long .. but seems frosch is addressing that issue ๐
19:16:03 <glx[d]> it's hard to predict when eints will try to push
19:18:40 <TrueBrain> Who wants to review some C++? ๐
19:33:35 <TrueBrain> Good ๐ it was a bit more code then I expected ๐
19:41:42 <glx[d]> at least can't be worse than pillow
19:42:25 <TrueBrain> We can always improve ๐
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:57 *** D-HUND is now known as debdog
20:41:44 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
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:26:44 *** ChanServ sets mode: +v tokai
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)
continue to next day โต