02:50:44 <07wizardike> So if you forget the map and then something out of view changes in a square that you have seen and then you read revelation and then unforget the map, the changes from revelation will be undone and we need to also undo the changes to the remembered tile overrides. Actually, I just tested this and unforgetting the map is already quite buggy before this PR as you don't see the changes until you reload. Maybe we don't actually want to 02:50:45 undo the revelation changes in this case? As for update_grid_colour_knowledge and update_terrain_knowledge being separate functions, I originally had these as one functions but there were places that weren't updating the grid colour knowledge or were clearing it (by not passing a second parameter to set_feature) when it didn't make sense to clear. I decided that these places shouldn't update the grid colour knowledge but I'm completely happy to change 02:50:45 this and make update_terrain_knowledge update colour knowledge. 03:00:05 <04dracoomega> Isn't non-wizmode map 'forgetting' essentially just marking all tiles as unvisited and not actually losing any map knowledge? At least that's what it looks like most of the time, and what seems to be the intended function of it. (In which case, I would find forgetting anything learned by ?revelation to be quite surprising behavior. I'd expect all unforgetting should do is mark tiles you'd actually visited as visited again.) 03:02:26 <04dracoomega> Also, what reason would would there be to update map_knowledge of a tile but not its color? You've looked into this much more than I have, so I could easily be missing something, but on the face of it it sounds strange to me. Aren't they sort of intrinsically linked (or are supposed to be, at any rate). Can you give me an example where this isn't the case? 03:19:15 <07wizardike> Unforgetting presumes that anything that is only magic mapped will be less accurate than the seen square in the forgotten knowledge so it copies the forgotten knowledge for these squares (I'm not sure if this is ever true or not. Magic mapping might have destroyed some knowledge?). regarding your second point, an example would be when opening a door that has parts of it out of sight. We want to update the player's knowledge to show 03:19:15 the out of sight parts of the door as open but whether we want to let them know its new colour is debatable (we always set the colour to black before this PR which seems very unintentional to me). 03:34:02 <04dracoomega> It doesn't seem clear to me why we'd want to update the tile of a door the player opened and not update its color to match. 03:34:02 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 03:42:26 <07wizardike> The fact that the door has changed from closed to open is something the player already knows but the fact that it might have changed colour isn't. I don't think doors can actually change colour and that's probably the case for all these areas of code that didn't set colour before the PR so this might not matter at all but I'm not sure. 04:29:26 03WizardIke02 07* 0.35-a0-288-g5a097ed5b7: Fix revelation updating seen squares not redrawing 10(9 minutes ago, 1 file, 3+ 0-) 13https://github.com/crawl/crawl/commit/5a097ed5b7b8 06:12:26 03WizardIke02 07* 0.35-a0-289-g9593cc5487: Fix revelation giving less information with map forgotten 10(59 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/9593cc5487d6 06:12:26 03WizardIke02 07* 0.35-a0-290-g6208fce011: Fix unforgetting the map losing terrain knowledge 10(19 minutes ago, 1 file, 14+ 8-) 13https://github.com/crawl/crawl/commit/6208fce01160 06:56:55 03WizardIke02 07https://github.com/crawl/crawl/pull/5208 * 0.35-a0-291-g5d593cae4c: Fix info leaks from feature tile overrides (CrawlOdds) 10(11 hours ago, 27 files, 281+ 79-) 13https://github.com/crawl/crawl/commit/5d593cae4cbe 14:07:01 <11Odds> A bug I understand but don't quite know how to fix elegantly: when you enter a level, autoexclusions get added and then immediately removed (and then added again next turn) This is because add_auto_excludes is called before viewwindow in world_reacts. This means that we don't update map_knowledge until after we add the exclusion, so the exclusion doesn't get the monster name as a description, and so it gets automatically removed by the 14:07:02 code which aims to remove autoexclusions after you kill their monster. The root of the problem feels like it is that the same function updates our map_knowledge and draws stuff. There's a simple fix where autoexclusions take their description from the monster that is actually there, but it would probably be nicer to somehow update our map_knowledge in a more timely way 14:20:37 <11Odds> (This bug brought to you by three separate lair staircases with in-LoS oklobs in my current game) 14:20:59 <04dracoomega> And so they just vanish and then reappear again, basically? 14:21:22 <11Odds> Well you never actually see them on the first turn 14:21:38 <04dracoomega> I mean the exlcusions 14:22:04 <11Odds> Yeah, they don't get rendered on the first turn (they are created and immediately destroyed in the code) 14:22:10 <04dracoomega> I'm genuinely surprised I've not really noticed this happen, myself. Like, I have to have taken stairs into oklobs before. 14:22:34 <11Odds> (Here is an example log - it's the same oklob on the two turns) 14:22:34 <11Odds> https://cdn.discordapp.com/attachments/747522859361894521/1494447936388599828/image.png?ex=69e2a499&is=69e15319&hm=86efe0ad8aa84f916a9ae396d0519ec0a77fb86b1680d4deec1261dfd686829f& 14:22:40 <11Odds> Maybe it's kinda new 14:22:45 <04dracoomega> It does not seem to be happening to me locally 14:23:10 <11Odds> Had you seen the oklob before? 14:23:14 <04dracoomega> Yes 14:23:18 <11Odds> It only happens if the monster is new 14:23:21 <04dracoomega> Oh 14:23:35 <11Odds> (Because your map_knowledge of it not existing is the problem) 14:23:55 <11Odds> This also makes it rather more annoying to replicate 🙂 14:24:00 <04dracoomega> Ah, yes, you're right 14:24:07 <04dracoomega> Well, you realize you can 'unsee' a monster in wizmode, right? 14:24:21 <11Odds> oh right I was trying to unsee the entire stair, which I couldn't 14:24:32 <04dracoomega> (If you use X -> ctrl+X it will forget all monsters on the floor, too) 14:24:35 <11Odds> But now I know what the bug is, I realise I could just have unseen the monsters 14:24:43 <04dracoomega> Well, those not in LoS anyway 14:24:52 <11Odds> (I initially assumed this was something to do with stairs that hadn't been traversed yet) 14:25:00 <04dracoomega> Would have made sense, yeah 15:31:50 Eyesayugh (L27 DjFE) Crash caused by signal #11: Segmentation fault (Crypt:3) 15:31:57 Eyesayugh (L27 DjFE) Crash caused by signal #11: Segmentation fault (Crypt:3) 15:32:04 Eyesayugh (L27 DjFE) Crash caused by signal #11: Segmentation fault (Crypt:3) 15:32:46 Eyesayugh (L27 DjFE) Crash caused by signal #11: Segmentation fault (Crypt:3) 15:32:58 Eyesayugh (L27 DjFE) Crash caused by signal #11: Segmentation fault (Crypt:3) 15:33:07 Eyesayugh (L27 DjFE) Crash caused by signal #11: Segmentation fault (Crypt:3) 15:33:45 Eyesayugh (L27 DjFE) Crash caused by signal #11: Segmentation fault (Crypt:3) 15:34:34 !crashlog Eyesayugh xl=27 djfe place=crypt:3 15:34:37 5. Eyesayugh, XL27 DjFE, T:36957 (milestone): https://crawl.akrasiac.org/rawdata/Eyesayugh/crash-Eyesayugh-20260416-223257.txt 15:43:51 Unstable branch on underhound.eu updated to: 0.35-a0-290-g6208fce011 (34) 15:45:37 <04dracoomega> Doesn't seem like a very helpful crashlog... 15:45:43 <04dracoomega> For something happening so repeatedly 22:36:02 Unstable branch on crawl.develz.org updated to: 0.35-a0-290-g6208fce011 (34) 22:59:43 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-290-g6208fce011 23:13:20 Unstable branch on cbro.berotato.org updated to: 0.35-a0-290-g6208fce011 (34) 23:56:05 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-290-g6208fce011