00:00:03 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-215-g0631661 (34)
02:52:11 <Lightli> ??c-r-d
02:52:11 <Sequell> c-r-d[1/2]: https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
03:11:54 <Rotatell> Unstable branch on crawl.beRotato.org updated to: 0.21-a0-215-g0631661 (34)
03:29:30 <Napkin> Cool!
03:29:31 <Sequell> Napkin: You have 4 messages. Use !messages to read them.
03:35:49 -!- amalloy is now known as amalloy_
07:01:56 -!- The topic of ##crawl-dev is: Crawl Development | Logs: http://s-z.org/crawl-dev/ | People with +v have commit access. | Please keep general Crawl-related chat to ##crawl. | Dev wiki: http://crawl.develz.org/wiki | Long stuff to a pastebin service, please.
07:01:57 -!- The topic of ##crawl is: Play Dungeon Crawl Stone Soup online now! Type ??servers for instructions. | http://crawl.develz.org | FooTV: http://termcast.develz.org - ??footv for instructions | See also ##crawl-offtopic
07:18:59 <Cheibriados> Disconnected vault 13https://crawl.develz.org/mantis/view.php?id=11193 by Yermak
07:46:44 -!- mumra1 is now known as mumra
08:00:39 <alexjurkiewicz> !tell hellmonk zot feedback: radiation breath spell frequency seems really low compared to other crabs
08:00:39 <Sequell> alexjurkiewicz: OK, I'll let hellmonk know.
08:21:45 <alexjurkiewicz> !tell hellmonk i take it back
08:21:46 <Sequell> alexjurkiewicz: OK, I'll let hellmonk know.
08:47:56 <gammafunk> !lg * xpinfo won
08:47:57 <Sequell> 20. Gorglomux the Victor of a Thousand Battles (L27 HOAK of Okawaru), escaped with the Orb and 3 runes on 2017-08-22 12:45:38, with 1790439 points after 62149 turns and 2:13:25.
08:48:02 <gammafunk> !lg * xpinfo hu won
08:48:04 <Sequell> hu is ambiguous: may be species or class. Use hu-- (Human) or --hu (Hunter) to disambiguate
08:48:06 <gammafunk> !lg * xpinfo hu-- won
08:48:07 <Sequell> No games for * (xpinfo hu-- won).
08:48:13 <gammafunk> !lg * xpinfo hu won -log
08:48:14 <Sequell> hu is ambiguous: may be species or class. Use hu-- (Human) or --hu (Hunter) to disambiguate
08:48:19 <gammafunk> !lg * xpinfo won -log
08:48:21 <Sequell> 20. Gorglomux, XL27 HOAK, T:62149: http://crawl.xtahua.com/crawl/morgue/Gorglomux/morgue-Gorglomux-20170822-124538.txt
08:49:52 <|amethyst> !lg * xpinfo mu won -log
08:49:53 <Sequell> No games for * (xpinfo mu won).
08:50:42 <gammafunk> oh that's a good one to look out for as well
08:50:52 <|amethyst> !lg * xpinfo su won -log
08:50:53 <Sequell> 1. Yermak, XL27 DsSu, T:72064: http://crawl.xtahua.com/crawl/morgue/Yermak/morgue-Yermak-20170821-230924.txt
08:51:27 <|amethyst> !lg * xpinfo en won -log
08:51:28 <Sequell> 2. beep, XL27 SpEn, T:84335: http://crawl.berotato.org/crawl/morgue/beep/morgue-beep-20170821-153221.txt
08:51:48 <|amethyst> !lg * xpinfo en won -log -2
08:51:49 <Sequell> 1/2. alcopop, XL26 SpEn, T:91229: https://crawl.project357.org/morgue/alcopop/morgue-alcopop-20170821-120350.txt
08:54:30 <gammafunk> some of those migh be transfers
08:54:36 <gammafunk> *might
08:54:52 <|amethyst> alcopop definitely is
08:55:05 <|amethyst> and beep probably
08:56:38 <gammafunk> 75611 | Lair:6   | Upgraded the game from 0.21-a0-207-g4a9efaf to 0.21-a0-210-gbfa5647
08:56:41 <gammafunk> yeah beep is
09:04:30 <advil> !kw xpinfo
09:04:31 <Sequell> Keyword: xpinfo => vlong>=0.21-a0-210-gbfa5647
12:10:38 <Cheibriados> Ignite Poison asks for confirmation when the player has cloud immunity 13https://crawl.develz.org/mantis/view.php?id=11194 by Stonar
12:43:06 -!- us17_ is now known as us17
12:47:32 <advil> re discussion in ##crawl, I've always wondered if the different behavior of different fog types is even intentional?  When I was working on that code it wasn't obvious at all
12:47:54 <gammafunk> well, as old as fog is, and as weird as old crawl dev was
12:48:00 <gammafunk> I'd have to guess that it was intentional
12:48:07 <gammafunk> but you could certainly argue that it shouldn't exist
12:48:11 <advil> personally I'd rather decrease the frequency and make them all work the same, w.r.t. spreading
12:48:27 <advil> if the goal of that is balance
12:48:41 <advil> or just make them all work the same, it's not the most common scroll already
12:49:10 <advil> maybe I'll look into the code archeology again at some point
12:49:43 <gammafunk> yeah, I agree
12:49:57 <gammafunk> I mean I guess you want fog to have some randomness to its effect but
12:50:07 <gammafunk> probably the duration/spread of clouds already achieves this?
12:50:30 <gammafunk> sometimes you read a fear and the monster beats the MR check, after all
12:50:47 <gammafunk> however fear is a stronger effect when successful
12:50:48 <advil> yeah, that should already have some randomness
12:50:58 <advil> & the good fog kinds already aren't perfect
12:51:15 <advil> depends on terrain, etc
12:51:30 <gammafunk> terrain?
12:51:44 <advil> its spread is impacted by terrain -- maybe not in ways that will matter for los
12:51:47 <gammafunk> do fog clouds spread differently over water?
12:51:51 <elliptic> advil: I think fog is very bad at the moment so buffing it sounds good
12:52:06 <elliptic> most other people like it more than me though
12:52:19 <gammafunk> qw power creep....
12:52:23 <advil> hm I'm not sure what I mean, but when I was testing it I noticed it seemed to matter whether there were walls and stuff
12:52:29 <gammafunk> but yeah, I agree that the terrible fog variants don't need to be a thing
12:52:33 <advil> I like it when it's not blue/purple
12:52:52 <advil> it took me a while to even realize that the blue/purple ones behave differently, too
12:56:28 <advil> !learn add advil_todo eliminate or change bad fogs
12:56:29 <Sequell> advil todo[1/1]: eliminate or change bad fogs
12:58:11 <|amethyst> turn it into a mix of petrifying dust and steam
12:58:43 <|amethyst> (why is blessed fire opaque, btw?)
13:01:09 <nikheizen> its REALLY bright
13:02:10 <|amethyst> FR: bring back opaque monsters
13:05:01 <advil> heh
13:05:04 <advil> was that just for mimics?
13:05:05 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.21-a0-215-g0631661 (34)
13:06:00 <advil> I find the idea kind of entertaining but I'm guessing it would not work very well for regular monsters (make juggernauts opaque??)
13:06:27 <elliptic> it was just door mimics I think?
13:20:25 <|amethyst> elliptic:  yeah
13:20:31 <|amethyst> and the opaque monster that still exists
13:20:36 <|amethyst> s/opaque/half-opaque/
13:34:00 <Cheibriados> Shadow Step onto unknown wand doesn't identify it. 13https://crawl.develz.org/mantis/view.php?id=11195 by Yermak
13:43:59 -!- amalloy_ is now known as amalloy
14:01:15 -!- mumra1 is now known as mumra
14:03:23 <espais> !messages
14:03:23 <Sequell> No messages for espais.
14:12:27 <gammafunk> Napkin: looks like CDO isn't pulling trunk updates right now
14:12:30 <gammafunk> &versions cdo
14:12:37 <Sequell> CAO: none, CBRO: none, CDO: 0.21-a0-2-ge494091, CJR: none, CPO: none, CUE: none, CWZ: none, CXC: none, LLD: none
14:12:38 <gammafunk> er
14:12:40 <gammafunk> wait
14:13:31 <gammafunk> yeah
14:13:40 <gammafunk> trunk is at the version above
14:15:13 <Napkin> looks like yesterday the build ran fine
14:16:19 <Napkin> heh, cleanup script removed it though :D
14:16:50 <Napkin> but i'm relaxing now, will check tomorrow
14:17:04 <gammafunk> thanks Napkin
15:41:52 <Cheibriados> 03amalloy02 07* 0.21-a0-216-g6d3fd91: Remove a bunch of #if 0 clauses 10(22 hours ago, 9 files, 0+ 83-) 13https://github.com/crawl/crawl/commit/6d3fd91c97f0
16:09:16 <Jorgrell> Unstable branch on crawl.jorgrun.rocks updated to: 0.21-a0-216-g6d3fd91 (34)
16:27:34 <travis-ci> The build passed. (master - 6d3fd91 #8655 : Alan Malloy): https://travis-ci.org/crawl/crawl/builds/267321207
18:02:02 <gammafunk> hrm, how does mgen-data.h know what monster_type is?
18:02:16 <Lantell> Unstable branch on underhound.eu updated to: 0.21-a0-216-g6d3fd91 (34)
18:02:18 <gammafunk> that's defined in monster-type.h
18:02:43 <gammafunk> but I'm not sure how it's able to see the definition of that enum
18:05:15 <|amethyst> gammafunk:  AppHdr.h -> externs.h -> monster-type.h
18:05:21 <|amethyst> which is not good
18:05:41 <geekosaur> secret #include requirement
18:05:55 <|amethyst> but because we always #include AppHdr first (for PCH support), anything in enums.h or externs.h is auto-included
18:06:24 <|amethyst> hm, externs anyway
18:06:30 <|amethyst> I guess that pulls in enums.h indirectly?
18:06:41 <|amethyst> ah, directly
18:06:44 <|amethyst> and s/enums/enum/g
18:07:07 <|amethyst> but, yeah, if you don't #include AppHdr.h first, probably nothing will compile
18:11:57 <gammafunk> |amethyst: well, I guess I should have asked a more direction question, which is
18:12:12 <gammafunk> I want to add an enum that's someting like xp_type or xp_tracking_type
18:12:20 <gammafunk> that will go in mgen_data and monster
18:12:31 <gammafunk> in place of the broken is_spawn field I added
18:12:43 <gammafunk> because I'm currently mistracking xp from orb spawns as level gen xp
18:13:07 <gammafunk> I didn't think too carefully about how that logic would work; a simple boolean won't cut it
18:13:09 <gammafunk> so I'm not sure where to define this enum
18:13:37 <gammafunk> perhaps a new header and make sure it's added to externs.h ?
18:14:11 <|amethyst> gammafunk:  we are moving in the direction of splitting up enums into separate headers, but
18:14:43 <|amethyst> if you include it from externs.h that defeats the purpose of that trend, in that it forces recompiling pretty much everything
18:14:56 <|amethyst> so I'd #include it directly where needed
18:15:02 <gammafunk> ok
18:15:50 <wheals_> have we tried forward declaring of enums yet at all?
18:17:12 <|amethyst> wheals_:  I don't like forward-declaration that much because you have to explictly specify the underlying_type
18:18:19 <|amethyst> it shouldn't be necessary to forward-declare enums if you have fine enough granularity of headers
18:18:27 <|amethyst> since it's extremely rare that the definition of an enum will refer to another enum
18:18:50 <|amethyst> so you don't have to worry about circular dependencies, which is where you really need forward declaration
18:20:14 <wheals_> true enough, splitting up headers should be good enough
18:22:01 <advil> hmm, yeah, secret includes are bad
18:23:32 <advil> that quest seems very quixotic to me though
18:23:48 <advil> I'm not sure my AppHdr-related project made any difference whatsoever in the end
18:24:02 <advil> I guess everything we do here falls under the "quixotic" category
18:24:11 <|amethyst> soon enough windmills will be replaced by modules I hope
20:44:47 <amalloy> huh, TIL about commands like CMD_SAFE_MOVE_LEFT, not bound to any key by default afaict
20:45:17 <amalloy> wow, and CMD_CLOSE_DOOR_DOWN_LEFT
20:47:45 <gammafunk> well sometimes you don't like leaving the down-left door open like that
20:52:09 <amalloy> why would you use a boring single key like C when you could bind eight different door-closing commands
21:19:55 -!- amalloy is now known as amalloy_
22:01:55 <brian__> hey all. first time building crawl here - macOS 10.13. is there any way to force the build to use the repo's version of Lua?
22:02:28 <gammafunk> yeah, there are Makefile arguments for each contrib
22:02:33 <gammafunk> ??install
22:02:34 <Sequell> install[1/1]: See the following for installation and compilation: https://github.com/crawl/crawl/blob/master/crawl-ref/INSTALL.txt
22:03:22 <gammafunk> brian__: add BUILD_LUA=y as an argument to your make command
22:09:23 <brian__> hm. doesn't seem to work. i have headers for 5.3.3 in /usr/local/include and it's still grabbing those
22:10:03 <brian__> do i need to build the contrib libs first?
22:10:32 <gammafunk> no, those would get built by your make from the source dir
22:10:38 <gammafunk> brian__: what's your make command, exactly?
22:10:48 <brian__> make BUILD_LUA=y
22:11:09 <gammafunk> hrm
22:11:14 <brian__> only worked with cmake until now, sorry if that is completely wrong >.>
22:11:36 <gammafunk> no, that would do a console build which should use the lua contrib
22:11:41 <gammafunk> I assume you want console
22:11:50 <gammafunk> but yeah that's a valid make command
22:11:51 <brian__> yep, i was going to try that first at least
22:12:06 <brian__> i get the line "* Need to build contribs: zlib lua/src sqlite"
22:12:23 <brian__> but then it immediately starts building tiles
22:12:36 <gammafunk> advil: do you happen to know why brian__ is not able to get the lua contrib to build when using `make BUILD_LUA=y'
22:12:36 <brian__> err sorry
22:12:43 <brian__> it stars building "tilegen"
22:12:49 <gammafunk> well it's not building tiles, yeah it's doing tilegen stuff
22:14:25 <gammafunk> brian__: you might want to ask advil or geekosaur, both have more experience with the OS X build than I do
22:18:15 <geekosaur> tilegn is built first because it's a utility program that also generates header files needed by the non-tiles build
22:18:31 <geekosaur> so it's a bit unfortunately named
22:19:23 <brian__> gotcha
22:19:27 <advil> hmm, not immediately sure
22:19:36 <geekosaur> (more precisely: even in non-tiles builds, the monster info structures include tile information from header files. tilegen generates those header files, so it must run even for non-tiles builds, before anything else is done)
22:20:37 <brian__> i do technically have a system package for lua5.1 installed through brew as well
22:20:52 <geekosaur> in theory that could be made conditional on tiles builds, but then I suspect you wouldn't be able to load a saved tiles game in console or vice versa
22:23:45 <geekosaur> I had at one point a modified Makefile that could build with the MacPorts versions of the contribs.
22:24:39 <geekosaur> But having seen far too much of the Makefile (run away!) I think you can't make it use /usr/local for overrides the same way, because it already knows about /usr/local
22:24:59 <geekosaur> (and unfortunately not in a way that helps you)
22:26:50 <geekosaur> crawl's build system is a mess
22:27:25 <brian__> compared to the cmake config in the project i spend most of my time on, it's not too bad :P
22:27:54 <geekosaur> I hope the person who wanted to replace our makefile with cmake is listening :p
22:28:16 <brian__> hahaha
22:28:21 <gammafunk> bh wanted us to use google's new thing, bezel I think it's called
22:28:34 <brian__> oh bazel
22:28:41 <gammafunk> sorry, bazel, yeah
22:28:58 <geekosaur> it took considerable experimentation to get the lua and ncurses includes to use non-system includes without causing conflicts
22:29:43 <geekosaur> and that's the part that I suspect would misbehave if you just took my Makefile and changed /opt/local to /usr/local everywhere
22:29:55 <gammafunk> Well, I was wondering why brian__ couldn't get the lua contribs to work
22:29:59 <brian__> mm
22:30:25 <geekosaur> it might work after tilegen was built; iirc that's done really early
22:30:43 <brian__> if I run make -B, it builds lua before tilegen
22:30:51 <brian__> but still includes the wrong header
22:31:34 <geekosaur> ...you'e probably in for some pain, then
22:32:39 <geekosaur> getting the headers to work right was by far the hardest part of getting crawl to use not-contribs on OS X. it's got too many special hardcodes for OS X and too many weird things to make includes happen in the right order (really, nothing should ever have to use -isystem...)
22:32:57 <geekosaur> (except kernel/OS builds and cross-builds)
22:33:26 <brian__> hmm
22:33:29 <brian__> well wait a minute. now it's pulling in the header from contrib/install, and still failing
22:34:35 <brian__> > cluautil.cc:55:5: error: use of undeclared identifier 'luaL_openlib'; did you mean 'luaI_openlib'?
22:36:26 <advil> so I suppose it is possible that something in the build system broke in 10.13
22:36:51 <advil> we certainly have not tested 10.13 at all yet
22:37:34 <brian__> yeah, i was about to say - this is on macOs 10.13, Xcode 9
22:37:43 <brian__> it wouldn't be the first thing that's broken
22:39:15 <geekosaur> that sounds rather odd though
22:44:56 <gammafunk> It wouldn't be a true release without OS X struggles
22:45:05 <gammafunk> msys2 broke a while ago, so it's high time
22:45:52 <advil> it does sound odd, given #define luaI_openlib    luaL_openlib
22:46:18 <advil> but perhaps it is indicative of versioning problems
22:46:48 <advil> probably older, rather than newer?
22:47:03 <advil> since that define is a backwards compatibility thing
22:47:09 <advil> (in the contrib version)
22:47:41 <brian__> sorry, i should do a better job of explaining
22:47:54 <brian__> all i did to get to this point was rename the /usr/local/include header
22:48:12 <brian__> so it's probably pulling in the right one for that and bad for everything else
22:48:13 <brian__> oop
22:48:16 <brian__> it's late here
22:49:11 <brian__> because yeah, according to the bundled headers, that compat flag is defined
22:49:30 <advil> ah, yeah, it's probably using a mix of headers
22:49:52 <advil> gammafunk: I'm not going to struggle too much until 10.13 is actually released
22:50:02 <brian__> that's fair
22:50:17 <advil> well, I don't mean to say that I don't want to know what's going on with your setup
22:51:24 <brian__> it is likely that it's my setup though - i think i installed lua through a separate installer and then 5.1 through homebrew
22:51:45 <brian__> er installation process.
22:52:20 <advil> hmm perhaps...I can try installing a different version of lua to see if I can replicate (probably not tonight though)
22:55:23 <brian__> all right. thanks for your help :) i'm going to play around with it a bit longer
23:22:34 <brian__> i just renamed all the lua headers in /usr/local/include and it built fine.. not satisfied with that solution but it's something!
23:25:32 <geekosaur> that sounds about right... related to why I suspected using /usr/local/include as a header location would just break things completely
23:25:53 <geekosaur> (cf. my Makefile hacks for MacPorts' /opt/local)
23:41:40 <johnstein> so I created a function, bool update_monster(monster& mon, int turns), in timed-effects.cc. I'm trying to pass monster_iterator, mi, from update_level() to that via: update_monster(mi, turns), but I get this error: timed-effects.cc:1406:38: error: invalid initialization of reference of type 'monster&' from expression of type 'monster_iterator'
23:42:47 <geekosaur> *mi, I think
23:42:51 <johnstein> the monster_iterator kinda confuses me I think. mi seems to represent an iteration of monsters in a single variable, but I'm not sure how to pass that correctly to the new function that only accepts a single monster
23:43:21 <johnstein> that worked when update_monster(monster* mon, int turns)
23:43:29 <johnstein> but I switched it from monster* to monster&
23:43:59 <geekosaur> right, so you need to dereference now
23:44:03 <geekosaur> *mi, as I said
23:44:32 * geekosaur just doublechecked the iterator definition and is reasonably certain *mi is the right thing here
23:44:42 <geekosaur> basically mi is a smart pointer
23:45:07 <geekosaur> to get he actual monster you dereference it, wither with *mi to get the whole monster, or mi->... to access a particular field
23:45:41 <geekosaur> mi++ is the "smart" part, it skips dead monsters etc.
23:46:20 <johnstein> timed-effects.cc:1406:29: error: invalid initialization of non-const reference of type 'monster&' from an rvalue of type 'monster*'
23:46:20 <johnstein> if (!update_monster(*mi, turns))
23:46:20 <johnstein> ^~~
23:46:20 <johnstein> In file included from timed-effects.cc:8:0:
23:46:20 <johnstein> timed-effects.h:11:6: note: in passing argument 1 of 'bool update_monster(monster&, int)'
23:46:20 <johnstein> bool update_monster(monster& mon, int turns);
23:46:52 <geekosaur> oh, the fnction itself
23:47:06 <geekosaur> I don't think you can use an iterator there without a temporary, then
23:47:32 <wheals_> does **mi not work
23:47:48 <geekosaur> hm, might
23:47:57 <johnstein> it made the error go away in eclipse...
23:47:59 <johnstein> compiling...
23:48:44 <geekosaur> mm, yes, * returns a pointer, so the iterator is acting like a double pointer
23:48:51 <geekosaur> yug
23:48:56 <johnstein> compiled! brb time to force push...
23:49:30 <johnstein> I seriously need a nice C++ boot camp or something
23:51:39 <johnstein> still didn't do what I wanted it to do, but the game worked at least. ty!
23:59:39 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-216-g6d3fd91 (34)