IRC logs for #openttd on OFTC at 2023-01-05
            
00:01:03 <reldred> (all good, I know not everything pans out ๐Ÿ™‚ )
00:01:45 <JGR> These things take time
00:01:49 <Pruple> reldred: there's still BAD FEATURES ๐Ÿ˜‰
00:01:54 <reldred> however, who do I have to bribe to help him?
00:02:14 <reldred> Pruple: i want mORE, MORE BAD FEATURES
00:03:20 <DorpsGek> [OpenTTD/OpenTTD] NyanGoat commented on issue #10298: [Bug]: Jukebox not playing all instruments https://github.com/OpenTTD/OpenTTD/issues/10298
00:15:40 <petern> I'm good at them.
00:15:52 <petern> Or at least, starting them.
00:20:40 <imlegos> NyanGoatviaGitHub: Someone in the thread managed to fix the midi file?
00:29:44 *** sla_ro|master has quit IRC ()
00:45:03 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:23:21 *** Wormnest has joined #openttd
01:34:17 <DorpsGek> [OpenTTD/OpenTTD] wholepuncher updated pull request #9852: Fix #9810: 'Rebuilding' a through road stop costs money. https://github.com/OpenTTD/OpenTTD/pull/9852
01:40:31 *** WormnestAndroid has joined #openttd
01:42:50 <reldred> Question; are the eight direction frences a railtypes specific feature? or can I make a .grf that just replaces the default fences with eight direction fences instead of the default ones that just use four sprites+offsets?
01:54:20 <Pruple> the 16 sprite version is only available with a railtype action 3
01:54:55 <Pruple> as a global replacement you're stuck with the old TTD 8 sprite version
01:54:55 <reldred> Gotcha
01:55:06 <reldred> Oh yeah hills forgot about those
01:58:43 *** supermop_Home has joined #openttd
01:58:49 <supermop_Home> yo
02:06:41 <Pruple> yoyo
02:07:10 <Pruple> okay, serious* question
02:07:24 <Pruple> has anyone in the history of the world ever used planespeed 2 or 3?
02:07:41 <Pruple> and if so, what's wrong with them?
02:08:04 <glx[d]> I think most directly switched from 1 to 4
02:08:20 <Pruple> exactly
02:10:14 <Pruple> I'm standardising and publishing my cost formulas, and trying to simplify them as much as possible. tempted to get rid of the multiplier for planespeed factor
02:10:55 <Pruple> would make aircraft less profitable if you have planespeed < 4, but wasn't that the point of nerfing planespeed in the first place? ๐Ÿ™‚
02:13:59 <supermop_Home> I got stuck in a neutron star or something
02:14:01 <supermop_Home> https://xkcd.com/2712/
02:18:55 <reldred> I use whatever setting AV8 doesn't whinge about.
02:19:09 <reldred> so if it's wrong I blame you Pruple
02:21:21 <Pruple> okay, so I've gone from having multipliers for planespeed, multipliers for pax vs freight, and different speeds for 5 different phases; on the ground, taking off, cruising, circuit, and landing...
02:21:38 <Pruple> to 100% when flying, 50% in the circuit, and 25% on the ground
02:21:47 <Pruple> and I'm sure no-one will notice the difference ๐Ÿ™‚
02:32:50 <kamnet> imlegos: No, the midi file is not fixed (and legally cannot be fixed and distributed). A change to the openttd.cfg file can restore it
02:35:23 <imlegos> ah...
02:40:28 <DorpsGek> [OpenTTD/OpenTTD] kevinfields777 commented on issue #10298: [Bug]: Jukebox not playing all instruments https://github.com/OpenTTD/OpenTTD/issues/10298
02:57:30 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
02:58:39 *** Wormnest has joined #openttd
03:27:42 *** D-HUND has joined #openttd
03:27:53 *** Wormnest has quit IRC (Quit: Leaving)
03:31:03 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:01:55 *** aaaa has joined #openttd
04:03:52 *** aaaa has quit IRC ()
04:04:28 <DorpsGek> [OpenTTD/OpenTTD] krysclarke commented on issue #10310: [Bug]: Wrecks of vehicles left at level crossings cause an avalanche of further accidents https://github.com/OpenTTD/OpenTTD/issues/10310
04:15:15 *** TROILUS has quit IRC (Read error: Connection reset by peer)
04:15:16 *** TROILUS7 has joined #openttd
04:15:16 *** TROILUS7 is now known as TROILUS
04:18:32 *** TROILUS8 has joined #openttd
04:18:40 *** D-HUND is now known as debdog
04:21:05 *** TROILUS has quit IRC (Read error: No route to host)
04:21:06 *** TROILUS8 is now known as TROILUS
04:23:27 <supermop_Home> idea: 128x2048 map with island in the middle, and rump landmasses at either end with various industries / bulk terminals
04:27:50 <supermop_Home> want to order more storage bins from Germany to keep stuff in while waiting to get into apartment, but this company is such a pain to deal with
04:28:18 <supermop_Home> they will sell to US customers, but only for local pickup
04:29:48 <supermop_Home> any shipment is such a hassel via a freight forwarding service that feel compelled to order more than I can really justify
05:00:51 *** Flygon has joined #openttd
05:43:16 *** keikoz has joined #openttd
07:26:02 *** sla_ro|master has joined #openttd
07:58:35 <kamnet> supermop_Home: When I get round to revamping my Early Empires map, one end of the map (512x1024 or 2048) is going to have a bulk terminal as the only secondary industry and you have to use ships to get it. The only primary industry is agriculture. Everything else you'll have to fund yourself.
08:57:35 *** HerzogDeXtEr has joined #openttd
09:19:43 *** Flygon has quit IRC (Ping timeout: 480 seconds)
09:20:30 *** Flygon has joined #openttd
10:41:42 *** Tirili has joined #openttd
10:52:13 <TallTyler> Sounds like Industries of the Caribbean, but less weird
11:09:45 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #10298: [Bug]: Jukebox not playing all instruments https://github.com/OpenTTD/OpenTTD/issues/10298
11:15:27 *** _aD has joined #openttd
11:17:52 <petern> Hmm, CPU clocks not dropping again. Stupid computer ๐Ÿ™‚
11:34:03 *** murr4y has quit IRC (Ping timeout: 480 seconds)
11:35:51 *** _aD has quit IRC (Ping timeout: 480 seconds)
11:38:46 *** murr4y has joined #openttd
11:50:45 <petern> Haha, phone scammer just to me to f*** myself due to wasting his time.
11:51:37 <pickpacket> hahaha
11:54:57 <LordAro> nice
12:20:42 *** Samu has joined #openttd
12:27:41 <DorpsGek> [OpenTTD/OpenTTD] George-VB opened issue #10320: [Bug]: Wrong capacity for ARV's parts https://github.com/OpenTTD/OpenTTD/issues/10320
12:30:11 <petern> Oh no.
12:33:10 <FLHerne> huh, names from the distant past :p
12:41:15 *** _aD has joined #openttd
12:48:48 <glx[d]> Duplicate ?
12:49:11 <petern> Of?
12:56:09 <petern> Looks like when you filter by cargo type, `GetArticulatedVehicleCargoesAndRefits` applies that in some way on top.
12:56:59 <glx[d]> Of #10032
12:57:04 <petern> (Presumably because you can have refits that change capacity for the same cargo)
12:57:30 <petern> Ahhhh yes.
12:58:00 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #10320: [Bug]: Wrong capacity for ARV's parts https://github.com/OpenTTD/OpenTTD/issues/10320
12:58:03 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed issue #10320: [Bug]: Wrong capacity for ARV's parts https://github.com/OpenTTD/OpenTTD/issues/10320
13:05:50 <petern> Hmm, given this function is only called for the buy menu, not sure any of it makes sense.
13:07:56 <petern> Oh well, blame me probably ๐Ÿ™‚
13:13:30 <petern> We should never have implemented NewGRF
13:21:21 <andythenorth> Debatable ๐Ÿ™‚
13:22:25 <petern> Don't debate it, nothing will ever happen.
13:27:52 * pickpacket is happy the NewGRF is implemented
13:28:00 <pickpacket> s/the/that
13:28:41 <DorpsGek> [OpenTTD/OpenTTD] kevinfields777 commented on issue #10298: [Bug]: Jukebox not playing all instruments https://github.com/OpenTTD/OpenTTD/issues/10298
14:49:12 <TallTyler> Anyone know why preview builds are failing on #9852?
14:53:57 *** _aD has quit IRC (Read error: Connection reset by peer)
14:54:28 <michi_cc[d]> `fatal: detected dubious ownership in repository at '/__w/OpenTTD/OpenTTD'` from https://github.com/OpenTTD/OpenTTD/actions/runs/3843066541/jobs/6544992316#step:5:10
14:56:21 <michi_cc[d]> I see in the Checkout step that the the "magic" setting to remove the ownership check is done, but apparently for whatever reason it has no effect.
15:11:43 <petern> it might be needed again, if the state from the checkout step is removed for safety?
15:12:08 <petern> (ensuring secrets are not passed around)
15:12:30 <petern> Although, of course it all used to work. Hm.
15:22:17 <Rubidium> has it gotten broken on other PRs as well?
15:24:01 <TallTyler> Yes, #10018
15:24:49 <TallTyler> And #9011, back in November, although I feel like other things have succeeded since then
15:37:26 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9852: Fix #9810: 'Rebuilding' a through road stop costs money. https://github.com/OpenTTD/OpenTTD/pull/9852#pullrequestreview-1237604618
15:41:04 <Rubidium> I can't see a clear moment things started failing. For some it's a month ago, but then another succeeded two weeks ago...
15:45:56 <LordAro> might depend on how the underlying git version has been rolled out across GHA and/or the relevant images
15:46:09 <LordAro> it's a particular new git version that added the change
15:48:02 <petern> That changed messed me up, cos I had some git repos on mapped network shares.
15:48:40 <petern> So I access it via `P:\repository` but it gets mapped to `\\server\p\repository` and it never matches.
15:49:24 <LordAro> it's broken almost every CI i've been involved in at some point
15:49:29 <LordAro> it's very irritating
16:07:30 <petern> I'm half-tempted to create custom docker images for the CI I use.
16:07:51 <petern> That means more maintenance though.
16:08:06 <petern> And if you then need a CI to build the image that the CI relies on... um...
16:08:08 <LordAro> just think how fast those builds will be though if you preinstall dependencies!
16:08:15 <petern> Yes
16:09:00 <petern> No joke, restoring nuget packages and installing the build tools on top of the dotnet image takes a while.
16:10:08 <petern> And because this CI doesn't keep any data outside of the working directory between steps, so I have to install tools, restore nuget, and build in one "step"
16:10:42 <petern> 1:31 to build a dotnet solution is quite a lot.
16:11:21 <LordAro> is that one hour, or one minute?
16:11:35 <LordAro> because one minute really isn't a long time
16:11:37 <petern> minute ๐Ÿ™‚
16:11:45 * LordAro looks sadly at his 90 minute build times
16:11:54 <petern> Ouch
16:14:20 <LordAro> well, strictly speaking the actual build takes about 20 minutes, all the other stuff takes the rest of the time
16:14:33 <LordAro> and that's to say nothing of the ~3 hours of test time
16:14:56 <LordAro> and this is *after* generating our own docker images
16:15:12 <LordAro> that each contain at least 4 compilers
16:15:39 <petern> Considering last month I was just building on my desktop, and manually (running a script that uses rsync) to deploy... this CI is better, even if slower.
16:16:20 <LordAro> mm
16:16:21 <petern> I deploy to test on merge into main, and deploy to production on tag. This means production is now always commit, merged and released code.
16:16:29 <LordAro> automation is love, automation is life
16:16:43 <petern> Before, I did occasionally do a fix and deploy it before merging it in.
16:16:51 <petern> yolo
16:17:08 <petern> If I had a team I would never have done that, of course. Of course.
16:17:16 <LordAro> Of Course.
16:19:28 *** TROILUS0 has joined #openttd
16:20:34 <TallTyler> My upcoming project has to touch stuff in worldgen GUI...can we merge #10093 so I don't have to do things twice? ๐Ÿ™‚
16:22:46 <petern> Do we getting a button to take us to advanced world generation settings?
16:23:27 <TallTyler> Not yet ๐Ÿ™‚
16:23:35 <TallTyler> Just changing calendar speed from worldgen
16:24:43 *** TROILUS has quit IRC (Ping timeout: 480 seconds)
16:24:43 *** TROILUS0 is now known as TROILUS
16:35:10 <petern> Huh, playing a fast-spaced staccato phrase in _pp_ is quite tricky.
16:36:19 *** gelignite has joined #openttd
16:44:00 *** Etua has joined #openttd
16:45:28 <glx[d]> TallTyler: I think updating emsdk version is the root cause
16:46:13 <glx[d]> And it's a pain to test preview workflow as it's not triggered until merged
16:49:12 <petern> It's all a bit magic.
16:54:39 *** Flygon_ has joined #openttd
17:02:13 *** Flygon has quit IRC (Ping timeout: 480 seconds)
17:12:45 *** Etua has quit IRC (Quit: Etua)
17:47:23 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10321: Fix: prevent corrupted GRF files to allocate stupid amounts of memory https://github.com/OpenTTD/OpenTTD/pull/10321
17:49:19 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10317: CodeQL triggered clean ups https://github.com/OpenTTD/OpenTTD/pull/10317
17:49:22 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299
17:51:56 <petern> Going to test the cat GRF with 10321 ๐Ÿ™‚
17:58:00 *** Wormnest has joined #openttd
17:58:39 <LordAro> petern: didn't get a place for APN :(
17:59:42 *** nielsm has joined #openttd
18:18:08 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299
18:18:33 <Rubidium> petern: yes please ;) I assume it's a huge GRF :D
18:18:40 *** nielsm has quit IRC (Ping timeout: 480 seconds)
18:19:21 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299
18:19:43 *** nielsm has joined #openttd
18:20:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299
18:21:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299#issuecomment-1372574446
18:22:12 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10321: Fix: prevent corrupted GRF files to allocate stupid amounts of memory https://github.com/OpenTTD/OpenTTD/pull/10321#pullrequestreview-1237844275
18:24:24 <petern> Big cats still work :p
18:25:25 <petern> https://cdn.discordapp.com/attachments/1008473233844097104/1060625082214514728/image.png
18:26:32 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10321: Fix: prevent corrupted GRF files to allocate stupid amounts of memory https://github.com/OpenTTD/OpenTTD/pull/10321
18:26:34 <petern> They're probably segmented, I didn't check.
18:27:00 <petern> Ah yup, so not very big at all. Never mind ๐Ÿ™‚
18:28:12 <Eddi|zuHause> are they objects?
18:28:32 <Rubidium> those look smaller than ~3000x3000 pixels, so they should be fine :)
18:29:58 <TallTyler> Even if it didnโ€™t Iโ€™d argue that big cats arenโ€™t that important to support ๐Ÿ˜›
18:35:17 <Eddi|zuHause> blasphemy!
18:42:50 *** Flygon_ has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
18:44:26 <petern> HOW DARE
18:44:48 <dP> check that auzind still works :p
18:46:03 <dP> it definitely allocates stupid amounts of memory :p
18:46:12 <dP> not in one sprite though so likely still fine
18:47:38 <petern> I think you'd hit sprite sorter limits before then tbh.
18:48:01 <dP> yeah, that's usually what happens with auzind
18:48:04 <petern> I seem to remember there being a height limit, and width is limited to being within a tile or so.
18:48:06 <petern> Oh
18:48:49 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/58068883f81d9c73132fa1d81aa582efe5f42172
18:48:50 <DorpsGek> - Update: Translations from eints (by translators)
18:49:10 <dP> oh, actually, no, it hits sprite cache limits, not sprite sorter
18:49:50 <dP> sprite sorter doesn't have any limits iirc
18:50:02 <dP> other than eternity xD
18:50:37 <petern> Well not really sprite sorter, more viewport limits.
18:51:00 <petern> There's a limit to how far "down" it goes.
18:51:33 <dP> yeah, but isn't that just a glitch territory, not a hard limit?
18:51:52 <petern> MAX_TILE_EXTENTS_*
18:51:54 <petern> Er
18:51:57 <petern> formatting :/
18:52:16 <dP> iirc azind just does exactly max size sprite for each tile xD
18:52:45 <petern> TBH, Overlapping tiles left and right is a bad idea, even with bounding boxes in place.
18:53:00 <Rubidium> dP: though is *one* sprite so big it fills more than a 4k monitor worth of pixels?
18:53:43 <petern> Hmm, what should I use to listen to a podcast on PC...
18:54:06 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #10321: Fix: prevent corrupted GRF files to allocate stupid amounts of memory https://github.com/OpenTTD/OpenTTD/pull/10321#pullrequestreview-1237888466
18:55:29 <Rubidium> those auzind NewGRFs are 13 and 14 MB, so... they need to be at least 5 times bigger and contain only one sprite to be able to trigger the threshold. I guess we're safe :)
18:59:43 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #10309: [Bug]: SDL2 driver goes to random resolution after fullscreen https://github.com/OpenTTD/OpenTTD/issues/10309
19:02:30 *** Wolf01 has joined #openttd
19:03:45 <TallTyler> https://cdn.discordapp.com/attachments/1008473233844097104/1060634728258080778/crash.zip
19:03:45 <TallTyler> Okay, I'm getting a weird crash in my "calendar progress speed" branch. Can anyone help diagnose? Here's the whole branch code: https://github.com/2TallTyler/OpenTTD/commits/tyler_ruins_time
19:03:45 <TallTyler> I have already tried setting `MILLISECONDS_PER_TICK` back to 30, but that didn't help.
19:04:09 <TallTyler> Interestingly, when I Ctrl+click on New Game to skip the world generation screen, it doesn't crash. So the problem is in there somewhere?
19:05:07 <TallTyler> The commit which touches genworld.cpp is here: https://github.com/2TallTyler/OpenTTD/commit/fd1e5400d2614f8311d66d8948e1718c2ba8f79d
19:07:06 <JGR> Most likely you've got a SetDParam wrong or missing
19:07:57 <DorpsGek> [OpenTTD/website] NyanGoat opened issue #245: Many (or all) redirects not working https://github.com/OpenTTD/website/issues/245
19:11:41 <JGR> WID_CS_CALENDAR_PROGRESS_SPEED_TEXT looks suspicious
19:12:03 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10321: Fix: prevent corrupted GRF files to allocate stupid amounts of memory https://github.com/OpenTTD/OpenTTD/pull/10321
19:13:01 <TallTyler> Line 1148?
19:16:00 <JGR> STR_JUST_STRING doesn't seem right when the the string has a parameter
19:16:12 <JGR> WID_GL_START_DATE_TEXT seems to be duplicated, but with different string codes as well?
19:16:45 <TallTyler> Oh, that second one is probably the problem
19:16:52 <JGR> Line 1393 and 165 - 170
19:17:19 <TallTyler> The code is copied from my previous attempt at this patch, which split the Technology date into a new system instead of this attempt which splits the Economy date
19:18:29 <JGR> Line 316 - 321 seems to be similar
19:19:08 <TallTyler> Yes, it's defined twice for Scenario Editor and GenWorld
19:19:18 <TallTyler> Crash fixed - thanks for the sharp eye! ๐Ÿ™‚
19:24:45 <JGR> No problem ๐Ÿ™‚
19:30:02 <TallTyler> Okay experts, how does C++ handle decimal numbers partway through calculations? If I set the setting above 100 (doesn't matter if it's 101 or 7,400) the days progress infinitely fast, leading me to believe that the calculation is DAY_TICKS * 0.
19:30:02 <TallTyler> if (++_date_fract < DAY_TICKS * (100 / _settings_game.economy.calendar_progress_speed)) return;
19:30:37 <TallTyler> Oh, is it just doing integer division immediately?
19:30:48 <TallTyler> What's a safe decimal type to cast these to?
19:30:49 <JGR> `(DAY_TICKS * 100) / _settings_game.economy.calendar_progress_speed` s better
19:31:16 <JGR> There is no decimal type
19:31:49 <TallTyler> Ah, right
19:32:05 <JGR> You can calculate using a different number basis if you need to, but I wouldn't bother unless you really need that
19:32:59 <TallTyler> By decimal type I meant float/double/etc but forget which of those are network-safe, and which exist in C++. I've been writing a lot of C# lately...
19:33:14 <TallTyler> But just restructuring the equation is a better solution anyway ๐Ÿ™‚
19:33:34 <JGR> float/double should be avoided for anything which needs to be synchronised between multiplayer instances
19:33:53 <TallTyler> That's the big thing I've learned here ๐Ÿ™‚
19:34:09 <JGR> There are many footguns around this
19:58:58 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on issue #10298: [Bug]: Jukebox not playing all instruments https://github.com/OpenTTD/OpenTTD/issues/10298
19:59:50 <petern> Obvious solution for that is `(DAY_TICKS * 100) / _settings_game.economy.calendar_progress_speed`
20:00:28 <petern> But whether that'll work as you intend is another matter.
20:00:53 <petern> See, I managed to miss JGR saying the same thing
20:06:31 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #10314: Codechange: Don't use a dense matrix to store LinkGraph edges. https://github.com/OpenTTD/OpenTTD/pull/10314
20:23:57 <DorpsGek> [OpenTTD/BaNaNaS] frosch123 opened pull request #122: Remove: 'Highspeed Trains' due to violations. https://github.com/OpenTTD/BaNaNaS/pull/122
20:25:01 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain approved pull request #122: Remove: 'Highspeed Trains' due to violations. https://github.com/OpenTTD/BaNaNaS/pull/122#pullrequestreview-1238000113
20:28:31 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299#issuecomment-1372707641
20:29:22 *** arikover has joined #openttd
20:34:13 <TrueBrain> meh, too bad `paths-exclude` doesn't work for `cpp` in CodeQL .. that would remove all those warnings from the generated files
20:37:10 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on pull request #10314: Codechange: Don't use a dense matrix to store LinkGraph edges. https://github.com/OpenTTD/OpenTTD/pull/10314#issuecomment-1372716145
20:39:01 <frosch> does someone know why preview builds are broken since last week?
20:39:20 <frosch> https://github.com/OpenTTD/OpenTTD/actions/workflows/preview_build.yml
20:42:34 <TrueBrain> What a weird error
20:43:18 <petern> Yeah it's ignoring the safe.directory added in Checkout.
20:44:05 <petern> I wonder if the git config no longer persists across steps?
20:44:51 <glx[d]> git in workspace vs git in docker image I'd say
20:46:47 <glx[d]> or `Temporarily overriding HOME='/__w/_temp/07fa0be3-e6f7-48bd-94b6-abba1bba4f40' before making global git config changes` now affects only the checkout step
20:47:21 <TrueBrain> We did update emscripten ofc, so also the OS of the docker updated .. might be related
20:47:33 <TrueBrain> Just rather unexpected to see this ๐Ÿ˜„
20:48:53 <glx[d]> anyway it's easy to add `git config` line in the workflow, but it's untestable before merge
20:50:16 <TrueBrain> You could run it in your fork to test, if you like
20:51:04 <glx[d]> oh true
20:59:29 *** borishiro has joined #openttd
21:06:46 <borishiro> Hi, I'm new to IRC and openttd channel in particular. Are there any subtopics or is it just one and only channel for any communication purpose?
21:09:30 <Pruple> there are other channels on the discord, but afaia just the one IRC channel
21:20:46 <dP> JGR: `_settings_game.economy.calendar_progress_speed * ++_date_fract < DAY_TICKS * 100` even better
21:28:28 *** eltsimoto has joined #openttd
21:32:44 <eltsimoto> d
21:33:03 <borishiro> thanks
21:33:18 *** eltsimoto has quit IRC (Read error: Connection reset by peer)
21:33:59 <TallTyler> https://cdn.discordapp.com/attachments/1008473233844097104/1060672536607727686/perminute.png
21:34:16 <TallTyler> Almost time for a draft PR, perhaps
21:34:50 <TallTyler> (for proof of concept before I finish converting everything else to real-time)
21:36:00 <EmperorJake> Real time? Does this mean gameplay can be completely separated from the calendar like in Transport Fever 2?
21:37:04 <andythenorth> can we make it more chill?
21:37:07 <andythenorth> last hour? ๐Ÿ˜›
21:37:10 <andythenorth> less dopamine crap
21:39:20 <TallTyler> EmperorJake: Yes, thatโ€™s exactly what Iโ€™m doing
21:39:50 *** _aD has joined #openttd
21:40:20 <TallTyler> Itโ€™s a percentage of default speed, anywhere from 0% (stopped) to 7400% (memes? idk)
21:40:37 <EmperorJake> Great, maybe we won't need daylength anymore
21:40:48 *** gelignite has quit IRC (Quit: Stay safe!)
21:41:14 <TallTyler> It includes a slight change to milliseconds per tick to match TTD and make one month almost exactly a minute - from the current 2.2 seconds per day to 1.99 seconds per day
21:41:59 <TallTyler> I have no idea how much Iโ€™ll screw up JGRPP doing this, but yeah, this would be how vanillaโ€™s alternative to daylength
21:42:21 <Gwyd> 7400% calender speed? Sounds useful
21:42:50 <TallTyler> Iโ€™ll also probably add some base game scalars to industry and town production, but thatโ€™s a totally separate PR than this probably to come shortly afterward
21:42:51 <EmperorJake> I'll probably still use daylength because I like the slower paced production and ratings changes, which I assume this patch won't affect
21:43:30 <nielsm> (the way of doing it that I personally like, because it removes all questions of "does the industry production rate change when the calendar progression rate changes?" - the two are no longer linked at all)
21:44:09 <EmperorJake> Yes, maybe station rating decay could be its own setting too
21:44:14 <TallTyler> Thanks for your NoCalendar branch by the way, that was where I started all this ๐Ÿ™‚
21:46:03 <TallTyler> The issue with station ratings and both town and industry production is โ€œNewGRF can do that so we should never touch itโ€ โ€” not a death sentence but definitely a longer conversation
21:47:03 <TallTyler> Iโ€™m personally in favor of doing sweeping features like those in vanilla rather than forcing NewGRF authors to design their own janky implementations, but thatโ€™s just me ๐Ÿ™‚
21:47:21 <andythenorth> do we include a scaling for vehicle intro dates?
21:47:24 <andythenorth> or does grf do that?
21:47:30 <TallTyler> What is that?
21:47:30 <nielsm> yeah, I'm hard in the came of, "if you want production rates or station ratings to behave differently, then use a NewGRF"
21:48:29 <nielsm> andythenorth: the idea is that you still have a calendar, which affects introduction of vehicle introduction etc., but the rate of calendar progression is decoupled from the rate of the game economy
21:49:15 <nielsm> everything runs on "per minute", so you can measure cargo production in units per minute, vehicle speed in tiles per minute, and so on, and those never change
21:49:31 <nielsm> ("per minute" being wall clock minutes at 1.00 simulation speed)
21:49:31 <petern> TallTyler: Ooh controversial ๐Ÿ™‚
21:49:32 <imlegos> So, in turn you could have the date change slower but the economy stays the same or even gets faster
21:50:48 <petern> What most people want from daylength is "more time between new engines coming out.
21:50:51 <nielsm> you could even express the calendar speed in something like "minutes of calendar year"
21:50:55 <imlegos> Would be neat if you could see an industry's production in both real time and in-game increments, but that's not the goal here
21:51:15 <nielsm> imlegos: that's something NewGRF can already do
21:51:19 <andythenorth> petern: this
21:51:24 <andythenorth> which can can be done in grf, but eh
21:51:32 <andythenorth> RT would be better
21:51:33 <nielsm> if you want industries to produce more or less cargo then use a mod
21:51:44 <imlegos> I wasn't saying that
21:51:47 <petern> TallTyler: is there a PR?
21:51:55 <TallTyler> Not yet, Iโ€™ll make one soon
21:52:00 <imlegos> I was saying like see how much is produced per minute and per month at the same time
21:52:08 <TallTyler> Still lots to fix but canโ€™t hurt to get eyeballs on it
21:52:20 <andythenorth> there is no month ๐Ÿ™‚
21:52:31 <andythenorth> there is no spoon
21:52:40 <petern> dP: were you able to test #10315 to make sure it fixes your issue?
21:52:47 * pickpacket bends himself so that the month bends
21:52:47 <TallTyler> petern: The nice thing is that people who want OpenTTD time scale can just set it to like 98% and revert the tick scaling ๐Ÿ™‚
21:53:11 <petern> Almost.
21:53:32 <petern> When you change milliseconds per tick, vehicles do move a bit faster.
21:53:47 <pickpacket> I donโ€™t get it. Are you talking about making the days longer?
21:53:57 <petern> I actually experimented just to see if it would fix running sounds, but alas not.
21:54:01 <nielsm> as I've written before, the really hard thing about this "NoCalendar" approach is what to call things
21:54:48 <nielsm> since you probably still want vehicle stats calculated in approximately "what used to be months but is now 12 minute increments"
21:55:02 <TallTyler> Internally everything is either EconomyMonth (or day/year) or CalendarMonth, but that could potentially be changed in the future to Minute, TwoSeconds, 12Minutes, etc...which I think is much more confusing ๐Ÿ˜›
21:55:08 <nielsm> wait, used to be years I mean
21:55:51 <nielsm> like how do you display the finances window?
21:56:05 <nielsm> what do you label the not-years?
21:56:32 <dP> petern: not yet... let me see if I can do that now...
21:56:43 <dP> what's the simplest way to checkout a pr?
21:57:21 <nielsm> the other Hard thing about this approach is that it is basically not optional, even if you play at 1/1 rate things will still be different from how it used to be
21:57:37 <petern> If you use VS Code, the it's easy with the github extension, there's a list of PRs.
21:57:56 <pickpacket> Uh. Iโ€ฆ I really donโ€™t get it. Right now inteoduction dates for vehicles, changes in oil production, building design for cities, are all loosely based on historic facts (as far as possible). What would you replace that with if you remove calendar dates?
21:58:13 <nielsm> pickpacket: calendar dates stay for those things
21:58:27 <TallTyler> https://cdn.discordapp.com/attachments/1008473233844097104/1060678695846682746/days.png
21:58:27 <TallTyler> For graphs I'm thinking of borrowing from how JGRPP has station cargo history graphs, which is just the last 48 days. Replace that with minutes and make it the right size, should work
21:58:40 <dP> petern: I use `git` command
21:58:43 <petern> I never remember the magic git command line incantation to check out PRs though :/
21:58:43 <nielsm> the thing is that you can change how many real time minutes one calendar year takes to pass
21:58:55 <pickpacket> but how does that mesh with removing dates from other aspects? Will dates and years still be displayed somewhere?
21:59:08 <nielsm> they should still be somewhere, yes
21:59:28 <petern> `git fetch upstream pull/10315/head:pr10315` maybe
21:59:38 <nielsm> you basically get two parallel measures of time progression: technological calendar, and economy calendar
21:59:44 <pickpacket> Then you would essentially use two different timescales simultaneously?
21:59:47 <TallTyler> And the player NEVER sees the economy calendar
22:00:10 <TallTyler> Industry "produced last month", timetable durations, etc., become real-world seconds and minutes
22:00:22 <nielsm> but the economy calendar measures things in minutes of real time (1 minute = 30 days at 100% speed)
22:00:28 <TallTyler> The economy calendar is purely internal, and always goes the same speed to match real-world time
22:00:49 <petern> Have you worked out all that needs to be economy and all that should stay calendar? ๐Ÿ˜„
22:01:05 <TallTyler> Pretty much, although I'm sure I'm forgetting things
22:01:55 <petern> And I guess "stay" calendar means switching to using calendar.
22:01:57 <TallTyler> That does not mean I have actually changed them over yet ๐Ÿ˜‰
22:02:12 <pickpacket> Uhโ€ฆ yeah Iโ€™m confused. Would there be a valendar at the bottom for the player to see the current date and year, but then production rates would be declared in real time minutes?
22:02:23 <TallTyler> Yes
22:02:24 <pickpacket> because that really sounds confusing
22:02:55 <pickpacket> Which perceived problem would it solve?
22:02:56 <TallTyler> Let me open a PR, and then people can try the preview build and tell me all the things that are missing from my to-do list
22:03:17 <TallTyler> It solves https://github.com/OpenTTD/OpenTTD/discussions/8397
22:03:18 <petern> It solves the problem that people want to change the length of games.
22:03:26 <imlegos> Making games last longer between vehicles but not play like you're waiting on a snail race for cargo
22:03:31 <petern> Daylength is older than OpenTTD ๐Ÿ˜„
22:04:22 <petern> Those niche engines that are only good for a few years before something better comes along? You get more use out of them...
22:04:38 <TallTyler> You can play steam trains forever!
22:04:41 <pickpacket> someone will have to explain to me how these two things relate to each other. Maybe Iโ€™m just too tired to get it
22:04:58 <imlegos> The current daylength factor that i remember experimenting with in jgr at one point, and playing with a longer day time would also effect the rate at which cargo generated
22:05:12 <JGR> This was originally a deliberate side-effect
22:05:33 <imlegos> The goal here is to *not* have cargo take longer to generate while at the same time the day took longer to progress
22:05:33 <JGR> Pax generation is too high for using cargodist, day length conveniently also resolved that
22:05:37 <nielsm> pickpacket: industries keep producing cargo at the rate they've always done, vehicles load cargo at the rate they've always done, vehicles move at the speed they've always done
22:06:05 *** borishiro has quit IRC (Ping timeout: 480 seconds)
22:06:15 <reldred> imlegos: JGR has options to then compensate
22:06:30 <reldred> for instance I use a dayfactor of 11x and a cargo factor of 5x
22:06:36 <andythenorth> can we have a thread for this?
22:06:46 <andythenorth> it will go on and on in overlapping conversations of confusion
22:06:47 <JGR> There are loads of day length threads on the forums ๐Ÿ˜›
22:07:00 <TallTyler> We can have a PR soon
22:07:01 <imlegos> The compensate option just means tge burst of cargo that happens every few minutes is larger
22:07:01 <andythenorth> TL;DR we want more time between engines
22:07:12 <andythenorth> but we can't have more time between engines with real dates because train fans
22:07:17 <andythenorth> therefore change time
22:07:24 <petern> > Game year duration dropdown has been moved from "New Game" dialog into "Intro" dialog.
22:07:25 <pickpacket> nielsm: in relation to real time clock, you mean? So in relation to days in the game all vehicles and cargo production would be faster?
22:07:27 <petern> Weird design choice there.
22:07:29 <andythenorth> changing daylength is full of elephant traps
22:07:33 <andythenorth> so change the display of time
22:07:44 <andythenorth> change years to minutes, the foamers can't complain
22:07:45 <petern> Dunno who kaomoneus is but
22:07:59 <andythenorth> everyone wins
22:08:02 <andythenorth> profit
22:08:08 <TallTyler> Slow Pace developer? Yeah, that's an interesting implementation
22:08:08 <reldred> andythenorth: come on, don't be so naive, someone will always complain
22:08:22 <andythenorth> reldred: those who want weird daylength shit will complain
22:08:28 <andythenorth> like the ones who want vehicles to move slower
22:08:40 <reldred> andythenorth: now that's just disgusting
22:08:44 <petern> Not seen what they've done.
22:08:44 <pickpacket> I meanโ€ฆ the year over year profit would go theough the roofโ€ฆ
22:08:46 <andythenorth> well now they can have 'real time'
22:08:55 <petern> But they don't seem to grok how git development works ๐Ÿ˜„
22:08:56 <JGR> andythenorth: Those people aren't on vanilla anyway
22:09:17 <JGR> The people who will really kick off are the reddit/openttdcoop people
22:09:41 <imlegos> pickpacket: This does make a note that not only would we want to detach industry cargo generation from in-game time, but also cargo payment rates
22:09:42 <reldred> *redditors...* ๐Ÿคฎ
22:10:51 <petern> Year by year may be higher, but realtime not.
22:10:53 <imlegos> Or is cargo payment already on 'real time'
22:10:55 <TallTyler> Adjusting town and industry production is a separate discussion, this PR does not change how the economy works
22:11:15 <petern> \o/
22:11:21 <pickpacket> imlegos: which means adjusting vehicle purchase and running costs
22:11:37 <petern> They're related ... but independent things.
22:12:01 <andythenorth> JGR: openttdcoop is over, and reddit can be self-selected out
22:12:20 <imlegos> The point of detaching payment rates would be so that crossing the whole map in 1 day to generate a billion dollars isn't a thing
22:12:28 <andythenorth> there is one angry poster with a signal obsession and 999 redditors who take screenshots with a phone
22:12:36 <andythenorth> ๐Ÿ˜›
22:13:12 <nielsm> payment rates are economy time, you don't cross the map in "one day" you cross it in "8 minutes" (or however fast/slow the vehicle moves)
22:13:41 <imlegos> Oh, so that's already done?
22:14:04 <pickpacket> imlegos: yeah instead payment rates would be calculated on real time minutes, of which there could be any number in a given year
22:14:14 <nielsm> payments are calculated on how many game ticks the delivery takes, not how many days on the calendar
22:14:21 <imlegos> Ah
22:14:59 <imlegos> The in-game cargo payment rates graph confused me since it says 'days in transit'
22:15:18 <nielsm> yes, that would need to be changed to "seconds in transit"
22:15:26 <TallTyler> There are so many things to change ๐Ÿ™‚
22:15:38 <nielsm> (one original-day is two seconds)
22:15:40 <pickpacket> And if we decide that a year is twice or ten times as many ticks, then the profits per year double or increase tenfold as well
22:16:30 <nielsm> yes "production last month" becomes "production last minute", and "profit last year" becomes "profit last 12-minute period"
22:16:34 <andythenorth> my alternative proposal didn't seem to stick ๐Ÿ™‚
22:16:54 <pickpacket> changing the balance sheet to work on minutes instead of calendar year completely detaches it from the idea of running a company on a fiscal year
22:17:00 <nielsm> it's just that "12-minute period" is kind of annoying to read and write
22:17:15 <pickpacket> andythenorth: I must have missed that. What was it?
22:17:22 <glx[d]> https://github.com/glx22/OpenTTD/actions/runs/3850789712/jobs/6561328134#step:5:20 <-- it's a joke
22:18:06 <nielsm> anyway, sleep time, gn
22:19:16 <dP> nielsm: I kinda missed the start of discussion but if you want to have that in gui it would look utterly ridiculous imo
22:19:36 <pickpacket> You would get the same โ€dilation of year without snail pace vehiclesโ€ by adding the possibility of slowing down game time coupled with a NewGRF that changes vehicle speeds
22:19:48 <petern> glx[d]: Uhhhhhh
22:20:01 <reldred> dP: Agreed,
22:20:41 <FLHerne> yeah, I really don't love the in-game minutes
22:20:48 <FLHerne> suspension of disbelief or something
22:20:57 <FLHerne> also, it would get really silly in case of game lag :p
22:21:09 <reldred> For initial development of the feature? Sure, but as a player I wouldn't want to look at that.
22:21:26 <FLHerne> pickpacket: yeah, but then it kind of breaks every NewGRF ever
22:21:41 <glx[d]> ok I was missing "--global"
22:21:45 <reldred> though to be honest, I'm perfectly content with jgrpp's implementation.
22:21:50 <FLHerne> and balance between vehicle speeds and production etc
22:21:52 <andythenorth> alternative proposal was change the formatting of date
22:21:52 <reldred> it achieves what I want.
22:22:00 <pickpacket> the choice to slow down game time could actually be useful in a single player game, actually. I usually quickly reach a point where I just canโ€™t build things fast enough to spend the money
22:22:07 <glx[d]> but the error message is not clear
22:22:20 <andythenorth> instead of "26th October 1985" do "26th October year 65"
22:22:26 <andythenorth> (my game started in 1920)
22:22:41 <andythenorth> it's less flexible
22:23:05 <reldred> Even that I'm not too crash hot on Andy, even though other games do use 'company year'
22:23:18 <andythenorth> they do
22:23:20 <andythenorth> a lot
22:23:32 <JGR> No single choice will please everyone
22:23:33 <pickpacket> Iโ€™m off to sleep as well. Can hopefully catch up on the discussion tomorrow :)
22:23:41 <JGR> I would just add a setting, but that's just me ๐Ÿ˜›
22:24:43 <TallTyler> "Just" add a setting would make this so much more difficult than it already is, I think
22:25:03 <TallTyler> Assuming you mean a setting to change strings, graphs, timetables, etc
22:25:22 <JGR> There's a trade-off between extra development time and never-ending user support
22:25:40 <andythenorth> try minutes, see what we learn ๐Ÿ˜›
22:25:42 <TallTyler> I won't throw out the idea now though, too much yet to finish before we can really debate implementation details
22:25:45 <andythenorth> https://www.youtube.com/watch?v=46h7oP9eiBk
22:26:11 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:27:18 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:27:49 <reldred> I dunno, I'm quite attached to years as they currently are. I design newhouses sets to introduce buildings based on real world years and architectural design progression, I've got no problem with how text gets rendered for the design and testing of a feature but it isn't what I would want to see going forward when playing the game.
22:28:25 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #10322: Tyler ruins time https://github.com/OpenTTD/OpenTTD/pull/10322
22:28:49 <TallTyler> Oops, didn't mean to have the branch name be the PR title, but that works too I guess ๐Ÿ˜›
22:29:19 <reldred> lmao
22:29:22 <reldred> that's beautiful
22:30:03 <petern> Yup ๐Ÿ™‚
22:30:10 <andythenorth> reldred: I design train sets to be realistic to within +/- 20 years of the intro dates for THE TRAINS THAT ARE FAKE
22:30:18 <andythenorth> I would like to adjust time ๐Ÿ˜›
22:30:34 <reldred> I don't always play with your fake trains andy ๐Ÿ˜›
22:31:04 <TallTyler> I do
22:33:48 <andythenorth> I don't
22:33:50 <andythenorth> NARS 2
22:34:18 <reldred> โค๏ธ NARS2
22:34:49 <reldred> I wish your offsets for your sprites you two used were closer so I can run horse wagons on nars2 but it doesn't look great
22:34:50 <TallTyler> My biggest problem with NARS is that all the trains are slightly different speeds, so everything gets bogged down under heavy traffic instead of flowing nicely
22:35:12 <reldred> TallTyler: that's the challenge I like, seperating out services, etc.
22:35:26 <TallTyler> I could probably decompile and fix but it's easier to bully Andy into making Moose ๐Ÿ˜›
22:35:37 <reldred> We should still do that anyway
22:35:45 <reldred> andythenorth: WANT MOOSE
22:35:50 <TallTyler> Nah, I get separating passenger and freight, but all the freight engines and wagons go slightly different speeds
22:36:02 <reldred> JGRPP realistic braking solves a lot of issues as well
22:36:22 <TallTyler> Speed adjustment I think, actually
22:36:29 <reldred> Yeah it's part of that
22:36:41 <reldred> speed adjustment came online as part of that feature
22:36:45 <TallTyler> It's buggy though, some of my trains keep slow even after the train in front takes a different track
22:36:56 <reldred> eh, doesn't give me much grief.
22:38:36 <JGR> The speed adaptation thing is from JokerPP and is really for homogenous networks
22:43:06 *** m1cr0man has quit IRC (Quit: G'luck)
22:43:30 *** m1cr0man has joined #openttd
22:45:28 <dP> looking at #10322, using real-world minutes seems counter-productive. it makes things that are logically belong to ingame time line looks ridiculous and only supposed feature is that it makes things like productions look the same when in reality they changed completely. bad-bad feature :p
22:46:59 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #10323: Fix: [Actions] preview_build failure due to git upgrade https://github.com/OpenTTD/OpenTTD/pull/10323
22:49:32 <andythenorth> such encouragement ๐Ÿ˜›
22:49:55 <andythenorth> is there ever going to be a feature that doesn't get shot down 5 times in chat?
22:51:37 <JGR> Getting feedback of one kind of another is the whole point of publicly raising it in the chat after all
22:53:10 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299
22:53:10 <andythenorth> speaking as someone who can be quite brutal, it's quite a brutal environment for newbies
22:53:36 <petern> It isn't actually real-world. You can pause it ๐Ÿ˜‰
22:53:42 <andythenorth> the chat?
22:53:49 <andythenorth> ๐Ÿ˜›
22:53:50 <JGR> I wouldn't minimise Tyler, he's no newbie
22:54:41 <andythenorth> I mean the first time I joined irc I got in a long argument about cdist and got shot down multiple ways and I'm still here
22:54:44 <andythenorth> but still
22:54:54 <andythenorth> the measure of some features is whether they work in game
22:54:57 <petern> Only just still here.
22:54:58 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10323: Fix: [Actions] preview_build failure due to git upgrade https://github.com/OpenTTD/OpenTTD/pull/10323#pullrequestreview-1238148928
22:55:09 <andythenorth> well I used to get kicked from irc
22:55:23 <andythenorth> but that's because of Truebrain's sense of humour
22:55:44 <glx[d]> let's try automerge
22:55:52 <andythenorth> not sure if TB actually can kick me from discord ๐Ÿ˜›
22:56:18 <andythenorth> /me replaces some variants to change the colour scheme
22:56:28 <glx[d]> we never kicked from IRC (it was dorpsgek)
22:56:36 <petern> I did.
22:56:45 <dP> petern: I tested #10315 a bit and that bug seems gone but I might have found another one, not sure if it's related but without #10315 doesn't seem happening
22:57:05 <petern> What's the another bug?
22:57:15 <dP> https://cdn.discordapp.com/attachments/1008473233844097104/1060693493158264973/Screenshot_from_2023-01-06_02-53-54.png
22:57:15 <dP> https://cdn.discordapp.com/attachments/1008473233844097104/1060693493506388058/Screenshot_from_2023-01-06_02-53-42.png
22:57:15 <dP> running reload_newgrfs enables one of the default vehicles
22:57:47 <dP> x10p is in the depot from the beginning so technically #10315 seems fixed
22:57:49 <LordAro> glx[d]: windows ci :(
22:58:24 <glx[d]> not the first time I'll rerun
22:58:38 <FLHerne> I like the overall idea of separating gameplay and "years" time
22:58:49 <dP> anyway, sleep time
22:58:55 <FLHerne> just labelling gameplay time in real-world minutes is weird
22:59:03 <FLHerne> although tbh I don't have a better idea...
22:59:26 *** Samu has quit IRC (Quit: Leaving)
22:59:58 <LordAro> glx[d]: strange failure
23:00:16 <petern> Hmm, this checkout is "grafted"
23:00:45 <petern> I don't think I like this github PR feature.
23:00:48 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1060694385890705478/image.png
23:00:48 <andythenorth> random wagons got quite random
23:00:57 <petern> VS Code github extension, that is.
23:01:33 <Pruple> dP: there seem to be a number of default vehicles in both screenshots, is it not just un-expiring one due to reliability rerandomisation?
23:01:36 <petern> Seems to cause other branches of the PR author's repository to be fetched too. Pretty odd.
23:02:15 <TrueBrain> andythenorth: Owh, you love me anyway โค๏ธ
23:02:24 <andythenorth> sometimes
23:02:26 <andythenorth> conditionally ๐Ÿ˜›
23:02:40 <TrueBrain> Pffff, I deserve unconditional love
23:02:48 *** HerzogDeXtEr1 has joined #openttd
23:03:21 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:03:36 <andythenorth> probably
23:03:53 <TrueBrain> How to kick someone from Discord .......... ๐Ÿ˜‰
23:05:24 <petern> Pruple: Yeah, that's just reset_engines rerandomisation.
23:06:14 <petern> If it was enabling a default engine that was disable, that would be another thing.
23:06:46 <dP> Pruple: Yeah, maybe it was just unlucky, I'll test more tomorrow
23:06:59 <petern> Not unlucky, just random
23:07:46 <petern> Although I, er, reinstated intro date rerandomisation slyly too, semi-unintentionally.
23:08:01 <dP> Unlucky in a sense that it only happened in non pr version xd
23:08:09 <petern> Ahh
23:08:27 <petern> Try multiple reset_engines ๐Ÿ™‚
23:08:38 *** HerzogDeXtEr has quit IRC (Ping timeout: 480 seconds)
23:08:54 <dP> I did, that's the funny part
23:09:12 <dP> Though only checked non pr once
23:09:47 <petern> https://cdn.discordapp.com/attachments/1008473233844097104/1060696647992082462/image.png
23:09:56 <petern> This checkout makes it hard to see changes :/
23:14:46 <petern> https://github.com/microsoft/vscode-pull-request-github/issues/1044
23:19:16 <andythenorth> TrueBrain: get my auth creds, violate policy, then wave bye bye to my account?
23:19:44 <TrueBrain> andythenorth: This isn't Slacks GitHubs tokens
23:19:44 <petern> Hmm.
23:19:56 <andythenorth> ๐Ÿ˜›
23:20:08 <petern> "Calendar progress speed" probably needs to reference "Daylength" otherwise nobody will find it ๐Ÿ™‚
23:20:18 <andythenorth> should I replace these trains?
23:20:20 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1060699302642589766/image.png
23:20:24 <andythenorth> oh wrong channel ๐Ÿ˜›
23:20:28 <petern> "affects only new games" may be an issue too.
23:21:29 <petern> andythenorth: Nah, refit them instead.
23:21:51 <andythenorth> hmm
23:22:00 <andythenorth> goes it rework Horse?
23:22:00 <andythenorth> subtypes?
23:22:10 <andythenorth> why do we even have replace?
23:22:15 <andythenorth> could just subtype refit to new model
23:22:19 <andythenorth> much more convenient
23:22:34 <andythenorth> Trigger's broom
23:22:50 <petern> Oh, it says "affects only current game" now, I misinterpreted that then.
23:23:05 <andythenorth> https://www.youtube.com/watch?v=56yN2zHtofM
23:23:42 <LordAro> petern: NoDaylength
23:24:40 <TallTyler> It needs a catchy acronym so we can talk about it here and confuse new people, like when we go on about NRT roads
23:25:12 <Rubidium> TallTyler: NoTime?
23:25:23 <glx[d]> matches noai and nogo
23:25:24 *** m1cr0man has quit IRC (Quit: G'luck)
23:25:27 <Rubidium> not really an acronym though
23:25:44 *** m1cr0man has joined #openttd
23:25:49 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #10323: Fix: [Actions] preview_build failure due to git upgrade https://github.com/OpenTTD/OpenTTD/pull/10323
23:26:17 *** m1cr0man has quit IRC ()
23:26:19 * glx[d] likes the automerge magic
23:26:20 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299#issuecomment-1372923355
23:26:32 *** m1cr0man has joined #openttd
23:27:20 <Rubidium> glx[d]: though there's no "autoremove branch" button checkbox, which makes it suboptimal
23:27:35 <glx[d]> so true
23:27:46 *** m1cr0man has quit IRC ()
23:28:01 *** m1cr0man has joined #openttd
23:28:10 *** borishiro has joined #openttd
23:28:49 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10299: Enable CodeQL code scanning https://github.com/OpenTTD/OpenTTD/pull/10299#issuecomment-1372925149
23:29:19 <glx[d]> let's try a re-run of a failed preview
23:29:59 <glx[d]> ok re-run is not enough
23:32:07 <petern> https://cdn.discordapp.com/attachments/1008473233844097104/1060702264781701130/image.png
23:32:07 <petern> Nice ๐Ÿ™‚
23:32:11 <TrueBrain> Nope, it rerun on the exact same revisions, sadly ๐Ÿ™‚
23:32:19 <TrueBrain> Maybe a good thing in most cases, I guess
23:32:37 <glx[d]> but re-runing preview_push or preview_label works
23:32:48 <glx[d]> as they redispatch
23:33:01 <TrueBrain> Yup, cheats! ๐Ÿ˜„
23:34:04 <TrueBrain> 536 alerts left .. not bad ๐Ÿ˜„
23:36:33 <glx[d]> ah preview_push skips the dispatch when reran
23:41:47 <Rubidium> TrueBrain: 525 if you account for #10317 I think :) So only 4 high security remaining, of which 2 are #10309, to check/fix before 13.0
23:42:45 <TrueBrain> Nice nice! Almost a green checkbox ๐Ÿ˜„
23:45:29 <glx[d]> ok all the previews should be back soon
23:45:50 <glx[d]> (only 3 PRs were affected)
23:46:55 <glx[d]> almost a flawless upgrade ๐Ÿ™‚
23:59:25 <glx[d]> <https://github.com/OpenTTD/OpenTTD/actions/runs/3851212107/jobs/6562159746> seems to work