00:27:02 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.22-a0-469-gf26638a (34)
01:27:17 <Gretell> Unstable branch on crawl.develz.org updated to: 0.22-a0-469-gf26638a (34)
01:56:39 <Gretell> Windows builds of master branch on crawl.develz.org updated to: 0.22-a0-469-gf26638a
02:58:37 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.22-a0-469-gf26638a
03:48:35 -!- amalloy is now known as amalloy_
07:57:53 -!- NomiAtWork is now known as Nomi
11:09:36 <muffindrake> The syntax highlighting file for vim provided in the crawl tree seems to wrongly highlight 'strings', even inside vaults
11:11:22 <muffindrake> https://i.imgur.com/dCPcRqi.png
11:11:24 <muffindrake> for example
11:12:27 <muffindrake> double quotes are also affected
11:13:53 <muffindrake> Oh, nevermind
11:14:11 <muffindrake> It seems that the correct syntax highlighting script wasn't actually being executed
11:14:21 <muffindrake> d'oh
11:15:22 <muffindrake> The ftdetect line has to be changed from
11:15:29 <muffindrake> au BufRead,BufNewFile *.des set syntax=levdes
11:15:32 <muffindrake> to
11:15:35 <muffindrake> au BufRead,BufNewFile *.des setf levdes
11:19:59 <aidanh> interesting; that change breaks auto-highlighting for me
11:20:49 <muffindrake> Well the existing script suggests the former line, which just doesn't work for me at all
11:22:35 <aidanh> possibly your vim auto-set some other filetype, with its own syntax highlighting rules
11:22:43 <aidanh> no matter, as long as it works
11:24:42 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:24:50 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:24:57 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:25:01 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:25:50 <gammafunk> muffindrake: if you're looking for vaults to make, ghost vaults are a thing we need right now
11:26:19 <gammafunk> oh, zotdef, how we've missed you
11:26:43 <muffindrake> Is that an active PR with examples of existing vaults?
11:27:01 <muffindrake> Also, to sanity-check my setup, is it supposed to look anything like this?
11:27:03 <gammafunk> yes, let me give you a link
11:27:04 <muffindrake> https://i.imgur.com/EEj4veQ.png
11:27:29 <muffindrake> just give me the PR number and I'll fetch it myself
11:28:01 <gammafunk> well, that color scheme and font size makes my eyes bleed, but it seems to have distinct colors for all the right thing
11:28:04 <gammafunk> *things
11:28:56 <muffindrake> It's not optimized to look good/read well with crawl vaults, obviously
11:30:41 <muffindrake> https://github.com/crawl/crawl/pull/700
11:30:43 <gammafunk> muffindrake: https://cdn.discordapp.com/attachments/205316046230388737/455755717253660683/unknown.png
11:30:44 <muffindrake> Is this it?
11:31:20 <gammafunk> yes, see the ghost.des and vaults_room_ghosts.des files
11:31:25 <gammafunk> in the latest commits in that branch
11:31:29 <muffindrake> Urgh, black on white
11:31:35 <muffindrake> you paper apologist
11:31:49 <gammafunk> we use it on paper for a reason!
11:32:13 <gammafunk> I don't think our vim colors are actually ideal though
11:32:24 <gammafunk> for non-predefined glyphs, just too much becomes the same color
11:32:47 <muffindrake> It's more the case that the syntax highlighting file pretends that a one-size-fits-all approach works
11:33:03 <gammafunk> those magenta H, and that same color is used for too many other glyphs
11:33:30 <gammafunk> well I don't pretend to be a vim syntax highlighting expert, but I think there are some fundamental limitations do what it can do
11:33:56 <gammafunk> there are other issues like how it's not written to handle interspersed lua that we often use in DES
11:34:25 <gammafunk> through those colon-delineated lua lines
11:34:33 <aidanh> yeah, was just about to mention that: all the disconnected elseif's are highlighted as syntax errors for me
11:34:41 <gammafunk> if you try to make if statements, it sees the subsequent conditions as disconnected
11:34:56 <gammafunk> ideally it would assemple those all into one lua "block"
11:35:12 <gammafunk> *assemble
11:35:12 <gammafunk> which should even include any interspersed {{ }} blocks of lua
11:35:32 <gammafunk> probably our approach to DES syntax is itself to blame
11:35:39 <gammafunk> it has maybe just too much flexibility
11:36:19 <gammafunk> but I don't know what kind of representation would be superior
11:36:47 <muffindrake> :setf plain
11:38:11 <gammafunk> I guess a modern game would simply have a non-human-readable format and would have a nice graphical program for all of this
11:38:36 <gammafunk> hell, even classic doom has that, and that's not a modern game!
11:38:41 <Pinkbeast> gammafunk: At least DCSS is better off than that
11:39:03 <aidanh> the syntax stuff isn't ideal, but it's not exactly a pressing issue demanding attention
11:39:26 <gammafunk> well, I'm not commenting to say that it is pressing
11:39:39 <gammafunk> just that it's a general problem
11:40:01 <gammafunk> I would certainly not at all mind someone giving it proper attention, for instance
11:40:10 <gammafunk> but yeah, it's not an easy problem to solve certainly
11:40:33 <gammafunk> a nice graphical vault editor would be lovely
11:40:37 <gammafunk> ??vaultedit
11:40:37 <Sequell> vaultedit[1/2]: Vault editing tool originally by nooodl, now hosted and developed by rangerofthewest: https://crawlerofthewest.github.io/vault/
11:40:41 <aidanh> right, that'd be very welcome, but I for one wouldn't want to delve into the bowels of vim's syntax highlighting architecture just for this
11:41:05 <gammafunk> oh, yeah I'm not really talking about syntax highlighting here
11:41:27 <aidanh> ah, I misunderstood then; vault definition in general?
11:41:30 <gammafunk> yes
11:41:39 <gammafunk> but as far that, this is more what tedronai and myself did recently: try to improve the highlighting file we have
11:41:59 <gammafunk> he spent a bunch of time making it more consistent, and I extended it to support a few more thinks, like multiline lua markers and other cleanups
11:42:10 <gammafunk> it certainly could use more work if anyone is interested, since I'm not super happy with it still
11:42:26 <gammafunk> namely for any vault that makes extensive use of non-predefined glyphs
11:42:37 <gammafunk> too many predefined glyphs seem to be sharing the same color with those
11:42:48 <gammafunk> and it makes those vaults actually a bit less readable than before our changes imo
11:43:56 <gammafunk> https://cdn.discordapp.com/attachments/205316046230388737/455759020133711886/unknown.png
11:43:59 <gammafunk> example of what I'm talking about
11:44:20 <gammafunk> notice how 'n' and 'G' share colors with all the non-predefined glyphs
11:44:44 <gammafunk> I guess we could have item list glyphs on their own color potentially as well, but honestly those get used for non-items quite a lot so I'm not sure it's wise
11:44:59 <aidanh> hm yeah I see what you mean
11:45:15 <gammafunk> it's really the 'n' that's the biggest culprit there
11:45:15 <aidanh> I imagine that'd be hard to fix robustly; there's only so many terminal colours and I doubt they could be dynamically allocated
11:45:43 <gammafunk> yeah, I'm not very good with vim and I don't know if there's a way to improve
11:46:32 <gammafunk> but I think I will try to see if 'n' can get another color at least
11:46:57 <gammafunk> maybe just give it the same color as 'c'
11:47:11 <aidanh> it might be possible to use 24-bit colour to get a wider set of colours, if your terminal supports that
11:47:42 <gammafunk> hrm, well this is actually "gvim", but that's a good point
11:49:04 <gammafunk> muffindrake: we need ghost vaults for basically all depths, but earlier dungeon levels are a good priority
11:49:53 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:50:22 <gammafunk> for early dungeon we basically have one single-ghost vault, a couple hard vaults at lower weight, and two somewhat easier ones at normal weight
11:50:22 <aidanh> I get the impression it's not possible to specify both monster and floor, correct?
11:50:42 <gammafunk> monster and floor?
11:51:08 <gammafunk> not sure what you mean by that
11:51:17 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:51:22 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:51:51 <aidanh> e.g. 0s and 9s on top of w
11:52:01 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:52:03 <aidanh> although I'd imagine it's possible with lua
11:52:06 <gammafunk> yes, you can
11:52:14 <gammafunk> simply KMONS: D = 0
11:52:15 <gammafunk> will work
11:52:25 <gammafunk> and then KFEAT: D = w
11:52:35 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:52:39 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:52:47 <gammafunk> obviously you wouldn't want to do that specific combo, since the 0 may not be able to live on w
11:52:57 <gammafunk> unless you meant W (shallow water), but yeah you can do this
11:53:44 <aidanh> hrm, I see, that makes sense
11:56:13 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:59:57 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
11:59:59 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
12:01:29 <aidanh> yeah, that's something that's definitely non-obvious in the online vault-editor
12:03:31 <gammafunk> oh, yeah
12:03:51 <gammafunk> I think the behaviour of those K statements in general is fairly confusing
12:04:22 <gammafunk> for instance if you try to define a monster list with MONS and also use KMONS (because you need to place some monsters on non-floor features)
12:04:39 <gammafunk> you really don't want to intersperse them as sequences
12:04:49 <gammafunk> doing e.g. MONS: first monster, second monster
12:04:56 <gammafunk> KMONS: 3 = third monster
12:05:01 <gammafunk> then MONS: fourth monster
12:05:19 <gammafunk> I think it just doesn't work since those are separately maintained lists
12:05:41 <gammafunk> so basically at some point use of KMONS messes up further use of MONS
12:06:14 <gammafunk> well it does if you use sequential glyphs like that, so vault makers tend to put KMONS on non-number glyphs a lot of the time
12:07:22 <aidanh> as in, the KMONS breaks the MONSs into two separate lists, when they should be one contiguous list?
12:08:57 <aidanh> that sounds pretty idiosyncratic, but then I have only a passing familiarity with vault syntax
12:13:25 <gammafunk> aidanh: what happens is that MONS is just maintaining its own list, and KMONS doesn't care about this list, all of those 'K' statements use a hash system where the key is the glyph and the value is after e.g. '3 ='
12:13:51 <gammafunk> MONS just is a vector though, and MONS doesn't know about what KMONS has
12:14:52 <gammafunk> so I think one definition for 3 will be finally used, the KMONS 3 = third monster or the MONS third entry, which is fourth monster
12:15:22 <gammafunk> right, this is sort of coming back to me, and the K statements all coordinate since they all see the same set of keys
12:15:50 <gammafunk> allowing you to have KITEM: 3 = ..., KMONS: 3 = ..., KFEAT: 3 = ...
12:16:19 <gammafunk> but there's no coordination with the other corresponding MONS and ITEM statments, which can also define these glyphs
12:17:14 <aidanh> ok, that makes sense; it feels almost like vault assembly code
12:17:14 <gammafunk> so if you define a glyph both with MONS or ITEM and also with a K statement, only one definition of that glyph is used, I think the K statement one
12:17:34 <gammafunk> heh, that's an interesting analogy
12:17:38 <gammafunk> it kind of is, I guess
12:20:19 <aidanh> so just to make sure I understand this
12:20:31 <aidanh> KMONS, KFEAT, etc map a placeholder to a monster, feature, etc
12:21:13 <aidanh> and MONS declares (part of) an array of monster types that are substituted for 0, 1, 2, ...
12:21:43 <aidanh> and when generating a cell, K* is consulted first
12:22:35 <aidanh> it sounds like it should just be a hard error if K* overlaps with a MONS entry
12:24:20 <aidanh> separately, this format is very graphical editor unfriendly
12:25:12 <aidanh> well, to clarify, I mean editors that expose terrain, items, and monsters as separate 'layers'; that implies some sort of placeholder allocation on save
12:25:54 <aidanh> although the interspersed lua would also be a challenge
12:31:30 <gammafunk> aidanh: I actually don't know about the resolution order for sure, I'd have to check
12:32:07 <gammafunk> aidanh: also, 0 is not defined by MONS, it starts at 1
12:32:17 <gammafunk> 0 is just pre-defined for "random level spawn"
12:32:25 <aidanh> ah, right
12:33:01 <gammafunk> but I recall that if you define e.g. MONS: first monster and then do KITEM: 1 = item
12:33:01 <gammafunk> either the monster or the item will not place when you use 1
12:33:09 <gammafunk> you have to use KMONS: 1 = first monster
12:33:54 <gammafunk> and there are other keyed statments like KPROP and KMASK which use the same system I think
12:35:18 <gammafunk> aidanh: and yeah, I think the format we have is extremely centered on text editor convenience; obviously if we had a bonafide graphical editor that supported everything we needed, we could use a much different format
12:35:30 <gammafunk> of course there's the work of trying to convert existing vaults to this new format in that case
12:39:37 <aidanh> yup
12:40:30 <aidanh> I was considering adding a vault editor to crawl itself, but it's the sort of thing that probably couldn't share much code between all three implementations
12:42:27 <aidanh> hm, perhaps just a vault testing mode/command would be good
12:42:45 <aidanh> basically a command that reloads a vault from disk, then generates a level with just that vault
12:43:04 <aidanh> perhaps this already exists?
12:45:31 <wheals> as far as i know there's no way to load vault changes without restarting crawl
12:47:08 <aidanh> well, that might be worth looking into, just to cut down on iteration time; bonus points for hot-reloading on file write
12:49:04 <gammafunk> aidanh: yeah, it would be convenient; could you somehow just reload the des files and resume the in-progress (wizmode) game?
12:49:14 <gammafunk> and just allow the user to proceed to use &P or &L
12:50:31 <gammafunk> I guess by "resume the in-progress game" I mean you use a wizmode command that reloads the des files and after this is complete, you can use &P and have the new vault def place
12:50:37 <aidanh> !source reread_maps
12:50:37 <Sequell> 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/maps.cc#L1478
12:51:09 <gammafunk> heh, interesting
12:51:55 <gammafunk> yeah that comment mentions some things I was sort of wondering about
12:52:18 <gammafunk> it's true that crawl presently aborts startup when it can't parse a map
12:52:33 <aidanh> &P generates an entire level around a vault; what I had in mind is to generate a level with a single vault only
12:53:03 <gammafunk> that is maybe an interesting idea just on its own since in many cases the surrounding level is a nuisance mostly
12:53:11 <aidanh> right, exactly
12:54:02 <aidanh> I'm not sure how one would handle placing player in a densely packed vault with no space; maybe have some sort of arena-like mode?
12:58:20 <gammafunk> yeah I guess you hve to define what you mean by "generate a level" a bit more precisely
12:59:02 <gammafunk> just an open layout with no features, place the vault, then place the player close to the vault connector (or just do the vaults MASK)
12:59:25 <gammafunk> if you don't use a normal layout, you don't get to see any of the interactions of the vault's connectors with an actual layout
13:00:22 <gammafunk> but if you use an actual layout, how do you build the level; just pick a layout and place only the vault you want, trying to put a stair near this vault?
13:00:32 <gammafunk> that way the player will generate next to the vault
13:00:51 <gammafunk> I guess even then you have to make the player generate on that specific stair
13:01:54 <gammafunk> when you generate a level, the player will start on a random upstair (or the branch entry), iirc
13:10:38 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.22-a0-469-gf26638a (34)
13:12:10 <aidanh> this might be better as a separate mode; that way the player can be hidden entirely, and there's more control over level gen/placement
13:12:20 <aidanh> e.g. you could show connectors with @
13:12:35 <aidanh> it'd be more work though
13:12:37 <gammafunk> oh yeah
13:12:53 <gammafunk> hrm, that does limit use of the mode a bit, I guess
13:13:07 <gammafunk> aidanh: could you somehow just allow the player to enter the map where they choose?
13:13:25 <gammafunk> but right, I guess it would be more work either way
13:14:22 <aidanh> well, the vast majority of & commands are not that useful for a vault viewer anyway, because your changes are not persisted
13:20:49 -!- amalloy_ is now known as amalloy
13:36:50 <aidanh> gammafunk: wrt making the map border permarock, do you have any idea how that might affect level generation?
13:38:19 <aidanh> e.g. there are some V floors which have lots of rooms in an otherwise full 80x70 open area
13:45:59 <gammafunk> aidanh: I thought that all levels have a permarock border already
13:46:48 <aidanh> well, it's non-modifiable, but it's otherwise indistinguishable from regular terrain
13:47:01 <aidanh> https://crawl.develz.org/tavern/viewtopic.php?f=8&t=25453
14:27:42 <muffindrake> Does a ghost vault need to _strictly_ be recognizable as such by making the ghost visible?
14:30:33 <muffindrake> I can imagine that runed doors are already a fair warning
15:04:23 -!- Suika is now known as erkin
15:12:48 <gammafunk> muffindrake: Yeah, that's what we're going for with those vaults; the player should always be able to see a ghost and examine it
15:13:05 <muffindrake> Alright, I can live with that
15:13:07 <Henzell> atrodo (L12 FeCj) ASSERT(m) in 'mon-util.cc' at line 1978 failed. (Zot (ZotDef))
15:13:28 <gammafunk> now this does not require that all other monsters in the vault be visible, however runed door/transporter vaults tend to be better when that is th ecase
15:13:37 <gammafunk> since the player can reason better about whether to attempt the vault
15:14:10 <gammafunk> but obviously a number of these vaults don't show any monsters at all, or even loot, and you just have to see (or read des file spoilers)
15:16:53 <muffindrake> Alright
15:17:35 <muffindrake> Now, besides that, your ghost_ooze vault has a few stray translucent walls at the bottom that didn't seem like they should be there
15:17:53 <muffindrake> and ghost_spectres has a double MAP directive
15:17:59 <muffindrake> gammafunk:
15:18:18 <gammafunk> oh, yeah, let me take a look
15:18:37 <gammafunk> I have to make a lot of continuous edits to these as I go
15:18:52 <gammafunk> and do a final round of more rigorous placement testing when I'm sure they're really done
15:19:00 <gammafunk> so some things like that will still be present
15:19:20 <muffindrake> I'll PR to the fork once I have come up with some
15:19:33 <gammafunk> no, those are intentional, the transparent rock
15:19:41 <muffindrake> What for?
15:19:43 <gammafunk> you'll find that if there was only one tile
15:19:49 <gammafunk> it's somewhat difficult to fully see in the vault
15:19:56 <gammafunk> so that's to give the player more places to look in
15:20:20 <gammafunk> if you're talking about the 4 'n' glyphs used in the vault
15:20:30 <gammafunk> if there were only 2, it's harder to get a good view inside
15:20:36 <muffindrake> Not _in_ the vault
15:20:42 <gammafunk> ah, I see, yes
15:20:50 <muffindrake> appended to the bottom
15:20:50 <gammafunk> yeah, you're right those are erroneous
15:20:55 <muffindrake> yay
15:21:13 <gammafunk> and yeah I see the other map
15:21:16 <gammafunk> I'll fix those and push; that will get squashed in the merge anyhow
15:21:50 <gammafunk> in terms of commits, we don't really want a ton of little fixup commits in at the time of merge
15:22:05 <gammafunk> it's fine of fixes get noticed later and individual commits get made, of course
15:25:05 <Cheibriados> 03gammafunk02 07https://github.com/crawl/crawl/pull/700 * 0.22-a0-390-g02dc908: Some ghost vault fixes 10(70 seconds ago, 1 file, 0+ 2-) 13https://github.com/crawl/crawl/commit/02dc908c14a3
15:25:07 <Cheibriados> 03gammafunk02 07[spooky_vaults] * 0.22-a0-390-g02dc908: Some ghost vault fixes 10(72 seconds ago, 1 file, 0+ 2-) 13https://github.com/crawl/crawl/commit/02dc908c14a3
15:30:28 <muffindrake> @?bone dragon
15:30:28 <Gretell> bone dragon (15D) | Spd: 10 | HD: 20 | HP: 146-208 | AC/EV: 20/4 | Dam: 30, 2009(claw), 2007(trample) | 07undead, evil, see invisible, fly, unbreathing | Res: 06magic(100), 05fire, 02cold, 10elec, 09poison+++, 12drown, 04rot+++, 13neg+++, 13torm | Vul: 08holy | XP: 3688 | Sz: Giant | Int: animal.
15:30:31 <muffindrake> @?golden dragon
15:30:31 <Gretell> golden dragon (08D) | Spd: 10 | HD: 18 | HP: 86-126 | AC/EV: 15/7 | Dam: 40, 2009(claw), 2007(trample) | see invisible, fly | Res: 06magic(180), 05fire, 02cold, 10elec, 03poison, 12drown | Chunks: 14noxious | XP: 4178 | Sp: b.fire (3d27) [11!AM, 06!sil, 08breath], b.cold (3d27) [11!AM, 06!sil, 08breath], poisonous cloud (3d11) [11!AM, 06!sil, 08breath] | Sz: Giant | Int: animal.
15:32:09 -!- |amethys1 is now known as |amethyst
15:33:43 <muffindrake> Are bone dragons actually used anywhere aside from vault?
15:33:46 <muffindrake> I mean abyss
15:33:48 <muffindrake> ??bone dragon
15:33:49 <Sequell> bone dragon[1/1]: Undead dragon with no breath weapon but good AC, resists, and melee damage. One of the two best (and capped) gifts Yred can grant.
15:34:22 <|amethyst> they're also used in the Hells
15:35:20 <muffindrake> I'm trying to determine whether they'd be a good fit for Depths-level ghost vaults
15:35:40 <muffindrake> probably too hard though
15:39:13 <gammafunk> muffindrake: they'd be fine in non-excessive quantities, they're really not too difficult
15:39:18 <gammafunk> I think they're used in a few depths vaults
15:39:57 <muffindrake> @?bone dragon simulacrum
15:39:57 <Gretell> unknown monster: "bone dragon simulacrum"
15:40:04 <muffindrake> Aww
15:40:06 <gammafunk> yeah, they don't leave a corpse
15:40:17 <wheals> bone dragon skeleton
15:40:18 <gammafunk> they're not a very interesting monster in the sense that they just resist a lot and have a lot of hp/defenses
15:40:31 <gammafunk> kind of like a tmons with trample instead of constrict
15:41:00 <gammafunk> but they're not too different from just a golden dragon really
15:42:10 <muffindrake> except golden dragons are significantly more threatening to characters without res
15:42:22 <gammafunk> well that's the thing about depths characters, they tend to have rF and rC
15:42:43 <gammafunk> you can think of them as kind of like a sturdier golden dragon that will persist longer and hassle the player while they're trying to deal with other things
15:44:14 <muffindrake> What about multiple ghosts in 1 vault? Should that be avoided?
15:44:35 <gammafunk> I'm going to make one of those myself, it will have 2-4 ghosts (and only those ghosts as monsters)
15:44:49 <gammafunk> obviously you don't want to go overboard with this, but sure you can make a vault like that
15:45:16 <muffindrake> I've had one in mind with 4, just with independent access to each, i.e. you'd never be fighting more than 1
15:45:20 <muffindrake> ideally
15:45:41 <gammafunk> well, I'm not a huge fan of this in that it's not really different from just an individual vault
15:46:11 <muffindrake> Ah, fair
15:46:12 <gammafunk> but at the same time it's ok to have a vault like that, since it's thematic at least
15:46:31 <gammafunk> so if you want to make one that's like a little ghost "prison", you could
16:00:48 <Henzell> minotr (L16 HuWn) Crash caused by signal #11: Segmentation fault (Abyss:2)
16:05:11 <muffindrake> What if a ghost vault wants to place a ghost, but there are no bones to do so?
16:05:26 <muffindrake> Wait, the question is wrong
16:05:40 <muffindrake> and unnecessary
16:05:54 <muffindrake> I presume the dungeon builder will check for bones before trying to place a ghost vault
16:07:13 <gammafunk> no, that's a good question, but it actually doesn't work that way
16:07:27 <gammafunk> see the previous commits in that PR for full details, but he synopsis is that there's a ghost permastore
16:07:48 <gammafunk> so that's a longterm source of ghosts if the bones file is empty at the time
16:08:10 <gammafunk> and if the permastore is empty (for instance after this branch is merged, it will be), the ghost is a clone of the player
16:08:49 <gammafunk> by clone I mean it's a ghost made from the player at the time of level gen
16:08:57 <muffindrake> I see
16:09:09 <muffindrake> That will actually allow offline players to see those vaults, too
16:09:13 <muffindrake> more foten
16:09:14 <muffindrake> often*
16:10:18 <gammafunk> the vaults have a fixed chance of 10% per level
16:10:39 <gammafunk> CHANCE is a way you can give a vault a fixed chance of generated on its relevant levels
16:13:14 <muffindrake> Well, yeah, 10% is a better chance than 0%
16:16:54 <gammafunk> It's not just the low end of placements, but also the top end; how many ghosts there are in a bones file no longer influences placement of ghosts at all
16:42:20 <muffindrake> What depth is considered appropriate for a flayed ghost?
16:54:59 <gammafunk> muffindrake: if you want a guide, look at mon-pick-data.h, the pop_BRANCH data
16:55:10 <gammafunk> where BRANCH is the lower-case name of the branch
16:55:18 <gammafunk> find the entry in that branch for flayed ghost
16:55:38 <gammafunk> for Dungeon they're always out-of-depth, so maybe D:13-15 if you want a nasty monster
16:55:45 <gammafunk> for Depths it's probably most of the branch
16:55:59 <gammafunk> but the first two entries for the monster give the range of placement
16:56:22 <gammafunk> and you can also look at the weight relative to other monsters, but you don't have to be too subtle about it
16:56:52 <gammafunk> they're like a weaker tormenter; you don't want to place too many of them, but they're something a Depths character should be able to generally deal with
17:01:06 <muffindrake> Alright, thanks a lot again :)
17:31:04 <advil> !crashlog minotr
17:31:20 <Sequell> 1. minotr, XL16 HuWn, T:30678 (milestone): http://crawl.akrasiac.org/rawdata/minotr/crash-minotr-20180611-200047.txt
17:31:51 <advil> heh that player had some good timing for that crash, as long as it didn't save
17:36:42 <muffindrake> >Compiled with GCC 4.7.2 on Jun 11 2018 at 10:10:10
17:40:44 <muffindrake> A fresh 6 years old
17:41:05 <muffindrake> nothing to do with the crash necessarily, just felt the need to point that out ...
17:41:51 <advil> I'm not sure I'm following
17:42:17 <amalloy> GCC 4.7.2 was released September 20, 2012
17:42:23 <advil> ahh
17:42:47 <muffindrake> Doesn't even debian stable come with gcc 6.3 now?
17:55:53 <gammafunk> well people don't upgrade their servers very often, especially for game servers
17:57:35 <Cheibriados> 03floraline02 07https://github.com/crawl/crawl/pull/784 * 0.22-a0-487-g3de9d90: Disallow password reset if feature is disabled 10(2 hours ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/3de9d90beb2d
17:57:35 <Cheibriados> 03floraline02 07https://github.com/crawl/crawl/pull/784 * 0.22-a0-488-gbff803d: Extract function for recovery token lookup 10(2 hours ago, 1 file, 25+ 13-) 13https://github.com/crawl/crawl/commit/bff803d4135f
17:57:35 <Cheibriados> 03floraline02 07https://github.com/crawl/crawl/pull/784 * 0.22-a0-489-gecf68fc: Report invalid recovery token before showing form 10(5 minutes ago, 2 files, 17+ 2-) 13https://github.com/crawl/crawl/commit/ecf68fcc416a
18:37:00 <alexjurkiewicz> this password reset feature is great
18:37:47 <alexjurkiewicz> !lm * x=cdist(name)
18:39:18 <Sequell> 90s limit exceeded: killed !lm * x=cdist(name)
18:43:15 <alexjurkiewicz> !lg * x=cdist(name)
18:43:21 <alexjurkiewicz> !lm * month x=cdist(name)
18:43:44 <Sequell> 848055 milestones for * (month): cdist(name)=5598
18:44:31 <Sequell> 8983210 games for *: cdist(name)=94879
18:45:03 <muffindrake> I'd like to see passing in username/password via environment variables when playing ssh
18:45:36 <alexjurkiewicz> you and the three other SSH players :P
18:45:37 <|amethyst> muffindrake:  that would need special sshd configuration
18:46:24 <|amethyst> and putting password in an environment variable sounds like a bad idea
18:50:13 <gammafunk> you could probably set up an expect script pretty easilly
18:55:27 <muffindrake> I'm reading about expect for the first time
18:55:47 <gammafunk> I expected you would
18:55:50 <muffindrake> will that even work? The login dialogue doesn't use stdout/stdin directly, it uses ncurses to control the terminal
18:56:09 <gammafunk> yeah, I guess you need something to send some things then return control of the terminal to you
18:56:22 <gammafunk> I'm not sure what people do for that, or if expect can work that way
18:57:15 <muffindrake> If anybody has wrangled with that here, I'd be delighted to hear what you did
18:57:16 <gammafunk> I know elliptic runs qw using expect
18:57:21 <|amethyst> IIRC it's something like "interact"
18:57:27 <|amethyst> in the expect script
19:00:42 <muffindrake> I'll just pester elliptic when he's around
19:03:25 <muffindrake> this stackoverflow answer seems to suggest my suspicions are correct
19:03:28 <muffindrake> https://serverfault.com/questions/357843/scripting-around-curses
19:22:58 <geekosaur> expect works fine for that
19:23:02 <geekosaur> at least for con sole
19:23:22 * geekosaur has some scripts, which need to be updated slightly
19:23:43 <geekosaur> also I should try server play again now that local network doesn;t suck quite so much
19:24:37 <geekosaur> also note that login is not full curses, it's handled by dgl
19:24:52 <geekosaur> which appears to be doing something significantly simplet
19:24:54 <geekosaur> simpler
19:25:49 <muffindrake> I see
19:25:56 <amalloy> muffindrake: when i was using iterm i put my username and password into the "Send Text at Start" setting of a new profile
19:26:59 <amalloy> i don't see any obvious built-in analogue of that in gnome terminal, so i think expect is probably simplest for that
19:31:03 <geekosaur> mine is actually a perl script, and I use a hook in the perl version of expect so I can escape the "interact" loop
19:45:03 <advil> there is an expect script in elliptic's repo
19:45:09 <advil> it worked basically fine for me
19:46:25 <advil> https://github.com/elliptic/qw/blob/master/qw.exp
19:47:29 <advil> not sure it's going to do much for the specific case though
19:55:46 <muffindrake> Eh, expect works just fine
19:59:09 <muffindrake> https://0x0.st/sLza.exp
19:59:14 <muffindrake> Something as simple as this works just fine
20:00:04 <muffindrake> Oh, wait, that's missing an interact line
20:00:23 <muffindrake> http://0x0.st/sLzB.exp
20:47:24 -!- amalloy is now known as amalloy_
21:35:33 <Cheibriados> 03gammafunk02 07https://github.com/crawl/crawl/pull/700 * 0.22-a0-391-g9807dab: A ghost vault that places multiple ghosts 10(17 minutes ago, 2 files, 72+ 0-) 13https://github.com/crawl/crawl/commit/9807dab835ab
21:35:35 <Cheibriados> 03gammafunk02 07[spooky_vaults] * 0.22-a0-391-g9807dab: A ghost vault that places multiple ghosts 10(17 minutes ago, 2 files, 72+ 0-) 13https://github.com/crawl/crawl/commit/9807dab835ab
22:14:38 -!- yesno_ is now known as yesno
22:44:58 <gammafunk> MarvinPA: how would you feel about making xp pots not generate before D:4 like we do with acquirement scrolls (and the other high level scrolls)
22:57:15 <MarvinPA> hm, that stuff is kinda inelegant and has weird implications for tracking unid'd items so i'm not a huge fan
22:57:36 <MarvinPA> i think there used to be more instances of it in the past that have since been removed?
22:58:42 <hellmonk> well alternatively you could remove the existing special cases yeah. It's weird that acq will not generate that early but !xp can though
22:58:48 <MarvinPA> i actually thought it'd been removed for scrolls but i guess not, the other similar thing was the old exceptions for no stacks of multiple xp/acq etc
23:00:23 <MarvinPA> could do some slight depth scaling for very shallow depths rather than a hard cutoff, perhaps
23:06:33 <gammafunk> yeah, I didn't really think about the item tracking aspect
23:07:40 <alexjurkiewicz> are people startscumming for !xp ?
23:07:43 <MarvinPA> would be very minor for !xp in comparison to the existing scroll stuff, but it's still not ideal conceptually
23:09:15 <gammafunk> it's not an issue of startscumming, just that getting early !xp, esp a stack, does make the early game pretty silly, however there are various things that can make the early game silly anyhow
23:09:23 <gammafunk> but that was the basis of hellmonk's request
23:10:13 <hellmonk> right, I got 2 !xp on D:1 and the game gets pretty dumb when you have like 7+ in 3 skills and 50 hp on D:2
23:10:43 <hellmonk> I'm not a fan of tracking where stuff spawns either, imo you have to remove the id game to totally fix this though because vaults that place items exist
23:11:04 <alexjurkiewicz> if dumb games with !xp on d:1 happen sufficiently rarely, is it a problem?
23:11:12 <alexjurkiewicz> It sounds like a nice little treat for the player
23:11:38 <hellmonk> and it's much more likely to get useful info out of "this pot spawned in sewer and is probably flight or curing" than "this pot spawned on D:1 and isn't xp"
23:11:58 <alexjurkiewicz> I remember picking up early !xp maybe once or twice, out of my 2k online games. It seems like an OK rate
23:12:14 <hellmonk> idk, randart generation prohibited on the first couple floors iirc, presumably for similar reason
23:12:57 <hellmonk> ultimately it's fine either way, I just think xp is good enough early that it should be handled consistently with acq or the other "rare" stuff thats currently banned from spawning
23:13:14 <hellmonk> whether that's letting it all spawn whenever or gating xp doesnt matter much to me
23:14:36 <gammafunk> maybe a gradient instead of a hard cutoff would be better, like MPA said
23:14:53 <gammafunk> I mean, you'd still get those 2 !xp on D:1 quite rarely of course
23:15:57 <gammafunk> but if you acquire gold dragon scales on D:4 as a character that can benefit from that, it's kind of similar really
23:16:22 <gammafunk> or just some +10 plate or whatnot
23:16:42 <hellmonk> sure, early acq also busts the power curve pretty frequently
23:20:05 <gammafunk> I guess part of the problem with a gradient is that it's still technically causing you to track items by level
23:23:35 <|amethyst> I see two other solutions for the tracking thing:
23:23:41 <|amethyst> (1) remove identification
23:24:07 <hellmonk> I mentioned that one already
23:24:19 <|amethyst> (2) have the game track it for you (probably where you found the first one); but that still requires spoilers
23:25:10 <|amethyst> I guess there's also the over-the-top (2b) have the game compute and track probabilities for each stack and subtype
23:25:34 <gammafunk> can we add an (a)nalyze entry to the item menu
23:26:09 <hellmonk> some day crawl development will come around to the glorious id-free future
23:26:11 <|amethyst> b - a +3 calculator
23:26:12 <gammafunk> analyze any item, costs MP, hunger, and light drain