00:13:43 <04dracoomega> ...oh, right, suddenly I am reminded of mumra's incomplete wand PR actually fixing #3 in general >.> 00:13:54 <04dracoomega> (Partway through fixing it myself >.>; ) 00:21:20 <04dracoomega> Oh, I think there may be an oversight in that commit anyway. 00:24:25 Unstable branch on cbro.berotato.org updated to: 0.33-a0-813-g6e8ebd26cc (34) 00:34:25 <04dracoomega> Ugh, maybe I am putting this off until after the species stuff or I'm going to be more weeks at it at this rate. I keep finding side problems to look in or fix 00:35:04 <04dracoomega> (Like, I could get a quick and dirty fix to some of this fairly quickly, but I'd like something that... isn't that, y'know?) 00:55:15 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-813-g6e8ebd26cc 01:48:29 <06mumra> Yeah was about to mention that ... what's the oversight exactly? I have this rebased and further tweaked on another branch and maybe already dealt with that 01:49:12 <04dracoomega> Maybe I am misreading it, but it looked like it wasn't passing on the proper wand power to the hex chance calculation - only to the damage one. 01:50:01 <04dracoomega> (I certainly could have been - I didn't switch branches from what I am in the middle of to actually test it) 02:16:27 -!- Changesite1 is now known as Changesite 02:41:36 <06mumra> hmm, it's maybe slightly worse. _get_spell_description just doesn't know whether it's a wand or regular spell so everything assumes it's a spell (both damage and chance). Even worse, it's using hd rather than spell_hd which can also vary 02:42:28 <06mumra> but i think that 1) is not a problem, what's happening is that spell power is first divided by 3 and then capped at 200, and seems to be capped on both paths anyway 03:28:41 <04dracoomega> That definitely isn't true. Some spells currently cap themselves to 200 in mon-cast.cc (though I actually think it would be better if they didn't - monster spells generally don't and this leads to a few weird niche cases like Brilliance doing literally nothing to Cause Fear on several monsters), but enchantments using normal beams don't. (This is easy enough to verify just by spitting out what power they apply with.) 03:29:58 <04dracoomega> Where conventional beam-based hexes can be cast with higher than 200 power just fine. (As I said, I don't think this applies to any enemy in the normal game, but does to some extra-high-HD ones in Sprints) 03:36:18 <04dracoomega> Really, it would be good if there was just a unified method for getting the actual power that will be applied to the player's willpower, in a single place (so that both xv and actual mechanical code can use the same thing) 03:48:06 <04dracoomega> (Anyway, I must go to bed now) 04:26:25 <06mumra> Ah. I was specifically looking at _ench_power in mon-cast.cc which divides by ENCH_POWER_FACTOR (which is 3) and then caps at 200, but now I see this function is only called for a handful of hexes - ones that don't use a zap, I think, because the zaps all implement the ENCH_POWER_FACTOR as part of the tohit calculator ... so yep the more i dig the messier i realise things already are and absolutely there should be a central place to 04:26:26 handle all this. _mons_power_hd_factor is also factoring in ENCH_POWER_FACTOR ... so it's really not clear if things are at all correct, how or why different hexes are having their power calculated, nor which hexes are being correctly estimated for xv etc, if any of them are even correct 04:34:05 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 04:34:33 <06mumra> Also not clear why things have to be multiplied by ENCH_POW_FACTOR just to get divided by ENCH_POW_FACTOR later on in various paths ... nor why SPELL_PAIN is singled out for being capped at either 50 or 150 (depending where it's being applied) int mons_power_for_hd(spell_type spell, int hd) { const int power = hd * _mons_power_hd_factor(spell); if (spell == SPELL_PAIN) return max(50 * ENCH_POW_FACTOR, power); return 04:34:34 power; } 04:38:36 <06mumra> %git 20e6238 04:38:37 <04Cerebot> PleasingFungus * 0.16-a0-3256-g20e6238a55: Factor out more spellpowers (10 years ago, 2 files, 10+ 5-) https://github.com/crawl/crawl/commit/20e6238a5580 04:39:12 <06mumra> this commit also not very helpful in explaining this 😂 05:16:45 Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-813-g6e8ebd2 (34) 06:44:06 <06mumra> Oh wait, that's a minimum power on Pain, isn't it (still for a completely opaque reason, tho) 08:13:12 Hello, what happened to the hunger mechanics and the deep dwarves? 08:17:59 <06mumra> Both long gone ... when did you last play? 09:02:24 <09gammafunk> ??changelog 09:02:25 <04Cerebot> changelog[1/3]: https://github.com/crawl/crawl/blob/master/crawl-ref/docs/changelog.txt - often incomplete and/or out of date, see {changelog[3]} for an exhaustive list of changes. 09:02:52 <09gammafunk> good reference for what has changed when 10:11:02 03dolorous02 07* 0.33-a0-814-g819cd40f79: Add another name to artefact jewellery. 10(2 minutes ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/819cd40f792a 11:02:04 <06pleasingfungus> mumra: the min 50 power for pain predates the commit you linked 11:04:16 <06pleasingfungus> %git 756243bbee2 11:04:19 <04Cerebot> greensnark * 0.5-a0-305-g756243bbee: [2053689] Fixed bad ench_power for the monster Pain spell. (16 years ago, 1 file, 1+ 4-) https://github.com/crawl/crawl/commit/756243bbee28 11:04:40 <06pleasingfungus> it seems to have been an attempt at some kind of bugfix 11:05:34 <06pleasingfungus> oh, wait, i guess the idea was that it added HD scaling for monster-cast Pain, but still keeping the old floor? sort of? 11:05:48 <06pleasingfungus> except that it actually halved their power, since it deleted an old line that would double it..? this is very silly 11:06:04 <06pleasingfungus> anyway, seems like nonsense that someone should cut 😛 14:14:46 <06mumra> Yeah definitely seems like a lot of accumulated nonsense ... would be nice if just more stuff can be expressed in zap-data really (maybe even move the zaps to yaml) 14:18:09 <04dracoomega> I mean, a lot of these hexes are zaps, but there's weird indirection going on here 14:18:40 <04dracoomega> And the ENCH_POW_FACTOR divisor that xv is using is just replicating what most (but not all!) hex zaps do by convention 14:32:29 <04dracoomega> (Not sure there's a lot of benefit to yaml-ifying them, since the zap structures are pretty simple) 14:32:57 <04dracoomega> (Yaml-ifying forms would be great. I don't know that I'll get to that in 0.33 or not, but it would be nice to do in general) 14:33:16 <04dracoomega> But those have so much data that the key to reading it has to be separated by lines, just to be able to find anything >.> 16:41:03 Unstable branch on underhound.eu updated to: 0.33-a0-814-g819cd40f79 (34) 16:59:59 <04dracoomega> The default monster XP calculation function is so bad. Did you know that a monster knowing both summon horrible things *and * summon dragon together is considered less dangerous than one with ribbon-worm-level regeneration? 17:00:29 <04dracoomega> (Dig is also worth more xp than either of those spells) 17:01:02 <04dracoomega> A huge number of spells are worth literally no xp at all 17:01:46 <04dracoomega> Like, I realize we've basically been papering over this by manually adjusting xp modifiers on new monsters all the time, so that the end result seems like something sane, but I can't help but feel that's an incredibly roundabout way of just setting a number manually in the first place 17:02:30 <04dracoomega> (And 'fixing' this function by adding a bunch of spells that realistically ought to be there would increase the xp of tons of existing monsters and require all of them to be manually lowered...) 17:03:22 <04dracoomega> Player ghosts are maybe one of the few contexts that really 'needs' dynamic xp value calculation, but lots of player spells are worth literally nothing at the moment 17:04:00 <04dracoomega> (Pan lords occur late enough into the game that I genuinely don't know that it would matter if their XP correlated in any way to their stats and spell set as opposed to just being a fix median) 17:06:00 <04dracoomega> (Frankly, you could probably proxy a perfectly adequate player ghost XL calculation just by looking at XL and the level of known spells) 17:06:21 <04dracoomega> Or, at least, something simpler than this 17:06:53 <04dracoomega> There aren't so many ghosts in the game that it needs to be more than 'ballpark reasonable', imo 17:08:48 <09hellmonk> Yeah the XP function is totally insane imo 17:10:16 <09hellmonk> Very hard to fix in a reasonable way though (or at least a way that's future proof enough that you don't want to adjust the XP modifier number on monsters every time something changes about them) 17:11:37 <04dracoomega> I do think it genuinely makes more sense to remove it completely and manually specify an XP value for normal monsters by hand. (This also means there are no cascading consequences to many monsters at once if we ever tried to change anything - since nothing is shared between them.) And a much simpler dynamic calculation can be used for the very small number of cases (like player ghosts) where I feel it's doing any relevant work. 17:13:04 <04dracoomega> (I realize that monster HP within a given type is randomized, and thus some are currently worth more or less than others. I'm not sure that even matters - like, if they all gave the 'average' XP for their type, does it really matter what one was slightly harder to kill and one was slightly easier to kill? It's less randomization than within the rolls of the attacks you'd make to kill them in the first place.) 17:13:25 <04dracoomega> But if that was felt worth keeping, it would be easy to just multiply the 'base' xp of a monster against how far its hp is off the average 17:14:16 <04dracoomega> Like, obviously this is a whole lot of bookkeeping (and running xp stats on branches to make sure nothing is getting out of whack), but it's something I'd be genuinely willing to undertake for 0.34 17:15:25 <04dracoomega> (It would also make it much, much easier to compare how much XP monsters are worth. Right now it's impossible to conceptualize via data, so you just have to spawn a bunch of things in wizmode, look at how much XP they're worth, and then nudge your new monster's multiplier up or down until it lands in a comparable range.) 17:16:03 <04dracoomega> Instead of just looking at the lich yaml and being like "Okay, they're worth 2500 and this is a bit easier, so I'll say 2350") 17:16:23 <09hellmonk> Tbh I agree 17:17:36 <09hellmonk> It would make changing things slightly annoying if the player XP curve ever changes and we want some kind of massive monster XP overhaul to compensate, but that seems unlikely to me so I don't see a real downside 17:18:44 <04dracoomega> I feel if wanted to change the overall player XP curve, it would be easier to do that by adjusting the XP cost of things at different levels anyway? 17:19:10 <09hellmonk> How does cerebot calculate XP values for @ ? I wonder if we could just start there 17:19:14 <04dracoomega> (And if it's just 'X branch is worth too much', that was surely always going to have to be monster-by-monster) 17:20:00 <04dracoomega> Wonder if that's just 'monster with exactly average hp'? 17:20:07 <04dracoomega> (I've not looked at the code) 17:20:34 <09hellmonk> Asking bc 'query each monster once' is more appealing to me than testing in wizmode or calculating the values 17:20:57 <09hellmonk> though it seems likely to be tedious in any case 17:22:07 <04dracoomega> Okay, it looks like it generates the monster 100 times and divides the total xp by 100 17:22:22 <04dracoomega> So not strictly certain to be the median, but 'close' 17:37:50 <09gammafunk> @dracoomega are further big pan changes coming in 0.33? I was going to add pan lord placement to a couple transporter vaults since those do seem like they should be the primary vault when they place, and it'd be a fun sort of pan lord vault to rarely get 17:38:00 <09gammafunk> but if 0.33 has some major pan changes, I'd prefer to wait on that 17:39:03 <04dracoomega> I know Index had a handful of new Pan monsters in the pipeline that might get done for 0.33. But we weren't going to be tackling the real Hellpanroulette-related overhauls until 0.34 now. 17:39:18 <04dracoomega> And I don't think any fundamental changes to anything are planned until then 18:02:45 <09hellmonk> I think I can pick up this XP thing or at least get the framework for it together if you want 18:28:27 <04dracoomega> I mean, if you're interested, I'm not going to say no. 18:30:13 kkplay (L22 DjCj) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 1981 failed. (Elf:3) 18:30:26 <04dracoomega> (I've realized that a couple things besides ghosts would still need some very simple dynamic XP, like orc apostles and dancing weapons, but it feels like those things coudl be handled in a very simple way by comparison to what we do not) 18:46:01 <09gammafunk> %git 0.32.0 18:46:01 <04Cerebot> gammafunk * 0.32.0: doc: Update the changelog for the 0.32 release (5 months ago, 1 file, 2+ 2-) https://github.com/crawl/crawl/commit/2a3b71ecb9cd 18:46:33 <09gammafunk> @dracoomega follow-up release question, do you have a general ETA for how far after the 6 mo. mark would be good for release? 18:47:35 <09gammafunk> don't need anything like a specific date at this point but a rough estimate as to how many weeks after we hit 6 mo would be helpful 18:53:29 <04dracoomega> Well, I hope the undead species stuff will be trunk-ready in a week or so. After that, the only 'big' thing I still wanted to do for 0.33 was the new forms stuff. I have a lot of specific designs already iterated on (but not coded). For the most part, I don't think there are large sweeping technical challenges to any of this (unlike earlier projects in this version), though it's still a decent bit of work. If I had to give an 18:53:29 estimate for how long it would take... I'd like to say 'a month', but I have definitely been slower to get things done this version than anticipated, in general. I suppose one advantage here is that it isn't the sort of thing that has to be completely done in one fell swoop, in the way that Makhleb was, for instance. There's a few parts that kind of need to be done together (as affects Shapeshifter start), but after that is possibly okay if I just 18:53:29 add 'some' number of them and add some more in 0.34. (I guess I have a personal preference for doing a large chunk of related things as 'one big push' so that they're all in a shared context from the start, but it doesn't have to be done that way.) I believe we hit the 6 month mark at the end of this month, right? 18:55:12 <04dracoomega> There's any number of small things I've wanted to do, but I don't think almost any of them are 'blockers', and can just be fit in however much time I have while waiting on balance feedback and doing other fixes for the big stuff 18:55:38 <04dracoomega> (Like, I wanted to do some more tweaks to Beogh in a handful of ways, but if that doesn't happen until 0.34, it's probably fine.) 19:06:49 <04dracoomega> Like, does that sort of add up to: -1 week for undead species -4 weeks for form stuff -2 weeks for balance observation/changes, misc stuff -2 weeks for feature freeze? Which would be just slightly over 7 months in total from last release? 19:10:12 <04dracoomega> (I can't be super confident on all the form stuff without getting more work underway, but recent work on vampire - which is more complex than some of them will be - gives me at least some frame of reference, I hope) 19:10:28 <09gammafunk> yeah, seems reasonable as an estimate 19:11:13 <09gammafunk> I don't think we want to treat 6 mo. as any kind of hard release date but it's probably good to aim for less than 8 months so we have a better chance of having two tournaments a year 19:12:34 <09gammafunk> likely going to be tough to actually achieve that this year regardless, even if we do get a mid april tournament 19:12:56 <09gammafunk> well, I guess it'd be close but still likely if release after this one is on a similar timeframe 19:13:30 <09hellmonk> next release will jsut have to get done in 4 months 19:13:32 <09hellmonk> no worries 19:14:00 <09gammafunk> we'll go back to weekly trunk update but instead of a trunk update it's a release 19:15:19 <04dracoomega> Really, a large chunk of this version on my end was taken up by large-scale refactoring, and surely there will be less of that in 0.34, right? >.> (I honestly can't even begin to guess how long hellpan roulette will take, but I don't want to try and start on that fairly early) 19:15:29 <04dracoomega> Er 19:15:30 <04dracoomega> I do 19:16:09 <04dracoomega> Since that really is a thing that kind of has to be done in one very large block, since it's so interconnected 19:16:24 <04dracoomega> And involves quite a lot of content 20:24:09 <06wensley> last time I calculated the average interval between tournaments was 220 days, or 1.6 tournaments a year, which seems like a pretty good cadence to me 20:59:55 If it's too big to do practically all at once dracoomega, another option would be to go side-by-side 21:00:21 have a beta gamemode that's just "the game, but with hellpan roulette enabled" 21:01:49 And then the new mode becomes the default 21:02:22 might be too painful to do though, idk 21:03:15 <04dracoomega> I mean, I'm not sure that really changes things, exactly? Firstly, experimental branches get a lot less play - especially if their contents aren't accessible until deep into the game. But I wouldn't want to even beta test an extended overhaul that was only 'partially' done. Or, well, obviously it can have room for many future refinements, but Pan and Hell both need to actually be equitable and the shape of Pan needs to be at least 21:03:16 close to the intended state. Otherwise you're testing some weird thing that's neither the established norm or what we plan to try turning it into. 21:03:56 <04dracoomega> (I don't mean to say that this is too big to be practical, but just 'It's big enough that I want to get an early start on it in 0.34') 21:04:06 <04dracoomega> Since I don't have a good sense of how long it will take 21:04:34 <04dracoomega> I will probably still do other smaller things along the way, here and there, and not just be buried in it for months 21:46:01 <09gammafunk> yeah we can't really roll out side-by-side content like that to online servers anyhow 21:46:19 <09gammafunk> but we do run experimental untracked branches sometimes, more recently on CDI 21:48:03 <09gammafunk> which is definitely still an option for content where we both need direct player feedback and know there are breaking or difficult-to-undo changes that have a high possibility of undergoing a high level of revision or not be merged entirely 21:49:14 <09gammafunk> but otherwise we do prefer to push features to trunk once we're pretty certain they're in a near-final state or at the very least are certain to not cause issues if they get major revisions or removal 21:49:59 <09gammafunk> for side-by-side content like experimentals or new modes etc, those require admins to add new configuration and restart the server 21:54:01 <09hellmonk> the problem with experimentals is that almost nobody plays them 21:54:06 <09hellmonk> (from personal experience) 21:54:12 <09hellmonk> it's pretty hard to get feedback 21:56:22 <09gammafunk> well, I don't think that's really accurate 21:56:37 <09gammafunk> we have definitely used experiementals to good success on CDI in recent versions 21:57:20 <09gammafunk> of course pushing to trunk is ideal in terms of feedback and is preferred, but it's not accurate that they haven't generated good feedback 21:57:37 <09gammafunk> maybe you're talking about descent mode, but that's a pretty special case 21:58:02 <09hellmonk> I remember having trouble getting feedback on the spider rework as well 21:58:25 <09gammafunk> I think I've run maybe a dozen experimentals and I do recall that a sizeable majority got feedback that the author was pretty happy with 21:58:47 <09gammafunk> yeah, like I won't say they all do; spider branch rework is somewhat challenging due to how late that content is in the game 21:59:03 <09hellmonk> maybe it's just a case of being the wrong tool for the task I was using it for 21:59:23 <09hellmonk> suspect that hellpan experimental wouldn't work well in that case though, since it's even later 21:59:27 <09gammafunk> yeah, it's a bit of an ask for players to take a game all the way to spider 21:59:46 <09gammafunk> I used to enable wizmode on old cdi to help with issues like that 21:59:57 <09gammafunk> but I'm not confortable doing that on CDI now that it's official 22:00:51 <09gammafunk> but even for stuff players can access at the beginning of the game, if there's no major concern about trunk in terms of the content just possibly getting removed or it somehow breaking something 22:00:55 <09gammafunk> then trunk is ideal 22:02:30 <09gammafunk> although there are some caveats. we narrowly avoided huge disaster fixed in this commit only because it occurred on an experimental: 22:02:34 <09gammafunk> %git efeffbb62afe3e3d34bf1919b8655b58769d63ff 22:02:35 <04Cerebot> gammafunk * 0.31-a0-222-gefeffbb62a: fix: Use the correct type for the minor version (1 year, 7 months ago, 3 files, 3+ 10-) https://github.com/crawl/crawl/commit/efeffbb62afe 22:03:18 <09gammafunk> if that code had just gone right into trunk, we would have been nuking and manually patching up saves on official servers for a while 22:03:44 <09gammafunk> or rather if the code that this commit fixed had gone into trunk 22:04:50 <09gammafunk> the funny thing in that case being that the erroneous code was in trunk, but the tag major PF added that put us over the limit that triggered said bad code to corrupt saves in a super bad way, that was in the experimental, thankfully 22:06:34 <09hellmonk> wow 22:16:57 -!- Changesite1 is now known as Changesite 23:06:23 <06pleasingfungus> hash tag blessed 23:06:37 <06pleasingfungus> but yeah experimental works better for stuff like backgrounds, species, even gods 23:35:09 Unstable branch on crawl.develz.org updated to: 0.33-a0-814-g819cd40f79 (34) 23:36:27 Sorry, clien tlost ocnnection and I didn't notice 23:36:47 Agreed that trunk based development is the best approach if viable 23:37:36 Just pointing out that it's possible to develop in trunk without exposing the work until it's polished enough / complete enough to light up 23:37:57 (because the problem with patchs not in trunk is other changes can end up conflicting) 23:38:36 The current serialization code makes me nervous 23:38:51 a lot of the enums aren't explicitly sized to match the serializatin code like naively I'd like them to be 23:39:31 wouldn't be as bad as the commit you linked, but could be nasty if someone overflowed a enum's implicit limit 23:40:04 That's orthogonal though... I'll try to put in a PR to at least add static asserts that the last enum value is within bounds for each enum sometime 23:57:00 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-814-g819cd40f79