IRC logs for #openttd on OFTC at 2026-07-29
⏴ go to previous day
00:06:32 *** andythenorth_ has quit IRC (Quit: Connection closed for inactivity)
01:15:47 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
01:31:16 *** MinchinWeb[m] has joined #openttd
01:52:48 *** Wormnest has joined #openttd
03:00:04 *** herms22 has quit IRC (Quit: bye)
03:04:54 *** herms22 has joined #openttd
03:27:59 *** Philemon has joined #openttd
03:31:20 *** Phileman has quit IRC (Ping timeout: 480 seconds)
03:40:17 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
03:43:04 *** MinchinWeb[m] has joined #openttd
03:51:07 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
03:51:34 *** MinchinWeb[m] has joined #openttd
05:02:09 *** ChanServ sets mode: +v tokai
05:09:10 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
06:13:11 *** andythenorth_ has joined #openttd
06:36:57 <peter1138> Hmm, so the substitute id property is normal 0x08.
06:37:05 <peter1138> And the class id property is normally 0x08...
06:37:52 <peter1138> Objects have an override manager but can't override.
07:26:58 <LordAro> clearly we should import some sort of toml library
07:48:23 <peter1138> Clearly... uh... no?
07:56:49 <andythenorth_> "toml is weird"
07:57:37 <peter1138> Well, maybe if LordAro wants to do it, that's his itch :)
08:47:58 <_zephyris> Any chance of a dummies guide to the NewGRF trees idea?
09:26:41 <_zephyris> I see there's the sprite layout definition for trees, but I'm not seeing how that would cooperate nicely with other currently loaded NewGRFs
09:27:48 <_zephyris> (or am I missing something?)
09:31:58 <peter1138> Yeah, there's no cooperation between NewGRFs, each has its own style of tree tile. That is potentially an issue.
09:32:44 <peter1138> The built-in system uses explicit lists of sprites for each tile, and so the new system does the same.
09:35:18 <peter1138> Initially I considered doing it at the individual tree level, which is why the existing data structure rearrangement has a new list of tree sprites.
09:36:06 <peter1138> But then I realised we'd have to be resolving NewGRF sprites for each individual tree instead of just once for a tile.
09:38:07 <peter1138> If we got rid of tree tile layouts, we might need to specify each individual tree on a tile.
09:38:19 *** Flygon has quit IRC (Read error: Connection reset by peer)
09:41:37 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
09:42:35 *** MinchinWeb[m] has joined #openttd
09:44:21 <locosage> does it allow to do tree shading btw?
09:44:53 <locosage> I guess that's just slope check on nearby tiles
09:45:33 <peter1138> You can do that with or without NewGRF introducing trees.
09:46:52 <locosage> it kind of needs newgrf support as shading trees doesn't look equally good for all grfs
09:48:07 <peter1138> Almost nobody is using 8bpp blitters, 32bpp blitters can apply shade equally.
09:52:04 <locosage> in theory yes, but currently all recolours are palette based iirc
09:52:26 <locosage> except maybe for crash/newspaper one
10:10:09 * peter1138 fixes Mpd.php by limiting `explode(': ', ...)`
10:10:24 <peter1138> Cos some of my tracks do have colons in the name, yup.
10:28:01 <peter1138> JGRPP takes a different approach, adds a shade parameter when drawing sprites.
10:28:24 <reldred> Tree shading is soooo nice btw
10:28:34 <reldred> Big fan of that in JGRPP.
10:45:03 *** WormnestAndroid has quit IRC (Remote host closed the connection)
10:46:11 *** WormnestAndroid has joined #openttd
11:10:04 <peter1138> _zephyris, if mixing trees on a tile is necessary this will require a redesign I guess.
11:12:12 <peter1138> +from different NewGRFs
11:34:46 <reldred> tbh I'm not sure I'd want to mix different grfs trees on a tile, would make it hard to do that low ground cover bushes/etc. that we talked about yesterday
11:35:00 <reldred> without then stacking more logic on top
12:04:10 <talltyler> Trees behaving like trees is my vote as well. I'd rather we add the core functionality for what NewGRF authors need rather than making them do it themselves with callbacks.
12:10:54 <_zephyris> I'd imagined a 'tree class' based system for placement - each tree gets a definition of valid tile types (grass, rainforest, desert, snow), a class (eg. lowland, highland, scrub, tall, cactus) and a list of classes that it cannot share a tile with. eg. I might want to define scrubland trees, normal trees and tall forest trees, and disallow tall trees from sharing with (short) scrubland trees.
12:10:54 <_zephyris> Then trees across NewGRFs could cooperate nicely.
12:23:23 <peter1138> Okay, so we'd need to store each individual tree instead of just the "cluster".
12:25:16 <peter1138> Then we might apply the existing growth stage logic, or also store that individually.
12:25:36 <peter1138> We'd need to resolve sprites for each tree individually, so up to 4 times per tiles instead of just once.
12:27:35 <peter1138> Compatible trees would need to be checked every time the tree count increases, and would need to check for compatibility across all of the trees that are present, so up to 4 times again.
12:28:32 <peter1138> Savegame conversion is fine, just needs to convert the old tile layout index to each individual sprite via the existing lookup tables which would only be used for this.
12:29:33 <peter1138> We'd be stuck with a limit of 255 different tree sprites as storing 4 trees uses more space.
12:36:06 <peter1138> And of course some people will be unhappy about us storing more "random data".
12:46:40 <talltyler> Scrub trees/brush would be such an amazing addition, keep forests from just blanketing the map and making everything look the same.
12:48:18 <peter1138> Well if you or anyone fancies looking at my example repository and providing replacement sprites, that can be ... tested :)
12:49:04 <peter1138> They're just taken from OpenGFX 1 anyway.
13:11:43 <talltyler> Garry G has a bunch of scrub plant sprites, you could ask him and/or trawl through the forum to find where he's posted his source files
13:17:40 <peter1138> Needs the 7 growth stages, and... stuff.
13:19:22 <talltyler> zyliety: has also drawn some trees?
13:21:38 <peter1138> It's the "low ground cover" stuff that would be interesting to see.
13:21:56 <peter1138> The "not quite a tree but still organic growth" things.
13:37:36 <andythenorth_> rabbits aren't quite trees
13:40:23 <brickblock19280> they have multiple growth stadges so surly they
13:50:26 <_zephyris> I'm super keen, can bash out sprites for testing
13:50:35 <_zephyris> Other dream features would be recolour definition somewhere in the pipeline, for recolour variants, and a time of year based switch (selecting recolour or sprite alternates, updated by tile loop) for season effects.
13:52:18 <peter1138> You can supply recolours in the sprite layout.
13:55:46 <peter1138> The usual varact2 variables are available to switch on date if you want.
13:56:28 <peter1138> There isn't yet a way to force a refresh. Doing that does get somewhat expensive.
13:57:22 <peter1138> (As noted by FIRS animated tiles before they are improved)
14:05:44 <_zephyris> Yeah, I wouldn't have a high framerate animation or animation triggers
14:05:52 <_zephyris> But tile loop update would be nice
14:06:37 <peter1138> That becomes a lot when trees have spread everywhere.
14:07:08 <_zephyris> But done anyway for growth
14:07:26 <_zephyris> Would need to think about a non-sprite layout way to set recolour if moving away from per tile sprite layouts, right?
14:08:48 <_zephyris> Thinking aloud: I think one of the biggest requests would be seasonality for trees, that's an obvious tree behaviour currently not possible
14:18:17 *** gelignite has joined #openttd
14:27:46 *** jinks has quit IRC (Ping timeout: 480 seconds)
14:44:49 *** Wormnest has joined #openttd
15:01:45 <andythenorth_> could track the number of apples
15:09:48 <peter1138> 256 temporary storage (i.e. 1KiB) per tree per tree tile?
15:10:21 *** jinks has quit IRC (Ping timeout: 480 seconds)
15:15:02 <peter1138> Would've been better off using objects :)
15:16:38 <peter1138> So animation state might be feasible if it can be slow enough. That gives the game a way to know if the tile should be updated.
15:18:06 <peter1138> You could then have 12 animation frames and switch them (based on game month) during the animation control. Then use the animation state in the graphics selection instead of using game month directly.
15:18:29 <peter1138> (That then means that trees don't all instantly switch (but maybe they should))
16:03:19 <_zephyris> All switching immediately wouldn't look good IMO, you want the stagger from the tile update loop
16:03:43 <_zephyris> Growing with tile update loop looks good because it's staggered across tiles
16:04:35 <_zephyris> A restricted performant season change/animation mechanism would be fine IMO
16:05:38 <_zephyris> Eg. 1 bit storage per tile, of whether it's current or previous month appearance
16:13:56 <peter1138> That's not how it works :)
16:32:09 <peter1138> Hmm, of course, you can mingle your NewGRF trees with default trees by directly use the original sprite IDs in your layout.
17:10:28 *** MinchinWeb[m] has quit IRC (Remote host closed the connection)
17:10:42 *** MinchinWeb[m] has joined #openttd
17:21:47 <LordAro> istr a reason why we never added WASD in the past
17:21:59 <LordAro> was it keyboard layouts with a lack of any real configurability?
17:22:38 <belajalilija> I think you can play the game very comfortably without using the arrows at all
17:30:24 <mmtunligit> WASD are already shortcuts for other things that i think are hardcoded
17:56:35 <_glx_> most shortcuts are configurable
18:16:47 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:31:40 <LordAro> yeah, but only via config file
18:32:05 <LordAro> not exactly user friendly to start with conflicting keybinds :p
18:33:44 <andythenorth_> I'd like my RAM back
18:34:04 <andythenorth_> this is used to suggest names for tab groups
18:34:08 <andythenorth_> great use of LLM
18:36:07 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
18:38:35 *** WormnestAndroid has joined #openttd
18:38:54 <_zephyris> peter1138[d]: What would be available for animation like that? Is the worry storage or update cycles?
18:44:34 <_zephyris> (naive questions I know, bad internet, so hard to check things}
18:58:58 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
18:59:44 *** WormnestAndroid has joined #openttd
19:01:18 *** kuayueren has joined #openttd
19:16:28 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
19:20:30 *** WormnestAndroid has joined #openttd
19:48:43 *** Wormnest has joined #openttd
19:48:43 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
19:48:51 *** WormnestAndroid has joined #openttd
20:10:37 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
20:11:11 *** MinchinWeb[m] has joined #openttd
20:19:12 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
20:19:54 *** MinchinWeb[m] has joined #openttd
20:45:00 <locosage> LordAro: probably because hotkeys work on key press but scrolling with arrows/wasd needs up/down events
21:13:38 <peter1138[d]> Storage is fine, there's enough space on the map. Just there are a lot of trees
21:17:53 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:42:42 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
22:42:59 *** MinchinWeb[m] has joined #openttd
continue to next day ⏵
