00:00:55 <04d​racoomega> ...the wording on that Zonguldrok clarification seems really awkward to me (though I don't immediately have a clearer rephrase to offer. Perhaps I'll try later >.>) 00:01:25 <09h​ellmonk> It struck me as a bit strange but better than not having it and I couldn't think of a cleaner place to insert it 00:04:13 <04d​racoomega> I wonder if a better thing is just to explicate the slot in the mechanical text of an item a bit better, somewhere 00:04:37 <04d​racoomega> (It is in the stash search tags, but that's not something people really think to look at here) 00:04:38 <09h​ellmonk> Maybe. It does show up at the bottom in the tags I believe 00:04:43 <09h​ellmonk> yeah 00:34:35 Unstable branch on cbro.berotato.org updated to: 0.33-a0-1065-g356a6cb85b (34) 00:52:52 April fools day idea: the only entry vault is that entry vault that had the bug reprot 00:55:35 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-1065-g356a6cb85b 00:57:50 00:57:55 This looks lik ea "remove the assert 00:57:58 or just fail fast 01:11:21 what's the point of batcloud sleep if you can't stab while in that form also could you at least give vamp rpois it's kinda sad scraping for rpois in a 16 skill form 01:11:25 ty for your consideration 01:13:06 <04d​racoomega> (I was actually debating giving bat swarm good stabs - even with their reduced base damage. The thing is, I didn't want bat form to be primarily an offensive option, but I did want it to sometimes be useful offensively instead of defensively. Would need to play more with it myself) 01:16:40 <04d​racoomega> Going to end up playing a lot of shapeshifters when all this new form stuff is in >.> 01:27:18 A terrible fate 01:29:49 <04d​racoomega> Hey, they're supposed to be fun and good! 😛 01:30:10 (there was a implied /s, sorry it unclear) 01:30:13 <04d​racoomega> Certainly I'm not putting in this much effort for them to not be fun and interesting ^^; 01:30:36 I've only got the sanguine form on a character that could benefit form it one so far 01:30:44 buff drop rates plz? :P 01:31:30 <04d​racoomega> Overall talisman drop rate will be higher once there are more talismans in the game (but that isn't likely to mean any specific talisman will be more common than now - the opposite is more likely, in fact) 01:32:05 <04d​racoomega> But ideally it should be easier for any character to find something of interest, and more paths upward should exist 01:32:32 Fair, I'm half joking 01:34:01 <04d​racoomega> (I mean, currently the odds of getting relevant lower-tier talismans when a player might want to use them isn't great, but a lot of talisman play tends to center around a few dominant options that people are looking for specifically. And I do hope there will be at least a bit less of that when more different options exist. In much the same way we don't ensure players find any specific spell they're looking for, but probably will 01:34:01 find some spell to suit their needs) 01:34:22 Yeah, I think it'll help too 02:27:53 @dracoomega - here's a great seed fo rplaying with talisman on recent master - e.g. 22bb8dc075bef1512f7342836ad7eadfe1f284be seed 993086427331182572 02:28:07 ARc blade + Sanguine Talisman 03:38:30 <04d​racoomega> Slowly but surely: 03:38:30 <04d​racoomega> https://cdn.discordapp.com/attachments/747522859361894521/1347881145534120026/image.png?ex=67cd6fa3&is=67cc1e23&hm=16db4b29a59dc9f54c40acaab0d141209f7f8d5dd69d70a7a971290d409900fb& 03:39:55 Please also fix the critical bug that the plural of talisman is "talismen" :-) 03:43:27 <04d​racoomega> Haha 03:43:30 <06m​umra> Honestly I thought I'd updated that PR recently, but clearly I didn't. I've certainly dealt with some of these issues and other stuff from Draco's feedback already (I just have a whole monsters branch elsewhere where I'm tweaking and iterating a few different ideas together which has felt more useful than having lots of separate branches). I feel it needs something else to synergise further with the sigils as well as solidifying the 03:43:31 glyphcaster/scribe theme. I've considered a monster version of Construct Spike Trap (reflavoured to glyph magic) to further exploit corridors and effectively have extra free shots at the player while they're stuck. 04:11:17 forget what what I said earlier the true road block to wining a vampire is finding the talisman... you will win back to back 3 rune games without finding one 04:33:12 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:32:23 Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-1065-g356a6cb (34) 11:34:45 03gammafunk02 07* 0.33-a0-1066-gd3ab83ea69: Add staircases and hatches to the stash tracker (Dzeddy) 10(13 hours ago, 1 file, 8+ 5-) 13https://github.com/crawl/crawl/commit/d3ab83ea6940 11:41:44 <03w​heals> everything in std gets into the default namespace because macros.h (which is included in AppHdr.h, which is included everywhere) has "using namespace std;". It's definitely not recommended practice but creating a giant commit that touches every file and makes git blame more confusing isn't worth it 11:43:48 <09g​ammafunk> right, that rings a bell, thanks 12:05:15 <06m​umra> string is such a universal standard and usually reserved word in most languages ... i'd never want to name a function or variable "string" so it's never going to be ambiguous ... being required to put a namespace in front of it when things like int or bool never have one does seem weird 12:54:30 <05i​coson> I think the difference there is that string is not a C type / requires an include 12:56:57 <05i​coson> I think the reasons why using namespace std; is supposed to bad are not primarily about string per se though (in fact I think there's a school of thought that using is bad in general) 13:03:56 <12g​e0ff> by the way, it seems like there's also some problem with subprocess in python 3.13: https://github.com/crawl/crawl/issues/4353 13:06:36 <05i​coson> rip 13:07:00 <09g​ammafunk> is there a way to hide webtiles chat via RC? 13:07:14 <05i​coson> there it looks like the code relied on subprocess importing signal, which isn't part of the standard (but it's not surprising that it would have done so) 13:07:15 <09g​ammafunk> I have a unique issue where I'm trying to watch my webtiles game via an obs "browser source" 13:07:26 <09g​ammafunk> and I don't think I can control this browser source in terms of making input 13:07:37 <09g​ammafunk> e.g. into the chat window to type /hide 13:08:04 <05i​coson> I don't think there's any rc interface to that? 13:08:09 <05i​coson> it's an account level setting 13:08:17 <09g​ammafunk> ok 13:08:27 <05i​coson> I could be wrong 13:09:00 <09g​ammafunk> I'll just have to do a screen source then. Maybe I could look into adding such an option, since I think it's possible to send this sort of thing to the webtiles client 13:09:45 <09g​ammafunk> (browser source is nice because it's a fixed url and I can do whatever with my personal browser window without affecting the stream/obs) 13:10:48 <09g​ammafunk> (also I have to crop a screen source to remove the non-crawl parts of the browser window) 13:15:52 <09g​ammafunk> honestly I'm pretty tempted to just use the browser source anyhow and not worry about the "2 spectators" bar at the bottom 13:17:49 <09g​ammafunk> Never mind! OBS' browser source has an "Interact" button where I can control it! They've thought of everything! \o/ 13:33:13 <12g​e0ff> It'd be great to have an rc option for making your games completely unspectateable. There's a lag spike when a spectator joins, which is especially noticeable during tournaments. Also, if they join in a wrong time, like during a spell animation or when switching floors, you'll get a bunch of visual glitches/partially updated dungeon view. 14:07:01 <09g​ammafunk> Isn't there already a way to prevent spectators that advil made? 14:07:09 <09g​ammafunk> from webtiles, at least 14:08:04 <09g​ammafunk> But these complaints are largely related to bugs in the webtiles client/server. Spending time fixing some of those would be great, for whoever can do that 14:08:35 <12g​e0ff> some servers don't allow anonymous spectating but that's it, iirc 14:09:27 <12g​e0ff> agree about "largely", but lag spikes feel unfixable 14:10:28 <12g​e0ff> it'd be hard to guarantee that no matter how many spectators join your game won't be affected at all 14:11:46 <09g​ammafunk> well, said lag is presumably coming webtiles server when doing the map send on join (per https://discord.com/channels/735056636644687913/747522859361894521/1049016155542663178) 14:13:56 <09g​ammafunk> well "affected at all" isn't exactly the goal. "not noticeably affected" is a pretty reasonable goal. it feels a bit odd to me to have an arbitrary user setting to prevent spectating 14:15:35 <12g​e0ff> (this is mostly for tournaments, when the server is already quite busy) 14:15:55 <09g​ammafunk> right 14:16:10 <06m​umra> such spikes are definitely fixable, there's no good reason why they have to exist. spectators should be able to join without affecting your game even slightly 14:17:00 <06m​umra> the fact that it happens leads to conclusions about how things are currently working and the thread blocking nature of existing IO 14:17:24 shmup (L15 TeFE) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -35,9 in region 2, should be 2,9 in region 3) (Swamp:2) 14:17:33 shmup (L15 TeFE) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -35,9 in region 2, should be 2,9 in region 3) (Swamp:2) 14:18:17 <06m​umra> ideally you'd have the tornado server maintain a copy of the entire current map in its own, so it can send it over to new clients asynchronously without the crawl process being involved 14:19:12 <09g​ammafunk> advil said the map data of a fully mapped level is something like a 140k message 14:20:48 i was intentionally forcing crawl to show me the min rows/cols.. but.. either this is a bug, or, it never informs you of htis when connecting to an existing run? 14:20:59 if you're curious how i can trigger that intentionally 14:21:25 i figured out its 79,23 or whatever by starting a new run that is, with a small term 14:21:40 <12g​e0ff> mumra, speaking about tournaments, you previously mentioned exposing mon_info's of on-screen monsters to spectators (so they could see their descriptions?), right? Suppose someone is doing a mega-zig during a tournament, and there's a screen full of random pan lords, 200-something of them. And there's a dozen spectators watching this game. How much data the server would have to send per turn for such games (if you send mon_infos each 14:21:41 time they update)? 14:22:23 <06m​umra> i mean that's sort of a lot, but it should be gzipped over and it's a lot of the same json structure repeating over and over, so compression should be fairly good the thing is what the crawl process should be doing is sending that in a separate thread so it doesn't actually block the game thread 14:22:49 <06m​umra> when i had a look at the tornado code it seemed like things were being done async there, so i think the blocking is happening in crawl itself there 14:23:38 <09g​ammafunk> sure, the crawl binary is completely single-threaded and doesn't have any optimizations like that for websocket communication 14:24:15 <09g​ammafunk> but it sounds to me like such optimizations would also entail some significant changes on the webtiles server side of things (and I guess the webtiles client) 14:28:35 <06m​umra> well in current webtiles you'd be sending 200 packed_cells per turn in that situation, assuming all the monsters move or otherwise do something that changes their rendering. packed_cells have a slightly deceiving name, they are not as compact as the name implies anyway 🙂 (hence this 140k for a complete map) 14:29:42 <06m​umra> so sending monster_infos instead is probably no worse, and may be a lot better, if a panlord only moves and you just have to send a pos update (in current webtiles in that situation you have to send two cell updates, the cell they moved from and the one they moved to, since the packed_cell has no understanding of what a monster is or where it is) 14:31:51 <12g​e0ff> interesting, so it's kinda moving the rendering closer to the client, in a sense? 14:32:23 <06m​umra> monster_info only changes when something like a visible status changes, or when the monster's damage level changes (we don't include their actual HP), so monsters just moving around could theoretically be very minimal 14:33:03 <06m​umra> exactly it's moving the same desktop rendering to the client, and making sure we replicate the entire model that desktop tiles renders from 14:33:28 <06m​umra> luckily the model is already separated into these "information-leak-safe" silos like monster_info, map_knowledge etc 14:38:28 <06m​umra> this'd allow us to do much more complicated stuff with tile rendering if we wanted without having to worry about how much extra data we're sending over. obvious existing examples of this are like doll weapon overlays, or kraken tentacles; for both of these we're sending multiple additional fields across in json to composite the overlays (and additionally duplicating a bunch of C rendering logic on the JS side) 14:39:20 <06m​umra> whereas if you just know "it's a kraken tentacle" and can figure everything else out client side, without even having to maintain a JS port of any rendering logic, that's clearly more minimal 14:39:34 <09g​ammafunk> but such a scheme would only realistically happen if we moved to the WASM approach, right? 14:39:48 <06m​umra> yes exactly 14:40:42 <09g​ammafunk> hence it's not like we're going to start sending monster_info instead of e.g. monster tile references to the existing webtiles javascript client 14:42:26 <09g​ammafunk> although now that I think about this (still in very vague terms), even with WASM and a common UI implementation, presumably we're going to need new information-leak-safe structures so that everything is leak-proof 14:42:37 <09g​ammafunk> I'm sure the UI cheats in a bunch of ways in that regard, currently 14:42:49 <06m​umra> probably some stuff like that will come out in the wash yes 14:43:21 <06m​umra> i'm mostly worried about the player object; probably 99% of it is leak safe but i'm sure there are some obscure props stored in the player by something that would constitute a leak somewhere 🙂 14:43:50 <06m​umra> env.map_knowledge covers most of the in-game data and it's all very thoroughly leak proof 14:45:42 <06m​umra> (there's maybe some risk around unid'd items, i'm not sure how that's partitioned actually) 14:49:11 <06m​umra> there's a bunch more interesting things you could get out of doing it this way -- you could suddenly add network support in the desktop build for instance 14:50:09 <06m​umra> and you could have a webconsole build to play proper console version thru the browser 14:52:46 <06m​umra> (yeah there is no way i'd want to even contemplate doing that to be honest -- even if the existing webtiles tech was first ported to a more modern e.g. typescript/react stack -- the effort of completely replicating the entire rendering system in typescript/webgl, plus the extra maintenance introduced, would be a huge non starter) 16:41:58 Unstable branch on underhound.eu updated to: 0.33-a0-1066-gd3ab83ea69 (34) 17:04:39 shmup: Last I checked the minimum screen size is smaller (just) horizontally than 80x24 _but_ things don't reliably know that; IIRC I suggested it just be changed to 80. 17:20:30 krsz (L21 MiFi) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 2284 failed. (Elf:3) 17:26:37 <06m​umra> Finally I present: Crawl - Wasm Edition https://crawl-webtiles-2.netlify.app/ 17:29:04 <06m​umra> Seems I got pretty much everything working (including save persistence, importantly). Doubtless if you play for a while you will probably hit a crash or infinite browser loop. Startup is pretty slow but the des cache is working so subsequent loads should be better. Enjoy! 17:30:10 <06m​umra> (If you do get a crash, some useful stuff should be in browser console. The crashlogs should get stored in IndexedDB but I haven't worked out how to access them yet...) 17:32:39 excellent job mumra 17:35:26 yoinked ur wasm 17:39:23 <06m​umra> Thanks 🙂 Am very impressed with emscripten. I've seen stuff done with it before but first time using it myself. Very few code changes were needed in the end to basically get it working, although a few more things could be tweaked to get it a bit nicer. But yeah, it largely "just works" 17:42:33 <06m​umra> I need to make the canvas fill the browser viewport, and get fullscreen working. And support for editing your rcfile. 17:52:24 <06m​umra> I'm thinking it'd be cool to make a build of this that just e.g. runs some randomised arena battles, and embed it on the DCSS homepage 18:08:06 <3 that idea 20:02:13 @mumra - very cool. And I like the idea of local client build with logic running online 20:02:34 I might actually play that :D 20:02:53 <06m​umra> Made some tweaks. Better default config and properly fills the browser window now (but not automatically on browser resize, unfortunately, you have to refresh) 20:02:55 it still would have some of the webtile latency, but still, might be snappy enough forme 20:05:25 Wait, is the recent move thing an rc file option? 20:05:28 the footsteps 20:05:38 I assumed that was webtile only, maybe I have it disabled 20:06:17 RE: rcfile editing, presumably that can get attacked along with whatever logic will eventually choose a version 20:07:16 It's honestly pretty snappy 20:07:58 Very very nice work 20:08:26 <06m​umra> I'm strongly suspecting the webtiles latency could be very much improved (with a bit of rewrite of how client/server stuff works) 20:08:48 well, question there may be how much is thread scheduling vs network, I guess 20:10:32 But yes, almost certainly 20:10:40 140k sounds like way more data than should be moving 20:10:55 <06m​umra> Webtiles has show_travel_trail = true as default but yes you can enable it in desktop as well. Made sense to enable it here by default for now as autoexplore and rest were noticably slower than desktop build. I think there's some optimisation to be done - I'm led to believe now that some large memory copies that might be trivial in native C++ apps are suddenly quite expensive in wasm (combined with the multithreading and additionally 20:10:55 having to copy stacks between workers and so on anyway) 20:11:31 large memory copies are never cheap but sometimes worse than others 20:11:40 WASM's memory model might also be somewaht to blame 20:20:55 <06m​umra> (I don't know where this 140k figure has come from tho, I can't see anything remotely that big just casually specating some games. Maybe that's a worst case scenario) 20:23:12 I think that was stated as a worst case for a full redraw of the entire level, or something 20:25:29 <06m​umra> Yeah very rare you would see that in practise. Maybe in a fully-explorerd shoals I guess 20:28:13 Definitely some room for careful improvement, I think 20:28:21 regenerating des could probably be parallelized? 20:28:26 locally too 20:29:06 or just be pre-canned 20:32:52 <06m​umra> interesting idea 20:36:04 <06m​umra> but yeah i don't know why we don't just normally include it in releases (certainly can here anyway) 20:36:04 Adds complexity? 20:36:04 <09g​ammafunk> advil just monitored some json data upon join specifically I think 20:36:04 Ah... on join 20:36:04 right, ahve to get full state 20:36:04 <09g​ammafunk> I just know the context was lag specifically when spectators join, not when they're already watching 20:36:04 That does make sense 20:52:32 Hmmm 22:18:16 the perf traces aren't entirely making much sense to me 22:18:19 will ahve to look at it more 23:35:33 Unstable branch on crawl.develz.org updated to: 0.33-a0-1066-gd3ab83ea69 (34) 23:58:41 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-1066-gd3ab83ea69