00:49:41 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4855 * 0.34-a0-1021-ga62ee1860f: Nerf zin piety post decay removal 10(18 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/a62ee1860fef 00:55:35 Monster database of master branch on crawl.develz.org updated to: 0.34-a0-1035-g296a76d0c2 00:59:27 -!- indigaz22 is now known as indigaz2 01:30:27 <06m​umra> Had another idea for a hex spell idea it sort of evolved into Forge/Summ as I thought about it: Gremlins. Leaning into the earlier folklore origins of gremlins (not the movies obviously) which still only originate from 1920s aircraft malfunctions. These would be fast, small and high EV and can both sabotage enemies but also repair your own constructs (making the leap that if they can cause mechanical failures, they can also fix things 01:30:28 when motivated). They won't respond to shouts, they'll just target something randomly in LoS and rush at it. Any given monster/construct can only be affected once by any gremlin. "Bad things" that happen to enemies would look like: a weapon, ability or item backfires on them damaging themselves, they drop their weapon or an armour/jewellery item; golems and other things mechanical in nature will be susceptible to some particular damage/debuff 01:30:28 (including monster forgecraft creations of course). Casting the spell creates a small group of them, say 1-4 spell power depending. There is not necessarily a hard limit like other summons, but you can only summon as many as there are enemies in LoS that can still be affected, a gremlin won't target something another one is targetting, if one finds it has nothing to target it will pop back out of existence. The idea being they're not great to spam as a 01:30:29 meat shield but can cause some havoc in the enemy ranks. (Perhaps an ability to "dodge past" other units so they can pathfind to things further back) 01:58:31 <04d​racoomega> Gremlin Sabotage Squad is cute flavor (though I find myself rather reminded of imps, in a Crawl context), though I am not entirely sure how to reconcile 'make multiple things at once, with no summon cap' with 'not good to spam as meat shields'. Consider how good butterflies were in that role even though they can't do anything and don't try to move towards monsters. I also wonder if there's some awkwardness with the combination of 01:58:32 wanting them to act once and disappear, and then also want to give them some way to not be obstructed by other enemies when moving, that makes the whole thing feel less creature-like - like the flavor is creature-based, but the mechanics are fighting against that a bit? (Also, when you said 'only affected once' is that... forever? For some long length of time?) Dropping armour is sometimes very good, though usually worse than corrosion (a majority 01:58:32 of armour-wearing enemies are getting less than 8 AC from it). Does it do nothing to non-construct monsters without equipment at all? 02:10:07 <06m​umra> Well in practise you do get a summon cap, it would just be quite high if there are a lot of fresh monsters on screen. Yeah the idea would be only affect something once, ever, so there can be potentially permanent maluses. Think there should be more of a selection of things they can do, these were just examples, so yep there should be things that can affect non-equipment-using monsters, taking some liberties with the flavour to also 02:10:08 include "generally causing accidents" rather than specifically mechanical failures, they would just be stronger effects where mechanical failures are involved 02:16:18 <06m​umra> (You could easily have stuff like "the monster gets their foot stuck in a crack in the floor", "some rubble falls from the ceiling" etc to have them do things to monsters without it being the monster's own gear that fails. I would hesitate to say but given a monster can only be affected once, even shafting as a very rare effect) 02:20:55 <06m​umra> I wasn't thinking they'd just disappear. A gremlin could, say, fix one of your constructs first, then target an enemy, they'll go and attack that enemy and affect them on hit, and then either keep attacking them until they are killed, or perhaps target another enemy (I think this kind of thing is harder to imagine various versions of how the effect should/could play out and maybe needs some experimenting to find the most fun) 02:29:42 New branch created: pull/4859 (1 commit) 13https://github.com/crawl/crawl/pull/4859 02:29:43 03CrawlOdds02 07https://github.com/crawl/crawl/pull/4859 * 0.34-a0-1032-g98affbff6b: Fix display of HP penalty in flux preview 10(11 hours ago, 6 files, 9+ 4-) 13https://github.com/crawl/crawl/commit/98affbff6b79 04:13:08 03WizardIke02 07* 0.34-a0-1036-g3a176dd0d6: Add Brian 'buehler' Faires to the credits 10(2 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/3a176dd0d636 04:19:32 03CrawlOdds02 {WizardIke} 07* 0.34-a0-1037-g7267fc8787: Don't offer Ash curses while ostracised from full piety 10(21 hours ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/7267fc878702 04:33:32 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:26:49 Marqq (L9 TrBe) Crash caused by signal #6: Aborted (D:7) 05:29:36 Marqq (L9 TrBe) Crash caused by signal #6: Aborted (D:7) 05:30:32 <04d​racoomega> ...crashing in chunk_writer::raw_write() upon trying to save sounds... concerning 05:30:43 <04d​racoomega> Like, I don't know what to make of that 05:31:43 03CrawlOdds02 {WizardIke} 07* 0.34-a0-1038-gb014eb5195: Fix display of HP penalty in flux preview 10(15 hours ago, 6 files, 9+ 4-) 13https://github.com/crawl/crawl/commit/b014eb51955f 05:38:57 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1037-g7267fc8 (34) 07:02:30 03nlavsky02 07* 0.34-a0-1039-g66040a7279: fix: colourise the Body Armour AC modifier in talisman descriptions 10(4 minutes ago, 1 file, 8+ 3-) 13https://github.com/crawl/crawl/commit/66040a72799a 07:22:12 winrateplayers (L27 FeBe) ERROR in 'tileweb.cc' at line 236: Socket write error: Resource temporarily unavailable (Pan) 07:23:04 <09g​ammafunk> looks like CAO webtiles is having some issues 07:25:21 Webtiles server stopped. 07:27:03 Webtiles server started. 07:27:46 <09g​ammafunk> restarted, nothing looked wrong precisely, just quite spikey/high load and apparently that was leading to crashes 07:46:11 Forgeling (L3 DEFw) Crash caused by signal #6: Aborted (D:2) 07:47:02 cesarpolux (L8 MiFi) Crash caused by signal #6: Aborted (D:7) 07:50:17 <08n​icolae> man, i am looking forward to this move being over and my computer being set back up 07:50:21 <08n​icolae> hachi machi 08:21:45 <08n​icolae> yesterday i was reminded of "the cask of amontillado" and that i had made a vault inspired by it, and spent like thirty minutes trying to track it down, assuming that it had been removed at some point, and then eventually realized that i cut it from the PR so i could merge it in time for 0.31 and it never actually went in. lol 09:10:16 <09h​ellmonk> for the love of god, nicolae 11:03:24 <04d​racoomega> I swear, if you could hear me babbling out loud about some of this code, you might think I was slowly becoming a madwoman. (I have found Yet More Dumb Things >.>) 11:04:15 <06d​olorous_84348> If the concept of gremlins from that old Bugs Bunny cartoon fits, maybe some equivalent of: "Sorry, Player, I ran out of energy." ("You know how it is with these A cards.")? 11:05:08 <06d​olorous_84348> We're coders, so we're all mad to an extent. 11:06:18 <04d​racoomega> And am seriously considering refactoring some structural things about monster enchantment handling. (We have a bunch of 'on expiration, do this' in remove_enchantment_effect() (which is what the function is for) but then a bunch of enchantments do their decay manually apply_enchantment_effect() and print their expiration message there instead. And some enchantments split their expiration effects between both functions. (And 11:06:18 then timeout_enchantments() is extra nonsense, which started all this) 11:08:08 <04d​racoomega> (This isn't the wierdest part of it, but essentially: monster enchantments don't decay at all if you've been off the floor for less than 10 turns, and after that most of them will instantly end, because it removes one 'level' per 100 aut, and the degree parameter is meaningless for 99% of enchantments and usually given junk values of 0 or 1. But for a few things, like draining or poison, it actually means stuff and they can last 11:08:09 much longer than their actual durations) 11:09:45 <04d​racoomega> Daze uses degree for a different sort of bookkeeping and will last a really long time off floor (far longer than if you were on the floor). Though of course monster catchup code is so buggy that they'll move around while dazed anyway 11:10:13 <04d​racoomega> (I am ripping out and replacing most of that and the enchantment code is the part I'm at next) 11:12:04 <04d​racoomega> But it's very tempting to reorganize things so that 'standard' decay functions can happen automatically (kind of like how we do it for player durations) 11:12:30 <04d​racoomega> (I don't know how deep I will end up going into the parts that are more 'It would be tidier' versus 'It would stop being broken') 11:26:34 <06d​olorous_84348> You're at least making major progress. My attempts to try to port more egos to artprops haven't worked out (some parts of that go in makeitem.cc, and some go in artefact.cc, but it's not always clear where), but looking through the code in the process has at least motivated me to clean up some bits of it. And looking into bug #4828 has led me down a rabbit hole where apparently reaching is handled via the quiver code, it appears 11:26:34 that none of the quiver code accounts for offhand wielding at all, and all those massive blocks of code in quiver.cc are... something. 11:27:13 <06d​olorous_84348> If I understand it correctly, that is. 11:28:50 <04d​racoomega> Oh, I've fixed at least some of the off-hand wielding quiver code stuff 11:29:02 <04d​racoomega> On the weapon arts branch 11:29:47 <04d​racoomega> (There were a variety of places where you could perform attacks with only one weapon, such as trying to use dir+attack with an axe against an open space) 11:30:23 <06d​olorous_84348> That's very good to know. 11:31:20 <04d​racoomega> (So many of my fixes have ended up entangled with other stuff that isn't yet done - I was really slow on parts of the weapon arts branch, and now I've been doing this other refactoring full-tilt for a while. But I'll be pushing this pile of stuff before I get back to weapon arts) 11:31:51 <04d​racoomega> I am... reasonably far along with it, though it's hard to give a time estimate, since I keep finding new problems 11:32:37 <06d​olorous_84348> Good luck with it. 11:33:02 <04d​racoomega> Thanks 11:39:42 <08n​icolae> we're all mad here 11:43:13 03dolorous02 07* 0.34-a0-1040-g409a2a9a61: Mention amphibiousness in fortress talisman desc. 10(3 minutes ago, 1 file, 5+ 5-) 13https://github.com/crawl/crawl/commit/409a2a9a6194 11:47:58 <06m​umra> Talking out load while coding definitely helps me get stuff. Five years of almost entirely remote working has not helped this habit 😅 11:48:39 <06m​umra> This week i started a new job and it's full time back in an office for me. I'm not sure what they think of my mutterings 11:50:47 <04d​racoomega> Oh, I was ranting to someone ^^; 11:50:56 <04d​racoomega> (Index, of course) 11:59:46 <06m​umra> Oh well that's far less crazy 12:33:40 -!- VagabondTruffle is now known as HN-MKU 12:47:12 03dolorous02 07* 0.34-a0-1041-g7a70d8a9cb: Replace a few artefact adjectives with synonyms. 10(6 minutes ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/7a70d8a9cba2 14:55:08 03dolorous02 07* 0.34-a0-1042-g2c1d4b5324: Update comment on talismans' not getting regen. 10(4 minutes ago, 1 file, 7+ 2-) 13https://github.com/crawl/crawl/commit/2c1d4b532480 14:56:59 <06d​olorous_84348> Bad news and good news. I'm currently unable to fix the old no-regen-on-artefact-talismans problem, but at least (a) I've figured out that it's shifted from crashing to just doing absolutely nothing, and (b) I know what the eventual fix for the problem should be: more artprops juggling. 14:58:45 <04d​racoomega> That comment is slightly misleading, isn't it? Lots of aux armour can only get regen from artprops and it works on them. (I realize talisman equipping uses an unrelated codepath, but the issue is that rather than artprop-only regen, isn't it?) 14:59:21 <06d​olorous_84348> Yes, it's the unrelated codepath that only checks the artefact-relatef bits. I'll fix the misleading part. 15:01:34 03dolorous02 07* 0.34-a0-1043-g643edf1ca2: Fix slightly misleading wording (DracoOmega). 10(74 seconds ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/643edf1ca27c 15:02:58 <04d​racoomega> I think maybe if a call to _handle_regen_item_equip() was added near the existing call to equip_artefact_effect() when transforming, and a check specifically against your talisman in _player_bonus_regen() was added (since it's not a 'slot item'), it might work with relatively little effort? 15:03:18 <04d​racoomega> (I could be overlooking something, but that was my impression on a quick survey) 15:03:59 <06d​olorous_84348> Maybe so. I'm feeling too burnt out to look into it anymore at the moment, but soon. 15:05:53 <04d​racoomega> Oh sure. No rush or anything. Just quick impression from someone who's spent a bunch of time with most of that code before ^^; 15:06:06 <06d​olorous_84348> Indeed 🙂 16:40:49 Unstable branch on underhound.eu updated to: 0.34-a0-1043-g643edf1ca2 (34) 16:57:41 03dolorous02 07* 0.34-a0-1044-gf4d9ab44da: Update regen talisman comment again. 10(7 minutes ago, 1 file, 4+ 1-) 13https://github.com/crawl/crawl/commit/f4d9ab44da6d 16:59:25 <06d​olorous_84348> Thanks for the pointer; I tried it, but all the checks for regen items' being attuned currently require the items to have slots, and talismans' being slotless is a problem there. 16:59:41 <06d​olorous_84348> At least I've learned things in the attempt. 17:04:32 <06d​olorous_84348> Maybe give the currently active talisman a fake slot, or something similar? 17:05:19 <06d​olorous_84348> (I wish I understood the slot code.) 17:09:41 <04d​racoomega> Oh, oops, right. Attuned status is stored in a player_equip_entry 17:10:05 <04d​racoomega> And talismans don't get one of those 17:11:35 <04d​racoomega> I guess it'll need a little something else 18:04:46 <06m​umra> @dracoomega Btw I am still keen to do something with the gold-to-silver spell, even if that means putting it to bed, but it'd be nice to salvage something from it. I'm just not sure what the most promising direction to take it would be. I'm not sure if you saw the last edits I made back in April (I didn't see any further comment from you on it, apologies if I missed something) The last experiment I tried was to remove the MP cost 18:04:47 entirely and make this just cost gold (as well as remove the channel-while-moving behaviour, which makes it a bit simpler to handle and target, and the cost simpler to understand; I know this was one of the interesting features, but it still thrusts you forward one space as you cast it, so move-and-shoot is still there) Really I think there are 3 ways to take it from here - Stick with this behaviour and try to balance the cost/power level from 18:04:51 there; it doesn't want to be endgame powerful where you have so much gold casting it is basically free, but it should be relevant enough in mid-late game this is something you do want to use against particularly tough enemies and also when low on MP to mop up 18:04:51 <06m​umra> - Revert more to the previous behaviour where you cast once and then it keeps firing as you move (with or without the MP cost). I made this overcomplicated before. It should just take 1 turn to cast like a normal spell, and then fire on every move whether a monster is in the way or not (something that was weird in the original design), and additionally melee an enemy if they're in the way. - Drop the gold cost entirely and make it a 18:04:51 straight up blasty spell with a big beam. At this point it should probably become Alch/Conj as the stuff has to come from somewhere, but does it even make sense to retain the silver brand? Another effect I was thinking the player doesn't yet have access to is Barbs, which actually seem to fit alchemy quite well as a variant of damage-over-time. (This could even replace or be added to silver in the case of the first two options as well; I feel silver 18:04:51 is a little boring in terms of the effect not really being that noticable, even if it's a fairly unique feature to have access to it) 18:06:59 <06m​umra> or the fourth option which would be rather sad * drop the spell entirely but use the 3-beam with compass direction for a ranged unrand (which i had thought separately to do as well) 18:23:49 <06r​egret-⸸nde※> Draco was prepping to go to sleep for the night when you pinged her, alas. 18:28:55 <06r​egret-⸸nde※> Barbs currently has no intensity or scaling factors to it, so it does very little damage to monsters currently. Even with this being reasonable to change (one of many different pieces of the todo list was to make it percentage damage, so it's not a pointless ui tax on peacekeepers and echidna), its play patterns are also fairly worse than other DoTs since it doesn't even function without actively kiting- there was some internal 18:28:55 testing with it for the Hexslinger revisions a few years ago, but it got rejected for not being the most fun to advocate even compared to how e.g. current poison spells regularly emphasize short-range effects outside of OTR. 18:35:19 <06r​egret-⸸nde※> The firing-while-moving mid-to-late spell behaviour heavily overlaps with current plans for the Disjunction replacement / Manifold Assault division after the weapon arts + skill cost rescaling + (apparently refactor eight different core game systems) project finally lands this version, if I remember correctly. I'd actually argue a ranged weapon unrand position would be fairly better off than spells, since each spell tends to 18:35:19 have far more competition between spells of comparable levels and schools than e.g. unrands, and ranged weapons as a whole are a very popular build with incredibly little per-run differentiation attached to them. 18:38:53 <06r​egret-⸸nde※> (If you're looking for projects, I could actually really use some new layouts for Pan with the Hell-Pan Roulette finally being the top and immediate priority for the next version, with some specific desires of lightly distributing around differing wall types / statues / per-floor different rock tile subsets as I've been tiling up for Pan without just making the whole floor non-rock, and with way too many of the current layouts 18:38:54 overlapping with D and Snake.) 18:39:11 <09h​ellmonk> do you think there's any angle for a ranged weapon non-unrand (ie a new base type) with some play style variance? I have found it very hard to think of any in the past, due to weapon swapping 18:41:32 <09h​ellmonk> maybe we should steal triple crossbows firing 3 times from bcadrencrawl so ranged users can have a use case for insane giga slaying 18:45:51 <06m​umra> The unrand in mind would be a triple crossbow that fires three parallel bolts 18:46:58 <06m​umra> The Cardinal's Crossbow (or Cardinals Crossbow, since it only fires in the compass directions) 18:47:02 <09h​ellmonk> re: pan layouts, I don't have much ability to code any new ones, but I wonder if the approach could be 1) expand the layout pool to use a lot more layout types from other areas and 2) apply a unique function similar to the ruin function on top of them 18:48:00 <09h​ellmonk> (not literally similar to ruin, but a similar "modify the level post-generation according to some parameters" idea) 18:48:32 <06m​umra> An interesting thought might be to reuse existing layout generators but mash multiple of them together. Divide the map into 4 quadrants and use a different generator in each 18:49:13 <09h​ellmonk> I think rift wizard does that on some levels. Dunno if crawls layout generators play nicely with that 18:49:17 <06m​umra> So there is an element of "planes colliding" 18:53:36 <06m​umra> Without modifying the original generators I think I would generate 4 entire maps, then generate the final composite by taking chunks from each (and some additional processing to fix connectivity). It would be a little slow but how many floors does newpan even have? This would play nicely into distributing different wall types etc as each chunk can use a different set perhaps? 18:54:35 <09h​ellmonk> Could work, I would definitely be worried about connectivity but maybe it isn't that hard to fix up 19:00:09 <09g​ammafunk> I might like to work on a layout for Pan, but before doing so, I'd actually like to know something about the new monsters and mechanics, and what if anything changes about the vault sets used in pan 19:01:58 <09g​ammafunk> interestingly, there's a pan layout vaguely like this idea that infinipliex made, it's one of the last layouts he worked on iirc, let me find it 19:03:43 <09g​ammafunk> !source layout_pan_divisions.des 19:03:44 <04C​erebot> https://github.com/crawl/crawl/blob/master/crawl-ref/source/dat/des/builder/layout_pan_divisions.des 19:04:27 <09g​ammafunk> this is really more just traditional subvaulting 19:05:02 <09g​ammafunk> although one could think of this kind of subvaulting as a "layout", of course it's much less variable than a layout would be 19:06:02 <09g​ammafunk> but it's funny that mumra mentioned the idea of stitching 4 types of sections together for Pan and infiniplex had apparently had a similar line of thought 19:07:18 <09g​ammafunk> oh hey, I was even the one to merge this 19:11:31 <06m​umra> oh interesting. yes very much like this but far more procedural 23:21:29 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1044-gf4d9ab44da (34) 23:35:27 Unstable branch on crawl.develz.org updated to: 0.34-a0-1044-gf4d9ab44da (34) 23:58:35 Windows builds of master branch on crawl.develz.org updated to: 0.34-a0-1044-gf4d9ab44da