00:22:58 someone reported on the PR: wands lost the green auto-pick up border around them after these updates 00:23:06 which I can look at tomorrow if no one gets to it first 00:30:33 Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-460-g737a915 (34) 00:33:22 Wands do not display green auto pickup border. 13https://crawl.develz.org/mantis/view.php?id=11285 by xbon 00:38:34 Wands can be identified (but it does nothing?) 13https://crawl.develz.org/mantis/view.php?id=11286 by xbon 01:20:22 Unstable branch on crawl.develz.org updated to: 0.21-a0-460-g737a915 (34) 01:41:00 gammafunk: do you accept debit cards 01:43:38 minmay: laundered through twitch bits 01:57:33 Windows builds of master branch on crawl.develz.org updated to: 0.21-a0-460-g737a915 02:11:12 -!- aditya1 is now known as aditya 02:11:39 -!- aditya is now known as adibis 02:31:21 beep 02:31:49 whoops 02:54:37 Monster database of master branch on crawl.develz.org updated to: 0.21-a0-460-g737a915 03:21:56 -!- amalloy is now known as amalloy_ 03:22:09 Unstable branch on crawl.beRotato.org updated to: 0.21-a0-460-g737a915 (34) 03:28:25 -!- amalloy_ is now known as amalloy 04:37:07 -!- amalloy is now known as amalloy_ 07:32:37 !messages 07:32:37 No messages for SteelNeuron. 07:44:52 03MarvinPA02 07* 0.21-a0-461-g2470eb2: Make some move-slowing effects more consistent 10(12 minutes ago, 2 files, 5+ 10-) 13https://github.com/crawl/crawl/commit/2470eb21e1b4 08:32:08 FR: confused monsters/player have Clarity for the confuse duration. 08:38:45 This prevents chain confusion spam from golden eyes (I think it's a problem) and as a side effect it gets rid of UI screw: targeting already confused monster with Confuse spell. 11:18:39 TZer0: looks like a permissions problem on the ttyrec dir, this gives me 403: https://underhound.eu/crawl/ttyrec/MirrMurr/2017-11-19.17%3A35%3A57.ttyrec.bz2 11:18:50 TZer0: the directory listing works just fine and shows the file 12:25:14 Unstable branch on crawl.akrasiac.org updated to: 0.21-a0-461-g2470eb2 (34) 12:38:18 !tell gammafunk it is on my server-status page as a known issue 12:38:18 TZer0: OK, I'll let gammafunk know. 12:38:33 !tell gammafunk https://underhound.eu/2017/11/04/serverstatus/ 12:38:34 TZer0: OK, I'll let gammafunk know. 12:38:45 (oops, could've put those in one message..) 12:40:53 no worries 12:40:53 gammafunk: You have 2 messages. Use !messages to read them. 12:41:25 I'll just wait till later to watch that person die in my new wizlab map.... 12:48:55 -!- amalloy_ is now known as amalloy 12:57:24 gammafunk: if you really want to see it, you could send me the nickname and I can correctly chown the files 13:10:36 TZer0: no it's ok, I don't want to make more work for you :) 13:11:33 I can be patient and wait just like the rest of your users are doing 13:17:11 wow, reddit hates newwands 13:18:37 mostly looks like reflexive anti-change sentiment 13:18:50 yeah, I've heard a bunch of positive comments 13:20:27 even in that thread there are a lot of positive comments 13:20:41 What does reddit hate about new wands? Oh no, I no longer get to have the infinite fun of juggling wands of the same kind with different charges and inventory slots around them? 13:22:49 I'd have more sympathy for the "oh but my recharge scroll decisions" people if there weren't so many charges and so many people not using charges in the first place 13:23:15 we could improve the number of charges given to the higher-end wands, or just even out their rarity a bit with the more common ones 13:23:17 they think it's a nerf to evocations, say they will miss the recharge choices 13:23:41 gasp 13:24:37 players also miss mountain dwarves 13:24:41 yep 13:24:46 said it was a nerf to dwarves 13:24:55 I don't think most of these comments are from people who have tried it 13:25:11 there are certainly plenty of things we could do past these changes 13:25:39 I think the recharging scroll was a bad design as a single item 13:25:59 yeah, it's sort of interesting how it presented the appearance of strategic choice with (usually) any strategic impact 13:26:16 a recharging effect somewhere could certainly be some kind of thing, but part of what makes wands interesting is that you just have what you have 13:26:19 hmm, random idea for "buffing" rare wands: wands have a 50% chance of regaining a charge when you use the last charge, instead of crumbling. gameplay principle, people like gambling 13:26:57 advil: sounds kinda like wresting one last charge out of that wand of wishing 13:27:04 well I don't think that would actualy introduce any kind of decision 13:27:04 heh true 13:27:16 like how would you use this effect to decide "I'm going to roll the dice now" 13:27:19 have it scale to 100% with evocations 27! 13:27:27 (probably not) 13:27:33 it's not actually rolling the dice in any way really; you just get a free charge sometimes 13:28:01 something more like you "overcharge" a wand and it either works, taking multiple charges, or blows up 13:28:01 stuff like that 13:28:24 the vague idea I had is that it would somewhat encourage not hoarding rare wand charges (if that turns out to be a thing people do) 13:28:26 stuff like that is also tricky to balance, but at least there's a risk/reward situation 13:28:53 well it wouldn't encourage me to change my usage of rare wand charges, unless I misunderstand the change 13:29:07 I would just use my wands when I need them and expect to sometimes get another charge 13:29:18 I think you underestimate how much a lot of people like rolling the dice 13:29:33 (I think a lot of strong dcss players do, actually) 13:29:34 but it wasn't a very serious idea 13:29:43 advil the the way you want to have someone "roll the dice" is when there's a risk 13:30:06 I mean, I'll grant that what you've propsed does involve rng, but I don't think the point is merely to introduce rng 13:30:20 I guess that has a sort of appeal, but I don't see how it actually changes gameplay 13:30:32 would by my complaint; it doesn't change the way I'd want to play 13:30:45 s/would by/would be/ 13:31:38 also s/the the/the/ 13:31:45 where is my irc spelling/grammar check 13:32:24 gammafunk: try turning into a bot with /nick Funkell. i've never seen a bot produce a spelling mistake 13:32:45 didn't I use that nick for a bot once? 13:32:50 beats me 13:32:53 .echo spleling 13:32:53 spleling 13:32:54 -!- gammafunk is now known as Funkell 13:33:01 -!- Funkell is now known as gammafunk 13:33:58 I wonder if there would be some interesting interaction with nearly empty wands, not sure what 13:34:44 yeah, and I'm not trying to just shut down anyone's ideas for more interesting wand stuff; just hopefully if we add any new form of interaction with them, there's some real decision-making and the effect is something interesting 13:35:03 I have been half-brainstorming a newnew pakellas but I haven't gotten very far 13:35:07 hm, another one (still not sure it's very good), training evo adds some chance (which would probably cap relatively low) of not draining a wand charge when you use it 13:35:11 this new god would not be a 100% evocations one 13:35:16 is https://www.reddit.com/r/dcss/comments/7e0plg/ctrlf_wand_of_lightning/ the same bug as the one that used to happen with the weird ring of plants in zot:5? 13:35:27 probably? 13:35:34 i thought we fixed the other one 13:35:37 I vaguely recall that getting fixed though, yeah 13:35:53 good luck finding the commit, though, since i have no idea what to search for 13:35:59 some version of that got fixed but it's still around 13:36:17 I hit that bug at some point before I was dev and asked about it in here, I can probably find it 13:36:52 https://crawl.develz.org/mantis/view.php?id=10828 13:37:00 layout_gridlike probably 13:37:44 iirc I set the trees on fire 13:38:07 arsonist 13:38:48 what we have here is an anti-tree dev conspiracy 13:54:36 advil: agreed it is layout_gridlike. i was able to repro after regenerating zot like 30 times with layout_gridlike forced, and its tree-affinity cranked up to eleven 13:55:06 hey, speaking of layout_gridlike, i see mumra's name all over the git blame... 13:56:07 that is, i don't actually know if layout_gridlike is the problem: maybe this is something the dungeon builder is supposed to fix after the layout runs, and layout_gridlike just happens to expose a dungeon-builder bug 14:01:21 yeah, I bet you're right, the builder should be ensuring a path through the entrance and it isn't 14:01:46 and gridlike happens to be able to produce lines of trees oriented in the right way 14:02:02 it must be tree-specific too? 14:02:19 maybe we could view this as a feature 14:02:28 opens up the design space for wands of lightning 14:02:54 gammafunk: sadly without ?recharge, players will use up all their /lightning too soon 14:03:09 it's been a while but in the game where I hit it I think I actually hadn't seen any and needed to go clear vaults 5 to look for one. which was fun in a way 14:03:10 amalloy: that's the strategic aspect! you have to conserve them 14:03:17 and formicids who sacrifice artifice and air magic would have an extra special challenge 14:03:29 oh right it was a jiyva char 14:03:32 advil: that's my guess too. i'm trying to find the code that tries to ensure traversability 14:03:38 so they had all been eaten 14:05:12 It doesn't make the game unwinnable, there's always zigscumming, panscumming, or abyss scumming 14:05:14 So it's okay clearly 14:05:20 GoXom 14:06:20 gammafunk: good players know that if you go Fo^Ru and sac artifice/air, you have to leave the lernaean hydra alive in case you get this vault 14:08:23 amalloy: actually I think that wouldn't work 14:08:34 because for lerny to do that, he'd have to be on the other side of those trees 14:08:46 but you could still just go to Zot:4 and shaft down 14:08:50 gammafunk: you could drag it E/W 14:08:54 don't even need lerny (sadly) 14:09:00 lol, sure, you can *get* the orb that way 14:09:03 tele randomly 14:09:03 you gonna shaft back up? 14:09:07 both ways, uphill in the snow 14:09:19 amalloy: fool, orb spawn a blizzard demon 14:09:35 come on people, bring your A-game here 14:09:42 Does wand of flame burn trees? 14:09:44 by A I mean angels and daevas 14:09:47 no it doesn't 14:09:54 fireball, bolt of fire, bolt of lightning 14:10:01 there goes my "a reason to use wand of flame" joke 14:10:02 and fireball only when the tree is directly targetted 14:10:14 oh and I guess said Fo would also have to sac fire (or just conj) 14:10:19 for this challenge to be real 14:10:51 also love 14:11:00 amalloy: but I have improved lerny tech if you can make a shaft trap on Zot:4 14:11:06 shaft him to Zot:5 into the vault 14:11:10 or they could... summon dragons? probably 14:11:23 I guess you'd really need to be able to make shaft traps for this to have any real chance of success 14:11:29 gammafunk: just send lerny to the stair half of zot:5 and then shaft yourself into the hall 14:11:38 oh, true! 14:11:42 she'll break you out 14:11:54 yeah, ok, then your Zot:5 lerny tech is legit 14:11:57 I'm sorry I made fun of it 14:12:18 imo we should suggest some of this stuff as a feature request for nethack 14:12:21 But what if lerny doesn't generate in your game 14:12:24 they'd love this kind of stuff 14:15:08 wtf is this "spotty" flag in map generation 14:18:25 03gammafunk02 07* 0.21-a0-462-g102393a: Don't show identified wands in the identification scroll menu (reddit) 10(11 minutes ago, 1 file, 1+ 3-) 13https://github.com/crawl/crawl/commit/102393a3824f 14:33:20 03gammafunk02 07* 0.21-a0-463-gc071dca: Don't show scrolls of recharging on the recognized item menu (Yermak) 10(8 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/c071dca879e3 14:44:34 so, i have a coord_def's x and y coordinates. is there an easy way to tell where on the map that is, in wizmode? like i had the dungeon builder print its coordinates for me but i don't know where it is 14:44:53 oh nm, X shows me 14:48:37 it's easier in tiles, the mouseover shows you 14:49:10 eh, X is fine 14:57:33 so, i believe i can fix this tree thing, but before i actually do i'd like to understand why it currently is the way it is, so i don't break some other feature i don't understand 14:57:40 it seems to me that _connect_vault_exit tries to create a path from the vault's @ sigil to any non-vault tile, and is willing to replace any non-vault tiles on the way with floor. after it finds a path, it calls join_the_dots to actually replace the path with floor, but join_the_dots explicitly does not consider trees overwriteable 14:57:47 so the disconnect is that when pathfinding we consider trees okay to pathfind to, but once we have the path calculated we refuse to overwrite them. does anyone see a reason to treat trees this way? i'd like to either make them not pathfindable-through, or else make them replaceable with floor for connectivity 15:00:37 i guess i'd prefer to make them not-pathfindable-through, since tearing a hole in one of these tree-boxes ends up looking pretty silly 15:07:41 yes 15:07:50 sounds like not-pathfindable would result in less vault breakage 15:08:00 many vaults use trees for borders etc 15:08:04 well it already won't tear them down if they're trees placed by vaults 15:08:16 oh, so these are trees from the builder? 15:08:18 yes 15:08:19 the layout, I guess 15:08:27 layout_gridlike 15:08:30 well, it's a similar principle 15:08:43 layouts can place structure that's important, I guess, that could include trees 15:08:49 is there anything else that can't be overwritten like that? 15:08:51 however perhaps this structure is generally overritable 15:09:25 I guess walls are just non-pathfindable? 15:09:29 but if a layout is placing contiguous trees like that, there's a reason isn't there? 15:09:50 I'm not familiar with what layout_gridlike can do with trees 15:09:50 !vault layout_gridlike 15:09:50 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/dat/des/builder/layout_cellular.des#L346 15:10:09 gammafunk: it places rectangular boxes where the border is one feature and the fill is another 15:10:13 it makes rectangles out of trees, and various colored walls 15:10:29 hrm 15:10:32 !source join_the_dots 15:10:32 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/dungeon.cc#L5311 15:10:37 and those walls can normally get clobbered by vaults, can't they? 15:10:43 those little boxes I mean 15:10:49 can they? i'm not sure 15:11:10 amalloy: in your testing is this bug always just with one-space wide tree walls? 15:11:18 both examples I've seen are like that, not sure way 15:11:31 oh maybe the middle is something other than trees, so it can't place? 15:11:39 advil: layout_gridlike only places one-space-wide walls 15:12:08 my testing involved turning off everything but trees, so i can't say whether it occurs for anything but trees 15:12:17 what I mean is that I've never seen a rectangle extruding from the orb entrance more than one space out 15:12:19 ah ok 15:12:33 right, the middle of those rectangles is never trees 15:12:40 it's water, or floor, or whatever 15:13:06 ah 15:14:02 !source layout_cellular.des 15:14:03 https://github.com/crawl/crawl/blob/master/crawl-ref/source/dat/des/builder/layout_cellular.des 15:14:12 advil: see material_pairs in that file for the feature pairings it uses 15:14:44 er, wrong file? 15:15:15 oh no, it's there, i had just misspelled my ^f 15:18:02 do you have a line number for the crucial trees-allow-pathfinding part? 15:18:12 I wonder if this is just something very very old 15:18:52 from when trees were not opaque or w/e 15:20:45 !source dgn_join_the_dots_pathfind 15:20:46 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/dungeon.cc#L5265 15:21:32 advil: there's nothing that says explicitly "trees allow pathfinding". it's just, anything that is not part of a vault allows pathfinding 15:22:14 and then later we say we are willing to overwrite anything that is "a floor, a wall, or liquid", as per 15:22:14 !source _feat_is_wall_floor_liquid 15:22:14 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/dungeon.cc#L5804 15:22:29 ah, hmm 15:22:30 thanks 15:24:09 i think it might be reasonable to just add trees to the list of things that are walls. they're already considered walls for this purpose in Swamp 15:29:21 huh, I see, sort of 15:29:32 is it that they don't get MMT_VAULT? 15:29:42 well, they get MMT_VAULT if a vault places them 15:29:51 but when the layout places them, as in layout_gridlike... 15:29:53 but layout_gridlike doesn't count? 15:30:02 I notice that a bunch of layouts manually add the mask 15:30:21 oh, i didn't realise that. maybe that's the answer 15:30:37 it looks kind of dumb in the lua, tbh 15:30:39 what does? 15:30:51 manually setting the mask, I think your way seems better 15:31:00 and the layouts that do this may also be setting it for floors 15:31:24 well, it's sorta correct to do that, i think, if you don't want that area to "count" for pathfinding 15:31:30 yeah 15:31:33 stupid question, where is the check for walls done in this pathfinding code? 15:31:45 it's not 15:31:49 oh 15:31:51 because we're willing to tear down walls 15:32:05 ohhh 15:32:13 anything that's not masked and is overwriteable can be torn down 15:32:16 yes 15:32:21 sorry :) 15:32:49 nothing to apologise for. it takes some time to figure out wtf is going on in the builder, i happen to know 15:32:58 heh 15:33:25 so a solution for layout_gridlike may be two-part: make trees overwriteable, and explicitly construct the masks 15:33:42 (that'll keep your ugly but pathable layouts from generating) 15:33:47 you'd only have to do one of those two things, right? 15:34:21 well, yeah, just to fix this bug, but it really does seem like trees are walls now 15:34:46 so that change seems right to me 15:35:08 i see. yes, i suppose if some other layout places trees which it doesn't mark as being part of a "vault" then they should be eligible for deforestation 15:35:27 and layouts should mark as part of a "vault" any trees that will look ugly when torn down 15:35:31 yeah 15:35:49 btw here's an example I found of a layout that does this: https://github.com/crawl/crawl/blob/master/crawl-ref/source/dat/dlua/v_rooms.lua#L370 15:36:25 some nice commented code there 15:41:01 anyone know where that light green rim around autopickup items is drawn? 15:41:15 tough thing to git grep for 15:48:31 ugh, adding this flag from the layout is not so easy, because it's not actually placing the tiles itself, it's calling out to dgn_fill_area. i guess i could add an optional "mark as vault" key to the map that dgn_fill_area consumes 16:18:08 -!- OICU812 is now known as Euph0roa 16:18:13 -!- Euph0roa is now known as Euph0ria 16:35:23 <|amethyst> gammafunk: look for item_needs_autopickup in tileview.cc; it's a few places 16:35:36 <|amethyst> gammafunk: the flag that sets is TILE_FLAG_CURSOR3 16:35:51 |amethyst: yeah, I did find this, thanks, but the problem is that unknown wands are not marked for autopickup 16:35:54 by default, it seems 16:36:06 I got distracted by something else, but I'll resume looking in a bit 16:36:33 <|amethyst> gammafunk: hm, but we have autopickup = $?!+"/% 16:36:52 <|amethyst> gammafunk: is maybe it being treated as useless there because it thinks there are 0 charges? 16:36:59 could be 16:37:22 <|amethyst> ah 16:37:23 not sure why it would think unided wands have 0 charges though 16:37:45 <|amethyst> because they're coming from the item_info, not the real item 16:37:52 <|amethyst> and the player doesn't know the number of charges 16:38:15 hrm, maybe I changed interaction with player info in some way 16:38:25 in terms of not setting KNOW_PLUSES? 16:38:30 <|amethyst> gammafunk: previously the function 'is_empty_wand' was 'is_known_empty_wand' 16:38:45 yes 16:38:45 <|amethyst> gammafunk: but it no longer checks KNOW_PLUSES 16:39:04 well, from what you're saying, it sounds like a call to that is returning the wrong result? 16:39:18 <|amethyst> gammafunk: is_empty_wand should be changed back to is_known_empty_wand 16:39:18 I should have made said function actually check for empty charges 16:39:27 well it's not that simple as I recall 16:39:32 <|amethyst> right now it does 16:39:35 <|amethyst> return item.charges <= 0; 16:39:40 <|amethyst> that should be something like 16:39:52 <|amethyst> return item_ident(item, ISFLAG_KNOW_PLUSES) && item.charges <= 0; 16:40:02 no, see this function 16:40:02 <|amethyst> or do you learn the plusses on sight now, not just walk-over? 16:40:06 it's used in multiple ways 16:40:27 it used to have an arg 16:40:36 maybe it needs to have an arg again 16:40:44 but I think this is used to see when a wand is empty 16:40:48 <|amethyst> or duplicate it and use the _known_ version in the is_useless_item 16:40:49 for purposes of evoking 16:40:54 <|amethyst> or just remove that check from is_useless_item 16:41:02 <|amethyst> you can't have zero-charge wands anymore, can you? 16:41:07 yes you can 16:41:08 <|amethyst> I guess maybe in transferred games 16:41:09 from wizmode 16:41:14 and yeah from transfered games 16:41:23 <|amethyst> maybe split is_empty_wand 16:41:30 <|amethyst> keep the current version as is 16:41:43 that's enough of a lead for me to fix that, so thanks 16:41:49 and of course feel free to patch yourself 16:42:15 it does have a few different calls that need to be looked at so they work properly, but I obviously missed some of the logic there 16:43:32 <|amethyst> hm 16:43:41 <|amethyst> also, not related to the current problem, but 16:43:56 <|amethyst> oh, never mind 16:45:12 <|amethyst> I was thinking _interesting_explore_pickup might need to be changed, but actually wands should behave the same as scrolls/potions, and they do (other than that an empty inventory wand doesn't count) 16:46:40 <|amethyst> gammafunk: oh, also, SCR_RECHARGING isn't in removed_items in item-prop.cc 16:46:49 |amethyst: recent commit did that? 16:47:01 <|amethyst> oh, didn't pull since earlier today 16:47:11 <|amethyst> yeah, it does 16:50:13 <|amethyst> I like how reddit calls the ?id bug (which I see is also fixed) a "major bug" 16:50:24 stoopid change 16:51:53 <|amethyst> hm, probably ?id frequency should be reduced? 16:52:40 <|amethyst> at least later in the dungeon (once you're likely to have ided most of the consumables, and all that's left are artefacts and the occasional amulet or "maybe it's distortion" weapon) 16:53:05 I seem to recall that we may not have increased it 16:53:14 when the wand charge wasting was introduced 16:53:54 it's certainly possible that we still generate too many, since that's partially why dpeg proposed the change as I recall 16:54:09 although I think his motivation was mostly about making the scroll have more use 16:54:22 <|amethyst> before charge wasting, you needed to ID the first of each wand, though of course you could do that by zapping 16:54:25 <|amethyst> and yeah 16:54:38 <|amethyst> it was mostly about making up for some of the loss to the ID game 16:55:03 <|amethyst> (weapon brands, non-runed weapons, artefact props on wear) 16:56:05 So what is the meat of the reddit criticism? 16:56:16 Is it that they dislike the loss of that decision of what particular wand to increase? 16:56:21 <|amethyst> SteelNeuron_: "you removed recharging, huge nerf!" 16:56:32 <|amethyst> SteelNeuron_: also "there are bugs" 16:56:35 right 16:56:36 <|amethyst> but mostly the former 16:56:56 Do you think there is anything legitimate behind it (i.e. loss of choice) or just complaints about power level? 16:57:17 I for one I'm pretty happy with the QoL change, I neglect wands a lot because I don't want to bother with inventory management and this is a godsend 16:57:20 but I'm curious 16:57:24 <|amethyst> I think it's mostly power level complaints 16:57:28 <|amethyst> yes, there is less choice 16:57:45 FK mentioned how we could increase frequency or charges of the high-end wands 16:57:46 <|amethyst> but that just means you no longer can save up your ?rech to use on your /cloud or /scattershot 16:57:56 which we could, but I think we can sit on this for a bit 16:58:01 <|amethyst> yeah, I think increasing charges would be pretty reasonable 16:58:14 honestly I think the recent winrate improvement was probably due to wand buffs 16:58:14 <|amethyst> but doesn't need to happen now 16:58:38 <|amethyst> the new wands are better than /haste /heal and /tele? 16:58:57 there were a few potential factors but we never found a single one (the winrate increase was higher than expected for the usual 'players get better' factor) 16:59:30 is there a specific target win rate? 16:59:52 <|amethyst> steady-state for the most part 16:59:59 <|amethyst> "same as last version" 16:59:59 |amethyst: it surprises me that setting MMT_VAULT on a coord_def that has a tree on it appears to make it be a wall instead. do you know why that is? 17:00:12 <|amethyst> amalloy: setting how? 17:00:34 |amethyst: i added some code in l-dgnbld that calls env.level_map_mask(pos) |= MMT_VAULT 17:01:50 <|amethyst> amalloy: is this code that's called from a layout? 17:01:59 <|amethyst> amalloy: if so, see: 17:02:04 <|amethyst> !source map_lines::apply_grid_overlay 17:02:05 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/mapdef.cc#L571 17:02:09 <|amethyst> if (is_layout && map_masked(gc, MMT_VAULT)) 17:02:09 <|amethyst> continue; 17:02:17 it is called from a layout, yes 17:02:22 <|amethyst> since MMT_VAULT means "the layout shouldn't overwrite this" 17:02:32 <|amethyst> (among other things) 17:02:38 oh 17:02:39 <|amethyst> so probably the tree is never being written 17:03:31 <|amethyst> btw, I "like" this pair of lines 17:03:35 <|amethyst> // Over-ride whatever property is already there. 17:03:35 <|amethyst> env.pgrid(gc) |= property; 17:03:52 <|amethyst> 1. hyphen in "over-ride" makes me imagine the map being trampled by a horse 17:04:08 <|amethyst> 2. that's clearly a logical or, not an override at all 17:04:28 so, i imagine you don't want to read all the scrollback. the problem i'm working on is that when the layout (not a vault) places trees, the dungeon builder has trouble with those trees when trying to ensure reachability of @ tiles in vaults 17:05:11 specifically, it pathfinds through the trees as if they were traversable, but refuses to overwrite them with floor tiles. contrast this with the behaviour for walls: the dungeon builder pathfinds through those as if they were traversable, and then replaces them with floor tiles to make them actually traversable 17:05:57 i had hoped to fix this by (1) allowing it to overwrite trees from the layout, and (2) changing layouts to set trees as MMT_VAULT if they are trees that should not be overwritten 17:06:26 <|amethyst> amalloy: hm, does it check MMT_VAULT for the walls? 17:06:55 <|amethyst> I guess it would 17:06:58 when pathfinding, it respects MMT_VAULT for all tile types. it tries to find a path through tiles that are not vaults 17:07:16 <|amethyst> in what situations would a layout make trees that it doesn't want to be overwritten? 17:07:28 |amethyst: layout_gridlike is the specific one that is known to cause issues 17:07:46 it makes rectangular blocks of, for example, trees 17:07:59 and just carving a path right through the middle would look pretty dumb 17:07:59 <|amethyst> I mean, if you just change it to be willing to path through non-vault trees and erase them 17:08:02 <|amethyst> oh 17:08:15 <|amethyst> but aren't situations like that the problem? 17:08:23 <|amethyst> the zot map for example 17:08:25 it's what causes the zot:5 entrance to get blocked occasionally 17:08:36 <|amethyst> right, and if the layout marks those as MMT_VAULT 17:08:48 <|amethyst> wouldn't that mean that they continue to block the entrance? 17:08:50 |amethyst: then the floor will get vetoed if we can't pathfind through 17:09:03 right now, we successfully pathfind through the trees, but then fail to overwrite them with floor 17:09:20 so it doesn't get vetoed and doesn't become reachable 17:09:25 <|amethyst> hm 17:09:55 the minimal fix is indeed to allow the builder to bulldoze those trees for real reachability, but then the map looks dumb 17:10:04 so i'd like to additionally allow the layout to say "i'd rather you veto this than break it" 17:12:00 <|amethyst> amalloy: hm, still not convinced MMT_VAULT is the right way to do it, but what about using KMASK: t = vault in the layout? 17:12:15 <|amethyst> amalloy: that way the mask gets set when the layout is laid down on the map 17:12:19 <|amethyst> rather than before 17:13:25 |amethyst: i'd rather avoid a tree-specific fix, since this vault can also place boxes made of things other than trees which in principle we might want to treat the same way 17:13:57 <|amethyst> it's not quite tree-specific 17:15:06 I suggested MMT_VAULT on the basis that a bunch of other layouts do that 17:15:08 <|amethyst> you'd want to set the kmask on the relevant squares, but that's no different from setting no_monster_gen 17:15:33 <|amethyst> but the mask should go in the vault's map, not on the level 17:15:36 e.g. https://github.com/crawl/crawl/blob/master/crawl-ref/source/dat/dlua/v_rooms.lua#L370 17:15:51 well, v_rooms.lua is a bit special i think 17:15:55 <|amethyst> hm 17:17:24 here's another: https://github.com/crawl/crawl/blob/master/crawl-ref/source/dat/dlua/layout/hyper.lua#L193 17:17:24 I should add that I have only the vaguest idea what the things I'm linking to do overall :) 17:17:45 I guess those two are the only two 17:18:36 <|amethyst> hm, maybe those two are happening after the layout gets placed? 17:18:43 <|amethyst> and the one you're adding before? 17:18:53 https://github.com/amalloy/crawl/tree/tree-debug is what i've got so far 17:19:25 i'm setting the flag while building the layout, so probably what |amethyst says is right 17:20:04 <|amethyst> yeah, if you look at the v_rooms code for example 17:20:19 ah 17:20:27 <|amethyst> it uses that vaults_get_usage thing 17:20:27 hm 17:20:39 i couldn't figure out what the deal was with vaults_get_usage 17:21:25 I'm back to not understanding how join_the_dots_pathfind works, then 17:21:38 I guess it's just assuming that holes can be punched through anything non-vault? 17:21:46 yes 17:21:46 <|amethyst> probably, yes 17:21:59 <|amethyst> I don't know why it would be failing to punch holes through trees in fact? 17:22:05 <|amethyst> I mean, without looking at the code 17:22:09 that's just a bug 17:22:17 I think amalloy has an easy fix for that 17:22:27 they aren't overwriteable 17:22:31 yes, it's easy to allow it to punch through trees 17:22:33 !source overwriteable 17:22:34 Can't find overwriteable. 17:22:48 it just means we'll have dumb-looking broken tree vaults from this layout 17:23:06 so i was hoping to let the layout prefer veto rather than overwriting 17:23:06 <|amethyst> advil: that's a parameter to join_the_dots 17:23:14 <|amethyst> defaulting to _feat_is_wall_floor_liquid 17:23:24 ah right 17:23:54 !source _feat_is_wall_floor_liquid 17:23:55 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/dungeon.cc#L5804 17:24:00 <|amethyst> amalloy: I think you can do as v_rooms does, and: 1. while building the layout, keep track of the squares you want to be MMT_VAULT 2. after placing the layout, apply MMT_VAULT to those squares 17:24:17 plus some weird branch-specific stuff with trees 17:24:20 |amethyst: that makes sense to me, but i don't know where "after placing the layout" is 17:24:25 <|amethyst> oh 17:26:38 <|amethyst> amalloy: I don't either 17:26:55 rip 17:28:05 <|amethyst> amalloy: ah, the vaults stuff does things weirdly 17:28:51 <|amethyst> amalloy: it has this paint_vaults_layout that does the actual changing of grid, in hypervaults.build_layout 17:29:01 <|amethyst> amalloy: and the rooms come after that 17:30:40 03MarvinPA02 07* 0.21-a0-464-g0a5f80b: Remove wands of lightning 10(32 minutes ago, 33 files, 42+ 107-) 13https://github.com/crawl/crawl/commit/0a5f80b8e118 17:30:40 03MarvinPA02 07* 0.21-a0-465-g8120a92: De-pluralise an acquirement prompt entry 10(55 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/8120a92d9ce2 17:31:20 uh oh, now that player with the zot issue is really stuck! 17:33:32 looks like it's offline tiles, so they'd have to work at it to update 17:35:37 <|amethyst> yeah, I guess vaults is just weird and does the "painting" of dgn.grid itself rather than putting things into the layout vault's map 17:36:18 <|amethyst> hm, yeah, not having a wand type that can burn trees seems limiting 17:36:29 <|amethyst> maybe digging could just be made to work with trees 17:36:40 <|amethyst> or at least one tree at a time 17:38:12 gammafunk: it seems weird to still have the recharge effect exist but be #ifdef'd out instead of just removing it outright 17:38:16 it doesn't really function anymore 17:38:30 MarvinPA: live pakellas games 17:38:37 since if you want to use it you have to make sure never to pick up multiples of a wand type 17:38:39 it felt weird to remove the primary god ability 17:39:01 i don't think those are worth caring about 17:39:17 well, I think that was the main basis for me doing that ifdef 17:39:25 so if you'd like to remove it completely, feel free 17:39:31 !lm * alive trunk pakellas x=cdist(name) 17:40:04 rip wand of lightning 17:41:11 at least I can't recall any other technical reason why recharging needs to exist 17:41:11 90s limit exceeded: killed !lm * alive trunk pakellas x=cdist(name) 17:41:12 MarvinPA: do we actually have a way to prevent people from reading those scrolls? 17:41:21 if we remove the recharging code, the scroll needs to not cause a crash 17:41:27 since live games will still have it 17:41:28 gammafunk: turn them into scrolls of junk on load 17:41:32 can you turn it into a scroll of removedness? 17:41:36 like when we remove wand types 17:41:37 ^ 17:41:42 <|amethyst> hm 17:41:43 but that's not what we do 17:41:49 we don't change types of wand of confusion 17:41:49 sure, or just a "sorry, this has been removed" message like lots of other removed things have 17:42:05 we have a special array and the evoke code has a check for this 17:42:13 -!- Adeon_ is now known as Adeon 17:42:17 not sure that the scroll code has this check (if it does, then that's great) 17:42:39 gammafunk: i disagree that that's not what we do. we're inconsistent: we've done both 17:42:57 you mentioned wand types! 17:43:21 what you suggested isn't what we do for wands, is what I was saying 17:43:46 and all I'm basically saying is that it's fine to do it, just that we need to not have a crash for existing scrolls 17:44:05 like currently you can quaff potions of restore ab 17:44:09 %git 77aac2f2795b95fad100266cf4aac3e15a38333e 17:44:09 07PleasingFungus02 * 0.18-a0-1209-g77aac2f: Wands: draining -> acid, fireball -> iceblast 10(1 year, 10 months ago, 32 files, 91+ 84-) 13https://github.com/crawl/crawl/commit/77aac2f2795b 17:44:10 I believe... 17:44:27 is what i was thinking of 17:44:44 but i agree that's a little different since it redefined wands rather than just removing some 17:44:51 yep, and it still works 17:45:02 what do you mean? 17:45:14 amalloy: well no, you were suggesting actually changing wand type upon load, e.g. in tags.cc 17:45:19 that's not how we handle wands 17:45:28 er changing scroll type 17:45:53 we have a special array and we compared wands to that; that code might work just fine for scrolls, but wasn't sure if it does 17:45:59 does that have all those curse scrolls? 17:46:03 I recall it not having them 17:46:11 <|amethyst> which array, removed_items? 17:46:23 yes 17:46:23 <|amethyst> yeah, they're all there 17:46:24 %git a6f70389726882b49cefdd3ad54c8da740edf40a 17:46:24 07MarvinPA02 * 0.20-a0-320-ga6f7038: Remove wands of hasting and teleportation 10(12 months ago, 41 files, 52+ 280-) 13https://github.com/crawl/crawl/commit/a6f703897268 17:46:32 ah, it does indeed 17:46:45 cool, if that prevents use of the scroll, well I can probably test that 17:47:04 ...nope 17:47:05 it doesn't, currently you can read the scroll and it works 17:47:09 it allows me...yeah 17:47:14 probably we should change that 17:47:56 huh, why wouldn't we remove the elf/forest runes? 17:48:04 yeah I wasn't sure about that comment 17:48:21 also, that bug that amalloy was working on is maybe a little more important now that wands of lightning are removed 17:48:23 <|amethyst> enchant weapon II and III get replaced in tags.cc though 17:48:39 <|amethyst> gammafunk: there are also places that deliberately put things behind trees 17:48:45 yes, that's true 17:48:48 the lair end 17:48:54 the lair end doesn't any more, does it? 17:48:57 (that could simply be modified) 17:48:59 it shouldn't do 17:49:02 oh, was it changed? 17:49:03 <|amethyst> ah, maybe that was fixed 17:49:03 I think it uses a statue? which isn't much better 17:49:04 since trees are opaque now 17:49:27 <|amethyst> digging works on statues now that disint doesn't, right? 17:49:35 but iirc I changed statues so they can be dug 17:49:40 or 17:49:42