03:16:30 03DracoOmega02 07* 0.35-a0-468-g3aa0c7bdef: Fix to-hit estimate for player beam spells against monsters 10(4 hours ago, 1 file, 19+ 11-) 13https://github.com/crawl/crawl/commit/3aa0c7bdef12 03:35:40 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 03:59:24 <11Odds> I think we might be very, very slightly overestimating hex success chances in targeters, but would love someone to check my maths - by my read the 201 on https://github.com/crawl/crawl/blob/3aa0c7bdef12c483dc11c3c55d5a9238b9e55908/crawl-ref/source/spl-cast.cc#L1653 should be a 200 (because the max that the dice can roll is 199, the chance at 200 should be 0) 04:00:34 <11Odds> (If I'm right, the maximum absolute effect of this is displaying a 49% chance as a 50% chance) 04:55:27 @Odds there may be rounding error involved so it may be 49.532156 (assuming floating point or binary fractions were used in the calculations) which in terms of horseshoes and hand grenades close enough. However if it were 49.49999% then that would be an error. 04:57:23 03DracoOmega02 07* 0.35-a0-469-gf07d79d43a: Don't crash when aiming beams at monsters with 0 EV 10(75 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/f07d79d43a82 04:58:09 <04dracoomega> I'm afraid I'm too close to bed to check anyone's math right now ^^; 05:02:45 <04dracoomega> Incidentally, though, I did find an issue with attack to-hit estimates today, also. It's considerably more minor than the one with beam to-hit (and also somewhat harder to fix, at the same time). But basically, the contribution to the player's to-hit from fighting and weapon skills is randomized before the to-hit is later rolled as part of the dodge calculation. The UI takes the average value for this to-hit, rather than 05:02:45 exhaustively randomizing it, which works out correctly enough most of the time. But if the player's to-hit is so low compared to a monster's EV that they need to roll above-average on this first roll to have a non-zero chance of success on the second roll, the targeter will underestimate their to-hit slightly. This generally only applies in situations where one's chance to hit is already really bad, though. Often involving deflect missiles. And 05:02:46 seems to mostly mean that "If the targeter says you have ~1% chance to hit, you might actually have 5%". By the time you're above 5% or so, it seems to be close to correct again. 05:04:30 <04dracoomega> So while it would be nice for this to be fixed, it's a lot less impactful than the bug I fixed earlier (30% looking like 10% is quite a bit more tactically relevant than 5% looking like 1%) 05:04:50 <04dracoomega> Since it gives the correct enough number in like 99.9% of cases already 05:04:55 <04dracoomega> As opposed to 'never' 😛 05:05:11 <11Odds> Yeah the thing I’m looking at is not a rounding error, it affects things at any precision (though as I say, very little so it’s not urgent at all 🙂 ) 05:06:16 <04dracoomega> (Funny thing is that I only found the bug I did because I was implementing a very very janky 'fsim except with beams' to get some quick stats on a few things and found that the numbers didn't even slighty agree with the UI estimate >.>) 05:06:48 <04dracoomega> Though it took me quite a while to figure out why they didn't (or even to be sure that it wasn't the test's fault) 05:23:32 <11Odds> I on the other hand just thought I should check the maths at least once to me more confident ignoring complaints about EH failing too often 🙂 05:26:21 <11Odds> (It’s always a bit scary how the hit/proc chances use different code from the actual rolls) 05:36:16 -!- TAS-2012v is now known as TAS_2012v 06:16:15 <08wormsofcan> ely has so many of these 06:16:31 <08wormsofcan> spike launcher can cause penance 06:16:41 <08wormsofcan> foxfire can cause penance 06:17:29 <08wormsofcan> wouldn't be surprised if rime yak could cause penance 06:17:48 <11Odds> Yeah, penance from damaging stuff you shouldn't is very much the hard bit (which I'm not doing anything about). It's quite hard to know in advance if a thing you do might damage a friend 07:29:04 03CrawlOdds02 07* 0.35-a0-470-g82d66c0333: Fix a very small error in displayed hex success chances 10(2 hours ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/82d66c0333c9 07:29:04 03CrawlOdds02 07* 0.35-a0-471-ge6ab79a80b: Fix a very small error in displayed to-hit chances 10(62 minutes ago, 1 file, 5+ 5-) 13https://github.com/crawl/crawl/commit/e6ab79a80bd7 07:32:47 what about those of us who display the success chances in decimal? (Sorry :^)) 07:33:43 <11Odds> Is that an option? 07:34:19 (The (bad) joke is that your commit is for success rates that are displayed in hexadecimal rather than for the hex spells) 07:35:03 <11Odds> Ah, I see 🙂 12:02:50 <12ge0ff> &versions 12:02:54 <04Cerebot> Latest versions seen in milestones this week: [LLD] => 0.34.1-3-ga2c7840, [CAO] => 0.35-a0-452-gb6d0317, [CUE] => 0.35-a0-465-gcc6d5d2, [CBR2 CDO CXC CRG CBRG] => 0.35-a0-467-g0a0f4f6, [CDI CNC CPO] => 0.35-a0-471-ge6ab79a 12:03:40 <12ge0ff> ^--- it looks like CAO is stuck on a version before Friday's glyph commits 12:18:50 <09gammafunk> sigh 12:19:27 <09gammafunk> Ge0ff always points out when things are broken, never when they work properly!!! 12:20:20 <09gammafunk> well, this one might not be so bad... PYTHON mon-data.h Traceback (most recent call last): File "util/mon-gen.py", line 424, in main mons = Monster(mon_spec) File "util/mon-gen.py", line 41, in __init__ self.from_yaml(yaml_dict) File "util/mon-gen.py", line 100, in from_yaml raise ValueError("failed to parse '%s': %s" % (key, e)) ValueError: failed to parse 'glyph': glyph isn't a string Failed to load 12:20:21 air-elemental.yaml make: *** [mon-data.h] Error 1 make: Leaving directory `/home/crawl-dev/dgamelaunch-config/crawl-build/crawl-git-repository/crawl-ref/source' Done 12:20:43 <11Odds> Oh, that's the same one we had on the MSCV build 12:20:56 <09gammafunk> we're running 3.10.5 on cao 12:22:12 <11Odds> Hmmm the fix should work from 3.7 12:22:23 <11Odds> (https://docs.python.org/3/using/cmdline.html) 12:23:01 <09gammafunk> what's the basic problem? 12:23:04 <11Odds> That build failure is from after https://github.com/crawl/crawl/commit/0a0f4f6124e25a3b0ae6d81a0fad5b96e48879cd? 12:23:22 <11Odds> It's that the file is being loaded in the wrong encoding 12:23:51 <11Odds> And the funny new glyphs are being parsed as two characters. The fix was to make python load everything in utf-8 by default, like it already does in sane environments 12:23:56 <09gammafunk> well in that case, surely this can be handled as a call to open() 12:24:11 <11Odds> Yep, specifying the encoding there should work fine 12:25:53 <09gammafunk> adding encoding='utf-8' as an arg should work 12:26:55 <09gammafunk> looks like there are two opens where we need to specify that 12:27:01 <09gammafunk> one for the template, another for the actual yaml 12:27:14 <09gammafunk> presumably if we add that we can remove that -X arg stuff? 12:27:36 <09gammafunk> I can test it out locally on cao and push if it works 12:27:40 <11Odds> The template probably doesn't have any silly characters 12:27:45 <11Odds> Yep 12:28:00 <09gammafunk> right but we don't want it to break when someone decides to add such a thing 12:28:32 <11Odds> Yeah. Though there are also all the other types of yaml files we haven't fixed this for 12:28:51 <09gammafunk> certainly could go through all such cases and use the encoding arg to open systematically 12:29:14 <09gammafunk> probably not too many of them 12:30:05 <09gammafunk> I can poke it sometime later, but if you want to make the commit yourself, feel free 12:30:06 <11Odds> Probably for the best, an explicit encoding is good practise 12:30:34 <11Odds> (Though this is the first time I've run across the default not being utf-8) 12:30:45 <11Odds> Sure I'll give it a go 12:31:00 <09gammafunk> yeah I'm not sure if more recent pythons default to that encoding or what 12:31:18 <09gammafunk> since I believe we're not having compilation issues on the other servers, that must be the case 12:32:38 <11Odds> Right, it looks like in some way that command line argument fixed the default on other servers but not CAO 12:33:39 <09gammafunk> well I believe that was in the context of a different build launching the script 12:33:55 <09gammafunk> whereas this script is being run directly in this build 12:34:29 <09gammafunk> as in I think that was probably just a CI step, no? it's not relevant to DGL server build 12:34:49 <09gammafunk> it would fix the CI failure but not do anything for the build on a live server; those aren't using CI 12:35:18 <11Odds> Oh right yes, silly me 12:37:39 <11Odds> Huh, some of these scripts claim to support python 2, which didn't have an ecoding parameter... are we actually still using python 2 anywhere? 12:40:38 <12ge0ff> webserver/readme.md says that > To run the server, you need: > ... > * Python 3.8 or newer. (Earlier versions may work but are not supported 12:42:54 <12ge0ff> also not sure about "may work", as server.py has this python def server_main(): if sys.version_info.major < 3: sys.exit("Python 2 is not supported, please upgrade!") 12:44:13 <11Odds> Cool. I was just trying to prove to myself these scripts fail under python 2 (I think they do, because they won't handle non-ASCII right), but that's very much more conclusive 🙂 12:44:20 <12ge0ff> also also, webserver/changelog.md has > - Breaking change: Python 2 (soft-deprecated in 0.25 in 2020, fully > deprecated in 0.29 in 2022) is now completely disallowed, as are old Tornado > versions. 12:45:40 <12ge0ff> (so it could be worth getting rid of "it might work in python 2" from those few files that still claim such compatibility) 12:47:14 <11Odds> Yep I'm doing so 🙂 13:00:24 03CrawlOdds02 07* 0.35-a0-472-gb61ad445cc: Specify UTF-8 encoding in python generation utilities 10(14 minutes ago, 6 files, 17+ 29-) 13https://github.com/crawl/crawl/commit/b61ad445cce7 13:01:00 <11Odds> Save your 🥳 until it works 13:01:17 <11Odds> I do so hate pushing changes I can't test 🙂 13:10:19 <02Darby> even though I am mostly tiles and occasional vaults, not code, my code commits had the longest phase of me secretly worrying "this completely innocuous one-line bugfix will somehow blow something up, even though there's no possible way it could" 13:13:33 you an everyone else who's authored a commit (including me, granting I have only 2 or 3 total) 13:18:46 <04dracoomega> I am very confused that the encoding='utf-8' thing works, since I already tried that locally, and it very much did not work. 13:19:58 <04dracoomega> (Like, it seemed to do nothing at all. It's not that the encoding parameter wasn't being acknowledge in general, since encoding='utf-16' or something actively incorrect did cause appropriate errors. But encoding='utf-8' itself made no difference to the original bug, whether it was present or not) 13:20:18 <11Odds> But did you have this bug locally? 13:21:03 <04dracoomega> (I spent a couple hours yesterday trying to set up an MSCV build of this locally. Which I didn't fully succeed at, but did get far enough to get Windows itself doing the python header generation step, which did have the same encoding issue as CI did) 13:21:29 <04dracoomega> And for me, adding the encoding='utf-8' arg did not improve matters (but the fix I pushed did) 13:21:40 <11Odds> Huh, that's deeply confusing to me 13:21:55 <04dracoomega> Yeah, I have no idea why it wouldn't work (though I actually found multiple people online complaining about the same issue) 13:23:16 <04dracoomega> Though if this satisfies CI (and CAO, maybe?), it's hopefully good enough. The MSVC build is not exactly widely used. 13:23:31 <04dracoomega> Fingers crossed?? 13:24:44 <11Odds> Yeah, all slightly worrying but not sure we're going to do better 13:24:55 <11Odds> Pretty sure my rebuild of CAO has got past the relevant bit 13:26:07 <04dracoomega> It may remain a mystery 13:52:31 Unstable branch on crawl.akrasiac.org updated to: 0.35-a0-472-gb61ad445cc (34) 14:44:41 <09gammafunk> remember though you can do a rebuild on CAO 14:44:48 <09gammafunk> ah, nice, you did that 14:44:58 <09gammafunk> you meant test locally first, which yeah that is annoying 14:45:16 <09gammafunk> aside from setting up a specialized container, that's tough to do 15:42:36 Unstable branch on underhound.eu updated to: 0.35-a0-472-gb61ad445cc (34) 20:20:59 03Neil Moore02 07* 0.35-a0-473-ga6541e14b8: Add some quotes about insects 10(9 minutes ago, 1 file, 24+ 0-) 13https://github.com/crawl/crawl/commit/a6541e14b864 21:26:54 03Neil Moore02 07* 0.35-a0-474-g2479e47b20: Add an arachnine quote 10(2 minutes ago, 1 file, 6+ 0-) 13https://github.com/crawl/crawl/commit/2479e47b20b9 21:38:36 03Neil Moore02 07* 0.35-a0-475-gf2f6b638ed: Add a dancing-related quote for Uskayaw altars 10(51 seconds ago, 1 file, 8+ 0-) 13https://github.com/crawl/crawl/commit/f2f6b638edf7 22:35:20 Unstable branch on crawl.develz.org updated to: 0.35-a0-475-gf2f6b638ed (34) 22:57:24 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-475-gf2f6b638ed 23:12:39 Unstable branch on cbro.berotato.org updated to: 0.35-a0-475-gf2f6b638ed (34) 23:55:10 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-475-gf2f6b638ed