IRC logs for #openttd on OFTC at 2026-10-16
⏴ go to previous day
00:05:04 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
00:05:45 *** MinchinWeb[m] has joined #openttd
01:17:18 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
01:17:28 *** MinchinWeb[m] has joined #openttd
01:41:34 <tony_pixel> escapes are only in literal string argument, so only replace there
01:41:40 <tony_pixel> I think this should be ok
01:42:05 <tony_pixel> if someone inserts an escaped filepath well, I guess we can't do much about that
01:46:36 <tony_pixel> huh, we should also check that nested id=value override ids in correct order
01:47:03 <tony_pixel> I'd expect a "parent" include's values to override inner ones
01:50:02 <_glx_> the most recent definition wins (that's how scoping works)
03:13:14 *** MinchinWeb[m] has quit IRC (Read error: No route to host)
03:13:32 *** MinchinWeb[m] has joined #openttd
03:13:46 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
03:13:51 *** MinchinWeb[m] has joined #openttd
03:29:16 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
03:29:32 *** MinchinWeb[m] has joined #openttd
04:00:58 *** Phileman has joined #openttd
04:04:18 *** Philemon has quit IRC (Ping timeout: 480 seconds)
05:03:53 *** ChanServ sets mode: +v tokai
05:11:08 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:11:35 <_zephyris> The random tile variation is interesting... That's about as simple as it could get and kinda works...
07:13:02 <_zephyris> The sprites are exactly what they sound like - a random shuffle of all except the tile border pixels
07:15:40 <peter1138> I wonder if the original sprite should be included. It's simpler not to, but slightly wasteful.
07:19:18 <peter1138> Hmm, actually not that complex to do, but does mean the NewGRF side needs a bit more work especially in Act 1.
07:29:09 <peter1138> Also the NewGRF changes assumes that no-one is making an Act5 with 255 entries. (There's only 28 different types, but I suppose you could define multiple times if splitting), nor defining 255 ActA sets.
07:29:28 <peter1138> Realistically they are not, but it would currently be valid to do so.
07:37:49 <_zephyris> Oh, yeah, I was wondering why I couldn't quickly find the original sprite
07:38:34 <peter1138> Question is what behaviour do we want.
07:38:55 <peter1138> For Act5 and ActA it's simple enough to do either.
07:39:14 <peter1138> For Act1, there is no original sprite.
07:44:38 <peter1138> So we can do: Act5 to set base sprite, then another Act5 to set variations. Same with ActA.
07:45:21 <peter1138> Hmm, possibly Act1 could do the same, real Act1 and then variation Act1.
07:46:34 <peter1138> The other way would be for all sprites to exist in the same block, so you'd need to dupe the original for Act5/ActA (not much difference for Act1)
07:48:27 <peter1138[d]> Roughly the same location as before, but with all 5 sprites.
07:48:52 *** SigHunter has quit IRC (Remote host closed the connection)
07:50:53 <peter1138[d]> That's pretty random.
07:51:22 <peter1138[d]> I mean, it's not random at all, but it kinda looks it.
07:59:52 <_zephyris> Yeah, definitely good random scatter. The ground tiles I suggested need more artistic direction, at the moment its subtle variation but would work better with more intentional variation I suspect
08:00:36 <peter1138[d]> Yes, just randomly shuffling them does not produce a good look, but for a POC that's fine.
08:01:28 <peter1138[d]> Hmm, I should try the water sprites, see what happens with off-map tiles.
08:02:57 <peter1138[d]> Yeah, it doesn't crash but only draws the same variatin.
08:04:22 <peter1138[d]> Hmm, just spotted a caveat. With kuhnovic 's branch it only does water tile variants on sea tiles. With my branch it does it for all water tiles.
08:05:28 <_zephyris> Random shuffled original water sprites
08:05:39 <peter1138[d]> I doubt that's a huge issue.
08:05:56 <_zephyris> They can be set separately by newgrf anyway
08:06:00 <peter1138[d]> Works enough for me :D
08:06:11 <peter1138[d]> But I'll do it for the full effect
08:06:54 <peter1138[d]> Well, not right now. Work-o-clock.
08:26:46 <reldred> <a:eyesshaking:833706919465058355>
08:32:06 *** tokai has quit IRC (Ping timeout: 480 seconds)
08:38:34 *** Flygon has quit IRC (Read error: Connection reset by peer)
08:39:18 <kuhnovic> _zephyris: I told you this would escalate quickly 😛
08:40:51 <kuhnovic> peter1138[d]: How many different sprites are you using here? This already looks "random enough"
08:44:30 <kuhnovic> peter1138[d]: That's a good thing right? And river / canal / sea tiles all use different sprites so it's easy to separate between them.
08:53:16 <_zephyris> I still wonder if it's the 'right' way to do it, vs. a varact2 for a newgrf tiletype feature.
08:53:39 <_zephyris> OTOH, base set niceness, client side only
09:27:54 <peter1138[d]> kuhnovic: They don't use different sprites, only if a NewGRF supplies them. It's not a huge issue, and may be desirable. It's just different from your PR.
09:28:42 <peter1138[d]> I could drop the attempt at Act1 support, so NewGRFs have to do their own thing.
09:31:51 <peter1138[d]> _zephyris: This actually looks kinda bad :(
09:33:01 <_zephyris> I think Kuhnovic's approach to vary sparkle level is better, these are very naive sprites
09:33:30 <peter1138[d]> Isn't that just a case of drawing the correct sprites?
09:35:06 <peter1138[d]> The issue is the shuffled pixels don't make a good animation cycle, not that the variations system is bad.
09:35:17 <andythenorth> and mixed climates 😛
09:35:31 <andythenorth> is the random seedable locally?
09:35:45 * andythenorth hasn't read the PR
09:37:38 <peter1138[d]> It's the way the sparkles all go "off" at about the same time.
09:41:09 <peter1138[d]> andythenorth: It's a hash based on the tile index, it's not controllable. If it was, you'd end up with the same "pattern" just with a different offset location.
09:42:44 <peter1138[d]> I guess the water animation cycle has a phase where there are no sparkles, so any layout of pixels isn't going to help.
09:46:22 <andythenorth> peter1138[d]: no biomes then 😛
09:46:41 * andythenorth always looking for exploits
09:46:48 <_zephyris> Yup, better sprites needed 🙂
09:47:53 <peter1138[d]> My clip doesn't do it justice, it misses frames :(
09:47:58 <kuhnovic> There are 5 colors for the shimmer palette animation. You get pretty good spread in terms of timing if you use all five. Another trick I used is drawing two adjacent shimmer pixels but with a 2 color index offset (I hope you understand what I mean by that). That creates the illusion of a longer lasting shimmer effect that moves along with the underlying wave pattern, provided you draw it
09:50:47 <peter1138[d]> Hmm, so there are 7 frames of sparkles and 8 frames of static.
09:52:07 <peter1138[d]> I think the palette animation code handles it so they're all offset by 3 frames. 3 * 5 = 15.
09:52:51 <peter1138[d]> So it should be possible to avoid a dead-zone of no sparkles with the right sprites. Maybe.
09:53:05 <peter1138[d]> That still may not be desirable though.
10:07:07 <peter1138[d]> Hmm, maybe a bit could be used to control whether the variations replace the original sprite or not.
10:08:08 <peter1138[d]> There's a byte that contains the number of variations, could stuff a flag in there.
10:57:45 <_zephyris> IIRC original water has an uneven usage of each of the shimmer colours, which is why it looks wonky. OGFX2 uses 5, one per palette index, per tile.
11:11:54 <kuhnovic> This should effectively have the same effect as the shimmer overlays from my PR. I just quickly put this together, it's lacking some of the anti flicker stuff that OpenGFX2 has, but it should be fine for a test. Only 3 out of 8 contain shimmer pixels, that's on purpose.
11:19:07 <peter1138[d]> _zephyris: Yeah, that's the conclusion I came to :)
11:22:32 <peter1138[d]> Hmm, if it's 32bpp then there are no shimmer pixels.
11:23:03 <kuhnovic> Ah oops, this gets converted down to 8bpp by OpenGFX2's scripts. One sec
11:27:10 <kuhnovic> This one should be 8bpp
11:32:41 <kuhnovic> Nice, seems identical enough. Does the animation look good?
11:36:37 <peter1138[d]> Yeah, bit of weirdness when zoomed out, but kinda normal there.
11:37:41 <peter1138[d]> Probably not as bad as when it was an overlay.
11:38:13 <kuhnovic> At least there is the ability to tweak it now
11:38:37 <peter1138[d]> And variable number of sprites without counting at runtime :)
11:39:44 <kuhnovic> I already fixed that! 😛
11:40:29 <kuhnovic> Oh wait, yeah your implementation actually supports a variable count
11:41:23 <peter1138[d]> I am wondering if I should support the tile hash for out of bounds tiles.
11:46:40 <kuhnovic> If you wrap the tileindex to its equivalent in-map coordinate then it should work just fine right?
11:47:33 <kuhnovic> The pseudo-random pattern would repeat outside the map boundaries but I doubt that that's even noticeable
11:49:25 <kuhnovic> Yeah that's a bit big
11:50:38 <peter1138[d]> I can use _cur_ti.x/_cur_ti.y instead of _cur_ti.tile for the infinite water tiles, I guess.
11:55:37 <peter1138[d]> Comparison, anyway.
11:56:34 <peter1138[d]> I see OpenGFX 2 already uses different sprites for rivers, that isn't standard baseset stuff :)
12:07:30 <kuhnovic> I know which one I like better 😉
12:11:41 <peter1138[d]> So I was wondering if other types of variations make sense, or if those should just be varact2 anyway.
12:21:19 <andythenorth> Default river sprites are bad - I drew them
12:29:46 <peter1138[d]> OpenGFX 1's take up too much tile.
12:30:14 <peter1138[d]> And zBase... well...
12:30:36 <peter1138[d]> I'm not sure what they are meant to be, but perfectly straight lines.
12:41:49 <peter1138[d]> Wonder were Act1 variations would fit in.
12:42:31 <peter1138[d]> Would avoid needing to duplicate tile layouts I guess.
12:48:16 <peter1138[d]> Reddit has completely stalled since those 2 AI posts.
12:49:49 <emperorjake> I feel the subreddit's been unusually quiet lately in general
12:51:20 <peter1138[d]> All moved on to OpenLoco instead?
12:58:47 <will_marshall_> I think the subreddit will pick up when 16.0 is out?
13:10:57 <talltyler> Well, when are these lazy developers going to release 16.0? 😛
13:22:14 <talltyler> Well, the milestone only has one PR awaiting review, and a documentation task... so we might be waiting a while 😄
13:32:13 <tony_pixel> meanwhile glx is prettying up the include patch, could you guys review #450?
13:32:56 <tony_pixel> We plan to add relative file handling there, so it would be nice if that one is merged before that
13:34:13 <peter1138[d]> talltyler: IMHO get the ball rolling on RC1. Anything left over is an excuse to not wait as long next time...
13:35:06 <peter1138[d]> No mac OS users to test things, maybe we need to merge to get it tested.
13:48:05 <andythenorth> I can test things this weekend (the cursor thing etc)
13:51:54 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
13:56:32 *** MinchinWeb[m] has joined #openttd
14:15:45 *** tabytac has joined #openttd
14:15:45 <tabytac> might as well also ask whats people thoughts on getting #16051 in before RC1 too?
15:03:57 *** rito12_13 has quit IRC (Quit: User went offline on Discord a while ago)
15:33:43 <tony_pixel> _glx_: what about recursive templating? Would we be able to just parse {ids} inside default options and in the passed literal strings and replace them?
15:33:53 <tony_pixel> or too much of a hustle?
15:34:27 <tony_pixel> I'm not sure about passed params but parsing inside default strings should be pretty easy
15:34:53 <tony_pixel> disallow defaulting on levels higher than the root
15:36:25 <tony_pixel> or maybe after the current version gets merged
15:36:40 <tony_pixel> I'm still due the implementation of relative paths
15:45:30 <tony_pixel> this works btw for less nested arguments to overwrite more-nested
15:46:02 <tony_pixel> If I include this with passed TYPE the right part gets replaced, so both possible behaviors are achieveable
15:52:52 <tony_pixel> you don't anymore?
15:53:57 <tony_pixel> you lost the spark man
15:55:29 <peter1138> The whole fallback system doesn't really work.
16:05:10 <LordAro> tony_pixel: i mean, yeah, a bit
17:03:38 <andythenorth> nml templating eh 🙂
17:22:30 *** nanapipirara has joined #openttd
17:45:27 *** nanapipirara has quit IRC (Remote host closed the connection)
18:04:58 *** gelignite has joined #openttd
18:56:38 *** SigHunter has joined #openttd
19:39:19 <tony_pixel> tony_pixel: pin-worthy tbh
20:28:17 <andythenorth> more than naptime
21:43:54 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:05:28 *** jfs_ has quit IRC (Ping timeout: 480 seconds)
22:23:35 *** toktik has quit IRC (Remote host closed the connection)
22:28:09 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
22:28:18 *** MinchinWeb[m] has joined #openttd
22:55:41 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
22:55:58 *** MinchinWeb[m] has joined #openttd
23:12:18 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
23:14:24 *** ChanServ sets mode: +v tokai
23:15:32 *** MinchinWeb[m] has joined #openttd
23:27:39 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
23:28:15 *** MinchinWeb[m] has joined #openttd
23:33:29 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
23:33:45 *** MinchinWeb[m] has joined #openttd
continue to next day ⏵
