00:33:15 Unstable branch on cbro.berotato.org updated to: 0.33-a0-443-g8f22220ccd (34) 04:32:41 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5249-g4a8afe7061 09:43:10 -!- TAS-2012v is now known as TAS_2012v 10:27:27 -!- lux is now known as Arachnite 10:31:31 03Implojin02 07* 0.33-a0-444-g1bdb9b73b7: Shorten Forgecraft's artefact property string (gammafunk) 10(86 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/1bdb9b73b775 11:44:45 <04dracoomega> Oh, oops. Must have overlooked that. 11:45:25 <04dracoomega> Or just glanced up at the nearest one, which happened to also be the full word? 13:00:31 <03implojin> @dracoomega just to check, did you review that the bits 96a7ec282a2 removed from tags were safe? mildly concerned that a PR to fix a graphical issue felt the need to remove something from tags 13:00:58 <04dracoomega> Isn't it just redrawing the map at a later stage? 13:01:02 <04dracoomega> The same code was just moved later 13:01:22 <04dracoomega> (It's just that not all information to render it appropriately had been set by that point) 13:01:36 <04dracoomega> At least that was my understanding of it, but I can take a second look 13:06:14 <04dracoomega> Looking over the code again, that is definitely what it looks like. Both where the code was moved from and to seem to be called as part of loading a floor (either via stairs or loading the game). I did test it locally, originally, and things appeared to function correctly, at least. 13:06:16 <03implojin> tile_draw_map_cell appears to possibly be initialising cell data in some places, not sure that deferring this is ok without looking closer 13:06:59 <04dracoomega> I guess I cannot guarantee that there couldn't be some consequence of deferring it in some case, but it did not seem to produce any visual discontinuity when I was testing 13:07:12 <04dracoomega> Since I think all of that stuff is generally called in direct sequence anyway? 13:13:45 <04dracoomega> Maybe I'm wrong, but I kind of assumed that if things were getting relevantly thrashed on level load/save, that it would be immediately obvious when reloading a bunch of times 13:14:25 <04dracoomega> There's nothing interactive between these two points 13:15:29 <03implojin> sounds hopefully fine then, i just wanted to check, thank you for looking 13:16:40 <04dracoomega> No problem 13:17:07 <04dracoomega> (And if it turns out I'm wrong somehow, I'll take responsibility ^^; ) 14:10:36 Conn (L5 OpFE) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 2166 failed. (D (Sprint)) 14:16:17 <04dracoomega> So, I've been looking at https://github.com/crawl/crawl/issues/4011 as I work through an assortment of bug reports. It looks like this was effectively broken by https://github.com/crawl/crawl/commit/357ea4826f429921068d013e38c30ec92cbf8384 but the underlying cause looks really weird to me. Basically, if aux_source is set to anything in the initial beam setup, it seems to be deliberately discarded/ignored. Can anyone think of a good 14:16:18 reason to do this? (See below code:) C++ bolt theBeam = mons_spell_beam(mons, spell_cast, power); bolt_parent_init(theBeam, pbolt); if (!theBeam.target.origin()) pbolt.target = theBeam.target; pbolt.source = mons->pos(); pbolt.is_tracer = false; if (!pbolt.is_enchantment()) pbolt.aux_source = pbolt.name; else pbolt.aux_source.clear(); 14:16:24 <04dracoomega> The code itself is quite ancient 14:23:18 <04dracoomega> I guess it's filling in default values, on inspection, so probably it should just only do that if nothing else was already specified 14:23:43 <04dracoomega> Since presumably if mons_spell_beam set aux_source directly for any reason, it does want that to be respected 14:25:04 Conn (L6 OpFE) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 2166 failed. (D (Sprint)) 14:31:12 <03implojin> that line literally predates stone soup, i think you'd probably(?) be okay to initialise aux_source at the top of mons_spell_beam and then respect that later 14:32:37 <04dracoomega> Yeah, it looks like it should be fine to only fill in aux_source if nothing else has 14:32:45 <04dracoomega> On a cursory test of a few things 14:55:40 03DracoOmega02 07* 0.33-a0-445-g7bd8858e0c: Make message for hitting rC- monsters with cold less misleading 10(2 hours ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/7bd8858e0cac 14:55:40 03DracoOmega02 07* 0.33-a0-446-g9a27585c1c: Don't let Fusillade target (or affect) orbs of destruction 10(2 hours ago, 1 file, 4+ 2-) 13https://github.com/crawl/crawl/commit/9a27585c1c2e 14:55:40 03DracoOmega02 07* 0.33-a0-447-ge3ca3d1998: Don't let the player (rarely) shoot themselves while confused 10(2 hours ago, 1 file, 6+ 3-) 13https://github.com/crawl/crawl/commit/e3ca3d199839 14:55:40 03DracoOmega02 07* 0.33-a0-448-gc00413b3c2: Flag Kinetic Grapnel as destructive 10(2 hours ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/c00413b3c2e3 14:55:40 03DracoOmega02 07* 0.33-a0-449-g531cc0b697: Fix battlesphere firing message (Flugkiller) 10(2 hours ago, 1 file, 5+ 1-) 13https://github.com/crawl/crawl/commit/531cc0b69762 14:55:40 03DracoOmega02 07* 0.33-a0-450-g4330605426: Shorten alchemy artprop string to match other spell schools 10(89 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/43306054268d 14:55:40 03DracoOmega02 07* 0.33-a0-451-g4d5a26f9b7: Don't ignore beam.aux_source set by mons_spell_beam 10(20 minutes ago, 1 file, 1+ 3-) 13https://github.com/crawl/crawl/commit/4d5a26f9b7a5 14:55:40 03DracoOmega02 07* 0.33-a0-452-g7ab36c3030: Fix an Arenasprint crash with foxfires 10(9 minutes ago, 1 file, 4+ 2-) 13https://github.com/crawl/crawl/commit/7ab36c303095 14:55:40 03DracoOmega02 07* 0.33-a0-453-g39329bb7ae: Don't show irrelevant information when looking up non-book spells (Ge0FF) 10(85 seconds ago, 1 file, 4+ 1-) 13https://github.com/crawl/crawl/commit/39329bb7ae62 14:58:24 <02Monkooky> @dracoomega I think mons might be running from blazeheart explosions because they're being damaged by a source they can't see 14:58:29 <02Monkooky> namely the dead blazeheart 14:58:44 <04dracoomega> Haha, really? (I hadn't gotten to looking into that one yet) 15:00:20 <02Monkooky> right now it's just a theory, but I'm about to code dive to confirm/deny 15:02:57 <02Monkooky> yeah it looks like that's exactly what's happening 15:02:59 <04dracoomega> This does seem quite plausible, glancing at the code 15:03:32 <04dracoomega> It's trying to pathfind to ANON_FRIENDLY_MONSTER up in good old (0, 0) 15:04:10 <02Monkooky> crawlcode at it's finest 15:04:20 <04dracoomega> (It might be fine to just skip the reachability check for anything at (0, 0)) 15:04:43 <04dracoomega> Since it's either a dead something or an anon something, or maybe some system thing. And either way, it shouldn't be trying to retreat from it 15:05:35 <04dracoomega> (This probably means this is a different bug than the one maybe affecting hellfire mortar) 15:05:50 <02Monkooky> I feel like the right behaviour should prevent that from coming up tho 15:06:32 <04dracoomega> I mean, the thing is that the mortar is reachable 15:06:35 <02Monkooky> like, in this case it's only happening because the annoy is coming from a dead monster before there's a hit mon chance to change to a new target 15:06:37 <04dracoomega> It's right there 15:06:48 <02Monkooky> right sorry this is still in reference to blazeheart 15:07:15 <04dracoomega> I mean, the annoy event directly sets the foe to whatever annoyed it 15:07:19 <04dracoomega> As part of the event itself 15:07:20 <02Monkooky> though while I'm here I'll see if I can see why mortar's causing flight 15:07:54 <02Monkooky> yeah, but we probably want to pre-empt that with an is-alive check 15:07:59 <04dracoomega> Yes 15:08:05 <04dracoomega> I mean, I think ANON_FRIENDLY_MONSTER is alive 15:08:10 <04dracoomega> So it has to be more than just that 15:09:12 <02Monkooky> ah. crawlcode 15:10:12 <04dracoomega> Yeah, things are considering the mortar to be unreachable. Which, on the one hand, makes sense since it's in lava. However, a bunch of reachability code specifically is satisfied with getting next to a spot - and I don't recall seeing this behavior if the player is standing over one tile of lava - so I wonder if something else is going on 15:11:14 <02Monkooky> is this reliable? 15:11:26 <02Monkooky> or do you only sometimes get fleeing mons 15:11:58 <04dracoomega> Maybe only sometimes? (But seemingly never for the player doing it) 15:22:05 <02Monkooky> const int range = mon->friendly() ? 1000 : mons_tracking_range(mon); if (dist > range) { mon->travel_target = MTRAV_UNREACHABLE; #ifdef DEBUG_PATHFIND mprf("Distance too great, don't attempt pathfinding! (%s)", mon->name(DESC_PLAIN).c_str()); #endif return false; } 15:22:09 <02Monkooky> the hell is this 15:22:23 <04dracoomega> What do you mean? 15:23:13 <04dracoomega> Of the various complicated and tangled things about Crawl monster movement code, this block seems fairly straightforward. 15:23:23 <02Monkooky> mons_tracking_range is between 3 and LOS 15:23:56 <02Monkooky> so it looks like if there's no straight line to an enemy more than 3 tiles away, it's considered unreachable 15:24:21 <04dracoomega> Yes, I was starting to wonder if it had to do with that. (Though worth noting: brainless monsters never retreat) 15:25:24 <04dracoomega> So it's really only animals that are weird here. (I had, entirely separately of this, wanted to do something with some of that tracking range code so that I can finally remove that 'native in branch' thing, part of which involved folding the bonus into some things) 15:25:51 <04dracoomega> However, it's worth noting that things are not automatically considered unreachable, even for non-native animals, just because it's 5 tiles away 15:26:24 <04dracoomega> It only gets to this point at all if it thinks it cannot go 'straight' at the foe. ie: there is a ray between it and there that is unblocked by impassible terrain or stationary monsters 15:26:56 <02Monkooky> right, I was aware of the straight line check 15:27:03 <02Monkooky> is that any ray? 15:27:06 <04dracoomega> So if something shoots at a rat from the other side of the screen, the rat won't fall back to pathfinding unless there's deep water or lava or something 'in the way' first 15:27:22 <04dracoomega> See can_go_straight() 15:27:47 <02Monkooky> hm, a fixme 15:27:48 <02Monkooky> https://cdn.discordapp.com/attachments/747522859361894521/1308921762817249330/image.png?ex=673fb3e2&is=673e6262&hm=4a3b981d3a459189b8407d7feacb63f45c78e06ca7f64562c15326fea53dc570& 15:27:49 <04dracoomega> (Hellfire mortar is probably unusally able to cause this behavior because there's lava that might be 'trivially' in the way) 15:28:00 <04dracoomega> That fixme is actually outdated 15:28:12 <04dracoomega> And refers to a different opacity type than is actually being used below 15:28:39 <02Monkooky> brilliant 15:28:40 <04dracoomega> (As it so happens, I've been all over some of this code only a few days ago, trying to deal with some firewood-related issues I mentioned in #dcss) 15:29:10 <02Monkooky> so if hellfire mortar is really consistantly causing monsters to flee this probably isn't it 15:29:22 <04dracoomega> No, I think it might be 15:29:26 <02Monkooky> nice 15:30:29 <04dracoomega> Hmm... although, isn't mortar's firing range only 5? 15:30:39 <04dracoomega> Seems like that could never be out of an animal's pathfinding range, if so 15:30:51 <04dracoomega> (I am going to keep investigating) 15:37:51 <04dracoomega> Ugh... I think what might be happening is that, since hellfire mortar makes so much noise when first cast, the monster notices it immediately and sets its foe to the mortar before it has even fired. And at that point, it is too far to pathfind to (and also over lava). To save recalculating pathfinding against unreachable monsters, in general, a monster tracks whether its target was unreachable the last time it tried, and will 15:37:51 usually skip bothering a large random percentage of subsequent times it has asked. So by the time the mortar shoots it, it has already determined it was unreachable (since it was unreachable a couple turns earlier) and will start running away. 15:39:14 <04dracoomega> If the monster is closer to you when you first cast the spell, or aimed in a way that does't put lava between the monster and it, no wierdness should happen, I think 15:39:23 <04dracoomega> (Or if it's smarter) 15:44:42 <04dracoomega> It's a little hard to tell the exact order things are happening in, but this would be consistent with observed behavior 15:51:47 <04dracoomega> (A fix for this is not altogether straightforward, though. I'm fine increasing default pathfinding range - as I said earlier, I'd been independently planning that anyway - and that probably fixes this specific manifestation of this problem, though it still feels like that implies other correctness in how things are handled) 15:58:28 <04dracoomega> For one thing, I think pathfinding may sometimes be done prematurely, before a monster has even determined that it wants to take an action towards a given foe 16:14:26 <04dracoomega> Really, the more I think about it, the more it just seems plain incorrect to have 'Too far away to bother trying to pathfind' use the same flag as 'Tried to pathfind and found it was unreachable', especially when it doesn't update if something is now closer. (There is a 1-in-12 chance each time try_pathfind is called to try recalculating anyway, but this essentially means that if a monster first sets a foe from a distance, and 16:14:26 therefore doesn't bother to check reachability, it will still consider them out of reach potentially quite a while later, after getting much closer) 16:16:45 <04dracoomega> Since it's essentially like "Well, 6 turns ago I was far away, so... shrug" 16:39:10 Unstable branch on underhound.eu updated to: 0.33-a0-453-g39329bb7ae (34) 19:18:35 03DracoOmega02 07* 0.33-a0-454-ge3c942dec9: Fix Ru magic school sacrifices blocking the wrong schools (Lightli) 10(89 seconds ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/e3c942dec96e