00:11:12 Stable (0.32) branch on cbro.berotato.org updated to: 0.32.0-20-g245f4a553c 01:39:16 <06mumra> Yeah I encountered this in the wall monsters work and it's really convoluted for little benefit. Just a bit intimidating to try and simplify 🙂 (been doing some further work on wall monsters and also yaktaur variety, trying to get some stuff actually finished to hopefully go into 0.33...) 03:59:07 New branch created: pull/4037 (1 commit) 13https://github.com/crawl/crawl/pull/4037 03:59:08 03Sean Dewar02 07https://github.com/crawl/crawl/pull/4037 * 0.33-a0-97-g8218d4fa48: Fix crash in Xom's wave of despair effect 10(15 minutes ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/8218d4fa480c 05:02:25 Stable (0.32) branch on crawl.akrasiac.org updated to: 0.32.0-20-g245f4a5 05:12:36 Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-96-gfd2f4f1 (34) 06:34:04 <04dracoomega> Looking through this summon stuff is reminding me of how I also wanted to significantly refactor killer_type at some point. It's this weird overlapping muddle of 'agent who caused death' and also 'type of death that happened', with a bunch of closely related types with unclear and/or minor differences. On a casual inspection here, deaths from the 4 different types of 'temporary monster duration' enchants get kill types of the 06:34:04 following: ENCH_FAKE_ABJURATION: KILL_MISC (except Battlesphere specifically is KILL_RESET instead) ENCH_ABJ: KILL_RESET (but KILL_DISMISSED if the enchantment is removed quietly) ENCH_SHORT_LIVED: KILL_TIMEOUT ENCH_SLOWLY_DYING: KILL_MISC 06:37:57 <04dracoomega> Oh, apparently if hoarfrost cannons die due to firing their final volley, they get KILL_TIMEOUT instead of KILL_MISC for some reason 06:47:18 <09gammafunk> Is that what ends up getting outputed in the ktyp logfile field? I've also found that field to be confusing 06:50:34 <04dracoomega> Maybe? (I am currently trying to tease apart the exact current differences between several of the closely related killer_types. I think a number of them are so similar in practice that almost nobody is really sure if there's a reason to use one over the other) 06:52:42 <04dracoomega> (This is the same enum that has things like KILL_YOU and KILL_YOU_MISSILE in it, which also bake agent into the kill type along with method, which many other kill types don't. Like, there's no KILL_BANISHED_YOU. It's KILL_BANISHED no matter who does it.) 06:54:47 <04dracoomega> It would be a pretty big task to separate that all out (though it would be nice, and there's evidenty some weird inconsistencies even about some of the basic types), but at the very least it seems like it ought to be possible to merge/clarify a few of the timeout/dismissal-related ktypes 06:56:11 <04dracoomega> Er, note that this is also seperate of kill_method_type, which is what includes such nice things as KILLED_BY_FALLING_THROUGH_GATE and KILLED_BY_SOMETHING 06:57:05 <04dracoomega> Those are the ones used for player death ktype in scores and such 06:57:23 <04dracoomega> The other ones apply to monsters 07:02:59 <09gammafunk> oh ok, it sounds like you're working on what goes in...maybe killer or kaux fields? 07:03:50 <09gammafunk> I haven't looked at what is used to emit those fields, possibly it's not a direct 1-1 with a single crawl enum for each field 07:04:20 <09gammafunk> there are lots of oddities we still see in kaux and killer/ikiller 07:04:24 <04dracoomega> I mean, since killer_type is only used for the deaths of monsters, it probably doesn't actually get emitted in the logfile, right? 07:04:50 <09gammafunk> hrm, perhaps not 07:05:04 <09gammafunk> so this has no relation to what's used for attribution of player death in general? 07:05:30 <04dracoomega> I think not 07:05:37 <04dracoomega> (I think that uses kill_method_type (and some other stuff)) 07:05:42 <09gammafunk> ok, fair enough 07:06:31 <09gammafunk> something like the uniq milestone verb's noun might be derived from killer_type to some extent 07:06:39 <09gammafunk> but that's not a thing we see issues with 07:06:52 <04dracoomega> Yeah, a few of those are used to emit milestones 07:07:04 <09gammafunk> (aside from the tournament scripts being unhappy ever time a new one is added, but that's just a case up updating tournament logic) 07:07:12 <04dracoomega> But the milestone afterward doesn't really depend on it 07:07:28 <04dracoomega> Like, for instance: C++ KILL_PACIFIED, // only used by milestones and notes KILL_BOUND, // only used by milestones and notes KILL_SLIMIFIED, // only used by milestones and notes 07:07:42 <09gammafunk> right 07:08:30 <04dracoomega> Those at least, are not confusing. But I'm not convinced anyone active can give a comprehensive explanation of how KILL_MISC, KILL_RESET, KILL_DISMISSED, and KILL_TIMEOUT actually differ from each other (but I'm working on it) 07:09:01 <04dracoomega> (There also used to be a KILL_UNSUMMONED that's been removed via version take for like a decade) 07:09:19 <09gammafunk> on the other hand, if you wanted to allow your refactoring project to snowball into cleaning up weird inconsistencies between killer/ikiller/kaux/ktyp, please feel free (don't do this!) 07:09:54 <04dracoomega> Ha. That does sound a lot larger ^^; 07:10:26 <09gammafunk> I think a few cases like these fields having weirdly added grammatical articles are probably low hanging fruit in terms of fixes, so I might take a poke 07:11:29 <04dracoomega> Really, my current scope is some unification / simplification of how duration enchants and killer_types are used by various sorts of temporary monsters, and generalizing of some of the handling of dismissing those on summoner death / level change and such 07:12:34 <04dracoomega> There's bigger tasks with killer_type refactoring that I think would be nice (monster_die() could stand to have quite a few things done to it) but not planning to tackle that all at once 07:14:09 <04dracoomega> (I am poking at this in advance of the Forgecraft spell work that's my Major Project #1 for 0.33 since I think it will benefit from this refactoring a bunch, and it makes sense to me to be able to get this into trunk first, so inevitable bugs can be noticed while I'm still spending weeks coding spells instead of them being on top of all the new spells) 07:16:14 <09gammafunk> the secret to success is to have many dozens of commits titled something like "WIP: daily" in your local branch so that you eventually have to give up on properly rebasing everything into separate changes 07:28:19 <04dracoomega> There's some rather baffling code in monster_die() that converts KILL_RESET into KILL_DISMISSED for a handful of monster types like fire vorticies, foxfires, and simulacra. These two types are very similar (comment claims they differ only in that KILL_DISMISSED lets them drop their inventories, which may or may not be 100% true, but seems close). So this reads a lot like "If a fire vortex died and we were told to also destroy its 07:28:19 inventory, don't." 07:28:34 <04dracoomega> For all the items these monsters are famous for carrying 07:28:48 <04dracoomega> (I think literally only one monster on the entire list can ever have items) 07:55:27 (do https://github.com/crawl/crawl/issues/3800 while you're looking at that :-) 08:46:06 robertstho (L8 FoMo) ASSERT(it != env.trap.end()) in 'traps.cc' at line 764 failed. (Abyss:1) 08:49:21 !crashlog robertstho xl=8 fomo 08:49:23 1. robertstho, XL8 FoMo, T:5179 (milestone): https://crawl.akrasiac.org/rawdata/robertstho/crash-robertstho-20240917-154604.txt 08:51:26 …uh? `feat_is_trap(env.grid(pos))` had just returned false 08:51:42 er, sorry, true or it wouldn;t have reached the `ASSERT` 08:56:16 on the one hand, it's in abyss; on the other, crawl isn't multithreaded so it can't have shifted between the two checks 10:14:12 Nightingale (L15 CoHu) Crash caused by signal #11: Segmentation fault (Orc:1) 10:14:29 <06mumra> That would be a whole other can of ribbon worms honestly 10:20:16 <04dracoomega> This isn't actually contradictory. Basically, there's a map feature corresponding to each trap type, and these features are on the normal feature grid, just like walls and doors. But there's also a list of trap_defs that contains information on the properties of those traps (...this may be mostly superfluous these days, but stored how much ammo they had and maybe some other things). A cell having a trap feature implies there should 10:20:16 be a trap_def entry in that list for that spot, but in this case there somehow isn't. 10:20:36 <04dracoomega> Basically: map says there's a trap there, but trap list doesn't have any data for one at that spot 10:21:21 <04dracoomega> Now, how this actually happened during floor generation, I'm not sure. Is Abyss supposed to remove all traps entirely? Did it grab a chunk of floor for somewhere without either removing trap features or creating trap_defs for them? 10:29:10 !crashlog Nightingale xl=15 cohu 10:29:10 1. Nightingale, XL15 CoHu, T:17174 (milestone): https://underhound.eu/crawl/morgue/Nightingale/crash-Nightingale-20240917-171412.txt 10:31:21 hm, shadow shooting at something, which leads to `monster::friendly()` presumably called on a target which isn't there any more? (might be the warlord that had just died?) 10:35:08 <04dracoomega> I don't think that's possible, since it's in tracer_affect_player 10:35:57 <04dracoomega> And a monster friendliness check there would normally seem to be the agent of the tracer (which should be your shadow) 10:38:25 <04dracoomega> Like, the only place I see that monster::friendly() can be called in that function is the line with ag && ag->as_monster()->friendly() which suggest that there is a non-null agent but it's not actually a monster 10:44:07 <04dracoomega> Looking at the exact order of logic, I am wondering now if this is what happens when you trigger a shadow shot while invisible, and while not able to see invisible, and while your shadow isn't out yet 10:45:21 <04dracoomega> (Since it uses the shadow's mid if it exists, but the shot tracer seems to default to using MID_PLAYER for the tracer if it does not. I'm surprised it doesn't use MID_PLAYER_SHADOW_DUMMY in that case, but possibly this bit of code was before I added that part for spells? 10:45:51 <04dracoomega> MID_PLAYER_SHADOW_DUMMY is basically 'pretend this is from a player shadow that doesn't actually exist yet' 10:53:21 <04dracoomega> Actually, it looks like it's even more specific than that 10:54:10 <04dracoomega> You need to make a shot that triggers a shadow shot and also kill whatever you were aiming at, while your shadow isn't out yet, and you're also invisible and cannot see invis 10:54:37 <04dracoomega> If any of those 4 things are untrue, it works properly 10:57:38 lol 10:58:54 <04dracoomega> (Which explains why I haven't seen this happen more frequently) 11:00:20 <04dracoomega> (But using MID_PLAYER_SHADOW_DUMMY does fix this, hopefully with any other negative side-effects) 11:09:02 03DracoOmega02 07* 0.33-a0-97-g4012fd3d9b: Fix a rare crash with Dith shadow shot 10(5 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/4012fd3d9bc6 11:09:02 03DracoOmega02 07* 0.33-a0-98-gfe4f17deeb: Update a comment 10(3 minutes ago, 1 file, 1+ 2-) 13https://github.com/crawl/crawl/commit/fe4f17deebdf 11:09:02 03DracoOmega02 07* 0.33-a0-99-g2b7a90caab: Remove a tiny bit of obsolete code 10(2 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/2b7a90caab1f 11:13:42 <07acrobat> @dracoomega https://github.com/crawl/crawl/commit/f798c56413617fcd46cedd42b840ec46834aed85 about this change, mimic's sleep stabbing damage is too low so it's not working as intended. imo mimic's sleep stabbing damage should be as strong as the damage of stabber player who has reasonable skills and stats for their xp level. or it should be strong enough to reliably one-shot almost all non-unique monsters player encounters at their xp 11:13:42 level. 11:13:43 <07acrobat> https://cdn.discordapp.com/attachments/747522859361894521/1285664996478554222/1.mp4?ex=66eb1855&is=66e9c6d5&hm=ca3d344cbbdbc88fa64867334bd39d635992893bfdee83364e793d66a0a9d625& 11:13:43 <07acrobat> https://cdn.discordapp.com/attachments/747522859361894521/1285664996889591918/2.mp4?ex=66eb1855&is=66e9c6d5&hm=27e8651715c9a06e0306131e00540e70c82aa3e535ef98abc339173a18ef89c0& 11:13:44 <07acrobat> https://cdn.discordapp.com/attachments/747522859361894521/1285664997443375185/3.mp4?ex=66eb1855&is=66e9c6d5&hm=19cc16448ef43ac092ab790eb7270c683e770113cbf303dc26d501069a28f4ee& 11:18:31 <04dracoomega> Hmmm 11:44:34 <04dracoomega> I guess the thing is, it's easy enough to raise their sleep-stab bonus damage, though I feel there was uncertainty at the time about doing even as much as I did - and I think this is the first feedback I've gotten on it not being good enough. I suppose my hesitancy is that if it is high enough that it does reliably one-shot almost all non-uniques at a given level range, this means that nearly every sleepstab the player makes in the 11:44:34 game will kill two enemies and stabber Dith already seems very good with Shadowslip as an enabler. But maybe 'kill an extra sleeping enemy per encounter' isn't that much better than 'coinflip chance to kill an extra sleeping enemy per encounter' that presently exists? ...though I suppose when I reduced shaow base attack when using quick blades a bit, this technically also nerfed their stabbing with the sort of weapon almost any stabber wants to 11:44:35 eventually be using (though looking at the numbers, that seems to be by about... xl * 0.625 damage per sleepstab, which I guess isn't a lot) 11:56:57 <07acrobat> imo killing an extra sleeping enemy per encounter has almost no balance issues at all. sleeping stab is already a very very weak offensive option in dcss and this is just small buff. and yes, it's not just when using quickblade that mimic's sleep stab damage is too weak (in the third video, my character is wielding dagger!) 12:00:19 <04dracoomega> Well, I'm willing to try raising the numbers a bit more and seeing how that feels 12:00:37 <07acrobat> thank you 🫡 13:16:10 <04dracoomega> Apparently if you leave ball lightning behind on a floor (whether you made them yourself or an enemy did) they will still be there to immediately explode upon your return, no matter how much time has passed 13:17:26 <04dracoomega> (Probably a similar sort of issue that was reported for hellfire mortar 'fast-forwarding' through its actions upon return to a floor, before I made it just disappear whenever you leave) 13:19:01 <04dracoomega> Probably giant spores also do this 13:22:56 <04dracoomega> (Trying to narrow down all the various ways temporary monsters and their durations are handled into the set of differences that actually matter. Like, there's a lot that 'matter' in the sense that it produces different messages with how the code is currently set up, but those can be rearranged into whatever new setup I end up with. But a sort of minimal set of mechanically-relevant properties.) 15:11:41 <04dracoomega> Apparently if you use wizmode dismissal on pharoah ants, they still bind souls. 15:12:22 <04dracoomega> There are a couple situations this actually happens outside of wizmode, but when I checked I don't think this can actually do anything. (If they could leave corpses, then placing a pharaoh ant corpse via levelgen could immediately bind souls of the things around it, though :P) 15:21:10 <04dracoomega> Nice commit message here: 15:21:13 <04dracoomega> %git 40d21e897e6e45167f301ec15fdee10be2cd0f20 15:21:15 <04Cerebot> DracoOmega * 0.12-a0-2611-g40d21e897e: Don't send KILL_RESET creatures to the Abyss (12 years ago, 1 file, 4+ 1-) https://github.com/crawl/crawl/commit/40d21e897e6e 15:21:30 <04dracoomega> Several killer_types need to be merged/deleted/clarified, since it is unclear what some of them do, and variable which ones are actually used in particular circumstances I say 15:21:33 <04dracoomega> 12 years ago 15:39:43 Unstable branch on underhound.eu updated to: 0.33-a0-99-g2b7a90caab (34) 15:51:55 <04dracoomega> Somewhat interesting history here which at least partially explains some of this mess 15:51:58 <04dracoomega> %git e2b04897c0ae8e645985a1e3ddcf2c43ef81f5db 15:51:59 <04Cerebot> due * 0.8.0-a0-5010-ge2b04897c0: New killer_types: banished, unsummoned, timeout. (14 years ago, 4 files, 44+ 26-) https://github.com/crawl/crawl/commit/e2b04897c0ae 15:52:05 <04dracoomega> %git 9bfcc7af377fd7e010ffe90824b2df7dd14f3ef3 15:52:06 <04Cerebot> gammafunk * 0.17-a0-1234-g9bfcc7af37: Remove the unused kill type KILL_UNSUMMONED (9 years ago, 2 files, 6+ 4-) https://github.com/crawl/crawl/commit/9bfcc7af377f 15:52:49 <04dracoomega> Apparently KILL_RESET used to do a whole pile of semi-unrelated things and the plan was to split this up in ways that made more sense, per the commit message of the first commit, but it was never properly done and KILL_UNSUMMONED was removed several years later without having ever been used 15:54:13 <04dracoomega> (This also explains my Don't send KILL_RESET creatures to the Abyss above because separating that out hadn't been properly done at the time either, and some other commits seem to have moved a few things away from KILL_RESET at that time because it was appearing not to work properly) 15:57:47 <04dracoomega> This also partially explains this gloriously nonsense comment that I've probably pointed out before, but which may finally be going away as I figure out what I'm doing with all this: C++ case KILL_BANISHED: // Monster doesn't die, just goes back to wherever it came from. // This must only be called by monsters running out of time (or // abjuration), because it uses the beam variables! Or 15:57:47 does it??? // Pacified monsters leave the level when this happens. 15:58:08 <04dracoomega> (This is used only for banishing things to the Abyss and basically 0 of anything this says is correct) 17:36:34 <09gammafunk> wow, I got to remove something but it was never even used... 18:09:42 03regret-index02 07* 0.33-a0-100-g727ca9edda: New Pan demon: nekomata 10(3 hours ago, 37 files, 227+ 43-) 13https://github.com/crawl/crawl/commit/727ca9edda61 18:09:42 03regret-index02 07* 0.33-a0-101-g9f88647463: Don't let chaos confuse boulders and bombs (#3654) 10(3 hours ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/9f88647463aa 18:09:42 03regret-index02 07* 0.33-a0-102-g5656a03f3f: Prevent more species dummy monsters from getting Crypt zombies 10(2 hours ago, 4 files, 4+ 4-) 13https://github.com/crawl/crawl/commit/5656a03f3f2b 18:09:42 03Lexi Hattaway02 {regret-index} 07* 0.33-a0-103-g80eda39fb5: Add arrival / ecumenical / ice cave entry vaults (#3984) 10(4 weeks ago, 4 files, 137+ 0-) 13https://github.com/crawl/crawl/commit/80eda39fb518 18:26:22 04Build failed for 08master @ 80eda39f 06https://github.com/crawl/crawl/actions/runs/10913696903 18:32:17 segfault! also complaints about the Elf bones file 18:42:05 <04dracoomega> I wonder if there's any specific logic to which parts of cleaning up after a dead monster are done at the start of monster_die() and which are done in monster_cleanup() (called at the end of monster_die() but also in multiple other places, often related to transiting monsters, like shaft traps or Okawaru duel) Obviously the monster continues to exist in some of the latter cases, so some things like enchantments on them not being 18:42:05 removed maybe makes sense, but it feels like there are other things that are in monster_die() but not monster_cleanup() that maybe shouldn't be. Like, cleaning up blood from flaying doesn't happen in the latter case, nor does removing the Bullseye status from the player. 18:45:25 <04dracoomega> Most of these are probably not terribly important, but I kind of wanted to do further reorganizing of monster_die() while I'm at all this and localizing 'cleanup' things that always ought to happen regardless of killer_type more in one place would be nice. (There's also a huge cascade of effects for specific types of monsters dying that all individually have some form of if (!wizard && !reset && !banished) checks in them that I 18:45:26 thought might make sense to pull those checks out of (and maybe put into a separate function). Like "Here's monster-specific stuff that happens when the monster properly actually dies a normal death.") 18:45:58 <04dracoomega> Since essentially none of those things are supposed to happen for anything that isn't a proper normal death 19:10:03 <06pleasingfungus> timing might be tricky. 19:17:29 <04dracoomega> Yeah, like I am wondering if this matters in some cases, and if so - which 19:17:40 <04dracoomega> Some of them I think are just bugs/oversights 19:18:00 <04dracoomega> Oh, you meant about the refactoring out monster on-death effects and not cleanup? 19:18:16 <04dracoomega> Most of them happen at the same point in time now, already 19:19:36 <04dracoomega> There's a big long block of 'do special thing when this monster dies' for different kinds of monsters, mostly all in a row. Spriggan druid's death boon, protean progenitors exploding into aspiring flesh, ice blocks turning into simulacra, etc. 19:38:48 03regret-index02 07* 0.33-a0-104-g8afca07a99: Fix the build 10(3 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/8afca07a9981 19:39:48 -!- 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 19:39:48 -!- 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 19:43:45 03regret-index02 07* 0.33-a0-105-g4c57dba787: Fix an include error 10(11 seconds ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/4c57dba787ca 22:35:28 Unstable branch on crawl.develz.org updated to: 0.33-a0-105-g4c57dba787 (34) 22:58:37 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-105-g4c57dba787 23:34:17 Unstable branch on cbro.berotato.org updated to: 0.33-a0-105-g4c57dba787 (34) 23:55:28 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-105-g4c57dba787