00:02:40 AlkalineIce (L13 DrSh) Crash caused by signal #11: Segmentation fault (Orc:2) 00:59:01 -!- indigaz23 is now known as indigaz2 03:31:38 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:10:19 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-956-g0af7640 (34) 05:23:39 <04dracoomega> I keep finding more bugs as I dive into tidying up around earlier ones. Did you know that, while moving in the usual way will immediately end any melee constriction the player is doing (even if you're just circling around a monster and remain adjacent to it the whole time), most other methods of moving won't end it, so long as you still land adjacent to your target? For instance, casting Vhi's such that you remain adjacent to a 05:23:39 constricted target will keep it constricted. Being trampled doesn't cause you to lose your grip. Even Gavotte or uncontrolled blinking won't abort it (even though taking a single step does). We're also surprisingly insistent about what displacement effects break you out of constriction. Casting bombard will break melee constriction (even if you remain adjacent to your constrictor), but not other forms of constriction, so grasping roots will just 05:23:40 follow you around as you move. Knockback effects don't break any form of constriction (ie: you can remain constricted in all ways after being thrown around, provided adjacency remains) 05:24:16 <04dracoomega> You can get force lanced across an entire room and remain rooted in place 05:25:18 <04dracoomega> (Monsters have similar behavior with not unconstricting targets when dislodged by most means. Normal movement will break it, but something swapping with them won't, for instance.) 05:26:40 <04dracoomega> And then this led to me noticing various other bugs with monster movement, where a bunch of functions do location effects afterward only for the player and not for monsters. If a monster tramples another monster onto a trap, it won't trigger (but the monster doing the trampling would trigger it in the same situation), nor will blastmotes immediately explode, or a few other things. But the same is not true of a player being moved 05:26:41 that way. 05:33:39 <04dracoomega> There's really a lot of other post-movement effects that we're somewhat inconsistent about doing (because there are so many ways things can get moved, and a bunch of it has to be done manually, so it's easy to overlook bits) which I've periodically thought I'd like to improve upon, but it's... daunting 05:34:18 <04dracoomega> Since this is sort of all one big complicated snarl of interconnected parts, where sometimes their differences are deliberate and important and sometimes they're accidents or even bugs. 05:34:30 <04dracoomega> (And it's not always immediately obvious which is which) 05:37:17 <04dracoomega> This all seems like quite a task to slip in to the process of implementing a very mechanically-simple effect I was working on >.> 05:37:25 <04dracoomega> (That just happens to involve constriction) 05:58:11 <12ge0ff> maintaining constriction while being trampled is kinda cool flavour-wise (although extremely inconsistent) 05:59:43 <04dracoomega> I could definitely see arguments for allowing you to maintain adjacent constriction under some circumstances when moving, but there's no way that getting pushed by a boulder should break it while being pushed by an elephant doesn't. (Or that walking breaks it when blinking doesn't.) 06:02:10 <04dracoomega> I'd think that it actually could be allowable to let you keep constricting things you sidestep around in general, but I have also been considering letting aqua form allow you to constrict things at range (in the process of rewriting some stuff), and that presents a lot more concerns about allowing the player to maintain physical constriction while moving. 06:03:36 <04dracoomega> "Grab a thing next to you, walk back a bunch of steps while it stays in place, repeat as necessary." (Of course, this needs room and they can still break out early and it's late enough that melee 1v1s are not exactly the fights you're usually worried about, but it does concern me a little.) 06:05:10 <12ge0ff> it feels like letting the player reposition while maintaining constriction has to have some kind of cost, like a chance to lose the grip on the target 06:09:19 <04dracoomega> The thing is, is it really worth making that chance not be 100% (as it currently is)? 06:09:36 <04dracoomega> And just be consistent about you losing your grip on things whenever you are moved by any means 06:26:26 <04dracoomega> Surveying all the places we call move_to_pos without ever calling apply_location_effects and there are at least 30, though probably like... almost half of them are probably fine or even correct? (And then some of them are very much not correct) 06:28:49 <04dracoomega> The 'annoying' thing is that the vast majority of the time you want move_to_pos to be followed by some point by apply_location_effects, but there are a lot of situations where it's important that something happen in the middle of it, such that you can't really bundle them together into a single function to use all the time. 06:30:03 <04dracoomega> C++ if (act->is_player()) move_player_to_grid(*di, false); else act->move_to_pos(*di); But we have a number of places that do something like this, where the player method does call location effects and the monster one never does, and probably there is some value in having a method call (or just a parameter) that lets you bundle those into one call when you 06:30:03 don't care about specific ordering. 06:32:05 <04dracoomega> One of the biggest / most common issues with applying location effects immediately is traps. There's already repeated problems with shafts eating monsters in the middle of things, and bundling this together more often could compound this. But I can't help but find myself wondering if a safer overall approach is to always defer trap triggers as a fineff in general? 06:33:08 <04dracoomega> Though this would still leave some location effects that can be fairly dramatic not doing that 06:34:30 <04dracoomega> I guess basically: while it makes sense from an underlying code perspective to call movement and location effects separately, it has historically lead to constantly overlooking calling the latter in the proper way, and it would be nice for that to be less of a thing 06:35:07 <04dracoomega> Like, I found at least a dozen problem cases today (admittedly some of them minor), when I know that we've had commits fixing this sort of thing many, many times in past. 06:36:19 my only contribution to dcss is a commit fixing flanking's interaction with sygil of binding 06:36:55 it looked like a lot of interactions are manually special cased 06:37:27 9-39-52 06:37:30 woops 06:39:42 <04dracoomega> Yeah, and that bug had probably been around for over a decade at that point 06:40:42 <03implojin> hard agree that it would be good to unify these so that callers are not constantly rolling their own logic and being inconsistent about it (feels like we've had this conversation a few times before) but it's probably going to require slightly refactoring several callers iirc because they all have their own little idiosyncrasies (maybe it won't be so bad? who knows) 06:41:32 <04dracoomega> Yeah, it seems very much not straightforward because many functions do have legitimate reason to defer things in different ways. 06:44:15 <04dracoomega> Even outside of trap weirdness, a common pattern is that we want to move a monster (and verify it actually moved) and then print a custom message about that movement before apply_location_effects does arbitrary things 06:44:26 <04dracoomega> Or the message order would look incredibly weird 06:44:46 <04dracoomega> Like saying that something fell into water and only afterward say that it moved 07:05:20 <04dracoomega> Really, the more I stare at this, the more I feel like I don't have a good sense of an adequate solution. Turning apply_location_effects into a fineff feels like a concerning level of overkill for something that does nothing >99% of the time and happens every time a monster moves. 07:49:15 <05icoson> adding crypt-r as a dep sounds like the way to go for py3.13 compatibility. I think forcing a password db update isn't the way to go, but maybe we ideally do want to give admins the option to update to something more modern (or start with something more modern). Though it does look like dgl may be the limiting factor here? 07:49:38 <05icoson> the relevant security concern is brute force attacks on the password db after a server is hacked 07:50:00 <05icoson> reasonable discussion of the issues here: https://security.stackexchange.com/questions/52041/is-using-sha-512-for-storing-passwords-tolerable 07:50:37 <05icoson> (since the best we can do under the current scheme is SHA-512 with salt; but perhaps dgl doesn't actually support that?) 07:51:44 <05icoson> crypt-r would support blowfish/bcrypt via glibc 07:51:54 <05icoson> I think 07:55:42 <05icoson> ah we have at least patched dgl to support SHA-512 (https://github.com/crawl/dgamelaunch/commit/9a8c1531fc5a5a0d19700a6e10ade83521c90aff) 07:58:47 <06mumra> It doesn't sound unreasonable to do so though, and it means it can be invoked automatically when a monster is moved rather than everywhere having to manually call it? 08:01:20 03dolorous02 07* 0.34-a0-957-gb018e8e09e: Add status dexcription for "Gem (*)". 10(3 minutes ago, 1 file, 5+ 0-) 13https://github.com/crawl/crawl/commit/b018e8e09e99 08:36:08 <04dracoomega> I do worry a little about using a mildly more heavyweight solution (that is almost never actually needed) for something done constantly. But beyond that, I suspect this might cause some lag time on certain effects happening compared to what one expect, in a number of situations (and it might be hard to track down all of them) 08:47:02 03dolorous02 07* 0.34-a0-958-gd0e9a9ddd5: Add references to baubles in Zin speech. 10(6 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/d0e9a9ddd516 09:37:59 <09gammafunk> In that case, I guess we can just continue using crypt-r for the foreseeable future. I don't know that we care terribly much about being as secure as possible should a password DB get leaked. Depending on cryptography that is deprecated to the point where it's not easily available on a modern system is more my concern (speaking as someone who's going to attempt a dist upgrade of CDI soon). 10:37:13 <06mumra> https://cdn.discordapp.com/attachments/747522859361894521/1428799022981972149/image.png?ex=68f3d048&is=68f27ec8&hm=78c4fb2c93d3f108e6cbadb7c549c0d579117b9ddfc20cf3b2441621987ffa72& 10:37:19 <06mumra> Tiles bug on this zin/gozag vault 10:37:49 <06mumra> i used /digging to get thru the grates and take the gold, but where the gozag wall got dug out it turned into a completely black tile 10:38:21 <06mumra> https://cdn.discordapp.com/attachments/747522859361894521/1428799309150814239/image.png?ex=68f3d08d&is=68f27f0d&hm=a40ff1323f29f4ba74cc1b11257a252ec756094e17799aef91d7f213915185c2& 10:38:45 <06mumra> obviously something to do with the walls being retiled, now the game doesn't know what floor tile to use when the wall is removed? 10:43:04 <06regret-⸸nde※> That's not a completely black tile, as can be seen in any quick image-editing software- that's just the normal floor_grey_dirt the rest of Dungeon uses, except much harder to parse as anything besides black when juxtaposed directly against the brighter walls and floor tiles of the rest of the vault. 10:44:31 <06regret-⸸nde※> (This sort of thing has to basically be handled on a vault-by-vault basis of making sure the ftile is set for walls glyphs likely to be dug as well as the actual floor itself, which would be very easy to do for this vault.) 10:44:45 tiles unreasons 😛 10:46:03 <06regret-⸸nde※> Yes, how dare anybody want to actually see anything in 2025. 10:46:27 <04dracoomega> I mean, it doesn't even strike me as particularly weird that removing a wall would have undecorated floor underneath 10:46:58 <06regret-⸸nde※> There's some reasonable defense it could use something else, like floor_pebble_brown or floor_sandstone, it is true. 10:47:07 <05icoson> also, looking at the defaults, I think the crawl repo uses "broken" as a default simply because that guarantees that a dev install will work out of the box with the widest variety of options, but dgl-config does use sha-512 as the default (so this is probably what most modern servers are using) 11:06:23 <06mumra> oh you're totally right of course. it looked completely black to my eyeballs due the contrast between very bright yellow and the grey dirt 🙂 11:07:52 <06mumra> yeah i would have thought it should at least use the marble floor tile of the rest of the vault, it does look buggy otherwise even if there's a slightly more rational explanation than i initially thought 🙂 11:10:40 <06mumra> damn ... i think i lost an enchant scroll because it seems the "enchant which weapon?" dialogue will just cancel itself if you disconnect and reconnect while it's open? (on first read-iding an enchant weapon scroll) 11:35:25 <06mumra> i'm not sure what the right fix is. but i'm slightly thinking it wouldn't actually hurt the id game if we allowed strategic scrolls to always be saved for later. read-id already carries the risk of burning up a useful tactical scroll. if you discover an enchant scroll and don't immediately know what to use it on or even have something i don't think it hurts to be able to save that one for later (i think with acquirement you already 11:35:26 can in any case?) 11:41:02 <02Darby> I kind of like that it results in having to decide about and put enchants on something you otherwise wouldn't 11:42:39 <04dracoomega> Same, honestly 12:38:21 <09gammafunk> it is sort of funny that acquirement is an exception mostly for UI reasons, but then again the upside you'd get from hanging onto it without using isn't very big. Whereas it is a pretty decently upside to get to hang onto enchant scrolls for later (especially for weapons) 12:39:45 <09gammafunk> uninterruptible acquirement where you somehow have a properly "jailed" way of inspecting everything about your character in order to make an informed decision turned out to be a massive headache 13:00:32 <06mumra> in this case i actually knew what i wanted to use it on, the scroll just got aborted for me because i moved my laptop, it connected to a different wifi, and the websocket disconnected 13:01:20 <06mumra> so with this behaviour we want the game to be able to resume the enchant menu at least 14:27:19 03gammafunk02 07* 0.34-a0-959-g13813543c0: Document requirement changes for WebTiles server 10(20 minutes ago, 5 files, 112+ 72-) 13https://github.com/crawl/crawl/commit/13813543c0ed 14:27:55 <09gammafunk> this has bumped various module requirements for webtiles server to versions appropriate for python 3.13 or later, but that seems fine since debian stable is also using python 3.13 14:28:24 <09gammafunk> and these requirements are optional for an admin to use and don't affect anything currently running 14:28:24 <09gammafunk> oh nice 14:28:50 <09gammafunk> that's how you close a PR! fix a bug and a bot detects that you fixed it and closes it for you 14:46:24 04Build failed for 08master @ 13813543 06https://github.com/crawl/crawl/actions/runs/18605277173 14:50:01 <09gammafunk> oops 14:50:35 <09gammafunk> I guess this causes issues for CI because we use 3.8 14:52:51 03regret-index02 07* 0.34-a0-960-gf182cc49eb: Fix trove_leda body armour (Monkooky) 10(60 seconds ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/f182cc49eb95 15:01:22 <09gammafunk> I suppose from that standpoint we shouldn't put 3.13 requirements into the requirements file 15:05:22 <09gammafunk> is there a way to condition requirements on the version of python being used? 15:05:49 <09gammafunk> aha, there is 15:05:58 04Build failed for 08master @ f182cc49 06https://github.com/crawl/crawl/actions/runs/18605705020 15:06:55 <09gammafunk> hrm, it looks like tornado 6.5.2 won't work with python 3.8 though 15:07:16 <09gammafunk> so that part will certainly be reverted, but it does look like I can condition crypt-r on the python version, at least 15:07:32 <09gammafunk> and just revert the rest of the requirement changes 15:07:45 <03implojin> searches suggest that even if we switched to our runners to ubuntu-latest (iirc there were problems with that, don't know if we ever fixed them), ubuntu 24.04 only carries python 3.12 15:08:19 <09gammafunk> well, I think the decision about 3.8 is also based on our stated minimum supported version 15:08:24 <09gammafunk> but that's a good point 15:08:36 <09gammafunk> we "officially" state we require at least python 3.8 in our docs 15:09:01 <09gammafunk> I'm not sure what our current runners have available python version wise, maybe 3.8 is just the latest for them 15:09:32 <09gammafunk> but for now to get CI working, I'll just add crypt-r with a condition for python >= 3.13 and revert the other requirement changes I made 15:09:41 <03implojin> https://documentation.ubuntu.com/ubuntu-for-developers/reference/availability/python/ 15:09:45 <03implojin> 3.10 and 3.11 looks like 15:15:56 <03implojin> oh never mind that was wrong, looks like they have later versions available 15:16:02 <03implojin> https://github.com/actions/runner-images/commit/d4d5736e7d5b88a683d1ea76e7dc74031c71d4c6 15:17:00 <09gammafunk> yeah, I'm not sure what's the most appropriate for all these CI tests, the oldest versions or a newer one 15:17:15 <09gammafunk> seems that we're currently just using the oldest version we officially support 15:17:30 <09gammafunk> I'm not even sure if 3.8 applies to webtiles only or also the game 15:18:16 <09gammafunk> but it's definitely what we state for WebTiles and I'm not sure what all versions we have out on live servers 15:19:52 <09gammafunk> ok I tested this change locally with an install of requirements and it works, so let me push and see if that at least fixes CI 15:21:36 <09gammafunk> install has no specific mention of a python version 15:39:53 Unstable branch on underhound.eu updated to: 0.34-a0-960-gf182cc49eb (34) 16:08:21 03gammafunk02 07* 0.34-a0-961-g7c3bd3c276: Roll back python package requirements 10(48 minutes ago, 3 files, 56+ 45-) 13https://github.com/crawl/crawl/commit/7c3bd3c27620 16:09:52 <09gammafunk> from the current running actions, looks like that worked 16:20:11 <03implojin> a brief test suggests our ci would mostly work fine on ubuntu-latest but still has a few issues 16:20:19 <03implojin> https://github.com/Implojin/crawl/actions/runs/18606444582/job/53057722290 16:21:14 <03implojin> would be good to bump this again so we can catch issues with packages breaking there before they hit players 16:42:57 <09gammafunk> more problems with libpng? 16:45:38 <03implojin> some of this may have been unresolved from the last time we had ci issues, i'm not sure what all was fixed while i was gone 16:46:46 <03implojin> i've got it working with just those 3 runs using 22.04 but currently testing an action matrix that will do 3.8 3.11 and 3.13 for the webserver since we want it to be compatible with whatever the servers have running 16:47:04 <03implojin> would be better to fix them properly ofc 17:06:54 03Implojin02 07* 0.34-a0-962-gc80b890e59: Bump most CI to ubuntu-latest, python to 3.13 10(2 hours ago, 1 file, 19+ 19-) 13https://github.com/crawl/crawl/commit/c80b890e59f3 20:54:14 03WizardIke02 07* 0.34-a0-963-g9630a171c0: Fix scrolls being wasted when losing connection (mumra) 10(18 minutes ago, 4 files, 134+ 26-) 13https://github.com/crawl/crawl/commit/9630a171c024 21:48:29 03WizardIke02 07* 0.34-a0-964-gbc34600443: Don't restrict telling the player about acidic slime to floors 10(29 minutes ago, 2 files, 3+ 10-) 13https://github.com/crawl/crawl/commit/bc3460044340 22:35:27 Unstable branch on crawl.develz.org updated to: 0.34-a0-964-gbc34600443 (34) 22:51:14 03Implojin02 07* 0.34-a0-965-g3beb288adb: ci: Bump android and mingw runs to ubuntu-latest 10(2 hours ago, 2 files, 7+ 3-) 13https://github.com/crawl/crawl/commit/3beb288adb56 22:58:32 Windows builds of master branch on crawl.develz.org updated to: 0.34-a0-964-gbc34600443 23:33:46 Unstable branch on cbro.berotato.org updated to: 0.34-a0-965-g3beb288adb (34) 23:55:34 Monster database of master branch on crawl.develz.org updated to: 0.34-a0-965-g3beb288adb