00:01:40 <06mumra> This magnavolt idea really gives me an image of a magical Taser 00:35:36 Unstable branch on crawl.kelbi.org updated to: 0.32-a0-900-g30fb1b0edc (34) 00:35:36 Unstable branch on crawl.kelbi.org updated to: 0.32-a0-900-g30fb1b0edc (34) 00:37:16 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-5186-gbdc6987af4 00:37:16 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-5186-gbdc6987af4 01:44:44 <06mumra> I want to clear up an inconsistency when targetting. With ranged and spells you see "(50% to hit)" in the targetting prompt, but in melee aiming with v, you see "(about 34% to evade your +0 hand axe)". There's no obvious reason why melee shows their evasion and ranged shows your to-hit, other than that the describe_to_hit function which is used in melee here is also used on the monster info xv screen. And on that screen, ranged ALSO 01:44:44 shows "to evade your +0 orcbow". So possibly two-fold improvement here: - Obviously targetting should be consistent and it should always be "to hit", whatever type of attack it is - Is there any reason to show monster's evasion chance on the info screen rather than just showing your to hit here as well? If I consistently made it "to hit" everywhere it would simplify a few code paths and IMO make things less confusing if everywhere you see a % it's a to 01:44:45 hit. So to clarify the change would be from this: It has about 34% to evade your +0 hand axe. It has about 64% to hit you. To this: You have about 66% to hit with your +0 hand axe. It has about 64% to hit you. - One final point, there are some cases the chance is prefixed with "about" and some where it's not. I think in all cases it's "about" because we're not showing decimal places. Is there any need for this clarification or is the word 01:44:45 superfluous? 02:07:20 <02Monkooky> showing up in a spellbook automatically makes a spell a player spell, right? 02:10:44 <02Monkooky> ah, I didn't add it to the book properly 02:13:50 <02Monkooky> oh was lookin at the wrong morgue nvm 02:25:49 <03wheals> agreed with the first two things, though i'd make sure it doesn't cause issues with lines being too long 02:28:19 <03wheals> for the last thing, i agree that it's fine to not have "about", i wonder if it's there to hedge in case the number ever comes up 0 or 100? but we could also specifically check for that 02:29:33 <03wheals> also melee/ranged can never reach 0 or 100 because of the autohit/automiss chances 02:33:37 <06mumra> Was thinking the describe functions should have a "verbose" bool which would be used on monster info where there's a bit more space but you need a more compact version on the targetter. On monster info it's fine to be a bit more wordy and have things like "about" and the weapon description, but on the targetter you know what you're aiming with anyway so the "with your +0 hand axe" can also be dropped 03:19:34 <02Monkooky> Ok, settling on: cast gastronomic expanse in a direction, and it spreads "in that direction" every 10 auts 03:21:50 <02Monkooky> thinking it should operate by moving the center of an area in the chosen direction, and increasing the radius by one which means that the frontier of the gastronomic expanse will advance two tiles in the chosen direction every 10 auts, and 1 tile in each perpendicular direction 03:31:59 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5186-gbdc6987af4 04:14:03 <06mumra> It might be interesting to use a simple cellular automata 04:14:58 <06mumra> So it creeps across in a semi-organic way 04:15:25 <06mumra> Let each border have some chance to spread to a tile, and heavily weight things in the direction of casting 04:15:46 <02Monkooky> hmm 04:18:01 <02Monkooky> I think I dislike that mechanically 04:18:42 <02Monkooky> the question 'when will tile X be reached' is- even for a dead simple automata- incredibly difficult 04:20:43 <06mumra> Hmm. Really it's just to give a bit of randomness to the spread rather than a perfect circle. (Circles are weird in crawl anyway because actually there's no such thing as a circle, if you want it spreading at even distance then it has to be a square to match LOS) 04:21:17 <06mumra> And you will know "it'll get there in roughly 2-3 turns" which is good enough, if you get the algorithm tweaked right 04:21:54 <06mumra> And you can guarantee you'll get roughly 2 units of spread per turn in the firing direction, one 1 unit per turn the other way 04:23:56 <02Monkooky> it seems very difficult to me to have a cellular automata that works as you describe 04:26:50 <06mumra> maybe "cellular automata" is the wrong way to describe what i am thinking 04:27:14 <06mumra> i just mean that rather than spreading in an exact circle, it spreads procedurally 04:27:44 <02Monkooky> using A for acid, firing upward- any scheme that looks at surrounding tiles and probabalistically spreading based on those ............ ............ .....AAAY..W .....AAA.... .....A@AX..Z If spread is more likely upward, then point X will take longer on average to reach than point Y. Point Z not only will take longer to reach than point W, the variance on reach time is extreme 04:30:41 <02Monkooky> I think something like this could be done but I really really don't want it to be the underlying mechanics of the spread. Maybe spreads in a square, but fakes not doing that by changing tiles at the border prior to the proper spread- but this would definitely be something to add on rather than code up in a first draft 04:30:50 <06mumra> no i don't mean distance from player. Z and W should take similar amounts of time to reach (W one or two turns slow) 04:31:25 <06mumra> but yeah 04:31:49 <06mumra> circle or square is plenty enough for a draft 04:31:54 <02Monkooky> yeah, the problem I was pointing out will arise unintended from any actual stochastic cellular automaton that would be trying to get this spread behaviour 04:33:12 <02Monkooky> because from position ...... .AAAY. .AAAA. .A@AX. Y becomes more likely to be spread to 04:35:29 <06mumra> but there should still be a reasonable chance to spread to X as well because it has a cell to the left 04:35:54 <02Monkooky> Best you can do is half as much 04:36:33 <02Monkooky> (if you want this to broadly speaking spread forward twice as fast) 04:42:40 <06mumra> you could also do two passes on each "growth" tick: - first pass, every neighbouring cell has an even and already good chance to be spread to, say 50-90% (higher the more neighbours it already has) - second pass, we do an additional spread only in the direction of travel. so any cell that has a southern (in above example) neighbour now has another chance for spread (maybe slightly lower 50-75%) - (could even try a third pass at this 04:42:41 stage with same rule but a low % so you get a small chance of some outlying tendrils spreading even faster) would be interested to see how this looked anyway to get a feel (might knock up a quick test later) 04:43:36 <02Monkooky> that's the exact same problem; you broadly get a cone 04:45:51 <06mumra> by neighbours i mean any of 8 neightbouring cells 04:46:06 <06mumra> so i would think you broadly get an elongated circle 04:49:43 <06mumra> you would probably get a similar effect i'm imagining by using perlin noise to fuzz the edges 04:53:17 <02Monkooky> I'm really more aiming for 'mostly square' 04:53:37 <02Monkooky> an elongated circle is a very weird shape to be trying to make in crawl 05:02:11 <06mumra> i actually misunderstood your description you know > and 1 tile in each perpendicular direction so i was thinking it also spread behind you 05:02:40 <06mumra> so yeah what i am trying to describe is also mostly square, with some fuzzing 05:06:46 Unstable branch on crawl.akrasiac.org updated to: 0.32-a0-900-g30fb1b0 (34) 05:40:13 New branch created: pull/3755 (2 commits) 13https://github.com/crawl/crawl/pull/3755 05:40:14 03Monkooky02 07https://github.com/crawl/crawl/pull/3755 * 0.32-a0-892-g700a82daa1: Remove unused areaprops 10(4 minutes ago, 1 file, 3+ 8-) 13https://github.com/crawl/crawl/commit/700a82daa163 05:40:14 03Monkooky02 07https://github.com/crawl/crawl/pull/3755 * 0.32-a0-902-g2c27c95087: Merge remote-tracking branch 'upstream/master' into areaprop-cleanup 10(2 minutes ago, 0 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/2c27c95087ef 06:11:05 03advil02 07* 0.32-a0-901-g99e313a671: fix: disable requirejs timeout altogether (mumra, ge0ff) 10(10 minutes ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/99e313a67178 06:11:05 03advil02 07* 0.32-a0-902-gb4fc452618: fix: lazy load webtiles title images (mumra, ge0ff) 10(84 seconds ago, 2 files, 44+ 38-) 13https://github.com/crawl/crawl/commit/b4fc452618ee 06:12:57 <05icoson> (@mumra apologies if you were also working on either of those) 06:13:40 <05icoson> both of those changes will take a while to roll out given the way caching of non-version-specific content works, but they should percolate out automatically sooner or later 06:15:58 <12ge0ff> do these changes require a server restart? 06:16:04 <05icoson> no, they shouldn't 06:16:17 <05icoson> it's just that browsers cache the affected files for a very long time by default 06:16:20 <05icoson> like a month or something 06:18:06 <02Monkooky> bleh, I'm using four different props for this spell 06:24:24 destino (L25 OpFE) ERROR in 'tags.cc' at line 5053: Invalid item: (quantity: 0) gold piece (Vaults:4) 06:42:34 <06mumra> no, didn't start on anything to do with that, good job 🙂 06:43:55 <06mumra> this is actually something else that would be addressed as part of moving to a js bundler, since the main js bundle would have a hashed filename ... just need to make sure index.html isn't cached (at least not too aggressively) 06:44:36 <05icoson> Well, that tech is already there it’s just not used on the really static stuff 06:45:20 <05icoson> Everything version-specific works that way 06:45:45 <06mumra> yeah it's just easy to do if the lobby code is bundled as well, since the bundler gives you a hash by default 06:47:10 <06mumra> you could actually then store all assets by hash (including tilesets) rather than by a version identifier -- meaning if a given asset didn't actually change between versions, e.g. there are no new tiles, you can still use your cache from the previous version 06:48:53 <06mumra> there are also cases where static files are additionally cached by an intermediary e.g. if you're dealing with s3 buckets, but also some nginx/apache behaviours can mean you do need a server restart 07:01:03 <05icoson> maybe; those files are all served by tornado, haven't run across a case with our servers where an intermediary interferes (though some of our servers do run nginx reverse proxies) 07:01:41 <06mumra> yeah i've definitely had issues with nginx needing a restart depending on cache settings 07:11:13 <06mumra> vampire mosquitoes are brutal with current blind, hit chance is dropping to 18% at 1 tile distance, 2% at 2 tile distance (normally 57%) 07:16:45 <06pleasingfungus> mumra: the reason for the difference is that we didn’t implement an estimation of the chance for monsters to sh block player attacks 07:17:36 <06pleasingfungus> so the % to hit for mons vs players includes your sh block where applicable 07:18:08 <06pleasingfungus> but % to evade is only ev 07:18:38 <06mumra> but then ranged should also have "to evade" because shields can come into play there as well right? 07:19:13 <06pleasingfungus> ‘about’ is because the whole setup is an approximation iirc, but i’d have to dive. it’s not a decimal point thing 07:20:08 <06mumra> yep there's an approximation there, but then there are other cases that use an approximation and don't have "about" 07:20:10 <06pleasingfungus> i’d think so, yes 07:22:18 <06mumra> so ideally then it would also model sh for monsters and have to hit everywhere 07:23:13 <06mumra> because even with to hit vs to evade it's not clear to an unintuited player the subtlety of that difference 07:33:16 <06pleasingfungus> sure 07:33:37 <06pleasingfungus> basically no one understands the current distinction without me explaining 07:33:50 <06pleasingfungus> and including sh chance would be great 07:33:57 <06pleasingfungus> just need someone to do it 07:36:26 <06mumra> looking at shield blocking code, i can see why nobody has done it yet 😂 07:42:17 <06mumra> so i see several places that already are also calling the same to_hit_pct approximation and then saying "to hit" even though it should be "to evade". example: _desc_electric_charge_hit_chance so i can fix up all those instances to use the same describe function and either all say "to evade" for now so it's at least internally consistent, OR i could make everything say "to hit" so the player doesn't have to keep inverting their mental 07:42:18 math, but at least add a note on the xv screen that indicates the monster can still shield block after a hit. and at least then when anybody comes along to implement shield calculations it'll be a much cleaner playing field 07:45:11 <06mumra> part of the problem with all this stuff is that it's always a monster_info object rather than a monster instance when we're determining these things. but the attack classes all need an actual monster as the defender. so it could also be worth adding a source_monster field to monster_info so there's a reference back to the monster class, then you could actually use attack classes properly and reuse the same code paths rather than having 07:45:11 to mirror everything 07:46:35 <06pleasingfungus> i mean 07:46:48 <06pleasingfungus> the point of monster info is to avoid the possibility of leaking unknown info 07:47:15 <06pleasingfungus> including source monster would wipe out that point 07:47:37 <06pleasingfungus> eg imagine you see a monster and then lose sight of it. offscreen, it picks up a shield 07:47:50 <06pleasingfungus> you don’t want to show that when xving your memory of the monster 07:49:48 <06pleasingfungus> an unlikely case, but still undesirable (and there are other similar possibilities) 07:49:58 <06pleasingfungus> eg what if a monster dies offscreen… etc 07:51:23 <06pleasingfungus> agree you do want to use the same code paths where possible, but you shouldn’t use a monster object 07:53:31 <06pleasingfungus> want a function that takes all the relevant fields from monster… hd, copy of the shield item def, etc 07:59:25 03Monkooky02 {dolorous} 07* 0.32-a0-903-g36d3288a94: Remove unused areaprops 10(2 hours ago, 1 file, 3+ 8-) 13https://github.com/crawl/crawl/commit/36d3288a94ad 07:59:25 03dolorous02 07* 0.32-a0-904-gd9e1bd76a7: Adjust a comment. 10(5 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/d9e1bd76a72c 08:05:35 <06mumra> reading through a bit more, it's not quite as complicated as it first looked 08:06:29 <06mumra> i can maybe just store the value of shield_bonus() in monster_info and everything else is then available 08:11:06 <06pleasingfungus> nice! 08:11:16 <06pleasingfungus> sounds great 09:35:00 -!- RadicalOrchid is now known as Menchers 11:12:39 03mumra02 07https://github.com/crawl/crawl/pull/3746 * 0.32-a0-906-ge165633d8a: correctly show to hit when blind 10(2 hours ago, 14 files, 148+ 54-) 13https://github.com/crawl/crawl/commit/e165633d8a87 11:16:06 <04dracoomega> I had been going to say "Aren't sanctuary_1 and sanctuary_2 both still in normal use?" but those are FPROP_SANCTUARY1 and not areaprop::sanctuary1 11:46:45 03dolorous02 07* 0.32-a0-905-g2ec9e35ba7: Fix underline. 10(2 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/2ec9e35ba728 12:04:50 03dolorous02 07* 0.32-a0-906-gab96632d6e: Fix foul flame colour in monster info bot. 10(3 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/ab96632d6ea6 12:17:09 <09gammafunk> alas these days very few users get to see proper colors on infobot output 12:17:17 <09gammafunk> only works directly on irc 12:17:57 <09gammafunk> of course we should add full html rendering to webtiles chat, I'm sure nothing could go wrong there... 12:21:56 <12ge0ff> Was (Is?) there a cwz webtiles chat feature that allowed inserting gifs from a google spreadsheet or am i misremembering that? 12:22:52 <12ge0ff> (each server needs to have that, obviously) 12:25:45 listentometal (L24 OpCj) ERROR in 'tags.cc' at line 5126: Invalid item: (quantity: 0) gold piece (Crypt:1) 12:25:45 listentometal (L24 OpCj) ERROR in 'tags.cc' at line 5126: Invalid item: (quantity: 0) gold piece (Crypt:1) 12:38:10 Unstable branch on crawl.akrasiac.org updated to: 0.32-a0-906-gab96632d6e (34) 12:48:47 <05icoson> we do not go in for standardized title screen sizes do we; there are exactly two of these images that have the same size 12:50:55 <05icoson> so if I were to apply a max size to title images, any opinions on what it should be? I guess my inclination is to do something like max 720p height (or that minus a margin that I haven't tried to calculate) 12:51:10 <05icoson> someone mentioned 1080p the other day 13:02:57 <05icoson> hm, the lazy loading thing unfortunately does look a bit glitchier with bigger images on a real server 13:05:22 <12ge0ff> There's only a guide for creating tiles: docs/develop/tiles_creation.txt The old dev wiki doesn't have anything about title images too. 13:07:20 <05icoson> I think we've often gotten them from fanart so probably people don't want to mess with the art too much 13:09:20 <05icoson> I might revert this lazy load change, it just doesn't look very good in live testing it on cao 13:12:08 <12ge0ff> there are ways to scale down an image to fit the screen in html, like https://stackoverflow.com/questions/3029422/how-to-auto-resize-an-image-while-maintaining-aspect-ratio#3029434 13:14:18 <05icoson> I'm also concerned about size 13:14:29 <05icoson> as in file size 13:16:25 <12ge0ff> Hmm, also it looks like local tiles do autoresize title images. The biggest one - the one with the dj and gnolls - fits just fine 13:25:18 <12ge0ff> > apply a max size to title images you mean scaling down images during a build step or resizing images before accepting them/adding them to the repository? 13:25:55 <05icoson> it would be easiest to resize the biggest ones in the repo 13:28:07 <12ge0ff> most images are below 1mb and 1000x1000, so this could be a standard 13:28:42 <12ge0ff> (or just 720p, as you've said) 13:40:02 <06pleasingfungus> note that some of them were already lossily resized 13:40:14 <06pleasingfungus> eg the antaeus one and the armataur one, iirc 13:40:26 <06pleasingfungus> so ideally we’d dig up the originals before re shrinking them 13:45:41 03advil02 07* 0.32-a0-907-g8f8f606f09: fix: further tweaks to webtiles lazy image loading 10(3 minutes ago, 1 file, 21+ 10-) 13https://github.com/crawl/crawl/commit/8f8f606f09d2 13:47:49 03advil02 07* 0.32-a0-908-g8e5f33bbaa: fix: sanitize sanity check 10(71 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/8e5f33bbaa0b 13:56:18 !tell gammafunk if you want to send me the spaces keys i can copy the files over. do you want me to omit all ttyrec and ts files? 13:56:18 floraline: OK, I'll let gammafunk know. 13:57:09 Unstable branch on crawl.akrasiac.org updated to: 0.32-a0-908-g8e5f33bbaa (34) 14:45:44 <06mumra> I think they resize based on width rather than height, because I'm sure i've seen the top/bottom cropped off the screen 14:52:20 <06mumra> @icoson If the lazy loading isn't working, the normal way to do it is just create an img element and set its src const img = documeent.createElement("img"); img.src = url; img.addEventListener("load", ()=>{ console.log("it's loaded"); }) Once it's loaded the file is cached by the browser and if you add an img element to the page with the same source it'll load instantly 14:59:49 <12ge0ff> > they resize based on width rather than height <-- that's how it's done in web tiles, not local tiles. Local tiles resize title screens to fit them all (and it's responsive, you can resize the window and the image rescales): 14:59:49 <12ge0ff> https://cdn.discordapp.com/attachments/747522859361894521/1225927904077025280/hor_vert.png?ex=6622e954&is=66107454&hm=c20182027fb89ed191c73cb935459baa64d611140047032985af317dc3de56fd& 15:00:15 <12ge0ff> (at least, that's how it works on linux) 15:06:30 <12ge0ff> well, web tiles don't do any resizing of the title screens, so the big ones are cropped 15:11:45 03dolorous02 07* 0.32-a0-909-gc671339a80: Fix info leak w/unID'd shop artefacts (#3756). 10(8 minutes ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/c671339a80ad 15:24:32 <06mumra> maybe it's desktop where i saw the cropped image 15:37:40 Unstable branch on underhound.eu updated to: 0.32-a0-908-g8e5f33bbaa (34) 15:43:38 03mumra02 07https://github.com/crawl/crawl/pull/3746 * 0.32-a0-907-gd82b4977e8: also affect spell accuracy where relevant 10(57 seconds ago, 2 files, 6+ 0-) 13https://github.com/crawl/crawl/commit/d82b4977e87d 16:13:40 !tell floraline Regarding simple storage, yes, I've made a different endpoint/bucket specifically for the cko morgue/lst archive as https://cko-archive.nyc3.digitaloceanspaces.com 16:13:40 gammafunk: You have 1 message. Use !messages to read it. 16:13:41 gammafunk: OK, I'll let floraline know. 16:14:40 !tell floraline I've sent the full details and access keys to webmaster@kelbi.org. Please only copy the morgue and lst files and ommit any ttyrec-related files in the copy. Thank you! 16:14:41 gammafunk: OK, I'll let floraline know. 16:29:21 03mumra02 07https://github.com/crawl/crawl/pull/3746 * 0.32-a0-908-g8d44d4d18e: tweaks and cleaning up 10(56 seconds ago, 5 files, 15+ 37-) 13https://github.com/crawl/crawl/commit/8d44d4d18e1d 16:33:22 <06mumra> This blindness effect is reasonably polished now ... definitely could do with someone giving it a sanity check especially with all the changes to to-hit displays and so on. I added shield checks as discussed so things are way more consistent ... however spells still use a totally different route so shields are not accounted there (and it's much less clear with all the beam mechanics when shields will even come into effect). Definitely an 16:33:23 overall improvement though. I removed the spell range changes; spell accuracy is affected where relevant. Still many spells completely bypass accuracy so it's clearly way worse for melee / ranged as intended. (Spell range reduction can maybe be used for a new "magic damping field" debuff) The branch needs a little cleanup and squashing still before it's ready to merge but appreciate any further input before I do! 17:24:12 <05icoson> it was working, it was just too lazy (in practice, loading was visible at the beginning of the load screen on cao) 17:24:52 <05icoson> the last commit put image selection/loading right after lobby entry, so it doesn't block page load any more and is loaded by the time you start a game 17:25:07 <05icoson> and doesn't load every image, just the one that will be used 17:40:36 03mumra02 07https://github.com/crawl/crawl/pull/3746 * 0.32-a0-909-g511339e713: linting 10(40 minutes ago, 4 files, 5+ 7-) 13https://github.com/crawl/crawl/commit/511339e71383 17:40:36 03mumra02 07https://github.com/crawl/crawl/pull/3746 * 0.32-a0-910-g9c381d9924: more finalising, plus wrath 10(68 seconds ago, 5 files, 29+ 8-) 13https://github.com/crawl/crawl/commit/9c381d992485 17:58:42 03mumra02 07https://github.com/crawl/crawl/pull/3746 * 0.32-a0-911-g241d32eacc: fix build and add glitter 10(73 seconds ago, 5 files, 15+ 2-) 13https://github.com/crawl/crawl/commit/241d32eaccd4 18:10:25 03mumra02 07https://github.com/crawl/crawl/pull/3746 * 0.32-a0-912-g12c564555c: really fix build 10(72 seconds ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/12c564555c30 22:35:42 Unstable branch on crawl.develz.org updated to: 0.32-a0-909-gc671339a80 (34) 22:58:57 Windows builds of master branch on crawl.develz.org updated to: 0.32-a0-909-gc671339a80 23:13:17 Unstable branch on cbro.berotato.org updated to: 0.32-a0-909-gc671339a80 (34) 23:55:36 Monster database of master branch on crawl.develz.org updated to: 0.32-a0-909-gc671339a80