--- Log opened Sat Feb 27 00:00:05 2016
20160227 00:00:06< celticminstrel> In fact, I think it's confusing to have name=target referring to a unit but name=protect referring to a location.
20160227 00:00:13< celticminstrel> I might just delete it.
20160227 00:01:39< mattsc> sounds good
20160227 00:01:59-!- louis94 [~~louis94@91.178.240.113] has quit [Quit: Konversation terminated!]
20160227 00:03:55< mattsc> celticminstrel: the Experimental_AI and Micro_AIs pages are ready to go too.
20160227 00:04:02< celticminstrel> Each aspect is registered twice - once as a composite and once as a standard...
20160227 00:04:21< mattsc> I didn’t do much with them though.  I only read and changed the intro section on Micro_AIs.
20160227 00:04:41< celticminstrel> ...and again as a Lua aspect.
20160227 00:04:44< mattsc> And ExpAI is pretty much a copy-and-paste from a forum post by Alarantalara (except for the setup part)
20160227 00:05:02< celticminstrel> Except at least one isn't registered as a Lua aspect - the attacks aspect.
20160227 00:05:20< mattsc> okay
20160227 00:05:37< mattsc> Aginor: did I point you to the Experimental AI wiki page a couple days ago?
20160227 00:06:05< mattsc> https://wiki.wesnoth.org/Experimental_AI
20160227 00:06:24< mattsc> That’s the AI we were talking about about possibly semi-defaulting
20160227 00:06:59< mattsc> celticminstrel: I now have two pages left to do, but both of them are still incomplete, so it’s going to take a little while.
20160227 00:09:50< celticminstrel> Okay.
20160227 00:10:20-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160227 00:11:24< celticminstrel> The only place the name=protect form was actually used is in ai_controller.cfg.
20160227 00:13:27< mattsc> You’ll have to talk to zookeeper about that one  ;)
20160227 00:14:11< celticminstrel> Well, changing it to protect_location is trivial (and judging by surrounding code is almost certainly what was intended).
20160227 00:19:48-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Quit: Leaving]
20160227 00:28:05-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Ping timeout: 244 seconds]
20160227 00:34:55< vultraz> celticminstrel: I think a bigger priority would be to fix the huge lag there is before the editor opens up
20160227 00:35:30< vultraz> you click the button, the loadscreens pops up, finishes, then there's almost 2 seconds of black screen before anything appears
20160227 00:37:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160227 00:38:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160227 00:42:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20160227 00:46:36-!- ancestral [~ancestral@8.sub-70-197-237.myvzw.com] has joined #wesnoth-dev
20160227 00:47:33< celticminstrel> BTW mattsc, your documentation mentions that invalidate_on_tod_change currently isn'y working, which is fine (the code seems to confirm this). However, the code also implies the same about invalidate_on_minor_gamestate_change.
20160227 00:51:04< celticminstrel> I suspect fixing tod_change would be easier than fixing minor_gamestate_change...
20160227 00:53:05< mattsc> celticminstrel: okay, thanks
20160227 00:54:07-!- aidanhs [~aidanhs@81.4.110.234] has quit [Ping timeout: 252 seconds]
20160227 00:55:31< mattsc> I’ve never seen any application that would need invalidation on minor_gamestate_change
20160227 00:56:53-!- aidanhs [~aidanhs@81.4.110.234] has joined #wesnoth-dev
20160227 00:57:11-!- irker515 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160227 00:57:11< irker515> wesnoth: Charles Dang wesnoth:master 2ee1cf3cc01f / src/editor/ (3 files in 2 dirs): editor: don't switch contexts if attempting to switch to current context https://github.com/wesnoth/wesnoth/commit/2ee1cf3cc01f7cac7b5edc0f65bacdb69441e109
20160227 00:57:12< irker515> wesnoth: Charles Dang wesnoth:master 86746aaaf094 / src/editor/map/context_manager.cpp: editor: don't redraw entire screen when switching contexts https://github.com/wesnoth/wesnoth/commit/86746aaaf094ece1540d143c8d58c8f9e551e243
20160227 01:01:39-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160227 01:02:27-!- ancestral [~ancestral@8.sub-70-197-237.myvzw.com] has quit [Quit: i go nstuf kthxbai]
20160227 01:02:39< vultraz> celticminstrel: actually it's almost 3 seconds
20160227 01:03:09< celticminstrel> I'm trying to locate the point at which composite aspects (and stages, goals, and engines) are parsed.
20160227 01:04:44< celticminstrel> ...okay, so the engine itself is responsible for at least the latter three. This fits with what I knew already.
20160227 01:04:58< celticminstrel> Uh, sorry. It's responsible for stages, at least.
20160227 01:05:20< celticminstrel> And goals.
20160227 01:05:53< celticminstrel> Ah, I guess the engine is also responsible for parsing its own declaration.
20160227 01:06:28< celticminstrel> Huh, the Lua engine doesn't seem to support that, though.
20160227 01:07:05< celticminstrel> Or maybe XCode's indexing is just broken.
20160227 01:10:58-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20160227 01:12:20< celticminstrel> It kinda looks like [engine] tags for Lua have no effect whatsoever...
20160227 01:14:18< celticminstrel> In fact, it looks like the engine constructor is always passed a config containing two keys: name=cpp|fai|lua and engine=cpp.
20160227 01:14:51< celticminstrel> There's a separate method for parsing the actually provided config, but the Lua engine doesn't implement it.
20160227 01:17:00-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160227 01:20:17< celticminstrel> Okay, so adding a Lua engine tag causes the game to crash. Wonderful.
20160227 01:21:14< celticminstrel> Probably due to the lack of the [data] subtag.
20160227 01:21:22< celticminstrel> Still, that shouldn't cause a crash.
20160227 01:32:46< celticminstrel> The specific error is "attempt to index a nil value".
20160227 01:37:20< celticminstrel> Does anyone know how to deal with this?
20160227 01:37:34< celticminstrel> I don't think pcall applies to this situation. Should I use lua_atpanic?
20160227 01:38:20< celticminstrel> There used to be something called lua_cpcall. Maybe that's the correct approach.
20160227 01:40:17< celticminstrel> ...or I could just check that the offending value isn't nil before using it. Duh.
20160227 01:52:20< celticminstrel> On an unrelated note, does anyone have any ideas about what FAI could stand for? Something unrelated to artificial intelligence?
20160227 01:55:13< celticminstrel> Okay, so somehow, the [engine]name=lua tag does work...
20160227 01:56:02< celticminstrel> (Another unrelated note - the gamestate inspector has problems. Can we perhaps force it fullscreen?)
20160227 01:56:04< celticminstrel> vultraz: ^
20160227 01:56:12< mattsc> celticminstrel: umm, FAI = Formula AI ?
20160227 01:56:25< celticminstrel> mattsc: I know.
20160227 01:56:39< celticminstrel> I'm proposing redefining the acronym.
20160227 01:56:56< mattsc> Oh, I see.
20160227 01:57:19< mattsc> Fertiliser Association of India
20160227 01:57:26< celticminstrel> Ha ha.
20160227 01:57:37< mattsc> It’s also the airport code for Fairbanks, AK
20160227 01:57:37-!- trewe [~trewe@bl20-20-15.dsl.telepac.pt] has quit [Quit: quit]
20160227 01:57:48< vultraz> Federal AI Inspector? 
20160227 01:57:48< celticminstrel> For some reason, the inspector shows the main_loop stage twice...
20160227 01:58:04< celticminstrel> I wonder if this has anything to do with my new parsing.
20160227 01:58:16< mattsc> It does not for me in 1.12
20160227 01:59:01< mattsc> Btw, I’m not joking: celticminstrel: in any case, I don’t really have anything to contribute to the other 
20160227 01:59:12< mattsc> umm, but I can’t cut and paste.
20160227 01:59:17< mattsc> Let’s try that again:
20160227 01:59:38< mattsc> Btw, I’m not joking: http://www.faidelhi.org/
20160227 02:00:00< mattsc>  celticminstrel: in any case, I don’t really have anything to contribute to the other things you mentioned
20160227 02:01:29< celticminstrel> Non-AI sides have no engines defined but do have all the aspects.
20160227 02:01:45< celticminstrel> vultraz: About the gamestate inspector, is that possible?
20160227 02:01:49< vultraz> yes
20160227 02:01:51< vultraz> will do in a second
20160227 02:02:19< celticminstrel> When first opened, it's all scrunched up in the corner, with the type list tiny and scrolling.
20160227 02:02:48< celticminstrel> (I'm at 800x600 because I figure that, when testing, it's best to use the smallest size people are likely to use.)
20160227 02:02:59< celticminstrel> (Normally I make it at least 1024x768.)
20160227 02:10:48< irker515> wesnoth: Charles Dang wesnoth:master 6b827e68d494 / data/gui/default/ (macros/_initial.cfg window/lobby_main.cfg window/title_screen.cfg): GUI2: added a macro for fullscreen window layout settings https://github.com/wesnoth/wesnoth/commit/6b827e68d49481aa37467d98db0c8a01efad282a
20160227 02:10:51< irker515> wesnoth: Charles Dang wesnoth:master 9afb987574be / data/gui/default/window/gamestate_inspector.cfg: tgamestate_inspector: display as fullscreen window and adjusted layout as releva https://github.com/wesnoth/wesnoth/commit/9afb987574be72504ba1f8a6c6c9ab23613c5909
20160227 02:10:54< vultraz> celticminstrel: ^
20160227 02:11:00< vultraz> see how that works for you
20160227 02:11:17< vultraz> I also made it so the contents area won't horizontally shrink the listboxes
20160227 02:13:10< celticminstrel> Anyone object to splitting up the AI config in the inspected by component type?
20160227 02:13:15< celticminstrel> ^inspector
20160227 02:13:36< vultraz> not I
20160227 02:17:13< celticminstrel> I'll try out the fullscreen inspector a bit later; it would require me to switch branches and/or rebase.
20160227 02:18:22< vultraz> ok
20160227 02:25:46-!- prkc [~prkc@563BD80A.dsl.pool.telekom.hu] has quit [Remote host closed the connection]
20160227 02:27:33-!- Appleman1234 [~Appleman1@KD106161141247.au-net.ne.jp] has quit [Ping timeout: 240 seconds]
20160227 02:30:01< Aginor> mattsc: no, you didn't. I'll have a look
20160227 02:37:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160227 02:37:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160227 02:39:29< irker515> wesnoth: Charles Dang wesnoth:master 0eb6d2866446 / images/editor/brush.png: Improve look of editor brush https://github.com/wesnoth/wesnoth/commit/0eb6d28664462669c082698593981e2ad80a9433
20160227 02:39:32< irker515> wesnoth: Charles Dang wesnoth:master 7115b5010259 / src/editor/editor_display.cpp: editor: fixed editor having two hex overlays drawing over each other https://github.com/wesnoth/wesnoth/commit/7115b501025965c1f46c1606e70e362bc206cd96
20160227 02:46:13< irker515> wesnoth: Charles Dang wesnoth:master d5b20f9c2102 / images/editor/selection-overlay.png: Apply slight tint behind editor selection overlay https://github.com/wesnoth/wesnoth/commit/d5b20f9c210281d4ae047cdbdd0a22abcd252e0f
20160227 02:55:02< mattsc> celticminstrel: no objections
20160227 02:55:08< mattsc> Aginor: thanks
20160227 02:55:30< vultraz> celticminstrel: opinion? https://www.dropbox.com/s/x9pqdkxiugu57js/status_orbs_friendslist.PNG?dl=0
20160227 02:55:37< vultraz> (for friends list icons)
20160227 03:09:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 244 seconds]
20160227 03:09:51-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160227 03:21:51< mattsc> celticminstrel: do you think that I really need to explain all these functions?  https://wiki.wesnoth.org/LuaAI#Functions_Returning_Other_Game_State_Information
20160227 03:37:26< celticminstrel> So, I think I figured out how engines work - the engine isn't responsible for parsing its own [engine] tag. Instead, the cpp engine is responsible for parsing [engine] tags. (But, in theory, maybe you could have additional engines that are created by some other engine, ie something [engine]engine=lua - probably not very useful, though.)
20160227 03:37:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160227 03:42:02< celticminstrel> vultraz: I'm not entirely sure why I can view shadowm's dropbox pictures and not yours. Something's different about how he posts the links. Your links take me to an HTML page, but he posts a direct link to the image.
20160227 03:42:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20160227 03:42:21< vultraz> agh
20160227 03:42:22< vultraz> sorry
20160227 03:42:24< vultraz> I forgot again
20160227 03:42:47< celticminstrel> mattsc: If the inspector view is split up by component type, do you thing there's any point in keeping the "ai config full" view?
20160227 03:43:12< celticminstrel> vultraz: You can answer that too.
20160227 03:43:23< vultraz> celticminstrel: he uses the obsolete Public folder
20160227 03:43:35< vultraz> celticminstrel: can you see this? https://dl.dropboxusercontent.com/u/95558676/current_inventory.png
20160227 03:43:40< celticminstrel> mattsc: And about the functions, without having looked at them I would suggest at least a sentence for each function.
20160227 03:43:56< vultraz> celticminstrel: also, I don't think so, to answer your question
20160227 03:43:59 * celticminstrel will look at them in a second.
20160227 03:44:11 * celticminstrel wrote thing instead of think. Ugh.
20160227 03:44:17< mattsc> celticminstrel: I assumed that you’d replace the “ai config full” view with “full” views for each config.
20160227 03:44:25< celticminstrel> vultraz: Yes, I can see that.
20160227 03:44:50< vultraz> celticminstrel: ok, so then he does indeed link thinks from the obsolete public folder
20160227 03:45:01< mattsc> *for each component
20160227 03:45:02< celticminstrel> mattsc: Well, what I did right now is literally just split up the "ai config full" view - one view takes just the stage tags, another just the aspect tags, etc.
20160227 03:45:29< mattsc> yes, that’s what I thought and I think that’s good
20160227 03:45:32< celticminstrel> So it's the same content, just split up. (And without any attributes.)
20160227 03:45:50< celticminstrel> (I think the only attributes were id and description, anyway.)
20160227 03:45:53< mattsc> it’s kind of a PITA to have to scroll through all the CAs first to get to the aspects
20160227 03:46:28< celticminstrel> mattsc: Again, about the functions - I don't think they're obvious enough from the name to leave them unexplained.
20160227 03:46:39< mattsc> celticminstrel: as for the functions, adding a sentence each is not a problem (well, I need to figure out what all of them do first, but …)
20160227 03:46:48< mattsc> but do I need to explain the output format etc.?
20160227 03:46:58< celticminstrel> You mean, what they return?
20160227 03:47:03< mattsc> yes
20160227 03:47:11< celticminstrel> That's kind of essential, yeah.
20160227 03:47:30< mattsc> also, they are clearly not finished (or at least they weren’t last time I checked)
20160227 03:47:37< celticminstrel> Hm?
20160227 03:47:50< mattsc> for example, at least in some cases, dst_src is the same as src_dst
20160227 03:48:25< celticminstrel> I'm not entirely sure what that means.
20160227 03:48:38< mattsc> yep, I know  ;)
20160227 03:48:48< mattsc> so I’d have to explain it  :P
20160227 03:49:14< celticminstrel> Is it supposed to be the same in those cases?
20160227 03:49:18< mattsc> they are movemaps, contain destination and source for all possible moves
20160227 03:49:36< celticminstrel> Hmmm.
20160227 03:49:41< mattsc> dst_src is supposed to be indexed by destination first, then source; src_dst the other way around
20160227 03:49:45< mattsc> but they aren't
20160227 03:50:10< mattsc> the C++ code exposing these to Lua just uses one for the other
20160227 03:50:37< celticminstrel> So, there's basically two things there - get_new_* and is_*_valid.
20160227 03:50:45< celticminstrel> What do those each do?
20160227 03:50:55< mattsc> don’t remember
20160227 03:51:12< mattsc> the thing is, I am very certain that nobody has ever used them
20160227 03:51:23< mattsc> I tried to use them for a while and found them useless
20160227 03:51:35< mattsc> and I’m probably the only one who ever tried
20160227 03:51:42< celticminstrel> So are you saying we could probably just remove them?
20160227 03:51:54< mattsc> nobody would cry over that, yes
20160227 03:52:00< celticminstrel> They sound like something that could be better exposed some other way.
20160227 03:52:09< mattsc> on the other hand, they probably have the potential of being useful
20160227 03:52:39< mattsc> nephro did something to make them more usable, but by that time I had my own methods already, so I never tested them
20160227 03:52:45< celticminstrel> Well, what I was thinking is removing them, but then exposing the same info some other way. I'll look at it at some point.
20160227 03:53:08< mattsc> well, the structures (?) behind them are being used in the C++ code
20160227 03:53:24< mattsc> it’s just that the way they were exposed to Lua was not particularly useful
20160227 03:53:26< celticminstrel> Yeah, I think I saw C++ versions of the functions somewhere.
20160227 03:53:46< celticminstrel> Grepping the data dir shows they seem to be defined in ai_helper?
20160227 03:53:56< celticminstrel> Wait no, those're different.
20160227 03:54:00< mattsc> well … not really
20160227 03:54:06< celticminstrel> That's get_src_dst_units. Sorry.
20160227 03:54:13< celticminstrel> ^dst_src
20160227 03:54:25< mattsc> I tried originally to replicate what those functions do in ai_helper
20160227 03:54:31< mattsc> but I later abandoned that too
20160227 03:55:02-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160227 03:55:56< mattsc> so, point being, I’m not particularly inclinded to spend much effort on describing them since I don’t believe anybody will ever use them
20160227 03:56:19< celticminstrel> What's with this dummy_engine_lua thing...
20160227 03:56:31< mattsc> celticminstrel: how about I say there are other functions available, use debug tools to see what they are, and if you ever feel you need them, let’s talk?
20160227 03:56:38< mattsc> the dummy_engine is needed
20160227 03:56:40< celticminstrel> Sure.
20160227 03:57:01< celticminstrel> I get that it's needed, but why is it needed?
20160227 03:57:18< mattsc> that’s nephro’s workaround for not having to define a Lua engine any more
20160227 03:57:32< mattsc> if no Lua engine is defined, it uses that one
20160227 03:57:45< celticminstrel> I can see that.
20160227 03:58:10< mattsc> I always thought that that was a workaround rather than a solution of the root cause, but then, what do I know
20160227 03:58:17< mattsc> about C++, I mean
20160227 03:58:44< mattsc> I’m not sure if that answered yoour question
20160227 03:59:04< mattsc> You used to need to define a Lua engine if you wanted to use Lua CAs.
20160227 03:59:11< mattsc> Now you don’t need to do that any more.
20160227 03:59:23< celticminstrel> It includes stdlib.lua which includes cache.lua... what the heck is all this stuff...
20160227 03:59:27< mattsc> But the way it is done is by having Wesnoth insert the dummy engine instead.
20160227 04:00:54< celticminstrel> Okay, so the AI table is in fact passed as an argument (or upvalue, whatever) to the [engine] code.
20160227 04:01:02< celticminstrel> The dummy engine does... something... to it and returns it.
20160227 04:01:31< celticminstrel> (Actually that something seems to replace those functions we were talking about with slightly different ones.)
20160227 04:01:38< mattsc> yes, it adds some of those dst_src and debug etc. functions to it
20160227 04:01:51< mattsc> but to be honest, I kind of dropped the ball on keeping up with that recently.
20160227 04:02:31< mattsc> I need to go and read about goats and dragons and wizards for a little while …
20160227 04:02:41< celticminstrel> So instead of get_new_* and is_*_valid, you call simply get_*
20160227 04:03:08< mattsc> bbl
20160227 04:03:10< celticminstrel> 'kay
20160227 04:16:57< mattsc> Short intermezzo, while the wizard put a magical rope around the fire dragon ...
20160227 04:17:20-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160227 04:17:24< mattsc> celticminstrel: the backgorund behind all this is this:
20160227 04:17:32 * celticminstrel has no idea what this thing about dragons is.
20160227 04:18:44< mattsc> one of the reasons why the dst_src tables are mostly useless is because they don’t adapt to the AI evaluation moving units around on the map during evaluation
20160227 04:19:07< mattsc> what you really need to know is “what would happen if I moved this unit over there”?
20160227 04:19:36< mattsc> the new_dst_src and is_valid etc. functions were nephro’s attempt to account for that
20160227 04:20:10< mattsc> but quite honestly, I don’t know if they are all finsihed and never used them myself
20160227 04:20:17< mattsc> so I don’t know what the exact staus is
20160227 04:20:28< celticminstrel> Do you know what's actually in these tables?
20160227 04:20:39< celticminstrel> I can probably find out from the source if you don't.
20160227 04:21:02< mattsc> in some of them, I do, yes.
20160227 04:21:23< celticminstrel> Only some? They're not all the same sort of data?
20160227 04:21:45< mattsc> they probably are, but not for sure
20160227 04:22:00< mattsc> they are tables like:
20160227 04:22:48-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has joined #wesnoth-dev
20160227 04:23:34< mattsc> { [1] = 12, [2] = 5, { [1] = { [1] = 3, [2] = 3} } , { [2] = { [1] = 3, [2] = 4 }, [3] = …
20160227 04:23:59< mattsc> meaning, the unit at 12,5, can move to 3,3 and 3,4 and …
20160227 04:24:05< mattsc> that kind of stuff
20160227 04:24:12-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160227 04:24:21< celticminstrel> So uh...
20160227 04:24:26< mattsc> :D
20160227 04:24:37 * celticminstrel tries to parse the nested braces.
20160227 04:24:54< mattsc> I might have screwed up some of the brackets ...
20160227 04:25:15< celticminstrel> They're array-like tables, not dictionary-like tables?
20160227 04:25:19< mattsc> It contains the coordinates for a unit, and then an array of coordinates where it can go; for all units
20160227 04:25:22< celticminstrel> ie, consisting of sequential numeric keys.
20160227 04:25:25< mattsc> yes, I think so
20160227 04:26:20< celticminstrel> It probably would've been easier to read if you'd used array format (omitting the [1] = and such)... though, with the level of nesting, I could be wrong.
20160227 04:26:31< celticminstrel> I get the general idea though, I think.
20160227 04:29:40< celticminstrel> I need to figure out why the main_loop stage is duplicated...
20160227 04:29:47< mattsc> celticminstrel: http://imgur.com/r7LEWaG
20160227 04:30:26< mattsc> so, I wasn’t quite right, but same general principle.
20160227 04:30:44< mattsc> that’s ai.get_new_src_dst()
20160227 04:36:40< mattsc> is that easier to read?
20160227 04:37:06< celticminstrel> I'll tell you once Firefox starts responding.
20160227 04:37:22< mattsc> I see …
20160227 04:37:50< mattsc> It seems to be in location_set format, which I vaguely remember
20160227 04:38:09< mattsc> as in, I vaguely remember that it was switched to that
20160227 04:44:26< celticminstrel> I just pushed all my stuff, AI or otherwise.
20160227 04:47:12< mattsc> sounds exciting
20160227 04:49:26< celticminstrel> Maybe.
20160227 04:55:40< celticminstrel> o.o
20160227 04:55:50< celticminstrel> What the heck is that 198612 thing?
20160227 04:56:18< mattsc> position of the unit in location set format
20160227 04:56:25< celticminstrel> Eh?
20160227 04:56:41< celticminstrel> Oh, wait, are there just that many elements in the table?
20160227 04:56:48< mattsc> 2^15 basis or something
20160227 04:56:55< celticminstrel> So this is a really huge table?
20160227 04:57:19< mattsc> https://github.com/wesnoth/wesnoth/blob/master/data/lua/location_set.lua
20160227 04:57:22< ancestral> celticminstrel: Or something important happened in December 1986
20160227 04:57:24< mattsc> no
20160227 04:57:28< ancestral> :-P
20160227 04:57:40< celticminstrel> Heh.
20160227 04:57:56< celticminstrel> I've seen location_set.lua before but never looked very closely.
20160227 04:58:04 * ancestral likes Wesnoth conspiracies
20160227 04:58:51< celticminstrel> Okay, so if you have a location_set L, you're supposed to index it as L[location_set.index(x,y)]. Weird, but whatever.
20160227 04:59:08< mattsc> if you ignore the specifics, it’s just a way to use a single index for 2-dim coordinates
20160227 05:01:39< celticminstrel> I don't see why this is needed, honestly. Just implement the __call metafunction to take X and Y.
20160227 05:01:54< celticminstrel> ...actually, that would be a good addition to location_set.lua...
20160227 05:02:53< mattsc> I don’t know what that means
20160227 05:03:15< celticminstrel> Do you know what revindex is for?
20160227 05:03:43< mattsc> yes
20160227 05:05:07< ancestral> Hmm
20160227 05:05:14< celticminstrel> Ah, it has get which does the same thing as my hypothetical __call, so I guess that's fine.
20160227 05:05:18< ancestral> I feel like half the bugs in Gna could be closed
20160227 05:05:27< ancestral> for Wesnoth
20160227 05:05:29< celticminstrel> Might be clearer.
20160227 05:05:59< celticminstrel> ancestral: Oh?
20160227 05:06:01-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160227 05:06:04< ancestral> Bug with Python AI
20160227 05:06:10< ancestral> Probably should be “Won’t Fix” :-P
20160227 05:06:22< celticminstrel> Yeah, anything about Python can be closed as Won't Fix.
20160227 05:06:33< ancestral> “Wesnoth will not start on OS 10.3.2”
20160227 05:06:34< celticminstrel> Since that was apparently removed for security reasons at some point.
20160227 05:06:37< ancestral> Yep
20160227 05:06:43< mattsc> sometimes I want to have a table where you can find either “all untis that can get to a certina hex” or “all hexes that a certain unit can get to”
20160227 05:06:49< celticminstrel> I think it officially supports back to 10.6 now?
20160227 05:07:04< ancestral> Yes, my point is some of these bugs are so irrelevant
20160227 05:07:10< mattsc> and it needs to be fast, so you don’t want to search through Lua tables of 2 (or 4) indiices
20160227 05:07:21< ancestral> Wait
20160227 05:07:25< ancestral> Maybe I’m looking at closed ones
20160227 05:07:26< mattsc> so that’s what you can do with location sets
20160227 05:07:44< celticminstrel> mattsc: As for what that means - if you put a function named __call in the metatable (right beside __index), then that function will be called if you try to use the table as a function.
20160227 05:07:56< celticminstrel> So, if that was there, you could write L(x,y) instead of L:get(x,y).
20160227 05:08:03< mattsc> (btw, I have mu own version of that functionality now, but same principle)
20160227 05:08:14< celticminstrel> Your own version of location sets?
20160227 05:08:24< mattsc> yes, essentially
20160227 05:08:28< celticminstrel> Why?
20160227 05:08:38< mattsc> but I do use location sets occasionally too
20160227 05:09:03< mattsc> because, as you say, what the hell is 198612?
20160227 05:09:19< celticminstrel> So what's different about your version?
20160227 05:09:27< mattsc> wheras if it is 16002 for coordinates 16,2, I can understand that from just looking at it
20160227 05:09:37< mattsc> so I use base 1000, rather than base 2^14
20160227 05:10:01< mattsc> I also don’t need all the LS functions
20160227 05:10:06< celticminstrel> Or you could implement the __tostring metafunction.
20160227 05:10:13< ancestral> Hmm https://gna.org/bugs/?5915
20160227 05:10:34< celticminstrel> How did you get that output, by the way?
20160227 05:10:42< celticminstrel> From the screenshot, I mean.
20160227 05:10:49< mattsc> Wesnoth Lua pack debug_utils
20160227 05:10:58< celticminstrel> Oh.
20160227 05:11:15< mattsc> debug_utils.dbms — best utility function ever written
20160227 05:11:31 * celticminstrel goes look
20160227 05:11:44-!- Kwandulin [~Miranda@p200300760F0BC5B71DF0341711DF01AA.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160227 05:16:37< celticminstrel> I suspect implementing __tostring wouldn't affect debug_utils.dbms.
20160227 05:17:31< celticminstrel> I wonder if adding a userdata location type would actually be useful.
20160227 05:17:51< celticminstrel> Currently locations are exposed as simple tables, either {3,4} or {x=3,y=4}.
20160227 05:26:06< mattsc> if I understand this correctly, I think it probably would be
20160227 05:26:40< celticminstrel> I think userdata is represented by address, which of course is guaranteed to be unique.
20160227 05:32:47< celticminstrel> Though I dunno how it would compare in efficiency.
20160227 05:39:38< celticminstrel> If loc is a userdata, then loc.x or loc[1] means invoking the __index function which is implemented in C++.
20160227 05:39:47< celticminstrel> (Or __newindex, if you're assigning.)
20160227 05:46:22-!- irker515 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160227 05:48:38< celticminstrel> mattsc: I was wondering earlier, would it be possible to create eg a [goal]name=target using the Lua engine, or can the Lua engine only handle [goal]name=lua_goal?
20160227 05:49:01< ancestral> Speaking of tooltips earlier, this would still be good to have: https://gna.org/bugs/?5162
20160227 05:49:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160227 05:52:04< celticminstrel> Agreed.
20160227 05:52:33< mattsc> celticminstrel: I think the latter, but that’s not how the goals are handled internally but the MtT Ca anyway
20160227 05:52:50< celticminstrel> Hm?
20160227 05:53:34< mattsc> the types of targets are these:  https://github.com/wesnoth/wesnoth/blob/master/src/ai/default/contexts.hpp#L41
20160227 05:53:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160227 05:54:03< celticminstrel> I think I was looking in that file a few hours ago.
20160227 05:54:10< mattsc> the [goal] types of targets get translated to those, so do the Lua targets
20160227 05:54:38< mattsc> So, [goal]name=target is type EXPLICIT
20160227 05:54:50< mattsc> [goal]name=protect_something is THREAT
20160227 05:55:05< mattsc> and for lua_goals, you just use the enum number directly
20160227 05:55:18< mattsc> that’s at least my interpretation of what’s going on
20160227 05:55:18< celticminstrel> Oh! I thought [goal] always produced EXPLICIT targets.
20160227 05:56:05< mattsc> maybe it does; but protect_targets are handled differently from others; so I think it’s the threat type of target
20160227 05:56:13< mattsc> I really don’t know, tbh
20160227 05:56:27< celticminstrel> I'll see if I can find out from the code.
20160227 05:56:54< mattsc> okay; I’m probably going to sign off soon for tonight
20160227 05:57:58< mattsc> actually, I think you’r eright
20160227 05:58:24< mattsc> it’s just that how the targets are calculated (they’re just locations, when it comes down to it), is different
20160227 05:58:39< mattsc> So lua_goals are actually more versitle than [goal] tag goals
20160227 05:58:44< mattsc> (assuming this is right)
20160227 05:58:57< celticminstrel> Well, lua_goal is a [goal] tag though. :P
20160227 05:59:16< mattsc> well, alright …
20160227 05:59:30< mattsc> more versatile than the other uses, maybe?  :P
20160227 05:59:37< celticminstrel> Sure?
20160227 05:59:59< mattsc> in that you can assign it any of those enum types
20160227 06:00:16< celticminstrel> cpp goals are taken from the AI registry, so each type is a different class...
20160227 06:00:27< mattsc> https://wiki.wesnoth.org/LuaAI#Goals_and_targets
20160227 06:00:31< celticminstrel> 5 in total, counting protect_my_unit
20160227 06:00:42< ancestral> Hmm
20160227 06:00:50< ancestral> We can’t open maps in the editor from saved games???
20160227 06:00:51< celticminstrel> Now XCode is beachballing...
20160227 06:01:06< ancestral> “Error loading map”
20160227 06:01:11< mattsc> the type= key for lua_goals can be set to any of those
20160227 06:01:19< celticminstrel> That's because it's not a map, I assume?
20160227 06:01:31< celticminstrel> It's a saved game which happens to contain a map embedded in it.
20160227 06:01:47< ancestral> Might be nice to be able to extract that map
20160227 06:02:08< mattsc> celticminstrel: anyways, have fun with this  ;)  I’m off for now
20160227 06:02:08< ancestral> https://gna.org/bugs/?6893
20160227 06:02:48< celticminstrel> ...oh, Lua goals come from the registry too.
20160227 06:02:50< vultraz> ancestral: btw, was that bug blocking you from working on the trailer fixes?
20160227 06:02:52< vultraz> fixed
20160227 06:03:02< ancestral> vultraz: Let me see
20160227 06:03:40< ancestral> I’ll rebuild one moment
20160227 06:04:45-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160227 06:06:20< celticminstrel> So basically, if you use the wrong engine for your goal, the goal is simply ignored.
20160227 06:14:44< ancestral> vultraz: Still crashes
20160227 06:15:02< ancestral> I have four days off Sun through Wed; I can try to work around it, it’s just going to take me longer, because it means I have to stick to single player
20160227 06:16:39< vultraz> ancestral: can't you load the mp replay from the titlescreen?
20160227 06:17:56< ancestral> No, it crashes'
20160227 06:18:03< vultraz> whut?
20160227 06:18:04< ancestral> Feel free to try
20160227 06:18:26< vultraz> can you send me one
20160227 06:18:30< vultraz> I don't have an mp replay
20160227 06:18:31< ancestral> Sure
20160227 06:18:34< ancestral> I mean
20160227 06:18:45< ancestral> You can just start a multiplayer local game
20160227 06:18:54< ancestral> Move a unit, end move a unit end
20160227 06:18:56< ancestral> Save
20160227 06:19:02< ancestral> (as replay)
20160227 06:19:10< ancestral> But I’ll do it for hyou
20160227 06:19:34< vultraz> no it's alright
20160227 06:19:49< vultraz> I forgot there was that Save as Replay thing
20160227 06:20:14< vultraz> ancestral: it loads fine in the titlescreen for me
20160227 06:20:22< ancestral> Okay, now play it
20160227 06:20:41< vultraz> it works fine
20160227 06:20:58< vultraz> it does assert if you click the Stop button, though
20160227 06:21:45< vultraz> still asserts when loading the replay from the mp Load Game, though
20160227 06:22:14< ancestral> Yes
20160227 06:22:17< ancestral> The stop button
20160227 06:23:05< ancestral> I do have a replay that crashes immediately
20160227 06:23:10< ancestral> Let me send that to you
20160227 06:23:12< ancestral> I’ll paste it actually
20160227 06:23:16< ancestral> maybe
20160227 06:25:22< ancestral> vultraz: http://mproud.com/wesnoth/3p_Morituri_replay.gz
20160227 06:25:32< vultraz> we should disable movement reach during replays
20160227 06:25:43< vultraz> it gives the impression you can move the units (when you can't)
20160227 06:26:32< ancestral> But yeah, kind of like the FR from ~10 years ago that asked for being able to open save game [and replay] maps in the editor
20160227 06:27:26< vultraz> hmm
20160227 06:27:30< vultraz> yes, that does crash
20160227 06:28:38< ancestral> vultraz: https://gna.org/bugs/?13248
20160227 06:28:42< vultraz> ancestral: if I make my own replay of the same game it does not crash
20160227 06:28:47< vultraz> (3p Morituri)
20160227 06:28:58< ancestral> So what’s different I wonder
20160227 06:29:11< vultraz> ancestral: try making a new replay of your own and see if it crashes
20160227 06:29:34< ancestral> You know it’s possible that replay could have been from 1.12
20160227 06:29:36< celticminstrel> I guess mattsc was right - protect goals are type THREAT.
20160227 06:29:38< ancestral> I’m not positive though
20160227 06:30:37< vultraz> no, the version string says 1.13.2..
20160227 06:31:43< ancestral> vultraz: http://mproud.com/wesnoth/3p_Morituri_replay-2.gz
20160227 06:31:48< vultraz> ancestral: why are you linking me that bug?
20160227 06:32:03< ancestral> You’re working on the preferences window, right?
20160227 06:32:19< vultraz> yes, but that sounds like it's a gui1 issue
20160227 06:32:27< ancestral> Ah okay
20160227 06:32:33< ancestral> vultraz: So my Morituri
20160227 06:32:37< vultraz> ancestral: crashes :|
20160227 06:32:40< ancestral> It has only AI players
20160227 06:32:48< ancestral> That may be the difference
20160227 06:33:11< ancestral> Why that should matter, I don’t know
20160227 06:33:53< vultraz> ancestral: ahhh
20160227 06:33:59< vultraz> yes, now I can reproduce the crash on my own
20160227 06:34:25< celticminstrel> So replays with all AI players have problems?
20160227 06:34:48< vultraz> yes
20160227 06:35:13< ancestral> Updated the bug
20160227 06:35:25< ancestral> https://gna.org/bugs/index.php?24439
20160227 06:35:27< celticminstrel> Try one where player 1 is AI and player 2 is human.
20160227 06:36:12< ancestral> Okay
20160227 06:36:54< vultraz> does not crash
20160227 06:37:19< ancestral> It loads
20160227 06:37:26< ancestral> click continuous replay
20160227 06:37:55< celticminstrel> You could update the bug summary.
20160227 06:38:01< ancestral> Click stop eventually and of course it crashes. src/game_events/pump.cpp, line 499
20160227 06:39:57< ancestral> Okay, done
20160227 06:41:58-!- Appleman1234 [~Appleman1@KD106161141247.au-net.ne.jp] has joined #wesnoth-dev
20160227 06:43:52< ancestral> Oh hey
20160227 06:45:30< ancestral> Anyone who is willing, please try my Simple Hot Keys and see how it works for you
20160227 06:46:01-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160227 06:46:47< ancestral> ‘r’ recruits (no control needed); ‘e’ recalls (no alt-r needed); ‘h’ lets the unit hold
20160227 06:47:05< ancestral> Honestly I don’t know why ‘h’ doesn’t tell the unit to hold already
20160227 06:47:35< celticminstrel> What's "hold"?
20160227 06:47:39< vultraz> it works
20160227 06:47:44< ancestral> http://files.wesnoth.org/addons/1.13/Simple_Hot_Keys.tar.bz2
20160227 06:47:50< ancestral> celticminstrel: Tell the unit to stay
20160227 06:47:57< ancestral> Like fortify, or sleep
20160227 06:48:00< celticminstrel> Ah.
20160227 06:48:26< ancestral> I supose it could be changed to ‘F’ as in fortify
20160227 06:48:30< ancestral> *suppose
20160227 06:48:36< celticminstrel> So it's as if you select it at the beginning of every turn and press... what was it... n? Or space?
20160227 06:48:41< celticminstrel> I think it was space.
20160227 06:48:50< ancestral> Many games space, yeah
20160227 06:49:04< ancestral> I suppose we could do that in Wesnoth
20160227 06:49:08< celticminstrel> "many games"? I'm talking about Wesnoth.
20160227 06:49:13< celticminstrel> The default hotkeys.
20160227 06:49:28< ancestral> Wait, is it?
20160227 06:49:44< celticminstrel> There's a hotkey that marks the unit as "moved" even if its movement points aren't depleted, then cycles to the next unit.
20160227 06:49:46< ancestral> shift+space
20160227 06:49:47< ancestral> YUCK
20160227 06:49:55< celticminstrel> I think it's space.
20160227 06:50:09< celticminstrel> I was saying it's like selecting the unit and doing that at the beginning of each turn.
20160227 06:50:26< celticminstrel> So, it's marked as moved so that cycling through units excludes it, but if you want you can select it and move it.
20160227 06:51:03< ancestral> celticminstrel: It’s shift+space by default
20160227 06:51:18< celticminstrel> I see.
20160227 06:51:20< ancestral> celticminstrel: Correct
20160227 06:51:23< celticminstrel> I guess that sort of makes sense.
20160227 06:51:36< celticminstrel> Since it's related to the function assigned by default to space.
20160227 06:52:12< ancestral> https://r.wesnoth.org/p580036
20160227 06:52:39< ancestral> Common actions should not need a shift, option or control key to press
20160227 06:54:09< celticminstrel> I think tab and shift-tab would be good for next/previous unit.
20160227 06:54:34< ancestral> Tab is used to speak messages in many games
20160227 06:54:45< celticminstrel> BTW, is F assigned in the hotkeys, or is that hardcoded?
20160227 06:54:54< celticminstrel> Really?
20160227 06:55:05< celticminstrel> I see you've assigned it to L though.
20160227 06:55:09< ancestral> I don’t see ‘F’ assigned
20160227 06:55:12< celticminstrel> Wait no.
20160227 06:55:19< ancestral> celticminstrel: It’s totally possible to assign multiple keys to the same action
20160227 06:55:26< celticminstrel> That's chat log, which is different.
20160227 06:55:34< celticminstrel> I guess you haven't reassigned chat then.
20160227 06:55:49< celticminstrel> F brings up the "formula command prompt".
20160227 06:55:49< ancestral> Yeah, I “extended” it
20160227 06:56:03< ancestral> Run formula, you’re right
20160227 06:56:06< ancestral> Which I mean
20160227 06:56:12< ancestral> How often does anyone use that?
20160227 06:56:20< celticminstrel> Probably never.
20160227 06:56:24< ancestral> Heh
20160227 06:56:33< celticminstrel> Maybe scenario designers occasionally do.
20160227 06:57:00< celticminstrel> But I don't think it's actually very useful for testing scenarios.
20160227 06:57:12< ancestral> So that would be an example of ctrl+F maybe being better for it, leave ‘F’ for more common functions
20160227 06:57:15< ancestral> *actions
20160227 06:57:44< celticminstrel> Formulas in your scenario (whether AI or unit filters) generally have access to a lot of variables which the formula prompt doesn't provide access to.
20160227 06:57:47< ancestral> Anyway, my hot keys tries to preserve as much as reasonably makes sense
20160227 06:58:04< celticminstrel> If it evaluated the formula in the context of the currently hilited unit, then perhaps it would be useful.
20160227 06:58:18 * celticminstrel would have no objection to making it Ctrl+F.
20160227 06:58:34< celticminstrel> I might actually implement that change sometime.
20160227 06:58:43< celticminstrel> Not the hotkey change, the other one.
20160227 06:59:39< celticminstrel> Huh, I didn't even know Go To Leader was a thing. Does it cycle through leaders if there's more than one?
20160227 06:59:47< ancestral> That’s a great question
20160227 07:04:47< celticminstrel> I think I basically understand how AI components work now.
20160227 07:46:46< iceiceice> fwiw i think the formula feature is quite rarely used
20160227 07:46:56< iceiceice> from what i understand, malformed formulas can crash the game
20160227 07:47:24< celticminstrel> I've been fiddling with them a little recently, and it hasn't crashed.
20160227 07:47:44< iceiceice> I think Ravana pointed out some assert in the formula parser
20160227 07:47:46< celticminstrel> I think that might've been fixed at some point. (It was probably just an uncaught exception somewhere, anyway.)
20160227 07:47:47< iceiceice> recently
20160227 07:47:48< iceiceice> i cant remember
20160227 07:48:08< celticminstrel> Ravana did point out an exception in the formula parser today. (Or yesterday?)
20160227 07:48:21< celticminstrel> I don't recall him pointing out an assert, but I could look at it at some point.
20160227 08:31:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160227 08:35:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160227 08:42:24< Ravana_> iceiceice, celticminstrel: I pointed out the result I got when I searched git for "illegal unary"
20160227 08:43:28-!- vultraz changed the topic of #wesnoth-dev to: 1.13.3 scheduled for Friday, March 4th | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160227 08:44:04< celticminstrel> I wonder if we can make the deadline this time. >_>
20160227 08:45:51< vultraz> let's get guifixes merged this weekend
20160227 08:46:04< vultraz> we'll have next week to test and hopefully the blocker bug can be fixed
20160227 08:46:20-!- celticminstrel is now known as celmin|sleep
20160227 08:55:42-!- irker816 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160227 08:55:43< irker816> wesnoth: Charles Dang wesnoth:master e5c5b0213e44 / data/campaigns/The_Rise_Of_Wesnoth/scenarios/15_A_New_Land.cfg: TRoW S15: added Lord Typhon's death to lose objectives (bug #24461) https://github.com/wesnoth/wesnoth/commit/e5c5b0213e44299f320a5eb57fd2b5ff02779e28
20160227 09:00:36< irker816> wesnoth: Charles Dang wesnoth:1.12 bd6dff7deee1 / data/campaigns/The_Rise_Of_Wesnoth/scenarios/15_A_New_Land.cfg: TRoW S15: added Lord Typhon's death to lose objectives (bug #24461) https://github.com/wesnoth/wesnoth/commit/bd6dff7deee12198b6af45b7f2abac57ab3af654
20160227 09:03:49< irker816> wesnoth: Charles Dang wesnoth:1.12 bcf9e15ec1d6 / data/campaigns/Under_the_Burning_Suns/scenarios/02_Across_the_Harsh_Sands.cfg: UtBS: fixed Go'hag not being included in death event filter (bug #24444) https://github.com/wesnoth/wesnoth/commit/bcf9e15ec1d6fd2fe3a07d0a2c02283b0c8af327
20160227 09:06:23< Aginor> celmin|sleep: celmin|sleep thanks for taking the time to review
20160227 09:07:23< irker816> wesnoth: Charles Dang wesnoth:master 2732b21610de / data/campaigns/Under_the_Burning_Suns/scenarios/02_Across_the_Harsh_Sands.cfg: UtBS S2: slightly more consistent ID for Go'hag https://github.com/wesnoth/wesnoth/commit/2732b21610de09fc894438d6e355e4fc95bdbedd
20160227 09:13:21< vultraz> Aginor: do you think we can get it merged by sunday?
20160227 09:39:51-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160227 10:08:27< vultraz> zookeeper: I just noticed, side-by-side, gray shallow is almost indistinguishable from medium shallow
20160227 10:09:15< zookeeper> eh... i don't see how
20160227 10:11:27< zookeeper> i'd say there's more difference than between medium and tropical shallow
20160227 10:15:39-!- mjs-de [~mjs-de@f049079156.adsl.alicedsl.de] has joined #wesnoth-dev
20160227 10:35:56< zookeeper> vultraz, was that with a particular ToD?
20160227 10:40:20< vultraz> default editor tod
20160227 10:42:37< zookeeper> ok, then i don't see it :p
20160227 10:45:09< zookeeper> isn't this what you see? https://forums.wesnoth.org/viewtopic.php?p=594040#p594040
20160227 10:46:25< vultraz> basically
20160227 10:58:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160227 11:03:11-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20160227 11:05:28< Kwandulin> So, how is a queen of the merfolk called? The king has the title 'Kai'
20160227 11:06:58< vultraz> I don't think that's been established 
20160227 11:09:23< zookeeper> yeah, it hasn't. i don't know if something prevents the same from being used for both, or whether a different title would be needed.
20160227 11:12:52< vultraz> well traditionally there's a different title
20160227 11:17:36< zookeeper> sure, but that doesn't mean the merfolk title can't be gender-neutral
20160227 11:22:38< zookeeper> pretty much all other titles are gender-specific, so might as well have a gender-neutral merfolk title just for variety's sake. they seem very egalitarian anyway, so it fits.
20160227 11:28:57< vultraz> alright
20160227 11:29:45< zookeeper> lua_common.obj : error LNK2001: unresolved external symbol "int __cdecl translation::compare(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?compare@translation@@YAHABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0@Z)
20160227 11:29:49< zookeeper> missing some include there?
20160227 11:31:50< zookeeper> it does have a #include "gettext.hpp"
20160227 11:31:55< zookeeper> so dunno why it's failing
20160227 11:41:20< vultraz> you always seem to have such nice build problems
20160227 11:46:34< zookeeper> oh you think?
20160227 11:46:54< zookeeper> well, at least that one was easy to solve
20160227 11:50:42< vultraz> it's weird, because no one else seems to get these issues
20160227 12:04:46-!- louis94 [~~louis94@91.178.240.5] has joined #wesnoth-dev
20160227 12:05:49< zookeeper> hrhm. fixing the unit placed event crash part of https://gna.org/bugs/?24439 is as easy as making play_controller::reset_gamestate not do anything to/with lua_kernel, but i don't know if that's appropriate.
20160227 12:07:29-!- irker816 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160227 12:08:46< zookeeper> on an unrelated note, there's a mess on the "player type" label: https://dl.dropboxusercontent.com/u/63964618/wesnoth/game_lobby_mess.png
20160227 12:09:39< vultraz> already filed https://gna.org/bugs/?24437
20160227 12:10:24< zookeeper> right
20160227 12:16:57-!- louis94 [~~louis94@91.178.240.5] has quit [Ping timeout: 244 seconds]
20160227 12:20:07< vultraz> hmmm
20160227 12:20:20 * vultraz is trying to pin down what's taking the editor so long to start up
20160227 12:22:23< zookeeper> you mean the 1-2 seconds between the loading screen's disappearance and when the map and interface actually appears?
20160227 12:22:36< vultraz> yes
20160227 12:23:35< vultraz> the entire editor_controller constructor only takes 382 ms to execute
20160227 12:25:17< zookeeper> should be easy to figure out
20160227 12:25:48< vultraz> if I had a profiler, yes
20160227 12:26:44< zookeeper> well just make time measurements in code and output the results, that's what i do
20160227 12:27:16< vultraz> that's what I;m doing
20160227 12:27:39< zookeeper> all right
20160227 12:28:03< zookeeper> unsigned int start_time = SDL_GetTicks(); <do stuff>; std::cerr << "doing stuff took " << SDL_GetTicks() - start_time << "ms" << std::endl;
20160227 12:28:20< zookeeper> that's what i use everywhere when i need to figure out what's taking so long
20160227 12:28:34< vultraz> the play_slice() only takes about 20 ms each loop...
20160227 12:34:59-!- Kwandulin [~Miranda@p200300760F0BC5B71DF0341711DF01AA.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20160227 12:38:47< vultraz> UGH
20160227 12:38:51< vultraz> I'm getting nowhere
20160227 12:50:17-!- Kwandulin [~Miranda@p200300760F0BC5D21DF0341711DF01AA.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160227 12:54:22-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160227 12:56:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160227 13:06:58< zookeeper> vultraz, well, the delay happens in editor_main.cpp, before editor.main_loop() gets called
20160227 13:07:15< vultraz> I hadn't gotten that far back...
20160227 13:07:31< zookeeper> shouldn't be hard to bisect it further
20160227 13:07:42< vultraz> thanks
20160227 13:08:33< zookeeper> all i did was start inserting an assert(false) into spots in the relevant-looking loading/initing code and seeing whether the assert triggers before or after the delay :p
20160227 13:10:19< vultraz> yup, narrowed it down
20160227 13:10:21< vultraz> 3176 ms
20160227 13:10:29< zookeeper> my money's on the editor constructor, and eventually the application of the terrain graphics rules and stuff
20160227 13:11:01< vultraz> 3:23:33]	vultraz	the entire editor_controller constructor only takes 382 ms to execute
20160227 13:11:04< vultraz> so I suspect not
20160227 13:11:09< zookeeper> oh, right
20160227 13:11:14< vultraz> but let's see
20160227 13:12:11< vultraz> hm
20160227 13:12:13< vultraz> no, you're right
20160227 13:12:24< vultraz> isolating it to the hotkey lines gives me "0 ms"
20160227 13:12:32< zookeeper> yep
20160227 13:12:38< vultraz> isolating it to the editor controller line gives me, this time 2821
20160227 13:12:57< vultraz> 2845..
20160227 13:13:01< vultraz> ok so it varies 
20160227 13:13:04< vultraz> but that's the problem
20160227 13:14:49< vultraz> let me measure the constructor again 
20160227 13:15:05< vultraz> 374
20160227 13:15:19< vultraz> so where's the extra ~2k ms coming from
20160227 13:15:46< vultraz> eh...
20160227 13:15:49< vultraz> hm
20160227 13:15:55< vultraz> wait, I'm only measuring the constructor action block
20160227 13:15:58< zookeeper> doesn't all those initiali... yeah
20160227 13:16:10< vultraz> I don't know how to measure that
20160227 13:16:21< zookeeper> so it's probably one of the editor_display, controller_base or context_manager initializations
20160227 13:16:28< zookeeper> just measure them individually i guess?
20160227 13:17:29< vultraz> money's on editor_display
20160227 13:18:30< zookeeper> and from there, the display constructor
20160227 13:18:54< zookeeper> and from there, terrain_builder
20160227 13:20:17< zookeeper> which, i can almost assure you, you won't be able to find potential for easy speedups in
20160227 13:20:38< vultraz> "display contructor took 1 ms" wellthen
20160227 13:20:53< vultraz> (though again, actions only..)
20160227 13:22:06< vultraz> might not be editor_display...
20160227 13:22:47< zookeeper> it's the terrain_builder::terrain_builder constructor
20160227 13:23:52< vultraz> oh?
20160227 13:23:55< zookeeper> and the time is mainly spent going through the gazillion terrain graphics rules
20160227 13:24:01< vultraz> :(
20160227 13:24:11< vultraz> so basically, nothing we can solve
20160227 13:24:23< zookeeper> basically, yes
20160227 13:24:39< vultraz> I mean, technically we could, but it would take a lot of effort
20160227 13:25:56< vultraz> still, it's something that will need to be done eventually
20160227 13:28:23< zookeeper> the obvious option would seem to be to do the terrain building in a separate thread and start it as soon as possible, but i'm pretty sure that's not exactly a simple refactor. just making sure that the loading screen waits until all that display initialization is done would be a good first step.
20160227 13:29:34< vultraz> terrain_builder::parse_config() is the offender
20160227 13:33:58< zookeeper> i dunno if openmp could be of help there
20160227 13:34:01-!- louis94 [~~louis94@91.178.240.5] has joined #wesnoth-dev
20160227 13:36:57< vultraz> we should call upon iceiceice and see if he has any insight
20160227 13:39:01< zookeeper> IIRC when i was profiling that stuff, i concluded that there's no obvious easy culprit to why it's so slow, it's simply because it has to do so much string handling and such.
20160227 13:39:57< zookeeper> and by "so slow" i mean "takes so much time", which i believe is an important distinction in this case :p
20160227 13:42:22< vultraz> well, we could use a hash map for the config class
20160227 13:42:50< vultraz> but gfgtdf mentioned something about the server only taking ordered wml..
20160227 13:44:19< vultraz> but you're right, an immediate solution would be to handle this during the loadscreen not after
20160227 13:49:54< vultraz> actually, that function seems to set the loadscreen progress...
20160227 13:49:56< vultraz> weird
20160227 14:14:33< zookeeper> it's done in the loadscreen in-game, but not in the editor
20160227 14:16:21< vultraz> yes, that's bad
20160227 14:16:25< vultraz> should fix
20160227 14:50:04-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160227 15:04:24< celmin|sleep> vultraz, zookeeper: I wonder, would it be possible to leave the loading screen up until after the editor_controller is constructed? Add an additional loading stage?
20160227 15:05:30-!- Kwandulin [~Miranda@p200300760F0BC5D21DF0341711DF01AA.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160227 15:05:38< celmin|sleep> Oh. I guess you already came to that conclusion. I was scrolled up a bit.
20160227 15:29:06-!- fabi [~quassel@176.0.66.187] has joined #wesnoth-dev
20160227 15:29:06-!- fabi [~quassel@176.0.66.187] has quit [Changing host]
20160227 15:29:06-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20160227 15:34:36-!- Kwandulin [~Miranda@p200300760F0BC5D21D1865CA1ED88414.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160227 15:35:39-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160227 15:50:26-!- prkc [~prkc@563BD80A.dsl.pool.telekom.hu] has joined #wesnoth-dev
20160227 15:51:33-!- louis94 [~~louis94@91.178.240.5] has quit [Ping timeout: 240 seconds]
20160227 15:59:49< celmin|sleep> I'm pretty sure I had something to say to mattsc... what was it again...
20160227 16:01:59-!- celmin|sleep is now known as celticminstrel
20160227 16:04:31-!- louis94 [~~louis94@91.178.240.5] has joined #wesnoth-dev
20160227 16:05:35< celticminstrel> Oh, right. Have you ever heard of [state] tags in Lua AI components? I think I saw [goal] and [candidate_action] using them.
20160227 16:05:44< celticminstrel> (In the code, not actual WML use.)
20160227 16:16:42-!- iceiceice [~chris@wesnoth/developer/iceiceice] has quit [Ping timeout: 244 seconds]
20160227 16:21:26-!- ancestral [~ancestral@97-116-184-84.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160227 16:27:30-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160227 16:31:25< mattsc> celticminstrel: I have not seen them used for anything, don’t even know what they do.  But I think I have seen them pop up somewhere; in the inspector output probably.
20160227 16:31:54< celticminstrel> Make sense.
20160227 16:32:19< celticminstrel> It seems to be arbitrary data passed to the Lua code, but what I really want to know is whether it's mutable data.
20160227 16:33:03< mattsc> Oh, hmm, yeah it might be an old way of doing that (before the data field worked); I have a very vague recollection of that.
20160227 16:33:40< mattsc> So if that’s the case, we can probably get rid of it.  *If* that’s the case.
20160227 16:33:54-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20160227 16:33:59< mattsc> Thanks for your comments from last night and your additions to the [engine] wiki entry.
20160227 16:34:06< celticminstrel> I think it would be nice if every type of Lua AI component was defined in basically the same way.
20160227 16:34:24< mattsc> That section I had copied literally from a page that already existed, because I didn’t know any better.
20160227 16:34:39< celticminstrel> With either a code= or location= key for the actual code, and [args] tags for arbitrary data (equivalent to current eval_parms and exec_parms).
20160227 16:34:41< mattsc> sure, that would make sense
20160227 16:35:25< celticminstrel> (For CAs maybe we could also support the separated evaluation= and execution= pair, in case people are still using that.)
20160227 16:36:03< mattsc> and after thinking about it some more, it makes sense that targets and protect targets are different types.  The AI really deals with them differently and needs to know somehow which one is which.
20160227 16:36:16< mattsc> ok
20160227 16:36:28< celticminstrel> You were right about protect targets being type THREAT, by the way.
20160227 16:37:07< mattsc> I saw your comment, that’s what I am referring too.  Thanks for checking.
20160227 16:37:16< celticminstrel> For some reason, all protect goals have a common protect_goal superclass, but target_unit and target_location both inherit directly from goal.
20160227 16:38:37< mattsc> ok
20160227 16:38:56< celticminstrel> Probably just a weird implementation detail..
20160227 16:39:18< mattsc> might have evolved, rather than being planned that way
20160227 16:42:47< zookeeper> who might be our currently-most-knowledgeable-person regarding the lua engine?
20160227 16:43:04< mattsc> you
20160227 16:43:12< zookeeper> i doubt it!
20160227 16:43:30< mattsc> ;)  celticminstrel  probably
20160227 16:43:51< mattsc> zookeeper: do you mean the engine, or the use of Lua?
20160227 16:43:51< celticminstrel> I'm not sure. I've worked with it, gfgtsf has worked with it, maybe iceiceice has too.
20160227 16:43:59< celticminstrel> Whoops, misspelled his name.
20160227 16:44:02< zookeeper> mattsc, engine
20160227 16:44:11< celticminstrel> What do you want to know?
20160227 16:45:51< mattsc> zookeeper: yeah, one of those three then, probably; definitely not me
20160227 16:46:18< zookeeper> basically i'd like to know what side-effects it might have if the first and last lines of this block were removed: https://github.com/wesnoth/wesnoth/blob/master/src/play_controller.cpp#L327-L344
20160227 16:46:41-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20160227 16:46:48< zookeeper> or at least the first. that would apparently fix the unit_creator crash in https://gna.org/bugs/?24439
20160227 16:49:45< zookeeper> or, in other words, why would the lua kernel need to be reset when reseting gamestate?
20160227 16:50:02< zookeeper> is it necessary to make like some global state stuff not persist across the gamestate reset, or what?
20160227 16:56:39< celticminstrel> Hmm.
20160227 16:58:04< celticminstrel> By setting resources::lua_kernel to NULL, it signals to other functions that the Lua kernel is not currently available.
20160227 16:58:40< celticminstrel> Line 332 first destroys the gamestate (which I'm guessing includes the Lua kernel as part of it), and then reconstructs it.
20160227 17:00:22< celticminstrel> Here's something else to try: https://github.com/wesnoth/wesnoth/blob/master/src/game_events/pump.cpp#L499
20160227 17:00:42< celticminstrel> Either delete that line or change it to an early return like the preceding two lines.
20160227 17:01:08< celticminstrel> I'm not sure if that would have undesirable side-effects, but it's probably worth a try.
20160227 17:01:12< zookeeper> well yes i could just remove/avoid the assert, but i assumed it was there for a reason
20160227 17:01:49< celticminstrel> Yes, I'm guessing it's probably there for a reason (though I can't imagine what the reason is), that's why I suggested exiting the function instead of asserting when the condition fails.
20160227 17:02:51< celticminstrel> The assert presumably means that the function calls stuff that might require the Lua kernel, so if the content of the function is skipped, it would probably not need the Lua kernel. (But that's event-processing code, so there could be other negative side-effects.)
20160227 17:03:04< celticminstrel> (Still, probably worth a try, right?)
20160227 17:03:39< celticminstrel> Also, it's possible that the reason for the assert being there no longer exists. Maybe you could try searching out the commit that introduced it for clues.
20160227 17:04:12< zookeeper> yeah. i guess i'll see what happens if i just turn it into a return instead.
20160227 17:08:09< mattsc> celticminstrel: [modify_ai] works in ActionWML and in [side][ai].  Do you know whether it works in [era][ai] and [modification][ai] also?
20160227 17:14:20< mattsc> It’s easy enough to test, but if you know already, I won’t bother with it.
20160227 17:14:33< celticminstrel> I don't!
20160227 17:14:49< mattsc> Okay; I’ll just try it then and see what happens.
20160227 17:15:00< celticminstrel> I'm guessing [era][ai] and [modification][ai] show up in the create game view?
20160227 17:15:16< mattsc> yes
20160227 17:15:48< mattsc> the description= attribute of that [ai] tag is what is displayed in the computer player selection menu
20160227 17:16:01< celticminstrel> BTW, [side][ai] has no use for id= and description=, right? Because they're being stripped out on my branch.
20160227 17:16:27< mattsc> description is need for just that reason ^
20160227 17:16:31< mattsc> id is not
20160227 17:16:41< celticminstrel> No no no, in [side][ai] specifically.
20160227 17:16:51< mattsc> oh …
20160227 17:17:02< celticminstrel> I know it's needed in AIs that show in the dropdown menu.
20160227 17:17:03< mattsc> yes, that should be correct
20160227 17:18:14< celticminstrel> Suddenly I think I understand why the stage is duplicated on my branch.
20160227 17:19:02< celticminstrel> The MP setup dialog probably injects ai_default_rca into the side's config, and my parsing also does something similar.
20160227 17:19:07< mattsc> yay
20160227 17:19:56< celticminstrel> I might have to look into how the MP setup does this.
20160227 17:20:46 * celticminstrel was working on something not AI-related, but I think I'll go back to AI for now since I've run into a design block.
20160227 17:22:55-!- louis94 [~~louis94@91.178.240.5] has quit [Ping timeout: 255 seconds]
20160227 17:31:17< celticminstrel> So, Lua can create ... stages, goals, aspects, and candidate actions.
20160227 17:32:57 * celticminstrel decides to look at guifixes while waiting for Wesnoth to compile.
20160227 17:34:16-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160227 17:38:36< celticminstrel> I don't really understand why draw_layering is in a video2 namespace... I guess it doesn't matter though...
20160227 17:40:58< celticminstrel> Program exit is the best time to have an assertion failure. >_>
20160227 17:41:00< celticminstrel> 
20160227 17:41:13< celticminstrel> ...whoops.
20160227 18:04:13< celticminstrel> vultraz: The gamestate inspector still has a problem with the upper listbox being too compressed.
20160227 18:05:18< celticminstrel> Aaaand I think I broke Wesnoth by attempting to use Experimental AI on a scenario that defines a Lua [engine].
20160227 18:58:29< celticminstrel> Found it. As I thought, it was injecting the full config for the chosen AI. If I just make it set ai_algorithm instead, that should fix it.
20160227 19:09:01-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160227 19:12:17< mattsc> celticminstrel: So, [modify_ai] works in [era][ai] and [modification][ai].
20160227 19:12:33< celticminstrel> Good to know.
20160227 19:13:04< mattsc> At least with external CAs it does.  I had some problem when I also used an engine definition, but since I don’t recommend using that any more anyway, I did not investigate whether that’s because I did something wrong or due to a fundamental problem.
20160227 19:13:20< celticminstrel> Would it cause any problems to change the ID of the Idle AI from ai_idle to idle_ai?
20160227 19:13:37< mattsc> I doubt it.
20160227 19:15:49< celticminstrel> The failure with experimental_ai might've been caused by [engine], or might've been caused by the invalid [goal]s.
20160227 19:16:46< celticminstrel> (There were invalid [goal]s because I added diagnostic messages if you try to define a [goal]name=lua_goal with the cpp engine or any other goal with the lua engine.)
20160227 19:16:59< mattsc> So is that a problem with the ExpAI or with the engine?
20160227 19:17:35< celticminstrel> I'll know once I try this with no AI stuff specified in the scenario.
20160227 19:17:44< mattsc> ok
20160227 19:18:36< celticminstrel> I doubt there's any need for this, but it would be hypothetically possible to allow Lua to be used to define new engines.
20160227 19:18:44< celticminstrel> Within the existing framework.
20160227 19:19:23< celticminstrel> (All it would require is overriding a single function in the engine_lua class.)
20160227 19:21:13-!- Kwandulin [~Miranda@p200300760F0BC5D21D1865CA1ED88414.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160227 19:21:15< mattsc> I agree that I don’t see a usecase for this at the moment.
20160227 19:21:42-!- irker083 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160227 19:21:42< irker083> wesnoth: ln-zookeeper wesnoth:master f4cb65692113 / src/actions/unit_creator.cpp: Fixed the unit_creator crash part of bug #24439 https://github.com/wesnoth/wesnoth/commit/f4cb6569211316d496e6896d595e5f66da1f15e1
20160227 19:21:50< zookeeper> celticminstrel, ^ seemed like a slightly less intrusive way to do it.
20160227 19:22:31< celticminstrel> Keeping in mind that the main purpose of an engine is to parse stage, aspect, and goal tags.
20160227 19:22:37< celticminstrel> Yeah, I don't see a usecase either.
20160227 19:24:35< celticminstrel> (I said "all it would require", but there's probably some other setup required too.)
20160227 19:28:06< Aginor> vultraz: it depends on what celticminstrel says in the end
20160227 19:28:36< Aginor> vultraz: my partner has a medical procedure today so I'll spend most of today fuzzing over her
20160227 19:30:57< celticminstrel> Aginor: What I say about what?
20160227 19:31:24< celticminstrel> Also Aginor, would you mind merging master to guifixes?
20160227 19:35:08< Aginor> celticminstrel: what you say about guifixes :)
20160227 19:35:13< Aginor> celticminstrel: I'll do so now
20160227 19:36:04< Aginor> can someone please mute the bot?
20160227 19:36:08< celticminstrel> zookeeper: Yeah, that's a good change.
20160227 19:36:35< celticminstrel> I honestly have no clue who can mute the bot, or how it's done, but I don't think I can do it.
20160227 19:38:38< celticminstrel> No problems with experimental AI alone.
20160227 19:38:53< Aginor> celticminstrel: you can't, you need to have a wesnoth cloak
20160227 19:39:06< Aginor> testing the merge now
20160227 19:40:03< celticminstrel> ...so, apparently I thought I was on my AI branch but actually wasn't.
20160227 19:42:29-!- mode/#wesnoth-dev [+o zookeeper] by ChanServ
20160227 19:42:44<@zookeeper> gimme a sec to figure out the mute command :p
20160227 19:43:50< Aginor> zookeeper: mode +q irker*!*@* might work
20160227 19:45:59-!- mode/#wesnoth-dev [+q irker*!*@*] by zookeeper
20160227 19:46:44< Aginor> merge is good
20160227 19:46:56< Aginor> pushing
20160227 19:47:05< celticminstrel> Did he mute it already?
20160227 19:47:13< Aginor> I think so
20160227 19:47:19< Aginor> he'll still se it but we won't
20160227 19:47:30< celticminstrel> I guess I'll find out.
20160227 19:47:33< Aginor> I'm done pushing
20160227 19:47:41< Aginor> zookeeper: thanks :)
20160227 19:47:58<@zookeeper> i guess it worked
20160227 19:48:04< celticminstrel> Guess so.
20160227 19:48:44-!- mode/#wesnoth-dev [-q irker*!*@*] by zookeeper
20160227 19:48:44< irker083> wesnoth: Charles Dang wesnoth:guifixes e5c5b0213e44 / data/campaigns/The_Rise_Of_Wesnoth/scenarios/15_A_New_Land.cfg: TRoW S15: added Lord Typhon's death to lose objectives (bug #24461) https://github.com/wesnoth/wesnoth/commit/e5c5b0213e44299f320a5eb57fd2b5ff02779e28
20160227 19:48:47< irker083> wesnoth: Charles Dang wesnoth:guifixes 2732b21610de / data/campaigns/Under_the_Burning_Suns/scenarios/02_Across_the_Harsh_Sands.cfg: UtBS S2: slightly more consistent ID for Go'hag https://github.com/wesnoth/wesnoth/commit/2732b21610de09fc894438d6e355e4fc95bdbedd
20160227 19:48:50< irker083> wesnoth: ln-zookeeper wesnoth:guifixes f4cb65692113 / src/actions/unit_creator.cpp: Fixed the unit_creator crash part of bug #24439 https://github.com/wesnoth/wesnoth/commit/f4cb6569211316d496e6896d595e5f66da1f15e1
20160227 19:48:52< irker083> wesnoth: Andreas Löf wesnoth:guifixes 46a0eb0e558f / / (84 files in 37 dirs): Merge remote-tracking branch 'origin/master' into guifixes https://github.com/wesnoth/wesnoth/commit/46a0eb0e558f2d705b6a5dfe8b55dd2a91e59b98
20160227 19:49:01< celticminstrel> Or not?
20160227 19:49:06<@zookeeper> i guess it wasn't quite done yet.
20160227 19:49:10< celticminstrel> Or yeah, that.
20160227 19:49:11< Aginor> zookeeper: it did, you were just too quick
20160227 19:49:13<@zookeeper> good timing, i guess
20160227 19:49:22< celticminstrel> It's clearly not the full log there.
20160227 19:49:34< Aginor> celticminstrel: all done
20160227 19:49:39-!- mode/#wesnoth-dev [-o zookeeper] by ChanServ
20160227 19:49:39< celticminstrel> 'kay
20160227 19:49:49< zookeeper> i have to write down this stuff somewhere...
20160227 19:50:02< Aginor> feel free to merge the branch with master if you're happy. I expect there will be minor details to mop up for a while longer
20160227 19:50:18< Aginor> the occasional gui2 dialog not undrawing at the right time :D
20160227 19:50:26< Aginor> I will need to disappear now
20160227 19:50:44< Aginor> and I don't know of my availability for the newxt couple of days
20160227 20:00:21-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160227 20:00:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160227 20:04:04-!- Kwandulin [~Miranda@p200300760F0BC5D271D1E57047649442.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160227 20:05:30< vultraz> 05:04:12]	celticminstrel	vultraz: The gamestate inspector still has a problem with the upper listbox being too compressed.
20160227 20:05:33< vultraz> too compressed how?
20160227 20:06:03< celticminstrel> It has a scrollbar.
20160227 20:06:16< vultraz> a horizontal scrollbar?
20160227 20:06:19< celticminstrel> Vertical.
20160227 20:06:34< vultraz> can't be helped, much
20160227 20:06:55< vultraz> gui2 absolutely sucks are doing calculations of two listboxes on top of each other
20160227 20:06:58-!- travis-ci [~travis-ci@ec2-54-157-222-14.compute-1.amazonaws.com] has joined #wesnoth-dev
20160227 20:06:59< travis-ci> wesnoth/wesnoth#8638 (master - f4cb656 : ln-zookeeper): The build has errored.
20160227 20:06:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/112288209
20160227 20:06:59-!- travis-ci [~travis-ci@ec2-54-157-222-14.compute-1.amazonaws.com] has left #wesnoth-dev []
20160227 20:07:03< celticminstrel> But, when I select something in it, the scrollbar disappears.
20160227 20:07:17< celticminstrel> (Might depend on what I select in it.)
20160227 20:46:59-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20160227 20:48:23< vultraz> blah, https://gna.org/bugs/?24454 is a whiteboard bug
20160227 20:48:31< vultraz> whiteboard will have to go, IMO
20160227 20:53:00< vultraz> celticminstrel: are you done looking at guifixes?
20160227 20:53:31< celticminstrel> I finished reviewing it. I haven't tried it out.
20160227 20:54:25< celticminstrel> Trying it out was the reason I asked him to merge master.
20160227 20:54:56< vultraz> ah
20160227 20:58:18< celticminstrel> Have you tried it, vultraz?
20160227 20:58:22< vultraz> yes
20160227 20:59:00< celticminstrel> I guess it didn't add any new files?
20160227 21:04:47-!- trewe [~trewe@bl20-14-107.dsl.telepac.pt] has joined #wesnoth-dev
20160227 21:04:53< vultraz> not that I know of
20160227 21:05:10-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160227 21:44:17-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 244 seconds]
20160227 21:44:28-!- Netsplit *.net <-> *.split quits: heirecka, higgins, loonycyborg, aeonchild, fabi, DDR, elias, Ravana_, Crendgrim, aidanhs,  (+9 more, use /NETSPLIT to show all of them)
20160227 21:44:35-!- Netsplit *.net <-> *.split quits: Yaiyan, horrowind, celticminstrel, ypnos, bumbadadabum, boucman, mattsc, nurupo, crimson_penguin, tomreyn,  (+1 more, use /NETSPLIT to show all of them)
20160227 21:44:35-!- Netsplit *.net <-> *.split quits: kidneb
20160227 21:44:53-!- Netsplit *.net <-> *.split quits: Soliton, timotei_, Gambit, wedge009, esr, vincent_c, Aginor, Jetrel, AI0867, irker083,  (+23 more, use /NETSPLIT to show all of them)
20160227 21:44:58-!- Netsplit *.net <-> *.split quits: midzer
20160227 21:51:05-!- Yaiyan_ [~Yaiyan@46.101.48.31] has joined #wesnoth-dev
20160227 21:51:05-!- Netsplit over, joins: DDR, higgins
20160227 21:51:05-!- iwaim___ [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20160227 21:51:05-!- Netsplit over, joins: celticminstrel
20160227 21:51:05-!- aeonchil1 [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160227 21:51:05-!- Crendgrim_ [~crend@wesnoth/forum-moderator/crendgrim] has joined #wesnoth-dev
20160227 21:51:05-!- Netsplit over, joins: aeth, {V}
20160227 21:51:05-!- Jetrel_ec2 [~Jetrel@ec2.happyspork.com] has joined #wesnoth-dev
20160227 21:51:05-!- shikadibot [~shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20160227 21:51:05-!- wedge009 [~Thunderbi@60.241.236.92] has joined #wesnoth-dev
20160227 21:51:05-!- Netsplit over, joins: trewe
20160227 21:51:05-!- Kwandulin [~Miranda@p200300760F0BC5D271D1E57047649442.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160227 21:51:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160227 21:51:05-!- Netsplit over, joins: irker083
20160227 21:51:05-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160227 21:51:05-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20160227 21:51:05-!- Netsplit over, joins: prkc, horrowind, stikonas
20160227 21:51:05-!- mjs-de [~mjs-de@f049079156.adsl.alicedsl.de] has joined #wesnoth-dev
20160227 21:51:05-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160227 21:51:05-!- Netsplit over, joins: boucman, aidanhs
20160227 21:51:05-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160227 21:51:05-!- Netsplit over, joins: clavii, elias, TC01, Jetrel, Lohengramm, ypnos, esr, nurupo, crimson_penguin, tomreyn (+3 more)
20160227 21:51:05-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160227 21:51:05-!- AI0867 [~ai@wesnoth/developer/ai0867] has joined #wesnoth-dev
20160227 21:51:05-!- Soliton [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev
20160227 21:51:06-!- Netsplit over, joins: EliDupree, molgrum, legoktm, Greywhind
20160227 21:51:07-!- Jetrel_ec2 is now known as Jetrel_bot
20160227 21:51:11-!- Netsplit over, joins: heirecka
20160227 21:51:13-!- Rhonda [~rhonda@anguilla.noreply.org] has joined #wesnoth-dev
20160227 21:51:13-!- Grickit [~derek@grickit.us] has joined #wesnoth-dev
20160227 21:51:19-!- Netsplit over, joins: oldlaptop, minzbonbon, quentinp, TheJJ, vincent_c, midzer
20160227 21:51:20-!- AI0867 [~ai@wesnoth/developer/ai0867] has quit [Ping timeout: 250 seconds]
20160227 21:51:21-!- Netsplit over, joins: pydsigner
20160227 21:51:21-!- AI0867 [~ai@wesnoth/developer/ai0867] has joined #wesnoth-dev
20160227 21:51:59-!- Netsplit over, joins: kidneb, timotei_
20160227 21:54:18-!- Grickit is now known as Guest52915
20160227 21:54:49-!- knotwork__ [~markm@99.192.83.208] has joined #wesnoth-dev
20160227 22:00:18-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Read error: Connection timed out]
20160227 22:00:31-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev
20160227 22:05:15-!- Jetrel_ [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has joined #wesnoth-dev
20160227 22:06:06-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160227 22:07:42-!- irker083 [~irker@uruz.ai0867.net] has quit [Ping timeout: 276 seconds]
20160227 22:07:43-!- aeonchil1 [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 276 seconds]
20160227 22:07:43-!- esr [~esr@wesnoth/developer/esr] has quit [Ping timeout: 276 seconds]
20160227 22:07:59-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20160227 22:07:59-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20160227 22:07:59-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160227 22:08:10-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160227 22:08:21-!- Jetrel_bot [~Jetrel@ec2.happyspork.com] has quit [Ping timeout: 276 seconds]
20160227 22:08:23-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has quit [Ping timeout: 276 seconds]
20160227 22:08:23-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 276 seconds]
20160227 22:08:37-!- louis94 [~~louis94@91.178.240.5] has joined #wesnoth-dev
20160227 22:09:31-!- Jetrel_bot [~Jetrel@ec2.happyspork.com] has joined #wesnoth-dev
20160227 22:10:03-!- Ivanovic_ is now known as Ivanovic
20160227 22:11:34-!- Ravana_ [~Ravana@unaffiliated/ravana/x-2327071] has joined #wesnoth-dev
20160227 22:20:05-!- lobby [~wesnoth@wesnoth/bot/lobby] has joined #wesnoth-dev
20160227 22:20:05-!- Topic for #wesnoth-dev: 1.13.3 scheduled for Friday, March 4th | Wesnoth Developers Channel | >>> Want to help? Go here: http://r.wesnoth.org/t42911 (and thanks!) <<< | Logs: http://irclogs.wesnoth.org | Bug tracker: http://bugs.wesnoth.org
20160227 22:20:05-!- Topic set by vultraz [~chatzilla@wesnoth/developer/vultraz] [Sat Feb 27 08:43:28 2016]
20160227 22:20:05[Users #wesnoth-dev]
20160227 22:20:05[ aeonchild      ] [ Guest52915] [ matthiaskrgr] [ stikonas ] 
20160227 22:20:05[ aeth           ] [ heirecka  ] [ mattsc      ] [ TC01     ] 
20160227 22:20:05[ Aginor         ] [ higgins   ] [ midzer      ] [ TheJJ    ] 
20160227 22:20:05[ AI0867         ] [ horrowind ] [ minzbonbon  ] [ timotei_ ] 
20160227 22:20:05[ aidanhs        ] [ Ivanovic  ] [ mjs-de      ] [ tomreyn  ] 
20160227 22:20:05[ boucman        ] [ iwaim___  ] [ molgrum     ] [ trewe    ] 
20160227 22:20:05[ celticminstrel ] [ janebot   ] [ new_one     ] [ vincent_c] 
20160227 22:20:05[ clavii         ] [ Jetrel_   ] [ nurupo      ] [ vultraz  ] 
20160227 22:20:05[ Crendgrim_     ] [ Jetrel_bot] [ oldlaptop   ] [ wedge009 ] 
20160227 22:20:05[ crimson_penguin] [ kidneb    ] [ prkc        ] [ wedge010 ] 
20160227 22:20:05[ DDR            ] [ knotwork__] [ pydsigner   ] [ ypnos    ] 
20160227 22:20:05[ elias          ] [ Kwandulin ] [ quentinp    ] [ zookeeper] 
20160227 22:20:05[ EliDupree      ] [ legoktm   ] [ Ravana_     ] [ {V}      ] 
20160227 22:20:05[ esr            ] [ lobby     ] [ Rhonda      ] 
20160227 22:20:05[ fabi           ] [ Lohengramm] [ shikadibot  ] 
20160227 22:20:05[ Greywhind      ] [ louis94   ] [ Soliton     ] 
20160227 22:20:05-!- Irssi: #wesnoth-dev: Total of 61 nicks [0 ops, 0 halfops, 0 voices, 61 normal]
20160227 22:20:07-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20160227 22:20:09-!- Channel #wesnoth-dev created Tue Jan 27 05:28:41 2009
20160227 22:20:40-!- horrowind1 [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160227 22:21:09-!- horrowind [~Icedove@2a02:810a:8380:834:21b:fcff:fee3:c3ff] has quit [Remote host closed the connection]
20160227 22:21:09-!- horrowind1 is now known as horrowind
20160227 22:21:12-!- Irssi: Join to #wesnoth-dev was synced in 75 secs
20160227 22:21:13-!- loonycyborg [~loonycybo@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20160227 22:22:43-!- Yaiyan [~Yaiyan@46.101.48.31] has joined #wesnoth-dev
20160227 22:24:04-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Ping timeout: 244 seconds]
20160227 22:24:51-!- Netsplit *.net <-> *.split quits: tomreyn, wedge009, nurupo, shikadibot, Jetrel_bot
20160227 22:25:38-!- fabi [~quassel@wesnoth/developer/fendrin] has quit [Ping timeout: 244 seconds]
20160227 22:27:09-!- Netsplit over, joins: Jetrel_bot
20160227 22:27:09-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160227 22:28:08-!- Kwandulin [~Miranda@p200300760F0BC5D271D1E57047649442.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds]
20160227 22:28:12-!- Rhonda [~rhonda@anguilla.noreply.org] has quit [Ping timeout: 240 seconds]
20160227 22:28:12-!- Guest52915 [~derek@grickit.us] has quit [Ping timeout: 240 seconds]
20160227 22:28:12-!- oldlaptop [~quassel@50-37-53-169.mskg.mi.frontiernet.net] has quit [Ping timeout: 240 seconds]
20160227 22:28:15-!- minzbonbon [~min@meta23.net] has quit [Ping timeout: 240 seconds]
20160227 22:28:15-!- quentinp [~quentin@ns363174.ip-91-121-196.eu] has quit [Ping timeout: 240 seconds]
20160227 22:28:15-!- TheJJ [~rofl@ipbcc36ea9.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds]
20160227 22:28:15-!- vincent_c [~bip@107.191.117.101] has quit [Ping timeout: 240 seconds]
20160227 22:28:15-!- midzer [~quassel@pD9FA2D72.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20160227 22:28:49-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160227 22:28:49-!- Elsi [~Elsi@luwin.ulrar.net] has joined #wesnoth-dev
20160227 22:30:30-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Max SendQ exceeded]
20160227 22:30:32-!- fabi [~quassel@176.0.66.187] has joined #wesnoth-dev
20160227 22:30:32-!- fabi [~quassel@176.0.66.187] has quit [Changing host]
20160227 22:30:32-!- fabi [~quassel@wesnoth/developer/fendrin] has joined #wesnoth-dev
20160227 22:30:35-!- shikadibot [~shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20160227 22:30:35-!- TheJJ [~rofl@ipbcc36ea9.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160227 22:30:36-!- quentinp [~quentin@ns363174.ip-91-121-196.eu] has joined #wesnoth-dev
20160227 22:30:38-!- Rhonda [~rhonda@anguilla.noreply.org] has joined #wesnoth-dev
20160227 22:30:44-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20160227 22:31:34-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20160227 22:31:56-!- oldlaptop [~quassel@50-37-53-169.mskg.mi.frontiernet.net] has joined #wesnoth-dev
20160227 22:32:37-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev
20160227 22:34:23-!- _laco [~laco@static.95.25.4.46.clients.your-server.de] has joined #wesnoth-dev
20160227 22:34:55-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160227 22:35:14-!- minzbonbon [~min@meta23.net] has joined #wesnoth-dev
20160227 22:37:50-!- midzer [~quassel@pD9FA2D72.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160227 22:38:23-!- mjs-de [~mjs-de@f049079156.adsl.alicedsl.de] has quit [Remote host closed the connection]
20160227 22:38:47-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20160227 22:41:21-!- Netsplit *.net <-> *.split quits: Elsi
20160227 22:41:30-!- Elsi_ [~Elsi@luwin.ulrar.net] has joined #wesnoth-dev
20160227 22:44:17-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160227 22:55:35-!- Appleman1234 [~Appleman1@KD106161153065.au-net.ne.jp] has joined #wesnoth-dev
20160227 22:56:25-!- Greywhind [~Greywhind@c-50-133-231-228.hsd1.ma.comcast.net] has quit [Ping timeout: 268 seconds]
20160227 22:59:33-!- louis94 [~~louis94@91.178.240.5] has quit [Ping timeout: 427 seconds]
20160227 23:01:33-!- Greywhind [~Greywhind@c-50-133-231-228.hsd1.ma.comcast.net] has joined #wesnoth-dev
20160227 23:06:26-!- TheJJ [~rofl@ipbcc36ea9.dynamic.kabel-deutschland.de] has quit [Ping timeout: 244 seconds]
20160227 23:08:06-!- aidanhs_ [~aidanhs@81.4.110.234] has joined #wesnoth-dev
20160227 23:08:17-!- aidanhs [~aidanhs@81.4.110.234] has quit [Read error: Connection reset by peer]
20160227 23:09:26-!- TheJJ [~rofl@ipbcc36ea9.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160227 23:10:09-!- trewe [~trewe@bl20-14-107.dsl.telepac.pt] has quit [Quit: quit]
20160227 23:11:57-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has quit [Excess Flood]
20160227 23:12:27-!- pydsigner [~pydsigner@unaffiliated/pydsigner] has joined #wesnoth-dev
20160227 23:13:19-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 268 seconds]
20160227 23:18:34-!- tomreyn [~tomreyn@archmage.megaglest.org] has joined #wesnoth-dev
20160227 23:18:37-!- tomreyn [~tomreyn@archmage.megaglest.org] has quit [Changing host]
20160227 23:18:37-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20160227 23:20:02-!- louis94 [~~louis94@91.178.240.5] has joined #wesnoth-dev
20160227 23:30:12-!- TC01 [~quassel@london.acm.jhu.edu] has quit [Ping timeout: 244 seconds]
20160227 23:32:32-!- TC01 [~quassel@128.220.251.37] has joined #wesnoth-dev
20160227 23:33:17-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160227 23:50:52-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20160227 23:51:14-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160227 23:54:07< Aginor> hmm
20160227 23:54:19< Aginor> I've broken SDL1 in guifixes (doesn't compile)
20160227 23:54:21< Aginor> I shall fix that
--- Log closed Sun Feb 28 00:00:06 2016