00:02:22 <mumra> moving is the worst thing, i hate it
00:13:45 -!- kramin is now known as FBI
00:14:14 -!- FBI is now known as Guest31869
00:14:20 -!- Guest31869 is now known as Kramin
00:28:39 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-437-ge5bf024 (34)
00:32:18 <geekosaur> (does that make him a kraminal?)
00:56:18 <ProzacElf> yes
00:56:26 <ProzacElf> haha, you won't hear me argue mumra
00:56:35 <ProzacElf> and i've had to move entirely too many times in my life
01:15:05 -!- Bammboobies is now known as Bammboo
01:15:10 -!- illusion is now known as Guest86007
01:22:54 -!- infrashortfoo__ is now known as infrashortfoo_
01:22:54 -!- tcsc_ is now known as tcsc
01:25:07 <mumra> yeah, same :)
01:31:54 <ProzacElf> heh
01:32:05 <ProzacElf> freenode seems to be having issues today
01:55:14 -!- blued is now known as bluedave
02:30:48 <mumra> ooh, dual quickblades
02:38:49 <ProzacElf> heh
02:39:05 <ProzacElf> i've never found those on a dude i wanted to use them on
02:39:32 <ProzacElf> it's always like "ah yes, what a fantastic alternative to wyrmbane.  i shall treasure them."
02:39:46 <mumra> these would've been really good
02:39:52 <mumra> but that char died already
02:47:01 <ProzacElf> heh
02:47:07 <ProzacElf> i think i'm getting worse at this game
03:03:48 -!- amalloy is now known as amalloy_
03:05:11 -!- amalloy_ is now known as amalloy
03:21:58 <Rotatell> Unstable branch on crawl.beRotato.org updated to: 0.21-a0-437-ge5bf024 (34)
03:48:44 <mumra> ok, i found a scarf. is this a unique slot?
04:03:43 <ProzacElf> goes in your cloak slot
04:03:50 <ProzacElf> which you've probably figured out by this point
04:03:59 <ProzacElf> they get some neat egos but no AC
04:04:18 <ProzacElf> well, maybe randart ones can give AC, but i don't even think they can
04:04:22 <mumra> oh right of course, i didn't find a cloak yet
04:19:54 -!- amalloy is now known as amalloy_
04:20:29 -!- amalloy_ is now known as amalloy
05:06:41 -!- amalloy is now known as amalloy_
07:13:45 <SteelNeuron> !tell gammafunk I've been thinking that the EV boost on wall jump may not even be necessary. Just wall jumping at normal walk speed + front loading should be still niche useful
07:13:46 <Sequell> SteelNeuron: OK, I'll let gammafunk know.
07:14:31 <SteelNeuron> !tell gammafunk this would go with a big decrease on Serpent's Lash cost (and making it first to unlock probably) so you can make all three moves get that extra boost more frequently
07:14:31 <Sequell> SteelNeuron: OK, I'll let gammafunk know.
10:55:43 <G-Flex> front loading?
10:56:04 <G-Flex> <ProzacElf> well, maybe randart ones can give AC, but i don't even think they can
10:56:13 <G-Flex> last time I got one, randart scarves don't even have scarf egos
10:56:19 <G-Flex> so they're just randart cloaks with 0 AC
11:00:42 <advil> hm that seems wrong, I wonder if that's intentional or not
11:17:42 <gammafunk> we probably should do something about artefact scarves
11:18:24 <gammafunk> We could turn their egos into artp and let those only spawn on scarves, for instance
11:18:53 <gammafunk> or maybe something like how we do with jewellery, I'm not sure how base type shows up for those
11:19:18 <gammafunk> but either way we'd have to make the scarf egos into artp, since I'm certainly jewellery types are all artp
11:21:07 <Yermak> Shouldn't player::body_size() function be in player.cc and not in player-act()?
11:21:19 <Yermak> player-act.cc*
11:29:36 <Yermak> Another question. A comment from _player_evasion_size_factor(): // XXX: you.body_size() implementations are incomplete, fix.
11:29:41 <Yermak> What does it mean?
11:37:43 <advil> lots of player stuff is spread around, because there is so much of it
11:39:21 <advil> advil$ git grep -l player:: *.cc | sort | uniq | wc -l
11:39:21 <advil> 16
11:40:17 <advil> as to what is incomplete there, hard to say...I would first check the age of that comment (because sometimes comments like that are like 8 years old from a time where devs were way more simulationist than we are now)
11:40:40 <advil> the commit message that it comes from could say more, too
11:41:34 <advil> does anyone know if there is a case where DNGN_UNSEEN is intentionally used for a tile that has been seen, ignoring map rot?
11:42:59 <Yermak> What is the best way to check the age of a line?
11:43:10 <advil> git blame
11:43:19 <advil> I usually go through the github web interface
11:44:48 <advil> though blame in player.cc takes forever to load
11:47:35 <advil> yeah, that comment is really ancient
11:47:37 <advil> https://github.com/crawl/crawl/commit/f92c98f617ffc96468e0fa7aaee043ac730ba697#diff-08b947783e77bea1187e7e4737c3b463R1749
11:48:16 <advil> could even be literally from crawl 4.1
11:50:53 <Yermak> Yes, player::body_size() was last modified siz months later.
11:51:00 <Yermak> six*
11:51:04 <advil> heh
11:52:20 <Cheibriados> 03amalloy02 07* 0.21-a0-438-g4af208b: Make ?mapping work even after forgetting level map (Beargit, EMTedronai) 10(28 seconds ago, 1 file, 9+ 3-) 13https://github.com/crawl/crawl/commit/4af208bdd212
11:52:36 <advil> oh man
11:52:38 <advil> you scooped me
11:52:42 <advil> amalloy_
11:55:31 <advil> amalloy_: I was going to add a fixup for old saves, do you have anything else in the works for that?
11:55:51 -!- amalloy_ is now known as amalloy
11:56:20 <amalloy> advil: no, feel free
11:56:51 <advil> do you happen to know the answer to "does anyone know if there is a case where DNGN_UNSEEN is intentionally used for a tile that has been seen, ignoring map rot?"
11:56:58 <amalloy> i think you can fix it so that future ?mapping works, but you can't retroactively reveal the map if they failed to use ?mapping in the past, right?
11:57:22 <advil> I was unmapping all squares with feat DNGN_UNSEEN
11:57:40 <amalloy> right, which i think is what i said
11:57:42 <advil> which seems to work, but I wonder if there's some weird use of that feature that I haven't thought of
11:57:53 <amalloy> i don't know the answer to that
11:58:00 <amalloy> but i agree it seems weird
11:59:15 <advil> yeah, I don't think there's a way to retroactively map, and I was going to add it to forget (not do it on load or anything)
12:01:08 <amalloy> add it to forget, or to map? if you add it to forget, doesn't that mean someone with a broken save will still have broken scrolls unless they try to forget the map again? why would they think to do that?
12:01:37 <advil> they would have to be told
12:01:47 <advil> I guess adding it to map is possible
12:02:12 <advil> but it is a lot simpler to add it to forget
12:02:22 <amalloy> well yes, but it's almost useless there
12:03:19 <amalloy> i'm a little surprised it doesn't actually already happen in map, since there's stuff there about updating features that are remembered as being different from what they are now, i think
12:03:35 <advil> if (!wizard_map && (env.map_knowledge(*ri).seen() || env.map_knowledge(*ri).mapped()))
12:03:35 <advil> continue;
12:03:37 <advil> is the culprit
12:04:04 <amalloy> i guess it depends on changed()
12:04:10 <amalloy> if (env.map_knowledge(*ri).changed())
12:04:30 <amalloy> too bad
12:04:56 <amalloy> anyway, i gotta go. have fun
12:14:27 -!- amalloy is now known as amalloy_
12:20:07 <Cheibriados> 03advil02 07* 0.21-a0-439-gabf74bb: Let mmapping work on saves where forgetting marked everything mapped 10(2 minutes ago, 1 file, 8+ 1-) 13https://github.com/crawl/crawl/commit/abf74bbfa6ad
12:21:18 <advil> I suppose I could have done a minor version tag blah blah blah but this seemed too minor for that
12:23:00 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.21-a0-438-g4af208b (34)
12:23:22 <advil> I suspect that fix won't work right for antennae and the like
12:42:02 <Yermak> Added size scale: https://pastebin.com/x3YdjdCc
12:42:30 <Yermak> I moved all single-pip resistances to the right column.
12:43:48 <Yermak> Probably it would be good to add the word for size, too (small, large, etc.). But I can't come with the spot to place it.
12:46:52 <Yermak> Should it got into "A: small, mutation resistance 1"?
12:55:14 -!- amalloy_ is now known as amalloy
12:59:46 <amalloy> Yermak: i haven't been following the discussion on this size stuff, but i'm surprised you made it into a metered thing like MR, rather than just putting it in A:
13:00:15 <Yermak> it's hard to tell which is bigger: small or little
13:00:41 <Yermak> With scale it can be seen outright.
13:01:34 <amalloy> i agree with your first statement but i'm not so sure about the second. i can see that ..*.... is not the smallest size, but i can't tell which specific sizes are smaller
13:02:08 <Yermak> All size adjectives are listed in manual.
13:04:35 <Yermak> We have SIZE_LARGE and SIZE_BIG but we use adjectives 'large' and 'very large'. Maybe we could use 'small' and 'very small' too?
13:05:25 <amalloy> i'm just one man, but i'd be in favour of that. i frankly have only a mild guess as to which of "small" and "little" is smaller
13:06:23 <Yermak> So 'small' and 'very small', don't add scale to %, and add size adjective to 'A'?
13:07:02 <amalloy> ??little
13:07:02 <Sequell> size factor[1/2]: For evasion purposes: spider form and bat form are tiny (factor 6), spriggans and felids are little (factor 4), halflings and kobolds are small (factor 2), trolls ogres centaurs and nagas are large (factor -2), hydraform is big (-4), and dragonform is huge (factor -8).
13:07:07 <amalloy> ??little[$
13:07:07 <Sequell> size factor[2/2]: Monster sizes from %?? (for constriction and trampling) in order and with examples: tiny (rats); little (felids); small (kobolds); medium (humans), large (trolls); big (death yaks); giant (dragons)
13:07:23 <Yermak> Also, side question: why tree-form is medium-size? This seems weird to Me.
13:07:24 <amalloy> !learn edit little[2] s/%/@/
13:07:24 <Sequell> I don't have a page labeled little[2] in my learndb.
13:07:32 <amalloy> !learn edit size_factor[2] s/%/@/
13:07:32 <Sequell> size factor[2/2]: Monster sizes from @?? (for constriction and trampling) in order and with examples: tiny (rats); little (felids); small (kobolds); medium (humans), large (trolls); big (death yaks); giant (dragons)
13:09:17 <Yermak> Actually, no, treeform has the size of the character.
13:10:34 <amalloy> Yermak: replacing little with small sounds good to me but i'm a little reluctant to say, "I am a Developer and I hereby Authorise you to do this because it will be a Good Thing and We Will Merge It". there may be some reason it's not such a great idea that some other dev would point out if they were asked
13:10:52 <Yermak> I understand.
13:10:53 <amalloy> er, with very small
13:19:12 <Yermak> Oh, so played-sized treeform was intentional: http://s-z.org/neil/git/?p=crawl.git;a=commit;h=5c7c912003b121e1d5e9a491f74ff861cd7d52f8
13:19:25 <Yermak> s/played/player/
13:21:11 <amalloy> Yermak: additionally, there was a funny bug caused by huge-size treeform, as i understand it
13:21:39 <amalloy> any player in treeform could wield giant spiked clubs, which didn't get unwielded when they un-transformed
13:21:41 <Yermak> Something like instadeath in deep water when form was over?
13:21:49 <Yermak> ah, yeah
13:22:11 <amalloy> maybe i have the details wrong, but something like that. formicids with a GSC and a large shield mist have been a sight to behold
13:22:26 <amalloy> or...spriggans???
13:23:49 <Yermak> I remember some dev has won Ko with giant club.
13:25:13 <amalloy> !lg devteamnp ko won sk=maces -log
13:25:14 <Sequell> 1. PleasingFungus, XL27 KoBe, T:86540: http://crawl.berotato.org/crawl/morgue/PleasingFungus/morgue-PleasingFungus-20140521-002909.txt
13:25:18 <amalloy> right you are
13:31:12 <Yermak> Should forms that can't use weapons mention it on 'A' screen?
13:35:05 <amalloy> i don't think so. it's already there: (weapon unavailable)
13:35:21 <amalloy> i mean, it's already on %
13:35:31 <Yermak> "Your paws allows you to move quietly." not being supressed in any form looks weird. Especially in tree form.
13:35:59 <amalloy> hah
14:43:48 -!- amalloy is now known as amalloy_
16:13:16 <Tux[Qyou]> i think wisp form is weirder to have paws
17:17:50 <Yermak> If we add the line descripting your size to the 'A' screen, should we add a mutation for it? This line should be able to change when character is transformed, but forms never add new lines to 'A' screen. Sometimes they show some of the mutations listed there as suppressed but that's all. Should this be reworked? For example, tree form should have "You cannot move and teleport.", dragon form "You can breath fire.", etc.
17:43:38 -!- amalloy_ is now known as amalloy
17:45:45 <amalloy> should size really be on 'A'? it's "weirdnesses and mutations", and "you are medium size" doesn't seem to fit that category. it makes some sense to be listed under A: on the % screen but not on the actual A screen; is there precedent for that?
17:49:45 <Yermak> I don't think so. But there is "You are very small and have problems with some larger weapons.\n" on 'A' screen.
17:52:18 <Yermak> I thought 'A:' on % screen was just a compact version of the 'A' screen. But if you say it's fine for something to be in 'A:' without being on 'A' than it's fine.
17:52:36 <Yermak> s/than/then/
17:57:57 <Cheibriados> New branch created: pull/649 (1 commit) 13https://github.com/crawl/crawl/pull/649
17:57:57 <Cheibriados> 03Yermak02 07https://github.com/crawl/crawl/pull/649 * 0.21-a0-437-g1757090: Remove Haste reference 10(11 minutes ago, 1 file, 3+ 3-) 13https://github.com/crawl/crawl/commit/17570903c65b
18:21:44 <Cheibriados> 03amalloy02 07* 0.21-a0-440-g28109cb: Simplify magic_mapping() by naming some intermediate locals 10(26 seconds ago, 1 file, 31+ 30-) 13https://github.com/crawl/crawl/commit/28109cbd927e
18:48:12 <Yermak> Huh, I didn't notice that descriptions for monsters already use "very small" instead of little!
18:48:24 <gammafunk> @?spriggan
18:48:24 <Gretell> spriggan (15i) | Spd: 10 (move: 60%) | HD: 7 | HP: 19-29 | AC/EV: 3/18 | Dam: 15 | 10weapons, 10items, 10doors, see invisible | Res: 06magic(60) | XP: 216 | Sz: little | Int: human.
18:48:38 <gammafunk> !flip consistency
18:48:39 <Sequell> (╯°□°)╯︵ʎɔuǝʇsᴉsu°ɔ
18:59:25 <Yermak> !source monster-main.cc:161
18:59:25 <Sequell> https://github.com/crawl/crawl/blob/master/crawl-ref/source/util/monster/monster-main.cc#L161
18:59:45 <Yermak> But here we use "little" and "Big"
19:01:34 <Yermak> Notice that the first three sizes there start with lowercase and other four - with uppercase.
19:02:42 <|amethyst> that was intentional, and for a time it also went BIG, GIANT
19:03:06 <|amethyst> as far as the words there, `monster` tries to be very terse in its output
19:03:27 <|amethyst> because it's really annoying when it has to be split into two IRC messages
19:03:45 <|amethyst> but changing it to "v.small" and "V.Large" shouldn't be too big a deal
19:04:33 <|amethyst> !tell SteelNeuron Sorry I've missed you.  Haven't had much time to do anything with Crawl the past several days, but I expect to be around this weekend.  I'm on UTC-5
19:04:34 <Sequell> |amethyst: OK, I'll let steelneuron know.
19:05:11 <Yermak> Ok, I see, so is this used only in irc messages?
19:06:24 <|amethyst> @??dragon
19:06:25 <Gretell> can't place dummy monster: "dragon"
19:06:28 <|amethyst> @??fire dragon
19:06:28 <Gretell> fire dragon (04D) | Spd: 10 | HD: 12 | HP: 73-106 | AC/EV: 10/8 | Dam: 20, 13, 1307(trample) | fly | Res: 06magic(60), 05fire++, 03poison, 12drown | Vul: 12cold | XP: 1073 | Sp: fire breath (3d24) [11!AM, 06!sil, 08breath] | Sz: Giant | Int: animal.
19:06:42 <|amethyst> That's what that code does
19:07:01 <|amethyst> it can also run from the command line, but it's mostly used on IRC
19:07:34 <|amethyst> 'make <FLAGS> monster' to build it, it will be in util/monster/monster
19:08:38 <|amethyst> it used to be a separate repo, but we folded it into crawl/crawl because it requires most of the crawl .o files anyway, and it was annoying to keep in sync
19:17:19 <Yermak> describe.cc has array describing sizes (monster sizes) for its own use. If I want to add size description to % screen, should I move this array to describe.h or would it be fine to make my own in output.cc?
19:17:21 <Yermak> !source describe.cc:3716
19:17:21 <Sequell> https://github.com/crawl/crawl/blob/master/crawl-ref/source/describe.cc#L3716
19:18:20 <|amethyst> hm
19:18:30 <|amethyst> that one's a bit weird because it has a null for medium
19:18:36 <|amethyst> I would do neither, but rather:
19:19:01 <|amethyst> move it outside of the function it's in, still a static array in describe.cc
19:19:18 <|amethyst> then make a function in describe.cc that takes a size_type and returns the appropriate element from the array
19:19:33 <|amethyst> replace the uses of the array with a call to the function
19:19:49 <|amethyst> and finally add the function prototype to describe.h and call it from your output.cc code
19:19:59 <|amethyst> again, if you want the same behaviour with medium
19:20:23 <|amethyst> if not, one or the other place will need to be special-cased, and I would suggest describe.cc is the better place
19:20:42 <|amethyst> i.e. instead of  if (sizes[mi.body_size()])   do   if (mi.body_size() != SIZE_MEDIUM)
19:20:51 <Yermak> If we don't mention medium size for monsters I guess we shouldn't mention it for player, should we?
19:21:35 <|amethyst> that may be reasonable
19:22:40 <Yermak> In this case, should I keep that null?
19:23:10 <|amethyst> yeah, if you don't need a word for medium, that would be fine.  But the function's comment should definitely make clear that it can return null
19:23:17 <Yermak> Or still replace it with "medium" for some possible future uses?
19:23:36 <|amethyst> I think having it return "medium" would be cleaner, yeah
19:23:46 <Yermak> Thanks.
19:24:16 <|amethyst> that would mean having the special-case code in two places, but IMO that's a little better than having a function that returns a const char * that might happen to be null sometimes
19:24:38 <|amethyst> ooh, you could have two functions
19:24:47 <|amethyst> one that returns what's in the array, including "medium"
19:25:00 <Yermak> or boolean parameter?
19:25:02 <|amethyst> and another that instead returns nullptr for SIZE_MEDIUM
19:25:10 <|amethyst> yeah, that would work too
19:28:48 <amalloy> instead of a boolean, accept a const char* argument that's "what do you want me to return for medium-sized things?"
19:29:25 <amalloy> boolean arguments are so hard to read, i wish we'd stop adding them. and this way the fact that you could get nullptr is very explicit
19:34:05 <|amethyst> hm
19:34:19 <|amethyst> yeah, that sounds better, assuming the default is "medium"
19:35:19 <|amethyst> I don't mind single booleans; it's when it gets to be more than one that it's a problem to me
19:35:43 <Yermak> Is there policy against using comparisons like 'if (CONSTANT == var)'?
19:36:30 <|amethyst> no policy, but I think Yoda-style comparisons are a little harder to read
19:37:15 <Yermak> On the other hand, they are more fool-proof.
19:37:27 <|amethyst> (at least, for speakers of languages where predicate complements come after the subject, which I think is pretty much all of them)
19:37:35 <amalloy> i also prefer non-yoda style comparisons, and that is mostly what is in the codebase now, but there is no law against the other direction
19:38:02 <amalloy> ??epic_bugs[god_xom
19:38:06 <Sequell> epic_bugs[1/28]: if (you.religion = GOD_XOM)
19:38:09 <|amethyst> I was about to do that
19:38:11 <|amethyst> :)
19:38:35 <Yermak> also, similar question: (int i = 0; i < n; i++) vs (int i = 0; i < n; ++i)?
19:38:42 <|amethyst> doesn't matter
19:38:48 <Yermak> ok
19:39:00 <|amethyst> ++i is usually better for iterators, but for plain ints there's no practical difference
19:39:34 <|amethyst> I usually use ++i myself because of the iterator thing, but C programmers tend to use i++
19:40:32 <G-Flex> jumping in to say that bug is amazing
19:41:02 <amalloy> fwiw we have around 50% more instances of ++i than i++
19:41:12 <G-Flex> ... okay now I'm curious why ++i would be better for an iterator
19:41:14 <amalloy> i prefer i++ but apparently am in the minority
19:41:25 <amalloy> G-Flex: i++ has to modify the iterator but return a copy of the old version
19:41:26 <|amethyst> G-Flex:  because i++ requires a copy
19:41:41 <|amethyst> what amalloy said
19:41:41 <G-Flex> oh so it needs to store another one
19:41:55 <G-Flex> makes sense
19:42:02 <G-Flex> thanks
19:42:14 <amalloy> !source melee_attack::melee_attack
19:42:14 <Sequell> 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/melee-attack.cc#L67
19:42:14 <|amethyst> in practice it's probably optimised away in this context
19:42:29 <|amethyst> since the return value is just thrown away anyway
19:42:35 <G-Flex> true
19:42:44 <|amethyst> optimised away *if* the iterator is defined in the header
19:42:46 <G-Flex> I imagine the performance difference won't be significant anyway in this case
19:42:48 <amalloy> |amethyst: is there a difference between putting "foo = false" in the constructor body, vs foo(false) in its initializer list?
19:43:04 <|amethyst> amalloy:  initializer list happens before the body runs
19:43:36 <amalloy> sure, but the first statement in the body also runs before the rest of the body runs
19:43:41 <|amethyst> amalloy:  for a bool there's no real difference other than timing
19:43:51 <|amethyst> amalloy:  for something of class type there is:
19:44:23 <|amethyst> amalloy:  if you initialize it in the body, then it would first be default-constructed (before the body runs), then assigned to
19:44:29 <amalloy> right, because the default constructor will be used before running the body, if it's not initialized explicitly
19:46:36 <|amethyst> The reason I prefer it even in the case of a simple type is that initializing it in the body reminds me of     int x; x = 10;
19:47:12 <|amethyst> I'd rather not have something uninitialized longer than it needs to be
19:47:21 <amalloy> yes, i understand that "best practice" is to initialize things before the body when it's possible
19:47:39 <amalloy> which is why this function confused me: why are we delaying initializing these things
19:47:51 <amalloy> (the function i linked above, that is)
19:48:18 <|amethyst> amalloy:  ah
19:48:42 <|amethyst> amalloy:  I *think* that's because those things belong to `attack` rather than `melee_attack`
19:49:02 <|amethyst> amalloy:  so unless they're added to attack's constructor, you can't initialize them in the initializer list
19:49:21 <|amethyst> err, initialization list, or whatever it's called... I guess initializer_list is something else now in C++11
19:50:12 <|amethyst> hm
19:50:38 <|amethyst> attack::attack already sets attack_occurred(false) so I guess that can be removed in melee_attack
19:50:46 <amalloy> yeah, i knew initializer list was a different thing but didn't know what to call this instead
19:51:10 <|amethyst> ah, "member initializer list"
19:51:22 <|amethyst> I guess the "member" distinguishes it from the other thing
19:51:43 <amalloy> makes sense
19:51:48 <amalloy> insofar as any c++ naming does
19:53:08 <|amethyst> damage_brand is explicitly not calculated in attack::attack, because (1) it wants to avoid doing much logic, and (2) it wouldn't be right for ranged anyway
20:01:15 <Yermak> https://pastebin.com/AVbjXyN4
20:01:30 <Yermak> |amethyst, I'm not sold that first one is better than the second one.
20:04:22 <|amethyst> Yermak:  amalloy is the one you should be convincing about that :)
20:04:28 <amalloy> heh
20:04:51 <|amethyst> I do agree that   get_size_adj(sz, nullptr);   isn't much clearer than   get_size_adj(sz, false)
20:04:51 <amalloy> i agree neither one looks any better from the implementation. i think the first one will look better when you call it
20:05:08 <Yermak> oops
20:05:46 <amalloy> |amethyst: but get_size_adj(sz, "medium") will be better than get_size_adj(sz, true), right?
20:05:48 <|amethyst> oh, yeah, also, SIZE_MEDIUM
20:06:09 <|amethyst> amalloy:  well, I'd make ignore_medium default to whatever doesn't return null
20:06:14 <|amethyst> amalloy:  so it's   get_size_adj()
20:06:19 <|amethyst> err, get_size_adj(sz)
20:06:44 <|amethyst> but of course for the other version you could also make medium the default
20:06:51 <|amethyst> s/medium/"medium"/
20:07:29 <Yermak> So it's better to make default to be "safe" (not returning null) even if we never use this default?
20:07:32 <amalloy> yeah, i guess if you set a default parameter then there's not much difference in the non-default case
20:07:49 <|amethyst> Yermak:  I think so, because someone will want to use that function for something else
20:08:09 <amalloy> and you want unsafety to look unsafe
20:08:33 <Yermak> And you both think that the first one is still better?
20:08:35 <|amethyst> const char* get_size_adj(const size_type size, bool fuck_me_with_a_blowtorch)
20:08:49 <|amethyst> Yermak:  I prefer the second, amalloy the first
20:08:54 <amalloy> i don't much care between the two
20:08:56 <|amethyst> :)
20:09:01 <Yermak> OK then
20:09:22 <amalloy> if you make the default be the safe one, "medium", as |amethyst says
20:09:45 <Yermak> oh, and do we really need to set a warning commentary before the three-line function?
20:09:50 <|amethyst> the default you set in the declaration, not the definition
20:10:58 <|amethyst> Yermak:  If the default doesn't return nulls, that could be mentioned in the documentation for the parameter
20:11:17 <|amethyst> // If ignore_medium is true, return a null pointer instead of "medium"
20:11:34 <|amethyst> (or the same thing in doxygen docstring lingo)
20:12:56 <|amethyst> I'd only insist on a warning if the default use case can give nulls, because no one would expect that
20:13:11 <|amethyst> s/can/could/
20:37:23 -!- amalloy is now known as amalloy_
20:40:24 <advil> re ++i vs i++, once you go through implementing prefix vs postfix increment you gain a new appreciation for the difference
20:40:48 <advil> some discussion on this se page: https://stackoverflow.com/questions/4421706/what-are-the-basic-rules-and-idioms-for-operator-overloading (which is generally a great page)
20:41:23 <advil> under "Unary arithmetic operators"
20:46:28 <gammafunk> Whenever the meaning of an operator is not obviously clear and undisputed, it should not be overloaded.
20:46:41 <gammafunk> Basically, the first and foremost rule for overloading operators, at its very heart, says: Don’t do it.
20:47:03 <gammafunk> FeelsBadMan
20:49:40 <advil> heh
20:50:15 <|amethyst> cout << "Don't do this" << endl << "Or that, either!\n";
20:52:09 <Yermak> "A: small, mutation resistance 1" vs "A: small size, mutation resistance 1"?
20:53:20 <Yermak> Sometimes "A:" string is quite long, should we omit 'size' for this reason?
21:13:59 -!- amalloy_ is now known as amalloy
21:32:52 <amalloy> i would write just "small"
22:41:36 <Cheibriados> New branch created: pull/650 (1 commit) 13https://github.com/crawl/crawl/pull/650
22:41:36 <Cheibriados> 03Yermak02 07https://github.com/crawl/crawl/pull/650 * 0.21-a0-437-g24aeb67: Add size to % screen 10(9 minutes ago, 4 files, 34+ 23-) 13https://github.com/crawl/crawl/commit/24aeb6729b53
22:42:14 <Yermak> So, do we need form kinks to be displayed on 'A' screen? Such as 'You cannot move and teleport." for treeform?
23:49:47 <gammafunk> !tell SteelNeuron Ok, I've got a wiki page for proposed WJC changes, including your proposals, here. You should be able to edit this as needed: https://github.com/crawl/crawl/wiki/Wu-Jian-Council-Changes
23:49:47 <Sequell> gammafunk: OK, I'll let steelneuron know.
23:59:47 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-440-g28109cb (34)