Times are UTC Toggle Colours
00:14:46 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #11069: Fix #11067, ed83c4b: Don't start competitors during map generation https://github.com/OpenTTD/OpenTTD/pull/11069 00:33:39 <iqTop[m]> <peter1138> "They have updated their comment..." <- If I've been passive-aggressive like this other guy you mention, I apologize. I may have been unwillingly intoxicated by incorrect medication from 2017 to 2022, but right now if I screw up then that's on me. 00:33:39 <iqTop[m]> As for the topic in question, sounds to me like he doesn't want to admit that his ISP is shit. Probably pays 0 USD or so because its their only option for fast internet. 00:48:38 <iqTop[m]> That, or he's at college and the firewall blocks outgoing connections. 00:50:15 <iqTop[m]> If it is an ISP he pays for, "his ISP is shit" is just me guessing he has an ISP that is so draconian that they won't let him host game servers from home. 01:56:32 *** Wormnest has quit IRC 02:35:37 *** D-HUND has joined #openttd 02:38:52 *** Flygon has joined #openttd 02:39:14 *** debdog has quit IRC 02:43:45 *** D-HUND is now known as debdog 03:32:56 *** keikoz has joined #openttd 04:15:43 *** tokai has joined #openttd 04:15:43 *** ChanServ sets mode: +v tokai 04:22:52 *** tokai|noir has quit IRC 04:29:31 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #11069: Fix #11067, ed83c4b: Don't start competitors during map generation https://github.com/OpenTTD/OpenTTD/pull/11069#pullrequestreview-1496891113 05:20:48 *** nielsm has joined #openttd 05:21:19 *** HerzogDeXtEr has joined #openttd 07:28:29 *** Wolf01 has joined #openttd 07:42:40 <pickpacket> hahaha. I've made it so that no company can buy exclusive transport rights when another company owns it. In a way. Another company can still *pay for it*, but it just doesn't get it π€£ 07:42:59 <pickpacket> will have to check that bit of code. I guess that's maybe in the GUI somewhere? 07:55:52 *** Etua has joined #openttd 07:59:32 <jfs> the right thing is to handle the command such that it fails, and also add the same check in the UI so the command gets disabled when it would fail 08:01:49 <pickpacket> I've made it so that it does fail, but apparently the money is spent either way so I'll have to look at that. But I'm looking at how to disable it in the GUI if it would fail 08:01:50 <jfs> the important thing to keep in mind is that the function for a command is called twice: first for test, then for actual execution. you want to verify all the preconditions in the test run, so it doesn't react execution, but also still test the preconditions in the real run. 08:02:08 <pickpacket> wth happened to GH? It's slow as molasses 08:02:19 *** Etua has quit IRC 08:04:10 <pickpacket> and it doesn't show line numbers in code files anymore! 08:04:51 <pickpacket> and #L anchors don't work 08:05:13 <ahyangyi> New and improvedβ’ UI 08:05:41 <pickpacket> f***in' hell... 08:06:06 <pickpacket> check if this link works: https://github.com/OpenTTD/OpenTTD/blame/master/src/town_cmd.cpp#L3336 08:06:36 <pickpacket> I want to change it to: 08:06:36 <pickpacket> if (cur == TACT_BUY_RIGHTS && !_settings_game.economy.exclusive_rights || t->exclusive_counter != 0) continue; 08:07:08 <pickpacket> but the negation melts my brain... "is the company NOT able to buy exclusive rights" 08:07:19 <pickpacket> would this line be correct? 08:09:06 <jfs> it's better to add parentheses around the "or" expression to be clear 08:09:25 <ahyangyi> Or break it into two if statements 08:09:38 <jfs> or even break it down to sub-conditions 08:09:43 <pickpacket> I just did added parenthesis a second ago :D great minds think alike 08:10:01 <pickpacket> I'll try compiling this and hopefully have time to try it later today 08:10:10 <ahyangyi> /* Is the company not able to buy exclusive rights ? */ 08:10:10 <ahyangyi> if (cur == TACT_BUY_RIGHTS && !_settings_game.economy.exclusive_rights) continue; 08:10:10 <ahyangyi> /* Does someone else already have the exclusive right? */ 08:10:10 <ahyangyi> if (t->exclusive_counter != 0) continue; 08:10:12 <ahyangyi> like this? 08:10:26 <jfs> if (cur == TACT_BUY_RIGHTS) { if (!_settings_game.economy.exclusive_rights) continue; if (t->exclusive_counter != 0) continue; } 08:10:29 <ahyangyi> Just to avoid dealing with the negation 08:11:03 <pickpacket> I don't think that would work, because if the first if statement matches it'll never reach the second 08:11:21 <ahyangyi> Well, both result in `continue` 08:11:31 <ahyangyi> oh 08:11:46 <ahyangyi> I saw nielsm's version and now understand what's wrong 08:13:00 <pickpacket> hmm? 08:13:49 <ahyangyi> I missed the parenthesis π 08:15:05 <pickpacket> :) 08:16:04 <pickpacket> where do I find nielsms version? 08:16:29 <jfs> 10 lines above 08:16:57 <jfs> jfs = nielsm 08:18:03 <jfs> ahyangyi: if you use @-mentions the IRC bridge will translate the names, and otherwise they might not match up 08:18:42 <pickpacket> line 3326, Joel-Milligan? 08:20:07 <pickpacket> anyway, I need to go do other stuff :) cya 08:20:15 <pickpacket> and thanks for all the input! 08:29:45 <truebrain> seems that ~40% cached is the number we will have to live with π Still, 40% of the content served SUPAH fast to the end-user .. and only 60% slightly less (but still incredibly) fast π 08:30:50 <truebrain> zbase and abase combined are good for 60% of the used bandwidth of yesterday π 08:31:10 <truebrain> (and for those who missed my daily updates, context is BaNaNaS CDN) 08:31:44 <truebrain> also when looking at last week ... abase + zbase: 1TB. All traffic: 1.6TB 08:31:54 <truebrain> we always knew it was a lot, but now I know exactly how much is a lot π 08:37:36 <truebrain> (and before anyone asks, with Cloudflare the egress is free, so we don't actually care anymore how big the files are π ) 08:37:41 <jfs> is it already compressed? if not, would it be possible to optionally negotiate a compressed version using one of the algorithms already included in the game for savegames? (would that actually gain anything significant?) 08:37:54 <truebrain> yes, they are compressed. 08:38:08 <truebrain> since the day of the birth of BaNaNaS, all content has been compressed π 08:38:14 <ahyangyi> in zip, I think 08:38:20 <truebrain> no, in .tar.gz 08:38:25 <ahyangyi> Alright 08:38:29 <truebrain> why would we ever do a zip, if we want to be cross-platform π 08:38:32 <ahyangyi> makes sense 08:38:53 <ahyangyi> Somehow the last time I got the download size wrong, I found the zipped version has the "right" size 08:39:04 <ahyangyi> by looking at the most significant digit only π 08:39:10 <ahyangyi> So, I learned the wrong lesson 08:39:15 <truebrain> π 08:39:45 <jfs> I wonder how much of those abase+zbase downloads are "select and download EVERYTHING" blindly 08:40:01 <truebrain> without joking, zip is a tar and gz in one, which is somewhat annoying to deal with. Our content is stored on-disk as a tar, as it is easy to find files. And on the wire it uses gzip over that to make sure it is as small as possible 08:40:27 <truebrain> (you can't seek in a zip-file) 08:40:44 <ahyangyi> And zip's handling of file name encoding is weird 08:40:53 <dP> tar.gz? I thought they were just tar, unless game extracts gz aftter download 08:41:13 <jfs> actually you can seek in a zip file, as the original format. zip is a concatenation of compressed files, while tar.gz is a compressed concatenation of files 08:41:27 <jfs> seek as in, decompress a single file from the archive 08:41:28 <truebrain> have you ever tried it? It is fun to try it in a zip-file 08:41:33 <truebrain> they really fucked up many concepts in a zip π 08:42:46 <truebrain> if I remember correctly, zip was that format that had its dir-listing at the end of the file 08:42:54 <truebrain> which is just awesome .. as to get there, you need to walk all the files first 08:43:05 <jfs> anyway, my suggestion was about using more than just gzip compression for the content too, like allowing xz or whatever 08:43:11 <truebrain> a tar on the other hand is streaming .. you can walk it while reading it 08:43:34 <truebrain> jfs: all attempts thus far shown the difference is in the single digits percentage wise 08:43:51 <truebrain> a few people have tried over the last few years even, as when we talk about BaNaNaS, people bring this up π 08:44:01 <truebrain> but as there are a lot of images in these bloody GRFs, it is not really helping 08:44:56 <LordAro> truebrain: thoughts on doing a dev-blog on all the infrastructure stuff? (once it is actually complete) 08:45:13 <truebrain> LordAro: planning to; as people tend to find those interesting, history has shown 08:45:21 <truebrain> but I first need to finish it, and this CDN is just being a dick 08:45:38 <dP> hm, 273mb vs 313 for abase, that gzip barely does anything... 08:45:42 <jfs> the directory in a zip file is at the end so you can extend the archive with more data without having to rewrite the entire thing (just overwrite the directory and add a new one) or have a fragmented directory. and also I'm quite sure it's designed so you can seek to a fixed offset from the end of the file to find a "footer" which points to the actual start of the directory, so you can find the 08:45:42 <jfs> start of the directory with at most two seeks 08:45:43 <truebrain> jfs: either way, don't let past experience hold you back, and try it out π 08:45:58 <dP> would be much better to use some modern image compression in grf format than trying to gz/xz over lz77 08:46:11 <jfs> GRFv9 when 08:46:26 <LordAro> truebrain: :) 08:46:35 <truebrain> jfs: That wouldn't surprise me if that works. I just remember it is a bitch to work with π 08:47:05 <truebrain> But yeah, actually changing how GRF does compression would be much more helpful here 08:47:23 <jfs> it's also how self-extracting archives work btw, by having the directory at the end of the file you can quickly verify that the file contains an archive and begin working with that 08:48:07 <truebrain> but it is the reason tar and gzip are called "streaming formats", and zip is not π 08:48:19 <truebrain> I know there are advantages 08:48:19 <jfs> a hypothetical GRFv9 could be insane 32bpp only even 08:48:35 <truebrain> no, a better compression also really helps for things like iron horse 08:48:38 <truebrain> percentage wise 08:48:43 <truebrain> in absolute numbers it is non-sense 08:49:04 <truebrain> if we ignore the BaNaNaS bandwidth etc for a moment, the thing that mostly gets to me is how much storage space on disk OpenTTD uses for those formats 08:49:14 <truebrain> like abase is 300+ MiB 08:49:37 <truebrain> and as we just established, storing it compressed would help a bit, but would slow down the game a lot, so netto not worth it at all 08:49:54 <truebrain> so having a GRF format that slims that down, would be helpful overall; not just for transmissing of files 08:50:54 <truebrain> but I have a suspicion, but never confirmed it, that it would be best to first stitch together images in a GRF to a bigger image, and compress that .. as compressing a lot of small images rarely is useful 08:50:54 <jfs> right now the GRF saves each sprite as an individual PNG (or RLE bitmap), right? 08:51:12 <jfs> I wonder if there would be savings from saving a single big spritesheet PNG and then pointing into sections of that 08:51:35 <LordAro> regardless of grfv9, i don't think we could get away with "reencoding" all the existing GRFs? 08:51:56 <LordAro> because things like abase & zbase are functionally dead and won't ever get updated otherwise 08:51:58 <jfs> I doubt bananas license allows that yea 08:52:00 <dP> yeah, combining images should be much better for compresion 08:52:04 <dP> maybe not for lz77 though 08:52:24 <truebrain> jfs: we think the same thing here π 08:53:42 <dP> LordAro: who needs a/zbase, just add compression before opengfx2 dies xD 08:54:51 <LordAro> i still think we should "forcibly" deprecate & hide one of z/abase 08:55:15 <truebrain> people keep saying that, but nobody actually ever does π 08:55:27 <LordAro> :p 08:55:43 <truebrain> like everytime someone mentions that, they are looking at some imaginary figure to actually do it 08:55:51 <truebrain> "I have this idea, but I don't dare to burn myself on it" π π π 08:55:53 <truebrain> hihi, sorry π 08:57:22 <andythenorth> it would be amusing to see the sea of pitchforks 08:57:29 <andythenorth> 'amusing' 08:57:36 <LordAro> yes 08:58:09 <truebrain> jfs: it is much worse, but it took me a bit of time to actually find the document specifying it .. as it isn't part of the NewGRF specs π 08:58:09 <truebrain> https://github.com/OpenTTD/grfcodec/blob/master/docs/grf.txt#L97 08:58:13 <dP> just sneakily send opengfx2 instead, how would they know? :p 08:59:33 <truebrain> basically, it even depends on the person writing the GRF if there is any compression at all 08:59:47 <truebrain> images are stored in RGBRGBRGB or worse: RGBARGBARGBA format 08:59:58 <andythenorth> compression affects compile time iirc 09:00:02 <LordAro> also it opens the idea of "curation", which is a bit of a rabbithole in a minefield 09:00:03 <truebrain> so I would guess, anything you do here, would help a lot π 09:00:06 <andythenorth> I did test various flags 09:00:17 <truebrain> LordAro: it is, yes π 09:00:51 <truebrain> the silliest thing is, that OpenTTD ships with libpng for how many years now? π 09:00:55 <dP> truebrain: there is even RGBAM 09:01:01 <truebrain> but strictly seen it is optional 09:01:19 <truebrain> you just can't load heightmaps and making screenshots takes even longer π 09:01:31 <truebrain> but you can still use NewGRFs! π 09:02:01 <andythenorth> hmm 09:02:06 <truebrain> the compression was fully written for palette images, where the exceptation was that a lot of pixels in a row are the same 09:02:10 <truebrain> it was not meant to be used with 32bpp π 09:02:30 <truebrain> I think the LRE part in the lz77 variation used, is never actually triggered in 32bpp GRFs π 09:05:24 <truebrain> so yeah jfs , if I were you, I would fiddle around there; could be a huge diskspace saver π And how we deal with existing content .. let's tackle that once it becomes actual π 09:05:41 <andythenorth> iron-horse.grf is 28.7 MB 09:05:51 <andythenorth> zipped it's 3.5 MB 09:05:57 <jfs> I'm wondering if I should rather work on, say, multithreading or deep water first tho 09:05:58 <andythenorth> what's the ratio there? π 09:06:02 <dP> there is also in-memory lre, though don't remember if works for transperent only or other pixels too 09:06:22 <jfs> (psst, https://github.com/OpenTTD/OpenTTD/pull/7786 and https://github.com/OpenTTD/OpenTTD/pull/11060 are ready!) 09:06:23 <andythenorth> hmm 8.2 compression ratio 09:06:26 <truebrain> jfs: welcome in the world of "oeh, there are so many things we could work on" π I know that pain π 09:07:24 <andythenorth> I've tried uploading zips to bananas instead of tar.gz, but (a) I don't know if it makes any difference at the bananas end (b) bananas won't accept a zip produced with Apple's compressor 09:07:40 <truebrain> BaNaNaS should accept zips 09:07:50 <andythenorth> yes but Apple... 09:08:16 <jfs> could it be because apple's adds those extra hidden dirs and files inside to store attributes? 09:08:16 <truebrain> Python's `zipfile` should be able to read it; even Apple's π 09:09:30 <truebrain> but you can always try it andythenorth : start python and run `import zipfile; z = zipfile.Zipfile("yourname.zip"); z.infolist()` 09:09:54 <andythenorth> hmm I just tested uploading Horse, bananas accepts it 09:09:59 <truebrain> (to be clear, the backend unpacks the zip, and repacks it with a strong tar.gz when all is done) 09:10:03 <andythenorth> the zip contains only the grf, nothing else 09:10:16 <andythenorth> normally the zip contains other things, I will explore more 09:10:37 <truebrain> worst case, BaNaNaS web shows you those files, and you need to remove them again 09:10:45 <truebrain> after uploading a zip, you only see the content of the zip 09:10:52 <truebrain> even without folders they might have been in 09:11:14 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1122453943209959455/image.png 09:11:14 <andythenorth> ok it's choking when it's a folder 09:11:29 <andythenorth> are those nested paths? 09:11:49 <truebrain> we don't strip out paths? I thought we added that in the end .. hmm .. so it is done a step later, owh well 09:12:03 <truebrain> it should really already been done π 09:12:15 <truebrain> the reason it doesn't pick up on those `license.txt` etc 09:12:30 <truebrain> anyway, you can see here you can just remove the special mac files π So your (2) seems to be bad memory, not an actual truth π π 09:13:29 <truebrain> owh, yeah, I remember now .. for AIs and GSes you do want folder support, so what it does it scans the whole archive if everything is in a single folder 09:13:32 <truebrain> if it is, it removes that folder 09:13:36 <truebrain> MacOS is ruining that for you π 09:13:39 <andythenorth> maybe I make my own zip, not using Apple's utility 09:13:53 <andythenorth> last time I decided this didn't matter 09:14:05 <andythenorth> .tar.gz will do, just slow uploads 09:14:18 <truebrain> gzip and zip should be about the same size 09:14:22 <truebrain> otherwise, use gzip -9 π 09:14:29 <truebrain> ah, sneaky edit 09:14:30 <truebrain> pfff 09:14:33 <truebrain> you can also upload a .tar.gz 09:14:39 <andythenorth> yeah, these aren't things I really understand π 09:14:55 <andythenorth> alberth wrote the part of the makefile that makes the release 09:14:59 <truebrain> haha 09:15:46 <andythenorth> https://github.com/andythenorth/iron-horse/blob/main/Makefile#L123 09:15:55 <andythenorth> there's a zip target also that I never use 09:18:50 <DorpsGek> [OpenTTD/bananas-api] TrueBrain opened pull request #395: Fix: ignore __MACOS in zips/tarballs, as it only contains MacOS metadata https://github.com/OpenTTD/bananas-api/pull/395 09:21:07 <truebrain> totally untested, but we will do that in a sec on preview 09:21:46 <truebrain> andythenorth: funny, that is a zip-file made by someone who doesn't use Windows π 09:22:05 <truebrain> (in general, zip-files don't contain a second folder in them, but all files are in the root; this in contrast to tar-files, where there is first a folder in them) 09:22:15 <LordAro> truebrain: ...MACOSX vs MACOS ? 09:22:43 <DorpsGek> [OpenTTD/bananas-api] TrueBrain updated pull request #395: Fix: ignore __MACOS in zips/tarballs, as it only contains MacOS metadata https://github.com/OpenTTD/bananas-api/pull/395 09:22:45 <truebrain> did I mention the "untested" part? π π 09:22:46 <truebrain> tnx 09:24:29 <andythenorth> π 09:28:14 <truebrain> andythenorth: please go to https://bananas-preview.openttd.org/, login, and upload that zip file again please 09:28:35 <truebrain> just the upload and hitting "auto fill" is enough; no need to actually publish it 09:29:49 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1122458618105696356/image.png 09:30:03 <andythenorth> that's a directory zipped 09:30:06 <andythenorth> works fine eh 09:30:18 <truebrain> would that make your life better? 09:30:25 <andythenorth> faster uploads π 09:30:43 <truebrain> so if LordAro can hit the approve button, that will be deployed moments after π 09:31:09 <andythenorth> ok that's our good deed for the day, now we watch TV? π 09:31:24 <truebrain> yes 09:31:43 <truebrain> such a simple problem, so easy to fix; I had no clue you ran into that π 09:34:30 *** Timberwolf has quit IRC 09:43:29 *** keoz has joined #openttd 09:44:58 *** keikoz has quit IRC 10:02:25 <DorpsGek> [OpenTTD/bananas-api] LordAro approved pull request #395: Fix: ignore __MACOSX in zips/tarballs, as it only contains MacOS metadata https://github.com/OpenTTD/bananas-api/pull/395#pullrequestreview-1497001291 10:02:28 <DorpsGek> [OpenTTD/bananas-api] TrueBrain merged pull request #395: Fix: ignore __MACOSX in zips/tarballs, as it only contains MacOS metadata https://github.com/OpenTTD/bananas-api/pull/395 10:03:06 <truebrain> cheers 10:38:16 *** Timberwolf has joined #openttd 10:58:02 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11066: Codechange: Use std::optional for GRFConfig::GRFError https://github.com/OpenTTD/OpenTTD/pull/11066 10:58:43 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11065: Change: Allow text shadow on WWT_EMPTY/WWT_TEXT to extend horizontally. https://github.com/OpenTTD/OpenTTD/pull/11065 11:02:36 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11022: Fix #11016: Use after free in network invalid packet error path https://github.com/OpenTTD/OpenTTD/pull/11022 11:02:39 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed issue #11016: [Bug]: Use after free in network invalid packet error path https://github.com/OpenTTD/OpenTTD/issues/11016 11:09:02 <andythenorth> hmm 11:09:11 <andythenorth> need to copy the town growth algorithm into GS 11:09:33 <andythenorth> TOWN_GROWTH_NORMAL is fine, but I want to multiply it by a factor 11:11:55 <andythenorth> grepped src for 0x10000 but can't find the town growth algorithm that way 11:12:38 <andythenorth> maybe TownTickHandler gets me closer 11:12:52 <DorpsGek> [OpenTTD/team] Naeso opened issue #430: [fr_FR] Translator access request https://github.com/OpenTTD/team/issues/430 11:13:56 <DorpsGek> [OpenTTD/team] Naeso opened issue #431: [fr_FR] Translator access request https://github.com/OpenTTD/team/issues/431 11:14:58 <talltyler> andythenorth: have you seen #11068? It could use a reference to your complementary/tint lookups for Horse π 11:14:58 <talltyler> https://github.com/OpenTTD/OpenTTD/pull/11068 11:15:14 <talltyler> I also think Iβve seen you suggest that setting before 11:15:37 <andythenorth> interesting 11:17:45 <andythenorth> Horse has mappings cc1 -> cc2 tint 11:18:06 <andythenorth> not sure that's what the PR is referring to 11:18:16 <andythenorth> hmm can't figure out what GetNormalGrowthRate is doing 11:27:18 *** Timberwolf has quit IRC 11:38:19 <jfs> GRFv9 fever dreaming: company coloring by base image, and an RGBA overlay for company color. the company color overlay is multiplied by the actual company color, so a pure grayscale (R=G=B) would produce a pure company color scale, but offset colors would cause hue variations... maybe this won't work as well in practice 11:39:51 <talltyler> That sounds like less-user-friendly RGBCC π 11:40:46 <peter1138> Multiply colours doesn't usually result in hue variations, just weirdness. 11:41:03 <jfs> you could just use one grayscale+alpha overlay to make CC, but I think having some way to shift the hue will be useful 11:41:24 <jfs> and yeah you're right, it won't give useful results that way 11:42:23 <peter1138> With 2CC the player can set both the primary and secondary hues, with your method they get to a primary and anything else is fixed, relative to the primary. 11:43:14 <jfs> I didn't get to the part where you can add a second overlay for the second CC 11:44:11 <andythenorth> I talked myself out of 3CC π 11:44:13 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1122492442248220743/image.png 11:44:21 <andythenorth> variants instead, with many colours 11:45:09 *** gill6151 has quit IRC 11:46:48 <AlphaGamma3521> Lovely 11:58:44 <DorpsGek> [OpenTTD/team] glx22 commented on issue #431: [fr_FR] Translator access request https://github.com/OpenTTD/team/issues/431 12:05:27 *** gill6151 has joined #openttd 12:13:48 *** Timberwolf has joined #openttd 12:27:12 <andythenorth> maybe I should just make my own town growth rules 12:27:29 <andythenorth> what are the current rules? I never really understood them 12:28:59 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #11069: Fix #11067, ed83c4b: Don't start competitors during map generation https://github.com/OpenTTD/OpenTTD/pull/11069 12:29:52 <dP> andythenorth: Check simple CB I think it has it copied already 12:30:20 <dP> jfs: Isn't that how rgbam currently works? 12:31:46 <dP> Ah, nvm, didn't notice you're talking hue 12:31:50 <andythenorth> thanks dP https://github.com/TheDude-gh/simplecb/blob/main/town.nut#L109 12:34:49 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11069: Fix #11067, ed83c4b: Don't start competitors during map generation https://github.com/OpenTTD/OpenTTD/pull/11069#issuecomment-1606067604 12:43:24 <andythenorth> hmm 12:43:32 <andythenorth> 'recommended upgrade' property for vehicles? 12:43:41 <andythenorth> expose to a UI filter in autoreplace? 12:43:55 <andythenorth> prop value is just a list of eligible IDs from same grf 12:47:18 *** keoz has quit IRC 12:47:29 *** keoz has joined #openttd 12:48:02 *** gill6151 has quit IRC 12:49:38 *** frosch123 has joined #openttd 12:49:38 <frosch123> andythenorth: https://newgrf-specs.tt-wiki.net/wiki/Callbacks#Autoreplace_vehicle_selection_.2834.29 12:49:46 <frosch123> ttdp had it 15 years ago :p 12:51:01 <andythenorth> π§ 12:51:50 <frosch123> though it was not a "recommendation", but a "newgrf plays the game" 12:51:55 <andythenorth> oh is this magic autorenew? 12:52:03 <andythenorth> seems like