IRC logs for #openttd on OFTC at 2023-12-12
โด go to previous day
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> 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:39 <peter1138> It's not even OpenTTD doing it. It's whatever platform-dependent text layouter is used.
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:40:11 <_zephyris> Ah, so, obviously you have to set the OS/2 font settings to control TTF/OTF line height
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: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
03:16:40 *** Flygon has quit IRC (Read error: Connection reset by peer)
03:26:27 *** Wormnest has quit IRC (Quit: Leaving)
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
06:28:05 *** keikoz has quit IRC (Ping timeout: 480 seconds)
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: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: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: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: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
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: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: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: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: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: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:46 <talltyler> Options menu has such a text-less button (but doesn't change colour)
13:15:00 <peter1138> Yes, I did mention the Game Options window last night ;)
13:15:08 <talltyler> I was pretty tired last night ๐
13:15:38 <Eddi|zuHause> GRF parameters should have similar buttons
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: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:24 <talltyler> Truly a PEBKAC problem
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: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> 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:37:49 <talltyler> Huh. The setting can only be changed when starting a new game...so 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: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: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: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: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: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: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: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: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
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: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: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:10 <_glx_> you will just not be able to build more noisy stuff near that town for some time
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: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:41 <peter1138> So if anyone outside the US says, it means they the customer is definitely not right.
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: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:39:55 <peter1138> andythenorth, how do I fix the NML ast in FIRS?
15:40:18 <peter1138> I think those NewGRFs are from about 15 years ago.
15:40:25 <andythenorth> that's probably "broken"
15:40:30 <talltyler> Nuance over text, etc
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: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: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:58 <andythenorth> cosmic ray hit the OPs memory chip
16:05:24 <peter1138> It was not always consistent.
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:16:27 <xarick> i'm trying to understand
16:17:08 <xarick> the AirportTileTableIterator defines the first tile differently than AirportTileIterator ?
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: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: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:04:01 <xarick> this thing doesn't play mkv files or what?
17:06:05 <merni> it's not a particularly common format these days
17:08:16 <peter1138> andythenorth, cake?
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: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:14:05 <xarick> nope, oh well, i can't get the nice video player feature in discord anymore
17:36:35 *** HerzogDeXtEr has joined #openttd
17:41:37 <peter1138> Is there a spec for the v2 container format?
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: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:51 <merni> idk how much farther, depends on where it is I guess?
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.
18:01:56 <talltyler> Right, and it doesnโt consider vehicles that are stopped/stored in the depot, just ones trying to leave
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: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:58 <peter1138> Given the prevalence of dummy 8bpp sprites, I consider it harmful.
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:16:39 <talltyler> locosage: Well, it does need a rebase ๐
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:22:49 <peter1138> Who can remember something from 18 months ago?
18:23:52 <peter1138> FFS, just burned mouth on hot drink :(
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:38:01 <locosage> right, so I made gs, zipped it for github but didn't attach ๐
18:50:28 <_glx_> oh I totally forgot there was a PR
18:52:26 <_glx_> peter1138: what changes were made ?
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
19:18:38 *** michi_cc[d] has joined #openttd
19:21:38 <michi_cc[d]> peter1138 even. Where's the IRC edit button?
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: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: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 :)
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: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:17:29 <peter1138> Eddi|zuHause, great they you'll remember the outcome.
20:18:01 <Eddi|zuHause> i don't remember with whom... frosch? celestar?
20:19:17 <andythenorth> there's no good in it ๐
20:50:28 *** Xaroth92 has joined #openttd
21:42:43 <peter1138[d]> locosage: robs_trains.grf in 8bpp
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:52:06 <truebrain> We need 14.0 so we can say if anyone cares ๐
21:52:19 *** wensimehrp has joined #openttd
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: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: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:38 <talltyler> Real-Time Mode is ready for you ๐
21:57:53 <talltyler> Actually changing the tick speed is...getting there ๐
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: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:02:07 <truebrain> Surprised that works that well
22:02:26 <truebrain> How does the 32bpp look?
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: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: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: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: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: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:33:06 <truebrain> Log(n) of 830k I guess
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:38:00 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
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:42:04 <peter1138[d]> Something simpler than what I've done might work.
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:48 <peter1138[d]> Thwarted by my own change -- I wanted to reload the sprite cache so I changed interface scale.
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: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:55:07 <_glx_> don't forget to disable planes and trains ๐
22:55:15 <talltyler> Yeah, good thinking
22:56:14 <xarick> did u add the nearest depot pr ๐
22:56:47 <_glx_> it's not 14.0 yet, just a PR build
23:00:18 <xarick> maybe he implemented already
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:17:40 <peter1138> Does the winhttp stuff use a proxy?
23:20:17 <_glx_> I should remove IR when doing tests, it's slow to start world generation
23:23:13 <_glx_> actually happens for any depot it seems, let's check the code
23:27:58 <peter1138> What about from other windows, e.g. station?
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:34:01 <_glx_> if VS/cmake decides to detect the switch
23:34:39 <_glx_> close folder/reopen solved it of course
23:36:13 <xarick> Cannot place more airports that give me a noise of 2 minimum
23:40:35 <_glx_> it's fine as long as I move the window
23:40:39 <peter1138> That's magic-eye mode.
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: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:55:58 <peter1138> Did someone remove the spacebar heating code again?
continue to next day โต