01:28:07 <06mumra> I commented on there as the "habitable features" changes look really good independently of the summoning changes and would be good to keep them even if the "sufficient space" part is reworked. (Except for "habital" being a misspell, and possible unintended impacts to general monster spawning and even navigation; the old primary/secondary habitat system was confusing enough but referenced in enough places that it's hard to assess what this 01:28:08 impacts) 01:32:46 <06mumra> Turning it into flags certainly makes things cleaner for wall monsters as they can go in three habitats really and this was fudged in my PR (and potentially to let dryads go back in trees or some other flavourful tree dweller for swamp) 02:32:17 <07wizardike> I'll remove the checks from summon_dragon, should I remove them from summon_spiders? It already has an is_player check 02:53:26 03WizardIke02 07https://github.com/crawl/crawl/pull/4427 * 0.33-a0-1181-ge86591aff9: Don't waste a turn when summoning with no space (NormalPerson7) 10(22 hours ago, 9 files, 506+ 84-) 13https://github.com/crawl/crawl/commit/e86591aff953 03:32:06 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 04:04:48 <06mumra> @wizardike I'm wondering if (as a separate refactor perhaps as you mention) - the original habitat_type enum is pretty much redundant with the flags, and in yaml files we could just list the flags instead (with amphibious as a shortcut for the water, land mask, and amphibious_lava is such an odd case and used for a pretty small number of monsters i think it's fine to just have lava, land for those cases 04:05:56 <06mumra> (i was already thinking about this kind of thing as part of the wall monsters work, just decided not to go down the rabbit hole at that time) 04:07:13 <06mumra> in terms of "primary / secondary" habitat you can just take the first flag listed as primary and everything else is secondary (for the purposes of placement, and maybe it applies to some other things like swimming status?) 04:19:36 <06mumra> (really looking at it, i'd just change habitat_type to be the flags class, that way a lot of code doesn't even need changing) 04:24:26 <07wizardike> I'll give this a go, although, I think only some habitats can be primary habitats as I think the code finds the primary habitat that corresponds to a tile and then spawns a monster with that primary habitat. e.g floor has primary habitat of land so spawns land monster and deep water has primary habitat of water so spawns water monsters meaning monsters with primary habitat of amphibious wouldn't spawn anywhere. There are work arounds 04:24:26 to this but maybe we should determine the primary habitat purely from the habitat like we currently do? 04:26:39 <06mumra> no i'm saying amphibious would be a shortcut for "water, land" 04:26:49 <06mumra> so amphibians primary habitat will still be water 04:27:25 <06mumra> only because amphibian is used in quite a lot of monsters so it's a handy shortcut 04:29:12 <06mumra> (sorry, other way around, amphibians primary habitat is land) 04:33:53 <07wizardike> That does make sense, although, I'm worried that this would brake if we split a category in two later on 04:33:54 <06mumra> what i'm kind of imagining for the final state: - mons_class_primary_habitat still exists and returns a single flag which can be used for the various things that check this (there's some really silly stuff, like catchup_monster_moves won't apply to monsters that don't have land as their primary, maybe this needs reviewing tbh) - mons_class_secondary_habitat maybe goes away, it's used for exactly two things, which could just be replaced 04:33:54 with "is_habitable_feature" i think 04:35:29 <06mumra> i'd rather say it leaves more flexibility if a category is split later on, current system is completely rigid 04:36:24 <06mumra> although i'm not sure if there's a compelling reason to split a category ... this stuff has to be kept simple for players to understand ... we don't want 1000 different combinations of "this monster can go here and here but not here" 04:38:23 <06mumra> for rock fish i considered "maybe they shouldn't go in metal walls?" but ended up at "all walls are the same" 04:41:10 <06mumra> (wondering how it'd look to split shallow and deep water do their own flags, so the various rules can be specified granularly. i don't think anything can't go in shallow water tho. then we have land-based monsters that can still go in deep water 'cos they're giant 04:44:04 <07wizardike> I think currently shallow water spawns land monsters, but I would have to check. Lava monsters can't go in shallow water 04:49:14 <06mumra> oh yeah of course 05:06:58 Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-1192-gbf953fe (34) 05:54:28 New branch created: pull/4431 (1 commit) 13https://github.com/crawl/crawl/pull/4431 05:54:28 03WizardIke02 07https://github.com/crawl/crawl/pull/4431 * 0.33-a0-1193-gdf6a481933: Fix erroneous warning when firing at enemy in front of friendly (dilly) 10(10 minutes ago, 2 files, 14+ 7-) 13https://github.com/crawl/crawl/commit/df6a48193321 06:24:55 <04dracoomega> To be honest, I have no idea why summon_spiders has an is_player check and it probably shouldn't. Like, I can't see us ever using this code as a player spell without modification, especially when sack of spiders already exists. (The inverse of 'player spell whose implementation leaves open future use by monsters' feels a lot more plausible than 'monster spell whose implementation leaves open future use by a player', on a design 06:24:55 level.) 06:25:22 <04dracoomega> (In fact, a few forgecraft spells have done that specifically because I planned to eventually put them on monsters) 06:25:31 <04dracoomega> Just haven't gotten to that yet >.> 06:26:24 <04dracoomega> I question the clarity of writing 'amphibious' instead of 'water, land' if it's being directly translated to the latter without modification or special meaning. It's barely even shorter. 06:26:47 <04dracoomega> (Flags for habitable zones does make some sense in general, though) 06:27:26 <07wizardike> Should I remove the "not enough space" check? Or the whole is_player check even? 06:29:27 <06mumra> yes a fair point 06:29:27 <04dracoomega> I guess I personally feel that this is a monster-only spell and is very unlikely to stop being one. 06:29:54 <04dracoomega> (Maybe that means the actor argument should be changed to a monster one for unambiguity?) 06:33:41 <04dracoomega> I mean this in the least snippy way possible, but it's been unclear to me the value of this. Or like... I can certainly rhyme off a list of things I want to do in future and would like to get to in 0.34, but the list is almost certainly longer than what will actually end up in 0.34, and a bunch of items on the list don't yet have concrete enough plans to say much about (and those details are unlikely to exist until I'm practically 06:33:41 working on the project). And which things I actually get to for 0.34 is going to remain unclear until I'm getting to them (I mean, aside from the 'highest-priority' stuff. I wonder if I worry that a concrete bullet-point plan implies more certainty about order or likelihood of accomplishing in a specific way than I feel I can provide so many months in advance? >.> 06:34:57 <04dracoomega> Even for things I have a more concrete-than-average plan for, like a couple spells, I'm reluctant to say "I am going to add X spell that does Y" until I've tested it enough to feel confident that a spell doing Y actually plays well, instead of just hoping it does. Is this a 'me' problem? ^^; 06:38:17 <04dracoomega> I mean, maybe if it were general enough... 06:42:10 <06mumra> "underpromise, overdeliver" is a fine motto 😉 06:49:32 03WizardIke02 07https://github.com/crawl/crawl/pull/4427 * 0.33-a0-1181-g97ddb25189: Don't waste a turn when summoning with no space (NormalPerson7) 10(26 hours ago, 9 files, 491+ 90-) 13https://github.com/crawl/crawl/commit/97ddb2518977 06:50:16 <04dracoomega> I mean, this isn't (presumably) a promotional page, so if anything was being listed there, I might rather categorize it by certainty (since 'don't say things you're not 100% confident on' leaves it close to empty on details, I think ^^; ) 06:51:34 <04dracoomega> I don't know how many players actually find and read a page like that, of course. (There is a tendency for a bunch of people to make bad assumptions about stuff that's still very incomplete, though. Like, assuming you've just overlooked a whole bunch of things which simply hadn't been gotten to yet >.>) 06:53:14 <04dracoomega> I suppose, while as a player-facing thing, I'm reluctant to promise too much specific, as a dev-facing thing, it's useful to at least give some idea of the subjects that someone might be expecting to tackle. 06:53:37 <04dracoomega> If perhaps broken down into categories of priority/liklihood 07:24:07 <09hellmonk> I think it's intended to be mostly dev facing, based on the previous ones written by ebering 07:27:20 <04dracoomega> I mean, it's inevitable that it gets out and discussed, but I guess so long as it's couched in sufficient caveats, I could try to do up a list later 07:32:56 <12ge0ff> > unclear to me the value of this A document with the dev plans for the next release is the first and essential step for implementing KPIs. Next, we'll need a schedule performance index (SPI), quality metrics, customer satisfaction metrics, and a cost performance index (CPI). (ducks and covers) 07:33:12 <04dracoomega> Wish I could figure out where I stashed that function to print out a 2D table of weights from a population picker 07:33:43 <04dracoomega> (I was about to ask "What the heck is a KPI?" before I got to the rest of the statement >.>) 07:34:08 <04dracoomega> Kaplication Programming Interface 07:34:35 <12ge0ff> imagine programming for fun, without Key Performance Indicators 🙀 07:35:25 <09hellmonk> Kapitalism Profit Increaser 07:35:58 <04dracoomega> Annoying thing is, I have used this on two separate projects already: to see apostle spell chances across all power tiers, and to look at Infernal Servant summon changes by invocations, and yet I still can't figure out what I did with it >.>; 07:36:06 <09hellmonk> anyway, if it's not useful that's fine, I had just noticed that we used to have development plans regularly and haven't done one in several years 07:36:37 <06mumra> @gammafunk It's been pointed out in roguelikes discord that since https://github.com/crawl/crawl/commit/d3ab83ea6940 searching for "hat" now returns all hatches in the game; and on further testing I found that "stone", "air", or even "rC" now returns all stairs in the dungeon. since there are 200+ stairs in a fully explored dungeon this can easily trigger "too many matches" if you're searching for a partial word and accidentally include 07:36:37 stairs (it's matching on the full string "A stone staircase leading [up|down]") This seems certainly unintended... Potentially it'd be more reasonable just to return stairs/hatches on the current level (tho I'm unclear on the specific intended use case for the search when you can already find stairs in the map) but there's not an immediately straightforward way to have a stash item that only normally matches on the current level. Wondering whether to 07:36:38 revert that for now until some further stash UI improvements can be made or if there's another idea to enable this without impacting item searches so badly? 07:37:42 <04dracoomega> No, I think a rough list of "Things I'd like to do (and in approximate priority categories)" is probably useful reference for other people. I just don't think that trying to be highly specific with anything is terribly useful, given how flexible a bunch of these things tend to be between 'getting down to working on it' and 'version pushed to trunk' 07:38:19 <12ge0ff> the 0.34 plans exist not only as a scattered message on this and the roguelikes discord, some players compile the list themselves: http://crawl.chaosforge.org/User:Patrick2011b 07:38:19 <04dracoomega> (And maybe "Development Plan" felt to me like something a lot more exact than that) 07:38:46 <04dracoomega> But I certainly have no problem with 'overview of approximate near-future plans' 07:39:11 <04dracoomega> (I have probably said most everything on it at one time or another already, but of course I can't expect everyone to have seen all of that ^^; ) 07:39:23 <04dracoomega> (Or remember it) 07:39:40 <04dracoomega> (I can't always remember all of it >.>) 07:41:34 <06mumra> Maybe more of a general "roadmap" without committing to specific release targets, unless some has very specifically said something will definitely be in that version (it's also probably a bit early to say what'll be in 0.34 when it's not even finalised what's going to make it into 0.33) 07:42:21 <12ge0ff> iirc, such roadmap didn't work and hence no one bothers making them now 07:43:32 <06mumra> Well nobody uses roadmaps these days, we all have GPS 07:43:55 <04dracoomega> Jokes on you; I don't have a smartphone or a car 😛 07:44:17 <04dracoomega> (Okay, I probably don't have any paper maps either) 07:45:01 <04dracoomega> ...I really am starting to think I have to implement this for a 3rd time now, since I seem completely unabe to find the code that I already used twice >.> 07:46:52 <04dracoomega> I can't believe after I had this problem the last time that I didn't save a copy of it in a more obvious place >.> 08:13:20 <08nicolae> i have a couple ancient ones in my car, i suspect most of them are long out of date, some of them i just have as souvenirs of Travels 08:23:29 <06mumra> how ancient, like this old? 08:23:29 <06mumra> https://cdn.discordapp.com/attachments/747522859361894521/1357012570002817095/Old-world-map.png?ex=67eea7f0&is=67ed5670&hm=559d4e12f89e09b56bee2d64d7436aa82aa75e6fa98eb9bbf91edffc8abee11a& 08:29:45 <08nicolae> i got ones so old they don't even have the new world yet 08:42:30 FR: Reflavour Great Orb of Eyes to the Butatsch Cun Ilgs (TRYPOPHOBIA WARNING: https://abookofcreatures.com/category/switzerland/) 08:42:31 Reasons: 08:42:32 -Further the trend of "X but it's BIG and Y but it's MANY" 08:42:32 -Further steal I mean take inspiration from mythologies and folktales across the globe. This one is ultra rae it's only specific region from a small country with a rather limited pool of myths to pull from and it's certainly unique. Bonus points for being in a super obscure language 08:42:33 -Avoid generic DnD monsters 08:42:33 -It fits pretty well it is covered in eyes and has hypnotic powers 08:42:34 -Might bait peope into looking it up and learn something new 08:42:34 Unreasons: 08:42:35 -The "bone melting flames" part is a bit iffy but I think mindblast is close enough 08:42:35 -Even I don't know how to pronounce it 08:42:36 -Might be too obscure for its own good 08:43:33 The trend of removing* 08:46:23 <08nicolae> no. players should get their bones melted. 08:47:10 03WizardIke02 {GitHub} 07* 0.33-a0-1193-g8ee07ae269: Fix erroneous warning when firing at enemy in front of friendly (dilly) (#4431) 10(9 seconds ago, 2 files, 14+ 7-) 13https://github.com/crawl/crawl/commit/8ee07ae269b7 08:47:51 Merge it with eye of devastation or something 08:48:15 Monsters should have easily spellable names like tzitzimitzl 08:51:01 <04dracoomega> I am not sure if it is ironic or appropriate that you misspelled it 08:51:04 <09hellmonk> wanna get 4424 done soon but I don't know the process for backporting it to old versions 08:51:32 <04dracoomega> I think it's literally just cherry-pick it into the 0.32 branch 08:51:57 <09hellmonk> oh, that's easy 08:52:02 <04dracoomega> (Of course, actual stable offline point releases have to happen deliberately, but I think this works for online) 08:52:29 <09hellmonk> well I think it doesn't matter for online, the bug is in offline tiles 08:52:31 <04dracoomega> ...of course, this fix is irrelevant for online 08:52:33 <09hellmonk> so maybe we don't need to do anything 08:52:44 <09hellmonk> I'll go ahead and merge for now 08:54:36 03WizardIke02 {GitHub} 07* 0.33-a0-1194-g8b514e5c94: Fix a crash when zooming local tiles (sulla) (#4424) 10(41 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/8b514e5c9413 08:56:11 <09hellmonk> Would like an opinion on trove vetoes in 4426 even though I intend for this to be temporary pending trove rework in next version. If this approach seems okay I'll go ahead and merge. 09:03:05 <04dracoomega> Seems vaguely reasonable as a minimal change. (Certainly, 'average of all magic skills with more than 0 skill' doesn't make much sense as a metric for how invested in magic one is. It's very common to have a high skill or two and a tiny bit in a bunch) 09:03:47 <04dracoomega> Although it's also somewhat hard to imagine a character not having 10 skill in some weapon by the time they're opening a trove, unless they're going unarmed (which is part of the point, I guess) 09:04:38 <04dracoomega> But like, I think that's a reasonable 'armed vs. unarmed' but not a reasonable 'caster versus melee character'. But casters often also care about weapons, so it was possibly a silly distinction in the first place 09:05:32 it's a metric for how gnoll or djinn you are in magic 09:06:43 <04dracoomega> Well, I assume (hope) djinn can't get spellbook troves in the first place. (Or do they just get a ton of manuals, maybe?) 09:07:45 <04dracoomega> I guess I suppose it's unclear how much this improves the current state as opposed to just shifting it slightly to one side or the other, but it doesn't seem obviously objectionable to me. (And there's clearly plans for more ambitious changes that will override it anyway) 09:12:17 <09gammafunk> Hrm, that's a good point. Not being able to search for hatches or shafts is a pain though. I can think of two things that would help, along the lines of one of your suggestions. Make searches that hit stairs, hatches, or traps only return these results if either 1) the hit is on the current level or 2) the search is targeting a specific level and the hit is on that level. The second condition is so one could search for a shaft or 09:12:18 hatch on e.g. Vaults:4 while not on Vaults:4 and have it match 09:12:58 <09gammafunk> If those can't easily implemented, then a reversion might be in order. I can certainly take a stab at the implementation at some point this weekend. Not sure if I'll have time tonight, as I want to roll out some changes to cerebot 09:17:56 <06mumra> not matching the entire string would probably be better as well. i can't imagine someone searching for "stone stair", if i wanted stairs i'd want to type either "stair(s)" or "upstair(s)" or "downstair(s)" 09:18:24 <06mumra> i suppose "stair up" "stair down" "hatch up" "hatch down" might be all reasonable as well (still doesn't solve the hat problem tho!) 09:26:24 <04dracoomega> So, I am working on changes to talisman generation / acquirement at the moment, and I am running into the artprops commit that touched talismans and pondering about the consequences of it. Like, randart properties cannot conflict with 'intrinsic' properties of a talisman form, which results in things like randart spider talismans being unable to get rPois on them. But it... doesn't seem wrong to me that a lucky randart could 09:26:24 overcome certain 'weaknesses' in the base form (and, as a player, I actually wouldn't expect rPois to be vetoed on such talismans, since the 'intrinsic' props aren't even listed in property form on it.) 09:27:59 <04dracoomega> And I guess, the more I think about it, the more it feels like randart talismans being able to give you an arbitrarily different set of resistances from the basic form is... perhaps even part of the point? ('This spider is different than other spiders') (Talisman variants that I plan for 0.34 will be even more divergent, potentially, like turning a granite statue into an ice statue or somesuch) 09:28:47 <04dracoomega> So like, I can see vetoing things that are redundant with the base form (ie: death talisman with rPois), but not ones that change a property of the base form 09:30:26 <08nicolae> what if by default, if the search term matches a result whole-word, assume the player is looking for that (so if they do "hat", and a "hat" is found, assume they want hats), and then have an option to be like "increase search for non-whole-word hits?" or something 09:31:05 <08nicolae> does search syntax have any way to specify "this as a word" without having to do whitespace regexes 09:44:15 <06mumra> some kind of "best match" algorithm would be an improvement 09:44:53 <06mumra> if i search for just "ha", daggers are matched simply because they have "sharp" in the description, there's no preference to hats that actually start with those two letters 09:45:37 <08nicolae> is there some way to exclude the descriptions 09:54:54 <09hellmonk> I suspect it's this way just because we do the same thing for equipment artifacts (like dragon scales) 10:32:00 <06mumra> one approach would be to score results based on the quality of the match, and sort by that. so a match in the item name and at the start of a word would be a much better match than in the description or in the middle of the word 10:52:07 <06dolorous_84348> Sounds delightfully bonkers to me. 10:53:06 <04dracoomega> C++ // XXX: regen disabled on talismans because of an untransform crash // related to talismans being slotless Huh. Did not realize this was a thing. I should possibly look into making it not be a thing. 12:40:50 <04dracoomega> Allowing talismans to generate with 'opposing, but not useless' artprops (ie: allowing rPois on an rPois- form, but banning rPois on a naturally rPois form) turns out to be more troublesome than expected. For a couple reasons, but a big part of it is that artprops store a 'max value that can be on an item' and consider the amount on the item to be the sum of the generated artprops and the 'intrinsic' ones. Which means that if the 12:40:51 intrinsic is negative, it can generate more than the max. Like, rF++++ becomes possible on an rF- form. rPois is even weirder, since it's set as a boolean and can't go over one despite this (but can still consume a random artprop to try, even though this has no visible or functional effect besides reducing the number of other properties on the item) 14:45:14 <06pleasingfungus> re: roadmaps: seems possible that the current set of active devs would be more roadmap-friendly than the historical set 14:45:27 <06pleasingfungus> for example, i was a maniac 14:45:42 <06pleasingfungus> yet hellmonk is known for his level-headed, calm development style 14:46:29 <12ge0ff> you need to be mega-calm to close 100+ PRs in a month 14:47:28 <06pleasingfungus> or to make hellcrawl, or bloatcrawl 2 14:53:44 <12ebering> I attempted some roadmapping 14:53:53 <12ebering> but I have found that I am not a roadmap person 14:54:15 <12ebering> even in professional life I'll write a research proposal/grant/whatever then do something completely different 14:56:01 <12ge0ff> even if roadmaps return in some form, they probably shouldn't include the long term goals, because they've just been copied from 0.23 to 0.28 plans (https://github.com/crawl/crawl/wiki/0.23-Development-and-Release-Plan, https://github.com/crawl/crawl/wiki/0.28-Development-and-Release-Plan) 14:58:07 <12ge0ff> although, maybe there's a point in making a page for long term goals specifically: SSO, emscripten port, moving webtiles to typescript/react, such things 15:04:49 <06pleasingfungus> !clapall SSO 15:04:51 <04Cerebot> 👏 S 👏 S 👏 O 👏 15:05:57 <12ge0ff> (also, moving local tiles to Electron, obviously!) 15:08:54 <04dracoomega> So, after a large amount of time staring at some debug output in bafflement, I feel fairly confident in saying that random_picker::probability_at often returns incorrect values. I used this quite a bit when arranging apostle spell chance tables, and Makhleb servant chances, and somewhat by coincidence I think it wasn't lying there, but it is also currently used at run-time for weight generation for spellbooks and is bugged there. 15:08:54 (It's also used by seed_explorer.lua, which is part of the test suite, though I'm not sure it producing incorrect values here actually invalidates the tests) 15:09:16 <12ge0ff> also-also, out of 60 GitHub wiki pages, only 3-4 are about contemporary things, and everything else is either outdated or already done. It's pretty hard to find relevant things there 15:09:24 <04dracoomega> (Basically, it seems to only look at the first population entry that can return a given value, but we constantly use multiple entries for the same value, to shape curves) 15:09:39 <04dracoomega> eg: C++ { 10, 14, 100, RISE, 6 }, { 15, 35, 100, FLAT, 6 }, 15:10:01 <04dracoomega> ie: rise from 10 to 14, then remain constant to 35 15:10:34 <04dracoomega> I think probability_at only sees the first entry (meaning it thinks it's impossible to get level 6 spells after ilevel 14) 15:11:02 <04dracoomega> It's unclear what this actually does to the drop rate of anything, given how mixed spellbooks are 15:11:21 <04dracoomega> But at the very least, it's not performing the behavior anyone would expect it is 15:11:54 <04dracoomega> (I found this because the weight tables for talismans, which use multiple entries extensively, made no sense at all) 15:12:17 <04dracoomega> And I assumed my debug output was wrong or something else was wrong for a while, but in the end I am pretty sure this function is what's at fault 15:12:51 <04dracoomega> (It claimed all talismans had a 0% chance to drop for a lot of item levels, for instance, and multiplying one of the weights by 100 didn't change its mind about that) 15:40:09 <09hellmonk> does this affect the weight of monsters in mon-pick-data or is that using a different thing 15:40:11 Unstable branch on underhound.eu updated to: 0.33-a0-1194-g8b514e5c94 (34) 15:40:23 <09hellmonk> bc if so then uh fucking lol 15:58:31 <06pleasingfungus> oh no 15:59:21 <06pleasingfungus> my beautiful tables 15:59:35 <09hellmonk> I copied those beautiful tables for spider rework 16:00:10 <09hellmonk> actually terrified about what this will do to sbranch spawns 16:01:11 <06pleasingfungus> ah, i see the bug 16:01:17 <06pleasingfungus> if (entry == pop.value) entry_rarity = rar; 16:01:22 <06pleasingfungus> this needs to be += 16:01:35 <06pleasingfungus> classic off by one character, etc 16:02:40 <06pleasingfungus> %git c1c896e988c 16:02:41 <04Cerebot> advil * 0.24-a0-366-gc1c896e988: Seed explorer improvements (6 years ago, 6 files, 195+ 5-) https://github.com/crawl/crawl/commit/c1c896e988c1 16:03:11 <06pleasingfungus> anyway the good news is that this function is barely used 16:03:37 <06pleasingfungus> it's used for some lua thing, moninf_get_avg_local_prob 16:04:06 <06pleasingfungus> and for _book_weight in choose_book_type 16:04:20 <06pleasingfungus> (so I guess that's never worked, rip) 16:04:39 <06pleasingfungus> > I think probability_at only sees the first entry oddly, I think it should only see the second entry 16:04:47 <06pleasingfungus> could be wrong, of course 16:04:54 <06pleasingfungus> anyway, since this affects almost nothing, safe to just ship a fix 16:05:46 <06pleasingfungus> now reading through random_picker::pick to check that 16:05:52 <06pleasingfungus> since that would be the one you'd really want to be right 16:08:22 <06pleasingfungus> i think it should be right, though I could be happier with the variable names chosen. 16:09:48 <06pleasingfungus> ha, time zones means that a hot-off-the-presses april 2 commit is coming after a few april 3 commits 16:10:22 03PleasingFungus02 07* 0.33-a0-1195-gbd1523b72e: Fix probability_at (DracoOmega) 10(2 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/bd1523b72e09 16:29:44 <04dracoomega> Yeah, I found the problem with the function myself before I said that (and was just going to run objstat to see how it actually affects book data), but got sidetracked working on a physical plumbing problem with the bathroom sink instead >.> 16:39:24 <08nicolae> how many commits did the plumbing thing take 16:55:23 <04dracoomega> I wish I could rebase some of this away, let me tell you 16:56:20 <06mumra> Was it a pipeline failure? 16:56:30 <04dracoomega> Yes, actually! 16:56:56 <04dracoomega> The leak was so obvious I didn't even need valgrind >.> 17:14:17 <09gammafunk> I had to have my sink garbage disposal unit replaced yesterday 17:14:49 <09gammafunk> Is this a sign of major plumbing and architectural issues for the dcss dev team? 17:18:44 <04dracoomega> Given the number of other things I have fixed or replaced over the past number of months, I'd say ours are 'ongoing' >.> 17:22:38 <04dracoomega> I've also been looking at objstat for the spellbook droprate changes as a result of that fix, and it's still not exactly clear the exact consequences. Some books are more common and some are less common (sometimes to a fairly significant degree in particular areas) but it's not clear how any of this actually shakes out to a practical effect. 17:23:00 <04dracoomega> Since spellbooks are fairly mixed in terms of spell levels in them anyway 17:23:50 <04dracoomega> (And, I mean, I was still thinking of trying out the parchment thing in 0.34 at some point, which would be a meaningful shakeup anyway) 17:24:04 <09hellmonk> I was about to post "fixed in 0.34" 17:24:08 <04dracoomega> Heh 17:24:49 <04dracoomega> Really, a lot of drop stuff is probably fine to be somewhat 'nebulous'. There's a lot of variance in Crawl in this regard. 17:25:14 <04dracoomega> I just can't help but be reflexively concerned about the 'unknown but far-reaching' consequences of an oversight like this 17:25:38 <04dracoomega> Even if it would probably be hard for it to actually change things in a way anyone would notice among the noise 17:26:23 <04dracoomega> What would be nice, actually, is if there was a way for objstat to measure the odds of finding X spell by Y depth, cumulatively. (This sounds very non-trivial to code, but it would be neat) 17:26:30 <04dracoomega> Since that's what actually matters 17:28:00 <04dracoomega> Most of the data is technically already there, but it's just incredibly hard to massage it into this form 17:28:12 <04dracoomega> By looking at a spreadsheet with a calculator ^^; 17:39:34 <09gammafunk> oh, I think I added...exactly this? 17:39:46 <04dracoomega> You... did? 17:40:02 <09gammafunk> Spells spreadsheet 17:40:12 <09gammafunk> in the output 17:40:23 <09gammafunk> or spells sheet more accurately 17:40:30 <09gammafunk> this was something I added years ago to help PleasingFungus 17:40:36 <09gammafunk> when he did his spell book rework 17:40:56 <09gammafunk> it gives a per-spell (and hence per-level) chance that a spell generates in a spellbook 17:41:11 <09gammafunk> also broken down by vaults, shop, being in an artefact book 17:41:22 <09gammafunk> it's the sheet after spellbooks 17:41:27 <09gammafunk> ??objstat 17:41:31 <04Cerebot> objstat[1/2]: Spreadsheets for all released versions and trunk: https://drive.google.com/drive/folders/0B7VXhHzhWWb7S282VWhLVWRXbG8?resourcekey=0-USiftCbTwRlT9M7Uz5Fskg&usp=sharing/ ; See the README for details: https://docs.google.com/document/d/1D5mFqVi8ghz_nzvVmDUc3unx8VanVBWfgvZ8xCHaiJo/edit?usp=sharing 17:41:34 <04dracoomega> Oh, somehow I never noticed this before now, huh 17:41:37 <04dracoomega> Even though it's right there 17:45:48 <09gammafunk> this sheet doesn't give you a cumulative probability, though 17:46:24 <04dracoomega> (Still, probably not worth diving too hard in right now or I'm just going to baffle myself with things like "Fire storm is more than twice as common in Vaults as Polar Vortex is" and how the change overall seems to have made polar vortex more rare and fire storm more common, even though it was already the more rare of the two. 17:46:31 <04dracoomega> Therein lies madness, I think 17:46:42 <04dracoomega> And I'm supposed to staring at talisman spreadsheets instead today ^^; 18:02:23 <09hellmonk> yeah I would suggest we just fix spell probabilities in 0.34 18:12:03 <04dracoomega> Parchments will certainly give a far easier lever to do so with 18:16:17 <06pleasingfungus> sounds like a dry subject 18:29:45 <09gammafunk> it is, but we shouldn't try to paper over these issues 22:35:35 Unstable branch on crawl.develz.org updated to: 0.33-a0-1195-gbd1523b72e (34) 22:58:45 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-1195-gbd1523b72e 23:33:29 Unstable branch on cbro.berotato.org updated to: 0.33-a0-1195-gbd1523b72e (34) 23:52:18 <04Cgettys> Ooh, are we listing TLA's???? 23:55:40 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-1195-gbd1523b72e