00:13:08 Stable (0.34) branch on underhound.eu updated to: 0.34.1-4-g0e95e087e2 00:32:46 Stable (0.34) branch on cbro.berotato.org updated to: 0.34.1-4-g0e95e087e2 03:36:09 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 06:39:59 <02Monkooky> is the issue tracker an inappropriate place for design feedback? 06:47:17 IMNMO (in my non-maintainer opinion) I think it's a reasonable place for design discussions/questions 08:23:13 <12ge0ff> Technically, https://github.com/crawl/crawl/#reporting-bugs says that > Bugs should be reported to our github issue tracker. Thoughtful ideas on how to improve interface or gameplay are welcome, but it's often best to discuss changes before opening an issue or pull request. 08:23:25 <12ge0ff> This is not a clear "bug tracker is for bugs" message. But we do have a whole bunch of places for feedback and discussions already. 08:23:48 <12ge0ff> Also, if we are talking about https://github.com/crawl/crawl/issues/5297, then giving Yred chars unlimited portal timers (until they go to another floor) doesn't feel like a thoughtful idea on how to improve gameplay. 08:29:55 <11Odds> I don't know really know about the current stance, but I do favour "bug tracker is for bugs" just because otherwise it becomes somewhat unusable - suggestions are very hard to close when they aren't either something we want to implement or something that's clearly a bad idea 08:40:18 isn't the (gamedev) wiki generally used for that? although I recall that mostly having been the dokuwiki which I assume is pretty much defunkt(tm) now 08:40:53 03CrawlOdds02 07* 0.35-a0-517-g8fd04349a1: Make some forbidden items more findable 10(31 hours ago, 12 files, 110+ 86-) 13https://github.com/crawl/crawl/commit/8fd04349a139 08:40:53 03CrawlOdds02 07* 0.35-a0-518-gb3abb6dad7: Clean up evil conducts a little 10(40 minutes ago, 3 files, 2+ 42-) 13https://github.com/crawl/crawl/commit/b3abb6dad7fa 09:16:50 I suppose there's also GitHub's discussions thing, though that's turned off for the repo. 09:21:29 that was my other thought, and has the advantage that I think issues can still be moved to discussions? 10:06:04 <09gammafunk> yeah we still have and could use doku wiki 10:06:14 <09gammafunk> the github wiki is great but non-devs can't spitball there 10:06:47 <09gammafunk> tavern proposals have been used in the past, but for long design docs it's helpful to have something more "stationary" 10:11:45 FWIW I was poking at eglot for Emacs, whose github issues are "bugs with patches only" 10:16:09 <09hellmonk> problem: there are 14 different places to submit design feedback 10:17:14 neh, this one's simplet. put 'em on a wall and toss a dart at 'em while blindfolded 10:17:20 ignore the others 10:17:29 (ideally, disable with pointers) 10:18:08 Tangentially related to design discussions: I've had this idea bouncing around in my head for years now (I've probably brought it up before too) but I've always been interested in making an unrand that is faster the lower your health is. (Not entirely sure what the best way to handle death's door is.) Does this seem like a reasonable thing? 11:29:00 <02Monkooky> While they are wrong about the mechanics of yred, and I'd disagree with them on all parts of this 'issue' even if they weren't, I don't think it's viable or wise to gatekeep the ability to provide feedback on being correct 11:31:17 <02Monkooky> it makes sense that we don't want a pile of unclosable feedback issues though 11:40:38 <09hellmonk> I am not really sure what the design goal of a weapon that speeds up when you have low health is, but I don't see why it would be a problem to implement. It is also probably fine to just make it work under death's door, since that's a high level spell. 11:49:29 Not saying it's a problem to implement; just don't want to implement it and have it turned down on the merits of its design. The design goal is just very high risk = very high reward—if you're hitting with say a 3 aut dire flail but are at 5% health then you're in quite a bit of danger but you'll be able to shred through stuff. 11:51:21 (Heck, if you're low enough why not make it a 1 or 2 aut attack if you're at mindelay? You're very likely a one turn death from a smiter stepping into LOS and blapping you at that point after all) 11:52:56 <12ge0ff> Such weapon would incentivize risky play when you keep tabbing while low on hp, in hopes of outliving the enemy. Which sounds like a good thing. Another question is how such unrand is supposed to interact with weapon skill, encumbrance, haste, finesse, and so on. It could be better to go a woodcutter axe-like route and make the speed solely dependent on HP. And have a suitable max delay for full HP, like 10 auts, so it's worth using even 11:52:56 at full health. 11:53:56 <12ge0ff> (the whole idea doesn't sound bad, but to tell if it's a good one, you need to playtest it) 11:54:29 <09hellmonk> probably should not require fully no hp for mindelay in that case, maybe it can taper between 25% and 75% hp remaining? 11:54:55 <09hellmonk> 25% being like the absolute lowest hp where you might conceivably melee something non-suicidally 11:57:27 <09hellmonk> if interactions with mindelay and haste are a problem, could consider varying base damage instead 11:57:28 Yeah was also wondering about a woodcutter axe type thing, and now that I'm looking I'm not especially seeing any obvious holes for unrands in any of the "hit things hard" weapon types. Mace would maybe be cute flavor (you're spinning it faster or something idk) but a big brother to woodcutter axe (exe axe even?) that has a similar gimmick of skill not affecting delay 11:57:51 is extremely funny* 12:04:04 <02Monkooky> I believe there's a hard cap of 3 auts as part of delay calculations, so it probably would be a nonbo with haste 12:20:49 03CrawlOdds02 07* 0.35-a0-519-g6cb6efe6f4: Make movement speed a bit less random 10(35 hours ago, 11 files, 90+ 73-) 13https://github.com/crawl/crawl/commit/6cb6efe6f45e 12:20:49 03brianfaires02 {CrawlOdds} 07* 0.35-a0-520-g15110aad8c: Create lua func you.movement_cost() 10(7 months ago, 4 files, 34+ 14-) 13https://github.com/crawl/crawl/commit/15110aad8c44 12:40:39 <11Odds> As @gammafunk notes: - The above is mildly terrifying, though I've tested everything it changes and stared at the code very hard - It would be lovely to not have all these scaling factors around, but instead use actual real-valued arithmetic, e.g. by using our existing very shiny looking fixedp library (which I wasn't aware of). I might look at that some time. 12:44:32 <11Odds> (I also wonder whether floating point arithmetic would actually be perfectly fine for lots of this and simplify the code a great deal) 13:01:12 03Sergey Semushin02 {CrawlOdds} 07* 0.35-a0-521-g5612391b3e: Do not show breath status if can't use it in current form 10(29 hours ago, 1 file, 4+ 2-) 13https://github.com/crawl/crawl/commit/5612391b3ebb 13:03:45 <12ge0ff> There are some articles about using fixed point arithmetic vs. floating point arithmetic for calculating things like probabilities. With floating point there would be no determinism / consistency on different platforms; also rounding errors have a tendency to accumulate over repeated calculations when you use floats. 13:05:33 <11Odds> Yeah, and sometimes that matters and sometimes it doesn't 🙂 13:06:09 surely Odds of all people would know about the applicability of floating vs fixed point arithmetic as it applies to probabilities! 13:09:03 <11Odds> "Accumulating rounding errors" is something we are doing all the time anyway, because we are doing arithmetic at far lower precision than floating points. Consistency between different platforms also doesn't actually seem important - does it matter if we round up rather than down fractionally more on one server than another (and it really would be a tiny, tiny effect) 13:13:44 <12ge0ff> "consistency" is relevant for debugging, when you want identical inputs to produce identical outputs, be that on a server or on your pc 13:13:59 <02Monkooky> Seed stability is good, yes 13:14:09 <11Odds> A good thing we don't currently aspire to, right? 13:14:36 <11Odds> Like, I can't replicate a server's behaviour on my pc. And floating point arithmetic on one platform is deterministic 13:15:10 <02Monkooky> I'm not confident that's correct actually 13:15:42 <12ge0ff> i don't what exactly you want to change, but it's worth remembering that we have c++ and javascript code, and their floats are not the same 13:16:54 <12ge0ff> (are there any calculations on the js side at all? like for displaying values?) 13:16:57 <11Odds> (If "platform" is sufficiently broad - like compiiler+compiler settings+machine- I am) 13:17:42 <11Odds> Yeah I'm primarily thinking of things like damage, delay, etc, where we do a lot of c++ arithmetic in scaled-up integers which we randomly round (preferably once, often multiple times along the way) 13:18:24 <11Odds> (Like today's speed commit) 13:19:08 <12ge0ff> Also, floating numbers have non-uniform spacing (denser near 0, sparser near 1), which can introduce (some) bias. 13:21:39 <11Odds> Yeah - I have read a bunch of stuff on this in the past and am aware of these arguments. There are tradeoffs here. 13:26:44 03geekosaur02 {CrawlOdds} 07* 0.35-a0-522-gfc95cd1e1a: Delete some dead code 10(3 days ago, 1 file, 0+ 4-) 13https://github.com/crawl/crawl/commit/fc95cd1e1a82 13:31:00 <12ge0ff> If you know about this topic, what are the other relevant limitations of floating point arithmetic for such calculations? 🙂 13:31:11 <02Monkooky> do you have a reason for this- ideally somewhere I could read more on the topic? 13:31:38 <02Monkooky> cause I need to know more about this for other projects 13:33:17 <11Odds> I think you've said most of the key things, but other things that pop to mind are that order of operations can matter in sad ways, and many of the problems matter in practise when your calculation involves numbers of extremely different scales. 13:33:59 <02Monkooky> I've been looking through https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Floating-Point-in-Depth.html 13:34:12 <02Monkooky> where you can learn about fun safe math optimizations 13:35:28 <12ge0ff> Also, to answer my own question, there doesn't seem to by any floating point calculations on the JS side except for drawing things in the dungeon view. So, if we don't worry about webtiles being a pixel-perfect copy of local tiles, it should be fine. 13:37:42 <11Odds> do you have a reason for this- ideally 13:40:43 One classic example of floating pointing weirdness would be where you can rearrange an array of 2046 numbers and sum them you can get any float as a result (up to some very large floats): https://discourse.julialang.org/t/array-ordering-and-naive-summation/1929 13:41:09 And another good article which itself links to many good articles: https://simonbyrne.github.io/notes/fastmath/ 13:58:06 <12ge0ff> (By the way, it looks like threads are not bridged to the irc side, except for the name of the thread. And they don't appear in the logs too) 13:58:45 <11Odds> Ah thanks, I shall avoid them 13:59:51 <11Odds> The IRC folk have missed Monkooky and I trying to work out to what degree floating point artihmetic really is inconsistent these days. But they can probably read Wikipedia themselves 🙂 13:59:56 <02Monkooky> this thread is pretttty off topic to be honest 14:00:11 <02Monkooky> as much as I appreciate it 14:00:17 <12ge0ff> it's interesting stuff! 14:01:32 <11Odds> (I will merely note on the overall topic above that no-one has addressed whether or to what degree any of these concerns apply to our use cases in particular, and there are very real tradeoffs; our integer scaling methods of doing arithmetic are far less precise, more error prone, and less readable) 14:15:41 <12ge0ff> I kinda agree about the "less readable" part, but an illustration/comparison of how it's done now vs. how it could be with the use of floating-point arithmetic could be useful. Like a current less precise and more error prone bit of code vs. how it could look like. 14:16:42 <12ge0ff> otherwise, talking about this topic in general, without concrete examples, is not very practical 14:29:10 <11Odds> Very reasonable 🙂 14:31:56 <11Odds> (And I also should definitely understand the fixed point thing we already have better, that's probably actually the way to go) 14:32:17 <09gammafunk> I will say that we should never use floating point (or any other technique) if it would introduce seed instability. Seeds are supposed to be stable across platforms 14:32:55 <09gammafunk> Since we specifically have dungeon generation seed stability right now after advil did tons of work to achieve this 14:33:30 <09gammafunk> I have no expertise or input as to whether floating point is a problem in this regard, but I wanted to reiterate that issue in particular 14:33:55 <11Odds> Just to check, seed stability is about dungeon and monster and item generation, right? Like, we don't expect my combat rolls to be the same across platforms? 14:33:59 <09gammafunk> correct 14:34:21 <11Odds> Yeah I 100% agree on that point, seed stability is great 14:34:41 <09gammafunk> it's so that you can generate the same dungeon given a seed every single time (modula aspects like player acquirement and trove selection, which are based on skills and species/god selection etc) 14:35:28 <11Odds> Totally I wouldn't do anything to mess with that 15:44:06 Unstable branch on underhound.eu updated to: 0.35-a0-522-gfc95cd1e1a (34) 20:33:57 <04dracoomega> @Odds Having a quick glance through the movement delay commit, is there some reason you picked 60 as the default scale factor? (Like, does that divide more nicely into the math we have than, say, 100 would?) 20:34:37 <04dracoomega> Like, I suppose it largely doesn't matter, since it's backend stuff, but it's the kind of conspicuous value that makes me wonder if it's specifically important, is all 22:36:00 Unstable branch on crawl.develz.org updated to: 0.35-a0-522-gfc95cd1e1a (34) 23:00:11 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-522-gfc95cd1e1a 23:07:25 <11Odds> Yeah, having more factors (especially 3) means less random rounding and so more consistent outcomes (shoulda left a comment) 23:08:56 <11Odds> It’s certainly not important 23:10:52 <04dracoomega> Yeah, a comment might be helpful if there was some specific logic to it being chosen 23:11:11 <04dracoomega> (An awful lot of scale factors we use for similar functions just end up being, like, 100 or 1000) 23:17:33 <11Odds> Yeah, specifically the fact that the most common way of changing speed has a factor of 2/3 is probably why I did it. It's a very small thing, but not random rounding in that case makes it fractionally less likely we get errors accumulating 23:17:45 <04dracoomega> Sure 23:18:48 <11Odds> (Also thanks for taking a look, it's code I'm very glad to have another pair of eyes on 🙂 ) 23:21:00 <11Odds> @o____0 - I was looking at your longwalking options PR, and... I'm confused about longwalking, which I've never used much 🙂 Do you understand exactly when it stops (before this PR)? And do you like this behaviour? 23:25:12 <08o____0> I was more familiar with the code in january when I wrote it but can look at it again tomorrow haha. Iirc it keeps going indefinitely until it hits something like a wall or item or something in runrest stop options 23:29:41 <08o____0> Ah it was February right. There's a video of it in action. Unlimited is equivalent to current behavior I think 23:29:57 <11Odds> In complicated levels the behaviour is some what weirder than that afaic 🙂 23:31:06 <11Odds> Like, it’s stopping in places that I don’t understand why. Your change (which looks very sensible) is mostly unrelated to that but while I’m in the area I wanted to understand the whole algorithm 23:31:32 <11Odds> But if you don’t happen to know already I can puzzle it out! 23:31:44 <08o____0> It stops when the wall beside you startsor ends I think? 23:32:06 Unstable branch on cbro.berotato.org updated to: 0.35-a0-522-gfc95cd1e1a (34) 23:32:29 <08o____0> It's natural to me while playing, I have to play a minigame where I aim for fearures that will take me far but not too far lol 23:32:52 <11Odds> Aha I see, thanks! 23:33:02 <08o____0> Like items on the ground, walls. Ofc when enemies show up it prevents movement 23:33:42 <11Odds> Right so if you explore the perimeter of vaults 5 hugging the inner wall it stops at the opening, if on the outer wall it barrels on 23:35:10 <11Odds> And you find that useful, compared perhaps to a world where it always went on but had limited range? 23:35:54 <11Odds> Probably it’s good to stop at the end of corridors 23:37:03 <08o____0> Oh yes, I find stopping at the end of hallways useful 23:38:37 <08o____0> Even though in complicated terrain you might only move 1 or 2 tiles. You can see what's ahead and hit the button fast and if a monster shows up, it stops you 23:39:54 <08o____0> I am going to sleep. Thanks for looking into it! Let me know if there's more questions 23:56:18 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-522-gfc95cd1e1a