00:23:06 03WizardIke02 07* 0.35-a0-579-g303dd0adc2: Fix wizmode placed features not using tile variations until reload 10(16 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/303dd0adc290 01:30:10 03CrawlOdds02 07* 0.35-a0-580-ged6722bbcd: Stop ignition firing through walls 10(11 hours ago, 6 files, 140+ 38-) 13https://github.com/crawl/crawl/commit/ed6722bbcdf0 01:57:01 <04dracoomega> @Odds I'm a little confused by C++ // Don't apply a LoS filter like the base class does, as the explosions can // affect things behind walls (when hitting wall monsters). in that commit. Isn't the point that it doesn't do that now? 02:16:34 <11Odds> It can affect some things behind walls, like all explosions 02:17:22 <11Odds> The explosion iterator deals with which 02:17:25 <04dracoomega> ...what things? I thought the entire point of determine_affected_cells() is that explosions didn't pass through walls 02:17:40 <11Odds> They pass sort of around walls 02:18:16 <11Odds> Like LRD with a single wall directly in front of you affects the square behind that wall; the explosion flows through the air from an air tile you can see, I believe is the logic 02:18:50 <04dracoomega> Hmmm 02:19:00 <11Odds> (But with a wall blocking your path it does not affect the tiles behind that wall, and now neither does ignition with wall monsters) 02:19:06 <04dracoomega> So is it basically like: ..*#. @.*O. ..*#. ..*O* @.*#* ...#. 02:19:27 <04dracoomega> I mean, maybe I should have picked something that can stand in a wall and not an ogre 02:19:34 <04dracoomega> For some reason I always use ogres for my example diagrams on instinct 02:19:50 <04dracoomega> Assume there's a wall under them 02:19:51 <11Odds> The unshown air above the ogre in the second diagram is load bearing, but yeah 02:20:00 <04dracoomega> Er, right, yes. That's empty 02:20:04 <04dracoomega> Sorry, extra bad diagram! 02:20:20 <04dracoomega> Okay, yes, that's fair 02:20:52 <11Odds> This is what LRD has done since ancient times, tbh I haven't thought about whether it should and if I were coding the first ever wall explosion it might not 02:21:47 <04dracoomega> Uh... this means that regular LRD targeting is lying, too, apparently 02:21:51 <04dracoomega> Since it doesn't indicate this either 02:21:58 <11Odds> I'm pretty sure it does! 02:22:27 <04dracoomega> https://cdn.discordapp.com/attachments/747522859361894521/1520358642019467307/image.png?ex=6a40e7d3&is=6a3f9653&hm=74ee198d4670097804d252e79244a6e9ef9c8974116374b29ae4ae530d2000c9& 02:22:34 <04dracoomega> But it does hurt the rat 02:22:36 <11Odds> Ah you can't see the rat 02:22:40 <11Odds> Make the wall clear 02:23:12 <04dracoomega> Huh. Well, if you know what the terrain there is, should it not still say it will get hit? 02:23:16 <04dracoomega> Whether you can see it or not 02:23:20 <11Odds> I think it universally does not 02:23:33 <11Odds> (e.g. a fireball would have the same property) 02:23:50 <11Odds> But yes, perhaps 02:23:59 <04dracoomega> https://cdn.discordapp.com/attachments/747522859361894521/1520359023965114488/image.png?ex=6a40e82e&is=6a3f96ae&hm=6c8f5f0da68279cae5f84ce2af49203e841f98044a3e9ff8d7514acff5cc8075& 02:24:13 <04dracoomega> Yeah, like, I know a fireball can hit another space or two there, but it does feel like maybe the UI should say this 02:24:26 <11Odds> Yeah I agree 02:24:47 <04dracoomega> (I do periodically see people surprised explosions hit out of LoS, even though the corner thing is pretty straightforward and useful) 02:24:50 <11Odds> Slightly scared this means a whole bunch of things will have to key off your knowledge 02:25:00 <04dracoomega> And I hadn't considered that the UI wasn't actually teling you this 02:25:07 <04dracoomega> (I am so used to the rules that I never even noticed) 02:25:18 <11Odds> (Hopefully now targetters are aware of this and autotarget in these cases they have another way to learn!) 02:25:46 <04dracoomega> Well, they're not going to autotarget to hit a monster not currently in LoS, I am pretty sure 02:26:01 <11Odds> They are with clear walls 02:26:15 <11Odds> But yeah, you can only learn here with clear walls 02:27:36 <04dracoomega> It can be mildly annoying code-wise when this happens, but there are a decent handful of targeters already that currently have to care about map knowledge, like Airstrike and Gavotte 02:27:47 <04dracoomega> It's at least fairly self-contained 02:31:56 03WizardIke02 07* 0.35-a0-581-g2f966049a6: Fix ruined levels and vaults not respecting FTILE definitions 10(29 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/2f966049a6df 02:33:09 <11Odds> Somewhere between mildlly annoying and incredibly annoying because of the monster/info split. I'm not so sure it will turn out to be easy in this case, but we can see when we try 02:33:35 <04dracoomega> But this specific thing doesn't care about monsters at all, does it? 02:33:39 <04dracoomega> Only terrain knowledge 02:33:51 <04dracoomega> (Which is far less fiddly) 02:34:09 <11Odds> Many separate targetters might be reading monster properties to determine whether they should highlight a square and now they should instead read monsterinfo properties so they can correctly highlight out-of-LoS squares 02:34:27 <11Odds> (Because they should assume whatever you thought was there, is still there) 02:34:33 <04dracoomega> I... think none of these regular explosion targeters do? 02:34:48 <04dracoomega> Regular beam stuff doesn't, anyway 02:34:54 <11Odds> Yeah, maybe it will all turn out to be fine 02:35:40 <11Odds> Some of them look at features, but those are easy enough to make go off map knowledge 02:35:52 <04dracoomega> (I still want to remove monster_info entirely at some point. I gave serious consideration to doing that before my invis rework here, but concluded that it would take multiple extra weeks of work for no player-facing benefit and so I should probably defer it again, given the other stuff on my to-do list. But there's been times it's complicated this work also, as I knew it would.) 02:36:32 <11Odds> Remove it and have map_knowledge have a monster in it? 02:36:43 <04dracoomega> Yeah, basically make a snapshot of the monster at that point 02:37:17 <11Odds> I guess monster info does two things though - gives you a snapshot and declares the interface for "things the player knows about a monster", and we'll lose the latter? 02:37:17 <04dracoomega> There's a ton of problems that come from partially duplicating many dozens of different queries for both object types (and then not always doing them the same way....) 02:37:44 <04dracoomega> Well, the UI code already has full control over what it chooses to the tell the player (and already in many times tries to pull up the real monster because it's impractical to query something off the monster_info) 02:38:11 <11Odds> Yeah, the nice guarantees of monster_info are substantially weakened because it's so painful we often just go around them 🙂 02:38:22 <04dracoomega> Like, in theory it's supposed to be a monster whose info is always safe for the player to know, but it's not like said information leaps to the screen without us telling the game to print it 02:39:07 <04dracoomega> (There are layers of it, like converting status effects to printable messages, but that doesn't require a completely different base class, imo) 02:39:29 <11Odds> Yes indeed; it does mean that we have to be more cautious about info leaks now the abstraction of "this is what the player knows" is gone 02:39:37 <11Odds> But overall I fully agree it's the right thing to do 02:39:51 <04dracoomega> I feel that abstraction has been so leaky for years that it's not actually doing much 02:40:05 <04dracoomega> Look at how often we end up leaking invis-related info in targeters 02:40:21 <11Odds> We always do that when we route around the abstraction, though 02:40:47 <11Odds> (Did you find a Wu wall jump leak in your invisibility quest? If not I'll fix it separately) 02:41:12 <04dracoomega> One key complexity in ripping all this out is that monsters don't own their own equipment (it's just index references to the floor item array), while monster_info currently does own its equipment (as unique_pt) since otherwise you can't snapshot anything independently of monster gear changes. 02:41:42 <04dracoomega> So monsters would need to start owning their equipment too (which would simplify level changes also, though) 02:41:58 <04dracoomega> Which is a whole other class of recurring bug 02:42:36 <04dracoomega> Maybe, but there's just so much state and important ways to query monster properties that I can't imagine 'duplicate most of this' is every the right principle to avoid leaks 02:42:37 <11Odds> Yeah monsters owning their equipment seems the right thing regardless, though obviously a significant change 02:43:00 <04dracoomega> The thing is, if we stored actual monster snapshots in env_knowledge(), we really could just query those and easily have 'what the player knows' available 02:43:02 <11Odds> (Yeah we do just agree on all this I think) 02:43:17 <04dracoomega> We're only checking 'real' information because it's impractice to query from knowledge 02:43:56 <04dracoomega> (It is always possible we could have a 'construct sanitized monster from another monster' that just selectively removes a few things we don't want, too) 02:44:04 <04dracoomega> When storing in map_knowledge 02:44:27 <04dracoomega> Not sure how much that would be needed, in practice, but it's a better option if there are things we do, I believe 02:44:44 <11Odds> Yeah there must be nicer ways to partially enforce this split at the monster level 02:44:55 <11Odds> And as you say, they may or may not be worth it 02:45:05 <04dracoomega> Also I had not noticed anything related to Wall Jump, but I'll take a look (since it might want fixing in a different way now) 02:45:31 <04dracoomega> Is it that you can tell if there's a monster at your landing spot? 02:45:35 <11Odds> Cool, it's a very simple one where if theres an invisible monster in the destination the targetter tells you 02:46:07 <04dracoomega> I can't help but wonder at it just shoving the monster out of the way instead of surprisingly failing. (Wall Jump is already pretty niche as-is) 02:46:16 <11Odds> I was going to have it fail without cost 02:46:26 <11Odds> And without turns 02:46:38 <04dracoomega> Er, isn't that leaking just as much? 02:46:54 <11Odds> No, because if the monster isn't there it has a cost 02:47:21 <04dracoomega> (Well, for better or worse, the policy for almost all spells that fail at an invisible monster deliberately have you pay the normal cost if you aim at nothing) 02:47:33 <04dracoomega> To keep from being able to check 'for free' in any circumstance 02:47:59 <11Odds> I guess I think gods are kinder than spells in this regard 02:48:22 <04dracoomega> (It turns out that Heal Other does also leak some info about invisible monsters this way at present, too, though) 02:48:29 <04dracoomega> With a very silly message 02:49:19 <11Odds> Ah the targetter says you'll heal something? 02:50:12 <04dracoomega> No, but if you aim at an invisible monster that is too strong for you, it says "Something would be completely unfazed by your meagre offer of peace." and takes no time 02:50:31 <04dracoomega> But it seems that Heal Other does take time/piety for whiffing on empty spaces 02:50:37 <04dracoomega> C++ monster* mons = monster_at(spd.target); if (!mons) { fail_check(); canned_msg(MSG_NOTHING_THERE); // This isn't a cancel, to avoid leaking invisible monster // locations. return spret::success; } 02:51:42 <04dracoomega> Like, I think we're quite consistent about this behavior. If you are allowed to aim at empty spaces and it turns out your guess was wrong, you pay full costs. 02:52:18 <04dracoomega> (Honestly, Wall Jump feels so situational that I can't help but wonder if 'push monster out of the landing space' would be sensible behavior to do all of the time) 02:52:33 <11Odds> Oooh 02:52:52 <11Odds> Of course you have to reckon with cases like there being nowhere to push it still 02:53:19 <04dracoomega> I feel like scenarios where there's an invisible monster at the destination and nowhere to push them that I would no longer feel concerned about it whiffing 02:53:28 <04dracoomega> And it could potentially be more relevant in more situations in general 02:53:47 <11Odds> I do think whiffing is fine for an ability which expects to target empty space 02:54:19 <11Odds> Oh sorry I mean free cancellation is fine, not whiffing 02:55:13 <11Odds> Heal other is whiffing because you targetted empty space when you should have targetted a monster, it's very much your fault. Is there an analogy for a spell/ability where targetting empty space is legal? I guess ballistos 02:56:01 <04dracoomega> Prism also 02:56:15 <11Odds> Ballistos make you pay the costs 02:56:28 <11Odds> So yeah I guess wall jump should also. 02:56:34 <04dracoomega> Prisms, too. Like I said, I think everything does (or that it would be considered a bug if something did not) 02:56:38 <11Odds> (Or it should push, that seems fine) 02:57:05 <11Odds> Right, I did wonder if gods did this differently. Like, flavourwise your god might go "nah, that won't work" rather than make you pay. 02:57:23 <04dracoomega> Not that I'm aware of 02:57:48 <11Odds> Yeah, ballisto is exactly equivalent so I guess there's no such exception 02:58:42 <04dracoomega> Paragon forcibly blinks away an unseen monster under where you summon it specifically because I felt like a level 9 spell shouldn't whiff over something so minor >.> 02:59:57 <04dracoomega> (Post invis-rework, it has to be unseen and without the player being aware of it, which is basically "This should only be able to happen when you can't tell that it happened" ^^; ) 03:09:13 03CrawlOdds02 07* 0.35-a0-582-g1019eb3f1f: Fix angering tentacle segments 10(74 minutes ago, 3 files, 12+ 21-) 13https://github.com/crawl/crawl/commit/1019eb3f1ffa 03:09:30 <11Odds> Places we will never run out of bugs: targetters, tentacles, terrain change. Maybe the letter t is really the problem here. 03:10:03 <04dracoomega> Hey, tentacles are ω 😛 03:10:39 <11Odds> I still can't remotely read console maps 🙂 03:11:58 <04dracoomega> I am obviously not nearly as quick at reading them as with tiles (frankly, I wonder if even experienced console players can read them as fast as an experienced tiles player can read tiles?), but I do wonder if having been around back when most of the games one could spectate were console gives at least a little fluency 03:12:16 <04dracoomega> (Correct me if I'm wrong, but you were around pre-webtiles, right? ^^; ) 03:12:58 <11Odds> Indeed I wasn't 03:13:02 <11Odds> !lg Odds 1 03:13:05 <04Cerebot> 1/819. Odds the Grave Robber (L6 DDNe), blasted by Pikel (wand of lightning) on D:3 on 2015-02-01 15:09:42, with 445 points after 3167 turns and 0:23:05. 03:13:17 <04dracoomega> Oh, further back than I thought, nonetheless 03:13:25 <11Odds> Annoyingly not actually my first online account, I've forgotten the name of that one. But within a year or two. 03:14:01 <04dracoomega> That's still like... ~0.15-ish, apparently 03:14:33 <04dracoomega> So more or less just after I left 03:14:44 <11Odds> Yeah took me some years to find the community 03:15:39 <11Odds> So even if console was still a big deal at that point, I wouldn't have been immersed in it 03:19:05 <11Odds> If you have a dopey mutation, and Ru grants you another one, it should probably get worse rather than just become permanent, right? 03:19:39 <11Odds> Currently the preview expects you to go to dopey 2, but you actually just go to permanent dopey 1 03:20:41 <04dracoomega> I think that behavior is basically how demonspawn work when species and normal mutations interact 03:20:59 <04dracoomega> Like, if you were slated to get robust 1 and already have robust 1, it just becomes permanent 03:21:10 <11Odds> Yeah, I guess it seems right for DS and wrong for Ru 03:21:14 <04dracoomega> Rather than getting 1 pemanent level and keeping one normal level on top 03:21:52 <04dracoomega> (What part of the preview expects you to get Dopey 2? Like, it says 'If you take this, your int will decrease by 6' or something?) 03:22:07 <11Odds> https://cdn.discordapp.com/attachments/747522859361894521/1520373657426329743/image.png?ex=6a40f5cf&is=6a3fa44f&hm=469c0e0cef8fa73a06e2f1aebb448204f342a0b7c5499374a5e36c9b91534934& 03:22:19 <11Odds> (This is taking me from Int -3 to Int -3) 03:22:24 <04dracoomega> Okay, well some part of that is incorrect, at the very least 03:22:36 <11Odds> We could just fix the preview 03:22:46 <04dracoomega> I am not entirely sure which stacking behavior I would consider correct, but it should at least report what will actually happen 03:22:50 <11Odds> And make this a nice bonus for bad mutations. There is still some sacrifice here 03:22:57 <04dracoomega> Yeah, you can't fix it 03:23:36 <04dracoomega> (It might be easier to just fix the preview than adjusting stacking behavior - especially since that only works if you're below the cap. At some point there's no more levels to give and it has to just make it permanent) 03:23:40 <11Odds> Yeah I'll just keep the behaviour and fix the preview without making any attempt to spell out that it's becoming more permanent 03:30:41 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 03:50:44 03CrawlOdds02 07* 0.35-a0-583-ge6ce6fa2a5: Fix the preview of a Ru mutation 10(19 minutes ago, 4 files, 5+ 5-) 13https://github.com/crawl/crawl/commit/e6ce6fa2a536 05:21:14 03WizardIke02 07* 0.35-a0-584-g7029c44831: Fix Gozag shops sometimes looking like walls 10(10 minutes ago, 1 file, 1+ 2-) 13https://github.com/crawl/crawl/commit/7029c448310c 07:35:11 <11Odds> More teleport closet stuff: at the moment we try to preserve vault stairs, but if there are more than three we start deleting them (this happens quite a lot). But some vaults rely on their stairs to avoid being teleport closets, so this is unsafe (nicolae_overflow_hidden_temple is an example) I wonder if the right thing is to add a vault tag which means we really must preserve stairs, and if there are more than 3 stairs in such vaults 07:35:12 we just veto the level 07:41:51 <04dracoomega> Does... removing all stairs or other connectivity from a vault not already cause a veto? >.> 07:42:06 <04dracoomega> (I am not saying I am familiar enough with the code to say that it does, but rather it seems like it ought to) 07:42:19 <11Odds> No, because the vault is opaque to the connectivity algorithm 🎉 07:42:31 <11Odds> The "entrance" of this vault is outside the closet 07:43:18 <11Odds> (Which makes sense, that's the place the player needs to be able to get to so that they see the vault) 07:43:50 <11Odds> Here's that particular instance: MAP xxxxxxxxxxxxx xxxxaxxxbxxxx xxG...G...Gxx mm.........mm @m}.........cm@ mm.........mm xxG...G...Gxx xxxxexxxdxxxx xxxxxxxxxxxxx ENDMAP 07:43:52 <04dracoomega> I know that at some point there is a flood-fill algorithm that tries to determine how many different 'areas' exist. Are you saying that this universally considers vaults opaque/irrelevant for this purpose? I would have thought that it operated on the final map 07:44:15 <11Odds> Yes, it considers vaults opaque except their entrances; vaults get connected because their entrances do 07:44:22 <04dracoomega> Hrmmm 07:45:09 <04dracoomega> (Is... there any non-performance reason that it ought to, I wonder?) 07:45:15 <11Odds> This allows vaults to be disconnected in unusual ways they've thought hard about - a vault's contract is "if the entrance is accessible the vault makes sense" (as I understand it) 07:45:34 <11Odds> E.g. maybe they've given you the enlightenment you need to escape their clutches? 07:45:39 <04dracoomega> Like, this pathfinding already accounts for transporter connectivity 07:45:55 <04dracoomega> Or some stage of it does, since I did that myself 07:46:08 <04dracoomega> To keep it from vetoing things with branch entrances only accessible via transporteer 07:46:23 <04dracoomega> Which is on the inside of a vault 07:46:32 <04dracoomega> (Maybe that's a completely different validation step, though) 07:46:35 <06regret-⸸nde※> While tags could hypothetically help here, vaults can heavily randomize for both upstairs and downstairs, and it'd take a lot of conditional lua to comprehensively get the whole field- I'd rather it be done by parsing if the vault contains stairs post-creation first?.... 07:47:08 <04dracoomega> Yeah, tagging does seem very error-prone 07:48:12 <11Odds> I'm not sure I understand - this is about whether it's safe to remove stairs from a vault (which it often is and we do it a lot) 07:48:41 <11Odds> Parsing whether the vault contains stairs wouldn't help us tell if it's safe to remove those stairs 07:49:51 <04dracoomega> I suppose there's a whole category 'stuff behind glass' this touches on... 07:50:20 <11Odds> Right.... I'd be scared to make connectivity go into vaults as there are a lot of vaults and it's hard to know how they are relying on the current setup 07:50:40 <04dracoomega> (But those should always always have NO_TELE_INTO. So I wonder if it's possible to consider NO_TELE_INTO spaces inside vaults opaque for this purpose, but try to ensure stair connectivity for any other bits?) 07:51:14 <06regret-⸸nde※> Wasn't there some efforts to make transparent a default a few years back? 07:51:24 <11Odds> This would be fine but I'd still not be at all confident vaults are all setting NO_TELE_INTO in these cases. Maybe they know you can't get in because it's full of monsters! 07:51:24 <04dracoomega> Like, there should be no deliberately-disconnected sections lacking this, right? 07:51:49 <04dracoomega> Well, I'd usually consider that a bug. We, in fact, fix such bugs somewhat regularly, so it might be nice if the game shouted at us about their presence before someone teleports in 07:52:08 <04dracoomega> Instead of usually afterward 07:52:13 <11Odds> Not at all sure. Dig for victory seems like it might be OK to teleport into? 07:52:53 <11Odds> The failure mode here is that we ban a lot of perfectly respectable vaults, which I guess we can measure through mapstat 07:52:57 <04dracoomega> (It's already tagged no_tele_into, isn't it?) 07:53:11 <04dracoomega> It sure looks like it 07:53:42 <11Odds> Would it be a bug if it wasn't? I guess so, because the player could get stuck in there if they dropped the digging wand and reentered 07:53:44 <06regret-⸸nde※> Monsters could be recalled out of their spots before they're dug out, yes. 07:54:04 <04dracoomega> Yeah, like I understand the reluctant here, and I don't want to sound flippant. But it just seems like it might be possible to essentially future-proof more teleport closet things by doing something like this, and that feels valuable to me 07:54:48 <11Odds> Yeah seems worth measuring the blast radius of this with mapstat 07:54:49 <04dracoomega> And if it's possible to get a safer and more reliable future state, I think that's often worth potentially mixing something up in the meantime (since we can test for this) 07:54:50 <06regret-⸸nde※> I already wanted to do some clean-up (though some boilerplate crunching functions) on glass closets nobody's supposed to teleport into, anyway. 07:57:19 <11Odds> Oh right yes, this change looks like flipping the default of this for vaults 07:58:22 <11Odds> And if we don't do that, we can still fix individual vaults by makign them transparent rather than having any new tag 08:07:40 <11Odds> (For clarity, I'll do this and report back, will be interested to see the kinds of vaults that get sad)