00:24:54 Galadan (L7 VSDe) ASSERT(item.props.exists(ARTEFACT_PROPS_KEY) || is_unrandom_artefact(item)) in 'artefact.cc' at line 1463 failed. (Temple) 00:25:08 <11O​dds> !crashlog galadan 00:25:11 <04C​erebot> 7. Galadan, XL7 VSDe, T:3120 (milestone): https://cbro.berotato.org/morgue/Galadan/crash-Galadan-20260705-072448.txt 00:30:22 03noncinque02 {GitHub} 07https://github.com/crawl/crawl/pull/5317 * 0.35-a0-731-g63c0d0f559: Merge branch 'crawl:master' into master 10(24 seconds ago, 0 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/63c0d0f559fc 00:38:55 03noncinque02 {GitHub} 07https://github.com/crawl/crawl/pull/5317 * 0.35-a0-732-g614ce23f8b: Update egos.txt 10(56 seconds ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/614ce23f8b65 00:53:01 <11O​dds> (Pretty sure I know what's up with this one, thinking through some edge cases and then will fix) 00:55:59 03noncinque02 {GitHub} 07https://github.com/crawl/crawl/pull/5317 * 0.35-a0-733-g1a5eb97e74: Update branches.txt 10(16 seconds ago, 1 file, 5+ 8-) 13https://github.com/crawl/crawl/commit/1a5eb97e747a 01:18:24 03noncinque02 {GitHub} 07https://github.com/crawl/crawl/pull/5317 * 0.35-a0-734-gda66296229: Update branches.txt 10(40 seconds ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/da66296229a2 02:19:09 New branch created: pull/5329 (1 commit) 13https://github.com/crawl/crawl/pull/5329 02:19:10 03Aliscans02 07https://github.com/crawl/crawl/pull/5329 * 0.35-a0-670-g4667eec2e9: Give a description to items the player has detected but not seen. 10(26 minutes ago, 6 files, 16+ 0-) 13https://github.com/crawl/crawl/commit/4667eec2e9a1 03:34:45 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 04:35:31 03CrawlOdds02 07* 0.35-a0-670-g971df940f6: Fix chain removal on complex item sets 10(2 hours ago, 5 files, 56+ 59-) 13https://github.com/crawl/crawl/commit/971df940f602 04:35:31 03CrawlOdds02 07* 0.35-a0-671-g6b413c78bc: Fix abandoning Ash 10(4 hours ago, 1 file, 24+ 9-) 13https://github.com/crawl/crawl/commit/6b413c78bc77 04:35:31 03CrawlOdds02 07* 0.35-a0-672-g01e22e3a22: Fix chain removal from mutation removal 10(2 hours ago, 1 file, 9+ 2-) 13https://github.com/crawl/crawl/commit/01e22e3a2227 04:44:25 <11O​dds> I guess no one has abandoned ash in quite a while 04:58:48 04Build failed for 08master @ 01e22e3a 06https://github.com/crawl/crawl/actions/runs/28739419340 06:19:01 <04d​racoomega> Or at least while wearing cursed items. (It seems my problem last night was not having enough things equipped) 06:20:31 <11O​dds> Yeah, it took at least two curses. I didn't work out exactly what then broke (but I did repro the crash) 06:20:56 <04d​racoomega> It somehow never occurred to me that shattering the items could itself be the cause of the item being garbled garbage. I wrongly assumed that when we destroyed an item, we actually called clear() on it. But apparently we only set a couple of its members to non-item values and just leave all the rest of it intact - including the flags that claim it's an artefact. 06:21:35 <04d​racoomega> The direct cause of the crash is this non-item still looking like an artefact, but its props table being cleared, so it can't tell you anything about its artefact properties 06:22:18 <11O​dds> Right, it's quite surprising the item isn't more garbage 06:22:35 <04d​racoomega> Like, if you look in dec_inv_item_quantity(), what it does for using an item up entirely is only set some members to default values. I... can't really see why? This seems like bad policy? 06:22:49 <04d​racoomega> Several other places also do this 06:23:01 <04d​racoomega> Though a lot of that code is very old 06:23:33 <04d​racoomega> (It is probably incredibly marginally more expensive to call item_def::clear(), but completely irrelevantly so) 06:23:49 <11O​dds> I agree. 06:25:20 why do I find myself suspecting there will be crashes due to e.g. later processed deaths linked to the removed/cleared items? 06:25:29 that wouldd be very crawlcode 06:25:33 <04d​racoomega> What do you mean? 06:26:43 <04d​racoomega> The player's full inventory is a fixed array of item_defs. 'Non-items' are just instances of those item_defs that are basically all zeros. There's no pointer concerns here. 06:27:03 monster killed by item, death deferred for some reason (e.g. fiuneff to avoid some _other_ issue) but holding reference to item that killed them, item gets cleared because e.g. last projectile or sth., then fineff death processed using invalid item reference? 06:27:58 <04d​racoomega> I mean, I can't curently think of an issue that could be caused by holding a reference to an OBJ_UNASSIGNED that still has its old flags versus an actual clean one 06:28:06 <11O​dds> There could however be places which access half cleaned-up items and don't mind about how they are half-cleaned-up 06:28:36 <11O​dds> (But if so this is bad, we shouldn't have this strange half-valid items) 06:29:04 <04d​racoomega> Yes 06:29:13 <04d​racoomega> Like, obviously I can't rule out some place doing something weird here 06:29:22 <04d​racoomega> But I suspect most of them would already show broken behavior 06:29:42 <04d​racoomega> (But apparently abandonining Ash has been broken since 0.33 and nobody notic) 06:30:11 <04d​racoomega> (Thanks a lot for all this. I was definitely the one who broke it, too >.>; ) 06:30:46 <11O​dds> Usually the case because you've reworked ~all the code by now 😉 06:30:59 <04d​racoomega> I admit I was... rather dismayed to realize how wrong handle_chain_removals() apparently was >.> 06:31:46 <11O​dds> It felt like it was probably written with the one-item case in mind 06:31:51 <04d​racoomega> (I'd still been planning to look into those periodic Vainglory shattering bugs for a while, but I will admit that the fact that that bug automatically fixes itself a short while into playing any further had repeatedly allowed me to put it off) 06:32:08 <11O​dds> Oh, does it? 06:32:30 <04d​racoomega> Equipped items are validated whenever the player is loaded, which quietly pops off any items you don't have the slots for 06:32:39 <04d​racoomega> And the player gets loaded at every floor change, and several other places, too 06:32:51 <11O​dds> Ah, I didn't realise the latter 06:32:56 <04d​racoomega> So you get the extra rings for - at most - the rest of the floor 06:33:33 <04d​racoomega> (It was originally save compat code to handle certain item changes. I hadn't thought about it being called during normal play. But that turned out to be a positive side-effect also.) 06:33:49 New branch created: pull/5330 (1 commit) 13https://github.com/crawl/crawl/pull/5330 06:33:49 03Aliscans02 07https://github.com/crawl/crawl/pull/5330 * 0.35-a0-673-g03e38ed4fa: Describe things under the cursor on the level map in console. 10(31 minutes ago, 10 files, 135+ 50-) 13https://github.com/crawl/crawl/commit/03e38ed4fa6f 06:34:37 <04d​racoomega> Like, there was a bunch of bespoke old code for things like boots of the assassin becoming a hood of the assassin, and this replaces most of that by quietly ensuring nothing is in the wrong place 06:34:54 <11O​dds> (Vainglory was just not doing chaining at all I think, handle_chain_removal would have just worked there) 06:34:59 <04d​racoomega> Huh, really? 06:35:32 <11O​dds> I think so. 06:36:04 <11O​dds> I mean, I'm sure it wasn't doing chaining. I think that handle_chain_removal would just have worked, though I'm a little uncertain about how the old version would have gone with possibly stale slot counts 06:36:53 <11O​dds> Makes me wonder if the player reload is doing chain removal, actually... 06:38:26 <04d​racoomega> ....probably not 06:38:46 <11O​dds> Hmmmm yeah get_forced_removal_list is in general not chaining. It probably just should do that centrally, though the mutation case did want to know which items were directly removed... 06:40:21 <11O​dds> I'll have a think, probably get_forced_removal_list should chain but IDK much about its callers 06:43:43 <04d​racoomega> There's some mildly complicated stuff in transform.cc, I believe 06:44:21 <04d​racoomega> Since sometimes it melds things and sometimes it removes things, depending 06:45:09 <04d​racoomega> For instance: 06:45:11 <04d​racoomega> %git 2e3b24b 06:45:12 <04C​erebot> DracoOmega * 0.34-a0-82-g2e3b24bea0: Improve a few things related to sphinx/serpent form additional slots (1 year, 1 month ago, 6 files, 84+ 28-) https://github.com/crawl/crawl/commit/2e3b24bea056 06:46:37 03CrawlOdds02 07* 0.35-a0-673-gf876266f55: Don't duplicate letters in quiver menu (bobkiller) 10(27 minutes ago, 1 file, 7+ 2-) 13https://github.com/crawl/crawl/commit/f876266f5510 06:47:42 <04d​racoomega> It does seem like a good idea that get_forced_removal_list() handle chainining, though I suspect there was some reason I was handling it separately originally 06:48:01 <04d​racoomega> (I cannot remember now what that may have been) 06:48:28 <04d​racoomega> As you say, there are cases where messaging definitely wants to know what immediate forced removal 06:49:16 <04d​racoomega> But it might be possible to use an outparam for that, in the subset of cases where those are known. So that the 'default' behavior is more complete. 06:49:34 <11O​dds> Yeah, I'll have a careful think about what callers want what 07:47:25 03CrawlOdds02 07* 0.35-a0-674-gf2e42f2ff0: Make forced removal of items cascade. 10(41 minutes ago, 3 files, 16+ 8-) 13https://github.com/crawl/crawl/commit/f2e42f2ff016 07:48:31 <11O​dds> (As far as I could see all the callers were pleased to chain) 07:57:56 <04d​racoomega> Ah, simpler than anticipated. Nice. 09:11:07 <09h​ellmonk> Going to start throwing branch today 09:22:51 <09g​ammafunk> stop harming trees with your branch throwing, hellmonk 12:14:55 New branch created: pull/5331 (1 commit) 13https://github.com/crawl/crawl/pull/5331 12:14:56 03Aliscans02 07https://github.com/crawl/crawl/pull/5331 * 0.35-a0-673-g08bc83e7a4: Show the in-game colours in the monster help lookup. 10(38 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/08bc83e7a414 12:43:43 03Aliscans02 {CrawlOdds} 07* 0.35-a0-675-g4a731d5719: Show the in-game colours in the monster help lookup. 10(67 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/4a731d571972 13:18:01 <11O​dds> I may be missing something in the docs, but is there a guide for running webtiles locally (for development purposes)? 13:18:58 https://crawl.montres.org.uk/wsl-webtiles.txt (which I think is linked? adapted? somewhere in your docs) 13:19:23 I think it's basically just python webserver/server.py 13:19:29 On Linux it's trivial: make -j 4 DEBUG=yes NO_OPTIMIZE=yes WEBTILES=y FORCE_CXX=g++ 13:19:32 python3 webserver/server.py 2> foo 13:19:37 <08o​____0> https://github.com/crawl/crawl/tree/master/crawl-ref/source/webserver 13:19:42 ah, see webserver/README.md 13:20:00 <08o​____0> "Running the server for testing purposes" section! 13:20:54 <11O​dds> Thank you both! 13:22:39 <11O​dds> I was looking at https://github.com/crawl/crawl/pull/5330, which gives item descriptions on X and mouseover... and it made me think this should be a thing on tiles 14:28:14 03Aliscans02 07https://github.com/crawl/crawl/pull/5329 * 0.35-a0-671-g3579f4eadf: Do not mark detected items as being defined. 10(65 seconds ago, 4 files, 3+ 7-) 13https://github.com/crawl/crawl/commit/3579f4eadf26 14:38:54 03DracoOmega02 07* 0.35-a0-676-g598ad577b8: Fix invis monsters sometimes being incorrectly listed in webtiles (Odds) 10(40 seconds ago, 1 file, 3+ 2-) 13https://github.com/crawl/crawl/commit/598ad577b87e 15:44:34 Unstable branch on underhound.eu updated to: 0.35-a0-676-g598ad577b8 (34) 19:04:05 <09h​ellmonk> throwing branch started, if there are specific things that need to go in hit me up whenever. 19:09:08 I throw my runs regularly, glad to assist 19:19:19 <08o​____0> haha 20:17:59 progressplayers (L23 HuSu) Crash caused by signal #11: Segmentation fault (Depths:2) 20:18:12 progressplayers (L23 HuSu) Crash caused by signal #11: Segmentation fault (Depths:2) 20:18:52 progressplayers (L23 HuSu) Crash caused by signal #11: Segmentation fault (Depths:2) 20:19:20 x` 20:19:27 gah; I'm so good at irc 20:24:39 progressplayers (L23 HuSu) Crash caused by signal #11: Segmentation fault (Depths:2) 20:25:12 <08o​____0> Player says they are just casting haunt on an empty tile to crash 20:25:57 !crashlog 20:26:02 23267. progressplayers, XL23 HuSu, T:92928 (milestone): https://crawl.akrasiac.org/rawdata/progressplayers/crash-progressplayers-20260706-032438.txt 20:26:59 crashlog supports that to the extent it can (can't tell if it's actually an unoccupied tile) 20:27:05 also no gdb so can't tell where 20:28:05 progressplayers (L23 HuSu) Crash caused by signal #11: Segmentation fault (Depths:2) 20:28:53 <11O​dds> Yeah it's the recent invis changes (01f08a5fe2). That removed a guard in haunt that we have a monster - perhaps it was supposed to change the targetter to make this impossible (or perhaps it was simply a mistake)? 20:30:48 (meanwhile I forgot to build once with bear so clangd will work) 21:20:01 <04d​racoomega> Wait, did I not change the targeter?? I specifically remember doing this. 21:23:07 <04d​racoomega> I even remember vacillating for a bit over how using common code for this meant a slightly less flavorful message for aiming haunt at an ally 21:27:15 03DracoOmega02 07* 0.35-a0-677-ge094053662: Fix a Haunt crash when casting on an empty space 10(72 seconds ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/e094053662e0 21:41:24 04Build failed for 08master @ e0940536 06https://github.com/crawl/crawl/actions/runs/28767758366 22:36:03 Unstable branch on crawl.develz.org updated to: 0.35-a0-677-ge094053662 (34) 22:59:58 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-677-ge094053662 23:33:41 Unstable branch on cbro.berotato.org updated to: 0.35-a0-677-ge094053662 (34) 23:56:14 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-677-ge094053662