00:00:14 <11Odds> Actually having started this I decided I prefer "include temp", because it gets negated a lot less. There are some instances of it just called "temp", and those are the ones which mostly confused me... I think we should actually expand that name and flip the ignore ones 00:04:47 <04dracoomega> Negated a lot less? (I mean, I assume either way it will have a default argument, so it will only be specified at all if we want non-standard behavior, right?) 00:15:00 <11Odds> I mean in the body... usually we are testing a condition only if we are including temp, so if you have igmore_temp you write if (you.duration[DUR_FINESSE] && !ignore_temp) 00:17:14 <04dracoomega> Oh, right, fair 01:35:47 03CrawlOdds02 07* 0.35-a0-532-gd3d9948555: Rename boolean temp parameters to include_temp 10(41 minutes ago, 11 files, 266+ 262-) 13https://github.com/crawl/crawl/commit/d3d9948555c6 01:35:47 03CrawlOdds02 07* 0.35-a0-533-g0ebad8decd: Flip ignore_temp flags to include_temp 10(40 minutes ago, 12 files, 55+ 55-) 13https://github.com/crawl/crawl/commit/0ebad8decdbf 01:44:18 03hellmonk02 {CrawlOdds} 07* 0.35-a0-534-g99c0180e40: Improve sticky flame messaging. 10(7 months ago, 2 files, 14+ 3-) 13https://github.com/crawl/crawl/commit/99c0180e4012 01:49:24 <06regret-⸸nde※> While the "burns terribly" part is good, is it... really an improvement to have constant additional resist messages? It's inconsistent with monsters resisting clouds, which would be quite awful to constantly display in the message log. 01:51:02 <11Odds> Hmmm... I was thinking that was consistent with most places we apply elemental damage. But maybe not.... what are other good damage over time examples to compare to? Clouds, I guess? Rimeblight? 01:51:30 <11Odds> Oh sorry you said coulds and I can't read 01:52:39 <11Odds> I do think telling the player that the monster has resisted their spell is nice, though 01:52:42 <04dracoomega> Yeah, this is one of those situations where it's like... possibly more consistent, but also very spammy (which is part of why I'd sort of let the PR sit there up to now) 01:53:30 <06regret-⸸nde※> Maybe if it could be fit on the same line?.... 01:53:54 <11Odds> It does actually display on the same line 01:53:55 <11Odds> https://cdn.discordapp.com/attachments/747522859361894521/1516727575563468922/image.png?ex=6a33b221&is=6a3260a1&hm=d76cc61a4b0b53b86a812703f0bcd7ed2f85a165cbcadbd5c2f834224469b046& 01:54:16 <11Odds> We coud show it on the initial application, though damage isn't actually being done at that point 01:55:41 <11Odds> (Probably this set of messages should have a newline after it, which it didn't before or after this) 01:56:31 <04dracoomega> I do tend to think that it might be better to print the resist message a single time on application. (Though the punctuation alone for resists on the repeated message seems fine to me) 01:57:53 <11Odds> I think I'll move the resist message to application then. I quite like the explicit feedback here, for me at least it's a clear way to tell me about resistances I'd forgotten about (likely, if I see this message it's because I didn't know the monster has rF!) 02:00:49 <11Odds> Oh wait there's already a resist message on the "hits", supressed in the screenshot above because we didn't get through the AC. So yeah let's just remove this bit. 02:04:33 <11Odds> I think I still like the player messages though, which are consistent with clouds and obviously much, much rarer. 02:06:10 <04dracoomega> You mean repeatedly printing whether you're resisting it? 02:06:19 <11Odds> Yeah 02:06:20 <04dracoomega> While on fire 02:06:28 <04dracoomega> I mean, that is certainly higher-priority information 02:06:29 <11Odds> Yeah, while on fire I want all the information I can get 🙂 02:07:17 <04dracoomega> (Mostly this sort of thing is a matter of signal/noise, and I think I can agree that it's useful to be a little louder about it when you're the one burning.) 02:09:51 03CrawlOdds02 07* 0.35-a0-535-gfad57e3c52: Remove spammy resists message 10(4 minutes ago, 1 file, 0+ 2-) 13https://github.com/crawl/crawl/commit/fad57e3c52f8 02:14:13 <11Odds> Oh, apologies @hellmonk - while going through PRs I realised I missed https://github.com/crawl/crawl/pull/4941, which does something extremely similar to the previewing change I made yesterday. 02:17:53 <11Odds> Some day soon I hope to drive our PR numbers into double figures 🙂 02:35:00 <11Odds> Re: https://github.com/crawl/crawl/pull/3352 (lightning rod formulae) - last time we discussed this we ended up with this that Monkooky helpfully summarised: Summary of current + proposals: Current: at each distance, the damage is less the more squares at that distance you hit. To maximize damage, can do weird targetting shenanigans to hit one extra/one less square Very unintuitive! Monkooky's change: Damage is less the more squares 02:35:00 you hit can sometimes do weird targetting shenanigans to hit an extra square without increasing arclength Has some wack behaviour caused by 'extending' the beam out to 5 regardless of what it normally would hits Odd's's' change: Does full damage on the beam you zapped this turn, lesser damage on the arc from prior beam Easier to communicate, probably less jank Maybe less interesting? 02:42:06 <11Odds> I tend to think there are 3 problems with the current thing: * The distance-dependent effect is very surprising (no-one would guess it in isolation or from the description) * It leads to fiddly targetting for optimal use * (Maybe) The targetter highlighting very much leads me to expect the beam itself is going to do more damage (it's brighter yellow!) Monkooky's change addresses the first one, it remains fiddly, and if we wanted to we 02:42:07 could fix the targetter to make it clearer. The change I proposed fixes all these issues but as Monkooky says isn't so interesting. TBH I think either of these is a clear improvement on the status quo but don't have a strong opinion between them 02:59:49 <04dracoomega> I think I have vague memories of preferring your option, the last time this came up. But one issue about this in general is that it feels like it is largely a mistake, at present, to spread the damage out versus concentrating it (ie: that while the item lets you cast a wide beam, this is usually a trap). This makes me feel a little fuzzy about how exactly how this spreading should work, and mostly made me wonder if the core 02:59:50 targeting of it ought to be reimagined entirely somehow. This was on my list for a serious think over when I got to that big pass on evokers I've been planning to do for... ages now. But since that's also clearly not going to happen anytime soon, it may make sense to do what you suggest. 03:02:56 <11Odds> Yeah I agree that spreading is a bit of a trap right now. I think we could fix that with any of these by tweaking parameters, but also the third option does that fairly clearly as long as you have a good enough place for the second beam 03:03:47 <11Odds> I do like the “sheet between beams targetting” in general, it’s quite unique and flavourful 03:04:39 <04dracoomega> Yeah, I guess option #3 means that you want it to be as big as possible, so long as the main beam is actually hitting something relevant 03:04:59 <04dracoomega> Which I think is reasonably intuitive (assuming I'm understanding correctly) 03:06:32 <11Odds> Option 3 is derived from “what I believed before any of this conversation”, so I’m highly biased in finding it intuitive 🙂 03:07:35 <11Odds> Cool, I’ll have a go at this and start thinking about parameters for balance 03:08:27 <04dracoomega> I knew it wasn't the case, but my understanding of the specifics of current damage falloff was mostly just "Don't temp fate, since I think it's uncharitable to the player" 😛 03:29:40 03regret-index02 07* 0.35-a0-536-gcfa9558a1d: Replace a decent chunk of mid-combat screen flashes 10(14 hours ago, 20 files, 89+ 12-) 13https://github.com/crawl/crawl/commit/cfa9558a1de4 03:29:40 03regret-index02 07* 0.35-a0-537-gfbdcd0e0b1: Add new Shatter vfx + option to choose either 10(14 hours ago, 12 files, 73+ 5-) 13https://github.com/crawl/crawl/commit/fbdcd0e0b124 03:29:40 03regret-index02 07* 0.35-a0-538-ge467b9c7cb: Loose other minor tile adjustments 10(25 minutes ago, 27 files, 7+ 2-) 13https://github.com/crawl/crawl/commit/e467b9c7cbce 03:29:40 03regret-index02 07* 0.35-a0-539-g1cd6560a68: 0.35 changelog update (through e467b9c7cb) 10(65 seconds ago, 1 file, 206+ 0-) 13https://github.com/crawl/crawl/commit/1cd6560a6857 03:34:37 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 07:48:01 <11Odds> Any thoughts on how to pick the damage numbers for reworked lightning rod? There are two parameters to play with; main beam damage and the proportion of that done by the sheet. I don't have great instincts for this, but if we think current lightning rod is mostly best used as a single-beam attack, and that we're making the AoE more relevant, probably the main beam damage should go down if anything. 08:22:18 <11Odds> Also I wonder how hard it is to make walls interrupt the sheet in a natural way, this feels silly... 08:22:19 <11Odds> https://cdn.discordapp.com/attachments/747522859361894521/1516825320706281603/image.png?ex=6a340d29&is=6a32bba9&hm=67e13948fe3037ee1bb77b5ea2ec5414a104aa249b3d297dabc6605c2e67f357& 09:30:58 <04dracoomega> It might make some sense to lower the main damage a little if the AoE damage is increasing meaningfully, but I'd be wary of nudging it down more than a little bit, since target prioritization probably means that primary damage going down is worth more than secondary damage going up. ...though I guess the new version lets you go very wide, so maybe it will have a larger impact than my first assumption here. 09:32:43 <11Odds> I think it's probably not so much "the AoE damage increases a lot" as "the main beam doing full damage lets you actually use the AoE part" 09:33:28 <04dracoomega> That is what I meant, yeah. Not like 'the raw damage the beam could do' but 'effective dps in a real battle' 10:32:05 nopoisonplease (L2 MiFi) Crash caused by signal #6: Aborted (D:2) 10:38:50 nopoisonplease (L2 MiFi) Crash caused by signal #6: Aborted (D:2) 10:47:56 nopoisonplease (L2 MiFi) Crash caused by signal #6: Aborted (D:2) 11:08:01 03CrawlOdds02 07* 0.35-a0-540-gd6847357b2: Rework lightning rod damage 10(7 hours ago, 7 files, 16+ 27-) 13https://github.com/crawl/crawl/commit/d6847357b22e 11:08:55 <11Odds> Oh oops I actually meant to push that to a branch 🤦 11:10:49 <11Odds> I think it's a sensible damage nudge, but would like a second opinion 11:11:18 you could force push and hope nobody updated in the interim 11:11:56 <11Odds> No, I'll revert it 🙂 11:13:20 03CrawlOdds02 07* 0.35-a0-541-g249ab93952: Revert "Rework lightning rod damage" 10(4 minutes ago, 7 files, 27+ 16-) 13https://github.com/crawl/crawl/commit/249ab9395213 11:16:23 <11Odds> (I thought a local branch would push to the same named branch upstream, which I'm sure has happened for some other branches. Will have to update my git understanding) 11:49:04 I've always had to use `--set-upstream`, and I think that's documented 11:50:24 also when I create a local branch it has no upstream and will say so if I try to push, but that may be because I habitually use `git switch -c` to create it 11:51:22 there are other ways to create local branches (e.g. `git stash branch`, or using `git branch` directly) and they may do other things 11:55:26 <11Odds> Thanks. Yeah, what I'm not sure of is how I created this local branch with an upstream. At any rate, I've set a bunch of git config now to ensure I can't do this particular stupid thing again. 11:58:32 nopoisonplease (L2 MiFi) Crash caused by signal #6: Aborted (D:2) 12:39:36 New branch created: gravityshield (1 commit) 13https://github.com/crawl/crawl/tree/gravityshield 12:39:36 03hellmonk02 07[gravityshield] * 0.35-a0-453-g876d2d869c: New spell, gravitic shielding 10(11 minutes ago, 12 files, 100+ 0-) 13https://github.com/crawl/crawl/commit/876d2d869cf0 12:40:40 New branch created: pull/5299 (1 commit) 13https://github.com/crawl/crawl/pull/5299 12:40:40 Branch pull/5299 updated to be equal with gravityshield: 13https://github.com/crawl/crawl/pull/5299 15:42:25 Unstable branch on underhound.eu updated to: 0.35-a0-541-g249ab93952 (34) 22:26:05 Xavori (L17 MDCK) ASSERT(m) in 'mon-util.cc' at line 2445 failed. (Shoals:1) 22:35:54 Unstable branch on crawl.develz.org updated to: 0.35-a0-541-g249ab93952 (34) 22:59:46 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-541-g249ab93952 23:32:16 Unstable branch on cbro.berotato.org updated to: 0.35-a0-541-g249ab93952 (34) 23:56:12 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-541-g249ab93952