00:13:08 Unstable branch on cbro.berotato.org updated to: 0.32-a0-33-g74fbe469d6 (34) 00:54:34 Monster database of master branch on crawl.develz.org updated to: 0.32-a0-33-g74fbe469d6 01:10:33 Stable (0.31) branch on cbro.berotato.org updated to: 0.31.0-2-g5a2aebc5c2 01:35:02 Unstable branch on crawl.kelbi.org updated to: 0.32-a0-33-g74fbe469d6 (34) 01:35:03 Unstable branch on crawl.kelbi.org updated to: 0.32-a0-33-g74fbe469d6 (34) 01:36:21 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-5140-g5775ae71e1 01:36:22 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-5140-g5775ae71e1 04:31:52 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5140-g5775ae71e1 05:07:24 Unstable branch on crawl.akrasiac.org updated to: 0.32-a0-33-g74fbe46 (34) 10:40:12 iamserjio (L27 OpSh) ASSERT(!monster_at(p) || monster_at(p)->submerged() || fedhas_passthrough(monster_at(p)) || mons_is_player_shadow(*monster_at(p)) || mons_is_wrath_avatar(*monster_at(p))) in 'player.cc' at line 639 failed. (Tomb:3) 10:46:42 !crashlog iamserjio 10:46:43 7. iamserjio, XL27 OpSh, T:23560 (milestone): https://underhound.eu/crawl/morgue/iamserjio/crash-iamserjio-20240120-174012.txt 10:53:39 player cast vhi's electric charge, a displaced monster landed on a dispersal trap. I wonder if this meant the player's target became occupied, and/or the player's position becomes confused between the two 11:14:20 yep, _displace_charge_blocker() triggered a dispersal trap, so the player is no longer where electric_charge() thinks they are and there's a different monster blinked to the supposedly empty target square. this one looks "fun" 11:16:29 I *think* the right thing to do is return spret::abort instead of failing an assert? 11:17:26 well, instead of move_player_to_grid() 11:31:53 interestingly, that crash just crashed the tournament script! 11:33:21 <09gammafunk> https://dpaste.com/CEKXPXRXL 11:33:32 <09gammafunk> I'm going to make it just ignore crash milestones 11:33:38 <09gammafunk> I guess it was previously recording them 11:45:43 hm, it's harder than that. you still want the charge trail up to where the player should have landed, since the dispersal happens after they get there. also existing checks use spret::success so I guess that should be used here. what I'm not sure of is whether the player has to be at least notionally moved to the target position for the charge clouds stuff to work 16:33:58 Unstable branch on underhound.eu updated to: 0.32-a0-33-g74fbe469d6 (34) 17:34:15 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:2) 17:36:01 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:2) 17:38:02 ongoing (L15 FoMo) ERROR in 'mon-util.cc' at line 696: bogus mc (no monster data): invalid monster_type 1000 (1000) (Orc:2) 17:40:40 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:2) 17:43:43 !crashlog jschmitter482 17:43:43 4. jschmitter482, XL27 DsAE, T:132033 (milestone): https://cbro.berotato.org/morgue/jschmitter482/crash-jschmitter482-20240121-004039.txt 17:43:50 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Abyss:3) 17:46:22 this crash log doesn't make much sense 17:48:56 <04dracoomega> I'm taking a look at it myself. It looks like a tracer for something the player has quivvered is somehow triggering the 'cut piercing beams from allied monsters short if they would hit you' code and somehow the ray that is getting is invalid 17:49:45 <04dracoomega> I don't know exactly why this would look like a monster source, but more importantly, I have no idea how the ray itself is invalid even then. This code is... wierd 17:50:06 right, but that's being triggered from runrest_stop… 17:50:38 &rc jschmitter482 cbr2 17:50:39 https://cbro.berotato.org/rcfiles/crawl-cbr2/jschmitter482.rc 17:51:35 &rc jschmitter482 cbro 17:51:36 https://cbro.berotato.org/rcfiles/crawl-cbro/jschmitter482.rc 17:52:13 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:2) 17:52:18 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:2) 17:52:23 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:2) 17:52:29 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:2) 17:52:30 this one makes the earlier crash look normal 🙂 17:52:37 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:1) 17:53:11 <04dracoomega> You mean the ?immo plus penance one? 17:53:22 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Abyss:3) 17:53:41 no, vhi's cast on a monster displaced the monster onto a dispersal trap 17:53:51 <04dracoomega> Oh, right 17:54:35 <04dracoomega> I basically have no idea how to read what _valid() is checking, aside from the fact that it surely shouldn't be normally possible to set up a beam from anywhere to anywhere without it being valid, right? Or we'd see that part all the time? 17:54:59 * geekosaur has no clue 17:55:18 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Abyss:3) 17:55:51 <04dracoomega> Like, it's worth noting, that _valid() is called also if you were going to advance the ray, so it doesn't seem like it could be specific to my rewind code 17:56:50 <04dracoomega> (By the way, if that .rc link 404s, does that mean that they don't have a custom one at all, or does it indicate a different error, since everyone should have a 'default' one?) 17:58:21 <04dracoomega> I just pulled up their game, and the spell they have quivered is plasma beam. For whatever that's worth. 18:00:38 means no custom one 18:01:04 I was wondering if they had e.g. a custom ready() that was triggering the quiver code 18:01:23 <04dracoomega> Plasma beam specifically seems to reuse the tracer used in spell_no_hostile_in_range without repositioning it 18:01:25 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:2) 18:01:48 <04dracoomega> Maybe this means it could try to regress beyond its start and that might cause an issue? 18:02:07 <04dracoomega> (Though I still need to figure out how this tracer could count as coming from a monster) 18:07:45 <04dracoomega> Like, the only call to ray.regress() in affect_player() is that one, and I cannot see how this counts as a non-player source 18:08:54 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Zot:2) 18:09:04 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (D:15) 18:09:18 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (D:15) 18:09:32 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (D:15) 18:12:54 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Abyss:4) 18:14:44 <04dracoomega> I watched them play a little. No obvious weirdness going on (and they certainly both cast plasma beam from the quivver repeatedly and had times with no valid targets around with no effect) 18:14:55 <04dracoomega> (I tried to ask them questions, but I don't think they noticed) 18:19:30 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:1) 18:19:59 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Depths:1) 18:30:26 <04dracoomega> Actually, I just noticed this weirdness in that crashlog 18:30:29 <04dracoomega> Standing on same square as: Monster 'the wrath of Vehumet' (21, 31) [midx = 0]: 18:30:59 <04dracoomega> Is it related to quiver tracers during wrath somehow?? 18:31:24 I was wondering if those were linked, since the tracebacks always start with god wrath 18:32:43 <04dracoomega> Okay, yeah, I reproduced it 18:34:05 <04dracoomega> (And tested it with a different spell quivvered and it's fine) 18:34:17 <04dracoomega> Seems to somehow involve Veh wrath hitting someone who has plasma beam quivered 18:34:49 <04dracoomega> Not that this yet makes the rest of anything clearer to me 18:36:08 <04dracoomega> God wrath message isn't in the log yet, so I guess this is crawl stopping you in the middle of wrath, but before the wrath has said or done anything but make the fake monster standing on your tile? 18:36:55 it's in the process of printing the message, and calling runrest_stop before outputting it, if I understand the traceback correctly 18:37:05 <04dracoomega> Yeah 18:37:12 (runrest_stop_message) 18:37:16 <04dracoomega> This still doesn't make clear how the player tracer could count as an ally monster tracer instead, though 18:37:31 <04dracoomega> But if it's reproducible, I can at least toss in some diagnostic statements and see if I can trace it 18:38:10 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 18:38:59 <04dracoomega> I guess this is infinitely deferring that guy's punishment, isn't it? 18:39:05 <04dracoomega> (Instead they are being punished far more annoyingly) 18:39:11 yep 🙂 18:39:20 <04dracoomega> New Veh wrath: just crash the player's game 18:42:38 <04dracoomega> Okay, initial diagnostics: the tracer is the second (fire) beam componant of the plasma beam tracer, and it thinks the source is a monster (probably the 'vehumet wrath' monster) 18:42:57 <04dracoomega> And the crash is probably from trying to double-regress a beam aimed at yourself (there's nowhere to rewind it!) 18:43:18 <04dracoomega> But uh... how does the player tracer get assigned a monster source? And why does this monster source count as friendly? 18:46:50 <04dracoomega> Random trivia: apparently god wrath can't happen if you're with Fedhas and standing on a plant 18:47:08 <04dracoomega> Since there needs to be no monster at the player's tile 18:47:29 secret fedhas tech 18:47:57 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 18:49:41 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 18:49:49 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 18:50:42 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 18:50:50 remarkably persistent 18:50:58 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 18:52:13 <04dracoomega> Oh god 18:52:17 <04dracoomega> C++ // Check for whether this is actually a dith shadow or wrath avatar, not you if (monster* shadow = monster_at(you.pos())) if (shadow->type == MONS_PLAYER_SHADOW && nominal_source == MID_PLAYER) return shadow; 18:52:37 <04dracoomega> (God wrath is delivered via MONS_PLAYER_SHADOW 18:53:08 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 18:53:33 <04dracoomega> For some reason, this directly hijacks the agent() of all beams fired by 'you' if you're standing on it 18:53:36 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 18:55:10 <04dracoomega> if (agent() && agent()->is_monster() && mons_att_wont_attack(attitude) && !harmless_to_player() && pierce && !is_explosion) Okay, my code checks the attitude of the beam and not the attitude of the... agent of the beam?? Because why would they be different, right? 18:56:05 <04dracoomega> So the above code replaces the player agent with the wrath avatar shadow standing beneath them, and then my code says "Hey, our agent is a monster and this beam is friendly!" because we are friendly to ourselves 18:56:30 <04dracoomega> So it tries to pull the beam back to not hit ourselves, but the beam was already aimed at itself, and then it tries to pull it back a second time (because plasma beam) and then the math gets unhappy 18:58:35 <04dracoomega> I don't think my code is really terribly incorrect here. (Maybe it should have a guard against double regressions??) But I need to understand why the player shadow hijacking is happening, since apparently that code was an attempt to fix some other bugs just a couple years ago 18:58:47 <04dracoomega> With Xom chesspieces, thematically appropriately enough 19:01:46 <04dracoomega> Nevermind, that commit only changed the comment 19:02:55 <04dracoomega> The more I look at this, the more bewildered I am. So long as there is a Dith shadow or god wrath avatar in existence standing on your spot, literally all player-originated beams will appear to come from this shadow/avatar instead 19:03:53 <04dracoomega> This may have been a very hacky way to try and implement shadow mimic ages ago (I'm not sure it even made sense back then), but after this got co-opted for god wrath, it makes even less sense 19:04:37 <04dracoomega> If god wrath is already coming from a monster, can't it just fire its own beams? In fact, it already does 19:05:12 <04dracoomega> Like, they appear to already be initialized in the usual way, which shouldn't need any of this 19:09:07 <04dracoomega> I can see both commits and commit message from advil a few years ago saying that this entire system of handling god wrath seems bug-prone and a bad idea 19:09:09 <04dracoomega> >.> 19:13:34 <09gammafunk> makes me wonder, how did veh wrath work before dith 19:13:45 <09gammafunk> because dith is, in dcss terms, relatively recent 19:14:11 <09gammafunk> very old by now, but it wasn't a god when I started getting involved in development (although I think it arrived quite shortly after) 19:14:11 <04dracoomega> Actually, looking into this, I'm not convinced even Dith needs that code block in beam::agent() at all 19:14:46 <04dracoomega> I don't know if anything changed over the last 10 years, but at this point it looks like the agent should already be set properly from the shadow mimic's own castin 19:14:57 <04dracoomega> Without needing to special-case agent() to return it if it exists 19:15:28 <04dracoomega> So I am genuinely wondering if that code can do anything besides cause obscure bugs 19:18:21 <04dracoomega> Okay, apparently the original version of that hijacking was added via https://github.com/crawl/crawl/commit/1c85753056f30765d8517bd0e8f195705b29da06 19:19:05 <04dracoomega> Not sure if this is needed anymore (and this still seems like a very weird way to go about it anyway). I'll attempt to test. Because mostly I'd just like to rip that out ^^; 19:22:10 <04dracoomega> Okay, apparently that code is still needed to make shadow mimic not copy your launcher brand 19:22:14 <04dracoomega> For some ungodly reason 19:26:27 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 19:27:42 jschmitter482 (L27 DsAE) ASSERT(_valid()) in 'ray.cc' at line 229 failed. (Pan) 19:48:22 <04dracoomega> Okay, so real Dith mimics have MID_PLAYER (which is... part of why this is so wonky). But god wrath avatars, despite also being MONS_PLAYER_SHADOW do not. So for now, as much as I hate this short-circuit, I think I am going to limit it to only hijacking if the monster at your feet has the player's mid, too 19:48:35 <04dracoomega> And otherwise leave it in place 19:48:57 <04dracoomega> (...and then rip the guts out entirely if I get my hands on Dith >.>) 20:33:29 <03wheals> doesn't the code you posted earlier already do that? (or is nominal_source something else?) 20:33:58 <04dracoomega> The nominal souce for shadow mimics is MID_PLAYER because shadow mimic creation specifically sets the monster's mid to MID_PLAYER >.> 20:35:25 <03wheals> right, but from what you posted it seems like it already checks for that mid before hijacking 20:36:41 <04dracoomega> Well, the problem here is that there is a player-initiated tracer happening, unrelated to the MONS_PLAYER_SHADOW that happens to be standing at their feet during god wrath 20:36:58 <04dracoomega> (I have a fix commited. Just testing branch compilation before pushing. I've written a very long explanation of everything there) 20:45:31 03DracoOmega02 07* 0.32-a0-34-g36ad0d86fd: Fix a very strange crash involving Vehumet wrath and quivering plasma beam 10(16 minutes ago, 1 file, 11+ 2-) 13https://github.com/crawl/crawl/commit/36ad0d86fdf5 20:45:31 03DracoOmega02 07* 0.32-a0-35-gd9ff480968: Don't let spectral weapons get free hits every now and again 10(14 minutes ago, 1 file, 11+ 0-) 13https://github.com/crawl/crawl/commit/d9ff4809687e 20:45:32 03DracoOmega02 07[stone_soup-0.31] * 0.31.0-3-g91b25704cd: Fix a very strange crash involving Vehumet wrath and quivering plasma beam 10(16 minutes ago, 1 file, 11+ 2-) 13https://github.com/crawl/crawl/commit/91b25704cd89 20:45:32 03DracoOmega02 07[stone_soup-0.31] * 0.31.0-4-g52a2dc7128: Don't let spectral weapons get free hits every now and again 10(14 minutes ago, 1 file, 11+ 0-) 13https://github.com/crawl/crawl/commit/52a2dc7128ef 20:50:33 floraline: A request if you can, would you be able to add rebuilds of 0.31 to your cron for stable versions? I think you do so for the other stables already. This way cko sees any important fixes we make to the branch during tourney 20:50:53 floraline: either that or if you can update the rebuild script to include 0.31, we can trigger them ourselves 20:51:05 we just made an important pair of bugfixes 22:02:14 Stable (0.31) branch on underhound.eu updated to: 0.31.0-4-g52a2dc7128 23:01:35 <06pleasingfungus> lmao good crash 23:34:46 Unstable branch on crawl.develz.org updated to: 0.32-a0-35-gd9ff480968 (34) 23:56:22 Windows builds of master branch on crawl.develz.org updated to: 0.32-a0-35-gd9ff480968