IRC logs for #openttd on OFTC at 2026-08-03
⏴ go to previous day
00:04:28 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
00:04:29 *** WormnestAndroid has joined #openttd
00:49:51 <peter1138> _zephyris, tree recolours only work for toyland because toyland has non-sensical "trees".
00:50:21 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:50:29 *** WormnestAndroid has joined #openttd
01:33:45 *** Wormnest has quit IRC (Quit: Leaving)
02:19:58 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
03:22:25 *** Phileman has joined #openttd
03:25:46 *** Philemon has quit IRC (Ping timeout: 480 seconds)
05:02:25 *** tokai|noir has joined #openttd
05:02:25 *** ChanServ sets mode: +v tokai|noir
05:09:10 *** tokai has quit IRC (Ping timeout: 480 seconds)
06:28:52 *** _cyclops_ has quit IRC (Quit: reboot)
06:29:27 *** reldred has joined #openttd
06:29:27 <reldred> seasonal tree variations would be superb
06:32:15 <peter1138> Yeah, you can do that with varactions, return different sprites.
06:32:50 <peter1138> Main issue is inability to control refresh.
06:34:26 <peter1138> With the tile layout version that would've been possible with animation state.
06:49:07 *** _cyclops_ has joined #openttd
06:55:13 <_zephyris> What's the issue with updating with the tile loop?
06:55:52 <_zephyris> I wouldn't try to do animation anywhere as complex as objects etc.
06:59:23 <_zephyris> Possibly better to think about it not as animation, but something different
07:01:48 <peter1138> It's coordinating it with what each individual tree "wants"
07:56:46 <DorpsGek> - Update: Translations from eints (by translators)
08:10:11 *** andythenorth_ has joined #openttd
08:41:43 <_zephyris> (Doesn't help that I really don't know how animation works elsewhere...)
08:42:35 <peter1138> Animation is a couple of callbacks and a frame counter stored in the tile.
08:42:59 <peter1138> The NewGRF controls happens to the frame counter during the callback.
08:43:27 <peter1138> There is only ever one NewGRF controlling animation on a tile.
08:43:56 <peter1138> The problem we have with trees is there could be up to 4 different trees controlling animation on a tile.
08:44:59 <peter1138> You could say that only the primary tree gets to control it, but that means the other trees, if they also wanted to use animation, might have animation state that they don't know what to do with
08:45:48 <andythenorth_> sharing thing is difficult :P
08:47:59 <peter1138> So a cut-down option might be to have a month counter on a tile which gets updated in the tile loop. If the month changes then it forces a tile refresh.
08:48:09 <peter1138> (But only if one of the trees requires it)
08:48:58 <peter1138> You can then sort of do seasonal variations without partial sprite update glitches, but only on a month-by-month basis.
08:49:26 <peter1138> (And what's a month in wallclock time anyway)
08:52:52 <peter1138> And maybe there's an algorithm to determine what the "current month" will be for a particular tree based on the tile loop update interval, then it doesn't need to be stored.
08:52:55 <andythenorth_> constraints are good also
08:54:40 <peter1138> Or just have a monthly event that forces all trees to be redrawn regardless, but then every tree that uses it would switch at once.
09:00:47 <peter1138> if (tile_loop_event_has_been_run_for_this_tile_this_month) return current_month; else return last_month;
09:01:59 <reldred> Staggering season changes over a two months would be fine I think
09:02:39 <reldred> Guess it depends how many seasonal variations you want to do
09:04:26 <mmtunligit> 4 variants for 4 seasons makes sense to me, and if youve got a tree that doesnt need that many it can just be told to stay the same for some
09:04:36 <mmtunligit> and i like staggering the changes too
09:06:02 <andythenorth_> action 0 jitter?
09:06:23 <andythenorth_> lots of things can be desynced by picking a random offset +/-1
09:12:58 <andythenorth_> how's that working out for vehicle intro dates? :P
09:14:00 <peter1138> That doesn't desync.
09:14:42 <andythenorth_> I don't mean network desync, in case that was ambiguous
09:14:53 <andythenorth_> I should have worded it better
09:18:43 <_zephyris> "Or just have a monthly event that forces all trees to be redrawn regardless, but then every tree that uses it would switch at once." <--- Something like this one, IMO
09:19:22 <peter1138> That would look bad in my opinion.
09:19:23 <_zephyris> Wouldn't need to be just every month, could be more granular than that.
09:19:55 <_zephyris> If you imagine just one tree changing then yeah, all copies of that tree would switch over a ~8sec tile loop.
09:20:12 <_zephyris> But if you imagine many different tree types, all changing at a different time, I think it'd work.
09:21:11 <peter1138> We try to avoid re-rendering things that don't need to re-rendered.
09:21:11 <_zephyris> Could jitter the time of year exposed to each tile, based on something pseudo-random.
09:21:59 <_zephyris> Not sure why that's an issue - if one of the trees on a tile needs redrawing then redraw the tile...
09:22:58 <peter1138> Looping the entire map to find out which trees need to be drawn is not ideal.
09:24:55 <_zephyris> I'm imagining it as similar to the tree growth loop, how does that trigger redrawing?
09:25:52 <_zephyris> Tile loop currently updates growth stage of trees and redraws those tiles, so why can't it also check (jittered) date for that tile and redraw if any of the trees on it have switched sprite?
09:26:14 <peter1138> Because tiles can be redrawn at any time.
09:28:43 <peter1138> So you have to make sure that the state the tile draws only changes at the same time as a the tile loop.
09:29:43 <peter1138> Tile loop isn't a monthly event, by the way.
09:29:49 <_zephyris> Hmm, so a stored 'animation' state for each tree on a tile which is updated each tile loop.
09:30:06 <peter1138> I am onboard with changing state during the tile loop, I am not okay with "just refresh the screen every month"
09:30:21 <_zephyris> Yeah, I realise that, it's only an ~8sec loop, right?
09:31:22 <_zephyris> I thought you were the guru of all knowledge! 🙂
09:36:11 <_zephyris> So, tree tiles store an animation frame for each tree on the tile. Every tile loop, growth state of trees and the stored animation frame is updated based on a check of date (which could be dithered based on tile position). If growth state or animation frame changes, mark as dirty.
09:38:14 <_zephyris> All trees of a single type changing within an ~8sec tile loop might look too fast, like you say, so a 2x2 tile dither (eg. `(yb << 1) | (xb ^ yb)`) would extend that to 32 sec, or a 4x4 Bayer matrix lookup to extend it to 2 min.
09:41:43 <peter1138> (See also snow-line changes)
10:04:37 <reldred> Id be fine if it was like the snow-line changes. Tends to create a bit of a pattern when it changes but I don't think it looks bad
10:04:45 <reldred> I mean, thirty year old pixel game and all
10:06:08 <andythenorth_> Farm fields are fine when animated?
10:06:23 <andythenorth_> Can’t remember how they cycle
10:08:40 <peter1138> Farm fields 1) store their state in the map 2) always change graphics depending on that state.
10:13:52 <_zephyris> They cycle to the next stage over one tile loop...
10:14:11 <_zephyris> (farm fields and snowline)
10:20:35 <reldred> andythenorth_: yeah they have a bit of a 'stripey' pattern when they cycle but I dunno I think it looks kinda endearing in a pixel game
10:21:34 <andythenorth_> watching some now
10:21:59 <andythenorth_> although with wallclock, it's best not to ask how a whole crop can be planted and harvested within March
10:24:54 <reldred> Yeah I must admit, I'm still using old jgrpp daylength
10:25:01 <reldred> couldn't wrap my head around wallclock
10:30:58 <andythenorth_> it just means that new trains are introduced less often in real time :P
10:31:12 <andythenorth_> everything else is identical
10:32:05 <andythenorth_> nobody complained so far so ... fine?
10:32:16 <reldred> Nah I have no problem with it
10:32:39 <reldred> a lot of players who's opinion i respect like it
10:32:56 <reldred> and I do in principle kinda dig the idea of being able to 'pause' the progression of time
10:41:33 <DorpsGek> - Add: summary for week 31 of 2026 (by OpenTTD Survey)
11:54:09 <peter1138> Hmm, it got hot again :/
13:15:23 <will_marshall_> I'm smug today because there is once again a nice easterly wind keeping coastal Lincolnshire a refreshing 22 degrees. I will be less smug when that wind stops blowing.
13:18:39 <will_marshall_> Bombing range ahead?
13:19:47 <andythenorth_> lot of live munitions bombing over the wash
13:20:28 <andythenorth_> "sound of holidays" -> Tornados at 300 feet, followed by distant explosions
13:21:19 <will_marshall_> Yeah! My mum wanted me to buy a house in Holbeach but I decided I didn't want to get flooded so I bought further up the coast near the other bombing range.
15:42:57 <peter1138> Hmm, I think the override manager stuff might be in the wrong place now :o
16:13:13 *** Flygon has quit IRC (Read error: Connection reset by peer)
16:27:37 <andythenorth_> suggest implementations or needs? :P
16:27:58 <andythenorth_> I would like to set company colour on an object to that of a nearby industry
16:28:30 <andythenorth_> could be done by looking for nearest industry industry with a specific badge predicate, and returning the colour from that
16:29:13 <andythenorth_> or by extending the UI to allow attaching objects to specific industries
16:29:18 <andythenorth_> 2 very different ideas :P
16:30:49 <talltyler> Suggest needs. My proposed implementation for that is "expandable industries," which is pretty much your second idea, but making them actually industry tiles instead of objects 😛
16:31:39 <talltyler> (NewGRF fields would be the same thing, in my vision, industries could plant whatever additional tiles they choose, and the author chooses whether each additional tile is permanent like a building or can be bulldozed like a field)
16:31:54 <talltyler> Not that I am volunteering to implement this 🙂
16:32:19 <peter1138> Should tree clusters on landscape generation use similar or different trees?
16:32:25 <talltyler> I thought FIRS currently does that with a modulo on the parent town ID?
16:34:55 <andythenorth_> FIRS uses modulo on the parent town ID yes
16:35:04 <andythenorth_> fails when it crosses an authority boundary
16:36:02 <andythenorth_> more columns for industry listing?
16:37:11 <andythenorth_> I like the sidebar buttons, but it's a bit unbalanced, I was trying to think of a way to rebalance it
16:38:04 <andythenorth_> hmm it only looks like it clips
16:39:38 <peter1138> It's still based on max of cargo types and industry types.
16:39:45 <peter1138> If you switch to cargo types that blank space will be used.
16:41:42 <peter1138> Of course, cargo types 'wastes space' due to the linkgraph saturation part.
16:44:51 <andythenorth_> I had a project to make objects build seamlessly on water or land
16:45:10 <andythenorth_> was tricky resolving coasts and foundations accurately
16:45:18 <andythenorth_> _should finish_
16:58:32 *** Wormnest has joined #openttd
17:15:56 <andythenorth_> ^ I wouldn't :P
17:16:01 <andythenorth_> flat is better than nested
17:18:35 <rito12_13> andythenorth_: The propulsion behaves better when nested
17:19:31 <andythenorth_> :person_shrugging:
17:19:43 <andythenorth_> I'm not really against it, just nesting always causes problems
17:25:14 <andythenorth_> hmm could the station window remember the opening position?
17:25:32 <andythenorth_> opening in the middle of the screen requires windowshading it every time to build anything
17:25:44 <andythenorth_> and it has no pin
17:36:11 <andythenorth_> for the filtering case, the happy path is quite narrow
17:36:49 <andythenorth_> `power/electric/ac` vs. `power/electric`
17:37:03 <andythenorth_> assuming players load more than one grf
17:37:25 <andythenorth_> `livery/br/large_logo/blue`vs `livery/br/blue/`livery/br/large_logo/blue``
17:37:40 <andythenorth_> oof can't edit irc
17:37:55 <andythenorth_> `livery/br/large_logo/blue` vs `livery/br/blue/large_logo`
17:39:38 <rito12_13> currently you can also have `livery/br/large_logo/blue` in one grf and `livery/br/blue/large_logo` in second or even `livery/br/large_blue_logo` in 3rd one
17:54:16 <_glx_> confirming nesting always is an issue 🙂
18:06:59 <peter1138> When I proprosed nesting I only meant in the UI.
18:11:47 <peter1138> So trees, 4 possible states or 12?
18:11:53 <peter1138> (seasons vs months)
18:15:26 <mmtunligit> id go for seasons personally
18:22:33 <rito12_13> peter1138: I think I found what you mean, so for filtering to work the grf authors would add `power/electric` themself to each vehicle when doing an AC/DC aware set
18:29:09 *** kuayueren has joined #openttd
18:46:00 *** kuayueren has quit IRC (Ping timeout: 480 seconds)
18:56:08 <peter1138> Also, who's got the gorse and other ground cover sprites?
19:00:50 <_zephyris> Is there an existing set?
19:08:11 <_zephyris> Well, I could knock a rough one up quickly...
19:23:17 <peter1138> Hmm, NML can't have a value of 0xFFFFFFFF.
19:34:33 <peter1138> ConstantNumeric is truncated to int32 :o
19:42:11 <_zephyris> A bit rough, but ok for tests?
19:42:41 <_zephyris> gorse, budleia, bramble, heather +/- flowers
20:18:37 <_zephyris> They're auto-generated growth stages, and not well tested for scale... so it'll be a bit meh
20:21:53 <peter1138> I don't know what I am doing :)
20:22:53 <peter1138> But they do look like they are just slapped on top instead of being part of the scenery.
20:25:00 <peter1138> Tree growth cycles probably ought to scaled by wallclock time.
20:25:36 <peter1138> Oh, maybe they are already.
20:26:47 <peter1138> I'm just using the global month variable at the month to switch graphics.
20:27:06 <_zephyris> Yeah, that's mostly sprites just needing refinement. Budleia's way too bright, no contact shadowing, etc. Looks like they're aligned a bit too high too.
20:29:50 <peter1138> So sub-trees might want their own month-jitter
20:30:47 <peter1138> I think tree positions doesn't consider the tile slope.
20:32:14 <peter1138> Might just be a case of expanding the positions to include a z-offset, and then repeating for each possible slope?
20:34:13 <peter1138> Kinda want the first 2 growth stages of the last planted tree on a tile to use the non-flower version. Hmm.
20:35:42 <peter1138> Hmm, well, that basically just means not putting flowers on those stages. Hmm.
20:36:40 <peter1138> What if growth stage was per-tree instead of only for the last tree...
21:11:02 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
21:11:11 *** MinchinWeb[m] has joined #openttd
21:15:31 <_zephyris> 4 sub-tiles, 4 possible x/y offsets of the 2x2 Bayer matrix.
21:15:43 <_zephyris> And, no, it doesn't consider slope.
21:16:56 <_zephyris> Flowery vs. non-flowery is definitely a graphics choice, I'd (properly) draw the early growth stages without flowers, and use the month switch for flowery/non-flowery.
21:26:06 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:28:01 <_zephyris> (The Bayer matrix comment was a way to easily do a dither per tree on the tile, if you didn't get that).
21:51:40 <belajalilija> _zephyris: My 2 favourite plants
21:52:05 <belajalilija> Budleia and gorse :chefkiss:
22:00:29 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
22:00:45 *** MinchinWeb[m] has joined #openttd
22:49:20 *** ialokin has quit IRC (Ping timeout: 480 seconds)
23:14:20 <peter1138> Refreshing with jitter sucks for performance :/
23:20:26 <reldred> <a:eyesshaking:833706919465058355>
23:27:27 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
23:29:14 *** MinchinWeb[m] has joined #openttd
23:37:05 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
23:38:02 *** MinchinWeb[m] has joined #openttd
23:50:03 *** andythenorth_ has quit IRC (Quit: Connection closed for inactivity)
continue to next day ⏵
