IRC logs for #openttd on OFTC at 2023-05-16
⏴ go to previous day
02:02:26 *** Wormnest has quit IRC (Quit: Leaving)
02:42:12 *** luffy[m] has joined #openttd
02:57:19 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:04:10 *** D-HUND is now known as debdog
05:25:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:36:20 <TrueBrain> and the first non-developer related surveys are arriving; now waiting for enough to make sure analyzing doesn't leak personal information 😄
07:36:16 <pickpacket> TrueBrain: how can I see the survey?
07:39:27 <petern> Oh gosh what is this rabbit hole I have myself in now...
07:42:05 <Rubidium_> pickpacket: given what TB said, I think you have to wait a while before the survey results get published
07:42:40 <pickpacket> Rubidium_: I meant how to participate .)
07:43:29 <petern> It's in Game Options, you need to be on a recent nightly.
07:45:11 <petern> You can tell a developer survey... "played time < 5 minutes"
07:46:48 <petern> "Time paused in a debugger"
07:47:21 <Rubidium_> yeah, I was thinking something similar. But more meta... the longest tick > 10 seconds or so
08:04:34 <TrueBrain> petern: sadly, that would be tracking 😛 But yeah, developers surveys are very easy to spot 🙂
08:06:22 <petern> Disentangling C-style linked lists is fun...
08:06:29 <petern> Wait fun isn't the right word is it.
08:11:30 <Rubidium_> maybe... depends on whether it's "violent or excited activity or argument"
09:01:02 <petern> Hmm, need to free up some space. I guess my WSL is out of control 😄
09:52:12 *** citronbleuv[m] has joined #openttd
10:41:31 *** joey[m]1 has joined #openttd
10:44:32 *** gelignite has joined #openttd
11:07:44 *** peter1138 has quit IRC (Ping timeout: 480 seconds)
11:08:59 *** milek7_ has quit IRC (Ping timeout: 480 seconds)
11:15:58 *** peter1138 has joined #openttd
11:15:58 *** ChanServ sets mode: +o peter1138
11:32:25 <glx[d]> Scoped mode change seems to be the cleanest and simpler way
11:34:08 <glx[d]> And it's similar to test/exec and company impersonation
11:52:55 <pickpacket> orudge: Can I make a request for a new way to donate? Could you add the possibility to buy a "subscription", i.e. a recurring monthly payment?
11:59:06 *** imlostlmao[m] has joined #openttd
12:09:05 <Eddi|zuHause> you mean like patreon?
12:17:54 *** karoline[m] has joined #openttd
12:17:58 <pickpacket> Eddi|zuHause: on patreon I would pay a monthly amount to patreon but openttd would only get paid when they make updates, iirc. I wanted to set up a recurring payment on paypal but apparently the seller has to offer a subscription then
12:18:43 <Eddi|zuHause> why would that be how patreon works?
12:19:58 *** fiddeldibu[m] has joined #openttd
12:29:18 <pickpacket> Because as a user I pay a sum each month to patreon from which all my subscriptions are paid, but some creators publish things every day while others publish twice a year. As a subscriber I may not want to pay a bunch of subscriptions to creators that aren't even active
12:30:00 <pickpacket> bear in mind that it's been years since I checked how patreon works. I may misremember or it may have changed 🤷
12:31:46 <petern> Hmm, why doesn't std::iter_swap work :/
12:31:50 <FLHerne> I think most Patreon subscriptions these days are simply per-month
12:32:21 <FLHerne> but yes, there is/was a "per <release/issue/thingummy>" option
12:33:20 <FLHerne> in this case, OpenTTD has had a fairly steady release cadence and development pace for like 20 years now, so I don't see the advantage
12:34:23 <petern> Remember the days when we didn't have new nightly releases?
12:34:42 <pickpacket> FLHerne: I don't care if it's patreon or another solution. I'd just like to make a recurring monthly donation :)
12:34:44 <FLHerne> per-release would just create spikes in both the game's income and subscribers' payments, and I don't see the benefit to either party
12:35:12 <petern> But yeah, Patreon does do simple monthly.
12:35:24 <pickpacket> could be an option then
12:35:26 <FLHerne> petern: I did say 'fairly'. I admit things have sped up since the immediately pre-GitHub period
12:36:19 <FLHerne> but it's not as if someone's going to subscribe monthly and then be upset that there wasn't a release this month
12:37:21 <FLHerne> and even then, there were annual releases even if the changelogs were a bit shorter, so per-release wouldn't say much
12:37:34 <FLHerne> I assume not "per nightly release" because that would be a bit silly :p
12:37:53 <FLHerne> although it would incentivise fixing the nightlies!
13:12:19 <Rubidium_> and disincentivize translators, as translating might cost them more money :p
13:17:30 <petern> `519dba4e2 (HEAD -> grfconfig-stl) Codechange: Use std::list for GRFConfig lists.` Well
13:19:00 <Rubidium_> with a diffstat of +500,-2000 or something?
13:19:52 <petern> ` 32 files changed, 415 insertions(+), 495 deletions(-)`
13:21:24 <petern> Hmm, remember when we couldn't have two files with the same name, else it blew up VS?
13:22:26 <petern> We have two `game_info.cpp` files and I keep opening the wrong one 🙂
13:34:16 <TrueBrain> so you are now VS? 😄
13:36:43 <petern> "This code was generated by a tool"... perhaps.
14:38:15 <TrueBrain> lol, "fun fact" .. our OVH VPSes handle ~70GB per day atm 😛
14:38:49 <petern> That's... quite a lot.
14:39:03 <petern> Let's add mp3/flac based musicset support too...
14:39:12 <petern> "Uncompressed 24bit 192kHz wav files"
14:39:47 <TrueBrain> hmm, seems for some reason the distribution between the two VPSes is not as fair as it should
14:39:54 <TrueBrain> one does 70GB, the other 10GB
14:40:40 <TrueBrain> which ofc gives the question ... why?! 😄
14:42:36 <TrueBrain> hmm .. it really is a fair `random`
14:43:46 <petern> Hmm, will this router's firmware update...
14:43:58 <petern> 90%, 6.5MB, seems to be taking a while 😄
14:44:46 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
14:45:26 <petern> Wow, it actually did. Last time I tried it ran out of memory/storage.
14:45:47 <TrueBrain> party at your place? 😄
14:46:16 <petern> Well... maybe I should try the latest version first...
14:46:40 <TrueBrain> ah, no, the requests got distributed fair
14:46:45 <TrueBrain> but the requests were not fairly distributed 😄
14:46:53 <TrueBrain> hihi, sorry, that sentence just sounded nice
14:47:02 <TrueBrain> but yeah, just by stupid luck, the big file requests ended up on one
14:48:11 *** jeremy[m] has joined #openttd
14:48:16 *** vista_narvas[m] has joined #openttd
14:48:22 *** wormnest[m] has joined #openttd
14:48:22 <TrueBrain> okay, picking another day it is 70GB vs 70GB 😄
14:48:34 <TrueBrain> that is a massive amount of BaNaNaS content .. more than I expected ..
14:48:57 <TrueBrain> in contrast, the rest of our infra uses ~10GB per day in total, from what I can tell (AWS is not the most clear in telling you this kind of information)
14:49:45 <TrueBrain> owh, make that 20GB .. we also use CloudFront .. still, that difference is insane 😄
14:50:00 <TrueBrain> most likely I discovered this too years ago, but it keeps surprising me
14:53:07 <Rubidium_> petern: you'd almost make a CI check for missing '_t's ;)
14:53:30 <TrueBrain> well, and I see the change to not allow "download all" really helped .. not many people download more than 500 objects per day anymore. That is nice.
14:53:31 <petern> I dunno! It was question rather than request.
14:53:52 <TrueBrain> we are doing it? New PRs postfix with `_t`?
14:54:19 <LordAro> that has been the recent trend
14:54:22 <TrueBrain> also means not more `int` and `uint`?
14:55:44 <petern> int is fine, and technically uint should be unsigned (int) so...
14:55:59 <petern> Anyway, it wasn't me who started it 😉
14:56:14 <TrueBrain> you sure about that? 🙂
14:57:01 <petern> We had uint16_t in OS X stuff for years, at least.
14:57:21 <TrueBrain> I have no issue if we start using _t for everything
14:58:00 <TrueBrain> but yeah, a checker might be nice to hint if we are doing it wrong, as we will forget SO MANY TIMES 😛
14:58:16 <petern> You yourself used it in the ICU stuff too 🙂
14:58:26 <TrueBrain> fully by accident, I promise you
14:58:30 <petern> See, didn't even notice. Hah.
14:58:39 <TrueBrain> pretty sure it isn't in the survey PR
14:58:57 <TrueBrain> at least, when working on OpenTTD, I tend to be careful and use the non-`_t` .. being annoyed every time it exists 😛
14:59:14 <TrueBrain> as when you switch to another project, it doesn't bloody work
14:59:21 <petern> LOL, I was following your example and using _t with new stuff because I thought you had... Oh well 🙂
14:59:41 <TrueBrain> so we created a nice circle there 😄
15:00:20 <petern> Anyway, no reason not to other than having both is a bit jarring (as LordAro mentioned a while ago), but doing it as we add things at least doesn't invalidate a whole load of existing changes.
15:00:47 <petern> But there is also a PR for that if we want to just go the whole hog and not care 🙂
15:01:29 <TrueBrain> what I wrote in that PR, as long as we provide seds and talk to our patch-pack makers (read: JGR), I am pretty sure we are fine to do so either way 🙂
15:02:36 <TrueBrain> lol, the `_t` in my ICU patch were from 3rdparty code I imported 🙂
15:03:10 <TrueBrain> explains why I used it in more places 😄
15:03:19 <TrueBrain> okay, that is funny 🙂
15:03:55 <TrueBrain> owh well .. forwards with `_t` we go! 😄
15:15:42 *** hamstonkid[m] has joined #openttd
15:16:04 *** enick_770 has joined #openttd
15:19:26 *** linda[m]1 has joined #openttd
15:21:04 <JGR> TrueBrain: Don't worry too much about me, my branch should not block you from progressing your own changes
15:21:41 <TrueBrain> No, but useless search replace to just make your life more difficult doesn't help anyone 🙂
15:22:09 <TrueBrain> Small effort for us to make that easier 🙂
15:26:15 <petern> TBH we've probably done more than enough refactoring to make it difficult...
15:27:59 <JGR> If need be I have I can reach for the big hammer of `git merge -s ours` 😛
15:47:11 <TrueBrain> Haha, certainly that works 😄
15:51:16 <petern> I guess that works better if it's one big chunk. Hmm.
16:05:51 *** thelonelyellipsis[m] has joined #openttd
16:18:53 <petern> Hmm, is it possible/allowed to test parent/head vehicle's cargo type/subtype during engine property callbacks?
16:21:06 <petern> I know there's the var 61 check, not sure about parent scope though.
16:24:10 <Eddi|zuHause> parent scope is not restricted like var61
16:24:29 <Eddi|zuHause> so if the variable exists, it can be read
16:25:04 <petern> I suppose that is because the head vehicle will already have been set up before the currentl vehicle.
16:25:51 <Eddi|zuHause> afair var61 is restricted because of possible circular dependencies bring in state into a stateless system
16:26:32 <Eddi|zuHause> parent scope doesn't have this circular problem, because it's only one direction
16:27:49 <petern> Yeah, I'm delving into this refit crap and of course the way capacity is determined doesn't cope with parent scope.
16:28:58 <petern> As it sets and reverts cargo type and cargo subtype per vehicle part, if any part bases its decision on the parent scope type/subtype, it'll be incorrect.
16:29:31 <petern> Or at least, could be different depending on the current state of the head vehicle.
16:29:57 <Eddi|zuHause> can the engine do wagon overrides depending on its own refit type?
16:30:05 <petern> I just remembered my brake pads are worn out... probably best not to go riding on that bike.
16:30:27 <petern> No, wagon overrides are setup and fixed by action 3.
16:30:52 <petern> I don't think they care about cargo type.
16:34:19 <Eddi|zuHause> anyway, as long as it's not a desync hazard, probably better to not worry about it until a newgrf uses it this way, and it's not a theoretical problem anymore
16:35:00 <petern> Well it might explain some strange things and unknown desyncs...
16:35:48 <Eddi|zuHause> that deserves an investigation, yes
16:38:57 <petern> Hmm, I guess you can also directly check capacity during the capacity callback.
16:39:07 <petern> (of both parent and self)
16:39:54 <petern> And current cargo count. Oh woe, not another rabbit hole.
16:41:27 <Eddi|zuHause> rabbit holes might be a proper fractal
16:43:16 <Rubidium_> TrueBrain: shouldn't the nlohmann-json and optin-survey branches be removed?
16:44:20 <TrueBrain> Hard to answer that question linguistic correct 😄
16:53:41 *** karl[m]123 has joined #openttd
17:17:56 <petern> Hmm, I expected this GRFConfig change to not actually work...
17:19:01 <petern> I... did not press enter. What.
17:19:38 <LordAro> better fill details in quickly before james tells you off
17:21:55 <petern> I've just been cleaning my winter bike. That I have not ridden for 6-7 months. That I put away dirty. Oops.
17:22:10 <petern> I guess I could just ride it...
17:22:22 <petern> At least its brakes work.
17:22:41 *** Heiki[m] has joined #openttd
17:24:23 <petern> Anyway, #10835 needs more work, I just wanted to it put it there before someone else starts refactoring it from scratch again.
17:24:40 <petern> Could do with parameter renaming for consistency at least.
17:26:16 <petern> I should comment there 🙂
17:32:42 *** NekomimiGunner18[m] has joined #openttd
18:04:03 *** Wormnest has joined #openttd
18:20:22 <pickpacket> I have thoughts and questions
18:21:42 *** gelignite has quit IRC (Quit: Stay safe!)
18:23:51 <pickpacket> I'm pondering a NewGRF that would reduce the value and production of coal and oil after a certain point in the game, and start closing down oil fields, coal mines, refineries, and power plants. I'd also like to reduce production of livestock on farms in a similar manner, and up the production of grain to balance it out (or make the farms produce
18:23:51 <pickpacket> some other cargo, or add another industry, something something something). As livestock production is reduced to 0 I'd like to replace the pig pen sprites
18:24:08 <pickpacket> What I want to know is: how much of this is even possible in a newgrf?
18:40:43 <Rubidium_> pickpacket: NewGRFs can have control over production changes, so you could decrease them slowly to eventually initiate closing down (there is a flag that allows closing down the last one)
18:41:35 <Rubidium_> replacing a cargo probably can't happen, but I guess you can add 3 cargos to an industry and once one cargo's production is 0, you can let the other grow
18:42:08 <DorpsGek> - Update: Translations from eints (by translators)
18:42:43 <frosch> in my youth there was a newgrf "PBI - pikka basic industries". it that stockpiling and mines depleted after N years
18:48:19 <pickpacket> Rubidium_: Could I set it so that oil rigs and coal mines can only decrease production after 1995 and never spawn after 2000? Set an expiration date for refineries and power plants, maybe? For farms I could set the livestock to only decrease same as coal and oil in that case, and add another cargo from some chosen year... I think? Is it possible to
18:48:19 <pickpacket> replace certain sprites after a certain time?
18:49:48 *** gelignite has joined #openttd
18:49:58 <pickpacket> I'll have to research this
18:53:24 <TallTyler> pickpacket: in Lumberjack Industries I made farms only produce grain during the fall harvest. Might be a good place to start. I use Fertilizer as a boost cargo so there’s some extra code to handle that, but comments should explain what’s going on. 🙂
18:54:18 <TallTyler> Heh, the way “Peter has a patch for that” I seem to often go “I did a similar weird thing in NewGRF”
18:55:14 <petern> Hmm, 8pm, maybe time for a short solo ride...?
18:55:39 <pickpacket> I'm a little conflicted about doing this because coal is usually the back bone of my enterprise and the thing that challenges me to make bigger and more efficient stations and lines
18:56:37 <Eddi|zuHause> pickpacket: the problem is that the game doesn't offer game mechanics to handle dynamic loads
18:56:38 <petern> Getting/setting by index is a pain with lists 🙂
18:56:53 <Eddi|zuHause> pickpacket: so you're constantly micromanaging the amount of trains on the line
18:57:19 <petern> Some would call that "constantly playing the game"
18:57:42 <Eddi|zuHause> there is somewhat of a difference between "play" and "micromanage"
19:02:24 <petern> So many refit experts 😄
19:07:07 <TrueBrain> `"game.settings.last_newgrf_count":` .. I forgot we had that "setting" 😄
19:07:50 *** Wormnest has quit IRC (Read error: Connection reset by peer)
19:08:47 *** Wormnest has joined #openttd
19:09:07 <petern> Is that the number of 'installed' NewGRFs?
19:09:19 <TrueBrain> something like that, yeah
19:09:28 <TrueBrain> never actually looked into it; but it isn't a setting as such 😛
19:09:36 <TrueBrain> more a "look, we can store some information here too" 😄
19:10:04 <Eddi|zuHause> is that needed for... anything?
19:10:48 <TrueBrain> no, we love random junk in our codebase
19:10:52 <TrueBrain> what a silly question
19:13:30 <Eddi|zuHause> well... for certain definitions of "need" you could delete the whole game :p
19:14:05 <Rubidium_> it's purely for the progress bar when scanning (for) NewGRFs
19:15:17 <TrueBrain> if you don't know how many to expect, use the number of the last round! 😄
19:16:09 <Eddi|zuHause> that's ... sort of sane?
19:16:57 <petern> Oh we have that json lib now, I guess I could ... think on it...
19:17:53 <petern> Hmm, can I dismiss CodeQL warnings as "resolved" rather than "Won't fix", "False positive" or "Used in tests"
19:18:39 <petern> (Or will it just do that if the Ci actually gets a chance to finish?)
19:26:16 <Rubidium_> I think the CI does that on its own
19:37:25 *** magdalena[m] has joined #openttd
19:46:13 <glx[d]> petern: didn't look at any of the code, but does it really needs to be a list ?
19:47:58 <petern> Probably not, the main one is re-ordering the config in the UI, the other is to sort the list while adding during scanning, which could be done with a sort afterwards. Otherwise it's straight front to back...
19:53:27 <petern> But because it's no longer pointers, shuffling/sorting means moving the data (although shuffling is only two items to change at a time)
20:01:48 <Rubidium_> vector with unique_ptr?
20:05:42 <petern> I was avoiding pointers.
20:07:43 *** jact[m] has joined #openttd
20:09:34 <petern> Well, std::advance works fine for index to iterator.
20:10:10 <petern> std::distance may work for iterator to index I guess.
20:14:09 *** amal[m] has joined #openttd
20:35:15 *** gelignite has quit IRC (Quit: Stay safe!)
20:37:11 *** HerzogDeXtEr has joined #openttd
20:55:49 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:31:54 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:40:23 *** shedidthedog[m] has joined #openttd
21:45:56 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:51:35 <petern> NetworkAddress is an interesting class
22:03:05 *** tokai|noir has joined #openttd
22:03:05 *** ChanServ sets mode: +v tokai|noir
22:08:03 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:09:59 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:15:49 *** JamesRoss[m] has joined #openttd
23:11:40 *** yubvin[m] has joined #openttd
23:11:58 *** elliot[m] has joined #openttd
23:19:43 *** warp[m] has joined #openttd
23:36:57 *** blikjeham[m] has joined #openttd
23:37:03 *** cjmonagle[m] has joined #openttd
23:37:14 *** CornsMcGowan[m] has joined #openttd
23:37:19 *** rudolfs[m] has joined #openttd
23:37:25 *** philip[m]123 has joined #openttd
23:37:30 *** leward[m] has joined #openttd
23:38:24 *** Farrokh[m] has joined #openttd
23:38:29 *** zzy2357[m] has joined #openttd
23:45:55 <petern> Ye olde header dependency errors...
continue to next day ⏵