00:17:00 Stable (0.34) branch on cbro.berotato.org updated to: 0.34.1-3-ga2c7840dd7 00:55:54 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-228-gbea90c2428 01:12:55 Stable (0.34) branch on underhound.eu updated to: 0.34.1-3-ga2c7840dd7 04:33:36 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 09:50:19 03RypoFalem02 07https://github.com/crawl/crawl/pull/5143 * 0.35-a0-226-gb3e6e7b5b5: fix: crash on ?/m monster description 10(32 minutes ago, 1 file, 4+ 1-) 13https://github.com/crawl/crawl/commit/b3e6e7b5b5ea 09:50:19 03RypoFalem02 07https://github.com/crawl/crawl/pull/5143 * 0.35-a0-227-gf59701208d: fix: Only count enhancers for monster spells, not abilities (hellmonk) 10(5 minutes ago, 1 file, 6+ 0-) 13https://github.com/crawl/crawl/commit/f59701208da8 10:46:14 <04dracoomega> I was aware this could be possible. The last-created mortar effectively takes 'ownership' over the terrain changes on its tiles (which is roughly consistent with how other forms of terrain change ownership have always worked.) The fact that it's technically possible to eat up the path of a different mortar by changing the terrain along it in certain ways didn't feel necessarily incorrect to me (and the situations needed to even cause 10:46:15 it are highly specific, since it requires stone+ or level border in the way of the newer mortar, too. But perhaps I will make it so that at least it doesn't remove lava under an existing mortar. This actually doesn't matter functionally, as the mortar will stop existing on its turn anyway, if there's nowhere for it to go, but it might look slightly visually weird, I suppose. But I don't think that being able to wipe out another lava path in this way 10:46:15 is actually incorrect (or at the very least, important enough to go to any lengths to prevent.). The original reason it was reported (triggering traps that reappeared under it) is something I recently changed for unrelated reasons, so wouldn't even happen now anyway. 12:01:42 horvathsaigyou (L23 BaAr) ASSERT(in_bounds(mg.pos)) in 'mon-place.cc' at line 3165 failed. (Depths:2) 13:02:27 <08o____0> !crash 13:02:33 <04Cerebot> 22798. horvathsaigyou, XL23 BaAr, T:46001 (milestone): https://crawl.akrasiac.org/rawdata/horvathsaigyou/crash-horvathsaigyou-20260320-190140.txt 13:12:56 <08o____0> fleshcrafter's bolt redirected(ru) to a Tengu Conjurer's battlesphere 13:15:35 <11Odds> That's very familiar 13:16:33 <09hellmonk> Misread that as fishcrafter 13:16:36 <09hellmonk> can we add this 13:17:44 <11Odds> https://github.com/crawl/crawl/commit/6183c0be11a8 - a previous similar thing 13:18:29 <11Odds> (But seems like a differentbug) 13:23:40 <08o____0> every game needs fishing and crafting and it just makes sense to combine the 2 13:24:11 <08o____0> They are also wearing warlock's mirror but I don't think that's causing this? 13:38:55 <11Odds> Seems pretty replicable 13:39:26 <11Odds> Doesn't have to be a battlesphere, either 14:14:38 <11Odds> Looks to me like bolt of flesh fails if it hits something it can't affect - where we put the flesh pile depends on the last affected position. So I think it just needs a check that the bolt has actually affected something before placing the flesh. 14:24:14 <09gammafunk> what would you call a larger variant of the fishcrafter? 14:26:11 <11Odds> A little replication (with Ru) - the kobold fires at the orb guardian, doesn't affect any monsters because of a cell, and then the flesh creation crashes 14:26:11 <11Odds> https://cdn.discordapp.com/attachments/747522859361894521/1484664373640433664/image.png?ex=69bf0cf2&is=69bdbb72&hm=b833801f8ac49d117aca70f98b29d9b924efcef77429c4aa2bfd2cc170d72f54& 14:27:15 <11Odds> Should Ru redirection be redirecting at things it can't hit in the first place? 14:51:13 <04dracoomega> I think Ru redirection is very dumb and basically understands nothing about what it's aiming, which makes it somewhat brittle (though usually less-so than this) 14:51:36 <04dracoomega> Also: the game is somewhat lying about redirecting spells, since it does this before the creature would decide to cast them. 14:52:00 <04dracoomega> As in: they can choose to cast them on allies or themselves even when no enemies are in range for them to have ever considered using on them 14:52:10 <11Odds> Oh interesting 14:52:26 <04dracoomega> This should be very easy to see if you stick an enemy with a hex behind a bunch of plants 14:52:38 <11Odds> This one is easily enough fixed by only creating the flesh pile if we've actually hit something 14:52:41 <04dracoomega> It will sometimes just cast at itself at random 14:52:59 <04dracoomega> (I didn't actually realize this behavior until I saw that happen while testing something unrelated once) 14:54:09 <04dracoomega> I don't necessarily think this has bad gameplay effects overall, but I have pondered rewording things to make it more like... I dunno, their magic is misfiring or something. Since you can 'redirect their attack' in situations where it's unambiguous that they aren't trying to attack. 14:57:24 <11Odds> Redirecting there attack is good flavour though 🙂 15:07:07 New branch created: pull/5145 (1 commit) 13https://github.com/crawl/crawl/pull/5145 15:07:08 03CrawlOdds02 07https://github.com/crawl/crawl/pull/5145 * 0.35-a0-229-g16fef69376: Fix a Ru flesh redirection crash 10(11 minutes ago, 1 file, 6+ 0-) 13https://github.com/crawl/crawl/commit/16fef69376d3 15:13:12 <11Odds> I don't actually know if this is the same crash that happened in the crashlog above... I can't read ascii screenshots 🙂 15:56:54 <06pleasingfungus> bold of you to say. personally, i keep it simple: i can't read 16:12:36 <09hellmonk> Jokes on you, I can read but choose not to 16:14:34 Some day I hope someone will explain the strange marks you are making appear on my screen 16:41:29 Unstable branch on underhound.eu updated to: 0.35-a0-228-gbea90c2428 (34) 16:55:04 <07wizardike> It actually does still trigger the trap I believe as it still starts its turn on the trap, it just doesn't trigger it twice anymore 16:57:51 <04dracoomega> Hmmm.... Players only trigger traps if they have moved onto a different tile. But apparently monsters technically can trigger traps by moving onto the same tile they're already on, though I think this still requires some call to move_to(pos) first? (As in, merely starting there seems like it should not be enough, but some codepaths can probably cause a monster to move onto where it already is) 16:58:35 <04dracoomega> There is probably no good reason for this behavior? 17:01:12 <06pleasingfungus> probably. 17:06:24 <04dracoomega> If I had to guess, I suspect what actually happened is that this check of "Don't trigger if we didn't actually move" was added for the player specifically because 'landing from flying' and a number of other things actually happen often enough to notice, and then this was not done for monsters because it comes up a lot less often and wasn't thought about (and also movement code was a lot more messy then) 17:07:06 <04dracoomega> (I could be wrong) 17:17:13 <07wizardike> The trap triggering is coming from monster::trigger_movement_effects called from _dgn_check_terrain_monsters called from _current_terrain_changed which is happening as part of the terrain reverting. It seems terrain reverting used to trigger the trap twice and now it triggers it ones? 17:58:35 <04dracoomega> I'm genuinely surprised I never noticed this when I added the code specifically to retrigger traps under actors after terrain changes (when I have dispersal traps a cooldown). Probably because I mostly tested it as a player, where of course that does not happen. 17:58:45 <04dracoomega> Anyway, I will probably change that tomorrow or thereabouts 18:35:55 03Jewel02 {GitHub} 07* 0.35-a0-229-g09475f4b62: Bind right click to Describe when in Display Map to match Look Around 10(57 seconds ago, 2 files, 28+ 14-) 13https://github.com/crawl/crawl/commit/09475f4b6231 19:09:27 03WizardIke02 07* 0.35-a0-230-g1288480e04: Add Jewel to the credits 10(3 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/1288480e04d6 23:13:17 Unstable branch on cbro.berotato.org updated to: 0.35-a0-230-g1288480e04 (34) 23:35:28 Unstable branch on crawl.develz.org updated to: 0.35-a0-230-g1288480e04 (34) 23:57:09 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-230-g1288480e04