03:34:10 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 06:47:01 hello! I was looking at issue #3112 on github and noticed that the MV_DELIBERATE move flag doesn't get set properly in the _handle_player_step function to avoid rampaging causing multiple thorns ticks... couldn't this be fixed just by checking the first_step and rampaging bools and passing the deliberate flag if they are both true or am i missing something? 07:00:04 <04dracoomega> _apply_barbs_damage() cares about the time taken for the movement, which isn't fully calculated for rampage moves until every tile has been crossed (since it can be affected by moving through shallow water or plants and such) 07:00:25 <04dracoomega> So we don't necessarily know on the first step how long the whole move will take 07:00:43 so damage should be checked after the full rampage and not before? 07:01:23 <04dracoomega> Well, currently it affects duration and not damage, but as-written, it does look to me like it needs to happen at the end 07:01:48 should i make a new issue or just try fix it? 07:02:25 <04dracoomega> I mean, that doesn't seem like an issue to me? Am I missing something? 07:03:03 even though the player moves deliberately the deliberate move flag is not set on a regular move due to the interaction with thorns and rampaging 07:03:31 there is a comment mentioning this 07:04:38 "XXX: While this is deliberate movement, we specifically don't use MV_DELIBERATE here so that rampage does not trigger barbs potentially many times in a row. move_player_action() will do this later." 07:05:31 i am relying on the deliberate flag when trying to check if the player was moved forcefully or not concerning issue #3112 07:08:38 sorry if i'm making no sense XD 07:10:19 it seems that player_did_deliberate_movement() gets called in two places, once checking the flag, or in the move_player_action function. 07:12:11 <04dracoomega> No, I understand what you're trying to do. Though I admit that I'm not certain the value or importance of using a different message here (since the previous message is already going to say if the movement was caused externally). There's lots of other places where deliberateness is not accounted for fully, since it doesn't matter. Like, a bunch of translocations that are deliberate and non-deliberate go through the same codepaths 07:12:11 without differentiation. 07:12:33 <04dracoomega> Since 'deliberateness' doesn't actually matte for translocations, mechanically 07:13:51 i think the idea is you can force more if your ice armor or ramparts are broken because you are trampled or translocated by an enemy. just forcemoring the move would stop even if the move happened while ice armor is not active 07:14:46 it's niche but i thought it would be a nice addition 07:15:26 also there might be more applications for checking this flag in the future and the way it currently is working is quite unintuitive 07:15:35 a change to the flag description could help 07:16:44 adding a "not including steps done by player action" or something of the sort 07:17:07 <04dracoomega> I mean, it is done for normal player movement actions. It's not done per step, but once per the whole movement. 07:18:23 the player_did_deliberate_movement function yes but not the MV_DELIBERATE flag in the player::move_to method as far as i can see 07:18:32 am i missing somethinG? 07:21:46 <04dracoomega> I mean, sure. But it says specifically what the effect of calling move_to() with that flag will be, which is in fact the complete current effect of using that flag. 07:23:35 it's just confused me that the flag called "MV_DELIBERATE" isn't set after a deliberate action of the player, especially because the description mentions "Movement was done deliberately by the actor themselves" 07:23:45 maybe it's just a me issue 07:28:19 <04dracoomega> I mean, it would perhaps be ideal if it was used in literally every place where a movement was deliberate, but the single place it is explicitly avoided when it would otherwise meaningfully apply has a clear comment about why. And outside of these current attempts to add a new feature involving those flags, didn't actually cause any other issues. (And given that handling barbs properly here would need some extra handling one way or 07:28:20 the other, since it literally doesn't have complete information at the time of the first call to move_to(), it seemed by far the most straightforward way of handling it to me.) 07:29:58 <04dracoomega> If we want to use MV_DELIBERATE to affect ozo's armour messaging, then several things need to be done differently in multiple places. (eg: random blinking - whether deliberate or not - doesn't set MV_DELIBERATE at the moment, since there was not difference whether it did or not.) 07:30:24 yeah, that's what i'm finding 07:30:34 sorry, i wasn't trying to start an argument 07:30:59 <04dracoomega> (A bunch of translocations where it was already unambiguous that it was deliberate did use MV_DELIBERATE, since there was no cost to doing so. But I didn't try to split existing methods apart to allow adding this properly, since that wouldn't have actually done anything.) 07:31:48 <04dracoomega> All of these flags and this way of handling movement is actually fairly recent, and a major rewrite from how things were at the time that bug report was first submitted, incidentally 07:31:54 <04dracoomega> %git fec6f05 07:31:54 <04Cerebot> DracoOmega * 0.34-a0-1248-gfec6f050e1: Refactor all actor movement code (10 months ago, 50 files, 691+ 777-) https://github.com/crawl/crawl/commit/fec6f050e1c6 07:32:14 <04dracoomega> I think it would have been considerably more unreasonable to try it back then 07:32:24 <04dracoomega> (Anyway, I hope I don't sound hostile or anything; I'm not meaning to.) 07:32:37 I know, I just don't want any bad faith 07:33:06 i'm trying to contribute to this game i love and i really don't want to burn bridges, i'm just not experience working on large projects like this 07:33:27 <3 07:34:09 I'll look for a different issue 07:34:26 <04dracoomega> No bridges are currently smoldering, don't worry ^^; 07:35:31 tysm for your time and patience 07:35:37 <04dracoomega> (Really, arranging things so that deliberate movement gives different ozo's messages is still possible, but I don't think it would be a quick change since a decent number of cases would need to be reorganized) 07:35:49 yeah, so it seems 07:36:06 <04dracoomega> And I remain a little uncertain of the cost-benefit there. 07:36:12 yeah XD 08:08:16 <04dracoomega> @Odds Testing the talisman plusses branch now, and wondering if we ought to do something about the form table when a plus (or minus!) pushes either min or max skill out of the possible range. Like, a +2 quill talisman has a row for the state you'd have if your shapeshifting skill was -2 ^^; (It's not completely wrong, but I wonder if it should cap the top and bottom at 0 and 27, even if this means not showing the full 'range' of 08:08:17 power a talisman would normally have.) 08:44:28 <11Odds> Hmmmm, yes. Definitely at the bottom I agree... at the top there's some precedent in mindelays at 28 08:45:17 <11Odds> (But I don't know that I like this precedent really, probably both should cap 09:01:02 Dcebgt (L23 DgHu) Crash caused by signal #6: Aborted (Abyss:5) 09:40:59 <11Odds> ^ Looks like another instance of that thing where killing a tentacle reverts its terrain and we get wall monster nonsense. I think we were just going to make the portal non-solid, but it looks like I never actually did that 09:46:47 <04dracoomega> I think the joke for those unrands is kind of funny, but it's also true that it's a recurring thing that people post screenshot being confused about how to reach 28 09:47:00 <04dracoomega> Sounds about right, by my memory 09:50:13 <11Odds> Yeah. If you're building on the branch, do you want to do the capping? Happy either way. 09:52:07 <04dracoomega> I'm still wrangling the new background design details, so I'd be just as happy if you could take care of that, if that's no trouble ^^; 09:52:23 <11Odds> Yep will do! 09:52:47 <04dracoomega> Just played some real runs with them for the first time today, and already have a list of changes (some easy and some 'I need to figure out what to do about this') 09:55:18 <11Odds> Nice 10:22:41 <09hellmonk> while I'm doing unrand stuff, if there are any obvious outliers that need buffed/nerfed lmk. I was thinking about reducing rift enchant somewhat bc that item is absurd 10:25:11 <11Odds> Personally I'd nudge mule upwards because while backblast is interesting I also think it's generally a negative 10:51:41 03DracoOmega02 07* 0.35-a0-1037-ge7a0c64938: Fix TSO's holy warrior summon lasting 1/10th as long as intended (acrobat) 10(73 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/e7a0c6493818 12:56:02 New branch created: pull/5425 (16 commits) 13https://github.com/crawl/crawl/pull/5425 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1038-gf70b554343: Make spell_effect_string non-static for usage in utilities 10(8 weeks ago, 2 files, 8+ 6-) 13https://github.com/crawl/crawl/commit/f70b5543437d 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1039-gf96bbbd5c1: Make possible to create aspiring flesh without PROTEAN_TARGET_KEY 10(8 weeks ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/f96bbbd5c1c0 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1040-gcca6120579: Use spell_effect_string for monster utility, avoid some duplication 10(8 weeks ago, 1 file, 47+ 131-) 13https://github.com/crawl/crawl/commit/cca6120579dc 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1041-gbb6f92e8c2: Restore some fallback part 10(8 weeks ago, 1 file, 3+ 0-) 13https://github.com/crawl/crawl/commit/bb6f92e8c2b3 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1042-gd8ade7effc: Make glaciate damage non-random in describe 10(8 weeks ago, 3 files, 4+ 4-) 13https://github.com/crawl/crawl/commit/d8ade7effc14 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1043-gc0ef330a1f: Add need_save flag for willcheck spells. 10(8 weeks ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/c0ef330a1ff5 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1044-g8e48dc8280: Fix healing spells "damage" 10(8 weeks ago, 1 file, 7+ 8-) 13https://github.com/crawl/crawl/commit/8e48dc828076 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1045-geccf829bc4: Support pain format 10(8 weeks ago, 1 file, 5+ 0-) 13https://github.com/crawl/crawl/commit/eccf829bc4dc 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1046-g4aad69247d: Restore minor healing dmg 10(8 weeks ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/4aad69247dc3 12:56:08 03Sergey Semushin02 07https://github.com/crawl/crawl/pull/5425 * 0.35-a0-1047-g176436b628: A few more fixes 10(8 weeks ago, 1 file, 10+ 1-) 13https://github.com/crawl/crawl/commit/176436b62897 12:56:08 ... and 6 more commits 13:25:52 <11Odds> Hmmmm... for making malign gateways non-solid, I'm a bit surprised we don't have some kind of actor_cant_be_here function. Lots of places seem to use solidity for this. 13:26:08 03DracoOmega02 07* 0.35-a0-1038-gaffa9b99c3: Be more explicit about fortress crab's ego-doubling effect (Acrobat) 10(39 seconds ago, 2 files, 7+ 4-) 13https://github.com/crawl/crawl/commit/affa9b99c3f2 13:28:05 <04dracoomega> monster_habitable_grid is possibly what you're looking for? 13:28:30 <04dracoomega> (Or actor::is_habitable(), I guess) 13:29:09 <04dracoomega> There's some weirdness I guess where that exclude water for the player, who can technically occupy it. 13:29:13 <04dracoomega> I don't know if that matters for what you're doing or not 13:29:32 <04dracoomega> But is there any reason to treat these portals as odd terrain in any way, though? 13:29:40 <04dracoomega> Nothing else can be there since there is always a tentacle there first 13:29:47 <04dracoomega> Oh, wait, the startup 13:29:55 <11Odds> Yeah, the startup 13:30:38 <11Odds> Yeah a lot of cases go through habitability. And also, a lot don't (e.g. placing shadows, placing orc friends, teleports, sporangium launches) 13:32:12 <11Odds> I guess the player side ones might be fixed by making this dangerous to the player 13:32:34 <04dracoomega> In older times, you actually could step into it, which would injure and blink you! 13:32:59 <04dracoomega> (Very literally dangerous) 13:33:04 <11Odds> Ha 13:33:05 <04dracoomega> Possibly not even with a warning prompt 13:33:39 <04dracoomega> (I mean, it was an era where you could use Vampiric Draining on a demon and injure yourself badly without a prompt, also) 13:34:09 <11Odds> I'm glad I missed that era 13:34:44 <04dracoomega> The message for doing this was something like YEARGHHHHH!!! 13:35:47 <11Odds> I guess the thing to do here would be to have some kind of "monsters can't go here" function that replaces some uses of solidity (which I guess is mostly being used when we don't have a monster yet) 13:35:48 <04dracoomega> My mistake, it was apparently "Aaaarggghhhhh!" 13:35:59 <04dracoomega> Pulling up the history 13:36:05 <11Odds> Or just don't bother making it unsolid and fix the beam thing, which is probably easier or at least less error prone 13:36:38 <04dracoomega> can_pass_through_feat() is another thing that might be relevant here 13:36:51 <04dracoomega> Slightly different than is_habitable() (in ways that were confusing at first, tbh) 13:36:54 <11Odds> That one already rejects monsters in gateways as it happens 13:37:27 <11Odds> (On the players side, feat_is_traversable is another relevant one) 13:37:49 <04dracoomega> This sounds just slightly more unclear than it ought to be 13:40:04 <11Odds> Yeah, I think it's just a new case because we've not had any non-solid tiles actors aren't allowed in before 13:40:39 <11Odds> So we're conflating that with solid in various places 13:41:02 <11Odds> (And then there's habitable vs passable, which are different similar enough to confuse) 14:25:51 <11Odds> @dracoomega did you feel strongly that gateways shouldn't be solid? I'm currently inclined to fix this bug some other way (like making the reversion of terrain a fineff, most likely), because making solid things that monsters and players can't go to is fiddlier than expected 14:26:25 <04dracoomega> I thought that was decided at the time mostly because it seemed like it would be less work 14:26:46 <04dracoomega> I don't have any strong feelings about whether it should or shouldn't be solid otherwise 14:27:02 <04dracoomega> It seems pretty low-impact most of the time 14:27:13 <04dracoomega> (Even if it actually worked properly, apparently ^^; ) 14:27:15 <11Odds> Cool, I shall do the version I now think is less work 🙂 14:27:21 <04dracoomega> Be my guest! 14:27:40 <11Odds> (And also causes many fewer expected bugs) 15:32:27 03CrawlOdds02 07* 0.35-a0-1039-gcbae639cbf: Fix a tentacle beam crash 10(34 minutes ago, 3 files, 33+ 1-) 13https://github.com/crawl/crawl/commit/cbae639cbf63 15:43:42 Unstable branch on underhound.eu updated to: 0.35-a0-1038-gaffa9b99c3 (34) 16:16:42 <11Odds> Hmmmmm. I wonder what the talisman table should display for the minimum row for a -2 death talisman, when you can't reach the minimum requirements and will always have an HP penalty 16:25:53 <04dracoomega> Probably should still be 27? Even if the HP always has a penalty on that line. 16:26:01 <04dracoomega> (Maybe an additional asterisk. Unsure.) 16:26:42 <11Odds> Yeah I think it's just 27 and it's a weird "minimum" 16:26:42 <04dracoomega> Mind you, I had already debated to myself whether a death talisman should ever generate normally which causes this situation 16:26:56 <11Odds> Right, these are not going to be very popular 16:27:15 <04dracoomega> Finally, an appropriate trade-off for extended 16:27:41 <04dracoomega> (Mostly, I haven't focused too hard on whatever the state of death form in extended until after extended gets all its big changes) 16:28:00 <04dracoomega> I'll see what I think again after the dust has settled on all of that 16:46:54 <02Darby> is true, "talisman which is now explicitly weak against half of extended" 16:52:34 I'm looking at the documentation in the README for the monster yaml definitions and I'm wondering at a certain line... for the `energy` field, it claims that a key of `move` "is a shorthand which sets both `EUT_WALK` and `EUT_SWIM`", but in energy-use-type.h there exists no enum named EUT_WALK, only EUT_MOVE, and in attempting to search around to 16:52:34 see where EUT_SWIM gets used a comment implies that this has been superceded by a new field named `SWIM_ENERGY`, and of course grep finds no such matching string anywhere in the codebase :P so I guess I'm just wondering, *does* adjusting the default energy value of `move` actually affect swim speed? 16:54:37 Easy enough to check in wizard mode? 16:57:01 But also I'd check the point where monster definitions moved into yaml 16:59:08 and eg 'git log -GSWIM_ENERGY' which I think will show it was a #define in mon-data.h before that. 16:59:08 spawning monsters in wizmode seems to suggest that a key of `move` alone has no effect on swim speed 16:59:32 Try having added a monster with an absurd value 17:00:52 so the next question is, is this intentional? I see no monster definitions which have *both* an energy entry of move and swim, so if there was a monster that should have previously have both, it might not now. on the other hand, `speed` is its own key in the monster defs, so maybe that's taken its place? for example, an adder has 130% move speed 17:00:53 just from its speed, and then 216% (energy swim 6) 17:00:56 I'll do so 17:00:58 To be clear, not saying you haven't found a bug here, just suggesting stuff to check. But I must drop. 17:01:46 either way, I think I've sufficiently proven to myself that the README is mistaken, so I'll correct that 17:01:55 Thanks 17:15:16 hm, somewhat confusing that, for speed, higher is better, then for energy lower is better, but in the UI both are rendered such that higher is better 17:15:34 I think gretell is also confused about this... @? for a juggernaut shows an attack speed value of 450%, when in-game this is 33% 17:27:19 fun fact, merfolk impalers are the only monster that has multiple entries for energy (attack and swim) 17:56:13 also, the test spawner, despite being stationary, has a 233% swim speed 19:01:28 there are no monsters with rElec-, but in my testing the UI at least appears to properly put an x on their rElec when you give them such. haven't verified if that actually works though... 19:16:10 weirdly, despite the fact that resists for monsters go up to 4, a value of 3 is enough for immunity, and there's no way to get, for example, rF+++, only rF++ and rF+ and rF- 19:22:31 for miasma, despite the fact that it allows positive values up to 4, as far as the UI is concerned there's only "resistance", not immunity 19:23:52 the configuration code allows for explicit torment immunity to be assigned, but no monsters actually do this, presumably all inheriting their immunity from their holiness 19:29:16 immunity to petrification doesn't appear to show up in the xv screen 19:52:29 <04dracoomega> Back when damnation was hellfire, rHellfire was internally rF++++ 20:01:09 I also imagine they all end up implemented as (the same) multilevel even when not or not using all of them 20:01:14 crawlcode… is 20:03:10 <04dracoomega> Well, this is internal encoding of monster base resists, I think? Stuff like monster::res_fire() won't return more than 3 under any circumstance. 20:04:02 won't _return_ but may well _store_ the same amount for any resist because someone lazily(?) used the same code for all of them underneath? 20:05:26 <04dracoomega> Monster base resists are basically stored as a bitfield (with some resists getting multiple bits and some being binary) 20:06:32 <04dracoomega> Hmm... why do we have major version tags for resist flags here? Do we ever marshall this anywhere? 20:07:16 <04dracoomega> Given that several ones were just outright removed, while others just dummied, I wonder if different people just made different assumptions here? 21:20:55 03WizardIke02 07* 0.35-a0-1040-g24e62450d4: Fix wizmode local placement sometimes giving incorrect tiles 10(51 minutes ago, 3 files, 43+ 34-) 13https://github.com/crawl/crawl/commit/24e62450d4d9 22:11:36 <08o____0> Game crashes when you kill kirke in debug mode (only with pigs alive so &m kirke band). It's hitting the die in dbg-scan.cc line 484 here https://github.com/crawl/crawl/blob/24e62450d4d92b1837ac97dc222f1f345b4938d7/crawl-ref/source/dbg-scan.cc#L484 22:33:50 Unstable branch on crawl.develz.org updated to: 0.35-a0-1040-g24e62450d4 (34) 22:51:16 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-1040-g24e62450d4 23:29:41 Unstable branch on cbro.berotato.org updated to: 0.35-a0-1040-g24e62450d4 (34) 23:51:49 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-1040-g24e62450d4