00:00:31 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-818-g31569e1b94 00:11:55 <11O​dds> For a long time CAO hasn't autoupdated, but the two manual buids I kicked off in that time succeeded 00:22:47 Thanks for fixing the CDO builds! 00:22:47 Goratrix: You have 1 message. Use !messages to read it. 00:23:06 !messages 00:23:06 (1/1) gammafunk said (2h 34m 49s ago): The CDO trunk builds have been fixed, thanks for the report. 03:35:07 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 07:45:16 New branch created: pull/5355 (257 commits) 13https://github.com/crawl/crawl/pull/5355 07:46:53 03Amelia02 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-547-g5d94e9f4b9: Jessica Modified 10(6 weeks ago, 3 files, 17+ 3-) 13https://github.com/crawl/crawl/commit/5d94e9f4b9fc 07:46:53 03Amelia02 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-548-gab0625cd59: Update mon-gear.cc 10(6 weeks ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/ab0625cd59c5 07:46:53 03Amelia02 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-549-g39714843b5: Update mon-gear.cc 10(6 weeks ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/39714843b539 07:46:53 03RoGGa02 {GitHub} 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-559-gfcb7cde2c6: Merge pull request #4 from AmeliaGryffon/Jessica-Modified 10(6 weeks ago, 0 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/fcb7cde2c6ec 07:46:53 03RoGGa02 {GitHub} 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-564-gdbd24358d6: Merge branch 'crawl:master' into master 10(6 weeks ago, 0 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/dbd24358d655 07:46:53 03RoGGa02 {GitHub} 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-577-g8dd1c3c4c5: Merge branch 'crawl:master' into master 10(5 weeks ago, 0 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/8dd1c3c4c5d7 07:46:53 03Lucien-main02 {GitHub} 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-585-gd54d7d30a2: Merge branch 'crawl:master' into master 10(5 weeks ago, 0 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/d54d7d30a2ea 07:46:53 03Lucien02 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-586-gf9bc037fe1: [Silent Spectre] [BcadrenCrawl Port] Initial YAML setup. 10(5 weeks ago, 1 file, 71+ 0-) 13https://github.com/crawl/crawl/commit/f9bc037fe1f5 07:46:53 03Lucien02 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-587-ge7c45348c5: [Silent Spectre] [BcadrenCrawl Port] Undead State: Ghost added. This also allows Poltergeists to transform. 10(5 weeks ago, 8 files, 23+ 5-) 13https://github.com/crawl/crawl/commit/e7c45348c5b9 07:46:53 03RoGGa02 {GitHub} 07https://github.com/crawl/crawl/pull/5355 * 0.35-a0-586-ga3022414e8: Update .gitignore with additional file patterns 10(5 weeks ago, 1 file, 56+ 0-) 13https://github.com/crawl/crawl/commit/a3022414e800 07:46:53 ... and 247 more commits 09:51:45 <09g​ammafunk> hmmm 09:51:57 <09g​ammafunk> > make[1]: Leaving directory /home/crawl-dev/dgamelaunch-config/crawl-build/crawl-git-repository/crawl-ref/source/rltiles' > * If you experience any problems building Crawl, please take a second look > * at INSTALL.md: the solution to your problem just might be in there! > PYTHON config.h > PYTHON mon-data.h > Traceback (most recent call last): > File "util/mon-gen.py", line 439, in > main() > File 09:51:57 "util/mon-gen.py", line 412, in main > text = load_template(args.templatedir, 'header.txt') > File "util/mon-gen.py", line 396, in load_template > return open(os.path.join(templatedir, name), encoding='utf-8').read() > TypeError: 'encoding' is an invalid keyword argument for this function > make: *** [mon-data.h] Error 1 > make: Leaving directory /home/crawl-dev/dgamelaunch-config/crawl-build/crawl-git-repository/crawl-ref/source' 09:52:19 <09g​ammafunk> I think that python encoding fix is problematic on cao somehow 09:52:38 <09g​ammafunk> are we somehow using a different python in the cron vs the rebuild script? 09:59:30 <09g​ammafunk> seems like that's what's happening 09:59:44 <09g​ammafunk> I guess it's using a default python2, or something 10:00:01 <09g​ammafunk> so this is probably as simple as updating some paths 10:01:28 The year is 2026 and python2 migration is still ongoing 😭 10:02:07 <09g​ammafunk> now the question is how is the CGI builder getting the correct python 11:38:07 03dolorous02 07* 0.35-a0-819-gf82e23d98b: Fix typos. 10(3 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/f82e23d98b1d 12:10:00 03Eivin Hatvik02 {CrawlOdds} 07* 0.35-a0-820-ga221df3ca9: feat: show owned consumable counts in shops 10(12 days ago, 4 files, 119+ 1-) 13https://github.com/crawl/crawl/commit/a221df3ca90a 12:15:42 Unstable branch on crawl.akrasiac.org updated to: 0.35-a0-819-gf82e23d98b (34) 12:17:27 <09g​ammafunk> that was with the rebuild script...I do need to track down how it's able to path to python3 via web activation while the cron somehow isn't 15:02:38 03DracoOmega02 07* 0.35-a0-821-g6768c1c5d0: Hopefully fix cursor for ranged attacks 'sticking' to old dead targets 10(81 seconds ago, 1 file, 0+ 1-) 13https://github.com/crawl/crawl/commit/6768c1c5d07e 15:02:38 03DracoOmega02 07* 0.35-a0-822-ge566e939d5: Unbrace 10(16 seconds ago, 1 file, 0+ 2-) 13https://github.com/crawl/crawl/commit/e566e939d54a 15:15:28 04Build failed for 08master @ 6768c1c5 06https://github.com/crawl/crawl/actions/runs/30769179774 15:43:59 Unstable branch on underhound.eu updated to: 0.35-a0-820-ga221df3ca9 (34) 15:55:15 03DracoOmega02 07* 0.35-a0-823-g340866cc77: Fix a clang compile warning (Ge0FF) 10(77 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/340866cc77ed 16:06:47 Eldin (L12 CoAr) ASSERT(desc) in 'describe.cc' at line 5120 failed. (D:9) 16:12:07 <04d​racoomega> Hmm... odd crash there. I think that is happening is they're xving the memory of a monster who had an attack flavour that no longer exists 16:12:18 <04d​racoomega> Since they last saw it in an old version 16:12:57 <04d​racoomega> (This is another situation where I'm not sure an assert is the right call. If we don't have a description for an attack flavour, surely this isn't the best way to inform us) 16:33:55 hm, should that behave like "ghosts"? 16:36:00 <04d​racoomega> I mean, it seems perfectly valid to just give an empty or placeholder description, does it not? (We do this with removed items) 16:36:13 yes 16:36:40 and I agree an assert is the wrong thing to do, if it was removed it was for a reason 16:36:54 asserts should be to catch oversights or errors 16:37:33 although I guess one could argue the oversight was not cleaning it up when reading the save file 16:45:28 <04d​racoomega> I mean, I think the 'oversight' is more likely to be 'X new thing is missing a description' (but that is also not assert-worthy, imo) 16:50:04 no, that one sounds more like "… of bugginess" 16:51:45 New branch created: pull/5358 (1 commit) 13https://github.com/crawl/crawl/pull/5358 16:51:45 03Aliscans02 07https://github.com/crawl/crawl/pull/5358 * 0.35-a0-824-g2ea87a39fd: Let view.get_map() report solid excluded features. 10(78 seconds ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/2ea87a39fdc5 17:01:11 Eldin (L12 CoAr) ASSERT(desc) in 'describe.cc' at line 5120 failed. (D:9) 18:11:34 Eldin (L12 CoAr) ASSERT(desc) in 'describe.cc' at line 5120 failed. (D:9) 18:24:14 <04d​racoomega> They really want to examine that orange demon 18:34:12 03DracoOmega02 07* 0.35-a0-824-g375e6f9dbe: Don't assert on looking up the description of a flavour without one 10(49 seconds ago, 1 file, 5+ 1-) 13https://github.com/crawl/crawl/commit/375e6f9dbef1 19:14:53 Centroid (L6 MiBe) Crash caused by signal #11: Segmentation fault (D:5) 19:15:14 Centroid (L6 MiBe) Crash caused by signal #11: Segmentation fault (D:5) 19:15:29 Centroid (L6 MiBe) Crash caused by signal #11: Segmentation fault (D:5) 19:17:01 Centroid (L7 MiBe) Crash caused by signal #11: Segmentation fault (D:5) 19:17:16 Centroid (L6 MiBe) Crash caused by signal #11: Segmentation fault (D:5) 19:19:14 Centroid (L7 MiBe) Crash caused by signal #11: Segmentation fault (D:5) 19:24:39 Centroid (L6 MiBe) Crash caused by signal #11: Segmentation fault (D:5) 19:25:56 Centroid (L6 MiBe) Crash caused by signal #11: Segmentation fault (D:5) 20:12:25 <04d​racoomega> I already know the root cause of this now, for the record. I'm just debating what to do about some other very weird behavior it uncovered. 20:12:53 <08o​____0> ah ok I was about to say haha 20:13:09 <08o​____0> isflag_unobtainable items, easy to reproduce with the seed 20:14:15 <04d​racoomega> The issue is that 'unobtainable' items aren't actually added to the stash tracker. And the code is currently making the assumption that if there are any items on a tile, that at least one of them is 'best' (ie: to put on top of the pile). I hadn't even internalized what would happen here. But apparently the fact that unobtainable items don't get added to the stash tracker means that xv pretended they didn't exist. 20:14:26 <04d​racoomega> Like, that isn't new behavior. If you examine such an item, you'd just see floor. 20:14:47 <04d​racoomega> The only remaining use of this flag is in grunt_nemelex_the_gamble 20:15:37 <08o​____0> oh I was wondering cause I had never noticed that flag before 20:15:47 <04d​racoomega> (Unfortunately, while merely not adding them to the stash tracker solves this crash, it causes them to just become completely invisible, now that we use the stash tracker to determine what item to render on top) 20:16:15 <08o​____0> aaaaaah 20:16:54 <04d​racoomega> Which is maybe not the best place to do this, but it felt like doing it outside would be duplicating a lot work given that we were already doing much of the needed work here, every time we refresh the screen 20:17:40 <04d​racoomega> (And with the stash tracker already used to control what xv shows you, it feels like simply not listing them was already a bug, if a less serious one) 20:17:53 <04d​racoomega> It's also kind of funny here since the items are frequently not unobtainable 20:20:56 <04d​racoomega> I'm half-tempted to say that we don't need special handling for a couple items in a single vault and they can just show up in stash search in general. (Though perhaps they could also just be hidden in search results, but tracked normally otherwise) 20:21:36 <04d​racoomega> It just feels a little silly to be keeping this flag around for exactly one vault, where the flag lies half the time anyway 20:22:05 <08o​____0> is_dubiously_obtainable 20:28:52 <04d​racoomega> Apparently the other effect of this flag is to make said item not count as 'seen' for the purposes of acquirement weighting 20:35:52 03DracoOmega02 07* 0.35-a0-825-g2ba693354f: Fix a softlock involving grunt_nemelex_the_gamble 10(26 seconds ago, 1 file, 5+ 5-) 13https://github.com/crawl/crawl/commit/2ba693354f03 22:37:43 Unstable branch on crawl.develz.org updated to: 0.35-a0-825-g2ba693354f (34) 23:02:27 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-825-g2ba693354f 23:35:26 Unstable branch on cbro.berotato.org updated to: 0.35-a0-825-g2ba693354f (34) 23:37:56 <11O​dds> Yeah I think we should remove it. It seems bad for this vault in particular - way worse to hide the item when it is obtainable than hide it when not - and confusing in general to have items hidden in ways players can’t understand. 23:42:54 <04d​racoomega> That is a fair point. (Also, at this point the 'cost' of ?acquirement falsely caring about an item you saw but couldn't obtain is possibly also not important enough to have additional infrastructure for.) 23:43:20 <04d​racoomega> Though did you know that you apparently don't count as 'seeing' a type of equipment if it's in a shop and you can't actually afford it at the time you see it? >.> 23:43:34 <04d​racoomega> Or so it looks like, anyway 23:45:08 <04d​racoomega> I'm really not sure what I think of that 23:46:23 <04d​racoomega> I'm sure approximately nobody knows about this, though I'm wondering if it is actually helpful to characters or not 23:46:41 <11O​dds> I did not know that.... and mildly dislike it as confusing, but it's not a particularly bad thing to confuse people about 23:46:58 <11O​dds> If you find a really expensive barding in a shop it's probably good 23:48:30 <04d​racoomega> (Inversely, if you find reasonably-priced weapons there early on, but don't yet have any gold, they don't get downweighted by ?acq, even though the player probably feels that they've seen them) 23:49:43 <04d​racoomega> I'm mostly not sure what I think of it depending specifically on how much gold you had when you first entered the shop, wherever it was 23:50:12 <11O​dds> Yeah I agree. It's an untidy thing to depend on, and in an extremely mild and unimportant way presumably leads to some odd incentives 23:50:46 <11O​dds> Like if I see a weapon shop early on perhaps I should spend all my gold in another shop 23:51:25 <11O​dds> Then I can have my lightly used demon blade and acquire one too 23:51:32 <04d​racoomega> All of this stuff likely only has extremely minor effects not worth caring much about. (But inversely, if this mechanic isn't actually doing anything that important, maybe it's... not important that it does it?) 23:52:04 <04d​racoomega> Like, I'm certainly not against 'Mechanic players don't know about doing subtle work behind the scenes.' in general. Sometimes they're quite meaningful. 23:52:13 <04d​racoomega> But I'm not really sure this is 23:52:25 <11O​dds> Right, acquirement weighting in general is an example 23:52:45 <11O​dds> I'd be in favour of removing this one as minor and surprising 23:59:17 <07w​izardike> Hiding an item from search that you might want to come back for when you get shatter castable seems dubious at best 23:59:43 <04d​racoomega> You can't shatter into the vault; it's indestructible 23:59:50 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-825-g2ba693354f