IRC logs for #openttd on OFTC at 2023-12-12
00:14:38 <_zephyris>
00:14:38 <_zephyris>
00:14:38 <_zephyris> What a mission...
00:15:32 <FLHerne> aagh, Toyland
00:15:56 <FLHerne> it's so easy to simply forget it exists but then you have to remind us :-(
00:17:33 <_zephyris> It's here to haunt your dreams!
00:18:12 <_zephyris>
00:18:12 <_zephyris> I should've made this font ages ago, so much easier than pixel pushing.
00:21:28 <peter1138> Now draw the small font ;-)
00:21:49 <FLHerne> Is that a vector version of the standard pixel one?
00:22:29 <FLHerne> well, vector font with similar appearance
00:24:21 <peter1138> If you get brave you can set up kerning pairs, I think.
00:24:34 <_zephyris> Yup, normal TTF font ๐Ÿ™‚ Well, the first half of the ASCII range
00:24:55 <_zephyris> peter1138: I was going to ask if OTTD supported kerning...
00:25:15 <peter1138> It does.
00:25:39 <peter1138> It's not even OpenTTD doing it. It's whatever platform-dependent text layouter is used.
00:26:08 <_zephyris> Oh, interesting
00:26:25 <_zephyris> Time to try some contextual alternates and ligature then...
00:26:54 <_zephyris> I couldn't get the diacritic 'overflow' working BTW...
00:27:17 <_zephyris> Past my fontforge knowledge, for now at least
00:33:26 <peter1138> Probably just a number somewhere.
00:38:48 <_zephyris> "7.1.2. Setting the baseline to baseline spacing of a font.ยถ
00:38:48 <_zephyris> You might imagine that there would be an easy way to set this seemingly important quantity. Unfortunately there is not."
00:38:53 <_zephyris> Goodie.
00:40:11 <_zephyris> Ah, so, obviously you have to set the OS/2 font settings to control TTF/OTF line height
00:41:07 <_zephyris> :widdle_goblin:
00:51:11 <peter1138> obvs
00:51:54 <peter1138> Hmm, adding at least 358 StrongType .base() calls probably suggests that using a StrongType is not the way to go.
01:14:59 <talltyler> Maybe not
01:25:50 <Eddi|zuHause> i've seen worse commit messages.
01:26:08 <Eddi|zuHause> argh, was in buffer again
01:26:37 <Eddi|zuHause> why have irc clients in the last 20 years not learned to warn people about that?
01:34:24 <talltyler> Or I guess that some helper functions are needed to avoid having to convert all over the place
02:56:46 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10543: Feature: Region-based pathfinder for ships (no more buoys!)
03:16:40 *** Flygon has quit IRC (Read error: Connection reset by peer)
03:26:27 *** Wormnest has quit IRC (Quit: Leaving)
03:56:21 *** D-HUND has joined #openttd
03:59:36 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:00:16 <locosage> xarick: it is correct for x > 1 and y > 1
04:24:01 *** felix has quit IRC ()
04:24:16 *** felix has joined #openttd
04:47:02 *** keikoz has joined #openttd
06:28:05 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:08:38 *** merni_ has joined #openttd
07:45:14 *** merni_ has quit IRC (Remote host closed the connection)
08:24:45 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
08:56:58 <peter1138> Hmm, is it possible to drop the requirement for 1x 8bpp sprites?
09:02:27 <Eddi|zuHause> might be difficult, but not impossible?
09:03:12 <Eddi|zuHause> should go along with deprecating 8bpp blitters, though, otherwise you need to provide awkward conversions
09:03:56 <peter1138> I don't think so. The authors are already making 32bpp NewGRFs with dummy 8bpp sprites.
09:04:07 <peter1138> It would be better to not have the dummy sprites.
09:05:32 <LordAro> The Authors
09:05:54 <peter1138> More than one but not all.
09:05:56 <Eddi|zuHause> sounds like a secret kabal
09:06:15 <peter1138> LordAro, now I have the Archers theme tune :(
09:07:49 <peter1138> I'm not sure if the requirement is from grfcodec/nmlc or OpenTTD.
09:16:28 <Eddi|zuHause> i'm pretty sure the requirement was just from not disturbing the specs too much, and that the game should still run with 8bpp blitters
09:19:20 <Eddi|zuHause> if you drop the requirement from grfs, you're factually deprecating them, might as well just declare them as deprecated as well.
09:21:17 <Eddi|zuHause> alternatively (and with less spec fumbling) you could just make nmlc provide the 8bpp conversions implicitly. solves the dummy sprite problem.
09:29:43 *** ahyangyi has joined #openttd
09:29:43 <ahyangyi> Not all grfs are made with nml though
09:29:54 <ahyangyi> In particular, the bridge ones
09:30:54 <ahyangyi> Anyway, I don't think "dropping a requirement that people are already working around" has much compability concern... Is the ability to enforce 8bpp blitter and get invisible sprites really so necessary?
09:40:34 *** thelounge34 has quit IRC (Quit: The Lounge -
09:43:48 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11495: Change: Simplify sprite cache memory management
09:44:03 *** thelounge345 has joined #openttd
09:52:09 <_zephyris> The simplest way to drop 8bpp is to formalise what is already done (ie. dummy 8bpp sprites), grab better metadata about newgrfs and provide a user error if using 8bpp-only blitter with a newgrf which reports as 32bpp only.
10:18:38 <locosage> It's not that hard to auto-convert 32bpp to 8. Some colours will change but overall it's playable
10:20:06 <ahyangyi> I can imagine edge cases like "one newgrf overrides base set graphics, another newgrf applies company colours on it" ๐Ÿ˜›
10:20:44 <ahyangyi> a bit like the recent discussion inDiscord channel #add-on-development, but more automagical and thus uncontrollable
10:24:25 <_zephyris> An intelligent 32bpp -> 8bpp without stray recolours and animated palette entries is trivial. Just do the conversion obeying the mask files, if provided.
10:25:17 <locosage> I wouldn't exactly call it trivial to do right and fast but doable
10:26:02 <locosage> needs a LUT basically
10:26:25 <_zephyris> Should've said this is a negative thing, ie. convert to 8bpp _not_ using commonly recoloured palette entries or aimated palette entries, unless an entry in that recolourable index series/anim colours is provided.
10:26:32 <_zephyris> It's how OpenGFX2 works ๐Ÿ˜‰
10:27:41 <_zephyris> You'd probably need to exclude the strucure recolour, CC and 2CC ranges, but not too bad.
10:30:26 <peter1138> _zephyris, "formalise what is already done (dummy 8bpp)" is a shitty solution.
10:30:39 <peter1138> A much better solution is "not require dummy 8bpp"
10:31:05 <peter1138> If there is dummy 8bpp, then OpenTTD doesn't know that 8bpp isn't supported.
10:31:14 <peter1138> If there is no 8bpp, then OpenTTD knows.
10:32:26 <peter1138> It can then tell the player, or maybe even convert to 8bpp itself.
10:33:00 <peter1138> But the current way of dummy 8bpp is probably the worst way.
10:33:26 <_zephyris> I said it was simplest, not least shitty ๐Ÿ˜‰
10:34:08 <_zephyris> You're totally right, you don't need metadata saying not 8bpp if there are no 8bpp sprites!
10:34:18 <peter1138> Okay but the idea of formalising it scared me :p
10:34:48 <peter1138> So... what actually makes the dummy 8bpp sprites required right now
10:34:58 <peter1138> Is it the tooling or the game?
10:35:13 <locosage> tooling
10:35:33 <locosage> I've yet to see any issues in the game with grfs lacking 8bpp
10:35:47 <locosage> 8bpp blitter aside ofc
10:37:59 <peter1138> So you have already made NewGRF which are 32bpp-only?
10:39:34 <locosage> yes, this one doesn't provide 8bpp sprites: <>
10:42:15 <ahyangyi> Hmm
10:42:55 <ahyangyi> So it's a workaround that tries to circumvent an NML restriction?
10:43:01 <ahyangyi> rather than a NewGRF one
10:47:49 <_zephyris> AFAIK it't not an NML restriction, it's a NewGRF restriction and the NFO and NML syntax are designed with the 'there must be an 8bpp sprite' requirement in mind.
10:49:12 <locosage> there is no restriction newgrf format
10:49:49 <locosage> grf-py doesn't require 8bpp sprites since I never saw the point
10:50:53 <_zephyris> Huh
10:50:57 <_zephyris> Interesting
11:22:44 <FLHerne> from "The type of the 1st sprite must always be 8bpp and of 'normal' zoom level" ?
11:23:30 <FLHerne> it might not blow up (when not using an 8bpp blitter) but it's definitely out-of-spec
11:49:32 <peter1138> Change the spec :_)
11:49:59 <Eddi|zuHause> well, there's no way forward without changing the spec. :p
11:51:15 <_zephyris> So what happens when OpenTTD tries to access a non-existent 8bbp sprite?
11:53:24 <Eddi|zuHause> i hope there are guards in place to catch that
12:05:52 *** thelounge345 has quit IRC (Ping timeout: 480 seconds)
12:10:30 *** thelounge345 has joined #openttd
12:13:56 <peter1138> You get the red ?
12:14:13 <peter1138> Which is fine, it doesn't crash, and it means we have the ability to know it is not present.
12:20:27 <peter1138> IIRC grfcodec fails decoding locosage's GRFs.
12:21:24 <peter1138> Not sure if it's because it's missing 8bpp, or because something else is wonky.
12:29:09 <xarick>
12:29:09 <xarick> a nice little table
12:29:46 <xarick> max distance from town for each noise level for each town_council_tolerance
12:34:54 <xarick> oh, it's only for the intercontinental airport type
12:39:42 <Eddi|zuHause> i almost fed the trolls...
12:40:24 <Eddi|zuHause> someone(tm) complained the game was unplayable. and i wanted to write, for an unplayable game, surely a lot of people play it.
12:41:46 <Eddi|zuHause> (something about a scenario using an old/broken AI, didn't read the whole thing)
12:47:38 <peter1138> Hmm
12:49:01 *** Flygon has joined #openttd
12:50:37 <Eddi|zuHause> what ever happened to the new scenario format?
12:52:11 <peter1138> locosage, does robs_trains.grf reuse data sections?
12:53:15 <peter1138> spriteno 74 -> 395
12:53:19 <peter1138> spriteno 75 -> 395
12:53:22 <peter1138> Seems so :)
12:54:09 <peter1138> Looks like grfcodec assumes all data sections sequential -- it doesn't set up a map of id to position like OpenTTD does.
12:54:22 <peter1138> So I think I know how to fix ti :D
12:55:20 <talltyler> Eddi: 10409 is a step towards a reproducible scenario format
12:55:27 <talltyler> I just need to finish it ๐Ÿ™‚
12:56:21 <talltyler> I read the thread too, and wish I hadnโ€™t. I liked the part about how we should call the current version 0.13.4 because the game is full of bugs and is still in early beta
12:57:05 <talltyler> But I successfully prevented myself from replying something rude, so thereโ€™s my little win for the day ๐Ÿ˜›
13:11:04 <peter1138> Error: GRFCodec thinks it has written 745 sprites but the info file only got 606
13:11:09 <peter1138> Hmm, it got further :D
13:12:08 <Eddi|zuHause> was there ever a requirement that grfcodec can decode every valid grf?
13:12:09 <peter1138> Hmm, there are some 1x1 pixel 8bpp sprites apparently.
13:12:24 <peter1138> Valid? Yes.
13:13:24 <peter1138[d]>
13:13:42 <peter1138> It decoded at least :D
13:14:25 <talltyler> Huh, looks like I can use a text button with no text as a green/red boolean button ๐Ÿ™‚
13:14:39 <peter1138> STR_EMPTY
13:14:46 <talltyler> Options menu has such a text-less button (but doesn't change colour)
13:14:48 <peter1138> or STR_NULL maybe.
13:15:00 <peter1138> Yes, I did mention the Game Options window last night ;)
13:15:03 <talltyler> STR_EMPTY
13:15:08 <talltyler> I was pretty tired last night ๐Ÿ™‚
13:15:38 <Eddi|zuHause> GRF parameters should have similar buttons
13:15:49 <peter1138> Nope
13:15:55 <peter1138> Those aren't real widgets.
13:16:27 <peter1138> With those the grf parameter window has to manually check the cursor position.
13:17:00 <peter1138> Hmm, okay, so probably the issue here is that NFO has no way to represent "reuse this sprite"
13:17:38 <peter1138> So every time is encounters id 395 is creates another 1x1 pixel.
13:18:02 <peter1138> However, I'm not sure why the 1x1 pixel exists.
13:18:20 <peter1138> It's like a spriteset result that is presumably not used, but then why is it there?
13:18:36 <peter1138> (That's probably a question for locosage)
13:18:41 <LordAro> that thread was very fun
13:18:50 <peter1138> Thread...
13:19:19 <peter1138> Sorry :(
13:20:53 <LordAro> how about a warning when a train is being asked to full load at a station it can never pick up from?
13:21:02 <LordAro> oh, transfers :/
13:21:24 <talltyler> Truly a PEBKAC problem
13:21:36 <LordAro> of course
13:21:38 <Eddi|zuHause> a warning when loading takes extraordinarily long?
13:21:47 <LordAro> but an understandable confusion from a new player
13:22:08 <talltyler> Transport Fever has a configurable maximum wait time for full load orders, I think it defaults to 2 minutes
13:22:21 <Eddi|zuHause> 3 minutes, but yes.
13:22:24 <talltyler> But can be set to unlimited
13:22:30 <talltyler> I like that approach, actually
13:23:04 <Eddi|zuHause> yes, current way of timetabling a full load order doesn't make any sense
13:23:47 <LordAro> that could work
13:23:53 <Eddi|zuHause> transport fever's timetabling could also be improved, however.
13:24:07 <LordAro> assuming people are happy with a "technically wrong" full load order
13:26:44 <Eddi|zuHause> well, transport fever has separate "minimum" and "maximum" times for loading
13:26:57 <Eddi|zuHause> but no timelimits for travelling
13:34:56 <talltyler>
13:34:56 <talltyler> Hmm, how to format this...
13:35:42 <talltyler> Do I do like the map edges, and have text buttons?
13:36:09 <talltyler> Wide green is just wrong
13:36:37 <peter1138> Oh, it's for the game menu!?
13:36:52 <peter1138> Yes, text toggle.
13:37:37 <peter1138> (Or drop down)
13:37:49 <talltyler> Huh. The setting can only be changed when starting a new I guess I can remove it from the Settings menu?
13:38:21 <talltyler> (most of my trouble has been trying to find a solution where they match between World Gen and Settings)
13:38:34 <peter1138> Yes, well, I still don't think that's a satisfactory solution.
13:39:20 <peter1138> But the settings menu style doesn't have to match the new game style.
13:44:47 <peter1138> Sorted. 745 sprites written :D
13:50:28 <peter1138> -rw-r--r-- 1 petern petern 679957 Dec 12 13:50 robs_trains.grf
13:50:30 <peter1138> -rw-r--r-- 1 petern petern 674857 Jul 17 17:37 robs_trains.grf.real
13:50:38 <peter1138> Slightly larger on rebuild.
13:50:44 <peter1138> But, uh.
13:50:55 <peter1138> Turns out grfcodec doesn't enforce that 32bpp comes first?
13:52:25 <peter1138> The decoded result of both is the same though.
13:52:28 <peter1138> So yes.
13:52:40 <peter1138> grfcodec is perfectly capable of creating 32bpp-only NewGRFs.
13:52:52 <peter1138> Decoding upsets it :)
13:57:21 <xarick> I need a variable name for "quietest airport with noise above 1"
14:00:22 <_glx_> q
14:04:25 <_glx_> <> maybe not super clean, but with this change iron horse HST can't run on HST if a non HST wagon is in the consist
14:04:41 <locosage> peter1138[d]: iirc empty (1x1) sprites are there for purchase menu sprites
14:05:01 <locosage> probably there is a better way than just adding 7 empty sprites but I didn't investigate
14:05:32 <peter1138> No, all 8 sprites are 1x1
14:05:40 <peter1138> And also, you only need to provide 4.
14:06:06 <locosage> hm, need to check then xD
14:06:13 <peter1138> (Unless your west and east directions are different)
14:06:14 <locosage> I still only have 1
14:07:38 <locosage> it's using a generated purchase sprite so it only has one direction
14:08:29 <talltyler> A classic branch name, `stuff` ๐Ÿ˜›
14:08:42 <peter1138> locosage, those are 32bpp though, of course.
14:09:06 <peter1138> This is 8 consecutive 8bpp 1x1 sprites.
14:10:40 <peter1138>
14:12:28 <peter1138> (Obviously all the 1x1s are actually just one single 1x1 in the GRF, but grfcodec can't handle that :))
14:12:34 <_jgr_> For vehicle purchase menu sprites you can just provide 1, you don't have to pad up to 4 or 8
14:12:59 <peter1138> _jgr_, nice. Looks like this GRF is already doing that too.
14:13:49 <peter1138> I wonder if I can make grfcodec use the same coordinates for the 1x1 sprites.
14:14:06 <peter1138> And then on encoding, if all the coordinates are the same, and it's container v2, reuse the same sprite.
14:14:29 <peter1138> Probably more useful to add that to nmlc though, tbh.
14:15:43 <_glx_> it's a pain to add stuff to nml ๐Ÿ™‚
14:17:05 *** nielsm has joined #openttd
14:17:11 <peter1138> So now it's just nmlc that enforces an 8bpp sprite?
14:17:32 <peter1138> Presumably if it didn't then people wouldn't have come up with the dummy 8bpp solution.
14:18:23 <locosage> ok, idk why it uses 8 empty sprites, it's on old version of the grf and the latest one doesn't seem to do that
14:18:35 <locosage> maybe that train just didn't have any graphics defined or smth
14:19:10 <peter1138> K
14:31:37 <locosage> oh, I figured it out, it's an invisible articulated part
14:31:50 <locosage> for engines with length > 8
14:32:00 <peter1138> Ahh
14:32:06 <peter1138> That old bad-feature :)
14:33:47 <locosage> I probably don't need 8 empty sprites for every cargo subtype on it but eh xD
14:44:43 <talltyler> Okay, so when using real-time units we have to lock the timetable mode (added in #11435) to Seconds. This is a client GUI setting.
14:44:43 <talltyler> But it's not tied to changing the real-time setting, because the player can load a savegame or join a multiplayer game... Where do we enforce this? Somewhere in saveload, or maybe when initializing the timetable GUI?
14:45:48 <talltyler> I've added a pre_cb to the timetable mode setting to lock it when the game is in real-time mode...I just need to set it properly when real-time mode is detected.
14:51:51 <peter1138> Okay, I've made a 32bpp-only GRF from NML.
14:54:00 <peter1138> -7 tram_foster_express.png 8bpp 48 1 8 18 -3 -10 normal
14:54:02 <peter1138> +7 tram_foster_express.png 32bpp 48 1 8 18 -3 -10 normal
14:54:06 <peter1138> Noice.
15:20:03 <andythenorth> _glx_: I should compile ๐Ÿ˜„
15:20:10 <andythenorth> did we "break" cdist again? ๐Ÿ˜›
15:20:19 <andythenorth> /me fears for my savegame
15:21:20 <_glx_> well issue might be if you have "incompatible" trains already running on "incompatible" tracks
15:21:47 <talltyler> How do you plan to handle that? Teleport to the nearest depot?
15:22:13 <peter1138> Just let them continue if they are already htere.
15:25:05 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #11341: Feature: Real-Time Mode
15:25:19 <talltyler> Finally fixed it ๐Ÿ™‚
15:25:26 <talltyler> Let's see what CI thinks
15:26:25 <xarick> I have a theory that might cause town->noise_reached to overflow
15:26:54 <xarick> place 4 towns near the 4 corners of the map
15:27:20 <talltyler> You know what to do with a theory, right? You have to test it. ๐Ÿ˜‰
15:27:49 <xarick> place noisy airports around the center of the map
15:28:02 <xarick> since they're too far away from the corner towns, they will get low noise
15:28:24 <xarick> now suddenly, place a town in the center of the map, inside the airports
15:28:36 <xarick> bam! new town should have noise_reached overflow
15:29:04 <andythenorth> convoluted cases ๐Ÿ™‚
15:29:06 <xarick> all the noise is transferred to the new town in the center
15:29:07 <andythenorth> are fun
15:29:30 <_glx_> and as said, it's totally fine
15:29:54 <andythenorth> if this is still that Reddit report, the OP said it was caused by FIRS
15:30:01 <andythenorth> I wouldn't discount that
15:30:05 <andythenorth> meanwhile
15:30:10 <_glx_> you will just not be able to build more noisy stuff near that town for some time
15:30:54 <andythenorth> <- OP says it was a FIRS error
15:31:13 <_glx_> the idea of noise limit is to prevent new build, but existing ones are ok
15:31:33 <talltyler> Occam's razor says everything is a FIRS error ๐Ÿ˜›
15:31:34 <peter1138> Customer's always right.
15:31:55 <andythenorth> we don't know which FIRS, or which parameters were on
15:31:56 <_glx_> paying customer's always right
15:32:10 <andythenorth> so we don't know...for example...if it's the version with untested features that attempt to do town stuff
15:32:19 <talltyler> The full quote is that the customer is always right in matters of taste. Not always right, period. ๐Ÿ˜‰
15:33:06 <talltyler> Meaning, people are allowed to mix aBase and standard zoom GRFs, not that they can do anything they want ๐Ÿ˜›
15:33:08 <andythenorth> has anybody retrieved the save from that reddit OP?
15:33:55 <talltyler> When I worked for the railroad I yelled at several customers who were risking their own lives. They were not right.
15:34:24 <peter1138> ...
15:34:47 <peter1138> We only ever use it as a joke. Only the US actually appears to have that attitude in places...
15:35:13 <talltyler> Unfortunately people take it seriously here ๐Ÿ˜ฆ
15:35:38 <xarick> andythenorth: we got save!
15:35:41 <peter1138> So if anyone outside the US says, it means they the customer is definitely not right.
15:35:44 <peter1138> +it
15:36:01 <talltyler> Lost in translation ๐Ÿ˜„
15:36:23 <peter1138> Basically, taking the piss.
15:36:41 <andythenorth> so how does xarick see which grfs the OP changed? ๐Ÿ˜›
15:36:49 <andythenorth> or what errors FIRS has thrown?
15:37:00 <andythenorth> I am not opening rando saves ๐Ÿ˜›
15:37:13 <talltyler> If you're using "taking the piss" as a universally-understood reference, I have bad news for you ๐Ÿ˜›
15:37:49 <peter1138> andythenorth,
15:38:18 <andythenorth> thanks for fixing FIRS again
15:38:47 <peter1138> talltyler, knowing that not everyone understands "taking the piss" is of course part of taking the piss by using the phrase...
15:38:59 <xarick> sec
15:39:55 <peter1138> andythenorth, how do I fix the NML ast in FIRS?
15:39:56 <xarick>
15:39:56 <xarick> andythenorth
15:40:18 <peter1138> I think those NewGRFs are from about 15 years ago.
15:40:21 <andythenorth> oh legacy FIRS
15:40:25 <andythenorth> that's probably "broken"
15:40:30 <talltyler> Nuance over text, etc
15:40:31 <andythenorth> 1.4.4M
15:40:36 <andythenorth> implies not a proper tag
15:40:39 <talltyler> Anyway, time for $real job
15:40:40 <andythenorth> or I brown-bagged the release
15:41:00 <andythenorth> peter1138: "yes"?
15:41:56 <peter1138> nmlc ERROR: "nml_output/026_asl.nml", line 18: Unrecognized identifier 'ZOOM_LEVEL_NORMAL' encountered
15:41:59 <peter1138> :o
15:50:40 <andythenorth> peter1138: xarick mystery solved ๐Ÿ™‚
15:51:13 <xarick> I don't think that solves much
15:51:27 <xarick> the bug was still unreproduced
15:51:53 <xarick> the underflow
15:52:14 <xarick> we just happen to step into that bug along the way
15:52:28 <xarick> but doesn't seem to be it that causes underflow
15:52:50 <andythenorth> what will happen if a noise value is removed from the wrong town?
15:53:28 <xarick> it was always consistent in being the "wrong" town, so...
15:55:19 <_glx_> andythenorth: should not happen, if noise is added to a town, it's removed from it
15:59:48 <andythenorth> magic bees then
15:59:49 <andythenorth> or sunspots
15:59:58 <andythenorth> cosmic ray hit the OPs memory chip
16:00:01 <andythenorth> flipped a bit
16:05:24 <peter1138> It was not always consistent.
16:06:39 <xarick> oh, how?
16:07:23 <peter1138> AirportTileTableIterator is used only when building the airport.
16:08:05 <peter1138> AirportTileIterator is used after that.
16:11:38 <andythenorth> that's what I thought the diff said
16:11:47 <andythenorth> so one will get the N tile, one won't?
16:11:52 <andythenorth> then the distance is wrong
16:11:59 <andythenorth> then we subtract the wrong distance
16:12:09 <andythenorth> I only guessed though based on skimming the diff ๐Ÿ˜›
16:13:16 <peter1138> All the FIRS code.
16:14:53 <_glx_> updated my branch
16:16:27 <xarick> i'm trying to understand
16:16:31 <xarick> lol
16:17:08 <xarick> the AirportTileTableIterator defines the first tile differently than AirportTileIterator ?
16:17:22 <peter1138> It can do, yes.
16:17:45 <xarick> ah, now THAT might be the reason for the underflow
16:18:10 <xarick> so it's different between placing vs removing
16:20:21 <xarick> but i was unable to reproduce it still, I placed in different orientations, and demolished
16:20:57 <xarick> and noise_reached for both towns were consistently >= 0
16:21:31 <xarick> need to test all airport types
16:21:40 <xarick> without the fix
16:24:09 <peter1138> You need to use a rotated airport from OpenGFX. The default airports all have the first tile as the top-corner origin, and they can't be rotated.
16:24:25 <peter1138> OpenGFX+ that is.
16:24:50 <peter1138> You also need two towns that are fairly close to each other.
16:25:40 <peter1138> It is not possible to reproduce from an airport in an existing savegame, as at that point the airport is already built.
16:31:48 *** Wormnest has joined #openttd
16:51:18 *** virtualrandomnumber has joined #openttd
16:52:05 *** virtualrandomnumber has quit IRC (Remote host closed the connection)
16:53:55 <xarick> okay, I reproduced something, not quite the underflow I was hoping, but... similar
16:54:32 <xarick> it added 3 noise to Funbridge on placement, and on removal, it removed 2 noise only
16:57:10 <andythenorth> it's 99% likely to be the same effect, different outcome
17:00:53 <peter1138> It's 99% likely to be FIRS.
17:02:14 <peter1138> But it is unplayable, so who knows.
17:03:27 <xarick>
17:03:27 <xarick> nop, it was OpenGFX+
17:03:40 <peter1138> Nope, FIRS.
17:04:01 <xarick> this thing doesn't play mkv files or what?
17:05:55 <merni> probably not
17:06:05 <merni> it's not a particularly common format these days
17:08:16 <peter1138> andythenorth, cake?
17:09:20 <xarick>
17:09:36 <merni> maybe discord just doesn't like previewing videos
17:09:45 <talltyler> So, we've got ship pathfinder binaries built. Do people prefer this Saturday or Sunday for a test game? (truebrain, now you can do something ๐Ÿ˜› )
17:09:47 <xarick> doesn't like mp4? must be HEVC being forbidden?
17:10:15 <talltyler> Just pick a date and I will create the event listing
17:12:06 <talltyler> kuhnovic: If you're free this weekend to join the test game, that might be helpful ๐Ÿ™‚
17:12:27 <merni> talltyler: I would prefer Saturday for entirely selfish reasons because I have something else on Sunday :p
17:12:34 *** keikoz has joined #openttd
17:13:03 <merni> if discord has such a thing as polls, maybe you could create one of those to find which day people want?
17:13:10 <merni> or a reaction poll in Discord channel #announcements ?
17:13:32 <peter1138> Or just set up a server and let people play...
17:13:37 <xarick>
17:13:37 <xarick> last test:
17:14:05 <xarick> nope, oh well, i can't get the nice video player feature in discord anymore
17:22:35 *** Wolf01 has joined #openttd
17:28:06 <xarick> I'm bad at maths
17:36:35 *** HerzogDeXtEr has joined #openttd
17:41:37 <peter1138> Is there a spec for the v2 container format?
17:50:23 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #9958: Add: [YAPF] Rail depot penalty based on the number of trains waiting in it
17:51:07 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10396: Change: More icon space size by interface scaling.
17:51:25 <peter1138> Very out of date :D
17:51:45 <merni> TallTylerviaGitHub: Why is it bad to go to a full depot?
17:52:25 <merni> it's not like the vehicles inside a depot occupy physical space
17:53:40 <peter1138> merni, a depot full of waiting vehicles means you will be waiting in it a long time.
17:54:26 <merni> hm
17:54:41 <merni> but wouldn't that be offset by the time taken to go to a farther depot
17:55:12 <peter1138> How much farther is it?
17:55:32 <peter1138> I imagine this works well when you have depots close together and would like them to be 'load-balanced.
17:55:36 <peter1138> '
17:55:51 <merni> idk how much farther, depends on where it is I guess?
17:56:11 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #8342: Feature #8095: Allow automatically separating vehicles in shared orders
17:56:29 <peter1138> Vehicles don't search that far for depots anyway, so they are going to be quite close.
17:56:47 <merni> TallTylerviaGitHub: ๐Ÿ˜ฎ
17:56:56 <peter1138> And just because there's a penalty doesn't mean it will immediately prefer a depot much further away.
17:57:55 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #9984: Add various user folders to the file browser windows
18:01:56 <talltyler> Right, and it doesnโ€™t consider vehicles that are stopped/stored in the depot, just ones trying to leave
18:05:35 <DorpsGek> [OpenTTD/grfcodec] PeterN opened pull request #29: Change: Support decoding of NewGRF with out-of-order v2 container and 32bpp-only files.
18:06:24 <peter1138> IIRC the main issue was the idea of having to count the number of vehicles inside the path finder.
18:06:30 <peter1138> Ah yes, that's still there.
18:06:55 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler closed pull request #11136: Change: Allow DEL key to close windows when focused on a textbox
18:06:58 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11136: Change: Allow DEL key to close windows when focused on a textbox
18:07:06 <talltyler> Yes, if it were cached it might be fine
18:07:13 <peter1138> `segment_cost += Yapf().PfGetSettings().rail_pbs_cross_penalty * depot->waiting_vehicles` would be somewhat nicer.
18:10:16 <peter1138> Can I change the spec that requires 8bpp normal zoom sprites?
18:10:46 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10538: Show the number of hidden vehicles on the button
18:10:58 <peter1138> Given the prevalence of dummy 8bpp sprites, I consider it harmful.
18:12:40 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10534: Change: Don't show error when rail/road construction/removal is already done
18:13:14 <talltyler> I have no issue with a spec change, but I'm maybe not the most qualified person to answer ๐Ÿ˜›
18:13:36 <talltyler> I do agree that changing spec instead of everyone not following the spec is probably better
18:14:01 <peter1138> They are "following" the spec, but in doing so it makes for a worse user experience.
18:14:03 <locosage> TallTylerviaGitHub: is it not finished? except rebase?
18:14:47 <peter1138> Did TTDPatch ever support container v2?
18:14:56 <peter1138> I'm guessing not.
18:16:39 <talltyler> locosage: Well, it does need a rebase ๐Ÿ™‚
18:18:01 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #11224: Add: [GS] Allow to set max loan for each company separately
18:20:44 <peter1138> Hmm, if I change the spec then nmlc is no longer following the spec... :o
18:21:32 <talltyler> _glx_: and andythenorth I don't truly understand the railtype compatibility problem you're trying to solve, but is there a PR for it already? ๐Ÿ™‚
18:21:32 <talltyler>
18:22:49 <peter1138> Who can remember something from 18 months ago?
18:23:52 <peter1138> FFS, just burned mouth on hot drink :(
18:26:47 <andythenorth> peter1138: this
18:27:16 <peter1138> How do I fix NML?
18:27:30 <andythenorth> talltyler: it does look like a similar issue yes
18:27:41 <andythenorth> peter1138: what's broken?
18:27:48 <peter1138> My changes to it :D
18:28:09 <peter1138> I'm adding zoom level and bit-depth to spriteset() to match alternative_sprites()
18:28:41 <peter1138> That bit works but the syntax regression test (026_asl) fails :O
18:29:48 <talltyler> I'm not trying to shame anyone for not searching PRs, just pointing out a possible starting place ๐Ÿ™‚
18:30:04 <andythenorth> this is basically the most relevant summary comment
18:32:28 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #10538: Show the number of hidden vehicles on the button
18:33:13 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11224: Add: [GS] Allow to set max loan for each company separately
18:38:01 <locosage> right, so I made gs, zipped it for github but didn't attach ๐Ÿ˜…
18:38:53 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on pull request #11224: Add: [GS] Allow to set max loan for each company separately
18:50:28 <_glx_> oh I totally forgot there was a PR
18:52:26 <_glx_> peter1138: what changes were made ?
18:53:37 <peter1138> To...?
18:53:52 <_glx_> to nml
18:54:11 <_glx_> I forgot discord replies don't work very well with irc
18:54:17 <peter1138> Oh, adding zoom_level and bit_depth to spriteset()
18:54:46 <_glx_> the error seems to imply something is not defined when it should
18:58:58 <peter1138> Yup, sorted it :D
19:06:08 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10534: Change: Don't show error when rail/road construction/removal is already done
19:12:44 <DorpsGek> [OpenTTD/nml] PeterN opened pull request #314: Change: Allow creating 32bpp-only NewGRFs
19:16:35 <DorpsGek> [OpenTTD/grfcodec] rubidium42 approved pull request #29: Change: Support decoding of NewGRF with out-of-order v2 container and 32bpp-only files.
19:17:24 <DorpsGek> [OpenTTD/grfcodec] rubidium42 approved pull request #27: Cleanup: Fix some warnings
19:18:38 *** michi_cc[d] has joined #openttd
19:18:38 <michi_cc[d]> peter1183: You might have already found it, but the container specs are <>
19:20:49 <DorpsGek> [OpenTTD/grfcodec] rubidium42 commented on pull request #28: Add: Install, Pack (windows) and Release workflow
19:21:38 <michi_cc[d]> peter1138 even. Where's the IRC edit button?
19:22:06 <peter1138> :D
19:22:09 <LordAro> bro do you even tab complete?
19:22:12 <peter1138> I didn't fine that, but thanks.
19:22:16 <peter1138> I mean, so thanks :)
19:22:23 <LordAro> or does that not work with bots?
19:23:48 <peter1138> Ah okay, so "out of order" is not actually allowed, but in this case I don't think it's actually out of order, it's just reusing the same data id from different places.
19:24:03 <peter1138> But I don't think OpenTTD enforces "in order" either.
19:25:10 <peter1138> Nope :)
19:25:39 <peter1138> I guess I should maybe attempt to add MP3 support to grfcodec too.
19:26:16 <peter1138> Although I think that's most likely going to be "if you want to shoot yourself in the foot, go ahead"
19:42:01 <DorpsGek> [OpenTTD/OpenTTD] DonaldDuck313 commented on issue #11575: [Bug]: Goods cars and trucks have very low capacity when refitted
19:52:52 <andythenorth> if FIRS changes that, newgrf vehicle set authors will bring pitchforks
19:53:13 <andythenorth> many sorts of balancing will be destroyed
19:53:52 <talltyler> Thatโ€™s not the question, is it? Seems they are proposing we change OpenTTD somehow
19:57:05 <peter1138> I'm not sure whre the 100, 200, 400 scaling comes from, though it seems a bit... a lot :)
19:57:32 <peter1138> Might be aircraft.
19:57:45 <peter1138> Might be original
20:02:31 <Eddi|zuHause> there's a weird "half" and "quarter" scaling when refitting wagons with default cargo "goods"
20:02:45 <peter1138> That's what we're talking about.
20:03:10 <Eddi|zuHause> but i think there are two refit callbacks, and one ignores this scaling?
20:03:27 <peter1138> Default engines don't have any callbacks.
20:04:58 <peter1138> Okay, default ships in the TTD are refittable, but the cargo capacity does not change.
20:06:08 <peter1138> And indeed, they don't change in OpenTTD either.
20:09:13 <peter1138> < this adds the code but doesn't add the multipliers.
20:10:45 <peter1138> < That added the multipliers.
20:12:36 <andythenorth> I don't want to find the chart
20:12:42 <Eddi|zuHause> i'm pretty sure we had this discussion over a decade ago already
20:12:42 <andythenorth> I pretend I know the chart isn't there
20:14:47 <andythenorth>
20:17:29 <peter1138> Eddi|zuHause, great they you'll remember the outcome.
20:17:46 <peter1138> *then
20:18:01 <Eddi|zuHause> i don't remember with whom... frosch? celestar?
20:19:17 <andythenorth> there's no good in it ๐Ÿ™‚
20:21:33 <DorpsGek> [OpenTTD/grfcodec] glx22 merged pull request #27: Cleanup: Fix some warnings
20:24:13 *** Xaroth92 has quit IRC ()
20:40:48 <DorpsGek> [OpenTTD/grfcodec] glx22 updated pull request #28: Add: Install, Pack (windows) and Release workflow
20:50:28 *** Xaroth92 has joined #openttd
21:31:44 <peter1138[d]> Hmm
21:32:24 <DorpsGek> [OpenTTD/grfcodec] glx22 merged pull request #29: Change: Support decoding of NewGRF with out-of-order v2 container and 32bpp-only files.
21:42:43 <peter1138[d]>
21:42:43 <peter1138[d]> locosage: robs_trains.grf in 8bpp
21:43:34 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #11428: Feature: Setting to control calendar progress speed
21:45:09 *** brickblock19280 has joined #openttd
21:45:09 <brickblock19280> that spark looks somewhat wrong
21:46:54 <peter1138[d]> Mind you there's not massive amount of shading on these sprites.
21:47:37 <peter1138[d]> Maybe I need to limit the palette range a bit more.
21:49:10 <brickblock19280> Can send you one with slightly more shading if you need it
21:50:40 <truebrain> Are we finally removing the 8bpp blitter? /me does an andy
21:51:12 <peter1138[d]> Not that I know of.
21:51:19 <peter1138[d]> It uses so much less memory ๐Ÿ˜‰
21:51:35 <truebrain> All this chat and PRs about 32bpp ... I thought, we are finally there!
21:51:53 <truebrain> Pfff, memory
21:52:06 <truebrain> We need 14.0 so we can say if anyone cares ๐Ÿ˜„
21:52:19 *** wensimehrp has joined #openttd
21:52:19 <wensimehrp> more cc?
21:52:29 <peter1138[d]> No, but I have been fixing grfcodec/nml to allow authors to make 32bpp only NewGRFs.
21:52:48 <truebrain> Like I say, remove 8bpp! ๐Ÿ˜„ just trolling
21:52:50 <peter1138[d]> grfcodec allowed it anyway, but it couldn't decode them.
21:52:55 <truebrain> Lolz
21:54:14 <truebrain> I like all the small changes you are making everywhere ๐Ÿ˜„
21:54:48 <peter1138[d]> Hmm. "0 B of 128 MiB downloaded"
21:54:49 <DorpsGek> [OpenTTD/nml] glx22 commented on pull request #314: Change: Allow creating 32bpp-only NewGRFs
21:54:52 <truebrain> Also in better news, I should have time to look into the ticker changes of talltyler next week \o/
21:55:08 <peter1138[d]> It has downloaded the file, but it's stuck, and left a .tar.gz there ๐Ÿ˜„
21:55:33 <truebrain> And if you can find out why ..... ๐Ÿ˜„
21:56:04 <peter1138[d]> I'm blaming FIRS
21:56:14 <_glx_> redownload, it should self fix
21:56:28 <truebrain> Can you reproduce, is the question
21:56:53 <_glx_> that's the main issue, I never managed to reproduce on purpose
21:57:05 <truebrain> Same
21:57:20 <talltyler> Woot!
21:57:38 <talltyler> Real-Time Mode is ready for you ๐Ÿ™‚
21:57:53 <talltyler> Actually changing the tick speed is...getting there ๐Ÿ™‚
21:58:02 <truebrain> Such progress
21:58:37 <talltyler> Having scope issues with .ini files right now, which is hard to diagnose because it builds fine for me on Windows but fails CI. I don't want to try things at random and hog all the actions runs ๐Ÿ˜›
21:59:03 <truebrain> Do it in your TZ and nobody cares ๐Ÿ˜›
21:59:34 <truebrain> But you can also make a PR in your own fork
21:59:39 <truebrain> That triggers CI too
21:59:52 <talltyler> The other night I went to bed late and Peter was still posting here ๐Ÿ˜ด
22:00:06 <truebrain> Peter is weird ๐Ÿ˜›
22:00:16 <peter1138[d]>
22:00:16 <peter1138[d]>
22:00:24 <peter1138[d]> Left: 32bpp-only houses NewGRF
22:00:50 <peter1138[d]> Right: in 8bpp mode with built-in conversion
22:01:21 <truebrain> That is a pretty nice result ๐Ÿ˜ฎ
22:01:40 <truebrain> How do you do the conversion? Closest match?
22:01:49 <peter1138[d]> Yeah
22:02:07 <truebrain> Surprised that works that well
22:02:15 <peter1138[d]> Me too ๐Ÿ™‚
22:02:26 <truebrain> How does the 32bpp look?
22:02:38 <peter1138[d]>
22:02:41 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:03:40 <truebrain> Hard to spot the difference .. the roof is different ๐Ÿ˜›
22:03:41 <_glx_> talltyler: yeah PR on your fork for this kind of tests ๐Ÿ™‚
22:04:01 <peter1138[d]> Yes, it's very close.
22:04:02 <truebrain> Just lucky with the grf having colours close the the palette?
22:04:12 <peter1138[d]> Probably yes ๐Ÿ™‚
22:04:36 <talltyler> _glx_: I just realized that the next step on my to-do list might just avoid the issue entirely ๐Ÿ˜„
22:04:58 <talltyler> We shall see
22:05:11 <_jgr_> The blue cars in the car park seem a bit odd, they seem to have been mapped to two different colours in the two cases
22:05:42 <truebrain> Nicely spotted
22:05:50 <_glx_> gives some variety ๐Ÿ™‚
22:06:21 <peter1138[d]> It's possible that it's picked up a palette colour that is used for recolouring
22:06:37 <peter1138[d]> I skipped the CC recolours, but building sprites have their own recolours.
22:07:39 <truebrain> Still surprised about the result ๐Ÿ™‚
22:08:17 <_glx_> anyway usage of 8bpp blitter might be quite rare (unless forced)
22:08:31 <truebrain> 14.0 will tell ๐Ÿ™‚
22:08:34 <_glx_> yeah
22:08:53 <peter1138[d]> Yeah, I wanted to see if this is possible. Seems it is, but would have some palette remap issues every now and then.
22:09:49 <peter1138[d]> I'm sure I've seen "bug" reports from people who've tried a NewGRF and only got white rectangles, or indeed nothing showing.
22:10:02 <peter1138[d]> "bug" in quotes because it would've been on reddit or the forums, probably.
22:10:21 <truebrain> Either removing 8bpp or having a patch like yours is important, I would say
22:10:31 <truebrain> We can slowly expect more and more 32bpp only work
22:10:59 <_glx_> I guess it won't work if dummy 8bpp sprites are present
22:11:02 <peter1138[d]> That's why I looked at grfcodec/nml. I'd rather have no 8bpp sprites, than dummy 8bpp sprites.
22:11:27 <truebrain> Yeah ๐Ÿ™‚
22:11:35 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:12:41 <peter1138[d]> Although it is possible to just force using the 32bpp instead of 8bpp dummy sprites.
22:14:57 <truebrain> How do you know if they are dummy?
22:15:26 <peter1138[d]> Quite.
22:15:47 <peter1138[d]> For this test I'm just always loading 32bpp and ignoring 8bpp.
22:16:41 <peter1138[d]> And there already exist 32bpp-only NewGRFs, so that's a useful test ๐Ÿ™‚
22:17:22 <truebrain> Did not expect that to just work, honestly .. expected some code line to do some check on a 8bpp sprite ๐Ÿ˜›
22:17:34 <truebrain> Guess v2 was implemented well ๐Ÿ˜„
22:19:28 <peter1138[d]> There is "one" issue. It's kinda slow finding the nearest colour.
22:19:39 <peter1138[d]> Although I am use a debug build which won't help.
22:20:40 <truebrain> You only have to do it once on startup ๐Ÿ˜‰
22:21:29 <peter1138[d]> No, you need to do it for every pixel.
22:21:39 <peter1138[d]> (of each sprite)
22:21:52 <peter1138[d]> But yes, once per load... of each sprite.
22:22:29 <truebrain> "Please wait while we are generating 8bpp sprites" ๐Ÿ˜„
22:22:40 <truebrain> We can make BaNaNaS do it ๐Ÿ˜›
22:22:49 <peter1138[d]> Yeah, that's a possibility.
22:22:58 <peter1138[d]> Actually make use of the v2 container features.
22:23:15 <orudge`> "Reticulating splines"
22:23:21 <_glx_> BaNaNaS modifying the grfs ?
22:23:31 <truebrain> Streaming GRFs when?
22:23:32 *** ChanServ sets mode: +o orudge`
22:23:32 <peter1138[d]> _glx_: MD5Sum will match ๐Ÿ˜„
22:23:37 *** orudge` is now known as orudge
22:23:57 <truebrain> Only download sprites in view ๐Ÿ˜›
22:24:29 <peter1138[d]> Well, that's partly how it works anyway.
22:24:46 <peter1138[d]> We don't have to convert all sprites to 8bpp on load-- they are converted as they are displayed.
22:25:01 <peter1138[d]> Wording. They are loaded first time they are displayed, and that's when they are converted.
22:25:23 <truebrain> So move that to BaNaNaS and only download it when in view .. on-demand ๐Ÿ˜„
22:25:47 <talltyler> OpenTTD, now Always Online
22:25:57 <peter1138[d]> Funny, I was able to use a std::map to remember what each RGB value maps to.
22:25:58 <talltyler> We should remove singleplayer and make it MMO-only
22:25:59 <truebrain> Subscription on top of it
22:26:08 <peter1138[d]> That is a massive memory hog but does make it faster.
22:26:25 <peter1138[d]> And of course relies on common colours and sprites having flat areas.
22:26:34 <peter1138[d]> Probably I should test a release build instead.
22:26:55 <truebrain> Just 256 lookups per pixel
22:27:30 <peter1138[d]> Less because we excluded animated and CC indexes.
22:31:16 *** wallaby2 has joined #openttd
22:31:19 <peter1138[d]> 830,442 items in my palette cache :p
22:31:33 <peter1138[d]> That's probably slower than 256 lookups per pixel.
22:32:52 *** wallabra has quit IRC (Read error: No route to host)
22:32:54 <truebrain> Lol
22:33:06 <truebrain> Log(n) of 830k I guess
22:33:25 <peter1138[d]>
22:33:25 <peter1138[d]>
22:33:33 <peter1138[d]> Oops, different zoom.
22:33:43 <peter1138[d]> But that's when you have 32bpp-only ground tiles ๐Ÿ˜„
22:34:28 <truebrain> Not perfect, but also not bad
22:34:31 <peter1138[d]> Good old Hall of Mirrors.
22:37:05 <michi_cc[d]> peter1138[d]: Probably more complicated than you'd like, but I think is the "best" 8bpp conversion tool.
22:38:00 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:40:50 <DorpsGek> [OpenTTD/nml] PeterN updated pull request #314: Change: Allow creating 32bpp-only NewGRFs
22:41:28 <peter1138[d]> Nice, but probably a bit too complex for on-the-fly conversion ๐Ÿ™‚
22:41:46 <peter1138[d]> Even a simple "alpha
22:41:50 <peter1138[d]> er
22:42:04 <peter1138[d]> Something simpler than what I've done might work.
22:42:07 <peter1138[d]> But not sure.
22:43:05 <peter1138[d]> RelWithDebInfo ๐Ÿ™‚
22:45:09 <peter1138[d]> e.g. it might be worth ignoring 2x and 4x zoomed sprites, that would could reduce the conversion time by a factor 16
22:45:31 <peter1138[d]> My phone says "It's time for bed"
22:45:38 <peter1138[d]> talltyler: is it 4am here yet?
22:46:15 <_glx_> convert 1x only and let openttd handle zooming as if only 1x 8bpp was provided ?
22:46:27 *** wallaby2 is now known as wallabra
22:46:34 <peter1138[d]> Yes, currently it just converts all that are available.
22:46:50 <_glx_> yeah skip EZ for autoconvert
22:47:35 *** pandonaut has joined #openttd
22:47:35 <pandonaut> Is it possible to download content from bananas directly?
22:47:38 <_glx_> no
22:47:48 <peter1138[d]> Thwarted by my own change -- I wanted to reload the sprite cache so I changed interface scale.
22:47:55 <pandonaut> Rip
22:47:56 <peter1138[d]> Which no longer clears the sprite cache ๐Ÿ™‚
22:48:06 <pandonaut> where does the in game pull the url from
22:48:15 <pandonaut> My in-game browser doesn't work but bananas does
22:49:11 <_glx_> are you using apple store version ?
22:51:00 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:51:27 <pandonaut> desktop but trying to play openttd at work :polite_laugh:
22:51:39 <_glx_> ah yeah firewalls
22:52:12 <talltyler> truebrain: Are you available this Saturday or Sunday for a community multiplayer game to stress-test the ship pathfinder PR?
22:52:18 <pandonaut> was able to pull some .grfs off the forums but some are only linked as in-game download
22:52:18 <talltyler> All I need to do is create the event
22:52:44 <truebrain> talltyler: Not sure. Might poke my head in
22:53:13 <talltyler> Okay, we'll do Saturday then
22:54:44 <talltyler>
22:55:07 <_glx_> don't forget to disable planes and trains ๐Ÿ˜‰
22:55:15 <talltyler> Yeah, good thinking
22:55:58 <xarick> talltyler
22:56:14 <xarick> did u add the nearest depot pr ๐Ÿ˜
22:56:26 <talltyler> Huh?
22:56:47 <_glx_> it's not 14.0 yet, just a PR build
22:58:03 <xarick> #10544
22:58:29 <talltyler> What about it?
23:00:18 <xarick> maybe he implemented already
23:05:55 <xarick> nope, he didn't
23:05:58 <xarick> ๐Ÿ˜ฆ
23:07:52 <xarick> centering view on ship depot is opening a viewport towards a power station, funny bug
23:10:47 <xarick> holy mother of river generation stalls, plz fix this bug already ๐Ÿ˜›
23:16:53 <DorpsGek> [OpenTTD/nml] PeterN updated pull request #314: Change: Allow creating 32bpp-only NewGRFs
23:17:40 <peter1138> Does the winhttp stuff use a proxy?
23:17:46 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick opened issue #11577: [Bug]: Ctrl + left click Centre view on ship depot opens a viewport centered on a power station
23:20:14 <peter1138> Works for me.
23:20:17 <_glx_> I should remove IR when doing tests, it's slow to start world generation
23:20:59 <_glx_> bug confirmed
23:23:13 <_glx_> actually happens for any depot it seems, let's check the code
23:24:16 <peter1138[d]>
23:24:21 <peter1138> o_O
23:25:53 <_glx_>
23:27:41 <DorpsGek> [OpenTTD/grfcodec] rubidium42 approved pull request #28: Add: Install, Pack (windows) and Release workflow
23:27:58 <peter1138> What about from other windows, e.g. station?
23:28:12 <peter1138> Or town.
23:28:29 <truebrain> peter1138: Winhttp follows system wide winhttp proxy settings, yes
23:29:02 <peter1138> Ok, so ensuring proxy settings are correct might help pandonaut.
23:29:35 <truebrain> No, you need to be able to create an outgoing TCP connection to 3978
23:29:37 <_glx_> from town it's the same
23:29:49 <truebrain> Otherwise you can retrieve the bananas content list
23:30:02 <truebrain> And Corp firewalls tend to block that, with good reason
23:30:10 <peter1138> Something to do with Tile to window_number strong type?
23:30:25 <peter1138> But then... would anything function at all..
23:30:36 <_glx_> and industries all point to the powerplant
23:30:48 <_glx_> but only for extra viewport
23:30:50 <_glx_> it's weird
23:31:19 <_glx_> scrollto works fine
23:31:47 <_glx_> let's test wsl
23:34:01 <_glx_> if VS/cmake decides to detect the switch
23:34:39 <_glx_> close folder/reopen solved it of course
23:34:58 *** bryjen has joined #openttd
23:36:13 <xarick>
23:36:13 <xarick> Cannot place more airports that give me a noise of 2 minimum
23:40:18 <_glx_>
23:40:22 <_glx_> oh nice
23:40:35 <_glx_> it's fine as long as I move the window
23:40:39 <peter1138> That's magic-eye mode.
23:45:07 <_glx_> but it used to work
23:48:39 <_glx_> same with all drivers, guess MS broke something
23:49:40 *** belajalilija has joined #openttd
23:49:40 <belajalilija> does the new ship ai just help with path finding or does it also make ships avoid eachoter and other stuff?
23:49:53 <talltyler> Just pathfinding
23:50:09 <_glx_> ok `wsl --update` fixed it
23:51:11 <_glx_> and extra viewports are fine in wsl
23:51:30 <_glx_> so we have a bug in windows
23:51:36 <truebrain> Or UB ๐Ÿ™‚
23:55:58 <peter1138> Did someone remove the spacebar heating code again?