00:38:41 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-4917-g3c53b74d1c 00:40:40 Fork (bcadrencrawl) on crawl.kelbi.org updated to: 0.03-1744-geb4f42f938 03:22:57 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-4917-g3c53b74d1c 05:07:08 Unstable branch on crawl.akrasiac.org updated to: 0.31-a0-18-gea43df2 (34) 05:39:34 is anyone planning on working on autotravel any time soon? i was thinking about trying my hand at it if it isn't already on someone's list. thought it might be cool and/or break my brain 05:41:45 i was looking for tests or scripts that log info about a path taken but didn't find any so was thinking i might start by adding something like that to see if i could get consistent results between the existing algorithm and something new 06:27:28 <06a​dvil> there's some debug logging code if you define DEBUG_TRAVEL, it's relatively minimal though 06:27:59 <06a​dvil> I had to add a bunch more when debugging the exclusion patch issues to see what it was really doing 06:40:06 wondering if i could throw in a turn counter for a path taken from start to end but not sure if that would really work the way the code is written. mostly just trying to figure out how to make sure any changes don't degrade the efficiency of it 06:42:27 <06a​dvil> it looks to me like the db rebuild last night took about 3hrs 06:51:21 <06a​dvil> as far as I can tell rage 2/3 are being correctly awarded now 06:52:51 <10P​leasingFungus> thanks! 08:03:09 I can confirm that I now have gotted rage 2 retroactively awarded, thanks :) 08:03:29 s/gotted/gotten/ 08:06:55 <08n​icolae> where can i see what i've won and my scores and stuff 08:07:51 <08n​icolae> oh there we go 08:12:17 <06a​dvil> I guess we don't have a page in the current t scripts that shows which players have gotten which banner? 08:12:21 <06a​dvil> or am I missing something 08:12:35 <06a​dvil> old t scripts used to have this 08:16:25 yeah, it looks like the best you can do is view source on https://crawl.develz.org/tournament/0.30/banner-collection.html and then search for the banner you are interested in 08:17:35 which tells me that 8 people have Rage 3, and sequell query gives the same thing, so seems good 08:18:18 btw it bothers me slightly that the banner image border ordering is dashed -> dotted -> solid 08:18:27 surely dashed is closer to solid than dotted is! 09:04:30 <06a​dvil> maybe it would be clearest to have no outline for tier 1 09:05:28 <06a​dvil> also did we never implement a banner tab at all for individual team pages 09:05:50 <06a​dvil> I wish I had any time at all to spend on this stuff right now 09:06:57 <09g​ammafunk> no worries; I'm really glad I was able to just rebuild the db on cdo because I likewise wasn't going to have lots of time in the next few days to go setting up a server to rebuild the db 13:44:46 <03r​obertxgray> I'm pretty sure we're facing this same issue after removing the "git fetch" from the CI workflows: https://github.com/eclipse-zenoh/zenoh/issues/153 13:46:24 <03r​obertxgray> this is a simple test showing the problem, there's an annotated tag "0.32" in the latest commit: https://github.com/robertxgray/crawl/actions/runs/4930103812/jobs/8810594557 14:02:14 <03r​obertxgray> tomorrow I'll test solutions, I should go to sleep, bye 19:31:16 <08n​icolae> https://www.reddit.com/r/dcss/comments/13dbyo9/vault_placement_failure_for_gammafunc_ghost_smash/ i already replied but i'm not quite sure what the issue could be 🤔 19:48:03 <09g​ammafunk> gammafunc??? 19:48:23 <09g​ammafunk> yeah surprised that one missed the update 19:49:48 <09g​ammafunk> I see, it didn't, they somehow have a stale des cache 19:58:46 <09g​ammafunk> @robertxgray I think this reddit user at https://www.reddit.com/r/dcss/comments/13dbyo9/vault_placement_failure_for_gammafunc_ghost_smash/ is running a Linux AppImage and somehow has a stale des cache. Not sure how that happened, but normally I'd tell someone to run crawl -builddb from the command line to fix it, yet that's not going to be so easy for the AppImage. Any help you can offer generally? 20:15:28 <09g​ammafunk> @advil this is sort of amusing. The lua items library get_items_at() function checks map knowledge to know if an item exists at a given map location, but then pulls the actual list of items from the player's stash data. So for things like the sensed abyssal rune (and presumably other map sensed items), the map knowledge check succeeds yet the stash has nothing (since it's purely sensed map knowledge). Hence get_items_at() returns an 20:15:28 empty lua list instead of returning nil like it would if it didn't detect any items. I guess the way to fix this would be to check the map knowledge items after checking the stash, and perhaps put a more convenient item list interface on the map knowledge so we can iterate more easily. Not sure if there's otherwise a reason to prefer looking at the stash first (e.g. useless items?) 20:18:14 <09g​ammafunk> now that I think I've finally (finally!) fixed all the awful bugs in my distance mapping implementation (the abyss was a real tour-de-force in terms of test the assumptions of the new code), looks like we'll sadly have to wait on qw moving towards the sensed rune, but it can still move towards e.g. runelights and the actual rune when it's spotted in LOS, at least 20:29:33 <06a​dvil> I'm not sure I understand the issue but the checkout action does run git fetch; the command I removed as far as I could tell does nothing more than shallows the fetch depth to 1 20:30:19 <06a​dvil> you can repeat the steps locally to get its effect (breaking git describe on trunk because the depth is too shallow) 20:32:08 <06a​dvil> huh, weird interaction, not immediately sure if sensed abyss runes should or shouldn't be in the stash tracker? 20:33:20 <09g​ammafunk> it would be nice to have an interface to the sensed map items in general, and some probably just can't be in the stash. I haven't looked, but things like gnoll sensed items and gozag sensed gold (if that still exists) 20:33:31 <06a​dvil> more specifically actions/checkout runs /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*, which aside from the --depth==1 (which is wrong) seems entirely redundant with the command I removed, which is run after that action 20:34:00 <09g​ammafunk> maybe those could be in the stash, but you can't travel to them, and I'm not sure if that breaks assumptions of stash 20:34:11 <06a​dvil> right, yeah, sensed items probably would be problematic in the stash 20:34:17 <06a​dvil> they are a weird type as well iirc 20:34:52 <09g​ammafunk> even crawl's actual interface to the sensed items seems bad; at least for the rune you can't x-v it or see any summary of what it is 20:35:25 <09g​ammafunk> well, not "bad", since it's better than nothing, but would be nice if you could at least confirm what you were looking at somehow 20:35:38 <06a​dvil> yeah, probably xv should work 22:34:56 Unstable branch on crawl.develz.org updated to: 0.31-a0-18-gea43df2a32 (34) 22:56:22 Windows builds of master branch on crawl.develz.org updated to: 0.31-a0-18-gea43df2a32 23:54:03 Monster database of master branch on crawl.develz.org updated to: 0.31-a0-18-gea43df2a32