04:17:52 03Aidan Holm02 07https://github.com/crawl/crawl/pull/632 * 0.21-a0-407-g96f6a8f: Refactor Menu scrolling into MenuDisplay 10(3 days ago, 6 files, 402+ 317-) 13https://github.com/crawl/crawl/commit/96f6a8f05605 04:17:52 03Aidan Holm02 07https://github.com/crawl/crawl/pull/632 * 0.21-a0-408-gaeef195: Remove limit on lookup-help results length 10(2 days ago, 1 file, 8+ 17-) 13https://github.com/crawl/crawl/commit/aeef195487df 04:30:17 -!- Yermak_ is now known as Yermak 05:04:10 -!- amalloy is now known as amalloy_ 05:07:05 -!- amalloy_ is now known as amalloy 06:07:13 -!- amalloy is now known as amalloy_ 06:17:29 So i'm interested in improving crawl's UI, especially wrt different window sizes, which a lot of the UI completely ignores (in both console and tiles) 06:17:46 since this would require a lot of rewriting, I'd like to bite the bullet and implement a box-based layout system, then incrementally convert UI code to use this 06:17:53 rather than augment each part of the UI individually 06:18:13 would this be something that you'd be willing to merge? 06:36:59 Certainly sounds nice; we're happy to have someone work on UI stuff in general 06:37:27 I'm not very qualified to comment on the technical merits of your approach; maybe |amethyst and/or advil are more so 06:38:02 My crowning Tiles achievement is fixing mouse lag that I introduced after the move to SDL2 06:38:26 And I barely have a grasp on the areas that I changed 07:28:45 Yeah; it's pretty confusing at present 07:30:12 I'm currently still fleshing out the idea; I've implemented this sort of thing before, but the trifecta of console/tiles/web add new and interesting twists 07:34:04 But in brief: the aim is to, for a given UI, declare a widget hierarchy that is automatically re-laid-out as necessary 07:34:41 tiles/console would both be supported (for console, the layout is on a character grid, not a pixel grid) 07:34:56 oh, that sounds interesting 07:36:16 sounds like a formidible rework of the UI code 07:41:08 Yeah... it'd have to be an incremental conversion 09:00:36 that sounds like a good project but yeah, not trivial :) 09:01:24 you should probably be aware that there's a school of thought that console ought not to be resized 09:01:38 I think because it messes up ttyrecs? (but I've never really followed) 09:07:32 FWIW it took me nearly 3 weeks (spare time only) to integrate into crawl a text input box 09:08:04 and it's only an ok text input box, not like the most amazing widget ever, but before that there was only text input in the messages window 09:08:15 so I have a pretty pessimistic view of time estimates for this stuff in crawlcode 09:08:50 no-console resize would be one of the more trivial things to handle; just use 80x25 instead of the actual console size 09:09:23 Oh, it's definitely going to take a while 09:09:53 well, I just mean to say that there are people around (maybe none currently active) who won't find value in making console resize work better; I'm not one of them personally 09:10:18 Ah, I see 09:10:49 & anyone who doesn't want to can just not resize 09:11:18 That does strike me as the most obvious workaround, yeah :) 09:11:50 but it may be worth at some point trying to understand what the objection is, and if it's just ttyrecs 09:12:09 * aidanh googles ttyrecs... 09:12:28 all online games are recorded in ttyrec format 09:12:37 <|amethyst> ttyrecs don't store console size at all 09:12:39 and it definitely does get messed up by resizing 09:12:43 yeah, for that reason 09:12:55 <|amethyst> so these are the same people who don't like people playing at anything but 80x24 :) 09:12:59 you have to match the size to replay successfully 09:13:30 Right... well that makes sense, even if it's kind of demented 09:13:36 <|amethyst> you just have to have a bigger terminal than the actual size, assuming you don't rely on the terminal automatically wrapping 09:13:49 ah ok 09:13:50 <|amethyst> and I don't think we do usually 09:13:56 and maybe footv can't resize? 09:14:17 <|amethyst> I don't know much about the web footv 09:14:21 1learn crawl-dev aidanh: well that makes sense, even if it's kinda demented 09:14:21 johnstein: You have 1 message. Use !messages to read it. 09:14:25 ttyrec is an ancient, obtuse format, but it's the only one we have 09:14:34 ^status 09:14:34 21 Crawlers. CBRO disk usage=96% (135GB) | RAM usage=29% (4GB)| uptime/CPU= 09:14:34 up 236 days, 13:52, 0 users, load average: 0.18, 0.31, 0.29 (4 Cores) http://status.berotato.org 09:14:53 btw one area that needs some cleanup is the HUD 09:14:53 speaking of ttyrecs, looks like it's filling up faster and faster 09:15:28 having configurable widgets in the HUD has been a wishlist item for a while, I think no one's done it because that code is kind of painful, and it's hard to do and sync with webtiles 09:16:09 <|amethyst> I'm happy to have someone with experience in cross-platform cross-toolkit GUIs work on it though :) 09:16:13 right now most of that is drawn by using cgotoxy and then printing stuff 09:17:37 HUD being the sidebar panel? 09:17:46 the thing with HP etc 09:18:14 specifically the part that's relatively constant across build targets 09:21:47 definitely seems like something that in principle would be better with a box-based layout 09:24:09 btw have you looked much at PrecisionMenu? 09:24:58 I've had a brief look at it 09:26:29 depending on what you mean by box-based, it might be sort of along the lines of what you have in mind, not that it's super easy to work with either 09:26:58 main use of that is in skill-menu.cc 09:29:36 It seems to be mostly based around attaching items to explicitly specified screen areas 09:30:42 My layout concept is more declarative and hierarchical; I guess a good analogy would be like CSS's flexbox model 09:31:10 Or something like GTK's layout model 09:33:38 I still need to conduct a survey of how the UI stuff actually works, in order to get some idea of what features the layout system would need 09:33:55 And webtiles and the spectating thing adds a unique twist 09:34:12 well, webtiles is using a css box-based layout 09:34:45 so it's already there 09:35:07 the actual boxes are mostly hardcoded in html/css though 09:35:25 Not for things like menus: those are rendered with the same pseudo-CRT approach 09:35:40 same approach that local tiles uses, i mean 09:35:41 yes, that's true 09:36:00 but I'm not sure that's the ideal of webtiles 09:36:33 Well, yeah, i'd say there's significant room for improvement 09:36:35 just a compromise to avoid having too many different ui code paths 09:37:01 Right; I do understand why that approach is in use 09:38:14 The current approach allows sharing UI state, which makes spectating relatively simple. If you have a different webtiles UI that takes advantage of the platform, you can't share that state, and you need to switch to a different spectating mechanism 09:39:14 I.e. a spectation API that communicates higher-level actions, not low-level state changes 09:47:31 yeah 09:48:02 but anything that doesn't have fine-grained input could easily be done like the HUD is (and the HUD in local tiles/console could in principle be done using menu.cc-like code, it just isn't) 09:49:30 there are already some cases where they diverge, text input is done in browser and the result is visually shown to spectators using pseudo-crt 09:50:02 What sort of customization options were on the table for the HUD? 09:50:57 well, some people have wanted the ability to control the order and type of things shown there; I'm not sure there's a massive demand for it but it seems like an interesting project 09:51:23 %git c068411295f4b7d37c8660aec62318ad5f616282 09:51:23 07elliptic02 * 0.20-a0-911-gc068411: Add an option to replace the noise bar with an equipment bar. 10(7 months ago, 4 files, 44+ 11-) 13https://github.com/crawl/crawl/commit/c068411295f4 09:51:28 is one example 09:51:33 Hm; if you expose the widget hierarchy to Lua, you immediately get virtually limitless customization 09:52:03 You need the API support and infrastructure for it, of course 09:52:38 yes, that would be a way to go 09:52:38 there's no widgets in the hud right now though 09:55:19 Synchronizing that with spectators would be virtually impossible though, but I don't even know if that'd be desirable 09:55:59 yeah, elliptic's change is console-only, and I believe spectators in webtiles would still see the noise meter 09:56:20 well I think it works in local tiles too? 09:56:55 I was thinking of spectators being confused if a player had item interaction widgets or something 09:57:06 Anyway, that'd be something to consider once (if...) I can the basic system working 13:08:34 -!- amalloy_ is now known as amalloy 14:56:01 hm, how did https://www.reddit.com/r/dcss/comments/78p2si/is_this_a_spawning_bug/ happen? the vault is tagged as no_monster_gen. are ghosts exempt from this restriction? 15:05:40 hm. have to think it's a bug 15:06:07 normally I'd suspect things like tele traps, ut sewers should have none and/or that part should be no_rtele_into etc. 15:09:45 also, come to think of it, I;ve seen a fair number of ghosts spawned in areas they shouldn't be (e.g. one of the 'tanks' in nem_the_choice) 15:09:59 also the very occasional unique 15:10:11 but for some reason not normal monsters 15:10:41 (which, ??? I thought uniques were spawned via random minivault placement) 15:20:25 ashenzari_visionary is another one I've seen capture both uniques and ghosts 15:43:04 Ghosts often spawn in deep water area in ice caves too 15:50:47 -!- G-Flex| is now known as G-Flex 17:08:40 <|amethyst> yes, ghosts do not obey monster placement restrictions because they use just monster::find_place_to_live (ultimately leading to monster_habitable_grid), while the MMT_NO_MONS restriction is handled in newmons_square_find 17:09:04 <|amethyst> s/monster.*restrictions/the no_monster_gen kmask/ 17:09:54 <|amethyst> and uniques do not obey it, because they are vaults which are explicitly allowed to be placed inside existing vaults (the overwrite_floor_cell tag) 17:10:06 <|amethyst> ghosts could probably be made to obey it fairly easily 17:10:15 <|amethyst> uniques might be a little trickier 17:12:48 Newbie developer question: right now my 'make' command takes half an hour to finish. Is there a way to speed it up? 17:13:42 <|amethyst> Yermak: -jN where N is the number of cores on your machine, or maybe that plus one 17:14:10 <|amethyst> Yermak: secondly, make NO_OPTIMIZE=y will build faster, but the crawl binary will be slower of course 17:15:14 <|amethyst> Yermak: thirdly, if you switch between branches or between builds, you might want to try out ccache to cache the object file outputs. That won't help if you're actually changing things (especially header files), but it does at least keep it from having to be actually recompiled every time you change a build flag then change it back 17:15:35 oh, it seems this is what I want 17:16:30 <|amethyst> Yermak: you might need to increase the default cache size for ccache, since we generate hundreds of megs of .o for each build, at least if debug information is turned on 17:21:07 <|amethyst> a user on reddit is reporting that they have part of the UI cut off in trunk (the right 20 pixels or so maybe). This makes me think of the changes related to default scaling for fullscreen vs non-fullscreen 17:21:11 <|amethyst> https://www.reddit.com/r/dcss/comments/78pea3/ 17:38:50 This line in INSTALL.txt is confusing: 17:38:51 https://github.com/crawl/crawl/blob/master/crawl-ref/INSTALL.txt#L125 17:39:17 Imo, command should be separated from the rest of the line 17:40:00 oh yeah, that is weird. that is clearly two different commands 17:42:45 03amalloy02 {GitHub} 07* 0.21-a0-402-gcbae7d1: Clarify command-line instructions (Yermak) 10(7 seconds ago, 1 file, 22+ 12-) 13https://github.com/crawl/crawl/commit/cbae7d1ba227 17:51:32 amalloy, should ccache speed up things right after its installation (since .o already exist) or should it "remember" .o files by running 'make' from scratch? 17:52:15 <|amethyst> Yermak: the latter 17:52:18 .o files created prior to installing ccache will not be in its cache 17:52:19 ok, thx 17:52:19 No keyword 'files' 17:53:33 but even without ccache, `make` avoids rebuilding .o files that are already present if their dependencies haven't been modified. so eg, running `make` twice without any changes in between, the second one will be much faster 17:53:48 so you might see some speedup after installing ccache anyway 17:54:53 without ccache make always takes half an hour 17:55:19 even if I run it without changes in between 17:55:23 What could be the case? 17:58:36 you're running on windows as i recall, right? 17:58:45 nope, couple of days on Ubuntu already 17:58:49 hm 17:59:10 well, so much for "blame it on windows" 18:01:46 hm. with no changes it's a couple seconds here 18:02:23 I haven't exactly run "make" and then "make" again. I did run "make" and "make TILES=y" 18:02:32 that will take a while, yes 18:02:34 oh, well that's going to require rebuilding a lot of stuff 18:02:36 oh 18:02:45 that's something ccache can hopefully help with 18:03:05 if your cache is large enough to store a tiles build and a console build at the same time you'll be able to switch between them cheaply 18:03:11 I keep separate repos for console and tiles and pull/rebuild each separately 18:03:24 or do that 18:03:37 Unstable branch on underhound.eu updated to: 0.21-a0-402-gcbae7d1 (34) 18:04:00 when I had local patches I made use of git stash to keep them in sync 18:04:18 (this was on OS X where I'd patched the Makefile to use deps from macports instead of contribs) 18:05:48 sadly tiles changes are not consolidated into one or a small handful of files; tghey're all through the source, so it needs to do a full rebuild. likewise WEBTILES 18:06:18 but that at least also works for consolem whch TILES=y doesn't and never will because of GUI vs. console app behavioral differences on both Windows and OS X 18:06:46 as well as needing code refactoring 18:07:51 -!- gressup_ is now known as gressup 18:08:02 As far as my changes don't touch anything that can cause different behaviour in tiles and console I guess I can use only one of them. 18:08:31 Is there any perfomance downside in using tiles instead of console? 18:09:43 yes, must almost all hidden in the support libraries (curses vs. sdl) 18:09:49 *yes, but 18:10:09 GUI's inherently going to involve it doing more work 18:15:09 sure, tiles is more work, but for a halfway modern system tiles is still not very much work 18:26:40 What is current TAG_MAJOR_VERSION? 18:26:52 MAJOR* 18:37:48 !source TAG_MAJOR_VERSION 18:37:49 Can't find TAG_MAJOR_VERSION. 18:37:52 oh well. it's 34 18:39:11 For example, MUT_ROUGH_BLACK_SCALES was removed a year ago. But it still has #if TAG_MAJOR_VERSION == 34 18:40:00 Is it just for compatibility with old characters who still have the muattion? 18:40:03 yes 18:40:06 ok, thx 18:40:43 the idea is that we keep the code for back-compat, but mark it as TAG_MAJOR_VERSION==34 so that on that glorious day we finally break save compat, we know we can delete that old code 18:41:03 I see 18:41:40 I was worried for a moment that we have to keep compatibility with old versions too 18:42:05 no, TAG_MAJOR_VERSION changes correspond to breaking save-compat 18:42:17 which used to happen a lot more often than it does now 18:49:37 What is git e-mail used for? 18:49:41 well. de facto I think it has already happened; you don;t get crashes but older games are increasingly unplayable when brought forward. levels with ghosts instead of monsters, characters built for one style of play that fail in the style that works in current versions (hello Nem!), etc. 18:49:56 technically 'playable' but not worth anything but quitting and starting over 18:55:03 ok, here is my first patch (one line deleted, hah): https://crawl.develz.org/mantis/view.php?id=11155 18:59:13 03Yermak02 {amalloy} 07* 0.21-a0-403-g4337635: Fix LARGE_BONE_PLATES colouring in Statue Form 10(8 minutes ago, 1 file, 0+ 1-) 13https://github.com/crawl/crawl/commit/43376356476d 18:59:24 looks good to me. congratulations on your first commit 18:59:33 thx (: 19:01:39 hey 19:01:45 i finished transferring the files 19:01:59 but having a weird error on running the update scripts from dgamelaunch-config 19:02:25 Yermak: typically we add people to CREDITS.txt when they make their first contribution. how would you like to be credited? 19:02:33 like /home/crawl-dev/dgamelaunch-config/bin/dgl update-stable 0.17 19:02:33 is throwing me https://pastebin.com/pDDLHqmN 19:02:38 As Yermak 19:03:36 03amalloy02 07* 0.21-a0-404-g291f19a: Add Yermak to CREDITS 10(12 seconds ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/291f19a91913 19:07:56 ZiBuDo: that looks sorta like a problem caused by having the wrong C++ compiler version? |amethyst would be the one to know though 19:08:10 i think you are right 19:08:12 that was my guess 19:08:16 but i wasn't sure 19:08:22 and am not sure which version i need 19:08:31 what does gcc --version say? 19:09:00 looks like i got memed 19:09:00 and it isnt installed 19:09:08 xD i swore i had this on the new os 19:09:10 rip 19:09:11 hm. maybe it's clang or something. what about cc --version? 19:09:16 since you clearly seem to have some kind of compiler 19:09:33 cc (Ubuntu 7.2.0-8ubuntu3) 7.2.0 19:10:44 well, good news, there is a compiler. the bad news is i don't know what to do with a version number, i just hoped it might be more useful 19:11:00 xD 19:11:39 i'm also not sure whether crawl requires c++14 or c++11. i think it's just 11 19:12:06 well it's the only thing on this server that requires c++ for me so i don't mind having one compiler for crawl 19:12:22 i don't have it noted the version in all my notes 19:12:39 we only require c++11 19:31:40 imo upgrade to c++20 early, get out ahead of the hype 19:47:49 The build has errored. (master - 4337635 #8862 : Yermak): https://travis-ci.org/crawl/crawl/builds/292879319 19:50:31 that worked 19:50:35 upgraded to gcc 7 19:50:51 since that is 11 compat 19:50:51 thanks! 19:53:53 What's with travis-ci? 19:54:51 builds randomly fail sometimes due to inability to properly set up the build environment 19:55:04 So that was a false alarm 19:55:29 not specific to crawl either, it happens in every project I'm involved with that uses travis-ci 19:56:13 they may well throttle network access for the free tier or something 20:30:30 huh i am getting: bison: option '--defines' doesn't allow an argument 20:30:30 for: Makefile:23: recipe for target 'levcomp.tab.cc' failed 20:30:44 anyone on the top of their head know what could be causing this? 20:34:43 got it apparently bison was out of date xD 20:55:33 Wow, I haven't thought of putting exclusions in labyrinth earlier. It was wise to ban them here! 20:55:45 heh 21:17:44 i tried to make exclusions in a labyrinth once. i forget why: i wasn't trying to cheat the system by putting down permanent markers or anything. i think there was just a monster i wanted to remember to avoid 21:18:05 or maybe even compute its line of sight? that's a cool thing you can do with exclusions 21:21:25 yeah 21:31:16 -!- amalloy is now known as amalloy_ 21:41:16 Wow, it looks like monsters can carry only one type of potion, one type of scroll and one type of wand! 22:03:02 -!- Telnaior_ is now known as Telnaior 22:30:06 so i am trying to get the webtiles up right now --- getting No such file or directory: '/tmp/crawlp3F64h' and Exception in callback 22:30:06 where File "/usr/lib/python2.7/socket.py", line 228, in meth 22:30:06 return getattr(self._sock,name)(*args) 22:30:06 error: [Errno 13] Permission denied 22:30:06 --- any1 know if previous saves relied on old tmp files? if so how do i reset the save? 22:34:05 that would be a websockets connection as a local socket, and you need to tweak systemd permissions 22:35:11 that is, when webtiles spawns a game, it uses a local socket to talk to the crawl process. on an increasing number of systemd-based systems, /tmp is locked down in daemons to only allow access to the daemon's own created files. 22:35:26 you need to tweak some setting to override that for webtiles to be able to talk to games 22:36:08 hmm 22:37:31 -!- mikee___ is now known as mikee_ 22:37:50 https://stackoverflow.com/questions/30444914/php-has-its-own-tmp-in-tmp-systemd-private-nabcde-tmp-when-accessed-through-ng possibly 22:38:50 (but possibly not as well. there's also systemd-tmpfiles acl config which looked a bit gnarly) 22:41:16 so does the tmp problem extend to the socket permission or would these be 2 diff problems 22:42:08 it would express as permissions 22:42:45 basically, there's this thing called cgroups that allows systemd to customize what permissions a process associated with a cgroup sees. in this case it is restricting processes in /tmp 22:42:53 er, accesses 22:43:23 if the file exists and would be readable, accessed via the cgroup it might not be readable. if it doesn't exist, the cgroup might not let it be created 22:44:31 you may be able to just disable the systemd-tmpfiles service and reboot to get normal unix behavior, from what I am seeing 22:46:08 well that would be the best thing 22:46:16 cuz this sounds annoying 22:47:00 (this will disabble /tmp protection globally though; better would be to figure out what access crawl needs and leave it in place) 22:49:15 -!- mikee___ is now known as mikee_ 22:54:21 i think i fixed it since the log isnt throwing thows errors but it just hangs when trying to open a socket: https://crawl.jorgrun.rocks:8081/ if you want to try right now 22:54:25 try trunk for now 22:55:59 I can't, sorry. (crap local network. sometimes I manage to connect but the upstream router times out the socket pretty much immediately) 22:56:14 nvm the problem is persisting 23:35:40 crawl master recently passed 55555 commits 23:36:13 %git 9255a1437d5a289aca909cbc8ad7fa2e5d4f909f 23:36:13 07advil02 * 0.21-a0-315-g9255a14: Only calculate ash bonus for ash characters 10(4 weeks ago, 1 file, 2+ 1-) 13https://github.com/crawl/crawl/commit/9255a1437d5a 23:59:31 Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-404-g291f19a (34)