00:55:36 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-1094-gc82cddcf98 03:42:12 03DracoOmega02 07* 0.33-a0-1095-gb58ee74901: Fix two spell flavor texts not showing in-game 10(2 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/b58ee749017d 04:32:31 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:31:13 Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-1095-gb58ee74 (34) 06:47:37 <06m​umra> Weird idea ... Change the spell success penalty for shields so that it doesn't apply if either you're unarmed, or you're wielding a magical stave. Lore wise I'm thinking "having a free hand" means you can still cast spells unimpeded, or with a magical stave you can cast spells through the stave. But having a weapon in one hand and a shield in the other how are you casting spells now, that's when you need a lot of shield skill to cast 06:47:38 spells effectively. The thinking here is would this make stave+shield or unarmed+magic+shield more interesting choices as it frees up some skill xp to work on other skills first rather than being mandated to drop a minimum amount of xp into shields as soons as you find one? Shields can still be worked on for extra SH but it lets you pick up a big shield sooner. Later if you want to pivot to another weapon you have more time to get shields and/or magic 06:47:38 skills up to required level for the shield penalty. 06:57:37 <02M​onkooky> stave + shield is kind of already the default for casters, isn't it? 07:08:42 <06m​umra> My own experience trying to play that combination is you have to train so many skild for the stave to be useful in melee its pretty annoying, and you probably want a real weapon to swap to for melee 07:21:17 <06r​egret-⸸nde※> Low amounts of evocations training is relatively popular even on mages between the current power level of gravitambourine and having some low mp option, though I'm not greatly fond of our awkward weapon-swapping interface anyway as-is for multiple staves and this would further pressure that front. 07:23:11 <04d​racoomega> I also think that 'staff+shield' is reasonably popular at the moment for casters, but even if it weren't, I'm not sure this actually would change what players would want to use as a weapon, so much as make it considerably better to swap your weapon away whenever you wanted to cast anything, and then swap back when you want to hit stuff. 07:23:57 <04d​racoomega> Like, you're already incentivized to swap to an enhancer staff and back again, if you have a different main weapon and a relevant staff, but this would make that an even bigger a much larger percentage of the time. 07:27:43 <09h​ellmonk> Would rather casters have more viable non shield options (especially some kind of 2h weapon) 07:29:30 <04d​racoomega> (I do want to do orb things in 0.34) 07:29:46 <04d​racoomega> I mean, two-hander stuff is also good to be more conceptually viable, too 07:30:50 <06r​egret-⸸nde※> (I... hmm, how many of the upcoming forms that help spellcasters work with shields or not?) 07:34:37 <06r​egret-⸸nde※> (So far I guess that's two that allow shields, one that doesn't that supports all magic, and three that don't and incidentally help one school.) 09:06:17 <12g​e0ff> > does anyone have strong opinions on https://github.com/crawl/crawl/pull/3249 I have a strong opinion about this PR. It would be extremely useful, esp. for berserkers/chars with *Rage/Ru worshippers, as it frees the player from manually resting cooldowns off. There are a bunch of stale and just incorrect things, though: * Fire can't be rested away now * Howl is also questionable on that list * Paralysis/Sleep/Petrified don't require any 09:06:17 additional handling * Trying to rest away Corrosion could turn into infinite waiting if the player is next to a slime wall * All zero stat statuses are gone * the PR adds flags to already removed statuses for no reason * and, more importantly, there's no need to have both explore_auto_rest_status_set and explore_auto_rest_status. The latter could have a default list of bad statuses, and, if we just use status/cooldown/duration names, then 09:06:18 explore_auto_rest_status_set and the two new flags are completely unnecessary 09:09:48 <09g​ammafunk> I mentioned your last point already above, yes. Think you'd probably want special terms in explore_auto_rest_status to match those groups (at least for the cooldowns) 09:10:29 <09g​ammafunk> I do agree with the rest of your points, although I haven't looked at the implementation in great detail, since I assumed I'd have to refactor/clean up a bunch of it 09:10:37 <09g​ammafunk> But I was more interested in problems with the general idea 09:10:46 <09g​ammafunk> and I do think the PR notes one potentially significant problem 09:11:19 <09g​ammafunk> which is that if you don't have any sanity checking on long waits in general, people can set entries that will cause indefinite rest (like the issue you mentioned with corrosion) 09:11:34 <09g​ammafunk> but one could trigger that easilly with a variety of statuses 09:11:40 <09g​ammafunk> so I'm not sure of the technical approach there 09:12:27 <09g​ammafunk> it's possible we need a combination of a check for a status lasting indefinitely, to the extent that's possible, and some kind of max rest time 09:13:10 <09g​ammafunk> then again, players can do all sorts of rc things to make their character behave very badly and we might want ot just cover the very common problematic cases 09:14:49 <12g​e0ff> a player adds explore_auto_rest_status += zot to their rc, presses 5, and the game tries to rest the zot timer off 09:14:58 <09g​ammafunk> yes 09:15:15 <09g​ammafunk> your corrosion example is probably more appropriate 09:15:25 <09g​ammafunk> since it'd be easy for a player to think "sure I'll rest off corrosion" 09:15:30 <09g​ammafunk> and then they go to dis... 09:16:10 <12g​e0ff> oh, right, there's will/2 in the pr too 09:16:27 <12g​e0ff> which could give an infinite resting in Tar 09:16:35 <09g​ammafunk> yeah I went through this fun with qw already, which has its own code to rest of negative durations 09:16:59 <09g​ammafunk> hence naturally in its first "new hell" attempts got to 0 oka piety by resting (and almost died to zot status) 09:17:27 <09g​ammafunk> (it died anyhow for other reasons but I think I saved it from dying to zot status) 09:17:32 <09g​ammafunk> !lg qw boring dis 09:17:34 <04C​erebot> No games for qw (boring dis). 09:17:43 <09g​ammafunk> !lg qw dis s=ckaux 09:17:45 <04C​erebot> 8 games for qw (dis): 5x damnation, 2x crystal spear, iron shot 09:22:48 <12g​e0ff> one approach could be doing something smaller, like adding a boolean option for resting only the finite cooldowns: -berserk, -breath, Exh, -ddoor, -vortex, -dcall, -recite, -hop, -word, -siphon, -swiftness, and -blink 09:25:27 <12g​e0ff> (and -blinkbolt, -dog, -gavotte too) 11:15:45 <09g​ammafunk> well, that doesn't solve the problem of debuffs 11:16:58 <09g​ammafunk> it might be fairly straightforward to enumerate the finite statuses, or more acturately "the statuses one should try to rest off" 11:17:13 <09g​ammafunk> technically, zot status is finite! 11:17:46 <09g​ammafunk> I suppose all statuses are ultimate finite, if you consider the ultimate game turncount cap.... 11:28:50 <09g​ammafunk> I'll just take a look at implementing a sufficiently "good" version of this option. There's no rush, and it can't be that bad to implement....can it...??? 12:51:29 <04C​gettys> I mean, it'd be painful, but surely one could special case it all? If tar, don't rest off will/2, etc etc etc 13:01:40 <09g​ammafunk> I can't imagine it'd be that difficult, no, it's mostly the pain of refactoring probably 13:01:50 <04C​gettys> Maybe a less stupid idea - if any duration / amount goes up or doesn't go down within x aux, break 13:02:13 <04C​gettys> (less stupid than my previous idea I mean) 13:02:34 <09g​ammafunk> It's also just a low priority feature so there's no rush to go diving in full steam. This is for a PR from 2023, after all 13:03:12 <09g​ammafunk> (Ideally we'd get to these at a faster rate on average rather than trying to do these huge batches close to release) 13:03:27 <04C​gettys> fair 13:03:28 <09g​ammafunk> (but some PRs are tougher to go through than others) 13:05:19 <04C​gettys> This one might be worth just closing https://github.com/crawl/crawl/pull/2118 The msbuild based one is working again 13:11:12 <09g​ammafunk> ooh, lua 5.4 support 13:11:14 <09g​ammafunk> this is one I really want 13:11:32 <09g​ammafunk> of course it might be a huge can of worms...I wonder if I can get that done before release 13:11:51 <09g​ammafunk> there are some technical issues remaining that I think I understand enough or could understand enough to get it working 13:12:27 <04C​gettys> I just went through https://github.com/crawl/crawl/pull/3715/files as well. it has merge conflicts these days, but besides that I don't see anything that would make me say no to this even if it were at my day job 😄 13:13:32 <06m​umra> @Cgettys Re: the ccache warning PR, i am really just wondering if anyone responsible for any build servers can comment on potential impact or otherwise of that PR. I don't know enough about potentially affected systems to be confident merging it 13:13:51 <09g​ammafunk> it's just a warning in the form of text output, right? 13:14:15 <09g​ammafunk> generally official servers do build with ccache for obvious reasons, but previous nothing stopped the build if ccache wasn't installed/used, of course 13:14:20 <06m​umra> Yes (but certainly in some CI processes one might fail on warnings) 13:14:30 <04C​gettys> RIght, and in the unlikely event that the warning was a problem 13:14:35 <04C​gettys> you just pass SUPPRESS_BUILD_CHECKS=y 13:14:37 <09g​ammafunk> well, I don't think any CI processes are grepping the text output of the build to catch errors 13:14:59 <09g​ammafunk> they generall just look at process return values iirc 13:15:13 <04C​gettys> I definitely have seen such hare-brained schemes 13:15:18 <09g​ammafunk> obviously one could make CI workflows that inspected output but it's generally not done 13:15:20 <04C​gettys> but I doubt the crawl servers do 😄 13:15:43 <09g​ammafunk> also CI would be irrelevant to official servers, of course 13:16:10 <09g​ammafunk> officials servers just run their own build from a checkout using some specialized "dgamelaunch-config" scripts and don't interact with github CI at all 13:16:17 <04C​gettys> Right, and I was careful to only use tools used elsewhere in the script 13:16:24 <09g​ammafunk> they do check out/update from github, of course 13:16:27 <04C​gettys> like which etc 13:16:29 <09g​ammafunk> but yeah that shouldn't affect any server 13:16:45 <04C​gettys> Worse case, we add SUPPRESS_BUILD_CHECKS=y or revert 13:17:26 <09g​ammafunk> @Cgettys I think I noticed from your checkcommit python pr that you had only partially converted your script to python format strings over the old % syntax 13:17:41 <09g​ammafunk> and was going to leave a comment about that; it was just like one or two lines you missed iirc 13:17:41 <04C​gettys> Oh, did I miss some? let me fix that 13:17:55 <09g​ammafunk> yeah, and I need to get to that pr as well obv 13:18:10 <09g​ammafunk> probably should use it as an opportunity to test CI changes in my own clone 13:18:59 <09g​ammafunk> it's scary to merge CI stuff when you can't test. just in the sense of not knowing whether something is broken or not....although I guess the CI of the commit in question should answer that question of correctness generally.... 13:20:57 03Cgettys02 07https://github.com/crawl/crawl/pull/4312 * 0.33-a0-1090-g9d29aba6b1: ci: fix checkconventionalcommit.py 10(4 weeks ago, 2 files, 6+ 4-) 13https://github.com/crawl/crawl/commit/9d29aba6b162 14:41:18 03Cgettys02 07https://github.com/crawl/crawl/pull/4312 * 0.33-a0-1090-gb2c00bc80d: ci: fix checkconventionalcommit.py 10(4 weeks ago, 2 files, 6+ 4-) 13https://github.com/crawl/crawl/commit/b2c00bc80dd1 14:41:43 <04C​gettys> In this case it's especially scary because the conditional is based on what repo it's running in, in part 😄 14:41:46 <04C​gettys> but yes 14:41:58 <04C​gettys> however, the conventional commit check currently never is blocking 14:42:06 <04C​gettys> it'll just warn in the checks if you go look at it 14:47:00 <04C​gettys> https://github.com/crawl/crawl/pull/4364/files looks trivial, google translate says it adds up ("a simple rock wall") 14:53:15 <09g​ammafunk> It's missing a period 14:55:26 <04C​gettys> Think it's intentional? not all places that say "A rock wall" have p eriods either"? 14:55:26 <04C​gettys> https://github.com/search?q=repo%3Acrawl%2Fcrawl+%22A+rock+wall%22&type=code 15:00:53 03DracoOmega02 07* 0.33-a0-1096-g45411cbfb5: Very gently buff poltergeist and nerf revenant 10(4 minutes ago, 3 files, 3+ 2-) 13https://github.com/crawl/crawl/commit/45411cbfb528 15:00:53 03DracoOmega02 07* 0.33-a0-1097-g6ed86a1e71: Give revenants one memory charge when they hit XL 3 10(3 minutes ago, 1 file, 5+ 0-) 13https://github.com/crawl/crawl/commit/6ed86a1e71d0 15:46:22 quixfox (L27 CoGl) ASSERT(mon) in 'fight.cc' at line 1303 failed. (Slime:1) 15:48:04 !crashlog quixfox 15:48:06 1. quixfox, XL27 CoGl, T:90893 (milestone): https://crawl.akrasiac.org/rawdata/quixfox/crash-quixfox-20250316-224620.txt 15:49:35 quixfox (L27 CoGl) ASSERT(mon) in 'fight.cc' at line 1303 failed. (Slime:4) 15:50:53 safe_discharge is passing a NULL mon to bad_attack during a cast of manifold assault 15:52:49 quixfox (L27 CoGl) ASSERT(mon) in 'fight.cc' at line 1303 failed. (Slime:5) 15:54:06 quixfox (L27 CoGl) ASSERT(mon) in 'fight.cc' at line 1303 failed. (Slime:5) 15:54:14 <12g​e0ff> yeah, it's easy to reproduce if you cast MA with arc blade when there's a bunch of monsters nearby 15:54:27 quixfox (L27 CoGl) ASSERT(mon) in 'fight.cc' at line 1303 failed. (Slime:5) 16:21:41 <04C​gettys> @mumra - re https://github.com/crawl/crawl/pull/4379, I wonder if that might be an interesting effect for a high-level hexes spell too, maybe hexes/tloc? dunno, just an idea 16:24:50 <04C​gettys> As for this... https://github.com/crawl/crawl/pull/4275 added MA + arc blade recently, maybe we should back it out if not able to fix forward? 16:26:23 <04d​racoomega> Actually, this may be a result of me refactoring the static discharge warning prompts after that to fix another issue with them 16:26:27 <04d​racoomega> Taking a look 16:26:54 <04d​racoomega> Immediate point of concern (and easy fix) if this is it 16:30:56 03DracoOmega02 07* 0.33-a0-1098-gdbf6267756: Fix an arc blade crash with Manifold Assault 10(61 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/dbf62677566e 16:34:39 <09g​ammafunk> You have to understand what the format of this file is. The "A rock wall" part is the key in this lookup 16:34:46 <09g​ammafunk> so it should not have a period 16:35:02 <09g​ammafunk> but the content should contain grammatically correct sentences 16:35:03 <04C​gettys> I thought you were complaining about the key half not having a period 16:35:18 <09g​ammafunk> no, the entry itself is missing one 16:35:19 <09g​ammafunk> look at the entries above and below 16:36:33 <04C​gettys> You're right, I was comparing to the other language files and misreading things 16:36:38 <04C​gettys> it should have a period 16:38:03 <04C​gettys> And a PR description 16:38:09 <04C​gettys> and be squashed 😄 16:39:08 <09g​ammafunk> does that second commit even have any content? 16:39:13 <09g​ammafunk> pretty confused about that one 16:39:16 <04C​gettys> I couldn't find any 16:39:33 <04C​gettys> Honestly, probably easiest to just rewrite teh whole commit at that point 16:40:05 <09g​ammafunk> well I'll see if the github UI will oblidge 16:40:13 Unstable branch on underhound.eu updated to: 0.33-a0-1097-g6ed86a1e71 (34) 16:42:15 <04C​gettys> I could open a fresh PR, but that just seems like it'd be even more work for you 17:21:31 <09g​ammafunk> I'm going to try editing the pr from github ui 17:22:29 <09g​ammafunk> well, scratch that, I'm just going to rebase it locally and push 17:22:39 <09g​ammafunk> hard to delete commits from the UI (impossible?) 17:23:29 I don't know of a way 17:48:00 03person5060502 {gammafunk} 07* 0.33-a0-1099-gb9a02fdcf7: Add rock wall description for spanish version 10(6 days ago, 1 file, 4+ 0-) 13https://github.com/crawl/crawl/commit/b9a02fdcf7ca 22:08:06 <06m​umra> I had an idea for a while for actually an Alchemy (+Hexes?) spell that applies some form of mass debuff to AC/SH. Like "transmutes armour temporarily to gold". Of course there is already an in development area corrosion spell (although I haven't seen any indication of it being worked on for this release) so this needs a way to be distinct. Having to hit twice could be a thing (buffs your weapon with a "Midas' touch"-like effect, 22:08:06 halving their defences when you hit them). But to compete with other high level spells you need to be affecting a lot of targets at once, or doing a lot of damage to less targets; something that takes effectively 3 turns to do anything (1 to cast the spell, 2 turns to actually hit the thing) doesn't seem great compared to more immediate options. 22:19:02 <04C​gettys> Having it take the strongest stat down straight-up would be interesting 22:20:13 <04C​gettys> hmm 22:20:17 <04C​gettys> well, idk 22:20:28 <04C​gettys> maybe another idea would be to have it punch thru will better than most hexes 22:20:58 <04C​gettys> say, make it only consider half their will, or some fixed reduction to their will 22:21:24 <04C​gettys> so it doesn't have to be lots of targets, but instead lets you take on things that would resist most other spells 22:29:34 <09h​ellmonk> this effect seems likely to be pretty narrow unless it's irresistible and large. For some points of comparison, bvc reduces monster EV without a check (provided it can be constricted), and irradiate has a flat 50% chance to drop their AC by 8 via the malmutate debuff. I guess some characters might want it specifically to get through problem monsters like orb of fire or curse toe in zot, but usually characters that can take advantage of 22:29:34 the big aoe can just use their big aoe damage spell again. 22:53:25 <06m​umra> irresistible and large was the idea there 23:00:40 <09h​ellmonk> well now you've got me wanting it so that I can lrd orbs of fire easier 23:03:25 <06m​umra> i am not sure conceptually how transmuting an OoF's "armour" into gold even works nor makes them more susceptible to damage 23:03:32 <06m​umra> but that can be worked on 23:13:41 Unstable branch on cbro.berotato.org updated to: 0.33-a0-1099-gb9a02fdcf7 (34) 23:35:45 Unstable branch on crawl.develz.org updated to: 0.33-a0-1099-gb9a02fdcf7 (34) 23:58:54 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-1099-gb9a02fdcf7