00:02:05 03noncinque02 {GitHub} 07https://github.com/crawl/crawl/pull/5317 * 0.35-a0-779-gcd6e02a034: Update branches.txt 10(61 seconds ago, 1 file, 9+ 9-) 13https://github.com/crawl/crawl/commit/cd6e02a03489 01:25:21 03CrawlOdds02 07* 0.35-a0-708-gb16d0a8e14: Fix unique annotations on taking stairs 10(30 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/b16d0a8e1455 03:33:23 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 09:24:52 <11Odds> @dracoomega - I had a recurrence of that monster invisibility bug - I teleported away from an unseen horror and the game thought it was near me (e.g. didn't let me autoexplore). I think what's happening is: - There's an unseen horror with a known position - I teleport away - The unseen horror moves. invis_monster_knowledge::update is called in finalise_movement, and sets my new position for last_player_pos I don't yet understand why we 09:24:53 need this finalise_movement update - should this monster not already have a last known position, if we've sensed it? 11:23:47 <11Odds> Is it deliberate that Nemelex's cloud card can put damaging clouds (e.g. miasma) directly on the player? Seems quite mean (I just got a nasty shock from some miasma) 12:09:50 <04dracoomega> I wish I could remember now what it was, but at one point in refactoring the invis system, I did remove that update in finalise_movement() under the assumption that its last known position would already be registered at the correct location beforhand, and there was some good reason I put it back. (There were certain specific circumstances where it wouldn't leave a memory behind properly otherwise, though I'm having trouble 12:09:51 recalling which >.>) Really, the issue here is that while moving out of its previous location is 'known' information, it ends of being (maybe the only case of?) getting said information while you're potentially far away from the monster, which makes the danger tracking weird here. Not immediately sure the best solution, but maybe something about not updating player pos if their real location isn't in LoS at all? Just wondering if there's other 12:09:51 circumstances this leaks things it shouldn't... 12:10:59 <04dracoomega> It is. (It fully surrounds monsters, which means you're always unsafe if standing next to a monster at the time. But you do get a turn of immunity to the clouds for the player to do something about standing in it) 12:12:19 <04dracoomega> (Nemelex has fairly few double-edged/risky cards left at this point, but I kind of feel it's thematically appropriate for the gambler god to have some of that. Wouldn't mind a few more, whenever I get to those planned card edits, so long as the overall results are adequate.) 12:13:57 <11Odds> Yeah, I guess Nem is kind of allowed to be mean like this... though this did feel especially nasty 12:19:25 <11Odds> On the invis thing - I think it somewhat depends what the reason is for this call... the natural thing to do would be not to call update here at all (we shouldn't get information when we are far away) - but if we need it we could have this particular update not set player location, because the player's current location could have changed in all sorts of ways since they actually knew where the monster was. 12:21:37 <04dracoomega> I think I'd like to mull this one over a little and see if I can reidentify what the actual problem was 12:21:58 <04dracoomega> Since it's possible that will present a better method of fixing it 12:22:24 <04dracoomega> (It's probably the player location storage didn't even exist when I put that back in. The backend changed meaningfully multiple times during development.) 12:22:31 <11Odds> Yeah, definitely seems like a good idea 12:50:03 <04dracoomega> Guided by my own method comment, I immediately found at least one scenario where, without that line in finalise_movement(), a memory does not get properly left behind. Though it probably represents a different bug. (If a known-invis monster follows you across floors, you will still know its current location on the new floor when you arrive there, but it won't leave a memory behind when it moves. But probably you're not supposed to 12:50:04 maintain knowledge of its location when it takes stairs, either) 12:56:31 <11Odds> (Yeah seems like we should clear that flag when placing on the new floor) 13:17:43 <04dracoomega> Wondering if there might be a bit of info leak weirdness with monster phantom mirror, if it targets a known-invisible monster. Currently, the clone inherits the MF_KNOWN_INVIS flag, but will have no information logged in invis_knowledge. Which means if the code in finalise_movement() was not there, the fake one would fail to leave a memory behind. But if it doesn't inherit MF_KNOWN_INVIS, we immediately know which is which (since 13:17:43 we can only see the real one). Possibly we should remove MF_KNOWN_INVIS on that sort of shuffling, except the player does know that some monster is at that spot (just not which one). I was considering having even MV_INTERNAL movements erase MF_KNOWN_INVIS, which might remove some of the need of the call in finalise_movement(), though it's the sort of thing that typically should be reserved for there - ie: movement 'side-effects'. Just wondering if 13:17:44 there might be cases this is incorrect behavior. 13:19:44 <04dracoomega> It feels like this might be the best way to ensure things are in sync, but I don't feel completely confident 13:20:39 <11Odds> Or the clone should get logged on create with a state equivalent to the original? 13:20:55 <11Odds> (So for known monsters, log their actual locations) 13:21:04 <04dracoomega> Well, phantom mirror probably needs bespoke handling independent of any change to when MF_KNOWN_INVIS is removed 13:21:18 <04dracoomega> Which shouldn't be too hard 13:22:30 <11Odds> I wonder if the known position and MF_KNOWN_INVIS could somehow be better coupled. It's currently somewhat hard to reason about how they get out of sync 13:22:54 <04dracoomega> Is it? 13:24:47 <11Odds> Well, what we're talking about here is various cases where the flag is set but we the position isn't up to date, because these are why the finalise_movement update exists 13:25:45 <11Odds> I'm not sure what it means for a monster to have MF_KNOWN_INVIS and the last_known_pos not be equal to their current position 13:26:43 <04dracoomega> Basically, if MF_KNOWN_INVIS is true, the other logged information isn't needed or consulted 13:27:07 <04dracoomega> The flag makes you.aware_of(mons) return true 13:28:38 <11Odds> Ahhh, thanks that makes a lot of sense 13:29:11 <04dracoomega> So it's only when the monster loses that flag that the backend tracking needs to be correct (which is why it is, in fact, set at that point currently) 13:29:32 <11Odds> Yep, finalise_movement actually could be the only the place we set the position 13:31:58 <11Odds> (So that update now makes loads of sense to me, but it still seems like it shouldn't be settign the player position - that should be for when we sense the monster, not for when we become uncertain about where it is) 13:34:42 <04dracoomega> Yeah 13:35:03 <04dracoomega> This may be the only case of invis_knowledge.update() that is for losing information instead of gaining it, yes 13:35:15 <04dracoomega> So perhaps it just shouldn't update that bit here 13:39:22 <11Odds> Yeah. Not sure whether it's then tidier to split the function up, as it feels like it's a few different functions with the branching now 13:41:04 <04dracoomega> Well, somewhat conveniently, the forced_pos is only used at this point, so probably that can condition not setting player position memory? 13:41:44 <04dracoomega> Not sure about splitting it into multiple functions, as there's some common bookkeeping, even here 13:42:10 <11Odds> Makes sense you definitely know this better than m1 15:42:41 Unstable branch on underhound.eu updated to: 0.35-a0-708-gb16d0a8e14 (34) 19:02:11 <08nicolae> time to bring back all the cards 19:02:34 probably some fork already has 19:05:21 <08nicolae> we need to implement slay the spire in nemelex somehow 19:08:50 geekosaur: not _all_ of them but a rather wider selection than before (and decks for everyone but Nem doesn't eat all your inventory space) 22:36:01 Unstable branch on crawl.develz.org updated to: 0.35-a0-708-gb16d0a8e14 (34) 22:59:53 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-708-gb16d0a8e14 23:12:17 Unstable branch on cbro.berotato.org updated to: 0.35-a0-708-gb16d0a8e14 (34) 23:56:18 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-708-gb16d0a8e14 23:58:42 03CrawlOdds02 07* 0.35-a0-709-gc827c1b0b7: Wipe forgotten map in wizmode forget 10(33 minutes ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/c827c1b0b776 23:58:42 03CrawlOdds02 07* 0.35-a0-710-gaf292bbb4c: Fix a message calling a hatch a portal 10(7 hours ago, 2 files, 18+ 10-) 13https://github.com/crawl/crawl/commit/af292bbb4cca