00:08:59 ebering: looking good 00:10:03 thanks again! 00:10:45 Unstable branch on crawl.jorgrun.rocks updated to: 0.23-a0-370-gf497b7cc99 (34) 00:31:02 Unstable branch on CRAWL.XTAHUA.COM updated to: 0.23-a0-370-gf497b7c (34) 01:21:21 Unstable branch on crawl.develz.org updated to: 0.23-a0-370-gf497b7c (34) 01:59:05 Windows builds of master branch on crawl.develz.org updated to: 0.23-a0-370-gf497b7c 02:12:36 -!- amalloy is now known as amalloy_ 02:59:59 Monster database of master branch on crawl.develz.org updated to: 0.23-a0-370-gf497b7c 03:23:21 Unstable branch on crawl.beRotato.org updated to: 0.23-a0-370-gf497b7c (34) 07:38:25 %git 0b11513c 07:38:25 07ebering02 * 0.23-a0-372-g0b11513: Exploration based trap effects. 10(4 months ago, 6 files, 60+ 7-) 13https://github.com/crawl/crawl/commit/0b11513cd37b 07:38:40 Logis limps here, I think. 07:38:45 logics* 07:40:25 When you're exploring a corridor the chance to get a trap effect is the same as before. And it's much bigger (you open up to 15 new tiles when walking orthogonally and up to 29 diagonally) when you explore open space. (Not even taking into account the fact that previously you had a non-zero chance to spot the trap before stepping onto it.) 07:41:49 You might argue that player also does moves that don't open new tiles. 07:43:18 We can look at the level in whole: when it's fully explored, the number of tiles you've stepped on isn't equal to level total area, but is much less. 07:46:39 I don't mind increasing the odds of being shafted or marked (though I do think the increment is way too big). I just think it should've been mentioned in commit description in case it was intentional. 08:48:46 %git 08:48:46 07advil02 * 0.23-a0-370-gf497b7c: Improve (?) filtered_vector_select 10(9 hours ago, 1 file, 8+ 7-) 13https://github.com/crawl/crawl/commit/f497b7cc9947 08:48:54 oh I see 08:49:46 Yermak you probably know this but that is in an experimental, not trunk, chei just doesn't say that on repeating the commit description 09:02:38 Yeah, I figured it out. 09:19:04 I do kind of agree that the penalty for moving in open areas is too high if trap chance is just proportional to # of squares revealed 09:19:10 I'm also a bit confused about some of the math in that PR 09:19:20 but it might just be that I haven't stared at it long enough 09:25:11 it seems like trap_count is going to end up 0 a lot, maybe that's intentional 09:29:38 I also would prefer a single instance of x_chance_in_y(trap_count, env.density), because that keeps the interpretation of num_traps_for_place closer to what it was doing before 09:30:48 though the fact that num_traps_for_place gets rerolled for *every square revealed* in this change is maybe not ideal? 09:31:47 it makes it a lot harder to interpret, because it is now repreenting a distribution rather than a single fixed (randomly drawn) number per level 09:33:20 it might be better to pick that value when doing level layout (what happens in current trunk), reserve some of the probability mass there for random traps, and save that with the level itself 09:33:29 I suppose I should be writing these notes on the PR 09:34:52 (by "random traps" I mean explore-revealed traps) 10:21:04 that is definitely the most experimental part 10:21:36 since traps aren't being placed I could see derandomizing num_traps_for_place 10:21:45 and re-naming it trap_rate_for_place 11:21:25 New branch created: pull/873 (1 commit) 13https://github.com/crawl/crawl/pull/873 11:21:25 03Doesnt02 07https://github.com/crawl/crawl/pull/873 * 0.23-a0-371-g63750ef: Spelling 10(8 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/63750effbbb4 11:37:02 03Doesnt02 {advil} 07* 0.23-a0-371-g3bc7ea6: Spelling 10(23 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/3bc7ea6fc1a9 12:10:45 Unstable branch on crawl.jorgrun.rocks updated to: 0.23-a0-371-g3bc7ea6fc1 (34) 13:05:31 Unstable branch on crawl.akrasiac.org updated to: 0.23-a0-371-g3bc7ea6 (34) 13:38:42 03stenella02 07https://github.com/crawl/crawl/pull/871 * 0.23-a0-372-g8c11ec0: Reverted accidental indentation changes, added comments for unicode characters 10(87 seconds ago, 2 files, 162+ 139-) 13https://github.com/crawl/crawl/commit/8c11ec0dd316 13:39:18 advil: 13:55:27 -!- amalloy_ is now known as amalloy 14:00:12 hm so msvc can't handle the unicode characters in the comments? 14:00:19 those are kind of useful for documentation purposes 14:00:27 oh no 14:00:31 I'm looking at the diff backwards 14:01:11 nevermind 14:05:11 the original diff just changed them to the codes, without the comments. i added the comments when i fixed whatever it was i broke with the indentation 14:05:11 though it does make the file look a bit uglier 14:05:20 yeah, having the comments is good 14:05:49 le sigh 14:06:04 can't just mindlessly copy-paste and have everything else work 14:06:09 debug isn't building properly 14:06:16 and freetype doesn't build x64 from what i can tell 14:06:25 this will require effort ._. 14:07:15 but win32 release tiles works 14:07:21 and that's all anyone uses anyway amirite 14:07:29 where the other msvc developers at 14:08:10 well, getting the release tiles version to build is a definite step forward 14:08:41 at the very least it shows that it can be done without any major overhauls (not counting the ones we already did) 14:09:02 i'm still pretty out of my depth 14:09:12 debugging msvc is hard 14:13:26 I'll probably fix the VLA thing in trunk at some point later today 14:13:32 sweet 14:13:47 how do you feel about having the project files for the contribs somewhere within the crawl repo 14:13:52 rather than inside the submodules 14:14:17 so i can iterate them (now and maybe later) without pushing to the submodules 14:14:57 though i'm not sure how much that would break 14:15:25 i'd just have to retarget them i think 14:15:45 ah...ideally they should be in submodules if they are under contrib, but honestly if it's in the MSVC directory I'm just going to merge it without looking hard 14:16:07 i.e. instead of having contribs.sln in \contribs pointing to a bunch of shit inside the individual subdirectories, you have contribs\contribs.sln and contribs\.vsproj or whatever 14:16:45 because right now you have contribs.sln pointing to like contrib\freetype\projects\windows\vs2012\freetype.vsproj 14:17:00 and if i edit the information in that vsproj i have to push to freetype 14:17:15 probably don't want to put them right in contribs, a subdirectory might be ok 14:17:23 not sure how other people feel about it 14:17:27 sure, just anything that isn't in the submodules 14:17:39 it's probably becuase i'm uncomfortable but this seems like a huge pain in the ass 14:18:07 i.e. pushing to 8 submodules 14:18:14 if it were dev-maintained it would be a definite no but what you're proposing might make organizational sense for something where it's probably not going to be, just to know what is necessary for getting msvc to work 14:18:55 i don't entirely follow what you mean by the first bit 14:20:03 just that I would oppose a change like this for e.g. Makefile-based build infrastructure that people with commit access were going to maintain, but this isn't quite the same thing 14:20:36 I guess one thing to keep in mind is that crawl can (and does) get built without using the submodule versions of the contribs 14:20:40 am i misunderstanding how the submodules work? haven't they been untouched for like 14:20:41 years++ 14:21:02 yes, because they all still work 14:21:02 sdl2 gets updated the most 14:21:21 i wonder 14:21:37 I'm not sure that building with non-submodule-versions will ever be an option for msvc so mixing the build systems probably won't matter? 14:21:57 i'm not 100% that i even changed much in the submodules 14:22:18 crawl-libpng is definitely missing a folder that came with that version, though 14:23:10 wait, it isn't 14:23:12 one second 14:25:41 i don't think any changes are necessary to the submodules 14:28:18 testing now 14:48:03 -!- jilles_ is now known as jilles 14:48:14 -!- babulose_ is now known as babuloseo_ 14:48:34 -!- babuloseo_ is now known as babuloseo 14:48:53 -!- aidanh_ is now known as aidanh 14:48:59 -!- FredrIQ is now known as FIQ 14:56:01 oh, cool 14:56:14 so tilegen.exe wants libpng.dll, but crawl.exe wants libpng16-16.dll 14:56:19 where is this information stored 15:03:01 -!- Mindiell_ is now known as Mindiell 15:15:48 03advil02 07* 0.23-a0-372-g5ce4c07: Try again to avoid recursive crashes when loading level/save data 10(71 seconds ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/5ce4c072109a 15:22:33 heh, I take it you decided to go with msvc file in the submodules? 15:22:55 i'd have to retarget everything to do it a different way 15:23:01 i guess so, yeah 15:24:15 you can pull all of those without looking at them, they're all project files 15:24:23 i was wrong; no changes to actual module files at all 15:37:05 03stenella02 07https://github.com/crawl/crawl/pull/871 * 0.23-a0-373-g2de947b: Update crawl-ref/INSTALL.txt 10(44 seconds ago, 1 file, 48+ 7-) 13https://github.com/crawl/crawl/commit/2de947bf75bb 15:47:40 03stenella02 07https://github.com/crawl/crawl/pull/871 * 0.23-a0-374-gbbfd2ea: Update crawl-ref/source/shopping.cc 10(2 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/bbfd2eae1b37 15:58:20 03Stenella02 {GitHub} 07https://github.com/crawl/crawl/pull/871 * 0.23-a0-375-g1732f49: use proper fix 10(6 minutes ago, 1 file, 9+ 8-) 13https://github.com/crawl/crawl/commit/1732f49720c3 16:10:45 Unstable branch on crawl.jorgrun.rocks updated to: 0.23-a0-372-g5ce4c07210 (34) 16:32:39 Unstable branch on crawl.develz.org updated to: 0.23-a0-372-g5ce4c07 (34) 16:33:28 TAS2012 (L27 MuNe) Crash caused by signal #6: Aborted (Depths:5) 16:33:45 heh I guess milestones use name in game, perhaps unsurprisingly 16:34:14 (TAS-2012v: that's not really you but my copy of your save I'm using for testing) 16:34:20 !crashlog 16:34:33 20331. TAS2012, XL27 MuNe, T:499179 (milestone): http://crawl.develz.org/morgues/trunk/TAS2012/crash-TAS2012-20181024-203327.txt 16:42:02 https://github.com/crawl/crawl/blob/master/crawl-ref/source/ability.cc#L3454 am i crazy or is something wrong here 16:43:41 uh 16:45:57 yeah, the static analyzer issue found that one, and I've been meaning to come back to it 16:46:13 I *think* it was intended to be --k 16:46:34 it would make sense given the comparison 16:48:04 that one is currently in my "??" category 16:48:22 the loop does exit, and I wasn't quite sure what the intent was at the time, so I put it off 16:50:03 looking over it again, it looks like other than the VLA the MSVC stuff is done 16:50:11 i'll test it on a windows 10 installation later 16:50:27 and work on the debug/x64 configs in the near future 16:50:27 %git 4693832f9d2 16:50:27 07haranp02 * 0.3-a0-251-g4693832: Cleaned up ability handling. It's still rather hacky, but not nearly as bad as the old horror. 10(11 years ago, 7 files, 1406+ 1487-) 13https://github.com/crawl/crawl/commit/4693832f9d2a 16:50:37 0.3 bugs 16:50:42 lol 16:51:11 03NormalPerson702 07https://github.com/crawl/crawl/pull/869 * 0.23-a0-354-g7540df5: Fix a couple of mistakes 10(2 minutes ago, 2 files, 2+ 2-) 13https://github.com/crawl/crawl/commit/7540df542f01 16:51:22 it's okay, some day soon everything will be ported to the standard from 7 years ago and everything will have up-to-date code 16:51:28 :) 16:52:56 how do you feel about updating libpng? the warnings that are hard-coded into this version are pretty unpleasant on the eyes 16:55:03 https://sourceforge.net/p/libpng/bugs/165/ 16:55:24 those errors are a bit annoying 16:55:42 i'm not smart enough to figure out how to ignore them 16:55:47 life is rough 16:55:52 you just have to blink at the right time :) 16:56:03 well, in MSVC they stay on my screen forever 16:56:13 it's possible to update it but it's not something I'm going to get to soon myself 16:56:34 that link has a solution i think 16:56:37 but i didn't look into it 16:56:37 the sdl2 update we did earlier this year was necessary but turned out to be a big headache with a lot of subsequent tweaks 16:56:55 so if a contrib isn't terribly broken, we don't rush to update it 16:57:00 oh, believe me, i wouldn't mind never looking at dependencies ever again 17:10:41 !source artefact_pad_store_vector 17:10:42 Can't find artefact_pad_store_vector. 17:10:57 !source artefact_fixup_props 17:10:58 Can't find artefact_fixup_props. 17:11:07 !source artefact.cc 17:11:08 https://github.com/crawl/crawl/blob/master/crawl-ref/source/artefact.cc 17:23:27 advil: https://github.com/crawl/crawl/blob/master/crawl-ref/source/artefact.cc#L1831 looks a bit suspicious 17:23:50 yes, I don't understand why it is safe to use max_size instead of size 17:24:06 well, after that function the two are guaranteed to agree 17:24:21 only if the if() was true 17:24:28 right 17:24:43 also, I don't understand why CrawlVector has to behave in this insane way for resizing 17:24:59 in what insane way does it behave? 17:26:02 that's what the comment there is about - basically, increase the max size to VEC_MAX_SIZE, resize, then lower the max size to ART_PROPERTIES 17:26:16 I guess the idea is that it doesn't automatically do any sort of adjustment of max_size on resizing 17:26:53 would be an ok crawlcode post, "// Authentic tribal dance to propitiate the asserts in store.cc:" 17:30:18 now I guess the next question is, if we change this to use `size()` for the size instead of `get_max_size()` will that break save compat 17:31:30 I'm also not sure how this would cause the crash in question, which seems to be happening inside of vector::reserve 17:32:19 (called by set_max_size) 17:38:49 what crashlog is this again? 17:40:39 https://crawl.develz.org/mantis/file_download.php?file_id=7830&type=bug 17:40:55 ignore the recursive crash part, that's just because of where the first crash happened 17:41:17 I can't replicate it locally but the save uploaded for that bug deterministically crashes on CDO 17:52:18 man, searching store.cc for max_size does indeed look pretty insane 17:53:41 it only seems to be used in asserts and in the call to vec.reserve 17:55:37 maybe relevant, I think this is some kind of ultra-late-game megazig character or something, so there's a ton of artifacts around 17:57:01 could it actually run out of memory? seems unlikely, since VEC_MAX_SIZE is only 0xffff 17:58:09 but reserve only ever increases the memory allocation if I understand the spec right 17:59:57 i also wondered if it could run out of memory 18:00:20 and that function gets called 438 times, so that's 28704768 * whatever CrawlStoreValue takes up 18:00:52 438 times? 18:01:22 for that particular save 18:01:24 it's called twice per artifact 18:02:50 well, on my system the memory impact is negligible, but it probably depends a lot on how reserve is implemented 18:03:09 about 5M 18:03:28 but does artefact_pad_store_vector actually result in a call to reserve each of those times? i'd have guessed that most of them already have the right size 18:03:43 no idea 18:03:57 oh wait 18:03:59 I misread 18:04:07 I do have an idea, because that dprf is inside the check 18:04:25 there are two calls to reserve, but the second one shouldn't matter. the first. one is triggered by vec.set_max_size(VEC_MAX_SIZE); 18:04:36 which reserves VEC_MAX_SIZE 18:05:16 what I have no idea of is if that has any real impact on the vectors 18:06:36 i.e. each of those 438 dprfs should correspond to a vec.reserve(VEC_MAX_SIZE (= 65536)) but I have no idea what the default reserve value of a std::vector even is 18:06:58 anyways, gotta go, will have to look more later 18:09:51 also weird, there are only 59 artifacts on the level and 26 carried, which doesn't add up to 438 / 2 18:10:31 maybe some other objects use those props 18:21:06 Unstable branch on underhound.eu updated to: 0.23-a0-372-g5ce4c07210 (34) 18:28:42 hey all, still having issues with the git/0.22 build with the ubuntu18 upgrade unfortunately :( 18:29:31 !tell johnstein advil mentioned you might have had some experience with fixing a webtiles server after a linux upgrade? i'm getting a glibc error even though the versions appear to match up 18:29:32 espais: OK, I'll let johnstein know. 18:30:36 things i've tried include apt-get update/upgrade inside the chroot, re-running debootstrap, updating trunk and the 0.22stable 18:40:18 11111 (L1 HOFi) Crash caused by signal #15: Terminated (D:1) 19:04:03 -!- amalloy is now known as amalloy_ 19:49:48 looks like there's a bug in trunk where bat form doesn't meld your weapon, but actually unequips it 19:53:08 which means if you have a cursed weapon, the weapon is forcibly unwielded while remaining cursed 19:53:21 and if you have distortion you get the unwield effect with no warning 20:15:41 -!- neunon_ is now known as neunon 20:26:24 -!- neunon_ is now known as neunon 21:06:27 https://i.imgur.com/EsaIrM0.png lol 21:06:45 also, looking at code analysis inside MSVC, crawl does some gnarly stack allocations 21:16:26 oh, the project files compiled without issue on windows 10 MSVC2017 21:17:19 i'll actually properly rewrite the install.txt after i get around to fixing debug/x64 21:17:35 since i don't feel comfortable writing with authority without having figured that out 21:18:25 -!- amalloy_ is now known as amalloy 21:18:27 also, i'm pretty sure msvc is free 21:18:45 since i remember someone quoting $500 or whatever when we first talked about it 21:18:59 gammafunk: probably the PR i merged 21:19:09 oh, cool 21:19:13 I haven't even taken a look further 21:19:18 if you wanted to try to fix, feel free 21:19:27 if not I can take a look later 21:19:44 and vp trunk players can enjoy their free weapon remove curse until then 21:19:57 powerful vp of ash tech 21:20:13 nah, i'll just confirm that PR was the culprit and roll it back 21:20:29 sounds good 21:21:20 amalloy: if you want to give credit for that, user who revealed this was Malacanter 21:21:29 roger 21:24:45 03amalloy02 07* 0.23-a0-373-g305c090: Revert "Fix transformation HP scaling with HP+ artefacts (11728)" 10(2 minutes ago, 1 file, 20+ 20-) 13https://github.com/crawl/crawl/commit/305c090e76ea 21:31:00 i agree that visual studio community edition is free and seems like its licensing would be compatible with using it for crawl but i haven't looked deeply into it 21:33:03 -!- amalloy is now known as amalloy_ 21:47:03 was that bug really the result of that commit? 21:47:08 that doesn't seem like it should do that 21:47:53 welcome to crawlcode 21:48:28 it has tat _remvoe_equipment call 21:48:39 oh, i guess the location of _remove_equipment (i.e. it being under you.form = which_trans) might do that 21:48:52 not sure what the logic was about there. ~crawlcode~ 21:49:12 i wonder why it was moved 21:50:10 oh, nevermind, np7 explains the entire thing 22:10:39 Unstable branch on crawl.jorgrun.rocks updated to: 0.23-a0-373-g305c090e76 (34) 22:39:02 i can't re-create the bug that np7 is reporting 22:40:23 but if it exists it would probably be due to item properties 22:40:26 not due to order of operations 22:42:56 since get_real_hp should handle all that shit implicitly 23:29:32 !lm csd wk3 won s=sk begin 23:29:33 No milestones for csd (wk3 won begin). 23:39:54 gammafunk: could you update the csdc pin? 23:40:01 (new post is up) 23:40:01 sure 23:40:04 thanks! 23:40:46 np 23:43:25 ebering: not sure if you're linking to all these posts anywhere, but might be nice to put a link to the previous week's post in the current one 23:44:18 at present no 23:44:24 I guess I can add that 23:44:38 there's not been much discussion outside of discord though 23:45:46 yeah I only realized since I unpinned week 3 23:45:51 then wondered what the comments were like 23:45:53 then I couldn't find it! 23:46:48 search solved that problem though