00:07:27 -!- amalloy_ is now known as amalloy
01:00:02 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.23-a0-389-g4a5eb33 (34)
02:27:21 <Gretell> Unstable branch on crawl.develz.org updated to: 0.23-a0-389-g4a5eb33 (34)
02:58:31 <Gretell> Windows builds of master branch on crawl.develz.org updated to: 0.23-a0-389-g4a5eb33
03:11:46 <Rotatell> Unstable branch on crawl.beRotato.org updated to: 0.23-a0-389-g4a5eb33 (34)
03:58:54 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.23-a0-389-g4a5eb33
04:26:45 -!- amalloy is now known as amalloy_
05:54:04 -!- Euph0ria is now known as CyberBurn
05:55:51 -!- CyberBurn is now known as WalterWhite
05:57:02 -!- WalterWhite is now known as FutureShock
08:28:02 -!- amalloy_ is now known as amalloy
13:05:22 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.23-a0-389-g4a5eb33 (34)
14:17:46 <Cheibriados> Setting a confirm_action for an ability generates a Y/N prompt every time the ability menu is opened 13https://crawl.develz.org/mantis/view.php?id=11738 by hexaflexagon
14:28:21 <Cheibriados> +10 Longsword generated as dancing weapon 13https://crawl.develz.org/mantis/view.php?id=11739 by Malacante
14:38:13 <amalloy> that's weird. it's coloured like an artefact, so +10 would be allowed, but shouldn't an artefact have a name and at least one artprop?
14:39:53 <switch__> it's really weird
14:40:01 <switch__> i wish he included more info
14:40:25 <switch__> is it possible for artefacts to roll in such a way that they don't have any properties?
14:40:36 <switch__> it's bound to happen at some point, if it's possible
14:53:39 <amalloy> !source determine_nice_weapon_plusses
14:53:40 <Sequell> 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/makeitem.cc#L376
14:53:45 <amalloy> seems to top out at +8 for non-artefacts
15:25:33 <amalloy> so, it looks to me like items() can decide, hey, this thing should be an artefact, give it a plus of up to +12, and then try to assign it artprops. if for some reason assigning artefact props fails, you could wind up with a +10 non-artefact item. but i don't see how assigning props could fail
16:03:54 <minmay> amalloy: if it's ISPEC_GIFT and unbranded it gets an extra 2+random2(3) enchantment on top of that, so unbranded weapons can get up to +12, not artefact prop failure needed
16:04:56 <minmay> ISPEC_GIFT or ISPEC_GOOD_ITEM i guess (why's that above ISPEC_GIFT???)
16:05:32 <amalloy> yeah, i found that and reproduced by fudging the random numbers to create a +12 non-artefact longsword
16:05:55 <amalloy> i was misled by the coloring; i thought it'd be green if it were a non-artefact, but that screen apparently doesn't apply item colouring
16:06:23 <amalloy> there are a couple vaults that place "dancing weapon ; long sword good_item"
16:06:30 <amalloy> this one was probably sword in the stone
16:06:36 <minmay> yeah
16:06:44 <minmay> it also happens with monster equipment a lot
16:07:01 <minmay> unfortunately I don't think ijyb can get a +12 club anymore
16:07:44 <minmay> also TIL donald has a 5% chance of getting crystal plate
16:09:51 <amalloy> so, imo the plus on randomly placed non-artefact items shouldn't be higher than what you could create with ?ew. i could just add a post-creation check that clamps it to at most +9, but does someone have a better idea?
16:13:12 <minmay> I think that bonus enchantment clause is pretty weird in the first place
16:14:45 <amalloy> fair. perhaps move it to after determine_nice_weapon_plusses has assigned a plus, and if the "good" item has no ego then ensure its plus is at least 3, or something?
16:19:44 <minmay> now you just have me thinking about how weird the distribution of determine_nice_weapon_plusses is
16:20:22 <switch__> could use some work
16:20:39 <amalloy> it is a certified Crawl Random Number Distribution: a distribution chosen randomly and arbitrarily
16:20:55 <minmay> it's about 18% +0, 23% +1, 28% +2, 12% +3, 10% +4, 5% +5, 2.5% +6, 0.8% +7, 0.2% +8
16:22:58 <minmay> the falloff from even -> odd is significantly bigger than the falloff from odd -> even (as you can probably tell just by looking at the formula, without seeing the percentages)
16:23:42 <minmay> er, those percentages are for ISPEC_GIFT/GOOD_ITEM of course, but the issue is obviously present for other item qualities as well
16:28:55 <amalloy> oh, i didn't notice the player helpfully pointed out that the item was from erik_vaults_1, which would have made it easier to realise the connection to good_item
17:10:11 <TAS_2012v> Score 152 on this page - http://crawl.akrasiac.org/scoring/top-combo-scores.html - is some kind of bug. It ould be interesting if it actually as some kind of feak DGBe (sic), but it's actually a SpBe from some 0.5-svn version: http://crawl.develz.org/morgues/git/rob/morgue-rob-20081005-182858.txt
17:10:44 <TAS_2012v> W-key not working properly...
17:11:19 <TAS_2012v> hole keyboad is beaking down, need a vacuum cleaner..
17:50:34 <Rotatell> giantbat (L25 VSWn) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 1904 failed. (Vaults:5)
18:13:37 <amalloy> !crashlog
18:13:51 <Sequell> 20360. giantbat, XL25 VSWn, T:62351 (milestone): http://crawl.berotato.org/crawl/morgue/giantbat/crash-giantbat-20181029-215024.txt
18:19:32 <gammafunk> amalloy: I have a bug for you to take a look at
18:19:39 <amalloy> orly
18:19:47 <gammafunk> it's a curious case of the monster with no valid monster type or mid
18:19:49 <gammafunk> one sec
18:21:00 <gammafunk> amalloy: A couple crashes in the los attack spell code in spl-damage.cc have happened, here's a local one with a gdb stack trace: http://dpaste.com/3T1Y8NK
18:21:29 <gammafunk> somehow when a monster is getting trained of life in the right circumstances, it seems to pass the alive test but have invalid monster data
18:24:47 <amalloy> gammafunk: i expect it's the same problem as these things often are: we calculate up front a list of monsters to affect, say X and Y. then, affecting X causes Y to die, but we move on to attack it anyway
18:25:06 <gammafunk> hrm
18:25:07 <amalloy> drain life follows the same pattern. i don't see any summoners dying in the log message, which is the most common cause
18:25:21 <gammafunk> well wouldn't the m->alive() test handle this?
18:25:39 <gammafunk> what you describe is sort of what I generally expected, but
18:26:11 <gammafunk> right before _los_spell_damage_monster() is an alive check
18:26:21 <amalloy> i see
18:27:08 <gammafunk> maybe I should try to trigger the crash in that specific way
18:27:16 <gammafunk> I just drained life a bunch of times until it crashed
18:27:34 <gammafunk> get a monster to summon, set summon hp to 1
18:29:05 <gammafunk> bingo
18:29:12 <gammafunk> boggart to 1hp with a summon up
18:29:26 <gammafunk> crashed upon drain life
18:29:44 <gammafunk> well, no idea why that gives a crash, but thanks for the lead
18:30:53 <amalloy> is a monster pointer still valid after monster_die has been called for it?
18:31:37 <amalloy> i think it's not, since monster_die ends with monster_cleanup, which calls mons->reset
18:32:44 <gammafunk> right, so is it the wrong check in that loop?
18:32:51 <amalloy> i'm not sure. monster death is weird
18:33:04 <gammafunk> if the monster pointer is invalid, I assume monster::alive() would return false
18:33:14 <gammafunk> well after the reset it would, I guess
18:34:20 <gammafunk> hrm
18:34:23 <gammafunk> really weird
18:34:27 <gammafunk> monster::alive() is
18:34:29 <amalloy> it would return false, yeah
18:34:32 <gammafunk> return hit_points > 0 && type != MONS_NO_MONSTER;
18:34:44 <amalloy> but we might not have a valid monster pointer at all?
18:34:51 <gammafunk> and it being the NO_MONSTER value is precisely why it crashes
18:34:56 <gammafunk> must be I guess
18:35:08 <gammafunk> the pointer was non-null at least
18:36:57 <gammafunk> comment above that aliveness test even remarks about watching out for invalidation :(
18:39:06 <amalloy> yeah, i'll see if stepping through with gdb reveals more clearly what's going on
18:45:34 <amalloy> gammafunk: i think it's not invalidation: killing the boggart crashes while the boggart is dying, before touching its summon
18:45:48 <gammafunk> oh, hrm
18:45:55 <gammafunk> ah
18:45:57 <gammafunk> it makes sense
18:46:04 <gammafunk> hrm
18:46:05 <gammafunk> actually
18:46:18 <gammafunk> the mon->hurt() happens after the set_attack_conduct() though
18:46:26 <gammafunk> so how would that happen
18:47:51 <gammafunk> mons_adjust_flavored shouldn't kill it
18:49:56 <gammafunk> although technically that function could for a different kind of effect
18:52:30 <amalloy> by the time set_attack_conducts is called, the monster is already dead. not sure why that is
18:56:43 <amalloy> ah
18:57:06 <amalloy> mons_adjust_flavoured does indeed kill it, by applying the hp loss for draining
18:57:25 <amalloy> in monster::drain_exp
18:58:32 <amalloy> yeah, nothing to do with summons. same thing happens to a 1hp goblin
19:11:09 <gammafunk> amalloy: ok, I should have looked into that more carefully, thanks
19:11:21 <gammafunk> I had read that and thought that the monster couldn't get killed
19:11:39 <gammafunk> but since it's a non-const parameter to that function I should have just assumed regardless
19:11:56 <gammafunk> this just didn't come up before since there was no god conduct code to look into the monster data
19:12:45 <gammafunk> hrm
19:12:53 <gammafunk> this may be a bug too in how I refactored this
19:13:03 <gammafunk> I think drain life is incorrectly applying these drain effects in the first place
19:19:35 <amalloy> you mean it shouldn't apply them at all, or what
19:21:46 <Lantell> Unstable branch on underhound.eu updated to: 0.23-a0-389-g4a5eb334b0 (34)
19:23:33 <gammafunk> amalloy: yeah, drain life shouldn't apply drain effects I believe
19:23:49 <gammafunk> I may have broken this
19:23:50 <gammafunk> let me go see
19:25:21 <amalloy> it used to use resist_adjust_damage instead
19:25:33 <CanOfWorms> yeah isn't drain life just supposed to be an LOS vampiric draining
19:25:48 <CanOfWorms> the yred version at least
19:26:50 <amalloy> it's sorta mysterious why ozo's used mons_adjust_flavoured while drain life used resist_adjust_damage, but i guess the point was to let ozo's slow via cold damage while drain life doesn't drain via draining (ie the problem we are seeing now)
19:26:55 <gammafunk> yep
19:27:04 <gammafunk> so I generalized it without conditioning that parameter
19:27:13 <gammafunk> there's a parameter to prevent the effects and I just didn't check it
19:27:29 <gammafunk> right
19:28:07 <gammafunk> well, thanks for your help, should be easy to fix this, just have to do a few small changes
21:10:16 <switch__> %git
21:10:16 <Cheibriados> 07Skrybe02 {ebering} * 0.23-a0-389-g4a5eb33: Address a TODO in layout_concentric_octagons 10(28 hours ago, 1 file, 5+ 6-) 13https://github.com/crawl/crawl/commit/4a5eb334b0ed
21:10:38 <Cheibriados> New branch created: pull/882 (1 commit) 13https://github.com/crawl/crawl/pull/882
21:10:38 <Cheibriados> 03stenella02 07https://github.com/crawl/crawl/pull/882 * 0.23-a0-390-g64eb0c1: Leave Dual-Wielders Alone 10(3 minutes ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/64eb0c1cb1d9
21:12:36 <Cheibriados> 03gammafunk02 07* 0.23-a0-390-g27fa94f: Fix a crash for LOS attack spells (MeekVeins, amalloy) 10(27 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/27fa94fbb5aa
21:12:36 <Cheibriados> 03gammafunk02 07* 0.23-a0-391-g8c51ad5: Don't apply negative energy effects to monsters for Drain Life 10(6 minutes ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/8c51ad5a296e
21:13:23 <switch__> gammafunk, can pull that bugfix whenever you want, shouldn't do anything but fix the bug
21:13:30 <switch__> i wasn't entirely sure how to properly format the change, though
21:18:05 <switch__> having so many logical operators next to eachother is kinda bound to be ugly, though
21:24:04 <|amethyst> switch__:  I like having the outer operator (|| here) all aligned, and if they're not too long (or too short), the inner expressions one-per-line
21:24:13 <|amethyst> switch__:  so
21:24:16 <|amethyst> return (mon.inv[MSLOT_WEAPON] && have_weapon_offs)
21:24:23 <|amethyst> || (mon.inv[MSLOT_SHIELD] && have_shield_offs);
21:24:50 <|amethyst> oh
21:25:07 <switch__> yeah
21:25:15 <|amethyst> I was misreading that
21:25:35 <switch__> feels parenthesis man
21:26:40 <|amethyst> I would line up the || and the && either with their respective surrounding parentheses, or one step deeper
21:27:23 <|amethyst> part of the reason I was confused by your code was the last && being indented deeper than the last ||, even though the || is nested deeper
21:27:42 <switch__> hmm
21:27:48 <switch__> it might be better to swap the two things
21:29:29 <|amethyst> yeah, then you can have
21:29:32 <|amethyst> return (mon.inv[MSLOT_WEAPON] && have_weapon_offs)
21:29:32 <|amethyst> || (mon.inv[MSLOT_SHIELD] && have_shield_offs);
21:29:32 <|amethyst> || ((mon.inv[MSLOT_SHIELD]
21:29:32 <|amethyst> || (mon.inv[MSLOT_ALT_WEAPON]
21:29:32 <|amethyst> && mons_class_wields_two_weapons(mon.type)))
21:29:34 <|amethyst> && have_shield_offs);
21:29:42 <|amethyst> where the indentation shows the nesting
21:29:53 <|amethyst> hm
21:30:00 <switch__> you uhh
21:30:02 <switch__> have some extra lines there
21:30:24 <|amethyst> oh, right, remove the second line
21:30:42 <switch__> return (have_weapon_offs && mon.inv[MSLOT_WEAPON])
21:30:42 <switch__> || (have_shield_offs && (mon.inv[MSLOT_SHIELD]
21:30:42 <switch__> || ((mon.inv[MSLOT_ALT_WEAPON]
21:30:42 <switch__> && mons_class_wields_two_weapons(mon.type)));
21:31:02 <switch__> uhh
21:31:11 <switch__> the first two have an extra indent
21:31:29 <switch__> https://i.imgur.com/K4eoKHh.png
21:35:10 <switch__> nevermind
21:35:11 <switch__> i like yours
21:39:12 <Cheibriados> 03stenella02 07https://github.com/crawl/crawl/pull/882 * 0.23-a0-391-g45d8439: Formatting 10(4 minutes ago, 1 file, 5+ 4-) 13https://github.com/crawl/crawl/commit/45d8439ec46e
21:40:09 <|amethyst> yeah, IMO the one at imgur is confusing because the third line looks like || attaches to have_shield_offs but it's really nested one deeper
21:41:04 <switch__> agree
21:42:07 <|amethyst> switch__:  you have tabs
21:42:14 <switch__> fuck
21:42:16 <|amethyst> switch__:  run checkwhite :)
21:42:32 <|amethyst> actually I think checkwhite -t 4 or something like that
21:45:00 <switch__> done
21:45:47 <switch__> ah, nope
21:45:50 <switch__> now it's one tab too far forward
21:46:37 <switch__> *now* we're done
21:46:43 <switch__> gonna change notepad++'s settings to use spaces
21:49:47 <Cheibriados> 03stenella02 07https://github.com/crawl/crawl/pull/882 * 0.23-a0-390-g3ba7293: Leave Dual-Wielders Alone 10(42 minutes ago, 1 file, 4+ 1-) 13https://github.com/crawl/crawl/commit/3ba7293b15c4
22:11:00 <Jorgrell> Unstable branch on crawl.jorgrun.rocks updated to: 0.23-a0-391-g8c51ad5a29 (34)
23:03:07 <minmay> two people today have asked me why there's a section in elf they can't get to, because deep elf elementalists are creating islands by turning rock walls into earth elementals
23:04:18 <minmay> can the spell get a check to make sure the rock wall getting destroyed has a traversible space next to it?