00:13:19 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1932-gab3808680d (34) 04:32:51 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:09:59 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1932-gab38086 (34) 13:23:36 <11O​dds> @dracoomega a fun bug reported by Flugkiller which I've diagnosed but am not fixing. If you cast crocodile in a way that creates shallow water where the player is going, it won't break ozo's armour (among other things). This is because the terrain change in crocodile calls trigger_movement_effects on the player (via _dgn_check_terrain_player). This then resets the deferred movement tracking, so that when we call finalize_movement in the 13:23:36 crocodile spell proper, it thinks we've not moved. Perhaps one fix is to move the finalize_movement in the crocodile spell before the terrain change, or perhaps you want to refactor everything about terrain. 15:29:16 <04d​racoomega> Oh dear 15:30:32 <09g​ammafunk> good ozo tech 15:30:38 <04d​racoomega> I mean, the whole system is built on the assumption that finalise_movement() will always be called before a different source of moving an actor can interpose itself. Which, well, should probably always be true, but this specific case is a bit awkward 15:31:46 <04d​racoomega> Will have to mull over whether a more general safeguard is possible, or whether 'changing the terrain under a player' is just to be considered an unsafe operation while mid-move 15:49:35 -!- meatpath1 is now known as meatpath 15:58:16 <04d​racoomega> On a different note, I discovered something while doing this ranged attack refactoring that is making me frown a bunch. So, firing a ranged projectile - in and of itself, and regardless of where it is aimed - alerts all non-sleeping monsters in LoS to your position. I wasn't actually aware of this behavior and was questioning how important it was, as I rewrote this. But then I realized that actually a lot of places make this same 15:58:16 function call. It completely ignores both noise and stealth, causing even silent actions to instantly alert all wandering monsters in LoS, no matter their distance. This is called by a large number of different actions the player can perform, but importantly: not all of them. Casting spells, zapping wands, firing ranged attacks, landing melee hits, and performing aux attacks do this. But using abilities, evokers, or scrolls does not. (This also means 15:58:16 that casting Silence auto-alerts distant monsters, while reading ?silence doesn't...) This happens even for explicitly silent spells! (It even happens while you're invisible, kind of. You still do alert all monsters, even from casting a silent spell while invisible. Being invisible, they still don't properly lock onto your exact position, though they do try. However, this results in a different weirdness in that they will keep shouting every time 15:58:16 you do this, since they were alerted, but still can't see you. So casting silent spells while invisible causes nearby monsters to make a ton of noise every time you do so.) 15:58:17 <04d​racoomega> Quite frankly, I think this is nonsense. We already have both a noise and a stealth system that is intended to cover most of this sort of behavior. This code dates almost entirely to Initial Revision (where it should be noted that the modern noise system did not yet even exist and noise just forcibly alerted within a given radius, even through thick walls.) Removing it would be a moderate player buff, especially to stealthy 15:58:18 characters. I am not sure the precise magnitude of this buff, but it would make a lot more 'sense' to me to not work this way and instead to rely on the noise+stealth systems we have. (It could possibly also be accompanied by a slight increase to the perception score of wandering monsters, if needed.) 16:00:57 <09h​ellmonk> that is uh, concerning\ 16:01:01 <12g​e0ff> yeah, i always found it strange that casting even the most silent spell alarts every awake monster nearby 16:01:32 <04d​racoomega> In past, I had more or less chaulked it up to failing stealth rolls, but seemingly not! 16:02:37 <09h​ellmonk> I would agree with trying to fold this into the existing stealth + noise system, but I do think we'd actually want to be a bit careful about balancing it 16:03:44 <09h​ellmonk> the implications seem rather large for something like attempting to melee a wandering monster with other wandering monsters onscreen (something you might do while stabbing, for example) 16:04:53 <04d​racoomega> Stab attempts don't do this, for the record 16:05:27 <09h​ellmonk> what about if the roll for a stab attempt fails 16:05:30 <04d​racoomega> (For some reason, the alert on melee hits is done via attack::player_stab inside calc_damage() >.>) 16:05:47 <04d​racoomega> A strange side-effect to calculating damage 16:06:23 <04d​racoomega> Yes, it has to be actual stabs, it seems 16:07:36 <09h​ellmonk> I guess the original idea is the monsters all saw something happen, so are alerted, but I think it's a behavior that few people know about and doesn't really make sense compared to normal stealth check and noise behavior 16:07:39 <04d​racoomega> I mean, it's worth keeping in mind that doing real damage with melee attacks does also make noise 16:08:08 <04d​racoomega> And it 'makes some sense' that a stealthy character fighting something on the other side of LoS might not alert distant things automatically 16:08:38 <09h​ellmonk> I forget, do we show alert chance in game yet 16:08:44 <04d​racoomega> (I realize this is a buff to stealth characters of a moderate-but-probably-meaningful magnitude. It feels a little hard to say precisely how much without actual playtesting.) 16:08:58 <04d​racoomega> I don't think we do 16:09:10 <09h​ellmonk> might be nice to add, would it be alright to table this until next version? 16:09:47 <04d​racoomega> I mean... we could. But do you think it's enough of a balance concern that having a month to tweak the numbers is insufficient? 16:10:02 <09h​ellmonk> oh, do we still have a month? 16:10:02 <09h​ellmonk> probably fine 16:10:29 <09h​ellmonk> I think raising monster perception a bit is sufficient to compensate 16:10:49 <04d​racoomega> This specifically only affects non-sleeping monsters, so I'd put any change to it there 16:11:09 <04d​racoomega> (I guess we could try to add the perception chance to a monster when xving it?) 16:11:20 <09h​ellmonk> yeah, I think that change wouldn't be too hard 16:11:27 <09h​ellmonk> I can submit a pr for it 16:12:03 <09h​ellmonk> probably the wandering perception chance should just scale with hd in some way / have a multiplicative component 16:12:16 <04d​racoomega> Wandering monsters already get higher perception 16:12:24 <04d​racoomega> It could just be by a bit more 16:12:27 <09h​ellmonk> yeah but it's flat, right? 16:12:33 <04d​racoomega> Oh, it might be, yeah 16:12:41 <09h​ellmonk> I think it's a flat +15 or something 16:13:01 <04d​racoomega> Sounds about right, by memory 16:13:28 <09h​ellmonk> monster perception also scales with hd already, but not very well 16:13:41 <09h​ellmonk> max perception is like roughly 75-80 iirc 16:13:46 <09h​ellmonk> for wandering orb of fire 16:17:08 <04d​racoomega> I mean, is there some reason you don't think that's high enough? 16:17:45 <09h​ellmonk> no, I'm commenting that it doesn't scale very much 16:17:49 <04d​racoomega> Ah, okay 16:18:37 <09h​ellmonk> most of the lategame limitations with stealth are monster density related (having to make many stealth checks is unreliable) rather than perception number related 16:18:57 <04d​racoomega> Stealth-focused gameplay feels like it already struggles a bunch later in the game due to monster group sizes due to the whole 'Only one monster needs to see you to wake everyone up'. Obviously this change would improve that somewhat, by making you more able to do things while monsters haven't quite found you yet. Unclear the exact magnitude of the effect. Obviously we don't want stealth to be too good, but I think there is 16:18:58 some legit value in being able to remain undetected longer through explicitly using quiet things carefully. 16:19:42 <09h​ellmonk> I think this will be a pretty big buff to invis, but invis is limited these days so should be fine 16:19:42 <04d​racoomega> Since most characters aren't really doing that at that point 16:19:57 <09h​ellmonk> (for all practical purposes, monster perception is 5 if you're invis and they don't see invisible) 16:20:46 <09h​ellmonk> or is it 4 16:20:46 <09h​ellmonk> whatever the minimum value is 16:21:15 <09h​ellmonk> invis subtracts 75 from monster perception, but monster perception is basically always less than 75 to begin with 16:21:35 <04d​racoomega> Huh 16:22:24 <04d​racoomega> It will certainly make monsters less noisy while you're invisible, which does have knock-on effects. 16:25:06 <04d​racoomega> In any event, it feels like a much better starting-point of stealth balance to not have these mostly-unknown autoalerts in a bunch of places 16:25:23 <04d​racoomega> And tweak from there 16:25:28 <09h​ellmonk> this is the first time I have heard anyone mention them tbh 16:25:36 <09h​ellmonk> in uh, 10 years in this community 16:25:54 <09h​ellmonk> there's probably someone who knew about them, but they're definitely one of those weird / obscure mechanics 16:26:13 <04d​racoomega> Yeah, somehow I hadn't noticed either 16:26:21 <04d​racoomega> Until I had to rewrite a function calling this 16:26:30 <04d​racoomega> And was like "...wait a second." 16:27:12 <09h​ellmonk> I suppose it's rather unusual to take one of those actions with a wandering monster onscreen while intending to retain stealth 16:27:55 <09h​ellmonk> I guess the other thing we have to worry about is making sure the actual target of the action is alerted properly, since I assume that is working as intended (but maybe that's an entirely different code path) 16:31:04 <04d​racoomega> We do have periodic bugs there, but basically if that wasn't working, then it wouldn't wake them if they were asleep either 16:31:08 <04d​racoomega> Which is a lot easier to notice 16:31:48 <04d​racoomega> Which is an independent class of bug that this wouldn't band-aid over in the first place 16:33:24 <04d​racoomega> Since alert_nearby_monsters() can never affect sleeping monsters at all 16:41:00 Unstable branch on underhound.eu updated to: 0.34-a0-1932-gab3808680d (34) 16:42:38 <04d​racoomega> Feel free to work on this, if you want, by the way. It's probably going to take me at least another day of work to finish up this ranged attack refactoring. And then I'll make the monster alert change and push that and a couple other things to trunk. Anemocentaurs might get deferred to the start of 0.35 now. I need to make a list of the remaining 'high priority' adjustments I wanted to get into 0.34 before we freeze, and it 16:42:38 wouldn't surprise me if they take up most of the 2-3 weeks. I'll have a better idea once I've reviewed things. 16:43:05 <09h​ellmonk> yeah, I can try to do it tonight or tomorrow 16:43:13 <09h​ellmonk> shouldn't be terribly hard 16:43:44 <04d​racoomega> Sure 20:40:09 -!- wvc4 is now known as wvc 20:50:41 -!- wvc4 is now known as wvc 22:11:51 New branch created: pull/5010 (1 commit) 13https://github.com/crawl/crawl/pull/5010 22:11:52 03yrdzrfxndfvh02 07https://github.com/crawl/crawl/pull/5010 * 0.34-a0-1933-gf3084839b0: Small batch of (mostly slime) vaults 10(18 minutes ago, 3 files, 263+ 0-) 13https://github.com/crawl/crawl/commit/f3084839b039