00:13:14 -!- GiantOwl is now known as Kalir
02:46:40 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.21-a0-265-gb353147
08:38:26 <Cheibriados> New branch created: pull/611 (1 commit) 13https://github.com/crawl/crawl/pull/611
08:38:26 <Cheibriados> 03Velros02 {GitHub} 07https://github.com/crawl/crawl/pull/611 * 0.21-a0-266-gc99fb2e: Ghoul HP regeneration near submerged enemies 10(3 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/c99fb2eb8ac2
09:04:23 <advil> |amethyst: re live monster spawning, it really shouldn't -- that block of code is just a conditional assert iirc
09:04:32 <advil> I can have a look tonight
09:08:03 <advil> my instinct says to check first:
09:08:19 <advil> %git bb444f2580aad7b80183c7c805619d6a1479c879
09:08:19 <Cheibriados> 07gammafunk02 * 0.21-a0-257-gbb444f2: Generate some monsters awake at level creation time on most levels 10(10 days ago, 1 file, 13+ 3-) 13https://github.com/crawl/crawl/commit/bb444f2580aa
09:08:41 <advil> which maybe someone's already done, I guess this bug has been a few days
11:48:24 <gammafunk> advil: look at that commit, I can't really see how that would affect zombie generation
11:48:54 <gammafunk> I suppose it could have come from some of the nospawn commits though
14:46:10 <Pinkbeast> Hello. I was wondering if perhaps Chei should never be pleased with a kill of a torpor snail
15:05:25 <shmup> @??torpor snail
15:05:25 <Gretell> torpor snail (03w) | Spd: 7 | HD: 10 | HP: 48-70 | AC/EV: 8/1 | Dam: 25 | amphibious | Res: 06magic(40), 12drown | XP: 423 | Sz: Large | Int: animal.
15:07:05 <shmup> @??gastr@??gastronok
15:07:06 <Gretell> unknown monster: "gastr@??gastronok"
15:07:08 <shmup> @??gastronok
15:07:08 <Gretell> Gastronok (06w) | Spd: 5 | HD: 20 | HP: 125-171 | AC/EV: 3/1 | Dam: 40 | 10items, 10doors, amphibious, spellcaster, see invisible | Res: 06magic(80), 12drown | Chunks: 14noxious | XP: 2231 | Sp: cantrip, airstrike (0-50), sum.small mammal, slow, sprint | Sz: Big | Int: human.
15:07:17 <shmup> torpors are too fast for chei to care maybe idk
15:07:44 <Pinkbeast> But they make things slow, surely Chei should approve of that.
15:10:00 <shmup> yeah
15:10:07 <shmup> it's a good enough idea that it can probably happen
15:15:01 <nikheizen> Probably won't happen as it's a special case, which is not looked well upon.
15:20:03 <shmup> is chei cool with killin all slow things?
15:21:55 <Pinkbeast> Chei never minds a kill, and I don't think they should mind you killing torpor snails - just not be pleased.
15:33:58 <MarvinPA_> why, though?
15:34:14 <gammafunk> yeah, it seems inconsistent to make a special case for that particular monster
15:34:25 <gammafunk> if chei cared about them specifically they'd been peaceful
15:34:50 <gammafunk> s/been/be/
15:35:07 <gammafunk> chei just likes it when you kill things faster than yourself
15:35:26 <MarvinPA_> right, it would also literally never come up anyway
15:36:18 <gammafunk> slowed naga with -swift???
15:36:28 <gammafunk> I'm not even sure how that speed check works
15:36:29 <Pinkbeast> Not literally never, it just did
15:37:00 <Pinkbeast> And why; because they make Chei's worshipper slow, which Chei should approve of
15:37:18 <gammafunk> that doesn't make sense at all though
15:37:18 <MarvinPA_> slow status doesn't affect piety i thought
15:37:24 <MarvinPA_> and yes lots of other monsters make you slow
15:37:30 <gammafunk> literally every monster with the slow spell can make chei's worshiper slow
15:37:50 <Pinkbeast> Only one always does it, though (err actually I was a formicid at the time so...)
15:37:51 <gammafunk> also every wraith monster with af_slow
15:39:03 <gammafunk> It's just a weird special case; either torpor snails should be peaceful for chei worshipers or they should work consistently wrt chei's appreciation
15:39:38 <Pinkbeast> Well, fair enough. See some of you on ##crawl
15:40:12 -!- MarvinPA_ is now known as MarvinPA
16:24:12 -!- oleum_ is now known as oleum
16:24:20 -!- flgr_ is now known as flgr
16:25:25 <shmup> oh, yeah. i wasnt thinkin clearly
16:45:03 <Cheibriados> Can continue training crosstrained skill at 27 13https://crawl.develz.org/mantis/view.php?id=11219 by damerell
17:30:56 <Eksell> stickyfingers (L18 FoAr) ASSERT((int)Buffer.size() == expanded_keys_left) in 'macro.cc' at line 544 failed. (Spider:4)
17:53:08 <minmay> j
18:06:13 <ProzacElf> k
18:26:33 -!- amalloy_ is now known as amalloy
19:05:14 -!- amalloy is now known as amalloy_
19:21:40 -!- amalloy_ is now known as amalloy
19:36:22 -!- Amnesiac__ is now known as Amnesiac
20:04:43 -!- Webmant9 is now known as Webmant
20:12:22 -!- amalloy is now known as amalloy_
20:22:27 <Dracunos> :q!
20:32:02 -!- FunkyGnoll is now known as FunkyBomb
21:07:33 <geekosaur> ^Kd
21:13:21 <nikheizen> 
21:44:13 -!- amalloy_ is now known as amalloy
22:08:41 -!- amalloy is now known as amalloy_
22:12:50 -!- amalloy_ is now known as amalloy
22:27:44 <advil> does anyone understand this loop? https://github.com/crawl/crawl/blob/master/crawl-ref/source/mon-place.cc#L553
22:28:10 <advil> I don't get the point of running it 300 times without any breaks or continues
22:28:42 <shmup> eh
22:28:43 <shmup> heh
22:28:45 <gammafunk> oh
22:28:51 <gammafunk> that might be my fault
22:29:08 <gammafunk> !gitgrep 2 spawn
22:29:08 <Sequell> %git HEAD^{/spawn}^^{/spawn}
22:29:08 <Cheibriados> 07gammafunk02 * 0.21-a0-255-g5a3d65e: Increase numbers of level generation monsters in most branches 10(11 days ago, 2 files, 16+ 16-) 13https://github.com/crawl/crawl/commit/5a3d65ea255c
22:29:08 <advil> no, it hasn't been changed in years
22:29:20 <gammafunk> advil: I think that's wrong
22:29:23 <gammafunk> !gitgrep 3 spawn
22:29:24 <Sequell> %git HEAD^{/spawn}^^{/spawn}^^{/spawn}
22:29:24 <Cheibriados> 07gammafunk02 * 0.21-a0-254-g1d58f9a: Remove monster spawns over time in most branches 10(11 days ago, 1 file, 29+ 120-) 13https://github.com/crawl/crawl/commit/1d58f9a54f8a
22:29:40 <advil> I just checked the blame...I guess the loop may iteratively change mon_type
22:29:51 <advil> so maybe that's why it would need to run more than once?
22:29:59 <gammafunk> !gitgrep 1 stair
22:30:00 <Sequell> %git HEAD^{/stair}
22:30:00 <Cheibriados> 07gammafunk02 * 0.21-a0-256-gb9be33d: Add a monster placement proximity type for generating away from stairs 10(10 days ago, 2 files, 8+ 0-) 13https://github.com/crawl/crawl/commit/b9be33d25565
22:30:03 <gammafunk> !gitgrep 2 stair
22:30:04 <Sequell> %git HEAD^{/stair}^^{/stair}
22:30:04 <Cheibriados> 07gammafunk02 * 0.21-a0-253-g6b34986: Don't try to spawn monsters from stairs 10(11 days ago, 2 files, 9+ 243-) 13https://github.com/crawl/crawl/commit/6b349860cb1b
22:30:05 <advil> there are other loops a bit like that, so maybe you changed one of them?
22:30:16 <gammafunk> I changed that one, I think
22:30:20 <gammafunk> let me check
22:30:25 <johnstein> bummer. seems like my iPhone won't load the bookmark to the line in question and I don't see any line numbers
22:30:41 <gammafunk> advil: yes, in that command I just linked
22:30:49 <gammafunk> and yes
22:30:53 <gammafunk> I messed up the break
22:31:05 <gammafunk> that's likely causing that bug
22:31:24 <gammafunk> what I did was remove the entire check to break the loop
22:31:36 <gammafunk> I should have only removed the condition on PROX_NEAR_STAIRS, which was removed
22:32:24 <advil> hmm confused by the blame view https://github.com/crawl/crawl/blame/master/crawl-ref/source/mon-place.cc#L553
22:32:26 <johnstein> gammafunk: where does the color for disliked weapons get set? ie vamp weapons that zin would hate.  I fee like it has to be one of the load_item routines in invent.cc but I can't seem to find the call to a routine that would set the color based on the brand
22:32:35 <johnstein> or advil or whoever may know
22:32:54 <johnstein> I've spent a couple hours on it and I'm feeling really dumb
22:33:12 <gammafunk> yeah, not sure about that blame display
22:33:50 <gammafunk> but let me fix that loop
22:34:42 <advil> still not sure you actually touched that one :-)
22:34:53 <gammafunk> advil: read the diff
22:34:56 <advil> maybe the one in needs_resolution is what you have in mind?
22:35:27 <advil> yeah, looking for it
22:36:11 <gammafunk> yeah you're right, it is a different one, but
22:36:30 <gammafunk> wait
22:36:47 <gammafunk> uh
22:36:58 <advil> it does seem plausible that iteratively changing mon_type could cause a bug like this though
22:38:04 <advil> although there's an "if (proximity != PROX_NEAR_STAIRS" that looks promising
22:38:15 <gammafunk> advil: no, this is the same loop
22:38:15 <advil> oh nm
22:38:27 <gammafunk> the loop I changed is the one you linked to in the blame
22:38:52 <gammafunk> it's just been modified a good deal with my commit
22:39:04 <advil> in resolve_mosnter_type?
22:39:07 <advil> *monser
22:39:09 <advil> *monster
22:39:17 <gammafunk> yes, your blame is about a loop in that function
22:39:33 <gammafunk> my commit changed same loop in said function
22:39:37 <advil> oh I see
22:39:41 <advil> hm
22:39:53 <advil> I guess it is all deletes, so doesn't show up on blame?
22:39:58 <gammafunk> maybe so yeah
22:40:11 <gammafunk> so that aside, let's see what's going on here
22:42:09 <gammafunk> yeah there's no break
22:42:28 <gammafunk> it should be making a selection and then breaking always
22:42:46 <gammafunk> it looks like this loop may have only been necessary when PROX_NEAR_STAIRS existed
22:43:08 <gammafunk> if prox type was not near stairs, it always uncoditionally ended the loop
22:43:12 <advil> yeah
22:43:20 <gammafunk> so it was doing this loop only to give chances for prox near stairs
22:43:28 <advil> I think it was just to find non-zombies
22:44:02 <gammafunk> theoretically this should not be the cause of the zombie bug
22:44:23 <gammafunk> advil: yeah it was to find things able to actually use stairs only if prox type was near stairs
22:44:29 <gammafunk> now prox type near stairs no longer exists
22:44:30 <advil> I think it might be...since mons_type changes, on the second iteration it'll find a non-zombie?
22:45:03 <gammafunk> ah, I see
22:45:16 <gammafunk> it's running extra iterations, which ..somehow changes the result?
22:45:23 <gammafunk> I don't see why a non-zombie would be selected
22:45:30 <gammafunk> aha
22:45:32 <gammafunk> that's why
22:45:34 <gammafunk> mon type :)
22:45:38 <gammafunk> it gets fed back into the call
22:45:44 <gammafunk> so it was getting e.g. drac zombie
22:45:58 <gammafunk> or rather it was getting called with something like "zombie"
22:46:06 <gammafunk> returning drac zombie
22:46:14 <advil> yeah, can confirm -- the resulting mons_type corresponds to the living version
22:46:14 <gammafunk> then calling it again
22:46:23 <gammafunk> ok, so basically, delete that loop
22:46:29 <advil> looks like it
22:46:41 <gammafunk> if you want to make that commit, feel free
22:46:49 <advil> neat bug :-)
22:47:00 <gammafunk> yeah, it was my fault since I didn't read that loop carefully enough
22:47:28 <gammafunk> should have looked at the fact that I mean a loop like that have no end condition when it does a fixed number of tries =p
22:47:37 <gammafunk> just a badly designed loop I guess
22:47:38 <advil> well, you would think it would be harmless still
22:47:39 <gammafunk> which didn't help
22:47:58 <advil> but who knew that pick_random_monster will return a different mons_type than its input
22:48:05 <gammafunk> yeah, but I can definitely blame myself for leaving the loop in state in my commit
22:48:13 <gammafunk> *in that state
22:48:24 <advil> hm, do you know why it resets the place?
22:48:58 <advil> I think it's safe not to do that
22:49:03 <gammafunk> I think
22:49:07 <gammafunk> it may not be safe
22:49:13 <gammafunk> !source pick_random_monster
22:49:14 <Sequell> 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/mon-place.cc#L375
22:49:40 <advil> it will only do it for the case where the loop terminates, is why I was thinking that
22:49:59 <gammafunk> yeah, it may be safe now
22:50:07 <gammafunk> but place pointer was passed before when it was an actual loop
22:50:20 <advil> ah maybe that's also changed iteratively
22:50:46 <gammafunk> advil: yeah final place can change because because depth fuzzing
22:50:53 <advil> aha
22:50:54 <gammafunk> which could still happen with a single call
22:51:00 <advil> that's why I was seeing all those fuzz messages too
22:51:03 <advil> was wondering about that
22:51:11 <advil> it seemed to do it a lot on levelgen
22:51:20 <gammafunk> yep, still happens for normal level monsters
22:51:29 <advil> but the loop would explain more fuzzing than I was expecting
22:55:49 <advil> hm did I make it generate no undead now?
22:58:10 <gammafunk> some would say you've improved crawl...
22:59:58 <advil> maybe I just got unlucky in my testing
23:12:59 <advil> ok, I think I now finally see exactly what happened.  "pick_random_monster" will pick a random zombifiable monster type when given MONS_ZOMBIE and co (I guess it's used elsewhere for that), so the second call overwrites MONS_ZOMBIE with some locally possible zombie type
23:16:05 <advil> it's actually even stranger: call #3 would then ignore its mon_type input, and pick a local monster, which won't do anything living but could be MONS_ZOMBIE again
23:16:15 <advil> so it's only because the loop was even length that the bug showed up
23:19:26 <advil> imo pick_random_monster shouldn't do that, it's not really consistent with the other ways that parameter is used
23:20:03 <advil> not obvious to me whether it's even used, though it could be indirectly
23:20:33 <gammafunk> weird
23:20:52 <gammafunk> so is hell using "random zombifiable monster"?
23:21:16 <gammafunk> instead of "locally possible zombie" which I guess is no zombie in hell?
23:21:19 <gammafunk> when I say hell I mean hell subbranches
23:21:29 <gammafunk> some of those like tar have no living monsters I think
23:21:32 <gammafunk> well maybe each of them do
23:21:42 <advil> tartarus has MONS_ZOMBIE in the monster list, and then at some point that function gets called, still trying to understand where
23:21:57 <advil> but at the first call, it just converts RANDOM_MONSTER into MONS_ZOMBIE
23:23:11 <advil> yeah, _place_monster_aux calls the pick_local_zombifiable thing directly
23:23:23 <gammafunk> cool, thanks for tacking that down
23:23:37 <gammafunk> I'm glad my terrible modification of that loop was good for revealing something, at least
23:23:42 <advil> heh
23:24:22 <advil> yeah, this behavior is kind of bad and the loop wouldn't have caused a bug if it didn't exist
23:24:38 <advil> really these fns should be able to be guarded by needs_resolution
23:25:41 <gammafunk> so much of the mons-place code was a pretty ancient mess
23:26:00 <gammafunk> it took me a long time to understand parts of it