03:31:47 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5208-geafff8c3b6 03:55:47 New branch created: pull/3930 (1 commit) 13https://github.com/crawl/crawl/pull/3930 03:55:47 03Aliscans02 07https://github.com/crawl/crawl/pull/3930 * 0.32-a0-1759-g6cc0909dd3: Make auto-training train spell skills more readily for djinn. 10(4 minutes ago, 3 files, 8+ 5-) 13https://github.com/crawl/crawl/commit/6cc0909dd350 07:44:46 03Implojin02 07* 0.32-a0-1759-gbf73d41ef1: Fix a teleport closet in water_maze_lemuel 10(2 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/bf73d41ef1ff 08:08:20 03Implojin02 07[stone_soup-0.31] * 0.31.0-33-g4a09855ce0: Fix a teleport closet in water_maze_lemuel 10(26 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/4a09855ce0ef 08:19:22 04Build failed for 08stone_soup-0.31 @ 4a09855c 06https://github.com/crawl/crawl/actions/runs/10029317997 08:40:31 <03implojin> seems like there are some pip venv CI commits that would need to be backported to get macos CI working for .31, i'm not going to touch these personally because it looks there are several of them and I have no idea what's needed here 09:06:03 03Medrano8302 07https://github.com/crawl/crawl/pull/3923 * 0.32-a0-1727-g537a20d0fc: Update Android SDK - API level 34 10(8 days ago, 8 files, 25+ 20-) 13https://github.com/crawl/crawl/commit/537a20d0fc6a 09:48:56 03Medrano8302 07* 0.32-a0-1760-gabeaff3f86: Update Android SDK - API level 34 10(8 days ago, 8 files, 25+ 20-) 13https://github.com/crawl/crawl/commit/abeaff3f86e2 10:06:20 <03robertxgray> I think it's eb5ba95c151, I'm going to test it. 10:06:45 <03implojin> looking at advil's commit history, it seemed like there might have been more required than just that, but i haven't tried 10:57:43 <03robertxgray> Right, d495c7ad2af is also needed 10:59:07 <03implojin> thanks for looking at it! 11:02:51 03advil02 {Medrano83} 07[stone_soup-0.31] * 0.31.0-34-g075ce762cd: build: fix macos ci 10(4 months ago, 1 file, 29+ 4-) 13https://github.com/crawl/crawl/commit/075ce762cde6 11:02:51 03mumra02 {Medrano83} 07[stone_soup-0.31] * 0.31.0-35-g6cd5f5668d: Break system packages (fix MacOS build) 10(3 months ago, 1 file, 10+ 1-) 13https://github.com/crawl/crawl/commit/6cd5f5668d72 11:13:47 <03robertxgray> It seems to work okay now, on another subject PR #3913 should probably me merged, but I'm terrified of breaking the web servers 11:20:19 <09gammafunk> !pr 3913 11:20:21 <04Cerebot> https://github.com/crawl/crawl/pull/3913 11:21:21 <09gammafunk> hrm, does that actually affect webservers in any way? 11:22:16 <09gammafunk> those requirements would only be relevant at the time someone set up the webserver, I think 11:23:11 <09gammafunk> and I think even only then assuming that they set up a venv? 11:23:19 <09gammafunk> which dgamelaunch-config does not do 11:23:41 <09gammafunk> possible I'm wrong about this and the makefile is doing something though 11:25:03 <09gammafunk> also these seem to be "dev" requirements 11:26:01 <09gammafunk> there is the potential wildcard of lld and cpo having custom setups, but those admins would be used to dealing with any of this. not sure it would be relevant for those either 11:26:02 <05icoson> That should be safe to merge 11:29:25 <03robertxgray> Thank you very much for having a look at it 11:30:26 <09gammafunk> sorry about not looking much at your Android PR, but I'm afraid I can't help much there :gammafHeh: 11:30:40 03dependabot[bot]02 {Medrano83} 07* 0.32-a0-1761-g1273c59209: Bump zipp in /crawl-ref/source/webserver/requirements 10(12 days ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/1273c5920969 11:31:02 <09gammafunk> I really want to try building the dcss app and messing around with android dev now that I have an android device but only so much free time 11:31:16 <09gammafunk> should do it though, always good to learn new skills 11:35:45 <03robertxgray> great! you'll see it's very straightforward, just run: make ANDROID=1 android, and then open the android-project folder with Android Studio 12:12:10 <12asciiphilia> In the long term, I want to use DWEM to create a mobile port for Webtiles. While I'm not very familiar with Android ports, it might be easier to implement new features compared to running Crawl on SDL on Android. Features like gestures, custom UI, and menu rearrangement could be more feasible. Seeing full-screen, canvas-based games running smoothly on mobile devices makes me believe there's potential. I don't know how it will turn 12:12:10 out, but if it works well, I could organize it and create a PR. 12:12:19 <12asciiphilia> I want to do everything, but budget and time are always the issues, haha. 12:15:02 you and me both… 12:27:23 <12asciiphilia> Recently, I've been trying to properly implement the webtile recording feature from the old CWZ function module on DWEM. By saving the files (js, css, tiles) from the game-* folder, storing all the WebSocket transmission data, and then reloading it on requirejs, the webtile play should be replayed exactly as it was. I'd like to name this feature wtrec. In the past, CWZ used this feature to allow everyone to view the play records of 12:27:23 the local tournament winner (I think the tournament was called King of WebSocket). Although the functionality was crude, it at least worked properly. With this feature, it would be fun to randomly replay scenes on the server's main page, such as the last moments of a player's death, ghost extermination scenes, or Abyss banishment scenes. 12:49:08 <09gammafunk> Yes, I recall seeing that CWZ functionality years ago when you deplaoyed it. It was definitely a proof of concept of the idea of replaying webtiles games, something that many people would like to have if it could be done with good reliability. It seemed to me that you'd have to save all primary client details, such as the files you mentioned, and have a way to load these dynamically into the browser whenever a "wtrec" was requested 12:49:09 for playback. And then you'd of course want to have those wtrec files stored on the server for replay in some fashion, presumably via Sequell queries or just with some other front-end. I'm not sure how ambitious your implementation would be, since it seems a lot of work even to me, who doesn't have the necessary javascript expertise. Storage of large json files longterm on servers is also a concern. Even if those are compressed, I assume they'll be 12:49:09 significantly larger than ttyrecs and would create space issues. But depending on what you put together, I might be interested in trying it on CDI as well. 12:49:28 <09gammafunk> If file storage is an issue, we can leverage S3 buckets to help, potentially 12:54:37 ah I've been pondering a replay methodology for games. I was uncertain the most compact method, however by forcing the proper seed points for the PSRNG and remembering "input decisions" one should be able to replay an entire game after recording of initial conditions etc. 12:56:56 as for how the output would work, if you have an option for the server for webtiles etc. It might just work like the a regular game to replay said game. The difference being that all input is prerecorded and replayed and the game follows the same path. 12:58:55 <09gammafunk> yeah, elliptic commented something along those lines that it might be the most efficient way of getting replays that work for both tiles and console 12:59:20 <09gammafunk> but we'd need seed stability for our gameplay rng, which we currently don't have 12:59:42 <09gammafunk> just have that for the dungeon generation rng 14:24:58 <12asciiphilia> As I recall, the file size was larger than ttyrec, but it was manageable when compressed. (It's been almost 8 years, so my memory is a bit fuzzy, but I think that from the point the tournament winner entered the Zot realm until the final clear, the file size was tens of megabytes for the uncompressed files.) It would have been nice if the game-* folder files were stored in the crawl repository (if they were easily accessible 14:24:58 through a solution like jsdelivr, we wouldn't need to store tile information within wtrec), but since game-* data is generated after the tile auto-generation and enum auto-generation process, that's not possible. (I’m not entirely sure about this part; it’s just a guess.) I've considered configuring an automatic build backend, where if a user requests game files for a specific version, it would trigger a part of the crawl build to generate the 14:24:58 files. However, I've concluded that it's better to include the game-* resources within wtrec for compatibility purposes. (It should be just a few megabytes.) First, I plan to create this as a client-side feature on DWEM as a proof of concept. By storing data in IndexedDB, we can store data comparable to the user's hard disk capacity. Instead of recording ttyrec on the server, the user would record their session directly. Once the wtrec file format 14:24:58 spec is finalized and the proof of concept is complete, we could implement server-side recording with a bot or provide a way to view replays online (either through Sequell queries or a FooTV-like interface). 14:29:30 <12ge0ff> I think I found what happened in that game. The "door ring" Xom action added in f441f4bd93d can crash the game, if the player is below XL6: 14:29:38 <12ge0ff> cpp int soft_cap = div_rand_round(you.experience_level, 6); int inner_cap = _xom_feels_nasty() ? 8 : 2 + random_range(1, soft_cap); ^--- if XL < 6, then soft_cap can be 0, which triggers ASSERT(low <= high) assert in random_range() 14:29:53 <12asciiphilia> Yes, using S3 could be an option, but considering that the file size is significantly larger than ttyrec, there might be cost issues. If I support server-side recording, I would probably set a download period (e.g., available for 30 days). While we might not be able to support recordings of older versions of Crawl, replaying through RNG seeding could also be an excellent approach. 14:33:05 <12asciiphilia> I don't know when it will be made, but I'll let you know if there's any interesting news. Designing with just words is always easy. Haha. 14:34:09 or you can feed those words to chatgpt and get something that's almost but not entirely unlike what you wanted 😛 14:34:31 if I remember designing with words requires a few additional hand gestures so it can't be all "that" easy :D 14:35:49 I was just thinking having the option of facetious commentary might make the replay all the more fun. 14:39:11 <12ge0ff> and the crash is reproducible with &Xdoor ring when at xl 5 or lower 14:41:47 <06pleasingfungus> nice investigation! 14:42:15 <06pleasingfungus> i’m on mobile and won’t be available to fix this anytime soon, but it sounds easy now that you’ve pinned it down 🙂 14:44:13 03regret-index02 07* 0.32-a0-1762-gf39ece730e: * All three of Xom's divinations are now crunched together into one effect. Each individual component frozen in time doesn't really provide much for useful strategizing, and this also helps those with less spoilers tell where vaults are by adding creatures to the magic mapping. (Also, detect creatures using only creature genera is kinda funny anyway.) In exchange, these divinations are slightly less likely to occur, swapping positions with the already-enticingly-variable and scaling tension spells. 10(2 minutes ago, 3 files, 120+ 89-) 13https://github.com/crawl/crawl/commit/f39ece730ea7 14:53:05 <06regret-⸸nde※> (Sorry, I forgot to include the commit message title in the copy-pasting of my write-up for the commit. >_>) 15:00:16 <09gammafunk> Haha 15:00:35 <09gammafunk> Funny how chei happily printed the entire thing 15:07:24 mayhap the longest chei single commit message 15:07:33 I think --oneline only works if you obey git commit formatting; you need to leave a blank line after the commit title 15:09:09 (chei relies on git for this stuff, yes, and git has a warning about this somewhere in its docs) 15:37:30 Unstable branch on underhound.eu updated to: 0.32-a0-1762-gf39ece730e (34) 17:32:35 <09gammafunk> This sounds reasonable. I agree that it's probably best to just have copies of the js/html/tile sheets/css necessary to recreate the client rather than trying to build it. Unfortunately you do have to deal with trunk versions where each commit can change a tile (or some other aspect of the client), so there are lots of client versions to store. This is also true for stable, since there are stable point releases, but far fewer of them. 17:32:36 If you you can bundle client versions by full "vlong" (what is returned by git describe) and encode the necessary vlong in each wtrec file so it knows which client file to load, it certainly seems like it could work. But you have much more know-how than I do about doing something like this, so I'll leave it to you :gammafHeh: In any case, look forward to seeing what you come up with should you progress from the designing-with-words phase. 21:04:51 Stable (0.31) branch on underhound.eu updated to: 0.31.0-35-g6cd5f5668d 21:17:50 03Isaac Clancy02 07https://github.com/crawl/crawl/pull/3873 * 0.32-a0-1364-g5ac22092ae: Don't let the player take actions when their turn is over 10(5 weeks ago, 43 files, 1290+ 657-) 13https://github.com/crawl/crawl/commit/5ac22092ae45 21:22:08 03Isaac Clancy02 07https://github.com/crawl/crawl/pull/3873 * 0.32-a0-1364-gf5c1228098: Don't let the player take actions when their turn is over 10(5 weeks ago, 43 files, 1290+ 657-) 13https://github.com/crawl/crawl/commit/f5c1228098f0 22:35:30 Unstable branch on crawl.develz.org updated to: 0.32-a0-1762-gf39ece730e (34) 22:58:22 Windows builds of master branch on crawl.develz.org updated to: 0.32-a0-1762-gf39ece730e 23:17:27 Unstable branch on cbro.berotato.org updated to: 0.32-a0-1762-gf39ece730e (34) 23:55:10 Monster database of master branch on crawl.develz.org updated to: 0.32-a0-1762-gf39ece730e