00:13:42 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1065-gdcfe8ede59 (34) 00:54:32 Monster database of master branch on crawl.develz.org updated to: 0.34-a0-1062-g464970fc77 01:59:25 -!- indigaz28 is now known as indigaz2 04:32:52 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:48:08 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4869 * 0.34-a0-1049-g9949b5f5be: Improve ranged combat tabbing 10(2 days ago, 4 files, 64+ 0-) 13https://github.com/crawl/crawl/commit/9949b5f5bea4 05:51:22 03Implojin02 07* 0.34-a0-1066-gca97a521a3: Remove a clua make api you.ability_table reference 10(17 hours ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/ca97a521a335 05:51:22 03Implojin02 07* 0.34-a0-1067-g80420c0373: Fixup some clua api documentation 10(4 minutes ago, 2 files, 11+ 10-) 13https://github.com/crawl/crawl/commit/80420c0373f8 06:13:51 New branch created: pull/4874 (1 commit) 13https://github.com/crawl/crawl/pull/4874 06:13:52 03Andrew02 07https://github.com/crawl/crawl/pull/4874 * 0.34-a0-1068-ga5edce7720: Fix wildshape skill estimation for talismans 10(3 minutes ago, 1 file, 9+ 0-) 13https://github.com/crawl/crawl/commit/a5edce772015 07:31:01 03CrawlOdds02 {Implojin} 07* 0.34-a0-1068-g71ebbbb606: Update Vehumet's gift weighting to consider averages 10(4 days ago, 3 files, 16+ 22-) 13https://github.com/crawl/crawl/commit/71ebbbb6069c 09:32:06 03Andrew02 {dolorous} 07* 0.34-a0-1069-gba974f2ec1: Fix wildshape skill estimation for talismans 10(3 hours ago, 1 file, 9+ 0-) 13https://github.com/crawl/crawl/commit/ba974f2ec152 09:53:39 <06mumra> @Odds Re the ranged autofight PR and using an arbitrary beam to calculate paths. In this PR (which I didn't merge yet, but I'm going to use as part of some work adding new ranged unrands) I added a ZAP_MISSILE_TRACER for a somewhat similar purpose for ranged tracers. (Maybe just a separate Lua function should be added tho for ranged paths, rather than having to hacking in some kind of dummy spell) 09:53:40 https://github.com/crawl/crawl/pull/4441/files#diff-31943abf0cff5c8476b8a1b6cce2e3ad5005ce54ae8ed4c369963dd7923fb957 10:00:07 <11Odds> Thanks! I was actually just this moment writing a separate lua function for ranged paths, which I think seems nicer (though I haven't quite done it yet, so maybe there are difficulties I've not realised - IDK much about the ranged/beam/zap code) 10:03:58 <06mumra> The zap was necessary to have a proper tracer instead of just using direction chooser. A proper tracer can also account for "the arrow will definitely reach these squares, and it might reach the squares behind, depending whether it hits the first enemy" which the current beam targetting doesn't show. 10:06:29 <11Odds> But at the moment, ranged combat works in some other way? It doesn't seem to have a zap type 10:06:31 <06mumra> Of course if I make some unrands with slightly exotic targetting (e.g. the first one I made is a 3-wide beam) then autofight needs some further update anyway potentially (there are squares that the 3-wide beam can't reach, currently autofight just assumes a ranged weapon can hit anywhere in LOS) 10:06:54 <06mumra> Yeah ranged just uses the direction_chooser class 10:07:20 <04dracoomega> zap types are basically just quick ways to fill in a bunch of data into the bolt struct. They're not part of the data in the bolt struct. 10:07:29 <06mumra> It took me a lot of digging to figure out how it was actually getting to a targetter tbh 10:07:55 <06mumra> Yeah once you fire, it creates a bolt and fills in all the properties manually 10:07:59 <04dracoomega> (But they're very convenient for filling properties in in a consistent way. In the past, a lot of spells did this manually too, but we've converted most of those over over time, since zap data lets xv show spell damage easily, too.) 10:08:21 <04dracoomega> Well, most spells that use beams directly in some fashion or another, at least 10:09:55 <11Odds> Please could you point me to where it does that? 10:10:51 <04dracoomega> Look at throw_it() 10:11:27 <04dracoomega> (Or perhaps recoil in horror at throw_it() - either or) 10:11:46 <06mumra> Yes I was about to say 10:11:59 <06mumra> The first confusing thing is that all ranged attacks actually happen in the throwing code 🙂 10:13:33 <11Odds> Thanks, I definitely got tricked by ranged-attack.cc 🙂 10:15:06 <06mumra> Yeah that's just for once the projectile hits 10:15:22 <06mumra> Actually launching the projectile is all happened in throw.cc 10:16:47 <06mumra> https://cdn.discordapp.com/attachments/747522859361894521/1434592086333722814/image.png?ex=6908e37e&is=690791fe&hm=ebc5a26502aeac15ce4011b756a81124eac3e33ae7d3a6ef8d74bb35b836b695& 10:16:54 <06mumra> This part is where the targetter is actually invoked 10:17:35 <06mumra> then populate_fake_projectile creates a temporary item for the ammo and _setup_missile_beam does the beam stuff 10:17:47 <11Odds> Perfect, thanks! 10:18:11 <04dracoomega> Ranged attacks basically make a bolt with an item attached, then when that bolt reaches an actor's space, can create a ranged_attack to test the actual hit effects 10:18:12 <06mumra> and eventually _player_shoot is called to actually fire the weapon after a load of other things happen 10:19:25 <11Odds> I think probably for my purposes I can set up a much more basic beam that doesn't do any of the exciting things throw.cc does 10:19:37 <04dracoomega> Most likely, yes 10:21:09 <04dracoomega> (As I said in #dcss earlier, I do think any somewhat intensive checks for caluclating 'best angle to hit X monster at' are likely better done in C++ and exposed to lua instead of done in lua) 10:35:34 <11Odds> That makes sense - I don't think I know what the threshhold for "intensive" should be though 10:36:16 <11Odds> Do you think the current approach (which traces a ray to each point in LoS, so takes time radius^3) would be better moved to C++? 10:40:39 <04dracoomega> It might, yeah. Well, I think I originally thought it was selecting a 'desired target' using the simple logic autofight already uses and then tracing LoS for rays that include that target and picking the best one. But I guess if we're trying to get it to exclude 'completely blocked' targets, it actually needs to gather more information via tracing rays before it can even tell what targets are valid in the first place, doesn't it? 10:44:26 <11Odds> The thing you originally thought is still my plan for this change (though if there's strong appetite to exclude completely blocked targets I could look at that too) 10:46:00 03dolorous02 07* 0.34-a0-1070-g0efa743828: Fix delay info leak on artefact heavy weapons. 10(4 minutes ago, 1 file, 4+ 0-) 13https://github.com/crawl/crawl/commit/0efa7438283e 10:47:28 <04dracoomega> Well, for the former, a get_best_path_through(target) or equivalent feels like it makes a lot of sense to me to exist C-side 10:49:29 <11Odds> For the latter, we might want to do the same anyway, and if the best path through the target isn't good we go down the list of targets 10:50:28 <11Odds> So we'd be using the same get_best_path_through(target), it would just need to return whether the path is good as well as the actual path 10:52:16 <04dracoomega> Perhaps. (Though I'd be cautious of any code organization that involves running those comprehensive firing angle tests on everything in LoS prior to deciding what it wants to focus on, which I fear the simplest integration with how autofight.lua is currently structured might do?) 10:53:04 <11Odds> I think it wouldn't need to do that... but would risk running that amount of tests if everything turns out to be blocked by plants 10:53:04 <04dracoomega> Since I think it basically calculates all properties about the targets first, and then sorts them? Which would imply fully figuring out reachability first? 10:53:43 <04dracoomega> I mean, there's probably no stopping it from being slow if it literally has to try falling back through everything. Just so long as it doesn't end up tracing every path to everything before it takes a shot even in trivial cases, if that makes sense? 10:54:00 <11Odds> Yeah, I think that should be easy to avoid 10:54:08 <04dracoomega> Okay 11:34:35 <04dracoomega> So, while continuing to refactor things, I was trying to do a tiny bit of tidying up of torment_cell(), only to realize that checking for the player's position in an odd way was deliberate because: // Don't return, since you could be standing on a monster. Which made me realize that there are lots and lots of places in the code that specifically assume only one actor can be occupying a space (and will do something to that one 11:34:36 actor and then stop). For instance, Irradiate, Static Discharge, Scorch (and many more that I'm not going to take the time to exhaustively search up now). And like... I can't help but wonder if it would be better general policy to say that if the player is standing on a plant, they actually shield it from all harm with their body, instead of actually trying to be comprehensive everywhere about whether there is additionally a non-player actor in the 11:34:36 same tile and doing effects twice. (Standard beam code currently does hit both things at once, when applicable, but that could be changed.) ...though I guess this means you could make a ballisto ally immune even to explosions and so forth by standing on top of it. This is maybe a mild buff in some situations but given just how much you'd rather stand behind plants usually, it's probably okay?) 11:36:26 <04dracoomega> I kind of hate to imagine restructuring all of these bespoke things to handle two actors in one tile, and future omissions seem inevitable. In fact, it's hard to track how many already exist. 11:46:05 <04dracoomega> (Whereas it's vastly easier to be consistent in the opposite direction) 12:37:17 -!- indigaz27 is now known as indigaz2 12:40:37 <09gammafunk> regarding, lua path/tracer checks, improving that situation could be good. I have an elaborate ranged attack projectile algorithm seen here in a qw branch that's not yet merged to master that's simply based on spells.path() that assess explosion radii, penetrating vs non-penetrating projectiles, destruction of thrown ammunition etc. I'm sure having better ray checks could be useful, but as this code shows, there's just a lot of 12:40:37 aspects to consider if you want to automate use of various types of ranged things 12:41:31 <09gammafunk> and of course it doesn't do non standard (i.e. not some kind of beam + possible explosion radius) spell targeters at all, because that's even more difficult to generalize 13:00:52 -!- meatpath1 is now known as meatpath 13:08:38 <11Odds> Thanks, really helpful to have that comparison point. I'm generally a little worried about letting the perfect be the enemy of the good here; I think we can make ranged combat tabbing significantly less miserable with something quite simple. On those considerations: * I'm inclined to ignore explosions (at least for now) * Penetrating vs non-penetrating; I guess here the difference is whether our projectile should hit the primary target 13:08:39 first if possible, and we should probably check that. * I don't think we care about ammunition destruction here * I'm definitely not intending to generalise this to spell targeters (though that would be nice, it seems a lot of work!) I don't think this change would make things worse on any of these fronts 13:15:44 <09gammafunk> seems like a reasonable summary, and there could indeed be something that has reasonably limited scope and relatively few corner cases (some of which might get improved over time). I'm not 100% sure of your meaning in the second point. Does that mean that e.g. autofight non-penetrating projectiles should assess its primary target and try a secondary if this isn't possible? 13:16:52 <09gammafunk> There's definitely a slippery slope to be aware of where we start with autofight improvements and end up closer and closer to qw-style "total" assessment, and at what point are way playing the game "too much" for players 13:18:36 <11Odds> On the second point - the plan is to still have autofight pick a "primary target" just as at the moment, and then pick a ray that hits that target based on secondary targets. For a penetrating attack, we'd just maximise how many targets are on the ray; for a non-penetrating attack we should probably try to ensure that the first target on the ray is the primary target. 13:20:10 <04dracoomega> I might be inclined to say we should do the former in all cases (but that should tend to happen anyway, due to how autofight prioritizes closest targets first) 13:20:36 <11Odds> Definitely very aware of that slippery slope - in another channel I wrote: "Totally agree with the balance of concerns here; IMO, this change is on the right side of it, because it's automating something very mindless I do many, many times a game (and would do more if it were faster)" 13:20:38 <04dracoomega> I'm not sure it's possible to pick a target that is at least tied for closest and then find a path that hits something else first 13:20:52 <04dracoomega> Sounds topologically impossible 13:20:55 <11Odds> Well, we don't just pick based on proximity 13:21:17 <04dracoomega> I thought proximity was the highest priority factor? Maybe I'm wrong? 13:22:07 <11Odds> I believe that the order is {"bullseye_target", "can_attack", "safe", "good_stab", "distance", "constricting_you", "poor_stab", "injury", "threat", "orc_priest_wizard"} 13:22:13 <11Odds> That last one sounds super principled 🙂 13:23:11 <11Odds> Still it's usually distance. Seems reasonable just to try to aim at the target first 13:23:22 <04dracoomega> Okay, yes, de-prioritizing bullseye stuff first, I guess. But otherwise distance is first for things we can actually attack. 13:23:44 <11Odds> And we deprioritise things that can't attack us, I think? 13:23:50 <11Odds> And can't get to us 13:24:09 <04dracoomega> I... is that what 'safe' means here? Like, that includes things that can't path to you? 13:24:21 <11Odds> That was my guess, but 🤷 13:25:09 <11Odds> Yeah looks that way 13:25:15 <11Odds> Pretty sure it routes through to mons_is_safe 13:25:46 <04dracoomega> Oh, I've... actually made some changes with that on this branch 13:25:53 <04dracoomega> (To fix some existing bugs >.>) 13:27:09 <04dracoomega> It no longer cares about pathfinding for monsters that you have unblocked line of sight to. Previously it would somewhat inconsistently ignore, say, land monsters on the other side of water, but in a way that made it entirely possible to autoexplore directly into melee range of them and only stop when they first hit you (assuming you could cross water) 13:27:49 <04dracoomega> And after wrestling with various options here, I opted to just make such monsters block autoexplore in general (and only care about pathfinding knowledge for things behind glass and sucH) 13:28:15 <11Odds> So I can still autoexplore through glass doors into nasty monsters who can't open doors? 13:28:32 03dolorous02 07* 0.34-a0-1071-g4a20da8d68: Fix spacing. 10(39 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/4a20da8d6842 13:28:33 <04dracoomega> I... hmm.... 13:29:17 <04dracoomega> I... guess if they're unruned and there's no other way for them to reach you? (I had not thought about this) 13:29:23 <11Odds> (I wouldn't worry about the effect of this on autofight, IMO no one is likely to be relying on this behaviour) 13:29:44 <04dracoomega> No, I don't think it's a problem, regarding autofight. If anything, it makes it more consistent. 13:30:03 <04dracoomega> Since anything that isn't always harmless (like a butterfly) that you have line of sight to, is not safe 13:30:26 <04dracoomega> (But this still keeps autofight from caring about things in glass transporter vaults and such, in theory) 13:32:14 <11Odds> Pretty sure this has always been the behaviour, though IMO it would be nice to fix it. It's a bit weird because it's a case where you don't want to autoexplore (or not in a certain direction) but you are completely safe 13:33:10 <11Odds> I guess that's just the same as your water case, actually 13:33:31 <04dracoomega> Yes, it's the same idea (but the water one is a fair bit more common) 13:34:08 <04dracoomega> It may be possible to handle this via doing this specific kind of pathfinding as if the monster could open doors 13:34:18 <04dracoomega> Whether it can or not 13:36:06 <04dracoomega> And yeah, I weighed this back and forth because like... those yaks on an island really can't reach you, and if you don't autoexplore right next to them, you are also completely safe. But it turned into a really hard problem when I tried to consider analyzing threat ranges and how many tiles a given monster could cover in the span of time it takes you to move closer, and so forth. Not unsolveable but extremely heavyweight to be 13:36:06 doing all the time, and we generally don't make vaults like that anymore anyway. So hopefully when it does come up, telling the player to do something about that enemy is appropriate. 13:36:48 <04dracoomega> And the simple approach of "There is a hostile monster out in the open" being a blocker is straightforward. 13:37:07 <04dracoomega> (It is important to automate this away for things actually trapped in boxes, though) 13:38:29 <11Odds> It does sound like in some cases the yaks on the island could block autoexplore for a long time in a slightly annoying way 13:39:01 <04dracoomega> Yes, but like... the 'yak island' vault has been gone for a long time, and as policy we don't put things on islands without some way to actually threaten the player. 13:39:18 <11Odds> Yeah, and I'm also not keen on autoexploring next to them, so I don't have a better suggestion 13:39:29 <04dracoomega> Obviously map generation can sometimes put melee enemies on the other side of stuff on a temporary basis, but probably the player actually should do something when this happens 13:40:08 <04dracoomega> (It felt like the nuissance value in the hopefully rare time this comes up is better than autoexploring into melee of something, even if that is also rare) 15:29:42 <06mumra> Re: Multi-level portals. There's this one idea I've had kicking about for a while which is "Jurassic Mesa". Its full realisation would be a 2-level ascent to the 3rd level which would be the flat plain (caprock) on top of the mesa, full of jurassic fauna and flora. First level would be navigating narrow concentric mountain paths (using a new "cliff edge" terrain which works directionally, allowing enemies to fire down at you but limiting 15:29:42 your ability to fire back at them; and you can't simply fly up it, although you can fly or fall back down it if you need to run). 2nd level would be navigating caves inside the mesa. Monsters include of course dinosaurs and other prehistorics, and also neanderthal variants of humans/elves/dwarves/etc. Plus (particularly on the last level) stuff like carnivorous megafauna and probably a t-rex boss. Obviously this is massively a pipe dream that I would 15:29:43 certainly never have enough time to seriously work on 🙂 15:33:50 <09hellmonk> couldn't it just be a branch tho 15:35:44 <09hellmonk> the thing portals give you is a way to make content that can't be backed out of without losing it permanently. Would that be the intent there? Like if you back out partway you lose the rest of the contents for good? 16:01:53 <06dolorous_84348> I've been looking into bug #4654, and it's been... interesting.The displayed formula via describe.cc:_staff_max_damage() isn't quite right when it produces a value of -1 for low-HD monsters with no necromancy skill wielding staves of necromancy, since the actual formula in melee-attack.cc:staff_damage() only uses random2() without any subtraction. I figured the displayed formula could just be set to a maximum of zero after 16:01:54 calculation, and wondered if the maximum damage formula was quite right, since fsim would produce a maximum damage value that was either equal to the displayed formula's value or one less than that (maybe it's just rounding? I'm not all that familiar with fsim), and all I've been able to figure out is that non-quick fsim crashes if you try to run it with a species that can't train armour (I happened to be a poltergeist during testing, and it also 16:01:54 happens when I'm a draconian). I could work my way around the crash, but I'm not sure how useful the information is if armour is untrainable. 16:31:56 03dolorous02 07* 0.34-a0-1072-ga5e1a6726e: Fix low-HD monster staff damage display (#4654). 10(5 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/a5e1a6726eda 16:34:48 <09gammafunk> rip negative damage 16:38:07 <09hellmonk> rN added 16:39:53 Unstable branch on underhound.eu updated to: 0.34-a0-1071-g4a20da8d68 (34) 18:55:02 -!- meatpath1 is now known as meatpath 19:21:12 -!- meatpath1 is now known as meatpath 19:34:27 New branch created: pull/4876 (3 commits) 13https://github.com/crawl/crawl/pull/4876 19:34:29 03WizardIke02 07https://github.com/crawl/crawl/pull/4876 * 0.34-a0-1071-g7de2c262e8: Unify status icon sizes between web and local tiles 10(85 minutes ago, 8 files, 214+ 179-) 13https://github.com/crawl/crawl/commit/7de2c262e813 19:34:29 03WizardIke02 07https://github.com/crawl/crawl/pull/4876 * 0.34-a0-1072-g7df76e545f: WIP 10(63 minutes ago, 1 file, 10+ 2-) 13https://github.com/crawl/crawl/commit/7df76e545f90 19:34:29 03WizardIke02 07https://github.com/crawl/crawl/pull/4876 * 0.34-a0-1073-g946dbd033d: WIP 2 10(52 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/946dbd033dc6 19:35:35 03WizardIke02 07https://github.com/crawl/crawl/pull/4876 * 0.34-a0-1073-g0a9644e55b: Unify status icon sizes between web and local tiles 10(86 minutes ago, 9 files, 224+ 181-) 13https://github.com/crawl/crawl/commit/0a9644e55b25 19:36:40 03WizardIke02 07https://github.com/crawl/crawl/pull/4876 * 0.34-a0-1073-gd69c08cc61: Unify status icon sizes between web and local tiles 10(88 minutes ago, 9 files, 224+ 181-) 13https://github.com/crawl/crawl/commit/d69c08cc61d4 20:30:00 03WizardIke02 07* 0.34-a0-1073-g3b4e6100cc: Change lesser beckoning message when target immune 10(11 minutes ago, 3 files, 6+ 2-) 13https://github.com/crawl/crawl/commit/3b4e6100cc33 20:43:29 Jarek1 (L1 GrMo) Crash caused by signal #8: Floating point exception (D:1) 20:44:57 <03implojin> !crashlog Jarek1 20:44:57 <04Cerebot> 2. Jarek1, XL1 GrMo, T:40 (milestone): https://underhound.eu/crawl/morgue/Jarek1/crash-Jarek1-20251103-034328.txt 20:48:44 <03implojin> div by zero in num_destructive, looks like 20:50:47 gah, right, can't check cue morgues any more 20:51:51 <09gammafunk> geekosaur: username crawlmoruge ; password: fuckaibros 20:51:51 <03implojin> you can, you just need the login posted on cue's webtiles page 20:51:54 <09gammafunk> er 20:52:12 <09gammafunk> crawlmorgue (i.e. spelled correctly) 20:53:30 03WizardIke02 07* 0.34-a0-1074-g422f7dc91f: Say when targeting an immune monster with lesser beckoning 10(4 minutes ago, 5 files, 25+ 0-) 13https://github.com/crawl/crawl/commit/422f7dc91f5d 20:53:35 <09gammafunk> hrm...did we really not have a mon info field for stationary monsters 20:55:18 <09gammafunk> I guess we just had it indirectly via mons class 20:57:50 <07wizardike> I guess I could have just used the mons_class_is_stationary one 20:59:34 <09gammafunk> it's probably correct to do what you did, I'm really not sure how one should think about designing this kind of info class 21:01:03 <09gammafunk> we have existing stuff like cpp can_see_invis = mons_class_sees_invis(type, base_type); so what you did is consistent with that 21:01:48 <09gammafunk> it's just an unfortunate design where there's all this manual duplication, but it's not difficult duplication to manage either 21:10:39 <04dracoomega> For what it's worth, the check for tentacles is superfluous as they're also stationary. 21:11:40 03Implojin02 07* 0.34-a0-1075-g5347199fb9: Fix a Vehumet div by zero crash (Jarek1) 10(4 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/5347199fb937 23:28:13 <06mumra> Certainly it could probably just be a branch. Although I struggle to think where it would even sit in the overall branch structure. 23:28:51 <09hellmonk> alternate lair clearly 23:30:45 <06mumra> That is an idea that popped to my mind as well 23:31:46 <06mumra> Although it would need some adjusting of the challenge as having ranged attacks rained down on you while limiting your ability to fight back would be too much for most characters to adapt to at Lair 23:39:05 <06mumra> Makes more sense to maybe rotate with Crypt 23:40:29 <06mumra> Lair seems generally impossible to replace without the potential to wildly skew game balance at a particularly sensitive point