02:25:07 03CrawlOdds02 07* 0.35-a0-716-g049aa0cdba: Stop useless casts of scorch, permafrost and plasma beam 10(40 minutes ago, 1 file, 20+ 17-) 13https://github.com/crawl/crawl/commit/049aa0cdbaa9 03:33:26 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:16:53 03CrawlOdds02 07* 0.35-a0-717-g6b81ce4688: Fix ordering of dump messages on monk/faded worship 10(2 hours ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/6b81ce468850 05:16:53 03CrawlOdds02 07* 0.35-a0-718-gd1854f4fe9: Fix Ash portal reveal in descent mode 10(62 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/d1854f4fe9a7 07:04:38 03CrawlOdds02 07* 0.35-a0-719-g0b11e0dbc8: Fix a multikill on Blorkula with pain bond 10(13 minutes ago, 1 file, 14+ 3-) 13https://github.com/crawl/crawl/commit/0b11e0dbc826 07:21:35 <04dracoomega> @Odds Regarding this, non-forced casts already stopped the player from using the spell without valid targets around, and I had considered (but apparently forgot to actually do...) just having a spell flag that meant "Don't allow force-casting" (ie: enforce that spell_no_hostile_in_range() must be false before allowing any casting of such a spell.) Not 100% sure that this is a better approach (but then it also might be reasonable 07:21:36 to extend it to things like Putrefaction, which also are never usable if spell_no_hostile_in_range() is false. Even if showing a targeting UI with no valid targets is obviously already less bad behavior than casting a spell for no benefit.) ...realizing now that C++ if (env.invis_knowledge.any_unknown_nearby()) return false; is even more incorrect, since those spells that require visible targets shouldn't change behavior just because 07:21:36 some unknown thing is around, so maybe that's another argument in factor 07:22:28 <11Odds> Does casting from the quiver with "p" count as a forced cast? I expect that's what I was doing when I hit this 07:23:31 <11Odds> (From the bugs I trip across, I think I quiver spells much more than other people 🙂 ) 07:24:25 <04dracoomega> (I sometimes wonder if I just use it much less >.>) 07:24:41 <04dracoomega> I pretty much only ever quiver spells to use them with shift+tab 07:24:57 <04dracoomega> (Which doesn't cast blindly without targets) 07:25:01 <11Odds> Whereas I probably cast most of my spells through p 07:26:00 <04dracoomega> Shift+tab and p are supposed to be equivalent, though 07:26:16 <11Odds> I think it's good not to have known-useless spells be castable even under forced casting, though 07:27:10 <04dracoomega> And like... trying to cast plasma beam without visible targets via p even currently says that there's no susceptible monsters in range and stops, for me. If it wasn't doing this for you, is there some other rc setting involved, maybe? 07:27:30 <11Odds> Hmmmm 07:27:55 <11Odds> Maybe I was forced casting, then! Forgetting that the invisibility rules had changed. 07:28:37 <11Odds> Because yeah, seems like p asks you to forced cast just like other casting methods 07:30:36 <04dracoomega> Either way, I certainly agree that it shouldn't let you force-cast when it knows it's useless. Just wondered at the benefit of slightly more generalized handling for such a thing. 07:31:22 <11Odds> Yeah, a flag that did this for all these spells (and any more I've missed - only checked spl-damage carefully) would make sense 07:31:47 <11Odds> And then we could not suggest force-casting when it won't work anyway 07:33:28 <04dracoomega> In past, a bunch of target enforcement was done by individual spell code itself. Over time, I've moved more and more of it out of spells themselves and into targeters, with the assumption that by the time you get to spell code, a valid target should be enforced. ...for years, it was possible to use unusual keypresses to directly bypass the targeter, which is part of why spells had all these additional checks themselves (and often 07:33:28 meant there were bugs letting you usefully bypass targeting restrictions for years when bits were overlooked >.>) See: 07:33:28 <04dracoomega> %git 0ad0e9b9b23b52 07:33:30 <04Cerebot> DracoOmega * 0.32-a0-2135-g0ad0e9b9b2: Don't let !/@ work when aiming smite-targeted spells (1 year, 11 months ago, 1 file, 1+ 1-) https://github.com/crawl/crawl/commit/0ad0e9b9b23b 07:35:14 <11Odds> Yep that makes sense 07:35:30 <11Odds> I'll think some time about doing this in a more generalised way 07:35:51 <04dracoomega> Sure 07:36:51 <11Odds> (Or more precisely I'll write that down and maybe think about it some time 🙂 ) 07:37:00 <04dracoomega> Sure ^^; 07:37:46 <04dracoomega> Reading that commit again, I don't think I ever went and did that full pass on removing redundant range checks from individual spells in a comprehensive way, though I've definitely pruned bits here and there as I run into them over time 14:00:12 <11Odds> Currently autoexplore can get stuck, because it pathfinds through visited transporters but then doesn't actually walk through them, so sometimes just ends up standing on a transporter. Which direction should we fix in - should autoexplore be prepared to go through visited transporters? 14:01:01 <11Odds> (E.g. "o" does nothing on this otherwise explored level because the quickest way to get to the unexplored bit is through this visited transporter) 14:01:02 <11Odds> https://cdn.discordapp.com/attachments/747522859361894521/1528144586185113791/image.png?ex=6a5d3b0c&is=6a5be98c&hm=23da3df36fdd2cf4fe50426028ee38541c1b82f08dc5bbe0f7ffee1fa62a203f& 14:20:49 <04dracoomega> Really? I'm surprised, since ctrl+g and variations on this definitely go through already-taken transporters 14:21:16 <04dracoomega> (Which, you may recall, was a source of repeated complaints in Necropolises and such, when the game would take places into them 'unexpectedly') 14:21:38 <04dracoomega> I'm pretty sure I just made them no longer count as known, but don't really otherwise changing travel behavior regarding them 14:22:48 <11Odds> It's because of this check which gates transporters if (runmode == RMODE_TRAVEL || runmode == RMODE_NOT_RUNNING || runmode == RMODE_CONNECTIVITY) 14:24:15 <04dracoomega> I'm not sure I see a good reason why travel and autoexplore have different behavior in this regard. (Maybe the concern was that autoexplore would be more likely to take the player into dangerous vaults they had already fled from, while travel itself was less likely to, as you would often be trying to travel into the vault? Though Necropolis experiences show that this wasn't always the case, either.) 14:25:18 <11Odds> Yeah, nasty vault which you've used both transporters in but left extremely scary could be a nasty shock.... but they aslo are for travel 14:25:34 <11Odds> So I also don't see a reason for inconsistency really 14:27:39 <04dracoomega> This makes me kind of inclined to let autoexplore also take them, and if the player has felt a vault that they want to not end up back inside, this is probably what exclusions are for? (It feels like there are some map layouts where it would be mildly irksome of travel had to interrupt you to manually take part of the path back and forth) 14:30:02 <11Odds> I think that's probably right. I think it's going to be pretty rare that it causes serious danger 14:30:48 <11Odds> And if it does, transporters should probably be either off or have a large cost for travel pathfinding too 14:34:42 <11Odds> (It's worth noting that every time autoexplore will take a transporter, we'd currently get stuck on that transporter. So it must be extremely rare or we'd be getting bug reports regularly) 14:35:08 <04dracoomega> Yeah 14:35:25 <11Odds> https://github.com/crawl/crawl/issues/4479 is an instance of this 14:39:33 <04dracoomega> I do think travel being transporter-aware is cute and sometimes fairly helpful. (There's one Zot entry you can't even enter or leave without a transporter, even.) I am reasonably hopeful that the Necropolis issues stemmed mainly from the player never having been inside said vault, and that any cases of fleeing what fewer number of transporter vaults exist outside can be handled by the player themselves (in the same way that you'd 14:39:33 exclude stairs you didn't want travel to take). 14:41:12 <11Odds> Do Necropolis transporters come pre-visited or something? 14:45:47 <04dracoomega> They did for a while 14:45:53 <04dracoomega> And don't anymore 14:46:30 <04dracoomega> (It was mostly to help with Gauntlets, actually - to make the UI community more explicitly where some of them lead, some it's not always 100% clear) 14:47:57 <04dracoomega> But after enough cases of travel unexpectedly taking the player through a transporter, I sadly decided it was probably not worth the chance of that happening 14:48:44 <11Odds> Yeah makes sense 15:28:22 03CrawlOdds02 07* 0.35-a0-720-gb51359a412: Remove temporary description and colour on corroded weapons 10(25 hours ago, 3 files, 4+ 29-) 13https://github.com/crawl/crawl/commit/b51359a412ef 15:44:22 Unstable branch on underhound.eu updated to: 0.35-a0-719-g0b11e0dbc8 (34) 22:35:51 Unstable branch on crawl.develz.org updated to: 0.35-a0-720-gb51359a412 (34) 22:59:53 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-720-gb51359a412 23:19:46 Unstable branch on cbro.berotato.org updated to: 0.35-a0-720-gb51359a412 (34) 23:56:05 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-720-gb51359a412