00:14:16 <|amethyst> hm, that save does freeze for me on explore if I use the player's rc, but it's weird... 00:14:40 <|amethyst> it's doing 00:14:41 <|amethyst> if (prompt_eat_chunks(true) == 1) 00:14:41 <|amethyst> return; 00:15:10 <|amethyst> the return is firing, but if I step through prompt_eat_chunks, it's returning 0 on line 454 00:20:16 didn't know about git config branch.master.rebase true 00:20:17 that's neat 00:20:25 <|amethyst> oh, it's not firing that return, never mind 00:20:36 <|amethyst> move_cmd() is returning CMD_INSPECT_FLOOR 00:24:35 so the pre-commit script is just a sanity check? 00:24:47 if it finds something it doesn't like, it tells me to run unbrace manually? 00:24:59 i.e. it's not supposed to do anything automatically, just prevent me from commiting? 00:25:08 (that's what it appears to have done) 00:32:36 |amethyst: dammit 00:32:48 <|amethyst> I'm not sure what it is about these options that cause the freeze... with the default config it continues exploring up to the runed door and gives the expected message "Partly explored, unopened runed door." 00:33:02 that would almost certainly be due to my fix of the previous autoexplore thing I broke 00:33:11 <|amethyst> easy fix is to change if (result == CMD_NO_CMD) to if (result == CMD_NO_CMD || result == CMD_INSPECT_FLOOR) 00:33:30 <|amethyst> but I don't know why it's happening in the first place 00:33:32 hrm, well inspect floor *should* only be returned 00:33:37 <|amethyst> there are no items under the player 00:33:54 when doing autoexplore and there's an item to pick up 00:33:55 specifically under greedy autoexplore 00:34:18 unless there's a case where somethign other than that is calling that direction_to_cmd() function (or whatever it's called) 00:34:36 I looked at the cases that did, none of them should call it with an direction of x == 0 && y == 0 00:34:46 so I assume that's happening under greedy autoexplore 00:35:43 I can look in more detail later 00:38:18 <|amethyst> hm 00:38:49 <|amethyst> in this case there's a runed door, so you'd usually stop at the door and get that message, which I supposed would be a case of x == 0 && y == 0 ? 00:39:07 yeah 00:39:07 <|amethyst> I found which setting was causing the problem 00:39:11 <|amethyst> travel_key_stop = false 00:39:35 don't interrupt travel is a keypress happens? 00:39:36 <|amethyst> If I load the save with a default config, it doesn't freeze; if I load that setting, it explores up to the runed door then freezes 00:41:02 so I'm probably not checking for the case when a runed door happens 00:41:12 find_travel_pos() 0s out the move 00:42:14 <|amethyst> ohhh, it is freezing with the normal config 00:42:25 <|amethyst> it's just that it stops being frozen when you hit a button 00:42:28 <|amethyst> but it is spinning 00:42:33 hah 00:42:38 well that needs to be fixed 00:42:49 what I need is a way to properly detect from find_travel_pos()'s result 00:42:52 that we hit a runed door 00:43:12 find_travel_pos itself knows this as it ran a fallback travel_path and saw that the dest is on a runed door 00:43:17 then it returns a zero move 00:43:25 but the caller doesn't really know that this has happened 00:43:56 <|amethyst> hm, so wouldn't this also happen for a transporter? 00:44:19 autoexplore doesn't fall back through transporters 00:44:27 er travel_path doesn't 00:44:35 <|amethyst> ah 00:45:00 <|amethyst> I figured the "unexplored transporter" message came about in the same way as the "runed door" message 00:45:18 <|amethyst> but I forgot that it actually paths up to the runed door before giving that message 00:45:21 yeah it instead looks through the travel cache 00:45:34 right, that's actually something I'd like to do with transporters, but there's a sort of issue there so I haven't yet 00:45:44 but yeah the way runed doors work is sort of special 00:46:20 hrm, so what was it doing in the past 00:46:43 I assume it didn't issue a command to inspect the floor when it arrived near the runed door 00:46:57 was travel() able to see that a runed door had been reached? 00:48:24 oh, it saw we hadn't reached the running pos 00:48:34 so then because there was no move, it stopped running 00:49:31 hrm....oh 00:49:31 I see 00:49:34 travel.cc:850 00:49:45 that logic needs to be applied to the case when autoexplore is happening 00:49:55 but I handle autoexplore earlier in the function and return 00:50:10 <|amethyst> ah 00:50:20 not a hard fix, just need to think about how to do it 00:50:28 since for travel I need to specifically check for transporters 00:50:38 part of the problem here is that transporters 00:50:43 should be handled more like how we handle stairs 00:50:55 those get set as a proper running pos 00:51:22 and there's a distance calculation (which has a nice travel penalty so that stairs are not taken simply when they're faster) 00:51:43 but this all uses the travel cache, and I don't want to put transporters into travel cache directly in the stair_info 00:51:59 because they're not stairs and it would cause some weird problems and logical inconsistency 00:52:21 well I can push a simple fix for this for now 00:52:24 <|amethyst> hm, also, I'm not sure that "inspect floor" is really the right thing? 00:52:42 in which case? 00:52:52 for greedy explore you mean? 00:52:58 <|amethyst> yeah 00:53:07 <|amethyst> since greedy explore doesn't necessarily mean you're on an item 00:53:15 <|amethyst> or on an item you want to pick up 00:53:27 well the way the logic works, form what I understand 00:53:37 is that find_travel_pos explicitely figures these things out 00:53:55 its being called with these move args and if it sees an item that needs autopickup under greedy explore 00:54:00 it then zeros the move and returns 00:54:13 then the caller sees this and translates that to inspect the floor command 00:54:27 so as long as find_travel_pos() is making the assessment correct, I think it should be right? 00:54:43 <|amethyst> right, but if stopping for an unpickuppable item were the only time it would return a zero move 00:54:44 returning CMD_INSPECT_FLOOR definitely seemed to be how greedy explore was supposed to work from before my changes 00:55:15 <|amethyst> then you wouldn't need the if (you.running == RMODE_EXPLORE) case 00:55:38 <|amethyst> are we sure that only happens in RMODE_EXPLORE for runed doors? 00:55:41 hrm, but if it had an pickupable itme, it has to returning a non-move as well, right? 00:56:22 <|amethyst> right... I'm saying, if it were a case where normal RMODE_EXPLORE would stop 00:56:35 <|amethyst> then RMODE_EXPLORE_GREEDY is going to return an inspect-floor command 00:56:45 oh ok 00:56:50 <|amethyst> even though a case that would have made RMODE_EXPLORE stop isn't about items 00:57:11 well, if you see the current code 00:57:14 I think this is what happens 00:57:21 first case is non-greedy explore 00:57:27 it returns CMD_NO_CMD 00:57:34 which will translate into stop_running() later on 00:57:37 by the caller 00:57:54 <|amethyst> if Options.explore_greedy is on, you never have regular RMODE_EXPLORE, do you? 00:58:30 ah, so greedy explore is stopping for non-items and getting that as inspect floor? 00:58:45 seems like that would have been a problem before my changes though 00:58:51 but I see what you mean 00:59:13 I guess it's sort of that find_travel_pos only awkwardly communicates its intent 00:59:31 <|amethyst> oh, I see, the old code also did that 00:59:56 <|amethyst> in direction_to_command 00:59:56 yeah 01:00:09 I modified that function to not have that that sort of special case 01:00:23 since I looked at all the callers of it, and only one specific case could have an empty move 01:00:35 which was the travel code we've been looking at for greedy explore 01:00:44 the other two callers should only ever have a non-zero move 01:01:28 this code is super hard to piece together in general, there's a lot of refactoring to be done, but it's hard to know where to begin 01:01:39 since it's pretty complex with a bunch of intertwined pieces 01:07:03 <|amethyst> hm, I do see the problem now with my "fix" 01:07:36 <|amethyst> which is that it makes answering N to "shall I ignore it?" stop running, so you have to press o again 01:07:44 <|amethyst> err, answering Y rather 01:07:48 <|amethyst> answering N should stop running 01:10:45 |amethyst: I think that happened in the past as well, didn't it? 01:11:00 if you hit Y to that prompt, it would stop 01:11:05 maybe it didn't and I just assumed it did 01:12:02 <|amethyst> at least with default settings, it stopped first, then when you pressed o again it prompted, and if you pressed y to that it would keep running 01:15:43 <|amethyst> what about: 01:15:48 <|amethyst> if (you.running == RMODE_EXPLORE_GREEDY) 01:15:48 <|amethyst> return you.pos() == you.running.pos ? CMD_INSPECT_FLOOR : CMD_NO_CMD; 01:16:14 <|amethyst> in _get_non_move_command 01:16:39 |amethyst: yeah that's a pretty simple fix for now 01:16:44 basically what I was thinking of doing 01:17:37 <|amethyst> I guess maybe a const bool fell_short = you.pos() != you.running.pos; so the comparison isn't repeated 01:20:00 if you'd like to commit that, please feel free 01:20:04 otherwise I'll do it in a bit 01:20:05 <|amethyst> sure 01:26:42 <|amethyst> hm 01:27:25 <|amethyst> this is still acting funny 01:27:42 <|amethyst> rather, now it's acting funny for the item case 01:27:59 <|amethyst> oh, doh 01:28:16 <|amethyst> I had the condition backwards :) 01:28:26 oh yeah, haha 01:39:09 03|amethyst02 07* 0.21-a0-172-gbca40f3: Don't infinite-loop when exploring hits a runed door (#11174). 10(5 minutes ago, 1 file, 8+ 2-) 13https://github.com/crawl/crawl/commit/bca40f30b4bb 01:39:09 03|amethyst02 07* 0.21-a0-173-g99db44b: Ignore the Mac terminal profile in checkwhite. 10(45 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/99db44becc94 01:45:09 at this rate we'll hit 200 commits by the end of the week! 01:47:23 <|amethyst> ugh, editing versions in Mantis admin is annoying 01:50:05 good tv 01:50:48 <|amethyst> oh, hey, the timestamp is interpreted as being in the server's timezone 01:51:27 <|amethyst> meaning if I go and edit a version that had a timestamp in CET (without changing the timestamp), the timestamp is now in CEST without the numbers changing 01:51:40 <|amethyst> so the version timestamp shifted by an hour 01:53:08 <|amethyst> but I did get 0.20 stable added in Mantis (and trunk changed to 0.21 and longterm development to 0.22) 01:53:15 oh, nice 01:53:38 <|amethyst> bugs filed in the last few months are likely to be wrong 01:54:25 <|amethyst> since people didn't have an option for 0.21, a lot chose "longterm development" instead of "0.20 development branch" 01:56:27 Windows builds of master branch on crawl.develz.org updated to: 0.21-a0-173-g99db44b 01:57:24 <|amethyst> unironically nice timing, Gretell 02:10:11 Unstable branch on crawl.jorgrun.rocks updated to: 0.21-a0-173-g99db44b (34) 02:52:47 Monster database of master branch on crawl.develz.org updated to: 0.21-a0-173-g99db44b 02:57:39 !source god_hates_spell 02:57:39 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/religion.cc#L3913 02:58:17 what exactly is fake_spell? it's only used by: 02:58:24 !source your_spells 02:58:25 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/spl-cast.cc#L1295 02:58:40 and is passed as !allow_fail 02:58:42 * @param allow_fail Whether spell-fail chance applies. 02:59:02 and is only used for the Trog HATE SPELLCASTING check 02:59:38 and for fun, it's returning !fake_spell, negating the passed negated allow_fail 02:59:49 at which point my brain slightly imploded 03:00:16 <|amethyst> fake_spell means it's not really a spell 03:00:37 <|amethyst> among other things, some wands go through your_spells 03:00:55 <|amethyst> also Beogh smiting 03:01:51 the double negative is still hurty 03:02:19 <|amethyst> yeah, arguably your_spells should take a fake_spell parameter instead of allow_fail 03:02:43 trying to add a docstring for fake_spell in god_hates_spell. trying to explain how it's being used here 03:03:30 <|amethyst> there's a similar parameter on _spellcasting_side_effects 03:03:38 <|amethyst> could copy the docstring from there 03:04:36 <|amethyst> also _spellcasting_aborted (identical @param docstring) 03:08:34 good (obvious in hindsight) suggestion 03:09:31 so basically Trog is cool with Fake_Spells, like evokables and innate divine abilities. makes sense 03:09:39 <|amethyst> yeah 03:11:35 Unstable branch on crawl.beRotato.org updated to: 0.21-a0-173-g99db44b (34) 03:20:33 -!- amalloy is now known as amalloy_ 03:23:19 03johnstein02 07https://github.com/crawl/crawl/pull/586 * 0.21-a0-171-gd725cb7: Modify warnings for memorizing hated spells 10(22 hours ago, 2 files, 10+ 5-) 13https://github.com/crawl/crawl/commit/d725cb708364 03:23:19 03johnstein02 07https://github.com/crawl/crawl/pull/586 * 0.21-a0-172-gb737cd4: Use a color enum instead of the actual color 10(3 hours ago, 1 file, 3+ 1-) 13https://github.com/crawl/crawl/commit/b737cd4d1eae 03:23:19 03johnstein02 07https://github.com/crawl/crawl/pull/586 * 0.21-a0-173-g71e67d2: Adjust some spell memorisation warning messages 10(42 minutes ago, 1 file, 5+ 2-) 13https://github.com/crawl/crawl/commit/71e67d2b3ee1 03:23:19 03johnstein02 07https://github.com/crawl/crawl/pull/586 * 0.21-a0-174-g9163cb8: Add some docstrings 10(11 minutes ago, 1 file, 22+ 0-) 13https://github.com/crawl/crawl/commit/9163cb844ab1 03:25:03 oh, looks like force pushing kills the old conversation in the PR? 03:25:16 alexjurkiewicz: for your serial_rivers, did you just want no_pool_fixup on all of these? 03:25:18 oh nm. outdated 03:27:12 doh, typo in there. I'll have to push -f again 03:27:15 ??doh 03:27:15 |amethyst[1/24]: <|amethyst> doh 03:31:20 ok, that should do it 03:31:57 still not sure if I have the right granularity for the commits. I started squashing, but figured I'd just leave it as it is. easy to squash quick if that's the best thing here 03:33:44 03johnstein02 07https://github.com/crawl/crawl/pull/586 * 0.21-a0-174-g6f45cf9: Add some docstrings 10(21 minutes ago, 1 file, 22+ 0-) 13https://github.com/crawl/crawl/commit/6f45cf989965 03:35:26 hm. I forgot to rebase my branch before force pushing. does that matter? I'm assuming since PRs don't get pulled in right away, nearly all of them are always somewhat out of date 03:35:45 (I'm 3 commits behind master now) 03:46:11 johnstein: PRs are just based on whatever's in the branch at any given time 03:46:29 but generally you don't need to keep force-pushing with rebases to keep them current 03:46:42 unless there's some big conflict you want to resolve 03:47:40 ok. ty. that was a neat one. kinda surprised we didn't already have that functionality too. something I really assumed was already there and that perhaps the bug report was missing something 03:48:22 I may take a stab at warning when targetting hated/loathed spells since there's a note in the code about it and it seems like a natural extension, but I'm not sure if that's going to be "simple" and "newbie friendly" 04:24:28 interesting little bug 04:24:37 I had a map without a name field 04:24:50 it was a decor vault that was getting placed as part of a serial 04:25:15 with the parent serial vault using dgn.place_maps() (lua function) 04:25:24 the vault placed even though it didn't have a vault name 04:25:34 with no placement errors (and of course no startup des errors) 04:25:50 but there was a strange behaviour where the NSUBST statement it had wasn't getting applied 04:25:56 only the SUBST statement it had did 04:26:08 was very puzzling for a while until I saw the name was missing 04:26:24 and figured "hey maybe vaults behave very oddly if you don't name them" 04:26:35 sure enough after adding the name both statements worked in the vault properly 04:26:51 is that the only map with no name? 04:28:24 !bug 11059 04:28:24 https://crawl.develz.org/mantis/view.php?id=11059 04:28:38 seems like an interesting one. sucks that someone lost a char due to it 04:31:28 well the map has a name, but I didn't include that line when adding it to the des 05:33:07 gammafunk: i think the serial river vaults that need no_pool_fixup have it 05:33:28 I'm leaving some comments in the PR 05:33:40 👍 05:33:41 but you do have some issues with stranding the player in deep water 05:36:27 👎 05:36:53 hrm 05:37:14 well 05:37:23 pool fixup might be preventing these from ever happening 05:37:36 alexjurkiewicz: your marsh vault (deep water + trees) mostly gets turned into shallow water 05:37:44 for the deep water, that is 05:37:57 and interestingly 05:38:03 if I set the serial's chance to 100% 05:38:19 it sometimes crashes, unable to generate a level when I weight that vault to 10000 05:38:40 yeah you can just change the w to W, I am pretty sure that was deliberate 05:38:41 must be some traversal error?? 05:38:48 not an actual issue I guess, but probably that particular vault's odd shape make a lot of vetoes 05:38:57 well I'm guessing it just gets vetoed so much 05:39:04 that it goes through all 1k level attempts 05:39:11 and then gives up 05:39:22 maybe it is some other kind of bug, but shouldn't be a problem in practice 05:39:31 the error suggests it was trying to veto levels 05:43:40 alexjurkiewicz: well, in any case I left a review requesting changes 05:43:57 most of the fixes should be simple 05:44:55 thanks mate, i'll check that pr and the str one out some time this week 06:25:31 "ta" order can target allies. It does nothing 13https://crawl.develz.org/mantis/view.php?id=11175 by Lavandula 13:04:05 Unstable branch on crawl.akrasiac.org updated to: 0.21-a0-173-g99db44b (34) 13:56:23 -!- amalloy_ is now known as amalloy 17:32:49 hm, is "Ashley Raine" a name I should recognize in this context? 17:33:11 just trying to put some context to a relatively brusque (negative) github comment 17:37:06 -!- Webmant9 is now known as Webmant 17:42:42 <|amethyst> advil: hm, I don't know, but there is an issue with the proposal 17:43:09 <|amethyst> advil: namely, what do you do about skill cost levels? 17:43:27 they are factored in as far as I know 17:43:48 <|amethyst> advil: including the fact that they will increase as you gain that 1.0 XL? 17:43:51 that is, it simulates skill cost level increases when calculating the xp 17:43:52 yeah 17:43:57 <|amethyst> aha, nice 17:44:14 the moment when I realized that I would have to do that was a bit annoying :-) 17:44:52 yeah, I would like some feedback on that PR in general probably 17:46:18 <|amethyst> I'd advise not to wait too much for feedback. You are one of the more active devs these days :) 17:46:24 heh 17:46:34 well, I'm not going to merge it too soon 17:46:44 <|amethyst> worst that happens is MarvinPA reverts it :) 17:47:17 I am interested in the question of whether that information is confusing or useful (or both), but that commenter didn't really give much meat in their commentary so without knowing where they're coming from it's hard to draw any conclusions 17:47:43 <|amethyst> advil: would be nice to show similar information in the m screen 17:47:47 yeah 17:47:50 that's where this is leading 17:47:51 I' 17:47:56 m going to implement skill targets 17:48:07 <|amethyst> ♥ 17:48:26 :-) 17:48:31 <|amethyst> ☺ 17:48:34 m is not the least confusing screen already though 17:49:19 <|amethyst> I was thinking just one number, the relative cost (scaled by changing skill cost) of gaining one XL 17:49:26 <|amethyst> at least when in cost mode 17:50:14 <|amethyst> since with your commit you can kind of figure that out, but only by inspecting a weapon 17:50:38 ah interesting 17:51:34 <|amethyst> would be nice if it were more continuous, because then you could do calculus instead of simulating :) 17:53:13 <|amethyst> hm, I would suggest in that message something like "At max training at your current level you would..." 17:53:39 huh, I never noticed that the m menu has a progress mode, but only in wizmode 17:54:30 <|amethyst> since skill cost level is not documented anywhere, the player might not expect that to change, and might incorrectly infer that XL XP requirements are greater than they actually are 17:54:45 ah I see 17:54:57 <|amethyst> I guess my "fix" doesn't actually address that 17:55:02 yeah, I think that if this commit does make it in players will realize how confusing some of the underlying mechanics are 17:55:16 <|amethyst> hm 17:55:18 <|amethyst> you know 17:55:34 I was talking to someone recently who knew about skill cost but didn't realize it was global, for example 17:55:55 (general q: what does skill cost really accomplish?) 17:56:26 <|amethyst> probably one could remove skill cost level and replace it with 1. a reduction in monster XL as you gain experience, a la Angband and 2. a new formula/table for XL by XP 17:57:49 <|amethyst> err, s/monster XL/monster XP rewards/ 17:58:00 <|amethyst> the intent is probably to have an equivalent of (1.) 17:58:26 <|amethyst> i.e. just because killing a few goblins can take you up to 1.0 conjurations at the start of the game, doesn't mean it should be able to later on 17:58:27 advil: if you kill an ogre at XL3, you gain several skill levels in whatever new skill you're training 17:58:35 would that actually make much difference in terms of how clear it is for the player? since xp isn't visible as a number 17:58:39 and probably shouldn't be 17:58:39 but you shouldn't gain several skill levels for killing an ogre at XL20 17:58:52 -!- MarvinPA_ is now known as MarvinPA 17:59:11 <|amethyst> MarvinPA_: not for the player, but it would make things like amalloy is talking about easier 17:59:36 <|amethyst> MarvinPA: specifically, applying the skill cost divisor to level XP and not just skill XP would make it easier for us to compare 17:59:39 advil: I never commented, but as a player I really like your approach for the skill stuff 17:59:40 fair enough, yeah 17:59:48 esp if it helps us get to skill targets 17:59:48 <|amethyst> err 17:59:52 <|amethyst> s/amalloy/advil/ 17:59:55 even if it's a bit fuzzy 17:59:57 <|amethyst> too many as! 17:59:59 i'd definitely be concerned about adding anything new to 'm' 18:00:01 -!- |amethyst is now known as |bmethyst 18:00:09 -!- |bmethyst is now known as |amethyst 18:00:18 /nick _amalloy 18:00:35 <|amethyst> MarvinPA: we could figure out how to remove auto mode to balance it out :) 18:00:41 although skill targets seem like a reasonable thing to add (although i think the way it can be done in lua currently is also fine) 18:00:55 one option for skill targets is to keep a minimalist gammafunk-style ui for it, but I think it'd be easier to use integrated into m 18:01:18 advil: to be clear, elliptic wrote that code, I just cleaned it up a bit 18:01:25 ah ok 18:01:31 and packaged it and profited from it 18:01:57 it is kind of awkward working off one skill 18:02:06 you'll set a target but then another unrelated skill will hit it 18:02:14 which I suppose means you set a bad target, but it's still weird 18:02:51 but maybe per-skill target vs not has nothing to do with the UI issue you are talking about 18:03:06 Unstable branch on underhound.eu updated to: 0.21-a0-173-g99db44b (34) 18:03:13 advil: fwiw i think "max training" is weirdly worded when contrasted with "current training (50%)". i'd just say "with 100% training" or something for consistency 18:03:18 yeah, I think the general issue is just that m has a ton of stuf 18:03:19 f 18:03:39 amalloy: yeah, good suggestion, I'm going to switch that to 100% for sure 18:05:27 |amethyst: is std::tie the way to destructure pairs in our current version of c++? 18:05:38 I think we don't have that yet :-( 18:06:30 i think it is in C++11 18:06:38 oh maybe I'm wrong 18:06:44 well if we have that, I'll use it 18:06:48 according to http://en.cppreference.com/w/cpp/utility/tuple/tie anyway 18:07:01 (assuming I don't find a better way for that function to work in the first place) 18:09:12 <|amethyst> yeah, std::tie works but honestly I don't know how much better it is than doing auto tuple = ...; then creating references to the tuple's members 18:09:38 |amethyst: i just want something that lets him give the members a name, instead of using them as .first and .second 18:09:41 <|amethyst> it will be nice when we can move to C++17, probably only 4 or 5 years from now :P 18:09:55 whether that's tie or just copying the values out into a local 18:12:31 <|amethyst> tie would be something like 18:12:35 <|amethyst> int a; 18:12:36 <|amethyst> string b; 18:12:36 <|amethyst> coord_def c; 18:12:36 <|amethyst> tie(a, b, c) = somefunc(); 18:13:42 <|amethyst> my suggestion is something like 18:13:43 <|amethyst> auto t = somefunc(); 18:13:43 <|amethyst> int a = get<0>(t); 18:13:43 <|amethyst> string b = get<1>(t); 18:13:43 <|amethyst> coord_def c = get<2>(t); 18:13:47 <|amethyst> err 18:13:53 <|amethyst> int &a, string &b, coord_def &c 18:14:21 <|amethyst> though for the int and coord_def at least copying is likely cheaper than aliasing 18:15:26 <|amethyst> with the return value optimisation, it seems like the tie() version would be more expensive, since you would have to at least move all the members 18:15:39 <|amethyst> expensive for things that are expensive to copy, that is 18:15:46 <|amethyst> s/copy/copy and move/ 18:16:08 <|amethyst> I guess none of those three types is actually all that expensive to move, though 18:16:14 right now it's using a pair, so it's like your suggestion except that when I call that function I only ever use the return values once, so I didn't bother to create locals 18:16:32 advil: my point is that giving them locals is better even if you only use them once 18:16:39 because that gives them a name for the human reading the code 18:17:05 so i don't have to go look up the definition of skill_level_to_diffs to get a vague idea of what .first and .second are 18:17:08 possibly I should just create a typedef or something 18:17:20 <|amethyst> or you could make a custom struct instead of using pair/tuple 18:17:23 yeah 18:23:36 Mysterious messages in Shoals 13https://crawl.develz.org/mantis/view.php?id=11176 by damerell 18:27:21 <|amethyst> that looks like one of the already-reported (probably recall-related?) orc follower unlinked bug 18:27:34 <|amethyst> 8187 18:27:43 <|amethyst> !bug 8187 18:27:43 https://crawl.develz.org/mantis/view.php?id=8187 18:28:09 <|amethyst> (got to go for a bit, someone else can mark that as a dup or something) 19:45:29 -!- amalloy is now known as amalloy_ 20:09:16 @??goblin 20:09:16 goblin (15g) | Spd: 10 | HD: 1 | HP: 3-5 | AC/EV: 0/12 | Dam: 4 | 10weapons, 10items, 10doors | XP: 1 | Sz: small | Int: human. 20:09:21 !source mons_power 20:09:21 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/mon-util.cc#L3355 20:15:22 @??chuck 20:15:22 Chuck (00C) | Spd: 10 | HD: 18 | HP: 96-138 | AC/EV: 14/2 | Dam: 45 | 10items, 10doors | Res: 06magic(100), 12drown | XP: 2149 | Sz: Giant | Int: human. 20:48:43 !source launch 20:48:44 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/artefact.h#L69 22:02:02 New branch created: pull/587 (3 commits) 13https://github.com/crawl/crawl/pull/587 22:02:02 03alexjurkiewicz02 07https://github.com/crawl/crawl/pull/587 * 0.21-a0-154-gbfa5d53: Remove returning missile brand. 10(6 minutes ago, 15 files, 53+ 142-) 13https://github.com/crawl/crawl/commit/bfa5d53d1225 22:02:02 03alexjurkiewicz02 07https://github.com/crawl/crawl/pull/587 * 0.21-a0-155-gf523027: Remove silver missile brand 10(6 minutes ago, 11 files, 31+ 5-) 13https://github.com/crawl/crawl/commit/f52302710657 22:02:02 03alexjurkiewicz02 07https://github.com/crawl/crawl/pull/587 * 0.21-a0-156-gdd2165b: Remove poison & steel tomahawks 10(6 minutes ago, 1 file, 1+ 3-) 13https://github.com/crawl/crawl/commit/dd2165b02de9 22:27:04 is there somewhere i can put my status icons for corroded and sprint? 22:27:39 the ones that got committed were just the draft versions 22:27:53 (i dont have github) 22:31:25 <|amethyst> Ultraviolent4: file a bug on mantis and upload there 22:31:25 |amethyst: You have 2 messages. Use !messages to read them. 22:31:37 -!- GiantOwl is now known as Kalir 22:31:41 good idea thanks 22:34:13 amalloy_: Would these have been your moves as a chei worshiper? https://youtu.be/ngBia2rQn1s 22:34:30 !tell amalloy Would these have been your moves as a chei worshiper? https://youtu.be/ngBia2rQn1s 22:34:30 gammafunk: OK, I'll let amalloy know. 22:34:43 <|amethyst> R-I suggests volcano salamanders need to have their weapon set nerfed, since they are a fair amount out of depth there, and are likely to be hasted because of the mystics 22:35:25 Oh no, |amethyst is in contact with the Ancient Ones of Power, we're all doomed! 22:36:04 I can take a look at their weapons, although I'm not sure they're much worse than the red dracs we can have there now 22:36:08 @?salamander 22:36:08 salamander (04N) | Spd: 10 (swim: 70%) | HD: 8 | HP: 53-76 | AC/EV: 5/7 | Dam: 1704(fire:8-15) | 10weapons, 10items, 10doors, fighter | Res: 06magic(40), 04fire+++ | Vul: 12cold | XP: 524 | Sz: Medium | Int: human. 22:36:47 @?red draconian 22:36:47 red draconian (04d) | Spd: 10 | HD: 14 | HP: 74-111 | AC/EV: 9/10 | Dam: 20 | 10weapons, 10items, 10doors, cold-blooded | Res: 06magic(40), 05fire | XP: 1228 | Sp: searing breath (3d18) [11!AM, 06!sil, 08breath] | Sz: Medium | Int: human. 22:37:10 @?salamander mystic 22:37:10 salamander mystic (08N) | Spd: 10 (swim: 70%) | HD: 10 | HP: 52-76 | AC/EV: 7/7 | Dam: 1004(fire:10-19) | 10weapons, 10items, 10doors, spellcaster | Res: 06magic(60), 04fire+++ | Vul: 12cold | XP: 768 | Sp: mystic blast (3d15), b.magma (3d18), haste other | Sz: Medium | Int: human. 22:37:51 I'm not really sure changing their weapon set would do a lot, but I'd need to see what their equipment is 22:38:30 they're not going to do as much damage as s two-headed ogre unless you lack rF maybe 22:38:30 <|amethyst> salamander weapons are halberd 5, trident 5, spear 3, glaive 2, shortbow 5 22:38:55 <|amethyst> red drac weapons are same as nagas 22:38:58 !lg * current volcano s=cikiller% 22:38:59 715 games for * (current volcano): 120x a salamander (16.78%), 72x (10.07%), 51x a two-headed ogre (7.13%), 48x a stone giant (6.71%), 44x a molten gargoyle (6.15%), 39x a draconian (5.45%), 24x a hell knight (3.36%), 21x a sun demon (2.94%), 21x a fire bat (2.94%), 18x a gargoyle (2.52%), 18x a wizard (2.52%), 16x an earth elemental (2.24%), 16x a fire dragon (2.24%), 16x an efreet (2.24%), 14x a... 22:39:11 can someone please add a mailmap entry for me? I had some wrong email addresses for a few old commits 22:39:37 you can see it with `g shortlog -e | grep Jurkiewicz` 22:39:43 just map it to my usual email please 22:40:32 I think salamancers getting those kills is very much largely due to just their being salamanders, possibly their being hasted 22:41:12 !lg * current volcano cikiller=salamander s=kmap 22:41:13 120 games for * (current volcano cikiller=salamander): 34x volcano_village, 22x kennysheep_volcano_temple, 19x volcano_pools, 15x pf_volcano_lost_world, 10x volcano_lake; vl_original, 7x volcano_grotto; vgs_many_chambers, 4x volcano_caves, 3x volcano_grotto; vgs_dualism, 3x volcano_grotto; vgs_trial_by_fire, 2x volcano_grotto; vgs_hot_hot_hot, volcano_grotto; vgs_statue_spotlight 22:41:25 <|amethyst> alexjurkiewicz: it doesn't map to emails, just to names, but sure 22:41:58 03|amethyst02 07* 0.21-a0-174-g0273943: Add an old email address for alexjurkiewicz. 10(19 seconds ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/0273943fec29 22:42:29 <|amethyst> alexjurkiewicz: oh, I guess there is a way to update email addresses, doh 22:42:37 <|amethyst> should have double-checked the docs before pushing :) 22:44:02 it wasn't until I saw the crawl project I realised mailmap could do *more* than rewrite email addresses :) 22:44:45 !lg * kmap~~chequers -tv 22:44:46 2. DunwichHorror, XL27 GrMo, T:83958 requested for FooTV: telnet://termcast.develz.org or http://termcast.develz.org. 22:44:52 new kill! 22:46:00 03|amethyst02 07* 0.21-a0-175-g25c56e7: Improve that mailmap entry by rewriting the email address as well. 10(13 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/25c56e7de92c 22:46:43 I guess the mask of the dragon vault is pretty deadly now. lots of mana draining behind several rows of berserk dragon 22:46:51 thanks |amethyst 22:47:14 !lg * map~~chequers 22:47:15 1913. Neil the Fencer (L11 MiBe of Trog), blasted by an electric eel (bolt of electricity) on D:10 (chequers_big_river) on 2017-08-08 02:22:26, with 8793 points after 7449 turns and 0:17:47. 22:47:21 this is how I thank you :( 22:47:24 !lg * kmap~~mask 22:47:26 2. DunwichHorror the Slayer (L27 GrMo of Wu Jian), slain by a golden dragon on Zot:2 (chequers_guarded_unrand_mask_of_the_dragon) on 2017-08-07 06:24:00, with 646638 points after 83958 turns and 5:14:06. 22:47:30 oh got a new kill 22:47:34 !lg * kmap~~mask -tv:<2 22:47:35 2. DunwichHorror, XL27 GrMo, T:83958 requested for FooTV: telnet://termcast.develz.org or http://termcast.develz.org. 22:49:25 hah 22:49:39 so many things they could have done 22:50:24 the vault needs more zot traps though 22:50:27 critical oversight 22:51:21 Updated icon for monster swiftness status 13https://crawl.develz.org/mantis/view.php?id=11178 by Ultraviolent4 22:51:21 Updated icon for monster corroded status 13https://crawl.develz.org/mantis/view.php?id=11177 by Ultraviolent4 22:54:54 hm but i dont like how monsters trigger zot traps against you 22:55:06 I'm not really serious :) 22:55:41 that vault is dangerous enough without those, although exposed traps would certainly dial it up another notch 22:55:54 03|amethyst02 07* 0.21-a0-176-gb3d4b37: Update monster swift and corroded icons (Ultraviolent4, #11177, #11178) 10(62 seconds ago, 2 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/b3d4b37311a7 22:56:14 zot traps triggering against the player is cool 22:56:58 perhaps a better design for zot traps exists, but it it's distinct and tactically meaningful 22:57:19 nice icons 23:09:27 Unstable branch on crawl.jorgrun.rocks updated to: 0.21-a0-176-gb3d4b37 (34) 23:12:44 much better 23:12:53 good job uv4 23:59:20 Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-176-gb3d4b37 (34)