IRC logs for #openttd on OFTC at 2026-10-14
⏴ go to previous day
00:55:27 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:55:39 *** WormnestAndroid has joined #openttd
01:58:29 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
02:00:33 *** MinchinWeb[m] has joined #openttd
02:36:09 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
02:37:34 *** MinchinWeb[m] has joined #openttd
02:43:02 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
02:44:27 *** MinchinWeb[m] has joined #openttd
03:05:28 *** Philemon has joined #openttd
03:09:02 *** Phileman has quit IRC (Ping timeout: 480 seconds)
04:03:08 *** wallabra has quit IRC (Ping timeout: 480 seconds)
04:03:08 *** Phileman has joined #openttd
04:06:32 *** Philemon has quit IRC (Ping timeout: 480 seconds)
04:36:10 *** wallabra has joined #openttd
05:03:48 *** ChanServ sets mode: +v tokai
05:08:55 *** Flygon has quit IRC (Read error: Connection reset by peer)
05:10:28 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
06:41:51 <_zephyris> Back to recolours, I've got a few fun (python) prototypes
06:44:09 <_zephyris> Define a few remaps, could be 8bpp index to index or RGB to RGB, then construct a full RGB LUT from that
06:45:05 <_zephyris> You have to be careful with file size/memory use, but live interpolation of a 6 bit per channel LUT should work
07:21:02 <peter1138> You're talking about something else again :)
07:26:12 <_zephyris> I do tend to do that, it's called half-reading the conversation history!
07:45:52 <peter1138> gcc's -fsanitize=address seems to get pretty confused by std::variant and sometimes std::optional.
08:27:13 <LordAro> peter1138: odd, not been my experience
08:32:49 <peter1138> `FileHandle` and `StringParameter` are quite noisy in suspected use of uninitialized data.
08:33:52 <peter1138> As is `PoolID::value`.
09:17:48 <emperorjake> Don't look at the subreddit right now if you don't want to see janky vibe-coded patches 😅
09:20:16 <peter1138> It's in the forum too.
09:21:45 <will_marshall_> the 3d view guy should have just infringed all the copyright on the playstation version i hear that's the style these days
09:22:44 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
09:23:21 *** MinchinWeb[m] has joined #openttd
09:24:00 <peter1138> I've approved the post now, against my moral judgemenet :p
09:45:43 *** WormnestAndroid has quit IRC (Remote host closed the connection)
09:45:59 *** WormnestAndroid has joined #openttd
10:12:22 *** WormnestAndroid has quit IRC (Remote host closed the connection)
10:12:35 *** WormnestAndroid has joined #openttd
10:38:02 <will_marshall_> the vibe is like you're unclipping the velvet rope and standing aside to allow a bunch of doc-marten wearers to approach and kick the crap out of a guy
10:51:14 *** nanapipirara has joined #openttd
11:14:07 *** nanapipirara has quit IRC (Remote host closed the connection)
11:23:35 <peter1138> Heh, just seen the slopped smooth curve one.
11:37:26 <andythenorth> such times we live in
11:45:26 <will_marshall_> I think the curve one is the really egregious one. Especially given they're saying "1x3 curves" which... 'aint no curve I've ever seen.
11:46:07 <andythenorth> "here comes everybody"
11:46:08 <Izzybee> it's kind of ... inane, too? what does that add to the game? it looks like it just makes it harder to understand what you're looking at. the first person one is kind of cute but it would also significantly increase the system requirements of the game, I suspect
11:46:34 <will_marshall_> Izzybee: that's how i felt. openttd with curves is just... not openttd
11:47:03 <Izzybee> not slopping the game is literally free. you can just not slop software. I recommend it. bluh.
11:47:58 <will_marshall_> very poor internal definition of progress these people have. more isn't always more
11:48:21 <audigex> I don’t mind people vibecoding crazy modified versions, as long as they don’t spam the community with it and don’t try to get it included in OpenTTD
11:48:42 <will_marshall_> they have to spam the community to get handshakes from people they never met!
11:48:44 <andythenorth> it's why the only workable policy is "no AI contribs"
11:48:55 <Ingo> Hallo, ich hoffe auf Deutsch ist eine Comunikation möglich
11:48:59 <andythenorth> even though "no AI" cuts off a whole set of tools
11:49:02 <andythenorth> but it's the only way
11:49:54 <Izzybee> they could run the game on weird systems instead and get middling responses from a subset of cute internet people in their powermac
11:50:49 <andythenorth> this week my YouTube is full of this "I one-shotted Photoshop with Claude" bullshit
11:52:42 <Ingo> Hello. I had this text translated using Google. Is there a version of the game where you can build bridges and stations diagonally? Regards, Ingo
11:54:58 <Ingo> Hello. I had this text translated using Google. Bridges would be great if they existed. Regards, Ingo
11:55:03 <audigex> andythenorth: The open source one by ArtCraft is actually surprisingly good
11:55:03 <audigex> Not perfect obviously, but for how early they are in the process it’s shockingly good
11:55:54 <audigex> Ingo: It’s a requested feature and might happen eventually. I don’t think it’s planned for any update soon though. Maybe one day
11:56:13 <Ingo> Hello. I had this text translated using Google. Signals on bridges and in tunnels would be great. Regards, Ingo
11:56:24 <mmtunligit> Ingo: JGRPP has this
11:56:28 <andythenorth> audigex: full disclosure: I haven't tried it, I am relying on secondhand information
11:57:02 <Ingo> Hello. I had this text translated using Google. What is JGRPP? Regards, Ingo
11:57:06 <audigex> I gave it a go, it’s genuinely far closer to photoshop than you expect
11:58:48 <mmtunligit> You can load saves from the base game in JGRPP but not the other way around
11:58:51 <Ingo> Hello. I had this text translated using Google. Okay, thanks. I'll take a look. Regards, Ingo
12:03:22 <andythenorth> hmm "free yourself from Adobe with Open Source replacement by Claude"
12:03:26 <andythenorth> going well so far
12:03:29 <Ingo> Hello. I had this text translated using Google. Thanks for that; have a nice day. Regards, Ingo
12:04:01 <andythenorth> mandatory accounts with your OSS?
12:04:29 *** Ingo has quit IRC (Quit: Page closed)
12:05:03 *** Smedles has quit IRC (synthon.oftc.net singleton.oftc.net)
12:05:03 *** Izzybee has quit IRC (synthon.oftc.net singleton.oftc.net)
12:06:24 *** Smedles has joined #openttd
12:06:24 *** Izzybee has joined #openttd
12:23:12 <reldred> andythenorth: I tried the Lightroom clone for laffs. Can’t even read raw files despite their being multiple very very good open source raw processing libraries out there, and you know, the entire point of Lightroom being for processing raws…
12:23:45 <andythenorth> it's not that I don't believe a one-shot Claude prompt can clone stuff 😛
12:23:57 <andythenorth> it's just that I suspect it's a grift
12:24:37 <reldred> And the whole UI was just janky and weird. Like clear it was copied by someone/something that didn’t understand what the original was actually doing.
12:25:14 <reldred> It has done nothing but reinforce the beliefs I already hold about ai peddlers.
12:31:22 <andythenorth> I don't get so wildly cross about Adobe
12:32:03 <andythenorth> £18 / month for Creative Suite, is 60p a day
12:32:35 <andythenorth> I use photoshop for hours at a time, it's like 10p an hour or something
12:32:55 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
12:33:07 <andythenorth> they do install some crappy license manager package, and 5GB of "value adding" media files I don't need
12:34:02 *** MinchinWeb[m] has joined #openttd
12:37:01 <talltyler> I have Photoshop CS5.1 from a million years ago, it still works 🙂
12:40:23 <kuhnovic> Which you totally paid for
12:44:42 <talltyler> I did! Student price, but...
12:46:38 <kuhnovic> Hey that still counts. Well, back then it did, when buying meant you actually bought it...
12:57:27 <peter1138> Of course it's not much, it's biased by the platform, but it's the most liked post, way above any release post.
13:45:06 <kuhnovic> _zephyris: I was thinking, maybe we have better control over the downsampling (is that the correct term?) when using full sea sprites instead of overlays. It might be nice to make the shimmer pixels disappear when zooming out, but openttd has some special selection rules when transparent pixels are involved.
13:49:24 <peter1138> Yeah, pixels take precedence over transparency.
13:55:40 <_zephyris> Current ogfx2 has that optimisation, so you don't get the strobe effect when you zoom out, and any new overlays I'd draw with the same thing in mind.
13:56:33 <_zephyris> Can always provide zoom out-specific sprite too
14:03:36 <kuhnovic> Overlay vs replacement, either way works for me. This graphics stuff is still a bit new to me so I'm probably the wrong person to make the call haha.
14:04:39 <peter1138> Full-sprites would get around the pixel/transparency priority thing.
14:05:00 <peter1138> As would including more non-shimmering pixels in the overlay.
14:05:37 <peter1138> Generic tile variations... Hmm.
14:07:29 <peter1138> std::set<SpriteID, std::pair<SpriteID, uint>> -- any DrawSprite finds an overlay variations and draws that? Feature agnostic, probably bad for performance but might not be.
14:07:48 <peter1138> Needs a new NewGRF action.
14:08:54 <peter1138> Would be useful to work with both plain sprites (again a specific sprite id) and action 1 sprites (everything dynamic)
14:12:35 <kuhnovic> Hehe, Cunningham's law at work again 😄
14:13:20 <peter1138> Is that tile hash algorithm used anywhere else?
14:13:33 <peter1138> There's a couple of weird ones already which are, uhm, kinda bad.
14:14:41 <kuhnovic> Nope, found this on SO of all places. The guy really did his homework.
14:15:42 <kuhnovic> I tried using the existing TileHash or whatever it was called but it was absolutely awful for this purpose. It might be fine for the other cases where it's used though. Hashes tend to be funny that way.
14:17:03 <peter1138> It's generally crap, yes. I'd keep it for house variations. Other things are not quite so precious.
14:17:24 <peter1138> I need something for treeeeeees and currently use a combination, so this might be useful.
14:17:33 <peter1138> Rail/road tiles use a crappy hash too.
14:17:50 <peter1138> (Only for NewGRF types)
14:18:31 <peter1138> Basically what I'm saying is such a hash should be a separate function to be reused, with perhaps a execution cost comparison.
14:20:18 <kuhnovic> Yeah it would make sense to put it in a general place so we can reuse it
14:21:58 <kuhnovic> I also tried the hashing function from our hashmap. That one was really bad for this purpose. I would be a bit hesitant to change that one though, we'd have to do some thorough YAPF benchmarking first.
14:25:58 *** nanapipirara has joined #openttd
14:26:36 <peter1138> I was mainly thinking of purely visual stuff.
14:34:48 *** nanapipirara has quit IRC (Remote host closed the connection)
14:36:27 <tony_pixel> _glx_: I think partials are the only relevant point where relative paths make sense, graphics normally lie in different folder tree entirely; probably a good idea to introduce additional parameter for `find_file` in the same PR, as include-s code is the only user of it currently
14:36:49 <tony_pixel> After #450 gets merged
14:55:42 <_zephyris> There's an argument for different pseudorandom hashes for different features, otherwise you'd get co-occurrence... OTOH, one better hash is possibly better.
15:05:08 <_jgr_> _zephyris: You don't need different hash functions for this, just a different salt value or other parameter
15:10:18 <_jgr_> As for YAPF performance, you can get an improvement with a better hash table (e.g. one which isn't a fixed size with linked list buckets), though it's been a long time since I looked at that and I don't have numbers to hand. I doubt the exact hash function with the existing implementation would make a big difference so long as it isn't crap.
15:58:02 <audigex> andythenorth: It’s fine for professional work, for hobby stuff it’s more than I can sensibly justify for the amount of use when GIMP is free
16:11:28 <andythenorth> Now you can one-shot Claude GIMP 🙂
16:24:33 <_zephyris> Krita for pixel art?
16:24:49 <_zephyris> It's my go-to for digital drawing/painting...
16:29:50 <tony_pixel> _glx_: sorry for the pings; wanted to do the PR for `new_include` to add default values, but it's probably easier if you just commit on-top
16:30:31 <tony_pixel> I renamed `dict -> symbols` to avoid ambiguities
16:31:13 <tony_pixel> both `{NO_DEFAULT:}` and `{NO_DEFAULT}` should work and yield empty string on replacement
16:32:21 <tony_pixel> or should I extend a bit to allow for `}` to be present inside default value?
16:59:39 <_glx_> I think in typical use case default value won't contain `}`
17:04:27 <tony_pixel> yeah, if it can contain `}`, it should be the last thing and so outside the `{template}`
17:38:56 *** gelignite has joined #openttd
17:39:04 <peter1138> Such undefined behaviour :o
17:50:20 <tony_pixel> removed variable introduction entirely, now avoids reformating extra lines
17:50:36 <tony_pixel> would be grateful if someone can review #450, it's tiny
18:37:22 *** Flygon has quit IRC (Read error: Connection reset by peer)
19:00:26 *** nanapipirara has joined #openttd
19:01:23 <tony_pixel> I tried out new include path and for some reason it doesn't work, I can't quite understand why
19:07:40 *** nanapipirara has quit IRC (Remote host closed the connection)
19:09:24 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
19:09:58 *** MinchinWeb[m] has joined #openttd
19:22:40 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:22:51 *** WormnestAndroid has joined #openttd
19:45:36 <tony_pixel> tony_pixel: _glx_ why additional state though?
19:46:34 <tony_pixel> currently I try to parse
19:46:34 <tony_pixel> include("header.pnml");
19:46:34 <tony_pixel> ```, and when I do so, it tries to continue parsing from where it left off, namely column 7, and not from the start of the file
19:49:02 <tony_pixel> I mean it substitutes the contents of `header.pnml`, but then it somehow starts not from file start
19:51:32 <tony_pixel> you change lexpos and then `lex.py` changes it back
19:54:26 <tony_pixel> we should calculate some `tok = self.lexer.token()`, *then* restore lexmatch and return `tok`
19:55:07 <tony_pixel> that way it just silently substitutes the files and continues lexing
19:55:31 <tony_pixel> I think this can be done easier with `lexer.clone()`
19:58:42 <peter1138> Hmm, I assume if I somehow had both simplified chinese and traditional chinese at the same time... the fonts are going to be very confused :o
20:01:51 <tony_pixel> yes, everything works now
20:02:12 <tony_pixel> Still unsure why an additional state
20:16:22 <peter1138> When you use the sprite stack, you can set register 100 to specify a palette.
20:16:57 <andythenorth> think I'll need to patch nml
20:17:37 <peter1138> With the branch, instead of that, you can set bit 30 in register 100, and then the lower 16 bits reference to the set of colours you want (either colour 0-1 or colour 2-3)
20:17:50 <peter1138> Yes, NML will need patching, I've not done that.
20:19:10 <andythenorth> hmm the varact2 chain I was going to patch also reads var 0x43
20:19:12 <peter1138> I wonder if, instead of colour 0-1/colour 2-3, it should be two 8 bit values, and allow mixing from any slot.
20:21:32 <tony_pixel> gosh I'm hyped for the include patch, that'll be a way for me to officially support file hierarchies without blind guessing
20:21:51 <tony_pixel> And project-wide intellisense will be possible
20:22:46 <peter1138> Hmm, no, because it comes after the livery selection, which can output a non-CC palette.
20:23:17 <peter1138> andythenorth, I'll have to see where sprite stack stuff is done in NML :o
20:24:16 <andythenorth> CB_FLAG_MORE_SPRITES sets bit 31 I think
20:24:22 <andythenorth> [digging through it]
20:29:09 <andythenorth> hmm `PALETTE_USE_DEFAULT` also
20:35:40 <andythenorth> does `0x40000000` set bit 30? Maybe I can just store that
20:36:06 <peter1138> 0x40000000 will use the 1cc/2cc palette
20:36:25 <peter1138> 0x40000001 will use the 3cc/4cc palette
20:37:52 <peter1138> Being able to switch it around to 2cc/3cc or 4cc/1cc might have uses but isn't possible with the current design.
20:38:56 <_glx_> tony_pixel: you mean the "include" state ?
20:39:34 <_glx_> temporarily removes 'include' handling
20:39:49 <tony_pixel> I've just thought of that
20:40:25 <_glx_> so 'include' become an ID and doens't reenter
20:40:57 <andythenorth> should I be seeing 4 colours? 🙂
20:41:08 <tony_pixel> yeah the patch, one minute
20:41:41 <brickblock19280> peter1138: seems wrong to me if it's bit 30
20:42:32 <peter1138> andythenorth, oh you need to see extra flags too, it's undocumented as yet.
20:43:24 <peter1138> bits 6-7 of the extra flags property to enable 3cc/4cc per engine.
20:43:34 <tony_pixel> tony_pixel: I've tested this one and it should be functional
20:43:38 <peter1138> (Only 4cc needs to be set)
20:44:18 <peter1138> brickblock19280, why?
20:44:49 <brickblock19280> I might have missunderstood but why is bit 0 relevant? I thought it was just bit 30
20:47:05 <peter1138> Bit 30 tells us to pick a livery "layer". (A layer is a pair of colours, combined into a 2cc palette remap). The "layer" is specified in the lower 16 bits. So layer 0 is the first and second colours, layer 1 is the third and fourth colours.
20:48:07 <peter1138> Yes, it's overdesigned.
20:48:48 <peter1138> layer 2+ don't exist, but, you know, could....
20:49:17 *** Smedles_ has joined #openttd
20:49:52 *** Smedles has quit IRC (Read error: Connection reset by peer)
20:52:06 <brickblock19280> okay I thought just setting bit 30 would make it use 4CC from that given sprite rather than using 2CC allowing any recolour sprite to be used just like if the bit isn't set
20:53:37 <andythenorth> pff, I am failing at basic nml patching 😛
20:56:07 <brickblock19280> should've read the PR description better
20:58:39 <peter1138> The UI doesn't get better :p
21:00:21 <andythenorth> I think the default CC setting might be transposed 🙂
21:03:12 <brickblock19280> would be nice to have CC3/4 available as vars the way CC1/2 are
21:04:15 <andythenorth> does 0x43 have bits left?
21:04:19 <andythenorth> it's a weird var 😛
21:04:28 <peter1138> Ah yes, that still uses true/false instead of 0/1.
21:05:00 <andythenorth> ok I've achieved....something 😄
21:05:08 <brickblock19280> andythenorth: not what I can tell
21:07:21 <peter1138> Horse is probably overly interested in what the 1cc/2cc colours are.
21:07:42 <brickblock19280> 0x64 isn't even documented
21:07:48 <brickblock19280> (will go do that)
21:08:21 <andythenorth> peter1138: it is, for the complementary sets
21:09:32 <peter1138> Can you do HSV calculations in NFO to find complementary colours...
21:10:26 <andythenorth> switch (FEAT_TRAINS, SELF, walbrook_mv_0_unit_0_switch_graphics_purchase_base, STORE_TEMP(0x40000001, 0x100)) {
21:10:26 <andythenorth> return walbrook_mv_0_unit_0_ss_vehicle_purchase;
21:10:36 <andythenorth> then how do I index into a colour set?
21:10:47 <andythenorth> no I shouldn't need to
21:11:34 <andythenorth> got some nfo if that's better
21:12:07 <peter1138> Are you asking a question?
21:12:23 <andythenorth> talking to think
21:13:11 <andythenorth> that 0x100 store action has bit 30 set, and should be returning the 3cc/4cc palette?
21:13:26 <andythenorth> the extra flags are also set
21:17:01 <andythenorth> maybe I need to stop handling recolour CB temporarily
21:21:27 <peter1138> If you use the recolour CB to return a palette then that replaces the livery.
21:21:51 <peter1138> It's all intermingling with things that don't make sense together.
21:24:23 <andythenorth> I've turned that off
21:24:40 <andythenorth> might have to make a basic example nml tomorrow
21:24:44 <andythenorth> Horse has too much going on
21:27:21 *** jfs_ has quit IRC (Ping timeout: 480 seconds)
22:41:46 <peter1138> So I saw some vibe-coded version of Quake.
22:41:58 <peter1138> With extra options, called "Slop Options"
22:42:11 <peter1138> Anyway, it was dire.
22:59:01 <peter1138> Tile-based sprite varations eh?
23:22:38 <_glx_> hmm I wanted to test current master, and I get a segfault in blitter
23:28:42 <tony_pixel> that's Wednesday for ya
23:34:41 <_glx_> oh BTW tony_pixel I pushed the updated version
23:35:05 <_glx_> noticed a line counting problem, but it's fixed now
23:37:51 <tony_pixel> current version should work as intended, I will test default values right now
23:40:05 <tony_pixel> you can probably drop `include` branch entirely and rename this one, and push to remote
23:40:15 <tony_pixel> should that update the branch in PR?
23:43:00 <tony_pixel> also, should we add relative paths in the same PR?
23:44:20 <_glx_> yeah I'll update the PR with the new version
23:46:26 <tony_pixel> regarding relative paths, preferably merge #450 before that, because it also edits `find_file`
23:52:27 <tony_pixel> happens to the best of us
23:53:46 <tony_pixel> parses this as template import I guess
23:54:21 <tony_pixel> maybe add parameter when file is included and avoid doing regex subs then
23:55:32 <tony_pixel> you can do `symbols = None`
23:55:40 <tony_pixel> and check if it's None
23:55:52 <tony_pixel> if not, then sub (even if it's an empty dict it'll work)
23:56:18 <_glx_> but that would still break if it's an included file
23:56:57 <_glx_> would be better to change the default format
23:57:38 <tony_pixel> something that isn't used often
23:57:43 <tony_pixel> `=` is not I think
23:57:50 <tony_pixel> especially inside `{}
continue to next day ⏵
