03:34:16 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 03:43:56 -!- The topic of #crawl-dev is: Crawl Development | https://github.com/crawl/crawl | Logs: http://s-z.org/crawl-dev/, temporarily http://crawl.akrasiac.org/logs/cheibriados/ | People with +v have commit access, devs on bridged discord as well | General Crawl-related chat to #crawl | Long stuff to a pastebin service, please 11:50:10 <11Odds> Eringya's surprising crocodile should break ozocobu's armour in all cases, right? 11:51:47 <11Odds> (It currently doesn't if the player ends up in shallow water that wasn't there before) 11:52:42 <12ge0ff> this doesn't really look like an intentional behavior 11:52:57 <11Odds> Yeah, I agree - more checking that the intent wasn't "never break armour" 11:53:18 <11Odds> (What's happening codewise is that the terrain change is clearing the deferred move by triggering movement effects) 12:24:43 New branch created: pull/5200 (1 commit) 13https://github.com/crawl/crawl/pull/5200 12:24:44 03CrawlOdds02 07https://github.com/crawl/crawl/pull/5200 * 0.35-a0-269-g00eaeb8610: Fix Eringya's Surprising Crocodile movement effects 10(16 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/00eaeb86109f 12:29:10 The surprising surprising crocodile surprise 12:33:35 <11Odds> Mostly noticed it because I added a warning for riding crocodiles into traps, which also warns you are breaking your armour. Including when you aren't. 12:34:13 <11Odds> (Not completely sure this is the right fix, but I couldn't see a more elegant way and at worst this is a glorified bug report) 13:16:00 <090x2d> I started vibe coding with claude this morning. the results are surprising. 13:16:00 <090x2d> https://cdn.discordapp.com/attachments/747522859361894521/1492981633102512418/Screenshot_2026-04-12_at_4.15.50_PM.png?ex=69dd4eff&is=69dbfd7f&hm=c4de46f2e1aa5518d46cffc515d61acff731b34ff2b332d3ab9d120f0162cdd7& 13:16:08 <090x2d> @doc_eon get a load of this 13:18:51 <12ge0ff> nice shadows 13:21:09 <090x2d> it's GPU raycast and animated 13:32:38 <090x2d> https://cdn.discordapp.com/attachments/747522859361894521/1492985820070809710/screencap.m4v?ex=69dd52e5&is=69dc0165&hm=e92b4f11051952adcd68e66320e5b609eae565405df40bc2647a9651fb688dea& 13:35:18 probably discord's fault, but I can't open that in any video player and even ffprobe things it's cursed 13:36:15 <12ge0ff> (it's just a screenshot. also, discord doesn't allow opening attached files if you're not logged in) 13:37:49 I can see the screenshot fine, just not the last one "screencap.m4v". Good to know on the attachment thing though. 13:38:12 And it still downloads a 3 meg file :? 13:41:59 <090x2d> I think I just broke the video export 13:42:23 No way to log into Discord on chiark, and I grabbed that with wget, getting a 3MB file which is "ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]", I don't think this is always true about "not logged in" 13:43:10 <090x2d> yeah, I screwed up the export 13:45:42 <090x2d> this should work 13:45:43 <090x2d> https://cdn.discordapp.com/attachments/747522859361894521/1492989109084619006/screencap.m4v?ex=69dd55f6&is=69dc0476&hm=1893821cdbc72bbaf12dc64f42ce8c8516154114426f2423c7fd82e07ea3e249& 13:48:39 ah there we go 15:12:48 <11doc_eon> This is super cool @0x2d 15:14:23 <090x2d> hmu on signal 15:19:28 <04dracoomega> I wonder if trigger_movement_effects() shouldn't trample all over another pending movement, actually. This may not be the only place this scenario is possible at the moment. But admittedly, I'm not sure if that behavior is correct for all possible scenarios either, hmmm.... 15:21:16 <04dracoomega> Going to take a pause on current Big Projects to handle a few PRs today, I think 15:26:13 <04dracoomega> Looking at https://github.com/crawl/crawl/pull/5196, the implemention used here suggests this same problem exists for a lot of other abilities. On a trivial check, multiple of the forms added in the past year. It really feels like this wants a more general approach (as a 4 year old comment even says) 15:26:22 <04dracoomega> Er, this isn't a criticism of the PR, to be clear. This is non-trivial. 15:29:28 <04dracoomega> Ugh, some of these abilities don't have ability targeters since they go through the spell interface instead, which is why the quiver code isn't seeing it. 15:31:39 <04dracoomega> But using targeting flags over there would put a different targeter layer on top of it in other cases. (Honestly, some parts of ability code are still a bit clunky compared to spells, in ways that aren't easy to fix) 15:33:11 <04dracoomega> Yeah, there's even older stuff this doesn't work properly for since this list was never kept in sync. (I'm not sure I knew about it and I have certainly never tried to quiver just about any of these things in normal play) 15:46:06 <04dracoomega> I am annoyed that I am leaning towards just making a bigger band-aid instead of changing any of this right now ^^; 15:46:36 <04dracoomega> But it feels like the relative gain just isn't worth the effort 15:47:30 <04dracoomega> Like, extracting custom targeting code from a dozen or two abilities is extremely not worth it, and while I could move this all over to flags on the abilities instead of a list inside the quiver, that seems equally easy to forget to add. And at least it's only related to the quiver. 15:47:43 <04dracoomega> So I'll probably just review for whatever else seems missing and add it 16:16:15 <04dracoomega> Some of these do even weirder things, it seems. Sign of Ruin claims that there's no targets in range if you try to do it from the quiver >.> 16:16:28 <04dracoomega> Not yet sure why 16:18:52 <04dracoomega> Oh, apparently its range was listed as -1, but that's not what's used for the targeter call, so it works fine when used normally 16:41:16 <04dracoomega> Hmm... now I am confused in the other direction. Beogh smiting isn't on this list yet seems to work properly anyway 16:43:11 <04dracoomega> Oh, nevermind, I'm just blind 17:49:07 <04dracoomega> Looking into https://github.com/crawl/crawl/pull/5194, while it's not unreasonable to handle this situation gracefully instead of asserting, the assert is there in the first place since this is supposed to be impossible - we categorically end constriction when a constrictor dies. And I'd like to figure out how this situation happened in the first place, but have not been able to reproduce it yet. Even going so far as to replicate the 17:49:07 original crash's scenario of a monster being constricted by an anaconda summoned by an ally that was recalled to a different floor. 18:23:46 <04dracoomega> @Odds Since you've done more recent work on this, do you think https://github.com/crawl/crawl/pull/5178/ is trying to address the same thing that your https://github.com/crawl/crawl/pull/5184 is, but in a different way? (They're rather less clear about explaining what's going on, so I'm not quite sure.) 20:11:21 <04dracoomega> Hmm.... this isn't a PR bug. This is a 'me' bug >.> 20:11:57 <04dracoomega> (I have apparently found one case where those "Your line of fire is blocked by an X" prompts was still load-bearing) 20:21:55 <04dracoomega> (Now I just need to figure out how to fix this >.>) 21:34:47 <04dracoomega> Well, I have progressed from it trying to shoot monsters through grates to giving up and shooting the player instead 21:34:53 <04dracoomega> I am not sure this counts as progress, really 21:48:58 <04dracoomega> I do not like this codepath very much 22:05:59 <11Odds> Yeah I wondered about this - I think some callers want to trample ongoing movement effects (e.g. recalling allies) and some don't 22:06:39 <04dracoomega> I mean, there shouldn't be 'ongoing movement effects' for recalling allies, should there? 22:09:21 <11Odds> Right, but not setting last_move_pos will leave the monster in a state where it looks like it is mid-move. That seems bad (though IDK if it actually causes problems) 22:10:23 <04dracoomega> Well, I was thinking more like checking if there's any existing state when trigger_movement_effects() is called, and if so, use that as the previous pos 22:10:43 <04dracoomega> But I haven't seriously investigated this yet 22:10:44 <11Odds> Ahhhh 22:11:16 <11Odds> The PR description is similar - I don't see how the code could address the issue; I think all it will do is make autoexplore willing to risk adjacency to some unknown out of bounds squares 22:12:05 <04dracoomega> Yeah, I was a little confused by it, but wasn't sure if I was the one misunderstanding or them 22:13:14 <11Odds> Yeah I think them (and the comment is quite AI-y) 22:13:32 <11Odds> (It's slightly awkward that out-of-boundness isn't visible to the player but is readily detectable) 22:13:37 <04dracoomega> I've reviewed like... 9 PRs of yours today, I think (including that one), which are more or less ready to go if I hadn't gotten sidetracking onto this other bug 22:13:46 <11Odds> Thanks! 22:14:03 <04dracoomega> You know, I hadn't considered this, but that might explain why it seems to almost make sense, yet I can't quite yet it >.> 22:14:23 <11Odds> The "Fix:" comment is a thing AIs do when they change things 22:14:24 <04dracoomega> For the most part, I am not sure why we bother to hide this 22:14:48 <04dracoomega> Like, what purpose does it serve? 22:15:20 <04dracoomega> It's unambiguous in several zones and they don't seem to suffer for it. (And you can always tell if you have digging) 22:15:26 <11Odds> It does make a difference - if you want to hug edges, knowing where they are helps 22:15:56 <11Odds> But it would be totally fine for players to know 22:17:11 <04dracoomega> Yeah, it's not that it's irrelevant, but it's only semi-hidden in the first place (and sometimes mildly confusing) 22:18:38 <04dracoomega> You know, back before our current wall monster implementation existed, I was working on my own for a player summoning spell that made wall-bound creatures, and one of the problems I had with it is that they couldn't occupy the map boundary, but the player couldn't necessarily tell that it was the map boundary. So it seemed like it was going to be constantly confusing why sometimes they wouldn't appear or move along a wall. 22:19:21 <11Odds> I thought we had "unnaturally hard rock walls" 22:19:49 <11Odds> (And do current wall monsters not have the same issue?) 22:20:38 <04dracoomega> I think 'unnaturally hard rock wall' is only used for stuff like in Zot:5 and not normal level boundary. The edges of D still just claim to be 'rock wall' even though they're undiggable. 22:21:41 <04dracoomega> You're right that current rock monsters also can't occupy the level boundary, but I felt that was much less bad in that: a) They weren't player summons you might try to create in an impossible place b) Mostly they can either also exist outside of walls or in places where the level boundary is not a real concern, like Slime 22:21:46 <11Odds> Flavourwise, I do tend to think that the level boundary looking different would be unappealing, as it's generally mixed in with other bits of wall 22:22:16 <04dracoomega> That is fine, but it seems probably harmless to me to tell the player that they're at the edge of a level. 22:22:38 <04dracoomega> (Probably) 23:45:51 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-268-g36cf4e329c 23:51:09 -!- TAS-2012v is now known as TAS_2012v