00:40:30 New branch created: pull/5212 (3 commits) 13https://github.com/crawl/crawl/pull/5212 00:40:33 03CrawlOdds02 07https://github.com/crawl/crawl/pull/5212 * 0.35-a0-291-g1bb9dcce8a: Track berserker piety 10(88 minutes ago, 1 file, 3+ 0-) 13https://github.com/crawl/crawl/commit/1bb9dcce8a1e 00:40:33 03CrawlOdds02 07https://github.com/crawl/crawl/pull/5212 * 0.35-a0-292-gbbc24bda9a: Split out max piety wastage for logging 10(44 minutes ago, 6 files, 26+ 10-) 13https://github.com/crawl/crawl/commit/bbc24bda9acd 00:40:33 03CrawlOdds02 07https://github.com/crawl/crawl/pull/5212 * 0.35-a0-293-g6467ac0d19: Track tithing piety 10(44 minutes ago, 3 files, 5+ 1-) 13https://github.com/crawl/crawl/commit/6467ac0d1939 03:33:38 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 07:21:28 New branch created: pull/5213 (105 commits) 13https://github.com/crawl/crawl/pull/5213 07:21:28 Branch pull/5213 updated to be equal with stone_soup-0.34: 13https://github.com/crawl/crawl/pull/5213 07:54:44 <09h​ellmonk> rip main 10:46:06 don't remember if anyone here has control over it but https://crawl.chaosforge.org is down (interestingly http is fine) 14:39:25 <04d​racoomega> We do not, alas 14:40:30 <04d​racoomega> Anyway, as I look at some of this gift piety stuff, I find myself wondering if Oka's piety formua should care about skill cost level instead of your actual XL (so that it would be normalized no matter what species you are). It never directly corresponded to displayed threat tier anyway. And it's mildly weird that some species can have a much harder time hitting 6* in a timely fashion than others, as a consequence of this. 14:41:57 <04d​racoomega> (Like, it's never been at all clear to me that stuff is 'less dangerous' to a fast-levelling species who has gained the same total amount of skill XP) 14:42:19 <04d​racoomega> Any more than a minotaur should get less piety because they're strong 14:43:53 <11O​dds> !apt xp 14:43:54 <04C​erebot> Could not understand "xp" 14:44:11 <11O​dds> !apt exp 14:44:12 <04C​erebot> Exp: Fo: 1!, Ko: 1!, Dj: 1!, Hu: 0, Gn: 0, Co: 0, Ba: 0, Mf: 0, Te: 0, VS: 0, Po: 0, Gr: 0, Op: 0, On: 0, Na: 0, Tr: -1, Mu: -1, Mi: -1, MD: -1, GC: -1, DE: -1, Ds: -1, Sp: -1, Re: -1, Dr: -1, Fe: -1, Dg: -2* 14:45:46 <11O​dds> All other gods use your actual XL 14:45:58 <02M​onkooky> but should they? 14:46:00 <04d​racoomega> Oh, right, XL technically matters there too 14:46:02 <11O​dds> Unless we are changing that too I'd be inclined to consistency 14:46:20 <11O​dds> Yeah the argument to prefer skill cost makes sense 14:46:24 <04d​racoomega> (It just matters so much less that people don't have anecdotes about it being weird on some species) 14:46:25 <02M​onkooky> Kobolds of Hep are weirdly strong because their ancestor levels noticeably faster 14:47:22 <04d​racoomega> Yeah, I somehow don't actually feel like that is actually wrong or negative, though. I wonder what the difference is? 14:47:50 <04d​racoomega> Maybe because it's a reward for reaching a level rather than a penalty? (Or just because it's a lot more transparent) 14:52:26 <02M​onkooky> the transparency I think helps a lot 14:53:06 <04d​racoomega> (There is, of course, no way to display the relationship between a player and the fine-grained XP values of hundreds of monsters in a clear and transparent way) 14:54:41 <04d​racoomega> It's kind of weird, though. I could make all normal kill piety care about skill cost level instead of XL, but since it's doing a direct comparison with monster HD, it feels like player XL is the appropriate measure (since that are used as equivalent in countless places). Oka is doing an XP calculation, though, and those often do use skill_cost_level (eg: everything that recharges with XP) 15:32:19 <02M​onkooky> So parrying currently has half effect if you lack an offhand 15:34:57 <09h​ellmonk> open to whatever wording adjustment seems best 15:35:37 <02M​onkooky> intuition would indicate 'no offhand, can't parry good', which suggests that wording should change rather than behaviour, but I can't think of a correct but not cumbersome wording 15:36:53 <09h​ellmonk> I think it's fairly important that it behaves this way since shield loss is a pretty big part of sac hand drawback 15:37:12 <02M​onkooky> actually "The shielding is twice as effective if the wielder has an offhand containing only weapons." 15:38:10 <09h​ellmonk> doesn't quite work bc you do get the full bonus if your offhand is empty 15:38:55 <02M​onkooky> "The shielding is twice as effective if the wielder's offhand is empty or wielding a weapon." 15:39:34 <02M​onkooky> also that first wielder should probably be wearer 15:39:40 <09h​ellmonk> Sure 15:40:34 <02M​onkooky> ALSO while I'm here I'd argue that the description should give one or both numbers 15:43:15 <04d​racoomega> It doesn't give either? 15:45:26 <02M​onkooky> it does not 15:51:20 <04d​racoomega> Well, that's clearly just an oversight then 19:51:19 <08n​icolae> apparently if your subvault has the same width as height, it might get rotated into the parent vault, even if the shape doesn't fit. hhhhhhhwelp. back to the drawing board. 19:51:46 I assume even with no_rotate? 19:54:36 <08n​icolae> Indeed! 19:55:27 I mean that sounds like a bug then, though I guess it gets weird if the parent vault can rotate. So on a subvault you'd want no_rotate to mean "use this rotation w.r.t. the parent vault" 19:55:59 <08n​icolae> i think if the subvault is not a rectangle the borders are treated as a gentle suggestion 19:57:47 pretty sure they are if it's not convex, but if you mean a simple square then yes, it seems wrong 20:01:48 <08n​icolae> they are convex but not rectangles 20:01:59 I could be misreading this but isn't this backwards, since map.map.width() is the parent map's width? https://github.com/crawl/crawl/blob/master/crawl-ref/source/maps.cc#L270 20:02:29 You'd only require rotating if the subvault's width is larger than parent's width (or height/height) 20:03:31 would be a casual 17yo bug if that is wrong 20:04:49 <08n​icolae> wouldn't surprise me either way tbh 20:05:10 <08n​icolae> do a lot of other vaults with heavy subvaulting have a lot of subvaults that aren't symmetric along any axis? 20:05:20 <08n​icolae> ugh, i'll deal with it tomorrow 20:05:32 <08n​icolae> or possibly i'll sleep in a bunch and deal with it TBD 20:05:34 <08n​icolae> we'll see 20:16:21 <08n​icolae> the subvault in question NAME: nicolae_shoals_pentapel_testing_xyz TAGS: transparent no_dump unrand nico_test_tag allow_dup no_tide TAGS: no_rotate MAP WW WcWW WxxWWW WWxx.ccW WW....xxWY W......WW Wc....cW Wc....cW W.cc.WW WWWWWW ENDMAP [some code elided, D is the subvaulted region, the statues and fountains around the edge are for knowing how the vault is oriented] MAP GDG DDD DDDDDD DDDDDDDG UDDDDDDDDD 20:16:22 DDDDDDDDDD DDDDDDDDDD UDDDDDDDDD DDDDDDD GDDDDDD ENDMAP 20:17:14 <08n​icolae> the 90 degree orthagonal corner appears to get aligned correctly but then it's 50/50 whether the rest of it lines up right or if it's flipped along the diagonal axis that passes through the 90 degree orthagonal corner 20:18:07 <08n​icolae> orthogonal* 20:19:10 sadly that's unreadable on this side of the bridge 20:19:22 IRC doesn't do newlines 20:21:45 (my Matrix bridge auto-pastebins those, but I gather Discord bridges don't support that) 20:23:00 (granting it does require significantly more infrastructure to support that, or a friendly external pastebin) 23:46:48 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-290-g6208fce011