Times are UTC Toggle Colours
00:02:49 *** Tirili has quit IRC 01:38:49 *** Flygon has joined #openttd 02:28:32 *** snail_UES_ has quit IRC 02:30:16 *** glx has quit IRC 02:35:11 *** debdog has joined #openttd 02:38:30 *** D-HUND has quit IRC 03:18:12 *** Wormnest has quit IRC 03:41:49 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz left a comment on commit: Cleanup: Give `SetDirtyBlocks` a more descriptive name. https://git.io/JfSJl 03:43:01 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz left a comment on commit: Cleanup: Fix typos in code comments. https://git.io/JfSJ4 04:14:33 *** Wormnest has joined #openttd 04:30:59 *** m1cr0m4n has joined #openttd 04:31:14 *** lastmikoi has quit IRC 04:31:14 *** m1cr0man has quit IRC 04:31:43 *** lastmikoi has joined #openttd 04:34:04 *** skrzyp has quit IRC 04:45:09 *** keoz has joined #openttd 05:07:13 *** Wormnest has quit IRC 06:11:45 *** sla_ro|master has joined #openttd 06:13:52 *** arikover has joined #openttd 06:15:05 *** andythenorth has joined #openttd 06:43:47 <andythenorth> yo 06:57:08 <EER> o/ 07:04:36 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8208: Cleanup: More documentation fixes https://git.io/JfSmf 07:08:45 *** k-man has quit IRC 07:21:40 *** k-man has joined #openttd 07:26:57 *** k-man has joined #openttd 07:29:43 *** k-man has quit IRC 07:42:35 *** k-man has joined #openttd 07:43:04 *** k-man has quit IRC 07:43:40 *** k-man has joined #openttd 08:12:24 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz opened pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 08:14:34 *** gelignite has joined #openttd 08:15:34 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 09:00:31 *** gelignite has quit IRC 09:12:34 *** Samu has joined #openttd 09:52:52 *** skrzyp has joined #openttd 10:05:11 *** skrzyp has quit IRC 10:16:21 *** skrzyp has joined #openttd 10:37:38 <planetmaker> moin 10:37:54 *** gelignite has joined #openttd 10:37:54 <planetmaker> I just explained that jfs and andythenorth are not the morons in one of the threads :P 10:39:01 <LordAro> planetmaker: hmm? 10:39:40 *** Laedek has quit IRC 10:45:28 <planetmaker> oh, that funny thread where *some guy* wants to explain that they don't understand why there is a NewGRF limit :P 10:50:08 <Timberwolf> My sarcastic side would go for, "cool, as you understand the problem why not submit a PR to fix it?" but that's probably just feeding the troll :) 10:54:12 <planetmaker> well... my reply might have included something of such salt :P 10:54:27 <planetmaker> especially as the guy stressed that he has an IT background and understands the isuse :P 10:55:49 *** skrzyp has quit IRC 11:01:43 <_dp_> planetmaker, I don't see your reply, you sure you actually posted it? 11:02:39 <planetmaker> no, I didn't. I sent a private message. 11:02:59 <_dp_> oh, ok 11:11:24 <planetmaker> not always good to do moderation in public :) 11:15:38 *** snail_UES_ has joined #openttd 11:28:51 *** WormnestAndroid has quit IRC 11:29:04 *** WormnestAndroid has joined #openttd 11:30:28 *** WormnestAndroid has quit IRC 11:30:41 *** WormnestAndroid has joined #openttd 11:44:46 <andythenorth> I assumed good intent and low knowledge 11:44:53 <andythenorth> maybe I got those the wrong way around 11:45:08 <andythenorth> but it's a starting point of sorts 11:52:05 <supermop_Home> ugh remote workstation not responsive - going to have to go into the office to restart it 11:53:07 <planetmaker> I can at least confirm the latter point, judging from a follow-up reply 11:56:00 <andythenorth> supermop_Home you need https://thedailywtf.com/articles/ITAPPMONROBOT 11:57:07 <planetmaker> just to satisfy my curiosity: on the bug tracker on github, could I, in principle, mark an issue as private or non-public in case that it contains (essential) private information? 11:57:36 <LordAro> planetmaker: i believe so 11:57:52 <planetmaker> can you show me how? I was looking for 30 minutes without success 11:59:07 <LordAro> hmm, perhaps not 11:59:45 <LordAro> gitlab you can 11:59:50 <planetmaker> yep 11:59:57 <LordAro> GH you just have https://github.com/isaacs/github/issues/37 12:00:22 <planetmaker> good that you arrived at the same place independently :) 12:00:51 <LordAro> can possibly move an issue to a private repo 12:09:20 <supermop_Home> andythenorth indeed 12:09:33 <supermop_Home> lucky for me the office is only 10 min away 12:14:17 *** Laedek has joined #openttd 12:42:12 *** glx has joined #openttd 12:42:12 *** ChanServ sets mode: +v glx 13:32:33 <FLHerne> planetmaker: Do you know how JGR does it? 13:32:45 <planetmaker> no 13:32:51 <FLHerne> I remember there was a patch that raised the limit only for local games 13:33:14 <FLHerne> But apparently you can have 255 grfs on a JGR server, so...? 13:33:23 <FLHerne> Maybe they're just not shown in the server list 13:33:43 <planetmaker> it might work, if you configure your client properly... dunnow 13:36:50 <LordAro> i don't think you can have 255 grfs on a server 13:36:52 <LordAro> https://github.com/JGRennison/OpenTTD-patches/blob/jgrpp/src/network/core/config.h#L60 13:37:22 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8190: Mac build fails with cmake https://git.io/Jf1a9 13:39:09 <LordAro> oh wait, here it is https://github.com/JGRennison/OpenTTD-patches/commit/6342099c4d3ad69e6eb5dd36e7e41ecc874b7d57#diff-5d7621e6bc0894916f1492a729fc7ec9 13:39:28 <LordAro> which builds on a few other patches 13:45:01 <FLHerne> tbh, it seems a bit unfair to the forum guy to insist that it's technologically impractical 13:45:15 <FLHerne> when there's an existing patch for it :p 13:45:29 <LordAro> no one's said it's technologically impractical 13:45:42 <LordAro> forum guy just seems to think that people have told him that 13:47:33 *** nielsm has joined #openttd 13:55:03 *** skrzyp has joined #openttd 13:59:06 <planetmaker> yes... such was not implied 14:14:31 *** spnda has joined #openttd 14:28:43 <FLHerne> Eh 14:29:54 <FLHerne> I just feel these threads always lead to browbeating the questioner with the details of the current implementation, as if that implies it's an invalid suggestion 14:30:24 <FLHerne> Obviously they know the limit currently exists, or they wouldn't ask 14:32:01 <LordAro> FLHerne: the issue is they seem very confused about *why* the limit exists, and was refusing to acknowledge anything else when explained to them 14:33:22 *** snail_UES_ has quit IRC 14:33:48 *** snail_UES_ has joined #openttd 14:34:05 <FLHerne> I don't think that's a fair reading 14:34:15 <planetmaker> tbh, I read it like that, too 14:34:44 <FLHerne> jfs explained it was a network limitation, questioner said networks are pretty fast these days 14:35:08 <planetmaker> jfs explained that it was a network *protocol* limitation 14:35:15 <FLHerne> Auge's post then immediately rolls out a ton of jargon to basically say "it doesn't work that way atm" 14:35:57 <planetmaker> https://www.tt-forums.net/viewtopic.php?p=1233105#p1233105 14:36:22 <FLHerne> Yes, up to there the thread is fine 14:36:51 <planetmaker> https://www.tt-forums.net/viewtopic.php?p=1233112#p1233112 elaborates on that 14:37:10 <FLHerne> Hm, no, it's jfs with the jargon as well 14:37:16 <planetmaker> and in the follow up it was shown that the explanation was not understood at all 14:38:34 <FLHerne> Again, I don't think understanding the technical reason is really at issue 14:39:20 <andythenorth> responding to suggestions is best approached as judo 14:39:22 <andythenorth> roll with it 14:39:28 <FLHerne> Perhaps they don't understand it, but it's just another form of "but it doesn't work like that *now*", which is frankly a pointless response 14:39:29 <andythenorth> that didn't quite happen here 14:40:28 <nielsm> I try to always give a non-technical summary/conclusion, at least it's my intention to 14:40:34 <FLHerne> So the guy keeps reiterating that it *could* be done, at which point people start attacking him for ignoring the implementation details that aren't especially relevant 14:40:35 <nielsm> even if it's also backed up by a technical explanation 14:41:02 <FLHerne> Not sure I'm making my point clearly 14:41:15 <FLHerne> I think 14:41:37 <FLHerne> - The suggestions forum shouldn't only be for people who can write a patch to implement their suggestion 14:41:46 <FLHerne> (because that's "OpenTTD Development") 14:41:58 <andythenorth> FLHerne I know what point you're making, it's not unclear to me 14:42:36 <FLHerne> - Rejecting suggestions because the current codebase doesn't support them is silly, because it's inherently true to one extent or another 14:42:43 <nielsm> implicit in my answers was also "we know it's a problem, we know it can be fixed, we have an outline of how it can be fixed, but it's more work than anyone is willing to put in right now and is considered low priority" 14:42:53 <planetmaker> FLHerne, I don't think anyone rejected the suggestion either 14:43:12 <andythenorth> nothing is accepted or rejected in suggestions forum :) 14:43:14 <nielsm> maybe I should just have written that 14:43:42 <planetmaker> What I do believe could have been said more clearly, perhaps upfront is like "thank you for the suggestion, it's a good one, it's possible, but it needs some changes no-one did implement so far in a satisfying way" 14:43:50 <andythenorth> Suggestions forum is just this https://www.youtube.com/watch?v=S90kfeD1P6I 14:43:56 <andythenorth> (I made the video years ago) 14:43:59 <planetmaker> and then the explanation with network protocol etc 14:44:06 <FLHerne> planetmaker: I think it's "Please don't try to argue network protocols if..." where it really goes wrong 14:44:07 <nielsm> what I take issue with is responses like: "many games can transfer much more data between computers than what openttd can. warcraft 3 for example have room for 8 megabytes of custom data including graphics. that is much more than openttd sends." 14:44:17 <andythenorth> oh they cut the sound :( 14:44:19 <FLHerne> They were never trying to "argue network protocols" 14:44:30 <nielsm> that indicates to me the poster is blaming the current state of openttd and past development for being bad 14:44:46 <nielsm> blaming past developers for not having done it The Correct Way from the beginning 14:45:05 <planetmaker> FLHerne, but they are like "it must be done and why isn't it?! It all goes slow because of large maps" 14:45:15 <andythenorth> yes that riled me, but if you stop a minute 14:45:17 <nielsm> s/indicates to me/reads to me as/ 14:45:19 <andythenorth> they're so far from reality 14:45:25 <andythenorth> that it doesn't matter what they say 14:45:32 <andythenorth> so we give them the benefit of the doubt 14:45:39 <planetmaker> which is also quite beside the point of what he tried to argue in the first place... So it's at least failure to communicate on both sides 14:45:43 <andythenorth> it's probably a 10 year old 14:46:02 <planetmaker> tbh, when *I* read it, I thought like "c'mon... get a grip and just let it slide" 14:47:15 <planetmaker> for both, actually, jfs' answer with "please don't try to argue..." and the reply to that as well... 14:47:43 <planetmaker> if one wants to start arguing details... then one has to be able to be a bit... more willing to accept an argument 14:47:57 <planetmaker> and not take everything personally straight away 14:48:01 <andythenorth> I rarely go in suggestions forum :) 14:48:14 <andythenorth> it's the equivalent of a below-the-fold comment section 14:48:57 <andythenorth> we have to have it though 14:51:44 <Timberwolf> I think people too easily confuse "suggestions" as "tickets for development" 14:53:33 <andythenorth> it's a mismatched social contract 14:53:33 <Timberwolf> Also after 15+ years it's hard to come up with a suggestion that is novel and appropriate, but also not implementable through NewGRF and/or GS. 14:53:43 <andythenorth> Timberwolf challenge :D 14:55:40 <Timberwolf> "expose player-available feature xyz to GS" is probably the best chance of finding an agreed-useful suggestion that someone cares enough to implement :) 14:55:59 <_dp_> pfft, what I come up with is quite often not implementable :p 14:56:22 <_dp_> Timberwolf, have you actually used GS? it sucks for pretty much everything 14:56:50 <Timberwolf> Yeah, I find myself working around things a lot. 14:57:09 <andythenorth> _dp_ we should get a newsletter :) 14:57:18 <Timberwolf> It does work, but my recollection is a lot of contracts that don't quite line up between different areas. 14:57:19 <andythenorth> we're becoming a broken record 14:57:32 <andythenorth> the channel will start auto-kicking us when we type 'GS' 14:57:59 <_dp_> andythenorth, yeah, and a certain someone when he types "newgrf" :p 14:58:03 <Timberwolf> I can't remember what it was where I was getting something from one place for the Villages Is Villages economic stuff and going, "argh, why does this use a completely different format"? 14:58:57 <Timberwolf> The underlying answer is probably going to involve various combinations of "Chris Sawyer", "486", "4MB" and "data structure" in most cases. 15:02:51 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfSoP 15:14:00 *** Wormnest has joined #openttd 15:20:11 <milek7> >pull requests submitted will be reviewed, and if good enough quality will be merged. 15:20:20 <milek7> well, do you really want to review such patchsets? ;p 15:33:28 <nielsm> narrow in scope and fixes a real problem? sure 15:33:38 *** virtualrandomnumber has joined #openttd 15:34:29 <glx> #8210 needs a review btw :) 15:41:16 <milek7> but what's real problem? 59 grfs? 64 cargos? 16 companies? all of it, none? 15:45:15 <glx> and finally only one type of train is built at the end ;) 15:57:58 <nielsm> just for the heck of it I tried adding more or less all the train newgrfs I have around, just to see what the vehicle selection would look like: https://0x0.st/iVva.mp4 15:58:06 <nielsm> I'm not sure why anyone would want to do that 16:00:36 <nielsm> not to mention the cost balancing act having multiple vehicle sets loaded is, all of them are internally balanced differently, so playing "rationally" (for maximum profit) usually one of the loaded sets will be preferrable to the rest and then the rest may as well not be there anyway 16:06:37 *** iSoSyS has joined #openttd 16:07:55 <planetmaker> nielsm, on a huge map with many companies, and company-limitation on which vehicles to build... it might make sense. You can also hide vehicles to make it then bearable again for the single companies 16:10:16 <_dp_> oh, I recently had an idea where it makes perfect sense actually 16:10:45 <_dp_> have like rpg server that runs about forever and takes a lot of grind to unlock stuff like new vehicles 16:11:06 *** iSoSyS has quit IRC 16:11:34 <_dp_> though that will run into max company problem way sooner than into grf limit xD 16:12:15 <nielsm> so you're saying we should be working on the 250 companies patch 16:12:28 <nielsm> (a bunch of values reserved for non-company owners) 16:12:56 <_dp_> not rly, it's just another crazy idea, I have them all the time xD 16:13:11 <_dp_> though I guess having > 15 companies would be nice sometimes 16:16:57 *** hamstonkid[m] has joined #openttd 16:19:29 <milek7> https://github.com/Milek7/OpenTTD/tree/more_companies 16:19:32 <glx> limit for companies used to be 8, now it's 15 because company colors and 8bits palette 16:19:39 <Eddi|zuHause> that requires fiddling with map array stuff, especially on tiles that store multiple companies (road,tram,stop) 16:19:43 <milek7> probably bitrotten because of NRT stuff 16:20:13 <nielsm> yeah roads have lots of owners 16:20:29 <glx> yeah map often use 4 bits only for owner 16:20:57 <glx> because there's only 15 companies 16:21:04 <Eddi|zuHause> you're gonna get a lot of dev vetos on making the map array bigger 16:22:00 <nielsm> the map array needs to go 16:22:18 <glx> stacked data per tile ;) 16:22:24 <planetmaker> time to un-earch michi's old NewMapArray branches :P 16:22:40 <planetmaker> (or however exactly it was/is called) 16:22:59 <milek7> "m1 bit 7 and m6 bits 1..0 and m1 bits 4..0: owner" 16:23:29 <planetmaker> http://www.icosahedron.de/openttd/git/newmap.git <-- only 9 years old :P 16:23:39 <LordAro> i'm pretty sure he updated it for GH 16:31:53 <milek7> that window though.. 16:31:55 <milek7> https://i.imgur.com/Q7FG8li.png 16:32:02 <nielsm> :D 16:33:37 *** Progman has joined #openttd 16:33:53 <Eddi|zuHause> i keep forgetting that this cargodist overlay existed 16:33:58 *** virtualrandomnumber has quit IRC 16:36:36 <_dp_> replace map array with map map :p 16:38:38 <FLHerne> Eddi|zuHause: How do you play without it? 16:38:56 <Eddi|zuHause> i haven't actually played in like 5 years 16:39:10 <milek7> yeah, it won't rebase cleanly due to NRT changes 16:40:18 <Eddi|zuHause> as much as the map array is a problem with extending the game, its rigid structure is probably the reason why the game has any performance at all, making these requests for expansion possible 16:41:45 <nielsm> the weird bitstuffing going on is imo also an impediment to understanding the code and extending with features 16:41:58 <_dp_> Eddi|zuHause, I don't think it will change performance much if player-owned stuff moves out 16:42:18 <nielsm> such as the same data sometimes being in different locations depending on the tile type 16:42:56 <planetmaker> Well, but even ownership is more than one per tile :) 16:43:23 <nielsm> owns land, owns railway track, owns road, owns tramway, owns station 16:43:31 <nielsm> several parts to it 16:43:37 <Eddi|zuHause> but keeping all the data in the same place might mean less than optimal space usage 16:43:39 <andythenorth> meanwhile 16:43:45 <andythenorth> official Android port? o_O 16:43:59 <Eddi|zuHause> andythenorth: are you maintaining it? 16:44:09 <nielsm> but everything except the land itself is a thing on top of the tile, and if objects on a tile were separated out from the base land in a "stack", could make sense 16:44:14 <milek7> why even Tile and TileExtended separate? 16:44:29 <nielsm> because of powers of 2 16:44:30 <_dp_> I've no idea how people manage to play it on android 16:44:31 <Eddi|zuHause> there's really 2 parts to the android port: the build/distribution, and the UI 16:44:40 <_dp_> very not touchscreen game imo 16:45:11 <nielsm> Tile and TileExtended are separate to avoid having a 12 byte large structure, which is annoying to index into an array of 16:45:14 <Eddi|zuHause> both need to be separated out and merged independently 16:45:25 <nielsm> so instead there is an array of 8 byte structs and one of 4 byte structs 16:45:29 <milek7> but you could have 16 byte one? 16:45:45 <nielsm> yeah if the landscape was extended with another 4 bytes they could be merged 16:46:00 <Eddi|zuHause> milek7: it was decided against a 16 byte one when going from 8 bytes to 9 bytes, as that would be doubling the data 16:46:19 <milek7> I guess that separation also increases cpu cache misses 16:46:52 <Eddi|zuHause> that's probably wild speculation 16:47:02 <milek7> yes :) 16:47:23 <nielsm> I think my idea of (also) making the landscape tiled instead of a single long array will help CPU cache 16:47:49 <nielsm> since you have better proximity between row-adjacent tiles 16:48:34 <Eddi|zuHause> yes, something like 16x16 superblocks or something, but that makes finding neighbouring tiles non-trivial 16:48:53 <nielsm> yep it makes indexing weirder 16:48:59 <_dp_> quadtree xD 16:49:39 <Eddi|zuHause> quadtree doesn't help in "for next tile in Y direction, just +256 and test for VOID" 16:50:11 <_dp_> Eddi|zuHause, is that even a thing? 16:50:20 <_dp_> and test for void can be done without any map at al 16:50:26 <Eddi|zuHause> yes, that's how it works currently 16:50:51 <Eddi|zuHause> with 256 being a variable, of course 16:51:50 *** Smedles has quit IRC 16:52:25 <Eddi|zuHause> _dp_: the vast majority of tile operations is "go 1 tile into {+|-}{X|Y} direction". you want that to be as efficient as possible 16:53:49 *** Smedles has joined #openttd 16:54:16 <_dp_> Eddi|zuHause, that's questionable... if anything tile loop is random 16:54:39 <_dp_> and slowest part is pf anyway, so as long as it's optimized everything should be fine 16:54:51 <Eddi|zuHause> tileloop is not "random" random 16:55:37 <Eddi|zuHause> it's also mostly a (current tile)+(fixed offset) operation 16:56:23 <_dp_> Eddi|zuHause, lol, sure when tile is integer everything is offset xD 16:56:49 <Eddi|zuHause> just "fixed offset" is chosen in a way that avoids straight lines 16:57:10 <Eddi|zuHause> it's more akin to knight's movement in chess 17:03:45 <FLHerne> Eddi|zuHause: Why would you test for VOID rather than just knowing how big the map is? 17:04:23 <Eddi|zuHause> FLHerne: because that's a less expensive operation 17:05:11 <FLHerne> Really? I find that hard to believe tbh 17:05:17 <Eddi|zuHause> FLHerne: testing for VOID is just reading a memory location, whereas checking whether you crossed the map border means decomposing TileIndex into X and Y components and checking each one individually 17:05:42 <FLHerne> You've got an extra branch, but it's a really short one, and compilers are good at optimizing those into various things 17:05:58 <Eddi|zuHause> you're trading memory (one line of tiles at each end of the map) for speed 17:06:06 <Timberwolf> Branches are weird for optimisation. 17:06:21 <Timberwolf> If they're consistently the same result, they may as well not be there on a modern CPU. 17:06:36 <Timberwolf> If they aren't... it's one of the slowest things you can do. 17:07:11 <Eddi|zuHause> Timberwolf: mostly they'll nowadays just execute both branches and throw away one result once they know which branch should have been taken 17:07:58 <FLHerne> Timberwolf: I mean, simple branches tend to be optimized into a pile of SELs or so 17:08:11 <_dp_> I bet it actually depends on a context, either can be faster depending on how well it can be optimized 17:08:11 <FLHerne> And then you don't have a branch at all 17:08:23 <Eddi|zuHause> which is how we ended up with "speculative execution" abuse attacks like spectre 17:08:35 <milek7> on the other hand you have extra memory access in region somewhere kilobytes near 17:09:19 <milek7> but map size check is simple divide and bounds check (which should probably be cached as frequently used) 17:09:29 <milek7> of course all speculation :) 17:10:21 <Eddi|zuHause> well, you could go all dynamic programming on it and make a giant lookup table for (tile|direction) whether that step would take you out of the map :p 17:11:02 <Eddi|zuHause> that's 4 bits per tile 17:11:38 <Timberwolf> Must... not.. get... distracted... into.. low-level... optimisation... rabbithole. 17:11:49 <milek7> ..and another memory access 17:12:03 <Eddi|zuHause> but since that's then decoupled from the map data, it might be another cache miss 17:13:30 *** frosch123 has joined #openttd 17:21:08 *** gelignite has quit IRC 17:47:10 *** keoz has quit IRC 17:57:37 *** urdh has quit IRC 18:02:04 *** Flygon has quit IRC 18:03:00 *** derF_C has joined #openttd 18:09:35 *** Wolf01 has joined #openttd 18:10:22 <Wolf01> Ha! Late for buying lego parts, bricks&pieces reopened today for Italy 18:13:12 *** Compu has joined #openttd 18:27:31 <nielsm> https://www.youtube.com/watch?v=SFv8Wm2HdNM 18:27:58 <nielsm> I kinda like that talk 18:29:22 *** gelignite has joined #openttd 18:32:37 <TrueBrain> glx : still expected nightly fails? (Just checking :D) 18:32:50 * andythenorth reimplements FIRS with GOTO 18:38:47 *** jottyfan has joined #openttd 18:39:34 *** jottyfan has quit IRC 18:59:27 <glx> TrueBrain: yeah, I'm waiting for #8210 approval :) 19:04:39 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfSDS 19:07:00 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8210: Revert f51e66f: creating zip bundle fails for MacOS https://git.io/JfSDF 19:08:31 *** urdh has joined #openttd 19:10:04 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 merged pull request #8210: Revert f51e66f: creating zip bundle fails for MacOS https://git.io/JfDpk 19:42:38 *** virtualrandomnumber has joined #openttd 19:45:08 *** virtualrandomnumber has quit IRC 19:57:48 *** jottyfan has joined #openttd 20:08:20 *** SpComb has quit IRC 20:23:16 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS9M 20:33:43 *** WormnestAndroid has quit IRC 20:34:14 *** jottyfan has quit IRC 20:34:19 *** WormnestAndroid has joined #openttd 20:54:22 *** nielsm has quit IRC 20:54:22 *** Gustavo6046 has quit IRC 20:55:14 *** frosch123 has quit IRC 21:09:22 *** SpComb has joined #openttd 21:15:24 *** andythenorth has quit IRC 21:16:47 *** Smedles has quit IRC 21:18:05 *** Smedles has joined #openttd 21:19:32 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS7R 21:24:26 *** arikover has quit IRC 21:33:16 *** Wolf01 has quit IRC 21:37:25 *** sla_ro|master has quit IRC 21:42:52 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 21:52:38 *** Samu has quit IRC 21:59:05 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 22:24:25 *** Markk has quit IRC 22:27:20 *** Gustavo6046 has joined #openttd 22:32:27 *** Markk has joined #openttd 22:36:53 *** WormnestAndroid has quit IRC 22:37:26 *** WormnestAndroid has joined #openttd 22:39:33 *** nielsm has joined #openttd 22:40:10 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 22:43:43 *** Gustavo6046 has quit IRC 22:44:04 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 22:49:06 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 22:49:47 *** Gustavo6046 has joined #openttd 22:57:37 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 23:00:02 *** spnda has quit IRC 23:00:05 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfSbo 23:25:38 *** Progman has quit IRC 23:40:07 *** Wormnest has quit IRC 23:48:04 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz updated pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfS3n 23:56:31 <DorpsGek_III> [OpenTTD/OpenTTD] techgeeknz commented on pull request #8214: WIP: Refactor gfx engine's dirty block system https://git.io/JfSAm