00:35:08 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1889-g843a6e3170 (34) 02:41:58 <11Odds> While having fun with tracers, I've noticed that fuzz_invis_tracer - which intends to throw monsters' aim off when you are invisible - seems to do nothing at all; it resets the tracer target, but this gets undone by undo_tracer so the real bolt gets fired in the original direction (and indeed, if monsters know where you are with invis they never fire in the wrong direction). If that's right - should we just remove this, or is it desirable 02:41:58 behaviour we should fix? 03:10:35 <04dracoomega> I'm minutes away from bed, so I don't have a lot of followup to this, but I will say in a general sense that it might actually sell 'being invisible' in a more intuitive way if monsters did visually aim at slightly visibly incorrect spaces sometimes (so long as those spaces aren't shots that are actively doing friendly fire for no reason, of course). It's otherwise hard to get a sense of them 'casting slightly less often' (since 03:10:36 cast rate is always pretty random) and otherwise seeming to do what they normally do. (Newcomers in particular are often surprised at monsters appearing to behave 'normally' while unable to see them, even though invis is still currently fairly strong) 03:11:35 <11Odds> They do sometimes do that! But they do it because they target the wrong square (where you used to be, I think?) rather than because the tracer process messes them up. 03:12:26 <11Odds> But yeah, this fuzzing thing does also seem very reasonable 03:12:27 <04dracoomega> Okay, well then this sounds like an implementation issue that I can't comment on properly without taking a more careful look at the code in question ^^; 03:12:40 <04dracoomega> (And I am going to go sleep now) 03:12:49 <04dracoomega> But I will take a look at it tomorrow 03:13:05 <11Odds> Thanks, sleep well! 03:15:07 New branch created: pull/4984 (2 commits) 13https://github.com/crawl/crawl/pull/4984 03:15:08 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4984 * 0.34-a0-1889-ge70233a0c9: Make javelins pierce in monster tracers 10(9 hours ago, 1 file, 3+ 0-) 13https://github.com/crawl/crawl/commit/e70233a0c9f0 03:15:08 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4984 * 0.34-a0-1890-g18c35205b5: Fix more friendly fire issues with penetrating beams 10(9 hours ago, 1 file, 14+ 0-) 13https://github.com/crawl/crawl/commit/18c35205b5aa 04:32:11 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:35:57 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1889-g843a6e3 (34) 07:00:09 <11Odds> Looking into monsters targetting invisible players more, I think there are a few places which at least look like they are trying to interact with it: In mon-behv.cc: * There's a chance each turn for the monster to detect you and update your position (_monster_guesses_invis_player). Otherwise, it carries on targetting the last place it detected you. * If the monster reaches its target, it does a stealth check to find you again. * There's a 07:00:10 _guess_invis_foe_pos check, which would set the monster's target somewhere near you. But it doesn't trigger often (if ever) because it only goes off when the monster has a foe but their target is (0, 0). I can't see when that would happen. In beam.cc: * There's code to change the target of the tracer if you are invisible (fuzz_invis_tracer), which ends up having no effect because it doesn't affect the target of the real bolt. This all adds up to 07:00:10 something quite reasonable - the monster targets where it last saw you until it detects you somewhere else, and if it reaches where it expects you to be it looks for you again. And then there are the two bits of code which purport to fuzz monster targetting but actually don't (AFAIC - I'm fairly confident about the tracer one, but mapping all the possible states of monster behaviour is beyond my ken) 08:36:22 -!- jds_ is now known as jds 08:51:20 CrazyBamboolord (L1 OpRe) Crash caused by signal #6: Aborted (D:1) 09:49:20 <09gammafunk> > And then there are the two bits of code which purport to fuzz monster targetting but actually don't (AFAIC - I'm fairly confident about the tracer one, but mapping all the possible states of monster behaviour is beyond my ken) If you just assume that the crawlcode works properly, you'll never go wrong... 11:06:24 KimonoBoxFox (L15 DsHW) ERROR: range check error (-28 / 80) (Lair:5) 11:52:56 <04dracoomega> So, that first crash is something to do with parsing a string to display as a title in the inventory menu (and appears to lack enough info to do any diagnostics beyond that). The second one is odd, though. It's from a (possibly confused) elephant trampling while seemingly probably dead (it's at (0, 0) and thus the trample follow math is wrong, since it's extremely not adjacent to the target anymore). But the part that confuses me 11:52:57 is that there's a check for the attacker being alive immediately before the knockback code? Which makes it look like the elephant moved from a (perfectly sensible) attacking position to (0, 0) while not actually being dead? I have no idea how that could happen. But the log also has a bunch of hostile monsters dissolving into shadows in Lair, which feels like some additional problem... 11:58:20 <04dracoomega> Beyond just not affecting the real beam, I'm not sure that fuzz_invis_tracer() does anything reasonable even to the tracer. It's already picked a ray at this point, so changing the target won't even change that ray as it advances. And so probably has a cryptic and weird (if it even does anything) meaning. I don't think that's been touched in like 19 years... Incidentally, I glanced at the PR, and I can't help but think it might be 11:58:21 better to have the 'cap the number of players found' code after the part where it determines if the player is in fuzz range in the first place (or it'll do map find operations for trivially false cases constantly) mapping all the possible states of monster behaviour is beyond my ken (And don't worry; it's beyond anyone's.) 12:06:24 <11Odds> Yeah indeed it doesn’t change the ray advancing…. It might change a very minor thing about when the ray stops, but even that I don’t think happens in practice 12:06:38 <04dracoomega> Also, looking at the javelin tracer fix, I'm a bit concerned about how the tracer wasn't setting that properly, but the real beam was, and a brief investigation suggests that this setup_monster_throw_beam() function isn't even the one that mons_throw() itself uses, and I feel it would be good to investigate if there's any reason why (or if they can just share the same thing). 12:07:36 <04dracoomega> Like: 'verify that there aren't other things also missing' 12:08:05 <04dracoomega> mons_throw() handles it via _setup_missile_beam() 12:08:41 <11Odds> Yep, I saw that and sort of assumed tracers and real beams had to be quite different for some reason 12:08:48 <04dracoomega> They usually are not 12:09:01 <11Odds> Cool I’ll see if I can work out if there’s a good reason here 12:09:02 <04dracoomega> Ranged attacks are a little bit more complicated than most, but I wouldn't assume it was deliberate here 12:09:09 <04dracoomega> The other method seems to be much newer 12:09:30 <04dracoomega> (So it may have been a refactoring at some point which overlooked this?) 12:09:34 <11Odds> Which one is newer, the real beam one? 12:09:51 <04dracoomega> Yes 12:10:01 <11Odds> Thanks I’ll dig into it 12:10:15 <04dracoomega> Or at least it has had edits done to it in more recent years 12:11:32 <04dracoomega> (Dith shadow mimic also uses setup_monster_throw_beam() apparently, but it has its own extremely bespoke tracer logic. I am not sure it properly accounts for javlins penentrating either, though, on reflection. 12:11:58 <04dracoomega> It probably doesn't matter with how it picks targets anyway 12:12:07 <04dracoomega> I can't hurt allies, at the very least 😛 12:12:59 <04dracoomega> Okay, I say that and suddenly want to verify... 12:14:33 <04dracoomega> Sigh 12:14:38 <04dracoomega> Nope 12:14:42 <04dracoomega> It will javelin your allies too 12:15:11 <04dracoomega> (And would be unaffected by the fix in your PR) 12:18:29 <04dracoomega> Yeah, there's a couple issues here. (Dith throwing characters are, uh... not very popular, after all) 12:20:19 <04dracoomega> The penetrating thing will need a very Dith-centric solution here, though. (So possibly I ought to handle it) 12:21:26 <11Odds> Just to check, a version of my PR that changed things to uses the same method as monster_throw wouldn't make the Dith case either better or worse? 12:23:47 <04dracoomega> Yes 12:24:43 <04dracoomega> Shadow mimic is pretty involved, and often does a lot of pseudo-tracers to determine viable places to appear in, that other monsters do not. And at that point in time, it may not even exist or have a weapon yet. 12:26:14 <04dracoomega> (Like, it often does things in the general format of "Find all monsters in sight worth targeting, then all spaces near the player we could appear in, then fire tracers from each of those spots against each of those monsters and pick the best shot") 12:26:49 <04dracoomega> So the ranged attack tracer logic will need to check the player's weapon first, to see whether it's penetrating or not, and use that for all of its custom logic 12:26:57 <11Odds> Turns out no-one has ever actually use Dith throwing and had allies at the same time 12:27:04 <04dracoomega> Probably, yes 12:27:09 <04dracoomega> Like, it very probably has never happened 12:27:49 <11Odds> Cool - I'll fix up the PR for the non-Dith case as suggested, and have no immediate plans to look at Dith 12:28:01 <04dracoomega> (Even things like Storm Bow won't matter, since it uses an unbranded copy of your weapon, but javelins do) 12:36:04 <04dracoomega> Okay, re-reading that log, it looks like the elephant was created by a boggart's shadow creatures. The elephant killed a yak (also made by shadow creatures) and Usk pain bond from that killed the boggart, who was the yak's summoner, which caused the yak to die extra (ie: performing cleanup on it mid-action) and that was the thing at 0,0, not the elephant 12:37:40 <04dracoomega> I wonder if there is a reason that pain bond isn't handled by fineff, the way injury mirror is? (Though probably sanity-checking trample adjacency isn't a bad idea anyway) 13:40:37 <07wizardike> If you do make pain bond a fineff it would also fix https://github.com/crawl/crawl/issues/4580. What happens with this bug is that blork has two bats left, you hit the first one reducing it to 0 HP then pain bond kills the second bat which drops items because there aren't any other bats with HP then the first bat dies and drops items 13:41:14 <04dracoomega> Oh, huh 13:42:40 <04dracoomega> (In general, it feels that the way that pain bond can cause chains of effect can create a lot of unpredictable corner cases) 13:49:33 <04dracoomega> The chaining nature of it makes it trickier to do this way than it was for Injury Mirror, I guess 13:50:02 so do various other things that can cause chains of effects, sometimes not by intent (e.g. https://github.com/crawl/crawl/issues/3482) 13:51:46 <04dracoomega> Dispersal trap behavior should be at least a little bit better in a number of ways since the movement code refactoring (though I wouldn't go so far as to say that no possible issues remain >.>) 13:52:12 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4984 * 0.34-a0-1889-gf929f5c5fa: Make javelins pierce in monster tracers 10(19 hours ago, 3 files, 10+ 9-) 13https://github.com/crawl/crawl/commit/f929f5c5fae4 13:52:12 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4984 * 0.34-a0-1890-g5424e92ac0: Fix more friendly fire issues with penetrating beams 10(20 hours ago, 1 file, 17+ 1-) 13https://github.com/crawl/crawl/commit/5424e92ac0cb 13:54:16 I've fixed a couple of other such as well, mostly of the form "effect of spell A causes unrelated effect B to fire which causes the rest of A to crash" (e.g. https://github.com/crawl/crawl/pull/3327, https://github.com/crawl/crawl/pull/4077, and I know other people have fixed still others) 13:55:26 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4984 * 0.34-a0-1890-ge8089d0478: Fix more friendly fire issues with penetrating beams 10(20 hours ago, 1 file, 17+ 1-) 13https://github.com/crawl/crawl/commit/e8089d0478fd 13:55:31 crawl is just filled with these now, some of which may only cause unexpected effects instead of crashes 13:56:47 <11Odds> Sorry for the spam, silly whitespace. That PR now commonises the tracer with the mon-throw bolt, and reordered the logic of checking to be less wasteful. 13:57:44 s/causes/triggers/ 14:16:18 <04dracoomega> Currently looking at what other calls of monster::hurt() exist that defer death cleanup, and I am amused that the first I find is related to another commit fixing another pain bond bug >.> 14:18:07 <04dracoomega> (I am sort of wondering the most reasonable approach might not be to package each damage packet as a fineff - since there can be an awful lot of radiating and also some valid reasons to consider these monsters to be at 0 HP earlier - but instead creating some list of 'pending deaths' that can be cleaned up automatically at fineff timing) 14:19:28 <04dracoomega> Right now, deferred death cleanup has to be done manually by whatever caller defers it, and that's not really practical with how recursive pain bond is 14:24:11 <04dracoomega> I suddenly wonder if there's an argument that we should be doing that in general 14:25:10 <04dracoomega> ie: calling monster_die() in batches after complete effects are done 14:26:14 <04dracoomega> We are forever having new manifestations of "We tried to query some property on this monster, but it was already reset." and in theory that is a more general solution. (Though I am sure it is still imperfect, and also somewhat scary) 14:33:10 tbh I was wondering about that with one of those PRs as well 14:36:25 <04dracoomega> Doing things to dead monsters is usually safe, as well, so long as they aren't reset 14:36:39 <04dracoomega> At least, quite a lot of things 14:42:38 New branch created: pull/4985 (1 commit) 13https://github.com/crawl/crawl/pull/4985 14:42:38 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4985 * 0.34-a0-1890-ge1a399a714: Remove fuzz_invis_tracer 10(15 minutes ago, 2 files, 5+ 27-) 13https://github.com/crawl/crawl/commit/e1a399a714e0 14:46:45 <11Odds> Closing in on 5000 PRs! 15:02:39 <04dracoomega> That number includes bug reports, I'm pretty sure 15:04:38 <11Odds> Ah yes, they share numbers. Never knew that. 15:04:47 <04dracoomega> Also: isn't it redundant to even bother checking if we're within 2 spaces of the player's real location, since found_player() could only possibly return true if that was the case? 15:06:01 <11Odds> Not quite. Clouds can affect you even if the target is far away 15:06:38 <11Odds> And it does seem reasonable to me that monsters shouldn't take you into account in that case if you are far away 15:06:48 <04dracoomega> Oh, it's checking that the target is within 2 spaces of you, not pos() 15:07:11 <11Odds> Oh yeah and indeed piercing things can 15:07:37 <11Odds> Yeah, when I briefly read it as pos() I thought this whole function could go, but it is somewhat meaningful 15:07:49 <09gammafunk> you'd have to also include a count of all mantis patches merged 15:08:03 <09gammafunk> although you could do some slight git-fu to just count commits by those not on the dev team 15:08:05 <11Odds> Not if what I want is to see a round number! 15:08:16 <09gammafunk> you don't know what the cumulative number is! 15:08:24 <09gammafunk> it might be close to round 15:09:02 <09gammafunk> actually, now that I think about it, it's slightly non-trivial in that contributors might later join the dev team 15:09:29 <09gammafunk> but you could get close to a count of outside patches; of course, if you're counting PRs in the first place, those can come from existing dev team members 15:09:37 <09gammafunk> some like hellmonk prefer to make PRs when possible 15:11:00 <09gammafunk> hoping to have Santa deliver a working version of NewSequell by Christmas. might be able to get an initial prototype online tonight, at least for the purpose of tuning 15:12:18 <12ge0ff> have the user-defined functions, like !megaprogress, survived? 15:12:50 <09gammafunk> Dearest Santa, All I want for Christmas is fully optimised PostgreSQL queries that don't consume too much RAM or available CPU. Love, gammafunk 15:13:46 <09gammafunk> weirdly, the user db is the one sqlite db I don't have a copy of, although greensnark did say that he'd make some files I requested available (which includes said DB) when he next works on Sequell 15:13:51 <09gammafunk> but we do have 15:14:02 <09gammafunk> https://web.archive.org/web/20250724032208/https://loom.shalott.org/userdef.html 15:14:22 <09gammafunk> which is a recent snapshot of the userdef page (thanks to rypofalem triggering wayback for that url) 15:14:33 <09gammafunk> so although it will be tedious, we can recreate userdef 15:14:45 <09gammafunk> and of course there's tons of junk in there we don't actually have to recreate etc 15:15:04 <09gammafunk> but for nicks and learndb I have the latest snapshots, and of course we have the logfiles/milestones 15:15:44 <09gammafunk> oh, actually that's another we don't fully have: all the milestone files for servers that are no longer online 15:16:05 <09gammafunk> sequell's backup of those is likewise unavail (although snark will provide them hopefully if he ever brings shalott.org back) 15:16:24 <09gammafunk> and I do seem to be missing a logfile or two, possibly for cjr, since it doesn't see e.g. my full win streak 15:16:43 <09gammafunk> one route there might be to ask totalnoob for copies of what he has 15:17:12 <09gammafunk> if snark isn't able to get us anything. really not sure on greensnark's timeline for touching sequell stuff again, since it's been like 1.5 months.... 15:17:51 <09gammafunk> but the bottom line is once we have a bot online, we'll have or a way to get everything we need, with a couple teeny tiny asterisks 15:18:22 <09gammafunk> by the way ge0ff, are you familiar with postgres' approach to parallelization? 15:18:23 <12ge0ff> also, speaking about totalnoob, could i suggest inviting them to this discord? 15:18:33 <09gammafunk> yeah, we could do that for sure 15:19:12 <09gammafunk> the key to getting a reasonable response time for my postgres queries was lowering processor allocation cost (from arbitrary 1000 units to 0) 15:19:23 <09gammafunk> but the explain analyze of queries doesn't imply that it's even parallel 15:19:59 <09gammafunk> yet that seemed to provide a critical speed boost so I think it might be using multiple cores; I need to watch what it's doing on that longer query more carefully 15:20:39 <09gammafunk> it's doing a sequential search on index, and we have an index on basically every logfile field (ditto for milestones but I haven't tested milestone queries) 15:21:36 <09gammafunk> maybe we can get a few DB people to discuss scaleability things once we have a more working bot prototype and know what could be improved etc 15:22:20 <09gammafunk> but right now it's using a $100/mo 8 vcpu 16GB memory instance which is both pretty hefty for a stats bot and more than what community donations can cover 15:22:27 <12ge0ff> you mean cpu_tuple_cost? 15:22:35 <09gammafunk> that one and the other one 15:22:45 <09gammafunk> the primary one that isn't the tuple cost, I adjusted both to 90 15:22:48 <09gammafunk> er to 0 sorry 15:22:48 <12ge0ff> (cpu_index... something?) 15:22:53 <09gammafunk> uh one sec 15:26:37 <09gammafunk> shared_buffers = 4096MB # min 128kB work_mem = 20MB max_worker_processes = 15 max_parallel_workers_per_gather = 4 parallel_setup_cost = 0 # same scale as above parallel_tuple_cost = 0 # same scale as above random_page_cost = 1.0 # same scale as above; lowered because of SSD 15:26:47 <09gammafunk> @ge0ff I think all of the modified settings 15:27:12 <09gammafunk> max worker process is silly because that can't be more than like 8, I got confused there 15:27:22 <09gammafunk> but those parallel costs were what I was talking about 15:46:22 <12ge0ff> You can see if Postgresql uses more than one core for a query by running EXPLAIN (ANALYZE, VERBOSE) select ... and looking for "workers planned/launched" stats there. Also these two parallel_..._cost options don't guarantee that the planner will parallelize the query, because the query must follow a few rules. Like, it can't write/modify data, can't run inside another query, or can't use user-defined functions 16:00:25 <12ge0ff> (https://www.postgresql.org/docs/current/when-can-parallel-query-be-used.html) 16:22:30 <09gammafunk> Yes this is what I meant by: > but the explain analyze of queries doesn't imply that it's even parallel I used auto_explain with analyze enabled, and it didn't indicate that any workers were planned/launched. This was a SELECT COUNT(*)... (aggregate I think it's called?) query. There should be no write/modify, wasn't run inside another query, nor was user-defined function 16:22:58 <09gammafunk> But I can post a more complete summary of the explain/analyze and the online log analysis tool's summary (recommended by an AWS article) later 16:24:53 <09gammafunk> It doesn't look like I'm doing any of the things relevant/listed there. Well, and it should be said that it appeared that those parallel cost setting changes were important, because without those the query took much longer (like 100s vs 3-4s iirc) 16:25:25 <09gammafunk> But what I really need to do is get the public version fully set up so we can monitor these things across a range of queries etc 16:41:15 Unstable branch on underhound.eu updated to: 0.34-a0-1889-g843a6e3170 (34) 16:57:52 03WizardIke02 07* 0.34-a0-1890-g8863ff3150: Rework how equipped tiles are specified for artifacts 10(30 minutes ago, 4 files, 132+ 173-) 13https://github.com/crawl/crawl/commit/8863ff3150e2 17:07:23 <04dracoomega> @Odds This isn't anything incorrect you did, but testing your PR to remove the rounding to integer skill values in the talisman properties popup has made me realize that actually an awful lot of the properties themselves actually do round (down) to an integer skill >.> 17:07:41 <04dracoomega> (HP from low skill does not, but a lot of other things do) 17:08:10 <04dracoomega> Like, the 17 skill and 17.9 skill are identical as far as hive form is concerned. 17:08:24 <04dracoomega> And given how this is structured, I suspect it's a lot more widespread than that 17:09:23 <04dracoomega> This looks like a surprisingly simple thing to change in many cases, though. (Who knows if it will be for all of them?) 17:28:19 <04dracoomega> I feel I have made a math error somewhere 😛 17:28:19 <04dracoomega> https://cdn.discordapp.com/attachments/747522859361894521/1452457687928410143/image.png?ex=6949e222&is=694890a2&hm=0450e2c7bb8d1e4e6ccd0201d5bd60e5397b8964c7538bd3510e9bc79683ecc0& 17:28:59 <04dracoomega> You too can train 8 levels of shapeshifting to increase your unarmed base damage by less than 1% 17:30:10 <09gammafunk> hey, if you mean 140->146 that's more than 1%! 17:32:16 <02Darby> > You too can train 8 levels of shapeshifting to increase your unarmed base damage by less than 1% proof this form is undertuned 17:33:22 <04dracoomega> I assumed the player had some level of base UC of their own! 17:33:32 <09gammafunk> even then 17:33:43 <09gammafunk> for typical UC base values at least 17:34:29 <04dracoomega> Oh, right, I did the math wrong even when making a joke about doing the math wrong 17:34:30 <04dracoomega> Wow 17:34:42 <09gammafunk> further proof of how much we desperately need NewSequell: I can't run !calc to show DO exactly how much of a percentage 6/N is! 17:34:53 <04dracoomega> (Okay, sure, ~4% :P) 17:35:24 <09gammafunk> I am a bit curious about body armour AC being +0 but....-100%? 17:35:52 <04dracoomega> The character's not wearing any body armour at the moment, so it has no effect 17:36:01 <04dracoomega> And 0 gets a + rather than - 17:36:09 <02Darby> setting your AC to 0% of what it was, which was also 0 17:36:31 <09gammafunk> well how is that -100% then? 17:36:53 <04dracoomega> Well, it would reduce your body armour AC by 100%. It's just the player doesn't have any right now. 17:37:11 <09gammafunk> oh that's what this percentage means, I see 17:37:23 <04dracoomega> Somewhat less confusing in a more realistic scenario 😛 17:37:33 <09gammafunk> yep 18:54:36 <09hellmonk> is this a scale problem? 19:08:49 <04dracoomega> Kinda. I mostly have it fixed now, I think (along with a little light refactoring) 20:21:33 03WizardIke02 07* 0.34-a0-1891-gbf00e4143a: Rework choosing tiles for items 10(88 minutes ago, 12 files, 1075+ 733-) 13https://github.com/crawl/crawl/commit/bf00e4143af7 20:33:58 <09gammafunk> reading sequell's perl code is enough to make you grateful to work with crawlcode 20:37:52 04Build failed for 08master @ bf00e414 06https://github.com/crawl/crawl/actions/runs/20420723521 20:37:53 <09gammafunk> perl sub _authorize_relay { my ($self, $m, $change) = @_; my $auth = $self->{auth}; if ($$change{readonly}) { $$m{relayed} = 1; $$m{proxied} = 1; $$m{readonly} = 1; return 1; } my $auth_req = Henzell::ACL::has_permission('proxy', $$m{nick}, $$m{channel}, $auth && $auth->nick_identified($$m{nick}), 20:37:54 'deny'); if ($auth_req && $auth_req eq 'authenticate' && $auth && !$$m{reprocessed_command}) { $self->authenticate_command($m); return 0; } if (!$auth_req || $auth_req ne 'ok') { $$m{relayed} = 1; $$m{proxied} = 1; return 1; } 1 } this function is called when !RELAY command is given and must return 1 otherwise, !RELAY will be ignored as a relay command. Henzell::ACL::has_permission(...) returns "ok" if they have 20:37:54 permission for relay, "authenticate" if the user would have permission if they were IRC authenticated (but they arent'), otherwise undef. So what does this function do if they do have permission for relay? 20:44:25 <09gammafunk> (the answer is that it pretends the relay/proxy didn't happen and returns 1) 20:44:38 need more context but it looks to me like $m is a REF message, if they're authenticated for relay it sets the relayed and proxied atttributes in the message, then I have no idea but some guesses what authenticate_command does. 0 if permitted, else 1. 20:45:15 <09gammafunk> that's the thing, if they're authenticated for relay it doesn't set those attributes 20:45:50 <09gammafunk> so that it won't later be rejected (because relayed and proxied commands aren't permitted to modify the DB) 20:46:05 <09gammafunk> so it's a hack to allow edits when "readonly" isn't set (and the user is properly authenticated) 20:46:31 <09gammafunk> I spent like 10 minutes staring at this trying to figure out why the logic seemed to be inverted 20:46:52 ah 20:47:12 (admittedly I was finding it hard to read because it's really crappily formatted on this end) 20:47:20 <09gammafunk> oh, haha, true 20:47:37 <09gammafunk> never did make the bridge format those code blocks in a nice way 20:47:43 <04dracoomega> Frankly, attempting to read any perl code makes me grateful even for C++ 20:47:59 <09gammafunk> yes, a lot of it's fine, but it's the conciseness that I really hate 20:48:07 <09gammafunk> there's a really really good one in here that just boggled me at first 20:49:46 <09gammafunk> perl return map { +{%$_, reprocessed_command => 1} } @$msgs; 20:50:21 <09gammafunk> msgs is an array of hashes (key-value data structure), map is the function that applies a function to a list, per usual 20:51:15 <09gammafunk> this is applying a function that (I think) applies the + operator to the argument, taken as a hash, so that it can add a key of reprocessed_command with the value of 1 to this hash 20:51:22 each hash being augmented with reprocessed_command, and the + deals with a syntactic ambiguity 20:51:42 <09gammafunk> yeah but exactly how +{...} works is confusing 20:51:59 <09gammafunk> I'm sure this is common perl idiom and you can figure it out eventually without perl doc 20:52:37 {%$_, reprocessed_command => 1} just adds the setting of reprocessed_command to the hashref. the + is because the { is ambiguous, you need the + to make it a value and not a code block iirc? 20:52:53 <09gammafunk> heh, yeah seems o 20:53:04 <09gammafunk> I thought it was the application of the + function tbh 20:53:53 in a sense it is, but unary + is a no-op. so the purpose it's serving is that of making the inner {} be a value 20:54:19 perl has a few syntactic oddities that require hacks like unary + to avoid 20:54:22 <09gammafunk> so I guess you could use any no-op to do that 20:54:41 right, but unary + is always a no-op so it's conventional 20:55:05 <09gammafunk> anyhow I'm not exactly going to rewrite perl out of sequell any time soon since all of its implementation of learndb and ACLs and IRC depend on it. Moving the irc side to python would be doable and would gain e.g. SASL support, but the learndb/ACL stuff would be more work 20:55:09 (to the point that if you examine the generated code, which you can if you know what you're doing, it's not even there) 20:55:39 <09gammafunk> one thing I do need to is see if we can determine whether a user is authorized on libera without messaging nickserv 20:55:55 03WizardIke02 07* 0.34-a0-1892-g162c21ee31: Fix the build 10(67 seconds ago, 3 files, 4+ 3-) 13https://github.com/crawl/crawl/commit/162c21ee312f 23:01:59 <11Odds> Yeah, I looked at the main one and I think EV was rounding and AC HP and damage were not. I did mean to fix that or raise it here, but I think it’s independent of the display issue? 23:02:24 <04dracoomega> It is - the display thing merely revealed it. 23:02:37 <04dracoomega> But I have also fixed it and am going to push that and some of the invis tracer stuff in a moment 23:06:39 New branch created: pull/4986 (1 commit) 13https://github.com/crawl/crawl/pull/4986 23:06:40 03RypoFalem02 07https://github.com/crawl/crawl/pull/4986 * 0.34-a0-1890-g8a4ee4470a: fix: missing newline in spell descriptions 10(8 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/8a4ee4470af7 23:08:54 03CrawlOdds02 {DracoOmega} 07* 0.34-a0-1893-g15d368e031: Fix preview of talisman attributes between integer skill levels. 10(34 hours ago, 1 file, 9+ 6-) 13https://github.com/crawl/crawl/commit/15d368e0313b 23:08:54 03DracoOmega02 07* 0.34-a0-1894-ge339c7e1a8: Fix dragon form breath damage being wrong in the talisman preview 10(4 hours ago, 2 files, 8+ 4-) 13https://github.com/crawl/crawl/commit/e339c7e1a82d 23:08:54 03DracoOmega02 07* 0.34-a0-1895-g22750ce800: Fix many talisman properties not scaling between integer skill levels 10(3 hours ago, 2 files, 32+ 33-) 13https://github.com/crawl/crawl/commit/22750ce800d3 23:08:54 03CrawlOdds02 {DracoOmega} 07* 0.34-a0-1896-g8ea545e54a: Make javelins pierce in monster tracers 10(29 hours ago, 4 files, 9+ 24-) 13https://github.com/crawl/crawl/commit/8ea545e54a55 23:08:54 03CrawlOdds02 {DracoOmega} 07* 0.34-a0-1897-g2f1e48cfaa: Remove fuzz_invis_tracer 10(9 hours ago, 2 files, 5+ 27-) 13https://github.com/crawl/crawl/commit/2f1e48cfaadd 23:08:54 03CrawlOdds02 {DracoOmega} 07* 0.34-a0-1898-g445b766777: Fix more friendly fire issues with penetrating beams against unseen players 10(29 hours ago, 1 file, 17+ 1-) 13https://github.com/crawl/crawl/commit/445b76677758 23:08:54 03DracoOmega02 07* 0.34-a0-1899-g04f1e15178: Some further improvements to tracers against invisible players 10(7 minutes ago, 2 files, 58+ 37-) 13https://github.com/crawl/crawl/commit/04f1e151784a 23:27:25 <11Odds> I wonder whether talisman display should really be showing non-integer values rather than rounding them down when we have random rounding 23:27:43 <04dracoomega> Most of those things are at scales that don't require random rounding (and they don't do any, anyway) 23:28:10 <04dracoomega> Stuff that uses very small numbers, like some of the UC damage scaling and aux damage do round randomly 23:28:37 <04dracoomega> (EV bonus may be the main current exception to that?) 23:29:14 <04dracoomega> Likely since the part of the EV calculation code that it plugs into can't take values with a scale less than 1-to-1 without some rewriting 23:29:26 <11Odds> Yeah EV and AC are the main culprits - AC returns a scaled value to the display code which then rounds it, and EV randomly rounds. Maybe it shouldn’t though? I expect there’s other random EV and we should round them together? 23:29:29 <04dracoomega> Like, the part where player evasion is calculated in general, I mean 23:29:56 <04dracoomega> I don't think there's anything wrong with AC? It effectively returns AC * 100 to the AC formula (which does use it at that scale) 23:30:19 <11Odds> Indeed - the display code then just rounds that to an integer 23:30:29 <11Odds> That could be fixed just in display.cc 23:30:48 <04dracoomega> Oh, that the talisman info menu specifically doesn't show the fractional part 23:30:55 <04dracoomega> Rather than it not operating like that 23:31:05 <04dracoomega> (Probably something could be done there, yes) 23:31:28 <04dracoomega> Like, theoretically, EV 'ought to be' adjusted likewise, but it would involve fiddling with a few more things 23:31:53 <11Odds> Yep, may well not be a priority 🙂 23:33:13 <04dracoomega> (Personally, I felt like there was always a sufficient number of other things getting fractional benefit from the shapeshifting skill that a theoretical EV breakpoint wasn't terribly important) 23:35:40 Unstable branch on crawl.develz.org updated to: 0.34-a0-1899-g04f1e15178 (34) 23:58:27 Windows builds of master branch on crawl.develz.org updated to: 0.34-a0-1899-g04f1e15178