00:03:01 <gammafunk> I'll should be going through PRs sometime soon this week
00:03:35 <gammafunk> not saying all will be merged of course! But looked at and either merged, closed, or at least commented on, unless they're just old ones that are kind of stuck
00:24:58 <alexjurkiewicz> :)
00:24:58 <Sequell> alexjurkiewicz: You have 1 message. Use !messages to read it.
00:25:03 <alexjurkiewicz> !Messages
00:25:03 <Sequell> (1/1) hellmonk said (2h 54m 20s ago): send a PR if you can, please
00:35:36 <alexjurkiewicz> hellmonk: how do you feel about replacing GC with GSC. If Ogres only get one of them and they have +3 apt...
00:35:58 <hellmonk> undecided on what the long term ogre plans are
00:36:07 <hellmonk> prob gonna continue to ignore it for now
01:20:01 <alexjurkiewicz> @??bai suzhen
01:20:01 <Gretell> Bai Suzhen (12d) | Spd: 10 | HD: 20 | HP: 152-216 | AC/EV: 14/8 | Dam: 24, 14 | 10weapons, 10items, 10doors, spellcaster, cold-blooded, see invisible | Res: 06magic(100), 02cold, 11elec+++, 03poison | Vul: 11silver | XP: 5269 | Sp: sum.hydra | Sz: Medium | Int: human.
01:20:03 <alexjurkiewicz> @??bai suzhen dragon
01:20:03 <Gretell> Bai Suzhen (11D) | Spd: 10 | HD: 20 | HP: 148-218 | AC/EV: 22/4 | Dam: 30, 1609(claw), 1607(trample) | 10doors, cold-blooded, see invisible, fly | Res: 06magic(100), 02cold, 11elec+++, 03poison, 12drown | Vul: 11silver | XP: 5259 | Sp: primal wave (3d26) [11!AM, 06!sil, 08breath], r.thunder [11!AM, 06!sil] | Sz: Giant | Int: human.
01:20:12 <alexjurkiewicz> @??xtahua
01:20:12 <Gretell> Xtahua (05D) | Spd: 10 | HD: 20 | HP: 106-153 | AC/EV: 15/7 | Dam: 35, 1709(claw), 2007(trample) | 04breaks doors, see invisible, fly | Res: 06magic(180), 05fire++, 03poison, 12drown | Vul: 12cold | XP: 4809 | Sp: searing breath (3d40) [11!AM, 06!sil, 08breath], paralyse | Sz: Giant | Int: human.
01:27:07 <Cheibriados> New branch created: pull/583 (1 commit) 13https://github.com/crawl/crawl/pull/583
01:27:07 <Cheibriados> 03Alex Jurkiewicz02 07https://github.com/crawl/crawl/pull/583 * 0.21-a0-154-g91904c7: Increase Bai Suzhen's defenses 10(6 minutes ago, 1 file, 5+ 5-) 13https://github.com/crawl/crawl/commit/91904c717329
01:46:49 <gammafunk> alexjurkiewicz: not going to merge the bai suzhe PR, disagree that bai suzhen has a problem more than other uniques, or at least one that would be solved by her having more HP
01:47:04 <gammafunk> !killratio asterion * recent elf:3|depths|snake:3|snake:4|spider:3|spider:4|vaults:2|vaults:3
01:47:08 <Sequell> asterion wins 1.252% of battles against * (recent elf:3|depths|snake:3|snake:4|spider:3|spider:4|vaults:2|vaults:3).
01:47:17 <gammafunk> this is not too much higher than bai suzhen
01:47:29 <gammafunk> and he has significantly less HP and defenses than her
01:48:00 <gammafunk> if she has a problem it's fairly small and it would be more her abilities being dangerous
01:48:07 <gammafunk> she has a massive amount of HP and quite high AC as well, even if she maybe doesn't use body armor
01:49:38 <gammafunk> moving her placement shallower would make her more dangerous, if that's necessary, but we've sort of historically said that anything like a 1% kill ratio is a rough metric of "good enough"
01:57:13 <Gretell> Windows builds of master branch on crawl.develz.org updated to: 0.21-a0-154-gb5400c9
02:26:21 <alexjurkiewicz> gammafunk: i guess i think most uniques would be more interesting if they died slower, especially onces like bai suzhen & louise
02:26:58 <johnstein> !killratio bai_suzhen
02:27:02 <Sequell> bai_suzhen wins 1.173% of battles.
02:33:52 <Henzell> Toadsmash (L25 FoAK) ERROR in 'cloud.cc' at line 580: cloud grey smoke in granite_statue at (35,46) (Depths:2)
02:34:05 <gammafunk> interesting crash
02:42:26 <|amethyst> gammafunk:  I get the same crash reliably when I Corrupt in the vicinity of that vault (statue_in_the_mist_lemuel)
02:44:32 <|amethyst> and when I do that while the statue is in LOS, I see two statues in the screenshot in the dump
02:44:32 <gammafunk> |amethyst: interesting, is it just some sort of general issue about corruption moving clouds?
02:44:50 <gammafunk> oh, it's moving the statue, not the cloud
02:45:14 <gammafunk> seems like corruption might need to just nuke any cloud where it moves a solid feature
02:45:54 <gammafunk> that's a good lead though, thanks. if you're not going to make a fix, I'll remember to take a look tomorrow when I have some time
02:46:03 <|amethyst> dungeon_terrain_changed already does that
02:46:12 <|amethyst> (set_terrain_changed actually)
02:48:36 <alexjurkiewicz> !killratio bai_suzhen_dragon
02:48:39 <Sequell> No battles for bai_suzhen_dragon.
02:49:05 <gammafunk> kills by the dragon show up as just bai suzhen in the logfile
02:49:21 <gammafunk> !lg * ckiller=bai_suzhen s=ckaux
02:49:22 <Sequell> 174 games for * (ckiller=bai_suzhen): 57x great wave of water, 33x torrent of water, 27x, 22x thunder, 10x tree, 9x rock wall, 4x some deep water, 2x quarterstaff, quarterstaff of draining, orange demon, oklob plant, ogre, neqoxec, metal wall, stone wall, earth elemental, closed door, quarterstaff of distortion
02:49:32 <gammafunk> note the the great wave of water
02:50:01 <gammafunk> also good deep elf mage force lancing
02:50:45 <|amethyst> gammafunk: hm, I'm not sure what in the corruption would be placing/moving a statue
02:50:50 <|amethyst> s/tion/tion code/
02:51:05 <|amethyst> I don't have time to look at it any more right now, so have fun with that tomorrow :)
02:51:12 <gammafunk> will do
02:52:40 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.21-a0-154-gb5400c9
02:53:24 <gammafunk> !lg * ckaux=asterion
02:53:25 <Sequell> No games for * (ckaux=asterion).
02:53:41 <gammafunk> !lg * ckaux=neqoxec
02:53:42 <Sequell> 79. manman the Executioner (L15 MiFi of Makhleb), collided with a neqoxec caused by Bai Suzhen on Spider:2 on 2016-12-09 10:35:40, with 82757 points after 17937 turns and 0:26:58.
02:53:49 <gammafunk> !lg * ckaux=neqoxec -2
02:53:50 <Sequell> 78/79. Fortnight the Cudgeler (L6 MuCK of Xom), rotted away (a neqoxec) on Abyss:1 on 2016-03-07 08:51:18, with 422 points after 6208 turns and 0:07:01.
02:53:54 <gammafunk> heh
02:53:57 <gammafunk> !lg * ckaux=neqoxec -3
02:53:58 <Sequell> 77/79. Peloso the Peltast (L15 MiFi of Okawaru), forgot to breathe caused by a neqoxec on Orc:4 (pubby_orc_utopia) on 2015-08-29 13:00:30, with 96217 points after 26053 turns and 2:36:34.
03:11:34 <Rotatell> Unstable branch on crawl.beRotato.org updated to: 0.21-a0-154-gb5400c9 (34)
03:42:54 -!- amalloy is now known as amalloy_
05:38:14 <Yermak> Vehumet enhances wands' range too. Is this planned?
05:38:28 <Cheibriados> 03gammafunk02 07* 0.21-a0-155-gb8a8bae: Tweak the layout of a abyssal rune vault 10(9 minutes ago, 1 file, 8+ 10-) 13https://github.com/crawl/crawl/commit/b8a8bae6105f
05:40:13 <gammafunk> Yermak: uh, probably not
05:40:41 <Yermak> So nobody cared about it since range of wands was changed?
05:41:17 <gammafunk> Not sure what you mean by nobody cared about it, you mean no one realized it?
05:41:23 <Yermak> yeah
05:41:25 <gammafunk> that is certainly possible
05:41:34 <Yermak> I personally don't play Veh that often
05:41:39 <gammafunk> since Veh worshipers tend to just rely on spells
05:42:03 <Yermak> It might be possible that wand damage is also enhanced
05:42:21 <gammafunk> you mean by e.g. archmagi?
05:42:31 <gammafunk> veh shouldn't enhance spellpower
05:42:42 <gammafunk> but I suppose it may be possible that spell enchancers would work like that, yeah
05:42:59 <gammafunk> hrm
05:43:05 <gammafunk> I doubt it actually
05:43:29 <gammafunk> I think that calculation really passes evocations-base skill and it's unlikely anything else would affect it
05:44:11 <gammafunk> yeah I see the range enchancement under veh
05:49:51 <Yermak> Should I file bug report or you're fixing it right now?
05:50:00 <gammafunk> please do that, thanks Yermak
05:50:24 <gammafunk> I won't be able to fix until tomorrow, but it should be simple enough to fix
05:54:11 <Cheibriados> Vehumet enhances range of wands 13https://crawl.develz.org/mantis/view.php?id=11168 by Yermak
05:54:41 <gammafunk> good catch, I think the fat that the wand ranges are new in 0.20 is also part of why it wasn't caught
05:55:16 <gammafunk> in that people don't quite remember which has what range now
06:10:14 <Jorgrell> Unstable branch on crawl.jorgrun.rocks updated to: 0.21-a0-155-gb8a8bae (34)
06:25:25 <advil> haha very nice catch Yermak
07:08:17 <gammafunk> we should make ijyb a veh worshiper and give her that passive :3
07:08:18 <johnny0> vehumet used to enhance rod range as well
07:08:42 <gammafunk> yeah, probably the exact same bug in the code path
07:09:10 -!- Reverie is now known as Catiua
07:09:14 <gammafunk> since it's a call from your_spells() to the spell range function, with the former having a way to identify the source of the spell (in terms of the tiem)
07:09:17 <gammafunk> *item
07:09:28 <gammafunk> but the latter not having any such argument
08:13:00 <Yermak> I just started a game using autoexplore. And oh my god, this newly imported bug #11159 is *really* annoying!
08:17:47 <johnny0> %bug 11159
08:17:47 <Cheibriados> 13https://crawl.develz.org/mantis/view.php?id=11159
11:35:40 <|amethyst> so what should it do if you say "don't ignore this item"?
13:04:47 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.21-a0-155-gb8a8bae (34)
13:20:22 -!- amalloy_ is now known as amalloy
16:25:18 <advil> maybe I'm misreading but isn't that the expected behavior?
16:25:24 <advil> re 11159
16:25:49 <advil> if you don't ignore it, then you can't autoexplore, because autoexplore expects you to do something about the item
16:27:45 <amalloy> players expect "dropping something to make space for the thing on the ground" to count as doing something
16:27:50 <amalloy> after which o should pick it up
16:27:56 <advil> oh I see
16:28:59 <advil> huh
16:29:06 <advil> I guess I always just manually pick things up in that circumstance
16:36:51 <advil> oh I see what I do, for whatever reason my habit is to use ;
16:36:59 <advil> which does autopickup on the current square
16:37:07 <advil> but yeah, o is odd in that case
16:37:21 <advil> (it's also not consistent, I think I just saw it pick up something?)
16:38:09 <advil> ah it works if you don't say not to ignore it and just preemptively drop something
16:47:53 <advil> I'm also getting autoexplore halting on some transporters?
16:48:14 -!- Menche_ is now known as Menche
16:49:48 <advil> without a message, specifically
16:50:47 <advil> though this level's a bit full of transporters because I was testing something on it
16:51:21 <gammafunk> what do you mean by halting on, that it's stopping when moving over the transporter?
16:51:43 <advil> yeah...then I move past and it will continue. if I stay on the spot, o does nothing
16:51:52 <gammafunk> ah, that does sound like a bug
16:51:56 <advil> it was only 1 specific one
16:52:14 <advil> (I seriously have like 30 transporters on this level so it may be abnormal circumstances)
16:52:19 <gammafunk> yeah
16:52:34 <gammafunk> but the general bug is probably caused by my transporter travel change
16:52:45 <advil> ah
16:52:46 <gammafunk> the bug wrt autoexplore item pickup
16:52:57 <gammafunk> I'm not sure why, it's just the most recent change to travel code
16:52:58 <advil> ohhh
16:53:01 <gammafunk> you could try to bisect from there
16:53:06 <advil> is this bug new?
16:53:11 <gammafunk> apparently?
16:54:36 <advil> ok yeah it is indeed new-ish
16:55:08 <advil> for some reason I hadn't realize that, thought it was old behavior
17:07:59 <advil> !source _get_non_walking_command
17:08:00 <Sequell> 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/travel.cc#L834
17:08:12 <advil> looks like a bunch of these cases will apply during autoexplore, and probably shouldn't?
17:08:34 <advil> the second one is definitely the odd stop on a transporter that I saw
17:09:13 <advil> haven't yet figured out how any of this would lead to 11159 though
17:11:47 <gammafunk> advil: well, travel_mode should be false under auto explore
17:12:39 <gammafunk> but yeah I can see how that !(travel_mode && [transporter]) one could be a problem
17:13:33 <gammafunk> I think autoexplore wouldn't call this function typically though
17:13:54 <gammafunk> or at least I'm not sure under which conditions it would, I'd have to remember the code
17:14:30 <gammafunk> since I think this function is only called under pretty specific conditions related to travel
17:16:41 <advil> that would explain why it only rarely happened on a level with a lot of transporters
17:22:24 <advil> I think if autoexplore has set the square as an intermediate target, that functino will be called?
17:24:28 <advil> ah, which may happen if you say n to that prompt
17:35:16 <advil> gammafunk: "if (last_stair == curr)" should maybe only happen for interlevel travel based on the code that function replaces?  The set of conditions that if is replacing also checks last_stair != -1, maybe that's taken care of though
17:35:39 <advil> that condition is definitely the one that is triggering 11159, I'm really not sure why but output debugging says it is so
17:40:24 <advil> I'm hesitant to try to fix myself though because I mostly have no idea how travel works :)
17:53:01 <gammafunk> advil: last_stair was turned from a level thingy to a level_pos
17:53:53 <advil> ah handling the -1 case?
17:54:19 <gammafunk> well, level_pos is a level (which I think is branch id + depth) and a coord_def
17:54:28 <gammafunk> so checking it being equal to -1 doesn't make sense
17:54:38 <gammafunk> whereas I think it did when it was just a level
17:55:08 <gammafunk> but yes, it checks that the level_pos is a valid one (which involves checking both the level and the position)
17:55:27 <gammafunk> advil: you've probably given me enough of a lead so that I can fix that bug
17:55:59 <gammafunk> probably autoexplore is doing some kind of weird fallback travel under the conditions of the bug
17:56:07 <advil> last_stair == curr when autoexploring, that I know
17:56:21 <gammafunk> yeah, but last_stair should be totally irrelevant
17:56:32 <gammafunk> last_stair is used to track the last stair that travel took
17:56:48 <gammafunk> autoexplore never takes stairs, so that variable should not come into play in autoexplore
17:57:02 <gammafunk> the reason it exists is so that if travel tries to take a stair and fails
17:57:12 <gammafunk> it doesn't sit there constantly trying to retake the same stairs
17:57:27 <gammafunk> so it tracks the last stair it attempted to take
17:57:27 <advil> well, autoexplore definitely calls _get_non_walking_command all the time, not sure if that's what's supposed to happen all the time
17:57:27 <advil> er
17:57:46 <advil> just "supposed to happen"
17:58:03 <gammafunk> yeah, it may be that it's calling this function when it shouldn't, or it may be that the function needs to be expanded to handle autoexplore cases
17:58:24 <gammafunk> but thanks, I can take a look at that one
17:58:27 <advil> in the old code the last_stair == curr equivalent check is in the scope of  if (runmode == RMODE_INTERLEVEL...
17:58:32 <advil> ok
17:58:57 <gammafunk> yeah RMODE_INTERLEVEL is interlevel travel
17:59:21 <gammafunk> so not something used by autoexplore (unless autoexplore is doing somethign weird that I didn't realize)
17:59:36 <advil> right, but that check isn't there any more :)
17:59:51 <advil> that I can find
17:59:54 <gammafunk> well, there are other checks
18:00:11 <|amethyst> the call to _get_non_walking_command is inside this if (!*move_x && !*move_y)
18:00:45 <|amethyst> previously there was a check for runmode == RMODE_EXPLORE || runmode == RMODE_EXPLORE_GREEDY
18:02:03 <gammafunk> yeah, I just need to see what happens when explore modes don't have a move
18:02:11 <gammafunk> what did they do?
18:02:24 <gammafunk> maybe it was simply return CMD_NO_CMD
18:03:03 <|amethyst> looks like it just reset you.running and did nothing else
18:03:25 <Lantell> Unstable branch on underhound.eu updated to: 0.21-a0-155-gb8a8bae (34)
18:03:49 <|amethyst> hm
18:04:02 <gammafunk> well, what command was returned?
18:04:07 <gammafunk> I presume CMD_NO_CMD
18:04:12 <|amethyst> yeah, I think
18:04:21 <advil> it might be the stop_running that's the issue, not the return; stop_running wouldn't have been called in that case
18:04:23 <|amethyst> which seems like what would happen now, unless last_stair == curr
18:05:09 <|amethyst> you might also check what happens when this (stopping because the pack is full) occurs on a stair
18:05:09 <gammafunk> yeah, I think that call to _get_non_walking_command() basically shouldn't be happening
18:05:19 <|amethyst> I suspect it might actually take the stair in explore mode
18:05:52 <gammafunk> so all those checks for last_stair in autoexplore shouldn't be occurring
18:06:13 <gammafunk> it's probably jsut seeing no move command and not properly checking the runmode before proceeding to follow that logic
18:06:22 <gammafunk> autoexplore shouldn't be trying to things related to stairs
18:06:58 <gammafunk> I can look in further detail a bit later
18:57:58 -!- amalloy is now known as amalloy_
20:49:08 <Cheibriados> Spell memorisation screen prioritises "not enough spell levels" over "divinely forbidden" 13https://crawl.develz.org/mantis/view.php?id=11169 by damerell
23:59:12 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-155-gb8a8bae (34)