Times are UTC Toggle Colours
00:11:13 *** frosch123 has quit IRC 06:36:37 *** Alberth has joined #openttd.dev 06:36:37 *** ChanServ sets mode: +v Alberth 07:14:51 *** Supercheese has quit IRC 10:17:32 *** frosch123 has joined #openttd.dev 10:17:32 *** ChanServ sets mode: +v frosch123 10:47:40 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26460 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 10:52:20 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26461 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 13:38:34 <planetmaker> frosch123, I need again some advise or guidance :) 13:38:47 <planetmaker> https://rhodecode.openttdcoop.org/pm-openttd/changeset/e8f54f5611363d6e0256f61a7a231e5829ab215f 13:38:51 <planetmaker> https://rhodecode.openttdcoop.org/pm-openttd/changeset/78587412e6a7b94beb59c6078655fc39ae79681a 13:39:15 <planetmaker> add a very simple TileCache. And the 2nd actually then starts caching the WaterDistance 13:39:38 <planetmaker> But it feels a bit... not versatile enough when I now want to add other values to cache, too 13:39:52 <planetmaker> feels that I'd duplicate code 13:43:08 <frosch123> is your water_distance actually a shore_distance? 13:43:15 <frosch123> due to both land/water? 13:43:26 <planetmaker> no, it's a water distance. I didn't change the logic 13:43:42 <planetmaker> thus a river or canal tile would trigger it, too 13:44:01 <frosch123> doesn't it return distance to land for water tiles? 13:44:07 <planetmaker> if (HasTileWaterGround(tile) == water) return 0; 13:44:13 <planetmaker> it does that 13:44:20 <planetmaker> for water tiles to land. for land tiles to water 13:44:34 <planetmaker> HasTileWaterGround is the cirterion 13:44:51 <frosch123> i guess instead of the bool, the invalid value should be 0 13:45:08 <frosch123> easy to test for validity, easy to invalidate 13:45:16 <planetmaker> true, could be done 13:45:20 <planetmaker> simplifies it 13:45:34 <frosch123> wrt. adding new cache values: yesterday you already had generic invalidation in load game / new game 13:45:50 <frosch123> about invalidation in commands and such: well, that is very specific to the cache :) 13:46:11 <planetmaker> I forgot to re-add those two places for InvalidateAll 13:46:18 <frosch123> also \n before { of functions 13:46:32 <frosch123> InvalidateClosestWaterDistance 13:46:49 <planetmaker> though I thought I could skip the InvalidateAll for after map load or map gen as it will be initialized with 0 = false anyway 13:47:11 <planetmaker> dangerous assumption maybe 13:47:30 <frosch123> well, i would assume that not all caches would be computed on first access 13:47:44 <frosch123> some things are easier to just compute once for all tiles at once 13:48:01 <planetmaker> I don't do that with the WaterDistance (so far) 13:48:16 <frosch123> well, yeah, it's part of step 3 only :p 13:48:21 <planetmaker> not sure it would be needed. yeah ^ 13:49:21 <planetmaker> but you'd recommend to add other caching variables to the same struct, including their methods? 13:50:10 <frosch123> yeah, i would expect certain common methods 13:50:13 <frosch123> like cache validation 13:50:23 <frosch123> and some caches may be invalidated together 13:50:26 <planetmaker> for instance, if I add TownDistance: should I implement the mothods then - as they're now - in town_cmd.cpp? 13:50:50 <planetmaker> not sure we can always say that value of 0 is the invalid value? 13:51:09 <frosch123> likely not, thus a init function would be fine 13:51:35 <planetmaker> makes it difficult to have a shared / common cache validation? 13:53:31 <frosch123> why? 13:53:42 <frosch123> we iterate over all vehicles to validate vehicle caches 13:53:54 <frosch123> thus we would also iterate over all tiles to validate tile caches 13:54:18 <frosch123> you can ofc add a new file tilecache.cpp, if that improves things 13:54:45 <frosch123> but i would still add all tile related caches to the same struct 13:54:58 <frosch123> instead of separate array for different tile caches 13:57:46 <planetmaker> you're thinking of something like a tCacheType = enum {...} and then void InvalidateCache(tCacheType cache, TileIndex tile)? 13:58:10 <frosch123> why an enum? 13:58:41 <frosch123> what is that function meant for? 13:59:15 <planetmaker> I don't see yet what method I can share between the different caches, what method could be common. Or how :) 13:59:39 <planetmaker> "Ich steh da grad auf dem Schlauch" :) 13:59:41 <frosch123> InvalidateAll, CheckAll, and such 13:59:58 <frosch123> for desync checks you would want to ocasionally validate all cached values 14:00:00 <planetmaker> which then call all the single methods? yeah 14:00:10 <planetmaker> ok 14:00:19 <frosch123> same for loading of games and such 14:00:25 <frosch123> one entry function for all tile cachs 14:00:41 <frosch123> specifiy entry functions for stuff like terraforming to only invalidate certain caches 14:00:41 <planetmaker> ok, I thought you meant something more fancy 14:00:52 <planetmaker> like a template function which would invalidate <whatever> cache 14:01:08 <planetmaker> instead of a wrapper which just goes over all caches 14:01:27 <frosch123> nah, templates will only work out if you have multiple similar caches 14:01:40 <frosch123> but i guess that is unlikely :) 14:01:54 <frosch123> nearest-coast and nearest-town is already quite different :) 14:02:02 <planetmaker> yep 14:07:18 <planetmaker> ok, thank you. I'll re-add the invalidation. Add InvalidateAll and RecalculateAll. And then add TownDistance and NearestTownID look for others 14:07:49 <planetmaker> s/look/and look/ 14:08:06 <frosch123> nearesttownid is enough, towndistance is easily computed from that for different metrics 14:08:24 <planetmaker> true :) 14:08:27 <frosch123> (well, different metrics is nonsense, then also the id would change) 14:11:41 <planetmaker> thanks for that feedback again :) 14:12:06 <frosch123> thanks for working on something :) 17:45:30 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26462 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:49:24 *** Alberth has left #openttd.dev 18:51:49 *** Supercheese has joined #openttd.dev 18:51:49 *** ChanServ sets mode: +v Supercheese 19:22:24 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26463 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 21:25:56 *** frosch123 has quit IRC 21:41:21 *** michi_cc has quit IRC 21:41:34 *** michi_cc has joined #openttd.dev 21:41:34 *** ChanServ sets mode: +v michi_cc 21:43:29 <LordAro> michi_cc, for some reason, i have decided to rebase your newmaps branch 21:43:44 <LordAro> i'm about 1/2 way through my initial make-it-merge stage 21:43:52 <LordAro> god knows why i'm doing this :)