IRC logs for #openttd on OFTC at 2025-03-25
⏴ go to previous day
00:35:06 <peter1138> Hmm, alternatively just one list and filter it.
02:40:32 *** Wormnest has quit IRC (Quit: Leaving)
03:10:46 *** geizeskrank has quit IRC (Ping timeout: 480 seconds)
03:14:19 *** geizeskrank has joined #openttd
03:56:39 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:02:47 *** WormnestAndroid has quit IRC (Remote host closed the connection)
04:02:49 *** WormnestAndroid has joined #openttd
04:47:23 <DorpsGek> - Update: Translations from eints (by translators)
06:33:40 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:57:49 *** SigHunter has joined #openttd
08:22:55 *** ChanServ sets mode: +v tokai
08:26:44 *** mindlesstux has joined #openttd
10:42:52 <pickpacket> xarick: cutsie me! :D Discord gives me some random pic because I'm connected over the IRC bridge
10:58:03 <_glx_> It's not discord, it's the bridge itself
10:59:57 <jfkuayue> I miss the peter1139 cat
11:05:57 <truebrain> I handpick a cat for every person talking on IRC! 😛
11:06:07 <truebrain> To match their personality
11:12:06 <pickpacket> truebrain: my colleagues can't even have an opinion on whether that cat matches my personality 😂 they suck at this, apparently
11:31:00 <peter1138> Right, let's push the release back a couple of months.
11:32:27 <_zephyris> In the meantime, crazy idea, why not convert all 32bpp sprites with a recolour but without a mask to an 8bpp nearest neighbour mask/32bpp "brightness remainder" representation on load?
11:34:20 <_zephyris> Playing with generating 32bpp LUTs from 8bpp recolour sprites, my best solution was kinda equivalent to that strategy.
11:38:19 <peter1138> What problem is it solving?
11:38:56 <peter1138> Also, what is "with a recolour but wihtout a mask"?
11:43:25 <_zephyris> Ways to recolour 32bpp sprites without needing an 8bpp mask
11:45:56 *** ahyangyi_ has joined #openttd
11:46:19 <ahyangyi_> "Nickname is already in use: ahyangyi" oof
11:49:20 <peter1138> ahyangyi, yes, you are already here.
11:50:15 <peter1138> _zephyris, so what is a 32bpp with a recolour but without a mask?
11:50:46 <peter1138> Sounds like something new, so I'm unsure what it means.
11:50:57 <ahyangyi> peter1138: The colour remap maps all colours within a certain range into different colours
11:51:07 <ahyangyi> such as maps all blue into company colour
11:51:47 <_zephyris> Am I totally confused? If you want, say, a company colour recolour of a 32bpp sprite the only way to do that is by providing an 8bpp mask. Would be nice not to need that, just provide a 32bpp sprite.
11:52:09 <_glx_> Mask is expected, it's in the spec
11:52:34 <ahyangyi> I think Zephyris is proposing a new remap format
11:52:39 <peter1138> If you have a 32bpp-only sprite, what is defining the recolour?
11:53:06 <ahyangyi> _zephyris: ^ See here
11:53:20 <peter1138> Who is providing the LUT?
11:53:49 <_zephyris> Well, that's what I'm wondering. I can see two strategies.
11:54:03 <_zephyris> 1. Translate the 8bpp recolour sprite to a 32bpp LUT, and use that.
11:54:28 <peter1138> Are we talking, e.g. 256 fixed LUTs, equivalent to the company colour recolour remaps?
11:54:28 <_zephyris> 2. Generate an 8bpp mask from a 32bpp sprite, and use the generated 8bpp mask for recolouring using the current 32bpp recolour scheme.
11:55:01 <_zephyris> Yup. Probably generated from the 8bpp recolour sprites, rather than needing separate hard-coding.
11:55:24 <peter1138> ahyangyi, I know what a recolour is, and I know what a LUT is. I'm specifically trying to get precise details of what is meant, because "just use a LUT" is not a spec.
11:55:53 <ahyangyi> peter1138: And I was mostly trying to link to previous messages, which contains concrete examples and discussions.
11:56:01 <ahyangyi> Just need to name "a LUT" before that
11:56:06 <peter1138> Okay, so with a fixed LUT, instead of having to use specific 8bpp palette, you now have to use specific 32bpp colours (with a specific hue, presumably)?
11:57:19 <peter1138> (So authors who accidentally use those colours will get their 32bpp sprite recoloured, even if they don't want it?)
11:58:18 <_zephyris> Yup, it's completely analagous to 8bpp recolour.
11:58:55 <_zephyris> So, if a 32bpp set is using colours very close to company colour blue on a vehicle sprite then they would get recoloured by this scheme
11:59:07 <peter1138> Not completely, 8bpp remaps work by palette index, so colour matching isn't a problem.
11:59:30 <_zephyris> Well, all the colours are unique...
12:00:50 <peter1138> Currently you can use any shade in the 32bpp part (including CC blue) and it won't be remapped.
12:01:01 <peter1138> With your LUT, that is not possible.
12:01:27 <peter1138> I'm not saying this is a problem, I'm just saying that is isn't quite the same.
12:01:45 <peter1138> Currently you can draw a 32bpp sprite and not have to be careful about colours.
12:01:52 <peter1138> With a fixed LUT, you need to be.
12:02:49 <_zephyris> It's different, it's more like the 8bpp situation where you have to pick with care.
12:03:37 <_zephyris> But, the 32bpp recolours would subsequently 'just work'
12:04:16 <_zephyris> Fixes various things...
12:04:50 <peter1138> We also still need to do the 8bpp palette remap. So there'd be two ways to do recolouring.
12:05:57 <_zephyris> Not necessarily, applying the 32bpp LUT to the 32bpp interpretation of 8bpp sprites would give an identical result to the exiting 8bpp recolour
12:06:31 <_zephyris> Doesn't handle animated pixel values of/c
12:06:51 <peter1138> Precisely because of 1) animated pixels 2) remaps match index, not actual colour.
12:10:06 <peter1138> I'm not deliberately being awkward. A concrete spec proposal needs to be explicit.
12:10:54 <_zephyris> Yup, and I'm still exploring ideas...
12:11:41 <_zephyris> _zephyris: Which is why ^this question/idea
12:11:58 <peter1138> That doesn't work in IRC.
12:13:01 <_zephyris> So, the 'best' way to do 32bpp recolours is probably to take the 32bpp image, do a 8bpp nearest neighbour conversion and retain the areas that you want to be recoloured. Then leave the brightness remainder in 32pp.
12:13:41 <_zephyris> So the recolour gets nice hue shifts, but smoother.
12:14:00 <peter1138> Shading like that doesn't work.
12:14:06 <_zephyris> Not perfect, but quite god.
12:14:19 <peter1138> It relies on all the recolours having the same brightness ranges, which is not the case.
12:15:03 <_zephyris> Yup, but closest approximation which is possible right now.
12:15:05 <peter1138> And requiring 8bpp nearest lookup for a 32bpp-only sprite with LUTs seems backwards.
12:15:19 <_zephyris> Nope, alternate idea.
12:15:50 <_zephyris> Two options, 1. 32bpp LUTs, 2. generate these remainder images.
12:16:16 <_zephyris> I'm testing at 3x2^5 RGB values
12:17:04 <_zephyris> Err, no, what do I mean.
12:22:02 <peter1138> The nearest colour lookup uses (2^6)^3, but that's only 1 byte each because palette index.
12:22:33 <peter1138> 256KiB just for that lookup, Whoops :P
12:23:08 <_zephyris> Heh, yeah, cubic scaling's a bugger
12:23:32 <peter1138> Then there's bridge and house remaps.
12:23:53 <peter1138> Those use different palette indices again.
12:24:02 <_zephyris> Yup. But generate the 32bpp LUT from the existing 8bit remap sprite.
12:24:32 <_zephyris> Could be on load or pre-calculated.
12:25:34 <_zephyris> Grass -> bare earth for infrastructure sprites, generated from the existing 8bpp recolor
12:25:58 <_zephyris> (Not perfect, the recolour has some palette index 'holes', but easy tweak)
12:26:49 <xarick> Singe Rail vs Double Rail, who ends up doing more trains?
12:27:01 <peter1138> How do we know if the recolour is going to be applied to an 8bpp or a 32bpp sprite?
12:27:13 <peter1138> (At the point of loading a recolour we don't know)
12:27:51 <peter1138> Some NewGRFs use thousands of recolours, automatically calculating a LUT for those when it's never going to be used is a bit pointless.
12:29:56 <xarick> by faster I mean, puts out more train routes
12:30:46 <peter1138> Hmm, 256KiB of remaps becomes 10.8MiB of remaps + LUTs.
12:30:56 <peter1138> I guess, overall, that's nothing.
12:31:06 <_zephyris> Yeah, seams reasonable.
12:31:31 <_zephyris> I'm testing with various sizes of LUT, wondering if (2^4+1)^3 is enough.
12:31:35 <peter1138> Palette animation though.
12:32:33 <_zephyris> Could do multiple frames of LUT
12:35:43 <peter1138> IMHO you do it with an 8bpp part.
12:39:37 <_zephyris> But, I realise still questions about coexisting with existing mask recolours
12:40:23 <_zephyris> A scheme could be: 32bpp sprite pixels with index 0 mask get recoloured using LUT, those with non-zero mask get recoloured using mask (and this handles animated indices)
12:40:50 <_zephyris> But, does risk breaking some blue vehicles which aren't intended to be recoloured
12:41:24 <_zephyris> maybe it's a good idea, maybe not.
12:43:11 <_zephyris> Maybe 32bpp sprites get a flag which is 'allow 32bpp LUT recolour'.
12:43:32 <_zephyris> Lots of maybes, still working out if LUTs are good enough,
12:44:03 *** peter1138[d] has quit IRC (Quit: User went offline on Discord a while ago)
12:53:38 <peter1138> Hmm, how did you calculate the LUT?
12:53:46 <ahyangyi> At least 32bpp-LUT nightgfx2 sounds more plausible than tinkering with alpha-blending
12:56:35 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:56:39 *** WormnestAndroid has joined #openttd
12:58:33 <_zephyris> peter1138: Imagine r, g, b space as a cube. The 8bpp recolour sprite is a list of original values for that colour space (eg. index 1 is r, g, b 16, 16, 16) and the target value (whatever the r, g, b of the target index is).
12:59:32 <_zephyris> So, you want to do a linear interpolation of the target value for each sample in the 3D space.
13:00:16 <_zephyris> Actual implementation is like a delaunay triangulation and interpolation between the 3 vertices, but in 3D, so simplex tesselation and interpolation between the 4 vertices.
13:01:19 <_zephyris> Currently, throw it at scipy.interpolate.griddata - but that's the underlying algorithm.
13:02:38 <_zephyris> (oh, and I'm actually doing sampling in YUV rather than RGB, but that's just a pre-conversion step)
13:04:23 <peter1138> I was hoping for an algorithm that takes into account the existing palette index remap :P
13:11:25 <peter1138> I'm a software developer, I think in lines of code, not 3D cubes.
13:14:50 <_zephyris> peter1138: Completely derived from the existing remap
13:15:28 <peter1138> The existing remap does not colour all of the colour space, onlty 266 entries.
13:15:41 <_zephyris> def remap_to_lut_simple(self):
13:15:41 <_zephyris> Convert palette index remap to r, g, b lut
13:15:41 <_zephyris> Simple linear interpolation
13:15:42 <_zephyris> for i in range(self.entries):
13:15:44 <_zephyris> if i in self.animated or i in self.special:
13:15:46 <_zephyris> samples.append(((self.palette["r"][i], self.palette["g"][i], self.palette["b"][i]), (self.palette["r"][self.remap[i]], self.palette["g"][self.remap[i]], self.palette["b"][self.remap[i]])))
13:15:48 <_zephyris> output_lut.set_lut_from_samples(samples, "linear")
13:15:50 <_zephyris> And the magic happens in `set_lut_from_samples`
13:58:20 <_zephyris> Resounding silence... Have the whole script 😉
13:59:59 <peter1138> Well, "here's a magic function" wasn't very useful.
14:00:33 <peter1138> But yes, looking at all that, I was right to not do any guessing.
14:01:58 <_zephyris> I reread your comment and realised what you wanted
14:07:56 <peter1138> More of a "what's involved", but as you had already written it for testing, yeah...
14:54:40 <xarick> make aqueducts cheap please
14:59:35 <xarick> hmm what are they doing?
15:02:05 <LordAro> doesn't really matter
15:02:14 <LordAro> they are not codestyle changes
15:05:16 <LordAro> "and anywhere else they appear"
15:05:29 <LordAro> come on, i'm trying to make it as obvious as possible
15:06:04 <xarick> okay, but line 232 had already std::min<int>
15:10:06 <xarick> I don't quite understand
15:10:14 <xarick> but hey... don't hurt me
15:14:13 <peter1138> If you don't know what you are doing, don't do it.
15:21:09 <peter1138> SLE_CONDVAR(CompanyEconomyEntry, delivered_cargo[NUM_CARGO - 1], SLE_INT32, SL_MIN_VERSION, SLV_170),
15:21:22 <peter1138> Hmm, what happens to that value, once it's put into the last delivered_cargo slot...
15:23:59 <xarick> didn't think anything wrong would happen
15:25:02 <LordAro> maybe not, it's still not a codestyle change
15:56:40 *** Wormnest has joined #openttd
15:57:25 <peter1138> Hmm, I think it's put into the last slot just to be hidden out of the way.
16:00:42 *** D-HUND is now known as debdog
16:16:25 <Rubidium> 20:52 <@Rubidium> I put it in the least likely used cargo slot ;)
16:16:25 <Rubidium> 20:53 <@Rubidium> so when, later, stats are shown of transported cargo per type you'd most likely not see the old stuff peaking for one cargo
16:18:34 <peter1138> I know that was at 20:52, but what day... month... year...
16:21:23 <Rubidium> the day of introduction of SLV_170 / r23826 (2012-01-20)
16:24:13 <peter1138> :o Some proper digging then :)
16:30:48 <LordAro> you can tell it's old because of the '@' :)
17:12:59 *** tabytac has joined #openttd
17:20:46 <zanooda2000> Is it any chance that thing will be reverted? It will break a lot of old openttdcoop saves. Articulated thing was used *as a feature* to make the game... more fun – to allow more junction-weaving possibilities.
17:20:46 <zanooda2000> Already made junctions will no longer work as intended.
17:22:13 <LordAro> certainly won't by reporting it here
17:22:35 <LordAro> but honestly, probably not
17:42:08 <andythenorth> LordAro: original PR anticipates spacebars
17:42:39 <LordAro> anticipating spacebars doesn't necessarily mean the spacebars should not be kept
17:42:54 <LordAro> wait, is that a triple negative?
17:44:09 <peter1138> Oh, what's that, curve speed.
17:44:14 <peter1138> There's a NewGRF property for that.
17:44:45 <peter1138> Vehicle property and railtype property.
17:45:36 <andythenorth> I'm puzzled what's exploitable
17:45:48 <LordAro> strange logic stuffs i think
17:45:59 <LordAro> it's all very timing dependent
17:46:13 <peter1138> Who said exploitable?
17:46:44 <peter1138> Your parcel from St Johns Street cycles is on its way.
17:47:07 <andythenorth> mine from Evri is stuck in a depot
17:47:11 <peter1138> That confused me briefly because I used to live on a St Johns Street... "Did I forget to update the address!?"
17:47:22 <andythenorth> I need to reply to ghio7579i@hotmail.com about it
17:47:28 <andythenorth> definitely works at Evri
17:48:01 <andythenorth> I just need to give them my card details I think
17:48:25 <peter1138> D.O.B. and NI number.
17:48:38 <peter1138> Might as well hand over your National Record of Achievement.
17:50:18 <xplusc> LordAro: I believe NUTS uses that quirk to make a fast train that turns tightly at full speed, not a logic thing. If the newGRF setting that was spoken about earlier just lets an engine type turn more tightly at full speed than it normally would, then that’s fine and just a matter of updating NUTS.
17:55:40 *** benjamincurry0972 has joined #openttd
17:55:40 <benjamincurry0972> I’ll teach 10 people to earn $30k or more within 72 hours but you will pay me 10% of your profit when you receive it. Note only interested people should apply, drop a message let's get started by asking (HOW)
17:55:40 <benjamincurry0972> @Official_Benjamincurry00
18:26:41 <zanooda2000> xplusc: This is probably not a setting, but some other feature built into newgrf itself. At least in NUTS newgrf settings I cannot find anything connected to curve length.
18:26:41 <zanooda2000> The question is rather whether it can be considered a bug in principle. Not indended feature maybe, but still, it find it's usage in some niche things.
18:28:39 <zanooda2000> Just from my experience, the first thing that came to mind was broken saves with NUTS. And also it can be connected to j"very long xussr wagons", they also have this "not a feature but a bug" that allows you to make more intricate turns in "realistic-like" games, instead of simple and boring 8-way movement.
18:34:29 <xplusc> My guess is that the new update changed some of the math that NUTS was doing to make some engines have a particular curve speed. So then it’s just a matter of updating NUTS along with the update. You seem to be familiar with the NUTS source and could tell me if it’s really using this feature.
18:39:05 <zanooda2000> xplusc: I don't really know about the source code, I can only *assume* how it should, how it works, or how it doesn't work in the game. Or detect changes between versions.
18:39:05 <zanooda2000> The only thing I remember is that this feature was used to work around some other newly introduced bug.
18:39:05 <zanooda2000> Anyway the fix will probably be pretty simple, but _someone has to do it_. Still, idk what to do about any other articulated-feature newgrfs.
18:42:09 *** tokai|noir has joined #openttd
18:42:09 *** ChanServ sets mode: +v tokai|noir
18:45:17 *** WormnestAndroid has quit IRC (Remote host closed the connection)
18:47:21 *** WormnestAndroid has joined #openttd
18:49:09 *** tokai has quit IRC (Ping timeout: 480 seconds)
18:59:12 <xarick> for OpenTTD 15 I need: #13476, #12249 and #10544
18:59:28 <xarick> ehm... asking too much I guess
19:00:48 <xarick> they're not going into beta2?
19:16:51 <Rubidium> xarick: I'm only doing things that are fun to me, looking at those PRs isn't for me
19:19:24 *** akimoto has joined #openttd
19:48:12 <xarick> hold ctrl-shift to overlay cargo type
19:48:24 <xarick> what do those icons look like?
19:49:25 <exceptik> xarick: Das corn, innit
19:50:08 <exceptik> (yeah in a passenger car, who cares 😆 )
19:51:10 <xarick> AAAHogEx concept of train engine is ...
19:51:46 <xarick> somehow it got worse in version 99
20:02:15 <frosch123> Rubidium: sorry, I won't get to #13872 before Friday
20:08:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:25:29 <xarick> probably AI music with AI video
20:32:18 <_glx_> peter1138: you're planning to do `ai_config` array too?
20:32:35 <_glx_> asking before really touching the area 🙂
20:35:07 <peter1138> _glx_, already have a patch for it, my comments about =
20:35:18 <peter1138> `= {}` and unique_ptr were related to it :)
20:36:09 <peter1138> Technically it's a copy, even if it's not really :S
20:40:23 <peter1138> Having ai_config and game_config in GameSettings like this is a bit weird though.
20:42:47 <peter1138> std::shared_ptr works of course, but that's kinda a bodge too.
20:47:40 <_glx_> slot config (non running) vs running config
20:54:43 <_glx_> oh actually for game script it's using slot config as running config
20:55:04 <_glx_> while for AIs it's copied to the company
20:55:59 <peter1138> Think I've found a solution, using unique_ptr :)
21:00:54 <peter1138> Hmm, actually, this initialisation looks like a copy...
21:03:11 <xarick> can you fix something in the scenario editor. Don't start the GS when loading a scenario in the scenario editor
21:05:49 <peter1138> Although creating a copy-constructor and having to make sure all the other members are properly copied... is a bit of a pain :(
21:08:24 <peter1138> Hmm, sub-object maybe.
21:13:59 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:14:33 *** WormnestAndroid has joined #openttd
21:23:20 <_glx_> xarick: GS doesn't run in scenario editor
21:26:59 <xarick> oh, looks like an easy fix apparently
21:28:14 <peter1138> 13 files changed, 38 insertions(+), 49 deletions(-)
21:28:27 <peter1138> 15 files changed, 99 insertions(+), 81 deletions(-)
21:38:50 <xarick> probably fixes #10108 and #12759
21:48:10 <locosage> _zephyris: That's how it works in cmclient
21:49:47 <_zephyris> Interesting. I'll take a look
21:51:37 <xarick> oops commit message mistake
22:26:32 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:32:19 *** WormnestAndroid has quit IRC (Remote host closed the connection)
22:32:24 *** WormnestAndroid has joined #openttd
23:20:03 *** Flygon has quit IRC (Read error: Connection reset by peer)
23:23:18 <xarick> why is the config->info nullptr
23:31:39 <xarick> but still... very strange
23:37:17 <xarick> well, it's definitely a me problem
23:38:14 <xarick> converted to draft, will fix tomorrow t.t
23:39:17 <xarick> something in game_sl not working as I expected
23:42:23 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:47:47 <xarick> I failed at copy pasting
23:55:53 <xarick> > No common parent found for this merge commit (max-depth of 256 reached)
23:56:52 <xarick> dang it, i wanted to go to bed...
continue to next day ⏵
