01:00:53 03WizardIke02 07* 0.35-a0-573-g24dab868eb: Fix some effects being endianness dependent 10(12 minutes ago, 5 files, 61+ 15-) 13https://github.com/crawl/crawl/commit/24dab868eb25 01:16:26 04Build failed for 08master @ 24dab868 06https://github.com/crawl/crawl/actions/runs/28225304898 01:31:53 <11Odds> How does lua doc generation work (i.e. how is https://doc.dcss.io/ updated)? 03:34:52 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:23:02 pelladn (L9 FoFi) ERROR in 'mon-util.cc' at line 3199: bogus mc (no monster data): invalid monster_type 1000 (1000) (D:7) 06:24:45 <09gammafunk> via CI, there's a command definition in the CI yaml 06:24:59 <09gammafunk> oh, for doc.dcss.io, that's an old url 06:25:00 <09gammafunk> ??lua 06:25:02 <04Cerebot> lua[1/1]: Crawl currently uses lua 5.4 (as of 0.34). You can find more information at https://www.lua.org/manual/5.4/manual.html For documentation on crawl's lua API for RC files, see: https://crawl.github.io/crawl/lua/index.html (trunk, not stable). 06:25:11 <09gammafunk> that link is the one updated by CI 06:26:14 <09gammafunk> we probably could add a special CI that created a separate url for any release 06:33:02 kuniqs (L27 DsBr) ASSERT(you.form == you.default_form) in 'transform.cc' at line 2351 failed. (Elf:3) 06:33:03 <11Odds> Ah right, thanks. The old one is what I found with my usual process of googling "dcss lua" 🙂 06:39:16 03CrawlOdds02 07* 0.35-a0-574-g236f66fc2a: Suppress an out-of-LoS bolas message 10(19 minutes ago, 1 file, 8+ 4-) 13https://github.com/crawl/crawl/commit/236f66fc2aa9 07:16:33 03CrawlOdds02 07* 0.35-a0-575-gea2d1a0413: Fix spurious messages during volcano catchup 10(4 minutes ago, 1 file, 6+ 1-) 13https://github.com/crawl/crawl/commit/ea2d1a0413bf 09:23:56 <11Odds> Investigating the teletrap in https://github.com/crawl/crawl/issues/5294, what's happening is we have a vault with a trap on its exit and on the two non-vault squares that exit connects to. The whole zone looks impassable to the connection algorithm (vaults are impassable except their exits, traps are impassable), so it isn't noticed. I think a milder but more common manifestation of the same bug is that we can roll traps that disconnect a 09:23:56 vault from the rest of the level. I think the right fix is to make sure that a vault gets at least one connected exit without a trap, which will guarantee that it is "noticed" by the connectivity algorithm (and this fix is also easy). But I'd welcome an opinion from someone who has thought more than me about dungeon generation. 09:25:01 <11Odds> (In this case, all these traps are webs. This bug is almost always going to happen in spider) 09:33:41 <11Odds> Actually.... I no longer think this is the right fix. The problem here isn't actually vaults at all, it's that we have an area made entirely of traps, and that could happen with no vaults at all. 09:48:56 <11Odds> So yeah I think we probably need an extra connectivity check that treats traps as passable (though possibly we should also do the vault entrance thing, which would prevent vaults getting disconnected from the rest of the level by a trap) 09:52:14 <04dracoomega> I'm slightly confused. Is this 'vault that connects to the rest of the level only via trap tiles' getting those connecting tiles replaced with wall at some later point already? 09:52:56 <11Odds> No sorry, it only connects to any external tiles which are trap tiles, and the whole thing is disconnected 09:52:59 <11Odds> https://cdn.discordapp.com/attachments/747522859361894521/1520109632121737307/607248711-747540c7-4a31-4489-b7a3-d34d952a6c1f.png?ex=6a3fffea&is=6a3eae6a&hm=35220f67d7b634fa75eb56cca7cfff39b51581902a4cb978356873c74ca45568& 09:53:21 <11Odds> This is a vault, and the three webs at the top are a) the entrance and b) the only two non-vault tiles in the zone 09:54:21 <11Odds> So the main problem is that in terms of not-opaque-because-vault tiles, this is a disconnected component made entirely of traps. If the rest of the vault wasn't there, we could teleport into those three tiles still. 09:56:23 <11Odds> At the moment, the level is making sure that all the passable tiles are connected, but this whole thing is non-passable (because vault-opaque or because trap), so is entirely ignored by that check 09:57:01 <04dracoomega> So it one of those 'non-vault traps' at the top was floor, the generator would either carve a path to it or fill in the zone? 09:57:19 <04dracoomega> But now does neither? 09:57:20 <11Odds> Yeah, or just veto 09:57:43 <11Odds> I didn't look so much at the fixing check, only the veto check as that seems like the main one to get right 🙂 09:58:02 <04dracoomega> (My confidence in the details of the map generation process is... very fuzzy, let's say) 09:58:15 <11Odds> (Or if the vault entrance trap was floor, the same would happen) 09:58:17 <04dracoomega> "I know very approximately what happens" 09:58:43 <04dracoomega> Just that it does fill in or veto things similar to this on the regular, at least 09:59:09 <04dracoomega> (Anyone who has played a long time has surely seem those cases where it clearly carved a big long hallway to attach a vault to the rest of the floor) 09:59:27 <04dracoomega> Though that may be generator-dependent 09:59:27 <11Odds> TBH I haven't thought of them as a level generation artifact 🙂 10:00:00 <04dracoomega> I think they're quite conspicuous when they happen (but not in a way that feels like 'an issue that needs fixing' so much as just a quirk of their nature) 10:01:19 <04dracoomega> But certainly, if the game isn't going to go out of its way to brute-force a connection to an existing vault, surely isolated vaults need to have some check that they're themselves attached to somewhere reachable, yeah 10:02:52 <11Odds> Yeah - though it's not just vaults; if you remove the whole vault here you still have a little teletrap full of webs (at least, this connection check wouldn't spot it - maybe there's another reason it can't generate) 10:04:48 <11Odds> So, I think the thing to do here is to check everything is connected (to a stair) when we count traps as passable 10:07:14 <11Odds> (That still leaves a lesser problem that a vault can get blocked from the level by a trap - e.g. here if you dug a little hole at the top - which we could fix by ensuring they have an untrapped entrance) 10:09:30 <04dracoomega> Not altogether clear to me that vaults should be guaranteed a non-trapped entrance 10:09:52 <04dracoomega> (Given how many vaults are not even obviously vaults, but rather 'level shapes' more than anything) 10:10:12 <11Odds> The rest of the level (apart from traps) is guaranteed to be connected (to stairs) with non-trapped paths 10:11:09 <04dracoomega> (To be honest, I'm surprised webs are even in the same category here, since even autoexplore doesn't care about them) 10:11:20 <04dracoomega> And don't really feel like they can count as blocking anything 10:11:55 <11Odds> Yeah I was mildly surprised Spider cares about webs 10:12:30 <11Odds> (Changing that would still leave this whole thing possible but naturally way rarer) 10:12:49 <11Odds> I suspect it would also make spider significantly crueller, actually 10:13:12 <11Odds> The narrow corridory levels would gain a lot of web blockades 10:14:51 <04dracoomega> I would be curious how much the actual effect was, tbh 10:15:25 <04dracoomega> (Though this is probably easy to arbitrarily test, if I felt like it, I suppose) 10:19:17 <11Odds> (Yeah I think you just want to mess with dgn_square_travel_ok) 10:27:50 <11Odds> Re: vaults getting disconnected with traps; I do tend to think they shouldn't be. I can't think of any really bad cases, but a vault behind e.g. a permanent tele trap could be super tedious and we prevent this for the rest of the level 10:40:13 <04dracoomega> No permanent tele traps spawn randomly anywhere, I thought? 10:40:41 <04dracoomega> (This may be a marginal enough effect regardless that it's not worth caring about vetoing, mind you) 10:42:19 <11Odds> (I didn't know that on permanent tele traps but it certainly seems true yes) 10:42:56 <11Odds> Eh, certainly seems fine to do nothing on that one. Worst case is a tedious walkign through dispersal or having to take a temporary tele trap to get into a vault, probably 10:45:54 <02Darby> and at least one common overflow already requires triggering a temporary teletrap to reach the altar by design 10:46:51 <11Odds> That one has at least thought about it though 🙂 10:47:11 <11Odds> I guess massive dangerous vaults are the worst case? 12:34:55 03CrawlOdds02 07* 0.35-a0-576-g0ee5010553: Prevent teleport closets made of traps 10(2 hours ago, 1 file, 23+ 0-) 13https://github.com/crawl/crawl/commit/0ee501055390 12:36:31 <11Odds> (For clarity I didn't do the thing where vaults can't be disconnected with traps and I'm not planning to) 13:26:04 03CrawlOdds02 07* 0.35-a0-577-g93e8449470: Stop fusillade firing through walls 10(4 minutes ago, 1 file, 15+ 1-) 13https://github.com/crawl/crawl/commit/93e8449470d3 13:27:43 <04dracoomega> @Odds Doesn't Ignition still have the same issue? 13:27:59 <11Odds> Oh, if I knew that I've forgotten it... 13:28:52 <11Odds> Yes, with the bonus that the targetter lies. Will fix! 13:33:44 <04dracoomega> Oh, the targeter additionally lies? How? 13:34:22 <11Odds> It gives the answer we'd like to be true (explosions not going through walls) 13:39:49 <04dracoomega> I don't actually see why 13:40:03 <04dracoomega> This may be a general targeter thing that never considers out-of-los positions valid 13:40:12 <04dracoomega> Since the targeter logic doesn't itself account for it 13:40:21 <04dracoomega> Er, the Ignition targeter logic specifically, I mean 13:40:48 <04dracoomega> (I really wish there was a less wildly boilerplatey way to get the proper explosion check here. It's rather clunky) 13:42:20 <04dracoomega> ...I honestly wonder about an 'explosion_iterator' 13:42:33 <04dracoomega> That takes a center point and radius and whatnot and handles that all in the backend 13:42:47 <04dracoomega> It can do the current precalculation, but then effectively let you step through it with no further steps 13:43:02 <11Odds> Yeah, I was just wondering about that. It's a bit of a mess to set up the right kind of beams and there's a lot of boilerplate with magic lines liek (9,9) 13:43:07 <04dracoomega> (Since it seems likely that we're going to add some smite-targeted explosion to the game in future) 13:43:12 <04dracoomega> At some point 13:43:27 <04dracoomega> And it would be nice if doing the 'correct' thing was relatively seemless 13:43:52 <11Odds> Indeed, "explode in the usual way" shouldn't be ten slightly weird lines of code 13:44:29 <04dracoomega> And then still require you to use an iterator after that 13:44:38 <11Odds> Though I guess you do need to set up a beam for things like trees 13:45:12 <11Odds> So this explosion_iterator needs the same beam but then is nice after that 13:45:21 <04dracoomega> Do fire explosions go through trees or something? 13:45:47 <11Odds> They affect trees' squares (I think?) whereas others don't 13:45:52 <04dracoomega> Ah 13:46:20 <11Odds> This may not be actually true in this function though 13:46:22 <04dracoomega> But yes, probably an explosion_iterator could take just a couple parameters (that would actually vary between callers) and handle all the beam setup internally 13:47:04 <11Odds> (Yeah fireball targeters don't actually say they are going to destroy trees, so this may not be a thing) 13:47:42 <11Odds> (They probably should though) 13:56:39 <11Odds> Yeah I think an explosion_iterator will work nicely, I'll have a crack at it tomorrow and fix ignition on top of that 14:00:30 <04dracoomega> Much appreciated! 14:01:53 <04dracoomega> (And so is the Xom and Pan work, which I may not have commented on at the time! Haven't actually made the time to look through it yet, buried as I am in invisible things) 14:02:28 <11Odds> Thanks 🙂 14:02:55 <04dracoomega> But I'm through most of the spells and abilities now, and the core UI additions are getting close to being done (or so I hope) 14:03:22 <11Odds> Nice. Quite the undertaking this 🙂 14:03:38 <04dracoomega> It's funny how, after going back to trunk to test a couple things, I've been on the branch so long that getting so little feedback on invis monsters feels weird now 😛 14:03:50 <04dracoomega> "Where's the indicator?" 14:03:56 <11Odds> A good sign! 14:04:02 <04dracoomega> I hope so, yes! 14:04:36 <04dracoomega> (Once I'm done with the UI stuff, I have a handful of monster changes to make an a new mechanic I want to try out, so it'll still be a little while before it's all merge-ready) 14:05:39 <04dracoomega> But the hardest stuff should be behind me now, at least 15:43:09 Unstable branch on underhound.eu updated to: 0.35-a0-577-g93e8449470 (34) 15:59:32 03autumn02 {CrawlOdds} 07* 0.35-a0-578-g6b10917da2: Fix item method docs 10(2 months ago, 2 files, 11+ 11-) 13https://github.com/crawl/crawl/commit/6b10917da235 22:36:05 Unstable branch on crawl.develz.org updated to: 0.35-a0-578-g6b10917da2 (34) 23:00:07 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-578-g6b10917da2 23:33:43 Unstable branch on cbro.berotato.org updated to: 0.35-a0-578-g6b10917da2 (34) 23:56:15 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-578-g6b10917da2