IRC logs for #openttd on OFTC at 2025-07-21
⏴ go to previous day
00:18:11 <talltyler> There are a lot of buttons that don't go beep 🙂
01:15:19 <talltyler> Holy side quest, batman
01:47:33 *** johnfranklin has joined #openttd
02:08:58 *** johnfranklin has quit IRC (Quit: Page closed)
02:12:08 <talltyler> Right, that was silly.
02:21:44 *** Wormnest has quit IRC (Quit: Leaving)
02:42:57 *** reldred has joined #openttd
02:56:06 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:25:19 <ahyangyi> Hmm, black is still not available as a company colour 😮
04:27:28 <ahyangyi> I guess we all wait for rgbcc to happen?
04:27:42 <ahyangyi> Or should I open a PR that just adds black
04:33:01 <wensimehrp> Load NewCC by default
04:34:26 <wensimehrp> 😄 NewCC is basically just a few recoloursprites, so you could add them to opengfx
04:35:30 <ahyangyi> NewCC cannot extend the list though 🤔
04:37:30 <wensimehrp> Load it as a static grf maybe
04:37:59 <ahyangyi> Company colour: 🔥 FIRE (reuses the fire palette)
04:38:29 *** agnosion has joined #openttd
04:38:29 <agnosion> discordapp.com/invite\qd542bHv all
04:38:50 <ahyangyi> Did my fire summon unholy stuff
04:39:09 <ahyangyi> Should have begun with water company colour first
04:48:00 <DorpsGek> - Update: Translations from eints (by translators)
05:25:09 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
05:30:53 *** keikoz has quit IRC (Read error: Connection reset by peer)
07:09:32 <DorpsGek> - Add: summary for week 29 of 2025 (by OpenTTD Survey)
07:42:58 *** SigHunter has joined #openttd
07:46:44 <locosage> peter1138[d]: I'll try to come up with something coherent a bit later
07:47:24 <locosage> peter1138[d]: well, they don't have any other choice...
07:55:53 <_zephyris> My toy code, if you're interested
07:56:05 <peter1138[d]> Just because there are some limits with 32bpp + 8bpp mask, doesn't mean they can only draw 8bpp because they "don't have any other choice"
07:56:46 <peter1138[d]> _zephyris: "What does it do"
07:57:34 <_zephyris> Hope/aim was to derive RGB luts from 8bpp remaps, which work nicely enough directly on RGB images
07:58:07 <locosage> peter1138[d]: I misunderstood you a bit, I though you were talking about mask, as there is no way to do recolours in 32bpp without drawing 8bpp except for some complex image processing code that does masks automatically
07:58:39 <peter1138[d]> Mainly I'm interested in the proposition that "LUTs" can allow artists to create 32bpp content without needing to faff about with 8bpp masks.
07:58:48 <_zephyris> Yup, that'e exactly what this does
07:59:40 <peter1138[d]> Yes, but what it's process?
07:59:59 <locosage> _zephyris: imo deriving luts from palette remaps is not a good way to do things, it's ok for compatibility, but there should be an ability to provide full lut somehow
08:00:04 <_zephyris> `test_lut.set_lut_from_samples` makes an RGB LUT based on a list of tuples of RGB thruples
08:01:13 <_zephyris> Take 2, let's try this better.
08:01:34 <_zephyris> It's specifically testing the actual recolouring (not anything to do with implementation)
08:02:10 <_zephyris> test_remap.set_remap_from_samples([
08:02:10 <_zephyris> (198, 80), (199, 81), (200, 82), (201, 83), (202, 84), (203, 85), (204, 86), (205, 87), # CC1 (blue) to CC2 (green)
08:02:10 <_zephyris> (80, 170), (81, 171), (82, 172), (83, 173), (84, 174), (85, 175), (86, 176), (87, 177), # CC2 (green) to purple
08:02:10 <_zephyris> #(144, 80), (145, 81), (146, 82), (147, 83), (148, 84), (149, 85), (150, 86), (151, 87), # blues to CC2 (green)
08:02:11 <_zephyris> test_lut.remap_image(Image.open("lut_test_image.png"))
08:02:55 <_zephyris> Make an instance of the class, set the RGB LUT you'd like to use by setting samples: input RGB->output RGB, then apply the remap to an image and check that it looks nice.
08:03:05 <peter1138[d]> I'm not sure where 8bpp palette indexes fit in, given the LUT proposition is for RGBA -> RGBA.
08:03:21 <peter1138[d]> (At least, I assume it is, because 8bpp is the sticking point)
08:03:33 <peter1138[d]> Why the fuck does my knee hurt this morning?
08:03:42 <peter1138[d]> (It's not the one I injured last year)
08:04:45 <_zephyris> Just translate 8bpp indexes to RGB values, and this will give you a good remap for that 8bpp remap
08:05:30 <_zephyris> (It's implemented, so if you give it a list of tuples of integers, instead of tuples of RGB thruples, it handles it like that:
08:05:30 <_zephyris> test_remap.set_remap_from_samples([
08:05:30 <_zephyris> (0x18, 0x7A), (0x19, 0x7A), (0x1A, 0x7B), (0x1B, 0x7B), (0x1C, 0x7C), (0x1D, 0x7E), (0x1E, 0x3A), (0x1F, 0x3B),
08:05:30 <_zephyris> (0x50, 0x68), (0x51, 0x69), (0x52, 0x6A), (0x53, 0x6B), (0x54, 0x6C), (0x55, 0x6D), (0x56, 0x6D), (0x57, 0x6E),
08:05:30 <_zephyris> (0x58, 0x7A), (0x59, 0x7A), (0x5A, 0x7B), (0x5B, 0x7B), (0x5C, 0x7C), (0x5D, 0x7D), (0x5E, 0x7D), (0x5F, 0x7E),
08:05:57 <_zephyris> That's an example of taking input/output 8bpp indices, and spits out a sensible RGB LUT
08:05:58 <peter1138[d]> How are we dealing with nearby colours?
08:07:09 <peter1138[d]> CC1 is certain shades of blue, CC2 is certain shades of green. With an RGBA designed for artists, presumably it is going to be a bit fuzzy.
08:07:48 <peter1138[d]> If blue is always mapped to the company colour, then an artist can't make something stay blue.
08:08:19 <_zephyris> Unless no recolour is set...
08:08:24 <_zephyris> Or the recolour is blue to blue
08:08:41 <peter1138[d]> Artists don't get to choose the recolour.
08:08:42 <_zephyris> That is precisely what I was trying to optimise/work through though
08:08:58 <peter1138[d]> When drawing a vehicle, the player's company colour selection is always applied.
08:09:35 <peter1138[d]> LordAro: I supposed that's better than not doing so 😮
08:10:35 <_zephyris> The way I implemented it here is taking RGB space and partitioning it based on the nearest RGB value which is in the OpenTTD palette.
08:11:08 <peter1138[d]> So an artist has to be very precise with which colour shades they draw?
08:12:05 <_zephyris> Yup. But, there's no fundamental reason the CC recolours couldn't use a different LUT for 8bpp and RGB
08:12:43 <_zephyris> (What you're asking is a bit of a contradiction, either you use a mask, or you have to be very precise about colour shades drawn...)
08:13:17 <_zephyris> If you don't want a solution based on just the RGB values in the image (precise shades) then of course you need more information somehow (mask)
08:13:27 <locosage> you don't have to, luts you use define how precise you need to be
08:13:29 <peter1138[d]> No, what I'm asking is how "using LUTs" is meant to fix everything.
08:14:17 <locosage> if it's a precise lut that only converts narrow color region you need to be precice, but it doesn't have to be like that
08:14:45 <_zephyris> Different solution to the problem, the hope/argument is that an artist is happier to draw precise shades than have a more technical solution.
08:17:02 <locosage> I'd say artist is happier when it can choose what works best for what they do
08:19:52 <_zephyris> A solution doesn't have to precisely copy 8bpp remaps, that was just my attempt to try to do that. Could chose to use eg. colours along magenta (where r=b, which is unlikely to be elsewhere in most sprites) to remap to CC colours.
08:20:36 <_zephyris> Arguably the only big challenge is CC. It worked well for me when I was testing using the ground tile/grass recolour:
08:20:54 <_zephyris> RGB LUT derived from 8bpp remap
08:27:09 <locosage> as one way to create luts using remaps is fine, I'm just arguing it shouldn't be the only way
08:27:26 <locosage> also, rail grass just needs a separate sprite imo
08:28:57 <peter1138[d]> What do you mean?
08:29:16 <locosage> who and where? about separate sprite?
08:29:30 <peter1138[d]> locosage: By this.
08:30:29 <peter1138[d]> God damn it. Load record, deserialise from json model. Look inside json to view the data I need. Deserialise... the json in there.
08:30:34 <peter1138[d]> Time for a redesign.
08:31:07 <locosage> peter1138[d]: what Zephyris does with palettes is just one way of creating luts, there many other ways to do so
08:32:35 <locosage> lut (a least the rgb one) is a 3d table, making it with like 1d table is a fine but limited way
08:35:49 <_zephyris> I went for that strategy because it seems tractable for a developer
08:37:03 <_zephyris> Easy to make the `((64, 0, 64), (8, 24, 88)), ...` magenta -> CC blue lookup, if that's the way you want to go
08:37:47 <_zephyris> Could just set the data of course, I was using 32x32x32 sampling of RGB, could just set those 32768 values.
08:40:54 <locosage> _zephyris: Yeah, but that't something that tooling can do. Game and newgrf spec should deal with full 3d luts imo
08:42:26 <_zephyris> Sure, that may well be better. I'm more thinking more about the usability and whether it really works rather than the implementation.
08:45:52 <locosage> _zephyris: why are you using 32 btw? it seems luts are usually `17**3` or `33**3`
08:46:16 <_zephyris> Oh yeah, probably is 33^3
08:47:50 *** wm_ has quit IRC (Ping timeout: 481 seconds)
08:49:58 <peter1138[d]> locosage: Well, let's assume we add the ability to include a LUT in a recolour map...
08:53:10 <_zephyris> Yup, I was thinking more about the practicalities, can we do an the automatic translation of 8bpp remit<->RGB LUT etc.
08:56:19 *** wm__ has quit IRC (Ping timeout: 480 seconds)
08:57:44 <peter1138[d]> Problem with having a LUT included as part of a recolour map is we're then back to having the colours to be LUTted fixed by the remap.
08:58:04 <peter1138[d]> So the artist has to draw with that again.
08:59:33 <peter1138[d]> Also, by `33**3` where's looking at a size of `33*33*33*3` bytes per LUT?
09:00:38 <peter1138[d]> And the LUT lookup has to be done pixel-by-pixel when actually drawing the sprite.
09:07:56 <_zephyris> peter1138[d]: Not quite sure what you mean, do you mean eg. the issue of forcing an artist to draw precisely the blue CC shades?
09:08:17 <peter1138[d]> Something like that.
09:09:06 <_zephyris> To me it's more a question of what the default CC LUTs look like, and whether they can be set up with a pure magenta -> CC and a pure cyan -> 2CC in addition to the CC blue -> CC and 2CC green -> 2CC
09:09:19 <peter1138[d]> Not necessary a problem, just setting limits.
09:09:42 <_zephyris> (could map both within the one default LUT)
09:09:44 <peter1138[d]> limits/expectations.
09:10:15 <peter1138[d]> Mapping both then means you have even less real colours to use.
09:11:25 <_zephyris> Reserving a narrow band of pure magenta (around r=b, g=0) and cyan (around g=b, r=0) is unlikely to be problematic, but would need feedback from artists
09:11:39 <_zephyris> Well... could just survey 32bpp sprites and see what people have used too.
09:12:37 <_zephyris> pure yellow (r=g, b=0) and pure red (g=0, b=0), green (r=0, b=0), blue (g=0, r=0) are more likely to be problematic.
09:14:13 <_zephyris> Hmm, magenta recolouring for the default bridge and structure recolours might work too
09:15:01 <_zephyris> peter1138[d]: Have a look at `remap_rgb` in my toy code, see what you think about speed.
09:15:33 <_zephyris> I guess most real-time implementations will be thinking about one LUT for eg. video, so probably just unpack the 33*33*33 into a full 256*256*256 for real time usage.
09:16:10 <peter1138[d]> I'm not concerned about performance, nothing has been written yet.
09:17:00 <_zephyris> Well, if Iron Horse comes along with 1000 RGB LUTs, probably want to think ahead about needing 1000 1Mb LUTs in memory!
09:17:06 <peter1138[d]> I think Iron Horse has something like 1000+ remaps, so 107811 bytes * 1000 is a lot 😄
09:17:15 <peter1138[d]> (But they are only palette remaps, not LUTs)
09:17:26 *** MinchinWeb has joined #openttd
09:17:45 <_zephyris> Andy's breaking things again 🙂
09:18:28 <MinchinWeb> On the station dialogues in-game, it displays a cargo number next to the station rating. That is how much of that cargo is expected to arrive at the station in the coming month, right?
09:18:47 <MinchinWeb> Can the AI get that number using AIStation.GetCargoPlanned() ?
09:21:55 <peter1138[d]> No, it's how much has been supplied.
09:22:48 <MinchinWeb> so after the station rating has been applied?
09:23:11 <MinchinWeb> I guess that's probably the number I want anyway, as that's the amount of cargo I want to take away...
09:24:24 <peter1138[d]> Is `GetCargoPlanned()` suitable?
09:27:29 <MinchinWeb> I'm trying to figure out how much cargo I expect to be supplied to the station in the coming month. (Or how much was supplied last month)
09:29:19 *** MinchinWeb[m] has joined #openttd
09:30:48 <peter1138[d]> Some of those functions seem like they might be related, but you probably know better than me 🙂
09:37:12 <MinchinWeb[m]> Yeah, I'm off the AI version of that. There's just not much commentary on how the functions work
09:37:15 *** MinchinWeb has quit IRC (Ping timeout: 480 seconds)
09:37:20 *** wm_ has quit IRC (Ping timeout: 480 seconds)
09:38:18 <MinchinWeb[m]> Maybe I'll manage to get coordinated and add some of that commentary...
09:39:37 <peter1138[d]> Experiment with them, if they're not suitable there may be another way.
09:46:23 <LordAro> also improvements to documentation are always appreciated :)
10:45:35 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
10:54:03 *** dh1 has quit IRC (Ping timeout: 480 seconds)
11:14:21 *** dh1 has quit IRC (Ping timeout: 480 seconds)
11:15:11 *** Smedles has joined #openttd
11:22:27 <peter1138[d]> ahyangyi: Is this black enough?
11:33:01 <yiffgirl> peter1138[d]: so hyped for v15
11:33:11 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:33:12 *** WormnestAndroid has joined #openttd
11:33:13 <peter1138[d]> Not sure this will make 15.0.
11:33:46 <MinchinWeb[m]> Is stainless steel an option as a "company colour"?
11:33:58 <yiffgirl> peter1138[d]: so hyped for 16.0
11:34:32 *** dh1 has quit IRC (Ping timeout: 480 seconds)
11:35:25 <peter1138[d]> Hmm, is sending sprites from client-server-client a terrible idea?
11:35:36 <peter1138[d]> I suspect the answer to that is 'yes'.
11:36:14 <yiffgirl> should i rebase the bridges pr? github says it still applies cleanly...
11:36:34 <peter1138[d]> No need if it applies cleanly.
11:37:13 <peter1138[d]> However from my last look it needs a lot of changes, and I'm not sure I can cope with listing and explaining them all.
11:37:28 <locosage> peter1138[d]: depends on the usecase, for something like custom company faces may be the only way
11:37:37 <peter1138[d]> So, uh... I may "take over"
11:37:55 <peter1138[d]> locosage: that was the use-case I was thinking of.
11:38:34 <peter1138[d]> But trolls will upload penises, breasts, and swastikas.
11:38:45 <peter1138[d]> And probably just plain porn.
11:38:59 <locosage> yeah, for public servers it's probably not a good idea
11:39:06 <brickblock19280> How's that necessary? If it's in the server grf
11:39:23 <brickblock19280> Or maybe you were thinking just a png
11:40:47 <peter1138[d]> So each player who wants a custom face has 1) create a custom NewGRF, 2) get the server maintainer to add it 3) restart the server mid-game... 😉
11:41:20 <talltyler> I still think that’s better than sending images. I don’t think we want to wade into that.
11:42:06 <locosage> Having a newgrf with a lot of pre-defined is probably a good way too but it will need players to download that grf, which is always an issue for server with no other grfs.
11:42:41 <locosage> So I'd personally like if it was just sending sprites around as I could add some moderation and server-side storage myself
11:42:57 <locosage> But how would a server owner do that without patching idk
11:44:58 <locosage> I guess openttd could add some way for admin to approve image before it's shown to everyone
11:45:19 <locosage> and save hash of that image somewhere so it doesn't have to be approved again in the next game
11:46:11 <peter1138[d]> Yeah, admin approval maybe... but all those unadminned servers 😄
11:46:46 <peter1138[d]> Anyway, the framework for faces is in place to allow add-on NewGRF faces to be created.
11:46:59 <locosage> well, it could be an option that is off by default... so at least players know that if it's enabled there is some chance admin will be looking
11:48:36 <wensimehrp> could be company logos
11:49:22 <yiffgirl> peter1138[d]: honestly that would be the ideal outcome for me, it was clearly a good few times more complex than my current skillset allows. i'm sorry to foist that work onto you, though.
11:50:29 <peter1138[d]> wensimehrp: Face selection window is now all dynamic, so it would be possible, once NewGRF faces is implemented, to have one full of company logos instead.
11:51:03 <peter1138[d]> Uh... something broke :S
11:51:17 <peter1138[d]> (Background should be the same colour)
11:51:31 <wensimehrp> oh I thought that was hair
11:53:58 <peter1138[d]> Weird having a yellow that is actually yellow.
12:08:23 *** dh1 has quit IRC (Ping timeout: 480 seconds)
12:22:23 <peter1138[d]> Hmm, wonder if hue-shifts should be a thing.
12:29:41 <andythenorth> when are player installable badges?
12:30:57 <andythenorth> new economic factor
12:31:18 <andythenorth> - countable number of player-installable badge slots per vehicle type, and per vehicle instance
12:31:33 <andythenorth> * install badges for things like 'power boost' or 'improved reliability'
12:31:42 <andythenorth> * install badges for livery and extra decor
12:32:03 <andythenorth> more badge slots in pro version of a mod
12:37:56 <peter1138[d]> How many bits are needed for contrast anyway...
12:38:43 <peter1138[d]> Oh, I only use 4 bits already. Hmm.
12:44:11 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
12:45:21 *** dh1 has quit IRC (Ping timeout: 480 seconds)
12:52:52 <peter1138[d]> Hmm, now that we have 32bpp-to-8bpp lookups, I can probably rearrange the packing anyway.
13:33:32 *** MinchinWeb has joined #openttd
13:40:34 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
13:41:47 *** MinchinWeb[m] has joined #openttd
13:45:50 *** MinchinWeb has quit IRC (Ping timeout: 480 seconds)
13:59:07 <peter1138[d]> `if (HasBit(pal, SPRITE_MODIFIER_CUSTOM_SPRITE)) pal += stage;`
13:59:17 <peter1138[d]> That might not work 😮
13:59:38 <peter1138[d]> (I'm not sure it needs to)
14:01:23 <LordAro> peter1138[d]: how did you do that? now my (other) knee is hurting as well
14:01:37 <peter1138[d]> It's the weather change.
14:01:47 *** MinchinWeb has joined #openttd
14:02:32 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
14:20:26 <kuhnovic> For some reason I'm visualizing LordAro and Peter1138 on a tandem bike falling over and both hurting there knee on the same side
14:20:45 <kuhnovic> Not sure what was in this coffee
14:20:56 *** dh1 has quit IRC (Ping timeout: 480 seconds)
14:27:18 <LordAro> don't believe i've ever actually ridden a tandem
14:38:33 *** dh1 has quit IRC (Ping timeout: 480 seconds)
14:40:32 *** kuka_lie has joined #openttd
14:49:57 *** Smedles has joined #openttd
14:54:45 *** MinchinWeb has quit IRC (Ping timeout: 480 seconds)
14:56:29 *** MinchinWeb has joined #openttd
15:06:47 *** MinchinWeb has quit IRC (Quit: Quit)
15:18:01 *** dh1 has quit IRC (Ping timeout: 480 seconds)
15:37:06 *** dh1 has quit IRC (Ping timeout: 480 seconds)
15:38:48 *** Wormnest has joined #openttd
15:57:56 *** dh1 has quit IRC (Ping timeout: 480 seconds)
16:21:12 *** akimoto has joined #openttd
16:34:36 *** Smedles has joined #openttd
16:39:11 <_glx_> yeah we never used these versions, but good to know
17:13:10 <rito12_51026> How can I expand variable size without breaking compatibility with old saves?
17:13:36 <rito12_51026> I've got this error `[2025-07-21 18:47:31] dbg: [sl:0] Game load failed...Broken savegame - Invalid chunk size iterating array - expected to be at position 409916, actually at 409917`
17:14:55 <rito12_51026> caused by changing 8 to 16 in following lines in vehicle_sl.cpp ` SLE_VAR(Vehicle, vehstatus, SLE_UINT16),`
17:15:24 <truebrain> Check out the many `SLE_CONDVAR` and the `SlVersion` or what was it called 😄
17:17:01 <truebrain> Basically, add a new version, add a `SLE_CONDVAR` from 0 till that version with `SLE_UINT8` and a new `SLE_CONDVAR` from that new Sl version till max
17:41:38 *** dh1 has quit IRC (Ping timeout: 480 seconds)
18:31:18 *** dh1 has quit IRC (Ping timeout: 480 seconds)
19:08:46 *** dh1 has quit IRC (Ping timeout: 480 seconds)
19:22:26 <peter1138[d]> The things you find.
20:01:01 *** ChanServ sets mode: +v tokai
20:02:50 *** akimoto has quit IRC (Remote host closed the connection)
20:07:55 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
21:16:07 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:45:20 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:30:42 *** xava has quit IRC (Quit: Leaving)
23:30:13 *** kuka_lie has quit IRC (Remote host closed the connection)
23:47:31 <peter1138[d]> Game Script perhaps?
continue to next day ⏵
