01:19:39 <Gretell> Unstable branch on crawl.develz.org updated to: 0.21-a0-348-ga060c75 (34)
01:57:17 <Gretell> Windows builds of master branch on crawl.develz.org updated to: 0.21-a0-348-ga060c75
02:53:13 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.21-a0-348-ga060c75
03:11:42 <Rotatell> Unstable branch on crawl.beRotato.org updated to: 0.21-a0-348-ga060c75 (34)
04:01:27 -!- Napkin_ is now known as Napkin
04:45:51 -!- amalloy is now known as amalloy_
04:55:16 -!- amalloy_ is now known as amalloy
05:50:29 -!- amalloy is now known as amalloy_
08:31:55 -!- Mayoi is now known as erkin
10:49:33 <advil> unfortunately all the reasons that made me want to try explicitly rewriting stuff using fixed point calculations also make it a pain to do the rewriting
11:43:51 <advil> today's weird interaction: inserting a dprf (pretty much anything will do, and boy did it take me a while to figure this out) in player::armour_class in a fulldebug console build breaks AC refresh in the HUD
11:45:01 <advil> if anyone has any ideas why that could happen, I'd be excited to hear them
11:50:18 <advil> inserting another dprf in the relevant conditional in output.cc unbreaks it
11:50:21 <advil> goddamn side effects
11:50:28 <|amethyst> advil:  in output.cc:
11:50:33 <|amethyst> if (you.redraw_armour_class)
11:50:33 <|amethyst> {
11:50:33 <|amethyst> you.redraw_armour_class = false;
11:50:33 <|amethyst> _print_stats_ac(1, ac_pos);
11:50:33 <|amethyst> }
11:50:44 <|amethyst> advil:  I bet if you switch the order of those two lines, it will work
11:50:57 <advil> ohhh
11:51:08 <|amethyst> hmm
11:51:17 <|amethyst> or maybe that would lead to an infinite loop instead :)
11:51:50 <advil> sadly, neither
11:52:00 <advil> that's a pretty relevant hypothesis though
11:52:11 <|amethyst> advil:  oh
11:52:15 <advil> it must be something like that
11:52:23 <|amethyst> advil:  are you sure the AC isn't showing up in the wrong place
11:52:32 <|amethyst> like, at the end of the message you just printed
11:52:52 <|amethyst> because in _print_stats_ac it does the CGOTOXY at the very beginning, before calculating AC
11:52:57 <advil> hm, it's not obvious, but it could be getting overwritten
11:53:05 <advil> I'll try that
11:53:14 <|amethyst> hm
11:53:55 <|amethyst> if that's it, I guess the proper thing to do would be to save/restore the cursor position somewhere, maybe in the message display code
11:54:08 <advil> that was it
11:54:16 <|amethyst> OTOH, changing that in the message display code could break other things
11:54:21 <advil> and yeah, there's all sorts of room for exactly this problem in this code
11:54:55 <|amethyst> and _boosted_ac and other things call armour_class too
11:55:07 <advil> I don't see any good reason not to group the goto and the print here
11:55:36 <|amethyst> yeah, it's less fragile anyway
11:55:53 <advil> it probably is safe to assume that outside of debugging situations none of these are going to print anything, I guess
11:55:56 <|amethyst> but printing in armour_class is probably not a great idea
11:56:11 <advil> yeah, I'm just doing it for debugging purposes
11:56:16 <|amethyst> I imagine it's also used in places (like %) where you can't even see the message window
11:56:46 <|amethyst> I mean, it's likely to break other things
11:56:47 <advil> that's usually ok because it will show up in the backlog, but with some visual artifactws in the menu
11:56:57 <|amethyst> which isn't necessarily conducive to debugging, as you just discovered
11:56:58 <|amethyst> :)
11:56:58 <advil> that sort of thing already happens a lot in a fulldebug build
11:57:11 <|amethyst> not entirely surprised there :)
11:58:37 <advil> hm would cgotoxy ever mess with color?
11:58:51 <|amethyst> no, but printing would of course
11:59:19 <|amethyst> so you'd want to make a variable for the colour, then only actually call textcolour() between moving and printing
11:59:49 <|amethyst> otherwise things might turn up in MSGCH_DIAGNOSTICS colour or just lightgrey
12:00:25 <|amethyst> not for AC because of the order of things in the code, but it would happen for SH when _boosted_sh is called
12:00:33 <|amethyst> if you had a similar dprf in the shield code
12:00:50 <advil> yeah, good point
12:01:20 <advil> I think if I ever wanted to work on output.cc again I'd try to have better abstractions here
12:02:20 <|amethyst> abstractions were three chapters after pointers in the book...
12:02:58 <|amethyst> ??linley henzell[6]
12:02:58 <Sequell> linley henzell[6/7]: Henzell discussing his programming ability: "You see, I gave up on Borland's [C++] manual (which is very good, I'm just lazy) when it started talking about pointers [....] After pointers came structs, enums, pragmas, classes, macros, and a whole lot of other stuff which still means nothing to me."
12:02:58 <advil> haha
12:03:17 <advil> this file always feels like I'm editing logo code or something
12:03:29 <|amethyst> nah, logo is functional :)
12:03:40 <advil> ugh also why is HUD_VALUE_COLOR a short
12:03:45 <|amethyst> it's more like apple 2 basic
12:03:47 <advil> heh
12:04:08 <|amethyst> yeah, IMO change that to a COLORS
12:04:16 <|amethyst> (or auto)
12:04:44 <|amethyst> (also, nice that formatted_string::textcolour(int colour) takes a plain int...)
12:05:06 <advil> there's actually a reason for that, those are sdl colours iirc
12:05:22 <advil> I can double check though
12:05:43 <|amethyst> oh, right, enum COLORS is in the tile tool, not crawl
12:05:58 <advil> or they have to interact with sdl colors, or something
12:06:07 <advil> it's true that int still doesn't seem ideal
12:06:32 <|amethyst> ah
12:06:34 <|amethyst> COLOURS
12:06:36 <|amethyst> sorry,
12:06:43 <|amethyst> in defines.h
12:07:23 <advil> yeah, I know the one you mean
12:10:18 <advil> of course now I have to test this in tiles too
12:10:36 <advil> and the actual thing I was trying to do is now way down in the stack
12:11:47 <advil> basic question: auto is deduced by the compiler, right?
12:12:02 <|amethyst> yes
12:16:08 <|amethyst> in this case it would be deduced as COLOURS because that's what LIGHTGREY is
12:18:54 <|amethyst> oh, nice, colour_bar has a member typedef colour_t that is a different type from the one in defines.h ...
12:19:06 <advil> lol
12:19:31 <advil> colour_bar, my old nemesis
12:20:01 <|amethyst> I wonder if anything would break if you just removed that typedef
12:20:12 <Cheibriados> 03advil02 07* 0.21-a0-349-g0c35859: Make some output.cc code very slightly less brittle 10(3 minutes ago, 1 file, 13+ 11-) 13https://github.com/crawl/crawl/commit/0c35859775eb
12:20:58 <|amethyst> oh, I see
12:21:58 <advil> there's a reason for that?
12:22:10 <advil> I fixed the ac thing since that's relevant to my current project, but I might now back slowly away from output.cc without making any threatening moves
12:47:56 -!- amalloy_ is now known as amalloy
13:05:14 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.21-a0-349-g0c35859 (34)
13:09:21 <Jorgrell> Unstable branch on crawl.jorgrun.rocks updated to: 0.21-a0-349-g0c35859 (34)
13:35:56 <greensnark> Sequell is going to take a short break for a brain replacement
13:36:25 <greensnark> When I said "short" I meant "long"
13:41:04 -!- neunon_ is now known as neunon
15:57:36 <gammafunk> @?orb spider
15:57:36 <Gretell> orb spider (06s) | Spd: 12 (spell: 200%) | HD: 7 | HP: 32-49 | AC/EV: 3/10 | Dam: 5 | web sense | Res: 06magic(40) | Vul: 09poison | XP: 588 | Sp: o.destruction (9d9) [06!sil] | Sz: small | Int: animal.
16:20:19 <Lightli> orb spiders have a melee attack?
16:22:53 <geekosaur> yes, but they do everything they can to not use it since theyre really hard to corner
18:02:38 <Lantell> Unstable branch on underhound.eu updated to: 0.21-a0-349-g0c35859 (34)
20:28:22 -!- amalloy is now known as amalloy_
20:58:44 <gammafunk> johnstein: looks like cbro disk is full again
21:00:27 <geekosaur> ^status
21:00:27 <Rotatell> 12 Crawlers. CBRO disk usage=100% (135GB) | RAM usage=24% (4GB)| uptime/CPU= 21:00:26 up 218 days,  1:38,  1 user,  load average: 0.00, 0.04, 0.15 (4 Cores) http://status.berotato.org
21:00:33 <geekosaur> whoops...
21:02:46 -!- amalloy_ is now known as amalloy
21:05:07 <johnstein> fuck yea
21:05:31 <johnstein> ^status
21:05:32 <Rotatell> 11 Crawlers. CBRO disk usage=98% (135GB) | RAM usage=25% (4GB)| uptime/CPU= 21:05:31 up 218 days,  1:43,  2 users,  load average: 0.08, 0.08, 0.14 (4 Cores) http://status.berotato.org
21:06:02 <johnstein> deleted some binaries. I will rsync ttyrecs later
21:10:35 <gammafunk> johnstein: thanks
21:13:15 <hellmonk> when you're trying to search the forum for species proposals but the word species is too common and it won't let you
21:13:38 <gammafunk> hellmonk: maybe search thread titles with proposal
21:13:47 <hellmonk> proposal is also too common
21:13:49 <gammafunk> actually you probably just want to limit search to thread titles
21:13:52 <hellmonk> and filtering seems to not do anything
21:13:55 <gammafunk> you're probably searching thread contents
21:14:43 <hellmonk> oh I can get around it with wildcards for some reason
21:15:24 <hellmonk> it says proposal is too common even when I search thread titles only but it takes proposa* just fine
21:15:32 <hellmonk> quality forum searchin code
21:23:26 <hellmonk> oh, I just found https://crawl.develz.org/wiki/doku.php?id=dcss:brainstorm:species:propose:proposed_species#iron_dwarf
21:23:40 <hellmonk> excellent times ahead
21:30:39 <hellmonk> so many of these do weird things with hunger and/or transformations, wtf
21:36:40 <hellmonk> god there are just pages and pages of awful text
21:46:12 <nikheizen> hellmonk: a race which turn into fast berserk doggehs please
21:46:23 <hellmonk> comin right up fam
21:48:08 <hellmonk> mfw I realize I'll probably put a couple dozen hours into an april fools joke branch
21:59:19 -!- amalloy is now known as amalloy_
22:37:35 <johnstein> ^status
22:37:35 <Rotatell> 44 Crawlers. CBRO disk usage=95% (135GB) | RAM usage=26% (4GB)| uptime/CPU= 22:37:34 up 218 days,  3:15,  1 user,  load average: 0.41, 0.50, 0.44 (4 Cores) http://status.berotato.org
22:41:37 <nikheizen> do you have to manually do disk clean up?
22:43:29 <gammafunk> johnstein: dang, that's after the ttyrec rsyncs?
23:53:01 <johnstein> no
23:53:02 <johnstein> that's after deleting old crawl-git* builds in source and stripping old binaries
23:53:09 <johnstein> ttyrecs should be transferred by now. I'll confirm and delete in a bit. should be down to about 85%
23:59:23 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-349-g0c35859 (34)