00:01:52 <04d​racoomega> Huh. I thought I specifically tested that, but I must have actually had an angle of direct fire on it and autofight was adjusting to something next to it (and it just looked like it was chaining through the thing directly ahead of me) 00:03:35 <04d​racoomega> (It does make autoaiming better in the case where you do have any angle on something else) 00:04:30 <04d​racoomega> So I'd probably consider this 'still room to be improved, but better than the old behaviour' 00:07:27 <04d​racoomega> By the way, I left a comment on https://github.com/crawl/crawl/pull/5167 in case you didn't notice. (I'm also planning to go over some more of them in the next few days, but that targeter bug I caused ended up taking quite a lot of time to fix) 00:51:45 <11O​dds> Thanks yes! I hadn’t spotted that case and will look into it some time 00:58:37 <11O​dds> Ah thanks, I’ll have a look at fixing this at some point 00:59:47 <11O​dds> And thank you also for the many recent reviews 🙂 03:33:46 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 03:52:02 <07w​izardike> @Odds regarding the third commit from https://github.com/crawl/crawl/pull/5167 you said "We were banning trees from having a tile override when out of LoS, which meant dead trees showed up as normal ones when magically mapped.". However, this isn't quite right, we are entirely banning trees from having tile overrides and instead they get their tile from their colour (see apply_variations in tilepick.cc and the %variation DNGN_TREE 03:52:02 brown line in dc-feat.txt ). This doesn't happen for magic mapped tiles as their colour is usually not set (see _feat_default_map_colour which is called from magic_mapping in map-knowledge.cc). Magic mapping not revealing tile colour very rarely has any effect anymore as we now reveal the exact tile overrides for floors and rock walls (which have the colour baked in). 07:57:07 feature req., maybe will work on patch, show which equipment is providing redundant resists 07:57:36 rElec+(++) on stats page, (++) colorcoded gray maybe 07:58:18 10/10 times I hit an extended run this becomes relevant, especially with even more inventory space for randart rings 10:54:51 <11O​dds> Thanks! Do you know why trees were banned from having tile overrides? I haven't quite got my head around why we have both overrides and apply_variations, which seem to do mostly the same thing 12:15:19 New branch created: pull/5203 (1 commit) 13https://github.com/crawl/crawl/pull/5203 12:15:20 03CrawlOdds02 07https://github.com/crawl/crawl/pull/5203 * 0.35-a0-285-gda10feb5f3: Let tracers enchantment chain 10(31 minutes ago, 1 file, 5+ 1-) 13https://github.com/crawl/crawl/commit/da10feb5f319 15:04:30 New branch created: pull/5204 (1 commit) 13https://github.com/crawl/crawl/pull/5204 15:04:31 03LiciTheCrawler02 07https://github.com/crawl/crawl/pull/5204 * 0.35-a0-285-gd6b4a1ae05: Feat: new conduct title, Unburdened 10(4 minutes ago, 2 files, 26+ 0-) 13https://github.com/crawl/crawl/commit/d6b4a1ae053c 15:11:24 03LiciTheCrawler02 07https://github.com/crawl/crawl/pull/5204 * 0.35-a0-286-gb54e9326fc: Checkwhite 10(3 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/b54e9326fc51 15:41:45 Unstable branch on underhound.eu updated to: 0.35-a0-284-g0df9381b46 (34) 18:36:19 <07w​izardike> So if you cast summon forest and it turns a wall with a tile override into a tree, you then move so that the tree is out of sight and wait off summon forest, the square will have a tree tile and be described as a tree. However, if you reload the game the square will have the wall tile but still be described as a tree. This is because we don't store tile overrides in the map knowledge, so as soon as the summon forest spell wears off 18:36:20 the tile override for the square will return to the wall tile and when the remembered tree is next redrawn it will have the wall tile. We get around this by banning terrain types that are created by temporary terrain from having tile overrides. Except, this doesn't actually work very well as 1. Nobody updates this when added a new type of temporary terrain 2. We use tile overrides on some terrain types that can be created by temporary terrain so they 18:36:20 can't be banned Tile overrides and apply_variations don't usually do the same thing. Tile overrides allow choosing a custom tile for a feature, apply_variations then applies any colour set for the square and applies animations. The tile override on Crypt trees would actually prevent the colour of the square from affecting the tree's tile as the dead tree tile doesn't have colour variations (only the normal tree tile does) which would prevent dead trees 18:36:21 looking alive if the square was recoloured green. Except, it does nothing because tile overrides are ignored on trees and it might not even be possible for a tree to be recoloured without becoming a demonic tree anyway. 18:40:10 <04d​racoomega> I recall some comments about Zin Imprison walls talking about information leaks via description overrides, which I assume it related to this mess 18:44:22 <07w​izardike> Yes, I believe those are metal walls with a tile override so we can't ban tile overrides for them (we could fix this whole mess by saving the tile override in the map-knowledge but I'm not sure if there is a better fix) 18:48:29 <04d​racoomega> Yeah, it's not something I've looked at too closely myself (beyond being originally surprised at how clunky the means for supplying a custom tile here is) 19:17:28 <04d​racoomega> @Odds I have been slowly reviewing the math for your piety decay removal PR and looking over some of these piety tables in the logs (which I had never inspected closely before). I was very confused for a while at how the percentage lost to piety stepdowns in a bunch of these logs was so high (like, up to 75% of piety in some cases, which is far higher than it seems like it should be) until I realized from looking at the code that 19:17:29 this is probably because they were at 200 piety and it was tracking the inability to gain more than 200 as the same as failing to gain piety due to the piety stepdown. (I'm not sure this really changes any of your conclusions, but I wonder if it's not the best way to chart that information, since we will presumably be staring at more of these charts in the weeks after the PR is merged) 19:40:27 <04d​racoomega> Huh. I've checked a bunch of Trog victory morgues now and they don't seem to have the normal piety table. (Or, well, they do, but it's empty). Piety by conduct is tracked, but not actual piety progress for some reason. 21:31:42 03WizardIke02 07* 0.35-a0-285-gf0a2de8890: Remove the needs_update parameter from dgn_replace_area 10(3 minutes ago, 2 files, 5+ 16-) 13https://github.com/crawl/crawl/commit/f0a2de8890b1 22:32:02 <11O​dds> Oh that’s surely going to be this not working for berserkers 22:34:01 <02D​arby> > (like, up to 75% of piety in some cases, which is far higher than it seems like it should be) a lesson in and of itself, though, 22:36:05 Unstable branch on crawl.develz.org updated to: 0.35-a0-285-gf0a2de8890 (34) 22:38:31 <11O​dds> Yeah I agree. The maths doesn’t end up relying on this column but it’s not terribly useful! 22:39:36 <11O​dds> (Gonna have to refresh my memory on all this, I’ve mostly forgotten what I did…) 22:55:33 Is there an easy way to submit art? 23:00:00 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-285-gf0a2de8890 23:04:38 <08w​ormsofcan> just share it 23:07:53 I don't see a way to share a png to the libera chat 23:11:27 -!- HN-MKU_ is now known as HN-MKU 23:20:36 Unstable branch on cbro.berotato.org updated to: 0.35-a0-285-gf0a2de8890 (34) 23:24:27 nevermind i figured it out, thank you 23:25:03 New branch created: pull/5205 (1 commit) 13https://github.com/crawl/crawl/pull/5205 23:25:04 03Amelia02 07https://github.com/crawl/crawl/pull/5205 * 0.35-a0-286-g49cacd4351: Create Valkyrie.png.png 10(7 minutes ago, 1 file, 0+ 0-) 13https://github.com/crawl/crawl/commit/49cacd4351fa 23:27:38 <11O​dds> Thank you, this was super useful and I understand much better now. I need to think harder about this, but: * My current thinking is that the right fix here is to have map_knowledge track tile overrides, which would also fix the thorny case of https://github.com/crawl/crawl/issues/5168, where we need the tile override for a description (and also just generally seems correct - tiles should be calculable from the player's map knowledge). But 23:27:39 this is a biggish thing * I also wonder if we should be banning tile overrides for temporary terrain rather than a list of tiles. It seems like no temporary terrain should ever have a tile override, and that tiles which can be temporary should be overriddeable when they are permanent (as in the Crypt tree case) 23:35:55 <11O​dds> Yep, for zealots we fail to register than they join their god and so never track any detailed stats (IIRC, only starting logging on join was so that we don't get confusing half-tracked games where the player upgraded version, but the zealot bit is just an oversight) 23:56:12 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-285-gf0a2de8890