Config
Log for #openttd on 25th June 2023:
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

Powered by YARRSTE version: svn-trunk