00:07:16 03dolorous02 07* 0.32-a0-433-g08bcfe7efd: Fix "Brilliance" inscription: Halo -> Umbra. 10(77 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/08bcfe7efda4 02:36:55 -!- 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 02:36:56 -!- The topic of #crawl is: Play Dungeon Crawl Stone Soup online now! Type ??online for instructions, ??lg / !lg for play stats | PM Sequell for long queries | http://crawl.develz.org | FooTV game replays: ??footv for instructions | #crawl-dev for dev discussion, #crawl-offtopic for offtopic 02:55:08 Monster database of master branch on crawl.develz.org updated to: 0.32-a0-433-g08bcfe7efd 03:21:30 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-462-gc38d1add40: Allow spell/summon kills to heal during bloodcraze 10(80 minutes ago, 6 files, 39+ 18-) 13https://github.com/crawl/crawl/commit/c38d1add40c1 03:21:30 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-463-g4aa36d09a1: Partially revert bloodcraze nerfs 10(71 minutes ago, 2 files, 4+ 4-) 13https://github.com/crawl/crawl/commit/4aa36d09a1b4 03:21:30 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-464-g1947bbc1b1: Move blood drain message before kill message 10(69 seconds ago, 1 file, 26+ 26-) 13https://github.com/crawl/crawl/commit/1947bbc1b14d 03:22:40 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-462-gc38d1add40: Allow spell/summon kills to heal during bloodcraze 10(81 minutes ago, 6 files, 39+ 18-) 13https://github.com/crawl/crawl/commit/c38d1add40c1 03:22:40 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-463-g4aa36d09a1: Partially revert bloodcraze nerfs 10(72 minutes ago, 2 files, 4+ 4-) 13https://github.com/crawl/crawl/commit/4aa36d09a1b4 03:22:40 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-464-g1947bbc1b1: Move blood drain message before kill message 10(2 minutes ago, 1 file, 26+ 26-) 13https://github.com/crawl/crawl/commit/1947bbc1b14d 04:06:10 Unstable branch on crawl.kelbi.org updated to: 0.32-a0-433-g08bcfe7efd (34) 04:06:10 Unstable branch on crawl.kelbi.org updated to: 0.32-a0-433-g08bcfe7efd (34) 04:10:53 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-5140-g5775ae71e1 04:10:53 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-5140-g5775ae71e1 04:11:44 -!- TAS-2012v is now known as TAS_2012v 04:25:18 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-465-gc802c53f26: Checkwhite 10(41 seconds ago, 2 files, 2+ 3-) 13https://github.com/crawl/crawl/commit/c802c53f26e2 04:28:51 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-465-gc802c53f26: Checkwhite 10(4 minutes ago, 2 files, 2+ 3-) 13https://github.com/crawl/crawl/commit/c802c53f26e2 04:53:34 grothendieck (L21 MDFi) ERROR in 'mon-cast.cc' at line 1782: Unknown monster spell 'Vhi's Electric Charge' cast by Olfrun (Depths:1) 05:12:07 -!- TAS-2012v is now known as TAS_2012v 05:54:11 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-466-gfba394a350: Allow blood drain to work on misses and blocks 10(46 seconds ago, 3 files, 13+ 2-) 13https://github.com/crawl/crawl/commit/fba394a350f4 05:55:21 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-466-gfba394a350: Allow blood drain to work on misses and blocks 10(2 minutes ago, 3 files, 13+ 2-) 13https://github.com/crawl/crawl/commit/fba394a350f4 06:17:18 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-467-g9182a803e9: Unbrace 10(58 seconds ago, 1 file, 3+ 13-) 13https://github.com/crawl/crawl/commit/9182a803e965 06:20:48 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-467-g9182a803e9: Unbrace 10(4 minutes ago, 1 file, 3+ 13-) 13https://github.com/crawl/crawl/commit/9182a803e965 06:33:03 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5140-g5775ae71e1 07:30:38 Unstable branch on crawl.akrasiac.org updated to: 0.32-a0-433-g08bcfe7 (34) 10:37:49 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-468-g4c8bf91ac0: Adjust bloodcraze healing cap 10(2 hours ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/4c8bf91ac018 10:40:24 03SentientSupper02 07https://github.com/crawl/crawl/pull/3529 * 0.32-a0-468-g4c8bf91ac0: Adjust bloodcraze healing cap 10(2 hours ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/4c8bf91ac018 11:10:47 <04d​racoomega> C++ bool bolt::can_knockback(int dam) const { switch (origin_spell) { case SPELL_PRIMAL_WAVE: return flavour == BEAM_WATER; ??? 11:11:00 <04d​racoomega> Just in case those primal waves that are not water don't have knockback??? 11:14:46 <04d​racoomega> I didn't mean to say that it produces incorrect results for what it's used for (at the time I said that, I hadn't realized it was used on the info screen; I was mostly referring to it switching based on spell type instead of actual explosive radius, but that makes sense given it being called for spells that are not currently happening) 11:15:00 <04d​racoomega> Though it does look like it's more or less wrong for LRD now 11:15:31 <04d​racoomega> (Suggests noise as if they have a radius 2 explosion, with a comment of case SPELL_LRD: // Can reach 3 only with crystal walls, which are rare but that's not been true for a while) 12:01:47 03nicolae02 07[brokenarts] * 0.32-a0-422-gbba8846a1a: Add a shop using the new artprops feature (gammafunk) 10(74 seconds ago, 1 file, 18+ 0-) 13https://github.com/crawl/crawl/commit/bba8846a1aa3 12:02:33 03nicolae02 07[brokenarts] * 0.32-a0-422-gbba8846a1a: Add a shop using the new artprops feature (gammafunk) 10(2 minutes ago, 1 file, 18+ 0-) 13https://github.com/crawl/crawl/commit/bba8846a1aa3 12:04:17 <03w​heals> definitely wouldn't be surprised if there are some errors with the noise not actually being right, especially with something like lrd 12:20:18 03nicolae02 07[brokenarts] * 0.32-a0-423-ge3804525d2: Touch up the Clear Minds Boutique just a skosh 10(28 seconds ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/e3804525d2a5 12:20:23 03nicolae02 07[brokenarts] * 0.32-a0-423-ge3804525d2: Touch up the Clear Minds Boutique just a skosh 10(30 seconds ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/e3804525d2a5 12:51:16 03gammafunk02 07* 0.32-a0-434-g1e417eb1c6: feat: Specifying fixed properties for randarts 10(5 days ago, 7 files, 184+ 46-) 13https://github.com/crawl/crawl/commit/1e417eb1c67c 12:51:16 03gammafunk02 07* 0.32-a0-435-g84f73fd571: feat: Rework wizmode artefact and randart stats 10(2 days ago, 3 files, 108+ 271-) 13https://github.com/crawl/crawl/commit/84f73fd571b0 12:51:16 03gammafunk02 07* 0.32-a0-436-g387adf243f: feat: Simplify formulas for artefact properties (elliptic) 10(27 hours ago, 1 file, 8+ 6-) 13https://github.com/crawl/crawl/commit/387adf243f85 12:51:16 03nicolae02 {gammafunk} 07* 0.32-a0-437-g7902d401d8: Add a shop using the new artprops feature (gammafunk) 10(51 minutes ago, 1 file, 18+ 0-) 13https://github.com/crawl/crawl/commit/7902d401d86a 12:51:16 03nicolae02 {gammafunk} 07* 0.32-a0-438-g4efcb1c6c7: Touch up the Clear Minds Boutique just a skosh 10(31 minutes ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/4efcb1c6c77e 12:51:47 03gammafunk02 07* 0.32-a0-434-g1e417eb1c6: feat: Specifying fixed properties for randarts 10(5 days ago, 7 files, 184+ 46-) 13https://github.com/crawl/crawl/commit/1e417eb1c67c 12:51:49 03gammafunk02 07* 0.32-a0-435-g84f73fd571: feat: Rework wizmode artefact and randart stats 10(2 days ago, 3 files, 108+ 271-) 13https://github.com/crawl/crawl/commit/84f73fd571b0 12:52:00 03gammafunk02 07* 0.32-a0-436-g387adf243f: feat: Simplify formulas for artefact properties (elliptic) 10(27 hours ago, 1 file, 8+ 6-) 13https://github.com/crawl/crawl/commit/387adf243f85 12:52:12 03nicolae02 {gammafunk} 07* 0.32-a0-437-g7902d401d8: Add a shop using the new artprops feature (gammafunk) 10(51 minutes ago, 1 file, 18+ 0-) 13https://github.com/crawl/crawl/commit/7902d401d86a 12:52:23 03nicolae02 {gammafunk} 07* 0.32-a0-438-g4efcb1c6c7: Touch up the Clear Minds Boutique just a skosh 10(32 minutes ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/4efcb1c6c77e 13:39:34 <13q​wqwqwqwqwqwqw> copying here the newest coglin drawback proposal (to replace -move and maybe also rev): no jewellery allowed, but at level 14 you get a power spike, possibly something like the following: take the 6 properties rF+ rC+, rElec rPois, AC+5 or EV+5 (one of them), Slay+4, Rampage Acrobat, Regen MPRegen, and randomly group them into 3 groups of 2, then let the player choose one group 13:41:38 <13q​wqwqwqwqwqwqw> (obviously precise details are open to tweaking, e.g. could only forbid rings and have a weaker power spike - I think the simplest version of this is PF's suggestion of no rings but get rF+ rC+ at some XL) 13:57:50 <04d​racoomega> For the record, I like this proposal a fair bit - or some tweaked variation on this, at the very least. Combines reasonable degrees of 'guaranteed value', still has obvious downsides attached (even if it ends up as good as a jewelry set, it comes later, and certainly isn't as good as good ones), feels reasonably species-unique. I think my main quibble is that it might be nice for a few options to be a bit less generic, but I don't 13:57:50 think that's a blocker either way. 13:58:12 <04d​racoomega> That is the sort of thing that's extremely possible to adjust down the road, also 14:05:53 03PleasingFungus02 07* 0.32-a0-439-ge3e1ee326f: Fix tab with off-hand reaching 10(7 minutes ago, 2 files, 25+ 7-) 13https://github.com/crawl/crawl/commit/e3e1ee326f0f 14:06:09 03PleasingFungus02 07* 0.32-a0-439-ge3e1ee326f: Fix tab with off-hand reaching 10(8 minutes ago, 2 files, 25+ 7-) 13https://github.com/crawl/crawl/commit/e3e1ee326f0f 14:12:39 <02M​onkooky> I also think this is cool think this manages to be a downside, but feel like an upside 14:13:16 <02M​onkooky> I've got a couple thoughts on precise details but that feels premature rn 14:22:51 03elliptic02 07* 0.32-a0-440-g1f14e3f6c3: Don't place hand cannon clouds on top of the player 10(66 minutes ago, 1 file, 2+ 3-) 13https://github.com/crawl/crawl/commit/1f14e3f6c323 14:22:55 03elliptic02 07* 0.32-a0-440-g1f14e3f6c3: Don't place hand cannon clouds on top of the player 10(66 minutes ago, 1 file, 2+ 3-) 13https://github.com/crawl/crawl/commit/1f14e3f6c323 14:23:29 <13q​wqwqwqwqwqwqw> btw why do we have both Chei and NotChei 14:23:47 because |amethyst's old machine got rebooted 14:24:07 I don't think he has access any more to get rid of it 14:32:51 javelincjr (L10 CoMo) ASSERT(defender->alive()) in 'fight.cc' at line 293 failed. (D:8) 15:00:24 <09g​ammafunk> woah 15:00:27 <09g​ammafunk> chei returned 15:00:39 <09g​ammafunk> we could just ban Chei from the channel if we wanted 15:19:30 <09g​ammafunk> definitely fun trying to write up the details of these fixed props our syntax doc. Shame I don't have a better place to refer people to for the artp names other than "See this variable in artefact.cc". I guess I could just provide the list in the syntax doc and hope people remember to update it somehow... 15:19:41 <09g​ammafunk> Need the yamlification of artps 15:20:55 <09g​ammafunk> Telling people about how some artps don't work on some item types is even worse 15:21:15 <09g​ammafunk> just going to have to tell the reader to try it in wizmode &% or something 15:24:02 <06p​leasingfungus> lol 15:24:06 <06p​leasingfungus> !crashlog javelincjr 15:24:07 <04C​erebot> 1. javelincjr, XL10 CoMo, T:6358 (milestone): https://cbro.berotato.org/morgue/javelincjr/crash-javelincjr-20240222-193250.txt 15:25:18 <06p​leasingfungus> oh wow 15:25:23 <06p​leasingfungus> co beogh crash 15:25:26 <06p​leasingfungus> scary 15:26:16 <09g​ammafunk> Do we not have gdb mentioned in the chroot installation for dgamelaunch stuff 15:26:31 <09g​ammafunk> Feels like no server has it these days 15:31:20 <04d​racoomega> Not sure coglin is involved there actually, looking at it. Stack trace says it's during a monster turn. (Not immediately clear what the problem is, though) 15:31:31 <06p​leasingfungus> yeah, does look coglin unrelated 15:31:38 <06p​leasingfungus> seems like a monster is somehow trying to attack a dead monster 15:31:39 <04d​racoomega> Only visible monsters seem to be that apostle and a foxfire 15:32:10 <04d​racoomega> (The apostle can be 'dead' in the middle of things, but the log suggests that's already finished, though?) 15:32:46 <04d​racoomega> Wondering if it's possible this is some weird foxfire interaction 15:33:40 <04d​racoomega> Like, I realize I'm unsure what happens to a still-living foxfire when the apostle that cast it converts 15:33:57 <06p​leasingfungus> yeah i am suspicious of the foxfires. 15:34:28 <06p​leasingfungus> would be wonderful to know which monster was acting 15:35:26 <04d​racoomega> It would, yes 15:35:38 <04d​racoomega> On a quick test, foxfires remain hostile but function normally (one hit its own caster) 15:36:01 <04d​racoomega> But I wonder if something weird happens if somehow the caster tries to walk into its own foxfire, which is now hostile? 15:36:20 <04d​racoomega> Hard to deliberately arrange this to happen 15:37:31 <04d​racoomega> I suppose I can try to test that outside of challenge circumstances 15:39:22 <04d​racoomega> Okay, not even managing to get a hasted executioner to act before its own foxfires hit it 15:39:33 <02M​onkooky> what happens on apostle convert? 15:39:40 <02M​onkooky> to like, mon ids and suchlike 15:39:54 <04d​racoomega> The apostle's mid doesn't change. It just changes attitude. 15:43:10 <02M​onkooky> do C stack traces contain any line num info? 15:44:28 <04d​racoomega> I feel like we get stack traces of differing detail depending on the server the crash log comes from 15:44:32 <04d​racoomega> Or something 15:44:47 <04d​racoomega> At least some of them seem to have more detail than others 15:45:40 <04d​racoomega> (Poor Windows version gets no stack trace at all) 15:47:13 <02M​onkooky> yeah... 15:47:51 <02M​onkooky> ok think there's a real chance this is to do with attacking own foxfire 15:55:30 <04d​racoomega> Is there something specific you think you've noticed? 15:58:42 <02M​onkooky> the condition for fight_melee to be called in handle_monster_move is if (targ && targ != mons && mons->behaviour != BEH_WITHDRAW && (!(mons_aligned(mons, targ) || targ->type == MONS_FOXFIRE) || mons->has_ench(ENCH_FRENZIED)) && monster_los_is_valid(mons, targ)) { 15:59:59 <02M​onkooky> and the targ->type == mons_foxfire seems unusual enough that it makes me leery 16:05:43 <04d​racoomega> That just seems to make a foxfire eligable to try to move into, even if it is aligned with you, I think? 16:06:07 03dolorous02 07* 0.32-a0-441-gaf4921d101: Add "Brilliance" quote. 10(15 minutes ago, 1 file, 13+ 0-) 13https://github.com/crawl/crawl/commit/af4921d101aa 16:06:24 03dolorous02 07* 0.32-a0-441-gaf4921d101: Add "Brilliance" quote. 10(15 minutes ago, 1 file, 13+ 0-) 13https://github.com/crawl/crawl/commit/af4921d101aa 16:06:34 <04d​racoomega> I've been unable to get anything weird or crashy to happen with various testing of switching alignments between caster and foxfire, thus far 16:06:34 re server crash logs, iirc the only difference is that kelbi had gdb installed 16:07:04 the C backtrace functionality is the same on all of them, and doesn't support looking up line numbers 16:09:50 <02M​onkooky> hm- it actually makes it inelegible to try to move into even if aligned 16:12:02 <04d​racoomega> Oh, misread bracketing 16:12:36 <04d​racoomega> (I mean, maybe this crash just has nothing to do with that foxfire at all ^^; ) 16:14:47 <02M​onkooky> !log javelincjr 16:14:49 <04C​erebot> 1769. javelincjr, XL6 MDMo, T:3367: https://cbro.berotato.org/morgue/javelincjr/morgue-javelincjr-20240222-202345.txt 16:19:39 <02M​onkooky> hm, guy kept playing without the offhand handaxe 16:19:47 <02M​onkooky> !log javelincjr co 16:19:48 <04C​erebot> 6. javelincjr, XL10 CoMo, T:7165: https://cbro.berotato.org/morgue/javelincjr/morgue-javelincjr-20240222-194558.txt 16:24:09 <02M​onkooky> hold on, I actually have somethin 16:24:19 <02M​onkooky> (maybe) 16:24:37 <02M​onkooky> (no) 16:27:06 <02M​onkooky> @dracoomega can you point me to the code for post-challenge apostle healing? 16:27:18 <02M​onkooky> or general challenge completion 16:45:09 <02M​onkooky> Is this an error with getting attacked before the avoided_death fineff triggers? 16:48:17 <02M​onkooky> yes, I think it is- the crash is on ASSERT(defender->alive()); which checks if defender's HP is > 0 by my read the disciple dying sets their hp to max, stores that value in a fineff, then sets their hp to a negative value? 16:49:51 <02M​onkooky> which if they get attacked somehow while the avoided_death fineff is scheduled but not fired, means they'll register as 'dead' for certain effects 18:36:12 Unstable branch on underhound.eu updated to: 0.32-a0-441-gaf4921d101 (34) 18:47:30 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:32 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:34 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:35 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:37 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:39 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:43 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:46 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:50 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:54 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:47:58 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:01 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:05 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:09 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:12 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:15 o.O 18:48:16 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:20 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:24 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:27 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:31 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:35 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:38 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:42 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:46 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:49 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:53 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:48:57 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:06 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:06 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:08 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:12 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:15 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:19 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:23 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:27 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:30 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:34 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:49:38 ShinQuickMan (L18 DECj) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -36,1 in region 2, should be 1,1 in region 3) (Orc:2) 18:51:31 <06p​leasingfungus> uh 18:53:00 sneaking suspicion whatever's wrong is triggering on game load 18:53:09 !crashlog 18:53:17 27209. ShinQuickMan, XL18 DECj, T:49512 (milestone): https://cbro.berotato.org/morgue/ShinQuickMan/crash-ShinQuickMan-20240222-234819.txt 18:54:14 hm, doesn't look like it 19:58:53 <04d​racoomega> I wondered about the interaction with this fineff (note: the way this works isn't my doing or new!) but it's not clear to me how a fineff isn't firing before some other monster gets to act. Maybe worth noting, however, that I think the apostle died to poison. If you note the absence of any other thing seeming to cause its death in the logs. 19:59:03 <04d​racoomega> But poison is triggered on the apostles own turn 19:59:15 <02M​onkooky> yeah, that was my thought 19:59:16 <04d​racoomega> So how could it be attacking itself there? 19:59:36 <04d​racoomega> Pretty sure there was no source of it being confused, right? 19:59:42 <02M​onkooky> isn't poison in pre_monster_move 19:59:55 <04d​racoomega> ...is it? 20:00:09 <02M​onkooky> think poison, clouds, and sticky flame are all in pre_monster_move 20:00:59 <04d​racoomega> I thought all enchantment updates were from the monster's own timeframe. Is that just their duration going down? 20:01:41 <02M​onkooky> // Apply monster enchantments once for every normal-speed // player turn. mons.ench_countdown -= you.time_taken; while (mons.ench_countdown < 0) { mons.ench_countdown += 10; mons.apply_enchantments(); 20:01:42 <04d​racoomega> C++ // Apply monster enchantments once for every normal-speed // player turn. mons.ench_countdown -= you.time_taken; while (mons.ench_countdown < 0) { mons.ench_countdown += 10; mons.apply_enchantments(); // If the monster *merely* died just break from the loop // rather than quit altogether, since we have to deal with // ballistomycete spores and ball lightning exploding 20:01:43 at the end of the // function, but do return if the monster's data has been // reset, since then the monster type is invalid. if (mons.type == MONS_NO_MONSTER) return; else if (mons.hit_points < 1) break; } Hmmm 20:01:46 <02M​onkooky> yup 20:02:18 <02M​onkooky> and all pre-monster move is handled before any monster move 20:02:34 <02M​onkooky> Don't actually know when the fineff is fired tho 20:03:30 <04d​racoomega> Well, fineffs certainly don't fire between this and a monster trying to move 20:04:01 <04d​racoomega> Looks like they will probably fire after the first monster in the round takes its action, whoever that is 20:04:50 <02M​onkooky> yeah, so if the apostle dies to an enchant or cloud, then gets hit by the first moster to act, they'll still be 'dead' 20:04:51 <04d​racoomega> I am really confused, then. Why are a bunch of monster enchantment durations specifically scaled to the speed of the monster if their triggering rate has nothing to do with the speed of the monster?? 20:05:09 <04d​racoomega> I assumed that was why they did that 20:05:16 <02M​onkooky> only fires if the mon has action energy 20:05:29 <02M​onkooky> void handle_monsters(bool with_noise) { for (monster_iterator mi; mi; ++mi) { _pre_monster_move(**mi); if (!invalid_monster(*mi) && mi->alive() && mi->has_action_energy()) monster_queue.emplace(*mi, mi->speed_increment); } 20:05:35 <02M​onkooky> wait 20:05:40 <02M​onkooky> no that's a lie 20:05:46 <04d​racoomega> Yeah, that's not how _pre_monster_move works 20:05:52 <04d​racoomega> That's where they get energy 20:06:09 <04d​racoomega> It's called once for everything, after each player action, but before any monster actions 20:06:22 <02M​onkooky> yeah I was reading the lines in the wrong order 20:06:49 <02M​onkooky> see: 20:07:35 <04d​racoomega> I am wondering now if this has multiple other weirdnesses 20:07:43 <04d​racoomega> Even if, yes, this seems likely the souce of this immediate crash 20:07:47 <02M​onkooky> quite possible 20:07:58 <02M​onkooky> I'll say this behaviour is hugely important tho 20:08:19 <02M​onkooky> for immolation if nothing else 20:08:44 <04d​racoomega> How does this directly work with immolation? 20:09:00 <04d​racoomega> That doesn't even tick 20:09:28 <02M​onkooky> if I lethally poison an inner flamed monster, I can step away from the monster and it'll explode before catching up 20:10:13 <02M​onkooky> if I use OTR versus immolated monsters, I don't need to care about monster action order killing me because the one that's not going to die acted before the one that is 20:10:15 <04d​racoomega> I mean, that would be true even if it happened at the start of the monster's own turn 20:10:25 <04d​racoomega> Wouldn't it? 20:10:38 <02M​onkooky> for the first of those yeah 20:11:06 <04d​racoomega> Note: I am not even immediately saying that the placement of this is a bad idea, but I am wondering if some stated assumptions elsewhere think that this isn't how it works 20:11:21 <02M​onkooky> right, yeah I get that and strongly suspect you are right 20:11:35 <04d​racoomega> For instance, I need to double check if this means that a bunch of things just last less absolute time on fast things without actually doing more 20:13:06 <02M​onkooky> just warning off changing the way this works instead of the gross hunt through spl-mon_ench 20:14:48 <04d​racoomega> (I mean, the fineff issue can be solved by just firing fineffs after all these things are updated (either after each monster or after all monsters) 20:15:12 <04d​racoomega> Can't be certain that this doesn't trip some other unexpected problem, but seems like a thing that should happen anyway 20:15:23 <04d​racoomega> After any batch of 'stuff happened' where something can die 20:16:32 <02M​onkooky> don't honestly get the purpose of the delayed_death fineff so I'll take your word for it 20:21:29 <02M​onkooky> well. polar vortex relies on speed 20:24:36 <02M​onkooky> faster mons will do less pvort damage 20:27:08 <04d​racoomega> Well, look at mon_enchant::calc_duration where the default durations of many things are scaled based on the monster's speed 20:27:26 <04d​racoomega> (Tons and tons of enchantments don't use these default durations, but a bunch do) 20:27:41 <02M​onkooky> oh dear 20:29:14 <02M​onkooky> Well, there you could argue that's intentional? 20:29:30 <02M​onkooky> Like, if I want to slow a thing for 'four actions' it should scale off mon speed 20:30:24 <02M​onkooky> mmm. I wonder if I'm somehow just entirely wrong 20:30:59 <04d​racoomega> Maybe it makes sense for things that do have their effect based on the monster's frame of reference, but it seems like things like poison/sticky flame do not? 20:32:24 <04d​racoomega> Wait, is it multiplying again later by a different factor of monster speed, at the end of that function?? 20:32:50 <02M​onkooky> this is baffling 20:35:48 <04d​racoomega> Yes, it kind of looks like it does some math and then more or less undoes that math before using the value?? 20:38:10 <04d​racoomega> With just a couple enchantments skipping this whole 'divide by factor then multiply by related factor' entirely and just return a duration right there 20:38:22 <04d​racoomega> Like inner flame, berserk, or rolling 20:40:16 <04d​racoomega> A lot of this hasn't changed in 12 years or something (when it was in another file altogether, so it might be even longer than that), but it's seeming increasingly baffling to me 20:42:01 <02M​onkooky> oh, hold on 20:42:17 <02M​onkooky> this is only going to apply if you're adding to an existing enchant, I think 20:42:34 <04d​racoomega> No, this is definitely used for base duration of new enchants, if nothing is manually specified 20:42:35 <02M​onkooky> which doesn't make it correct, but makes it a hell of a lot less visible 20:42:43 <04d​racoomega> I'm quite sure of that one 20:43:06 <02M​onkooky> oh I see yeah 20:43:19 <04d​racoomega> If you just call, say, monster->add_ench(ENCH_SLOW) instead of monster->add_ench(mon_enchant(ENCH_SLOW, 0, dur) whatever 20:43:25 <04d​racoomega> Which is done quite frequently 20:43:29 <02M​onkooky> added = &(enchantments[ench.ench] = ench); luv u c 20:43:39 <04d​racoomega> (Maybe not a strict majority of the time, but still many many places) 20:46:29 <04d​racoomega> A bunch of this code seems to date to at least here: 20:46:33 <04d​racoomega> %git eae61da171bd07d54eb09775a244257411359221 20:46:34 <04C​erebot> greensnark * 0.3-a0-626-geae61da171: Monster enchantment overhaul: (17 years ago, 13 files, 339+ 198-) https://github.com/crawl/crawl/commit/eae61da171bd 20:47:20 <02M​onkooky> ...monstuff.cc 20:47:29 <02M​onkooky> mstuff2 20:47:46 <04d​racoomega> Apparently before things even had proper durations? 20:47:51 <04d​racoomega> C++ case ENCH_PARALYSIS: if (random2(120) < mod_speed( hit_dice + 5, spd )) del_ench(ENCH_PARALYSIS); 20:48:03 <04d​racoomega> A lot of just probabilistic chances to wear off 20:48:51 <04d​racoomega> (And this commit was trying to give them something like our current duration system, I think) 20:53:48 <04d​racoomega> Oh, wait, back then modded_speed actually included a monster HD factor, to reduce duration against high HD targets 20:54:17 <04d​racoomega> Even then only used on a handful of things 20:54:28 <04d​racoomega> But this means that it wasn't a simple 'divide and then undo division' thing going on 20:55:06 <04d​racoomega> For at least Slow, Fear, Paralysis, Confusion, and Charm 20:55:20 <04d​racoomega> Waait 20:55:52 <04d​racoomega> That's still true??? 20:56:59 <04d​racoomega> Now applied to exactly Slow, Corrosion, Fear, Paralysis, Petrified, Confusion, and Charm 20:57:26 <04d​racoomega> (And only if their duration is set by this method, which I doubt it always is for any of these things) 20:58:14 <09h​ellmonk> the monster duration stuff doesn't make any sense to me no matter how many times I look at it 20:58:29 <02M​onkooky> do you know if anyone knows how it's supposed to work? 20:58:49 <04d​racoomega> I mean, I think it was 'supposed' to do this 20:58:57 everyone's too afraid of it >.> 20:59:13 <04d​racoomega> (The fact that modded_speed is affected by HD, but _mod_speed is not is already really poor naming) 20:59:33 <09h​ellmonk> I think it's "supposed" to be doing what it's doing, but it's very confusing 21:00:08 <09h​ellmonk> also the fact that fuzzed durations are biased to 90% of the mean or whatever is a bit uhhhhhhhh 21:01:08 <04d​racoomega> I've added a bunch of enchantments in my day, but I think I have manually set durations in nearly all cases rather than use any of this? 21:01:12 <09h​ellmonk> in my opinion it would be better to check hd (if necessary) on the other side of applying the effect instead of handling this through _mod_speed 21:01:49 <09h​ellmonk> maybe that spreads things out too much 21:02:12 <04d​racoomega> No, I agree. If we want that effect (I am going to do math to see how significant it currently is anyway), then this is not the way to do it 21:02:34 <04d​racoomega> imo, nobody who's touched related code as much as this should still be as unclear about how some of it is working >.> 21:03:13 <06p​leasingfungus> i have always feared and eschewed that system 21:03:15 <09h​ellmonk> I'm also unclear that monster hd should affect ench durations at all tbh 21:03:21 <06p​leasingfungus> and i have never understood it 21:03:53 <06d​olorous_84348> Neither have I. 21:04:11 <09h​ellmonk> you already have a number (usually willpower) to affect monsters resisting it and another number to affect the duration (power) 21:04:26 <04d​racoomega> I mean, most effects don't involve this factor at all, anyway 21:04:52 <04d​racoomega> And not even all uses of the status effects that do involve this number here always use codepaths that involve it 21:05:24 <09h​ellmonk> I am pretty sure I went out of my way to not call this in all the fork stuff I did 21:05:38 <09h​ellmonk> don't remember if I ran anything through it in mainline 21:06:28 <04d​racoomega> I almost always didn't use it 21:06:42 <04d​racoomega> Even when reusing common effects, you don't really want a 'standard' duration for many of them 21:06:55 <04d​racoomega> Since some effects should be much shorter or longer or based on the power of the effect applying them in some way 21:07:09 <04d​racoomega> And not just "Whenever a monster is slowed, for any reason, it should be for this long" 21:07:29 <09h​ellmonk> vaguely thinking that the fuzzing function and the way that summons use a duration of 1-6 could be improved upon as well (this is probably out of scope for what you're doing) 21:07:41 <02M​onkooky> feels like this could just be excised without any real loss? 21:07:52 <04d​racoomega> I suspect so 21:08:13 <02M​onkooky> also, should note that summon shadow creatures uses this nonsense 21:08:20 <04d​racoomega> (Running math, corrosion seems to always use this function, and it results in durations against HD 20 things being a little more than 1/2 as long as HD 5 things?) 21:08:48 <09h​ellmonk> that's fairly substantial, but unclear if it matters 21:08:59 <04d​racoomega> Unclear if it needs the extra complexity of caring about this, no 21:09:09 <04d​racoomega> But even if it did, it can just be applied elsewhere, imo 21:09:24 <09h​ellmonk> I wonder if any player outside the dev channel has ever learned this mechanic 21:09:31 <09h​ellmonk> ig minmay probably knew about it 21:09:34 <04d​racoomega> I mean, I have done so much enchantment work, and yet... 21:09:58 <04d​racoomega> Going to curiously look up slow applications that use default durations and which don't 21:10:13 <04d​racoomega> Corrosion was uniquely narrowly run through one function, really 21:11:55 <09h​ellmonk> this might matter for paralysis I guess 21:12:06 <02M​onkooky> what is ENCH_ABJ 21:12:19 <04d​racoomega> A summon's duration 21:12:20 <09h​ellmonk> it's the "monster is temp summoned" enchant 21:12:25 <04d​racoomega> (If it's abjurable) 21:12:26 <02M​onkooky> that's kinda what I thought 21:12:34 <02M​onkooky> so that's based on speed for shadow creatures 21:12:40 <04d​racoomega> ENCH_FAKE_ABJURATION for duration if it isn't. (Or sometimes ENCH_SHORT_LIVED instead) 21:12:53 <04d​racoomega> Well, sure, but isn't it remultiplied at the end? 21:13:00 <02M​onkooky> wait, no hold on 21:13:08 <04d​racoomega> Anyway, I looked through the code to see which uses of slow care about this weird HD factor and which don't 21:13:10 <09h​ellmonk> the way summons use the code path is not very good but I don't think monster hd or speed actually affects it 21:13:26 <04d​racoomega> And I believe the list is: Effects that use default duration: Curare Effects that do not: literally everything else in the game 21:13:37 <09h​ellmonk> lol 21:14:14 <02M​onkooky> mon_enchant me = mon_enchant(ENCH_ABJ, d); me.set_duration(mons, &me); mons->update_ench(me); 21:14:20 <09h​ellmonk> probably a more "correct" way to handle curare would be default duration + some throwing dependent amount - some hd dependent amount, but on the "applying the status" side 21:14:38 <02M​onkooky> think this uses default duration? 21:14:49 <04d​racoomega> I mean, yes, if we want HD to matter, we can involve HD in the duration calc there (which many things do, on a case-by-case basis that can make sense) 21:16:15 <04d​racoomega> So yes, I think that probably all of this should be ripped out and replaced with something considerably simplified - with many bits of old behavior preserved in just a tiny fraction of cases, if that 21:16:29 <02M​onkooky> yeah summon_shadow_creatures absolutely scales the summon's duration based on it's speed and HD 21:16:48 <09h​ellmonk> the more I think about summons the more I want ench_abj duration to just be a random2avg around some number of aut 21:17:00 <04d​racoomega> I mean, summons use 'default' degree-based ENCH_ABJURATION all the time 21:17:55 <04d​racoomega> rand2avg has way too low a low end 21:18:09 <09h​ellmonk> oh I guess you need a base value 21:18:12 <04d​racoomega> But it could definitely fuzz around a specified duration 21:18:42 <04d​racoomega> There's such a weird ancestral lack of granularity between 4, 5, 6 even if it mostly works out okay in practice? 21:18:49 <09h​ellmonk> maybe I should chalk it up as workable but very weird 21:19:41 <09h​ellmonk> I think the big problem with it is if you want a summon duration to scale with power (questionable i guess? do we have any of these left?) you have to do like "degree 2 + x chance in y of adding a degree" instead of just smoothly scaling it 21:19:58 <09h​ellmonk> maybe this doesn't matter at all but it's kinda weird 21:20:04 <04d​racoomega> Are you sure this isn't effectively doing duration like summon spells normally do? (Except that it's choosing the 'base duration' based on the HD of what is summoned, since it varies so much) 21:20:38 <02M​onkooky> I have no idea what summon spells normally do, to be honest 21:20:40 <02M​onkooky> so, no 21:20:43 <02M​onkooky> not sure at all 21:20:57 <02M​onkooky> I am pretty sure what I said is true though! 21:21:04 <04d​racoomega> The math is weird, but the comment is helpful C++ case ENCH_FAKE_ABJURATION: case ENCH_ABJ: // The duration is: // deg = 1 90 aut // deg = 2 180 aut // deg = 3 270 aut // deg = 4 360 aut // deg = 5 810 aut // deg = 6 1710 aut // with a large fuzz 21:21:19 <04d​racoomega> And basically we usually set summon duration to one of these degrees 21:21:39 <09h​ellmonk> I think the gap between deg 4 and 5 is basically fine since no player summon spell should really have deg above 3 or so anyway, so 5 and 6 can just be for extraneous not-really-summons stuff 21:21:49 <04d​racoomega> Looks like shadow creatures uses 4 as the maximum, but high HD things can last less time? 21:23:08 <04d​racoomega> (I didn't actually realize this was the case, though it's not entirely unreasonable?) 21:23:13 <02M​onkooky> hm, I guess this still seems to me like it scales off speed for no reason? 21:23:42 <09h​ellmonk> seems easy to test, hook up a monster with 500 speed and make it summon that 21:24:44 <04d​racoomega> A lot of calc_duration stuff looks like that, but the math actually ends up being 'divide by factor of speed, then multiply by factor of speed' mostly removing the entire act of doing so in most cases, more or less 21:24:45 <04d​racoomega> I think??? 21:25:25 <02M​onkooky> where's the multiplication going down? 21:32:37 <04d​racoomega> int raw_duration = (cturn * speed_to_duration(mons->speed)); 22:00:56 <04d​racoomega> So, someone ran into the old problem of "Reflected player projectile misses player, hits ally behind them, gets penance" (which I think has been a long-time TSO issue) with Beogh, and I am wondering if there's any good reason why the attack conduct check for beams shouldn't use agent() (which accounts for reflection) rather than just checking the thrower type 22:01:04 <04d​racoomega> Since this one line change does seem to make the problem go away 22:03:52 <04d​racoomega> Okay, the last time this line was changed was 15 years ago, so I am going to assume agent() didn't even work that way back then 22:04:12 <04d​racoomega> And that this is probably fine 22:17:59 03DracoOmega02 07* 0.32-a0-442-g4e6cf12409: Fix reflected projectiles causing the player penance if they hit an ally 10(10 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/4e6cf12409d9 22:17:59 03DracoOmega02 07* 0.32-a0-443-g36b1df8bed: Fire final effects after _pre_monster_move 10(2 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/36b1df8bede7 22:18:55 03DracoOmega02 07* 0.32-a0-442-g4e6cf12409: Fix reflected projectiles causing the player penance if they hit an ally 10(11 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/4e6cf12409d9 22:18:56 03DracoOmega02 07* 0.32-a0-443-g36b1df8bed: Fire final effects after _pre_monster_move 10(2 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/36b1df8bede7 22:28:52 04Build failed for 08master @ 36b1df8b 06https://github.com/crawl/crawl/actions/runs/8014262703 22:32:27 03DracoOmega02 07* 0.32-a0-444-g3038c6faba: Fix a possible crash 10(10 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/3038c6faba0d 22:32:41 03DracoOmega02 07* 0.32-a0-444-g3038c6faba: Fix a possible crash 10(13 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/3038c6faba0d 22:39:39 03DracoOmega02 07* 0.32-a0-445-g4bed94c0a3: Don't give apostle challenges while the player is under penance 10(4 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/4bed94c0a30c 22:40:37 03DracoOmega02 07* 0.32-a0-445-g4bed94c0a3: Don't give apostle challenges while the player is under penance 10(5 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/4bed94c0a30c 22:53:51 03dolorous02 07* 0.32-a0-446-ge4683972fd: Fix messaging in Jinxbite sprite message. 10(23 minutes ago, 1 file, 3+ 2-) 13https://github.com/crawl/crawl/commit/e4683972fd32 22:54:15 03dolorous02 07* 0.32-a0-446-ge4683972fd: Fix messaging in Jinxbite sprite message. 10(24 minutes ago, 1 file, 3+ 2-) 13https://github.com/crawl/crawl/commit/e4683972fd32 22:58:23 <06d​olorous_84348> Argh. That should have been "fix pronoun", not "fix messaging". 23:07:19 <09g​ammafunk> my favorite commit message typos are the ones where you carefully check and spellcheck the commit message body 23:07:29 <09g​ammafunk> but then forget to check the commit message title :yogidaFeels: 23:09:50 <06p​leasingfungus> i would never. 23:15:02 03gammafunk02 07* 0.32-a0-447-gf641b5e0b5: doc: Document the artprops item spec tag 10(14 minutes ago, 1 file, 21+ 2-) 13https://github.com/crawl/crawl/commit/f641b5e0b57c 23:15:02 03gammafunk02 07* 0.32-a0-448-g3324ac0059: fix: Exclude unrands from wizmode randart stats 10(3 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/3324ac0059c9 23:15:04 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.31-a0-1632-g3e80a7f90b: Remove an unnecessary check 10(4 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/3e80a7f90b20 23:15:14 03gammafunk02 07* 0.32-a0-447-gf641b5e0b5: doc: Document the artprops item spec tag 10(14 minutes ago, 1 file, 21+ 2-) 13https://github.com/crawl/crawl/commit/f641b5e0b57c 23:15:16 03gammafunk02 07* 0.32-a0-448-g3324ac0059: fix: Exclude unrands from wizmode randart stats 10(3 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/3324ac0059c9 23:15:27 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.31-a0-1632-g3e80a7f90b: Remove an unnecessary check 10(4 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/3e80a7f90b20 23:16:43 <09g​ammafunk> wow 23:16:51 <09g​ammafunk> 448 commits feels like a lot for 23:16:58 <09g​ammafunk> %git 0.31.0 23:16:58 <04C​erebot> gammafunk * 0.31.0: feat: New small abomination tiles from Sastreii (5 weeks ago, 4 files, 1+ 0-) https://github.com/crawl/crawl/commit/2b8753d7e0ea 23:17:09 <09g​ammafunk> only 1.25 months after release 23:17:37 <09g​ammafunk> what do we often have, 2k commits? or is it 1k 23:18:22 <09g​ammafunk> %git 0.31-b1~1 23:18:24 <04C​erebot> PleasingFungus * 0.31-a0-1627-g952d896825: Partial changelog update (6 weeks ago, 1 file, 66+ 15-) https://github.com/crawl/crawl/commit/952d89682525 23:18:36 <09g​ammafunk> %git 0.30-b1~1 23:18:37 <04C​erebot> PleasingFungus * 0.30-a0-1178-g2f52df8dfa: Turn off the zombie incinerator (acrobat) (10 months ago, 1 file, 1+ 1-) https://github.com/crawl/crawl/commit/2f52df8dfa13 23:18:45 <09g​ammafunk> ok more like 1k, so yeah it's a lot 23:22:16 <06r​egret-⸸nde※> %git 0.16-b1~1 23:22:17 <04C​erebot> kate- * 0.16-a0-4134-g2ca243f668: Let Ashenzari's skill boost handle unrandart staves (9 years ago, 1 file, 21+ 8-) https://github.com/crawl/crawl/commit/2ca243f6681d 23:22:22 <06r​egret-⸸nde※> %git 0.15-b1~1 23:22:23 <04C​erebot> PleasingFungus * 0.15-a0-2403-g91670f7809: Remove Gozag from the changelog (10 years ago, 1 file, 14+ 27-) https://github.com/crawl/crawl/commit/91670f780909 23:22:26 <04d​racoomega> God, 4134?? 23:23:27 <09g​ammafunk> was 0.16 another extra long cycle? 23:23:40 <06r​egret-⸸nde※> a bunch of extended monsters and monster shuffling, a bunch more spells, two gods (including ru, huh), and zotdef removal 23:23:59 <06r​egret-⸸nde※> (there was some chart to see these by version, right) 23:24:01 <09g​ammafunk> obviously the release highlight was zotdef removal 23:24:26 <04d​racoomega> Still seems disproportionate to that number, but who knows 23:24:58 <04d​racoomega> Pondering looking into making use of that new randart property specifying for apostles to try and make their armour have more resists at higher levels 23:25:39 <04d​racoomega> A whole lot of randart properties don't actually do things for monsters (besides flavour, here) and lategame apostles would benefit from a bit more consistent access to resists 23:26:42 <09g​ammafunk> yeah I apparently check them all in a quick bash script: > 0.10: 3351 > 0.11: 3387 > 0.12: 3380 > 0.13: 3227 > 0.14: 3675 > 0.15: 2542 > 0.16: 4189 > 0.17: 2272 > 0.18: 1840 > 0.19: 1946 > 0.20: 1159 > 0.21: 668 > 0.22: 976 > 0.23: 988 > 0.24: 865 > 0.25: 1187 > 0.26: 1284 > 0.27: 1670 > 0.28: 1725 > 0.29: 1083 > 0.30: 1189 23:27:23 <09g​ammafunk> that probably includes the beta branch commits as well for each release but that's fine 23:28:06 <09g​ammafunk> we definitely did have larger releases prior to 0.20 23:32:13 03dolorous02 07* 0.32-a0-449-gf785c728e9: Fix typos. 10(10 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/f785c728e9fe 23:32:13 03dolorous02 07* 0.32-a0-450-g080537f31e: Fix wording. 10(8 minutes ago, 1 file, 3+ 4-) 13https://github.com/crawl/crawl/commit/080537f31e97 23:32:54 <09g​ammafunk> how do you actually specify gear for them? Does it even use an item spec? Do you set it up directly from the C++ side? 23:33:03 03dolorous02 07* 0.32-a0-449-gf785c728e9: Fix typos. 10(11 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/f785c728e9fe 23:33:04 03dolorous02 07* 0.32-a0-450-g080537f31e: Fix wording. 10(8 minutes ago, 1 file, 3+ 4-) 13https://github.com/crawl/crawl/commit/080537f31e97 23:33:05 <09g​ammafunk> I haven't looked at your implementation at all 23:33:14 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-449-g65e791635e: Fix autopickup not being reactivated when shafting monsters 10(10 months ago, 1 file, 12+ 0-) 13https://github.com/crawl/crawl/commit/65e791635e82 23:33:18 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-450-g743fae42db: Fix autopickup sometimes not reactivating when invisibility ends on a monster 10(10 months ago, 1 file, 6+ 2-) 13https://github.com/crawl/crawl/commit/743fae42db69 23:33:23 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-451-g9ca0a4424b: Fix toggling of autopickup when polymorphing monsters 10(10 months ago, 1 file, 20+ 1-) 13https://github.com/crawl/crawl/commit/9ca0a4424b8d 23:33:27 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-452-g0078cf7785: Fix autopickup not deactivating when charming wears off invisible monsters 10(10 months ago, 1 file, 5+ 1-) 13https://github.com/crawl/crawl/commit/0078cf778577 23:33:31 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-453-g7bbf063289: Reactivate autopickup when polymorphing an invisible monster makes it friendly 10(2 weeks ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/7bbf0632896f 23:33:35 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-454-g92a8ccdcc7: Don't reactivate autopickup when shafting a friendly invisible monster 10(2 weeks ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/92a8ccdcc780 23:33:40 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-455-gd218713caf: Remove an unnecessary check 10(22 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/d218713caf9f 23:33:50 <04d​racoomega> It's set up directly from C++ side. give_apostle_equipment in mon-gear.cc 23:34:42 <04d​racoomega> It wouldn't be hard to allow passing a table along to make_item_for_monster, though. Maybe make a helper function for making one easily. 23:35:26 <04d​racoomega> (Since this approach in general has the benefit of being able to specify 'relevant good things' and then still fill out the rest with 'whatever' that still makes it look like a normal randart, just probably a good one) 23:35:29 <09g​ammafunk> ah, yeah I see you call items directly 23:35:51 <09g​ammafunk> this means that all you need to do is create the fixed props table yourself as a CrawlHashTable 23:36:04 <09g​ammafunk> and pass it in via the new arg to items (although as a pointer) 23:36:04 <04d​racoomega> Yeah 23:36:14 <04d​racoomega> I was skimming the relevant code just now 23:36:38 <09g​ammafunk> and set the level to the appropriate value corresponding to randart 23:36:49 <04d​racoomega> Yeah 23:37:21 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-449-g65e791635e: Fix autopickup not being reactivated when shafting monsters 10(10 months ago, 1 file, 12+ 0-) 13https://github.com/crawl/crawl/commit/65e791635e82 23:37:21 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-450-g743fae42db: Fix autopickup sometimes not reactivating when invisibility ends on a monster 10(10 months ago, 1 file, 6+ 2-) 13https://github.com/crawl/crawl/commit/743fae42db69 23:37:21 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-451-g9ca0a4424b: Fix toggling of autopickup when polymorphing monsters 10(10 months ago, 1 file, 20+ 1-) 13https://github.com/crawl/crawl/commit/9ca0a4424b8d 23:37:21 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-452-g0078cf7785: Fix autopickup not deactivating when charming wears off invisible monsters 10(10 months ago, 1 file, 5+ 1-) 13https://github.com/crawl/crawl/commit/0078cf778577 23:37:21 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-453-g7bbf063289: Reactivate autopickup when polymorphing an invisible monster makes it friendly 10(2 weeks ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/7bbf0632896f 23:37:21 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-454-g92a8ccdcc7: Don't reactivate autopickup when shafting a friendly invisible monster 10(2 weeks ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/92a8ccdcc780 23:37:21 03Wizard Ike02 07https://github.com/crawl/crawl/pull/3120 * 0.32-a0-455-gd218713caf: Remove an unnecessary check 10(26 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/d218713caf9f 23:37:31 <09g​ammafunk> does seem pretty easy; let me know if you have downstream issues or anything. One aspect of this that's potentially up in the air is that fixed props consume quality points used for further randomization, specifically for adding more good props 23:37:41 <09g​ammafunk> however that's probalby a secondary concern for you 23:37:44 <09g​ammafunk> if it's a concern at all 23:37:57 <09g​ammafunk> since you really care about the base type, enchant, and the desired fixed props 23:38:40 <09g​ammafunk> but with the current system, the more good props you fix, the less quality points will be available to add further good random properties 23:39:38 <09g​ammafunk> which is probably good from a balance standpoint; it just means that with quality being binomial with 7 trails and a p of only 0.21, you don't have a lot of points to play with on average if you do want additional randomization of good props 23:42:05 <04d​racoomega> Yeah, I've not really looked that internals of how randarts get generated basically at all 23:42:22 <04d​racoomega> Certainly conventional randart power level concerns don't apply to apostles 23:43:06 <04d​racoomega> And most randart properties do nothing for them anyway, so the main downside of 'not seeing extra properties' is mostly from a flavor perspective, if things look too 'fixed'. But I will play with it. 23:45:26 <04d​racoomega> In the nearish future 23:46:06 <04d​racoomega> (I finished implementing the last new draconian breath today! Just want to do some local playtesting for approximate number sanity testing first, and then I'll push that too) 23:47:13 <09g​ammafunk> does this change dragon form at all? 23:49:47 <04d​racoomega> It doesn't touch dragon form for non draconians 23:50:06 <04d​racoomega> Not that I even know how relevant the breath damage is there 23:50:28 <04d​racoomega> (I admit that wasn't quite sure what I should do with it for draconians. Currently it's still like "You have your normal breath weapon, but its power is higher" and thus still uses the new charges system)