01:23:03 <10P​leasingFungus> post-tournament question: WDYT about moving mobile 8s (crystal guardian, guardian golem, iron golem, electric golem, toenail golem, spellforged servitor, ushabti, peacekeeper, saltling) onto 9 (currently war/molten/'' gargoyle)? 01:24:29 <10P​leasingFungus> currently there are 22 monsters on 8 (counting a few weird special cases) and 3 on 9; this would result in there being 16 monsters on 9 and 9 monsters on 8 01:24:34 <10P​leasingFungus> which feels like a better split 01:26:17 <09h​ellmonk> ruins my 8675309 vault, sorry cant do it 01:26:37 <10P​leasingFungus> why was demonspawn afraid of animated tree 01:26:47 <10P​leasingFungus> because tree golem gargoyle 01:34:34 Unstable branch on crawl.develz.org updated to: 0.28-a0-69-g49dcd67cf8 (34) 01:55:38 Windows builds of master branch on crawl.develz.org updated to: 0.28-a0-69-g49dcd67cf8 02:03:50 -!- mhcerri3 is now known as mhcerri 02:26:20 Unstable branch on cbro.berotato.org updated to: 0.28-a0-69-g49dcd67cf8 (34) 02:51:47 <09g​ammafunk> !nchoice 02:51:48 <04C​erebot> Time for a new nchoice! It will appear shortly on the tournament website (if it hasn't yet). Type "=nemelex XXXX" to update !nchoice with the new combo, where XXXX should be replaced by the new combo. 02:52:42 <09g​ammafunk> !nchoice 02:52:46 <04C​erebot> HuAM: 0 wins || dracos369: CUE, L9 Shooter of Vehumet || tlilden78: CAO, L1 Vexing of No God || unihiutale: CXC, L1 Vexing of No God 02:53:49 Monster database of master branch on crawl.develz.org updated to: 0.28-a0-69-g49dcd67cf8 03:12:58 Stable (0.27) branch on cbro.berotato.org updated to: 0.27.0-1-g7a089689b8 03:30:52 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-4217-g7c68dc2372 04:17:51 -!- allbery_b is now known as geekosaur 06:26:06 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-4217-g7c68dc2372 08:20:26 tormodpwns (L16 VSFi) ERROR in 'tileweb.cc' at line 229: Socket write error: Resource temporarily unavailable (D:12) 08:20:29 LeafClover (L18 MfEn) ERROR in 'tileweb.cc' at line 229: Socket write error: Resource temporarily unavailable (Shoals:4) 08:30:53 -!- allbery_b is now known as geekosaur 08:34:36 <12e​bering> uhoh 08:34:42 <12e​bering> @gammafunk are you still awake 08:35:58 dang CAO seems like it's totally offline 08:44:14 New branch created: pull/2049 (1 commit) 13https://github.com/crawl/crawl/pull/2049 08:44:14 03robertxgray02 07https://github.com/crawl/crawl/pull/2049 * 0.28-a0-44-g3973157e3a: AppImage support 10(3 days ago, 6 files, 188+ 4-) 13https://github.com/crawl/crawl/commit/3973157e3a53 09:14:45 03robertxgray02 07https://github.com/crawl/crawl/pull/1892 * 0.28-a0-72-g91ee094a69: Move Android related ignores to crawl-ref/.gitignore 10(6 minutes ago, 2 files, 8+ 16-) 13https://github.com/crawl/crawl/commit/91ee094a69bc 09:30:02 Ashenzari info leak 13https://crawl.develz.org/mantis/view.php?id=12619 by Yermak 10:24:52 Webtiles server stopped. 10:27:03 Webtiles server started. 10:27:36 I've restarted cao 10:27:40 also turned off scoring for now 10:28:52 will try to restart it later; I think last time it was possible to leave it running with a better nice, maybe I'll also adjust the download interval or something 10:32:12 <06a​dvil> not sure what happened except that it seems to have gone into a tight loop where a stream closed exception gets raised continuously, 2021-07-31 08:18:58,218 WARN: #4366 Exception during async write_message 2021-07-31 08:18:58,219 WARN: #4366 Stream is closed Traceback (most recent call last): File "/chroot/crawl-master/webserver/ws_handler.py", line 942, in after_write_callback File 10:32:12 "/home/crawl-dev/tornado-4.5.3/tornado/concurrent.py", line 238, in result raise_exc_info(self._exc_info) File "", line 3, in raise_exc_info StreamClosedError: Stream is closed 10:35:55 <06a​dvil> this is one of those things where if it were possible, it would be more profitable to just simply switch to using the asyncio branch than debugging callback-based code 13:02:05 Stable (0.27) branch on crawl.akrasiac.org updated to: 0.27.0-1-g7a08968 13:07:58 Unstable branch on crawl.akrasiac.org updated to: 0.28-a0-69-g49dcd67 (34) 14:51:05 <06a​dvil> bolt::determine_affected_cell seems to have some really large polynomial blowup with the size of the radius 14:51:49 <06a​dvil> I'm not really sure what all it's doing, most of what it calculates in the count values doesn't seem to get used 15:09:34 <09g​ammafunk> @advil figures that it's the culprit. I spent a while reading that code recently just to understand how the DFS algorithm worked after someone asked about it, which was useful when worms mentioned the LRD targeting display problem I fixed recently. It's a recursive method that's not trivial to understand 15:11:00 <06a​dvil> it definitely recurses back to cells it's seen before, many, many times in the case of firestorm 15:11:36 <06a​dvil> hm, was there a time where some explosion effect in crawl had a gradient effect depending on distance from the center? 15:12:11 <09g​ammafunk> in terms of damage falloff? 15:12:21 <06a​dvil> or something like that 15:12:25 <10P​leasingFungus> can’t think of one 15:12:33 <09g​ammafunk> there was glaciate but I don't think that logic was plugged in via beam 15:12:38 <10P​leasingFungus> yeah 15:12:41 <06a​dvil> it's also possible that the check commented with // Is that cell already covered? is just wrong, not sure 15:12:42 <10P​leasingFungus> ditto ice storm 15:13:05 <09g​ammafunk> ice storm was I think the same type of beam explosion as firestorm, and had no falloff effect 15:13:15 <10P​leasingFungus> sounds right 15:13:18 <09g​ammafunk> it had a variable explosion radius probably 15:14:52 <09g​ammafunk> yeah that condition does look suspicious, now that you mention 15:15:11 <06a​dvil> keep in mind that untouched cells are actually INT_MAX 15:15:12 <09g​ammafunk> oh, right this inits to INT_MAX 15:15:14 <09g​ammafunk> right 15:15:31 <09g​ammafunk> but then probably it only wants to check that the count is < INT_MAX? 15:15:44 <06a​dvil> yeah, I'm not quite sure what count is actually calculating 15:15:54 <09g​ammafunk> maybe the count can improve via a better path 15:15:59 <06a​dvil> why do we add 0, 5, or 17 to it 15:16:06 <09g​ammafunk> ah, so that I can explain 15:16:52 <09g​ammafunk> it uses zero when moving from center-adjacent location to another center-adjacent location 15:17:02 <09g​ammafunk> that's what that "circling around the center" comment is referring to 15:17:25 <09g​ammafunk> and here center refers to the center of the explosion 15:18:15 <09g​ammafunk> the explosion algorithm simply doesn't want to penalize propogation of explosion in through those (up to) 8 tiles 15:18:47 <06a​dvil> ah, this is all to do complicated things in non-open space? 15:19:01 <09g​ammafunk> 5 is the penalty of propogation for movement that doesn't "reverse" the recently taken x or y direction 15:19:08 <09g​ammafunk> and 17 is the penalty for propogation that does 15:19:09 <09g​ammafunk> yes 15:19:20 <09g​ammafunk> it defines the rules for how explosions move around walls 15:20:58 <09g​ammafunk> well it defines the rules for non-walls, but the idea is that walls stop explosion propogation (even for explosions like fragmentation that center on a wall tile, although the tiles surrounding the wall get free propogation by that "circle" exception) 15:21:21 <09g​ammafunk> this count is checked against an allowed value calculated from the explosions radius 15:22:39 <09g​ammafunk> cpp // A bunch of tests for edge cases. if (delta.rdist() > centre.rdist() || delta.rdist() > r || count > 10*r || !map_bounds(loc) || is_sanctuary(loc) && flavour != BEAM_VISUAL) { return; } this calls that count check an "edge case" but it's pretty fundamental to the algo 15:31:33 <06a​dvil> maybe it means "edge" more literally 15:32:02 <06a​dvil> I have a theory for how to fix it but this is so complicated it's a bit hard to tell 15:32:36 <06a​dvil> possibly instead of checking m(new_delta + centre) <= count it should first calculate cadd and check m(new_delta + centre) <= count + cadd 15:33:22 <06a​dvil> because the cases where it's re-recursing are ones where on the basis of count it looks like there's an opportunity for improvement but there actually isn't because cadd is 5 15:38:11 <09g​ammafunk> aha 15:38:13 <09g​ammafunk> sounds promising 15:38:24 <09g​ammafunk> well, if it helps, I set up things like 15:38:58 <09g​ammafunk> https://cdn.discordapp.com/attachments/205316046230388737/868198533101129728/unknown.png 15:39:03 <09g​ammafunk> to understand propogation better 15:39:24 <09g​ammafunk> like there it hits the X to the NW of the green crystal but not to the N 15:40:41 <09g​ammafunk> if you replace that green crystal with rock and lrt that square, it should hit both X and an addition one to the NE (due to that "circling" behaviour) 15:41:30 <09g​ammafunk> I guess I should specify that "it hits" in that first description means the fprism explosion, not lrd 15:43:18 <06a​dvil> well, that is better and the explosion shape looks the same, but the recursion is still not right 15:46:39 <06a​dvil> oh, maybe it's also that the targeter calls this a billion times 15:53:08 <06a​dvil> very odd firestorm shape, but this is what happens currently: 15:53:09 <06a​dvil> https://cdn.discordapp.com/attachments/747522859361894521/871118303169478696/Screen_Shot_2021-07-31_at_3.52.22_PM.png 15:56:11 <10P​leasingFungus> that’s extremely odd 15:58:15 03kate-02 07* 0.28-a0-70-gdd8709b231: Fix poison-vulnerable monsters displaying as meph immune 10(13 seconds ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/dd8709b23151 16:00:52 -!- allbery_b is now known as geekosaur 16:01:46 <06a​dvil> ah, target finding is doing some fairly brute-force searching in the case of explosions, which leads to a lot of these calls 16:02:37 <06a​dvil> in directn.cc code of the less comprehensible type 16:02:37 Unstable branch on crawl.kelbi.org updated to: 0.28-a0-70-gdd8709b231 (34) 16:04:47 <06a​dvil> maybe ok if this isn't multiplying with bad recursive code, I at least don't get a noticeable lag on local tiles any more 16:05:03 <06a​dvil> but I never replicated the conditions for a multi-second lag either (maybe lots of monsters around) 16:05:28 <09g​ammafunk> for me it was completely open los and high spellpower so that the radius was larger 16:05:44 <09g​ammafunk> also I guess your system is a lot faster than this old laptop 🙂 16:06:01 <06a​dvil> yeah I get a log under those conditions but it was more like in the 100s of ms 16:06:02 <06a​dvil> ah fair 16:06:33 <10P​leasingFungus> imagine using an old laptop instead of buying a new top of the line desktop every week 16:06:34 <10P​leasingFungus> 5hed 16:07:03 <06a​dvil> about 300ms measured in a profiler on on my M1, so that would likely be a lot worse yeah 16:07:08 <09g​ammafunk> advil was talking about this mysterious M1 thing so much I had to google what it meant 16:07:13 <10P​leasingFungus> heh heh 16:07:41 <10P​leasingFungus> it's short for magic 1, the number of potions of magic included free with every purchase of a new mac 16:09:00 <06a​dvil> with this change I'm seeing cpu bursts of my like 60ms on popping up the targeter, which I can't say is perfectly ideal 16:09:08 <06a​dvil> *more like 16:10:47 <06a​dvil> although now that I look down the call tree I think this is UI time 16:11:03 <09g​ammafunk> regarding that firestorm explosion targeter, it may be somewhat unclear from that picture, but some of that explosion is traveling out of los and is not rendered by the targeter 16:11:27 <09g​ammafunk> I don't think it would be even with x-ray vision, although x-ray vision will show you the full explosion animation so you can see affected cells 16:11:54 <06a​dvil> it still seems like it is discontinuous though 16:12:04 <06a​dvil> I will try with xray vision 16:12:21 <09g​ammafunk> is it actually accurate, the targeter vs explosion? 16:12:22 <06a​dvil> oh, there is a path back here 16:12:34 <06a​dvil> yeah, I did get an explosion in the upper cell once 16:12:39 <09g​ammafunk> ok 16:13:44 <06a​dvil> x ray vision apparently doesn't apply to targeters, but I think you are right that there is actually a continuous path for it to reach that cell via the notch above where I'm targeting in that screenshot 16:14:00 <10P​leasingFungus> is that an info leak? 16:15:24 <09g​ammafunk> yeah, it probably is 16:15:59 <09g​ammafunk> if you see the affected indicator it does tell you something about the lack of walls in certain places 16:16:44 <09g​ammafunk> and the "determine cells affected by explosions" code doesn't check about map knowledge or anything 16:18:31 <10P​leasingFungus> oop 16:18:40 <10P​leasingFungus> new tech 16:19:16 03advil02 07* 0.28-a0-71-g84acfa7270: fix: speed up explosion calculations (gammafunk) 10(4 minutes ago, 1 file, 4+ 4-) 13https://github.com/crawl/crawl/commit/84acfa727042 16:19:47 <06a​dvil> I thought explosions can't happen out of los any more? 16:20:24 <09g​ammafunk> no definitely do 16:20:34 <06a​dvil> ah, just clouds? 16:20:37 <12e​bering> just clouds 16:20:37 <09g​ammafunk> don't think there was any change in that regard to explosions, yeah 16:20:56 <12e​bering> I tried to implement beam clamping this go around but it had undesirable effects, but even that implementation didnt' touch explosions 16:23:18 <09g​ammafunk> oh, so now's probably a good time to bring up the thing which caused me to first look into this at all, which is something that became more prevalent with ash in the sense you could see it happening with x-ray vision 16:25:23 <09g​ammafunk> If you put a lil orc like so: https://cdn.discordapp.com/attachments/205316046230388737/868179295053443102/unknown.png 16:25:40 <09g​ammafunk> and target the far wall tile it's north of with lrd 16:25:57 <09g​ammafunk> it will sit there and just stare at the wall indefinitely as you lrd it from out of los 16:26:31 <09g​ammafunk> this is because it has traveled to the noise source it was seeking and has found it (the wall you are LRDing) 16:26:35 <09g​ammafunk> but now it has nothing to do 16:27:28 <09g​ammafunk> think this is probably only a problem with lrd, since anything else would have to target a floor tile, which would allow the orc to move to that floor tile, traveling around the wall to finally see you 16:28:16 <09h​ellmonk> Fuzz lrd noise location ig? 16:28:25 <09h​ellmonk> Not sure how else youd fix it 16:28:49 <09g​ammafunk> seems maybe like something where you might want to change monster AI wrt what it does with finding noise, but I'm not sure what 16:29:55 <09g​ammafunk> it could perhaps attempt to move to some location adjacent to noise location at random, but that would probably take too long on average for it to make it around the wall 16:30:27 <09g​ammafunk> I'm not sure if there are other kinds of degenerate cases where monsters get stuck like this 16:30:42 <06a​dvil> if it takes damage and can't see an enemy, moving might be a good idea 16:30:52 <09g​ammafunk> yeah 16:31:06 <06a​dvil> that's not a perfect solution because it might just move back 16:31:20 <09g​ammafunk> is there some simple logic that would make it prefer moving to that position taking it "around" the wall? 16:32:04 <09g​ammafunk> probably not 16:32:19 <09g​ammafunk> the could be getting manipulated this way from the far west, for example 16:32:25 Unstable branch on crawl.kelbi.org updated to: 0.28-a0-71-g84acfa7270 (34) 16:32:54 <06a​dvil> a variant of hellmonk's idea would be for monster ai to treat noise as fuzzed in a case like that, it gets stuck coming from some directions because the point source is in a wall I guess 16:32:56 <09g​ammafunk> I guess in that case said position would also be an improvement for the mosnter 16:34:05 <06a​dvil> maybe noise already is happening at every position in the explosion though 16:34:17 <10P​leasingFungus> i don't think it is 16:34:28 <10P​leasingFungus> ignition has code to only make noise at the centre of explosions 16:34:36 <10P​leasingFungus> which presumably is trying to emulate beams 16:34:45 <09g​ammafunk> right, the "effect" noise happening only at the target 16:35:37 <06a​dvil> I see, maybe for LRD it should be the other way around 16:36:06 <06a​dvil> hm, I wonder to what degree you can mess with out of los monsters in general by using lrd on a width 1 wall 16:40:19 <09g​ammafunk> you should be able to have them move over to one side of a wall with a tactical lrd and then run down the opposite side 16:40:54 <09g​ammafunk> probably especially easy to coordinate with ash 16:45:15 <06a​dvil> Although just shouting probably works 16:46:06 <06a​dvil> I remember having a qaz char with antennae or something and noticing a similar effect 17:16:29 <09g​ammafunk> !tstats 1 t0.26 17:17:45 <04C​erebot> Stats after 1 days (t0.26): 620 players, 173 runers, 106 winners, 139 wins, 3172 games, winrate 4.38%, total player time 65d+15:03:11. 17:18:01 <09g​ammafunk> !tstats 1 17:18:06 <04C​erebot> Stats after 1 days (t): 731 players, 166 runers, 90 winners, 124 wins, 4315 games, winrate 2.87%, total player time 65d+1:17:24. 17:18:21 <10P​leasingFungus> wow 17:18:24 <10P​leasingFungus> just discovered some deep lore 17:18:27 <10P​leasingFungus> // FINALLY! determine primary spell effects {dlb}: if (spell_cast == SPELL_BLINK) { // Why only cast blink if nearby? {dlb} if (mons->can_see(you)) { mons_cast_noise(mons, beem, spell_cast, flags); monster_blink(mons); } 17:18:48 <10P​leasingFungus> powerful special casing 17:19:07 <10P​leasingFungus> more players, fewer winners? i approve 17:19:31 <09g​ammafunk> yeah, looks promising @ebering 17:19:37 <09g​ammafunk> re: tstats 17:19:40 <09g​ammafunk> obv only first day 17:19:58 <12e​bering> nice 17:20:12 <09g​ammafunk> hrm, so that disallows casting blink if the player is invisible? 17:21:48 <10P​leasingFungus> or out of LOS 17:21:55 <10P​leasingFungus> e.g. if the monster is fighting a summon or something 17:22:06 <10P​leasingFungus> both very weird 17:22:10 <10P​leasingFungus> also extremely weird that this is uh 17:22:15 <10P​leasingFungus> nowhere near the functional logic of any other spell 17:23:38 <10P​leasingFungus> // FINALLY! determine primary spell effects {dlb}: if (spell_cast == SPELL_BLINK) { // Why only cast blink if nearby? {dlb} if (mons->can_see(you)) { mons_cast_noise(mons, beem, spell_cast, flags); monster_blink(mons); } else return false; } ... // other blink spells go here else { ... // 17:23:39 (battlesphere stuff goes here) mons_cast(mons, beem, spell_cast, flags); // every other spell's logic goes here ... // (more battlesphere stuff here) } 17:26:51 <09h​ellmonk> How does this relate to blink away / blink range 17:26:59 <10P​leasingFungus> they're in the "... other blink spells go here" bit 17:27:04 <10P​leasingFungus> the funny thing is that they're bugged 17:27:13 <09h​ellmonk> Lmao awesome 17:27:15 <10P​leasingFungus> they're supposed to create noise (a tiny amount! 2 noise!) on cast 17:27:32 <10P​leasingFungus> but because they have this custom logic, they completely skip all the noise stuff 17:27:44 <10P​leasingFungus> wouldn't be surprised if there are other issues too 17:29:54 <10P​leasingFungus> @hellmonk also, most of the way through implementing living spells & walking tomes. going to hand you a bunch of different types to play with and let you tweak numbers, etc as you see fit 17:34:21 <09h​ellmonk> Poggers 17:46:21 <10P​leasingFungus> (probably after t, to avoid distracting players) 18:24:22 Unstable branch on underhound.eu updated to: 0.28-a0-71-g84acfa7270 (34) 20:27:16 typo there... "disappates"... https://github.com/crawl/crawl/commit/ed1d120c62e6aaa73617eb1f319f8676ed4c730b 20:29:44 fixed here i guess. https://github.com/crawl/crawl/commit/271197699b0a70a712d329be4ab146388eb36f9a 20:31:46 or introduced again... ;) 20:34:58 <10P​leasingFungus> that was a fix 20:35:03 <10P​leasingFungus> unless you're seeing something i missed? 20:35:47 yep it's fixed 20:35:59 fixed in the next commit iirc 20:36:03 commits are confusing :) 21:03:51 -!- allbery_b is now known as geekosaur 22:30:41 New branch created: pull/2050 (1 commit) 13https://github.com/crawl/crawl/pull/2050 22:30:41 03kippig02 07https://github.com/crawl/crawl/pull/2050 * 0.28-a0-72-g5080c1d7d2: Edits tgw_trog vault to avoid rat spawns late. 10(9 minutes ago, 1 file, 4+ 0-) 13https://github.com/crawl/crawl/commit/5080c1d7d23f