--- Log opened Tue Oct 11 00:00:21 2016
20161011 00:03:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 00:04:22< celticminstrel> tad_, shadowm: I'm pretty sure Lua can easily be configured to automatically use static_cast. Maybe it even does so automatically when compiled as C++.
20161011 00:05:36< tad_> celticminstrel, Lua has no issues with the (int) cast [probably because it never uses it] so it's just fixing the call sites in Wesnoth C++ elsewhere. Done and wrapping up, except ...
20161011 00:07:01< tad_> I **need** to get past these -Werror about unused return value and deprecation for fribidi_log2vis .. so I put in GCCC pragmas to suppress it for the one line. Should I PR that change or ignore it/back it out once I'm done with what I'm doing?
20161011 00:07:53< celticminstrel> Lua uses C-style casts all over the place, but hidden behind a cast(type, value) macro. So that's probably defined to use static_cast instead in C++.
20161011 00:08:15< celticminstrel> I have no idea what fribidi_log2vis is.
20161011 00:08:30< tad_> celticminstrel, Don't know, don't care ,,, Lua compiles cleanly and that's all I care about right now.
20161011 00:08:54< celticminstrel> If it's a deprecatec function that we have no choice about using, then using pragmas seems like a good idea.
20161011 00:08:58< celticminstrel> ^deprecated
20161011 00:09:20< celticminstrel> I guess you could send a PR. Maybe someone who actually knows what it's for will have something else to say.
20161011 00:09:43< shadowm> I'll have an answer in 45 minutes.
20161011 00:09:47< tad_> fribidi is the support for bi-directional display (think Arabic fonts .. LTR instead of RTL). I don't normally see the errors but I'm doing a scons 'strict' build to check the Lua changes.
20161011 00:11:04< tad_> I will do a PR and someone more pedantic than I about bidi support, or less pedantic about message suppression, can approve or reject.
20161011 00:12:10< tad_> It looks like changing away from log2vis is painful/complex so I'd say we stick with it. Comments on fribidi mailing list are 'sure, it's deprecated, but it's not going away, so go aheadand use it'
20161011 00:13:25< irker137> wesnoth: mattsc wesnoth:master 2eeed5ad3528 / data/ai/micro_ais/cas/ca_big_animals.lua: Big Animals Micro AI: move only one unit per execution https://github.com/wesnoth/wesnoth/commit/2eeed5ad3528149d78a1102aca505e1023c9cb20
20161011 00:13:27< irker137> wesnoth: mattsc wesnoth:master 3d2fd331d3a6 / data/ai/micro_ais/cas/ca_hunter.lua: Hunter Micro AI: goto hex must be passable for hunter https://github.com/wesnoth/wesnoth/commit/3d2fd331d3a63c7a35e2b7dc80754ccf1a8be040
20161011 00:27:25< tad_> shadowm, celticminstrel The changes I made for luaL_checkint are up on my GL_Lua2 branch, now, if you want to see what I did.
20161011 00:30:42-!- ancestral [~ancestral@8.42.164.20] has joined #wesnoth-dev
20161011 00:32:51-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161011 00:34:19-!- ancestral [~ancestral@8.42.164.20] has quit [Client Quit]
20161011 00:34:44-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 260 seconds]
20161011 00:40:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20161011 00:40:39-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20161011 00:44:58< shadowm> tad_: RTL instead of LTR, not the other way around. Hopefully.
20161011 00:45:53< shadowm> I don't get the warning on Debian stretch, so it's probably some newer version of FriBiDi that triggers it. Or you did something bad to the SCons recipe.
20161011 00:46:58< tad_> All I did for this area was add the strict option. And I reported the same message a day or two ago when I was doing a first-ever build on clean master in prep for today's work.
20161011 00:47:21< shadowm> The official Windows release builds (read: the ones that are uploaded to SF.net) do not use FriBiDi, I believe (anyone who was one of them from version 1.13.3 or later I think, the one that introduces the version info dialog, can check this).
20161011 00:47:43< shadowm> IIRC loonycyborg didn't bother with it because it's only used by GUI1 elements and it's more or less broken.
20161011 00:47:56< shadowm> Or at least was back in 2008 and that's how the Pango-based ttext was born.
20161011 00:48:36< shadowm> So you can either not use FriBiDi, or figure out a way to silence those warnings.
20161011 00:48:46< vultraz> which for some reason uses SDL_TTF constant values.
20161011 00:48:47< tad_> Well, I've a PR prepared .. either it can commit or someone can take a look at eliminating it.  FriBiDi mailing list talk about Pango is they don't use it any more and do it internally.
20161011 00:48:53< shadowm> You didn't add the strict option. The strict option already exists.
20161011 00:49:18< tad_> shadowm, I meant 'added to my command line, to test my changes for Lua'
20161011 00:50:12< shadowm> I've been using strict for years now, still haven't gotten the warnings (read: errors) hence my theory is that they are caused by some version that hasn't landed in stretch.
20161011 00:50:24< shadowm> Or sid, for that matter.
20161011 00:51:14< shadowm> <vultraz> which for some reason uses SDL_TTF constant values.
20161011 00:51:16< shadowm> Say what?
20161011 00:51:36< tad_> $ yaourt -Q fribidi
20161011 00:51:36< tad_> extra/fribidi 0.19.7-1
20161011 00:51:57< shadowm> Uh huh.
20161011 00:52:03< shadowm> I have 0.19.7.
20161011 00:52:04< vultraz> https://github.com/wesnoth/wesnoth/blob/master/src/text.cpp#L68
20161011 00:52:19< shadowm> Okay, I literally have no idea how you got that then.
20161011 00:52:45< shadowm> vultraz: Looks like you could change that and nobody outside would notice.
20161011 00:53:05< shadowm> It was probably used for compatibility purposes OR an earlier incarnation of ttext used SDL_ttf.
20161011 00:53:26< shadowm> Oh wait, the header says.
20161011 00:53:39< shadowm> "The flags have the same values as the ones in SDL_TTF so it's easy to mix them for now. To avoid including SDL_TTF in the header they're only declared here. Once SDL_TTF is removed they can be moved in the header."
20161011 00:54:09< shadowm> (sic)
20161011 00:54:23< shadowm> I don't know why anyone would want to do that?
20161011 00:54:43< vultraz> I'm going to refactor that
20161011 00:54:47< vultraz> so we don't do shit like this
20161011 00:54:48< vultraz> https://github.com/wesnoth/wesnoth/blob/master/src/gui/widgets/helper.cpp#L55
20161011 00:54:54< shadowm> So it's probably some piece of interop that isn't self-evident or has long since been removed.
20161011 00:55:35< vultraz> cairo handles weight and style in two different parameter. 
20161011 00:55:44< shadowm> I'm reasonably sure that the earliest GUI2 iterations used SDL_ttf.
20161011 00:55:45< vultraz> er, pango
20161011 00:56:38< vultraz> so I'm going to separate weight and style.
20161011 00:56:46< vultraz> bold is a weight, not a style.
20161011 00:57:05< shadowm> Is there a point to spending time with that?
20161011 00:57:16< vultraz> well
20161011 00:57:20< shadowm> Are we going to be able to use extended and numeric weights now?
20161011 00:58:10< vultraz> I'm going to give WML constants corresponding PangoWeight values, but they're just numeric aliases.
20161011 00:58:26< vultraz> a better question will be whether I can get the damn game to load lato's weight variations :|
20161011 00:58:30< shadowm> You know, Light, Semilight, Medium, Semibold, Bold, Extrabold, and their numeric counterparts that I believe are all multiples of 100.
20161011 00:58:31< vultraz> last time I tried, it didn't work
20161011 00:58:44< vultraz> yes, https://developer.gnome.org/pango/stable/pango-Fonts.html#PangoWeight
20161011 00:59:02< shadowm> Considering that the synthetic versions usually look like poop and it's a preposterous waste of space to include fonts with support for more than Medium and Bold.
20161011 00:59:09< shadowm> (And their italic counterparts.)
20161011 00:59:26< vultraz> Lato has an advantage over DVS of having dedicated weight variations
20161011 00:59:32< shadowm> And that with some luck one person will ever make use of this.
20161011 00:59:45< shadowm> That's not an advantage, vultraz.
20161011 01:00:17< shadowm> It only means that you have the option to waste your time with gratuitous typography choices and make other people pay the price in bytes.
20161011 01:00:35< shadowm> This is Wesnoth, not Adobe Illustrator or whatever.
20161011 01:00:52< vultraz> True.
20161011 01:01:33< vultraz> Perhaps for now I'll just refactor ttext to not use the TTF constants
20161011 01:02:14< vultraz> (and gui2)
20161011 01:02:25< shadowm> My point either way is that perhaps there are more pressing things to do than give 1% of us the ability to get off on rare font weights.
20161011 01:03:19< vultraz> It's not that hard to do.
20161011 01:03:36< vultraz> Whether it will actually work is another thing.
20161011 01:04:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 01:04:54-!- gfgtdf_ [~chatzilla@x4e32b2c9.dyn.telefonica.de] has joined #wesnoth-dev
20161011 01:06:56-!- gfgtdf [~chatzilla@x4e36a1e7.dyn.telefonica.de] has quit [Ping timeout: 260 seconds]
20161011 01:07:03-!- gfgtdf_ is now known as gfgtdf
20161011 01:09:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20161011 01:17:30< shadowm> HM, hm.
20161011 01:18:51-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161011 01:21:48< shadowm> vultraz: https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20161010_222117.png
20161011 01:22:20< shadowm> What do you recommend?
20161011 01:49:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 01:52:39-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161011 01:53:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20161011 01:57:39< pydsigner> Oh look we're talking about fonts again :P
20161011 01:59:44-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161011 02:01:00< pydsigner> vultraz: FWIW, DVS has non-synthetic weight variations
20161011 02:09:23< shadowm> vultraz, celticminstrel: https://github.com/wesnoth/wesnoth/pull/821
20161011 02:09:39< shadowm> celticminstrel: I'd like to know how well this works on OS X, particularly if it compiles in the first place.
20161011 02:10:57< shadowm> I intentionally opted for a lazy approach like on other non-Windows platforms.
20161011 02:12:19< vultraz> shadowm: it works for now
20161011 02:12:32< shadowm> vultraz: No, it doesn't.
20161011 02:12:54< shadowm> Pay attention to that horizontal scrollbar's associated area.
20161011 02:13:17< vultraz> it's the window scrollbar
20161011 02:13:43< shadowm> Exactly, and the window controls are either invisible or cut off.
20161011 02:13:56< shadowm> Back in _my_ days this would've been considered unacceptable.
20161011 02:14:41< shadowm> I'd have had to chastise myself for pushing a crap design.
20161011 02:14:54< vultraz> We're going to try to implement collapsing floating panels for 1.13.7.
20161011 02:15:12< shadowm> Collapsing what now?
20161011 02:16:17< vultraz> Something that would allow the bookmarks list to expand over the saves list without shoving it to the right.
20161011 02:16:22< vultraz> Though that might not even be possible
20161011 02:16:23< vultraz> who knows
20161011 02:16:35< shadowm> vultraz.
20161011 02:16:40< shadowm> The problem in that screenshot isn't the bookmarks bar.
20161011 02:17:42< shadowm> The thing that is demanding more space than is available (okay, due to the bookmarks bar, but also because of the dialog's size restrictions) is the path label.
20161011 02:18:22< shadowm> I need it to be ellipsized instead.
20161011 02:24:17< vultraz> yeah, well, that's another thing that needs to be done.
20161011 02:31:01-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161011 02:32:40-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20161011 02:35:12 * celticminstrel agrees on the window scrollbar being unacceptable.
20161011 02:37:57-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161011 02:44:24< vultraz> shadowm: as a temporary measure you could put everything except the buttons in a scrollbar panel
20161011 02:45:10-!- tad_ [~lundberg@173.217.65.103] has quit [Quit: Leaving]
20161011 02:45:58-!- un214 [~un214@104.220.56.173] has joined #wesnoth-dev
20161011 02:46:13< vultraz> actually, the lists, I mean
20161011 02:46:28-!- gfgtdf [~chatzilla@x4e32b2c9.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161011 02:48:00< vultraz> (and the path label, that is)
20161011 02:49:04-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161011 02:49:32-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161011 02:49:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 02:59:49< vultraz> celticminstrel: are you feeling up to looking at that flg dialog not showing issues
20161011 02:59:55< vultraz> celticminstrel: it's kinda a blocker
20161011 03:00:50< shadowm> Scrolling the map on the editor is really sluggish, even on a GTX 1060. :p
20161011 03:00:56< celticminstrel> Possibly...
20161011 03:01:15< shadowm> (Yes, I know it's all done in software right now.)
20161011 03:03:45-!- un214 [~un214@104.220.56.173] has quit [Remote host closed the connection]
20161011 03:13:20< vultraz> I might postpone the release to early next week
20161011 03:13:27< vultraz> so I can finish this mp stuff
20161011 03:13:52-!- irker137 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161011 03:15:45< vultraz> celticminstrel: is a function that potentially never completes because it calls code that never returns to the call site memory mismanagement? 
20161011 03:16:34< vultraz> even if the next statement is simply a return
20161011 03:16:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161011 03:18:18< shadowm> A function that never returns is a dead end, so there's almost no point in the caller having a return statement (unless the compiler is unaware of the callee's nature).
20161011 03:19:36< shadowm> Now, if the callee doesn't return to the caller because it throws an exception that the caller doesn't handle, then the callee returns to the caller just not in a normal way.
20161011 03:20:17-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20161011 03:20:43< shadowm> But assuming that's not what you meant, then the answer as to whether memory mismanagement is taking place is complicated and depends on a lot of nuances.
20161011 03:21:34< shadowm> For example, the code that runs below main() allocates memory for global objects, library state, etc.
20161011 03:22:12< shadowm> That memory will never be formally released if the program doesn't return from main() or exit(), but it's not being wasted either because it's needed by the program.
20161011 03:23:06< shadowm> It's only a waste if the programmer chose to make objects global when they would serve their purpose better with a shorter lifetime.
20161011 03:24:05< shadowm> (e.g. you don't want to make the unit map global because it's not needed when the game isn't actually in full game mode, such as in the title screen.)
20161011 03:25:52< shadowm> Also, note that I said "never formally released". It is usually released in the end, just not in a way that is meaningful to your program -- on account of it being already dead.
20161011 03:26:36< shadowm> Heap and stack allocations in modern operating systems are backed with memory that the OS knows how and when to release if circumstances arise.
20161011 03:26:58-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161011 03:27:10< shadowm> There _are_ things that if you never formally release yourself  may never be released at all even if your program kicks the bucket, but you probably don't work with any of those yet.
20161011 03:33:29< shadowm> I forgot case 3 for the original question: if you are using setjmp in C++ code then you might as well be juggling nuclear warheads.
20161011 03:33:50< shadowm> Or taking a swim in the Arctic.
20161011 03:34:26< shadowm> Surrounded by polar bears and orcas.
20161011 03:35:16< shadowm> vultraz: So yeah, what's the improved version of the original question?
20161011 03:35:41< vultraz> Gimme a new minutes
20161011 03:35:44< vultraz> few
20161011 03:36:35< shadowm> Do we ever use toggle_panel in a context other than listboxes?
20161011 03:36:45< shadowm> Okay, yes, the answer is yes. In how many places?
20161011 03:36:46< vultraz> tree view nodes
20161011 03:37:23< shadowm> Kind of the same thing, really.
20161011 03:38:11< shadowm> I know they are used for the hotkeys thing in what I expect is not a listbox.
20161011 03:38:38< vultraz> it is a listbox.
20161011 03:38:44< shadowm> The reason I'm asking is that in this case it would actually make more sense to decouple the background from the toggle_panel def and into the listbox and tree view widgets.
20161011 03:39:55< shadowm> The default disabled/enabled state background, that is. Not the hover/active state backgrounds.
20161011 03:39:57< vultraz> listbox, potentially
20161011 03:40:02< vultraz> not the tree view
20161011 03:40:14< shadowm> Why not?
20161011 03:41:32< vultraz> there are cases where we'd want listboxes without toggle panels or toggle buttons. right now, tree views are an opportunity to get around this restriction
20161011 03:42:02< shadowm> But surely you'd still want them to have a background, or maybe not?
20161011 03:42:20< vultraz> im not sure
20161011 03:42:34< vultraz> in mp create and staging it does good sans background
20161011 03:42:46< shadowm> Okay, I see what you mean.
20161011 03:42:55< vultraz> well*
20161011 03:43:37< shadowm> It's too bad we can't specify a canvas for "that part that doesn't contain any children widgets" of a widget.
20161011 03:44:19< shadowm> I've been trying to put something below the listbox's content area but I'm having difficulties trying to find a widget that will grow to fill the area without demanding any space itself.
20161011 03:44:37< vultraz> put what?
20161011 03:44:53< shadowm> Something that will draw the same background as toggle panels.
20161011 03:45:36< vultraz> why not horizontal and vertical grow = true?
20161011 03:45:45< shadowm> Because it doesn't work?
20161011 03:46:15< shadowm> <shadowm> grow to fill the area without demanding any space itself.
20161011 03:46:28< vultraz> grow_factor = 0
20161011 03:47:27< shadowm> Nope.
20161011 03:47:40< vultraz> in [row]?
20161011 03:47:45< shadowm> Yep.
20161011 03:48:27< vultraz> what exactly is it you're trying to place?
20161011 03:49:22< shadowm> First a panel, now a label.
20161011 03:49:31< vultraz> [footer]?
20161011 03:49:37< shadowm> No, a widget.
20161011 03:49:51< vultraz> no, I mean is it in the footer
20161011 03:50:10< shadowm> No, it's in _content_grid.
20161011 03:50:27< vultraz> headers/footers are simply grids attached to the top/bottom of the main content_grid grid
20161011 03:50:27< shadowm> In a new row below the row that contains the _list_grid.
20161011 03:52:40< vultraz> Id have to see screenshots and code
20161011 03:52:54< shadowm> I can't show you screenshots because they are identical to the status quo.
20161011 03:53:30< shadowm> https://dl.dropboxusercontent.com/u/21371130/poop/listbox_background_attempt.diff
20161011 03:54:08< vultraz> why are you not using [drawing]
20161011 03:54:12< shadowm> I got this to work previously with a [drawing], yes.
20161011 03:54:18< shadowm> But [drawing] needs a fixed size.
20161011 03:54:25< vultraz> ..no?
20161011 03:54:29< shadowm> Yes?
20161011 03:54:38< shadowm> When I didn't specify the size the thing simply wouldn't show up.
20161011 03:55:08< vultraz> try (width) and (height)
20161011 03:55:20< shadowm> Those are canvas variables, they work in the [draw].
20161011 03:55:32< shadowm> I really don't think they will work in the widget attributes themselves.
20161011 03:55:38< vultraz> Try anyway
20161011 03:55:59< vultraz> you're probably right, though
20161011 03:56:11< vultraz> I think I needed window_width or something, but that's not what's wanted
20161011 03:56:43< shadowm> Didn't work.
20161011 03:57:19< vultraz> I think the simplest solution is simply to duplicate the toggle panel without a background
20161011 03:57:25< shadowm> Oddly, if I use 10,10, the height is 10 and the width as large as there's space left in the grid.
20161011 03:57:46< vultraz> toggle panel definition*
20161011 03:58:29< shadowm> But then I get 10 extra pixels at the bottom of each listbox.
20161011 03:58:50< shadowm> So e.g. if you scroll all the way down there's 10 pixels of nothingness at the end.
20161011 03:59:15< shadowm> Well, 10 pixels of background, anyway.
20161011 04:00:26< shadowm> e.g. https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20161011_010015.png
20161011 04:01:45< shadowm> I'd rather make the default toggle panel not have a background, and make the background-having one opt-in.
20161011 04:02:05< vultraz> sure
20161011 04:02:11< shadowm> And then transition all toggle panel-based tree views in existence to that.
20161011 04:02:25< vultraz> so, campaigns and the inspector
20161011 04:02:33< shadowm> Although, honestly, that makes the whole thing only 80% less hacky.
20161011 04:05:05-!- JyrkiVesterinen [~JyrkiVest@87-100-182-88.bb.dnainternet.fi] has joined #wesnoth-dev
20161011 04:05:20< shadowm> So yeah, probably will do user bookmarks first.
20161011 04:09:57-!- irker369 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161011 04:09:57< irker369> wesnoth: Ignacio R. Morelle wesnoth:master c458e3e18050 / data/gui/window/ (game_cache_options.cfg game_version.cfg screenshot_notification.cfg): gui2: Make dialogs with fs browse buttons use the new browse icon https://github.com/wesnoth/wesnoth/commit/c458e3e1805041a3ca9a0c00478a0bc9a32bf445
20161011 04:12:41< irker369> wesnoth: Ignacio R. Morelle wesnoth:master abc9a599b6f8 / data/gui/window/game_cache_options.cfg: gui2/tgame_cache_options: Relabel OK as Close https://github.com/wesnoth/wesnoth/commit/abc9a599b6f83b1349753fb66574b925e525c0a1
20161011 04:21:57< celticminstrel> [Oct 10@11:15:45pm] vultraz: celticminstrel: is a function that potentially never completes because it calls code that never returns to the call site memory mismanagement?
20161011 04:21:58< celticminstrel> Uhhh. What?
20161011 04:22:21< vultraz> nevermind
20161011 04:23:17< Aginor> don't use the goto family and you're good :D
20161011 04:23:34< shadowm> Oh yes, that should've been case 2.5.
20161011 04:23:48-!- Netsplit *.net <-> *.split quits: crimson_penguin
20161011 04:26:20-!- Netsplit over, joins: crimson_penguin
20161011 04:30:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 04:31:50-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161011 04:35:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20161011 04:41:42< vultraz> I wonder if there's any way to get scenario metadata without reloading a config
20161011 04:41:52< vultraz> but I guess not
20161011 04:42:05< vultraz> since  campaign [scenarios] are *always* behind a define guard
20161011 04:44:21< vultraz> ok, so in gui1 mode
20161011 04:46:03< vultraz> there's the loadscreen pre-config
20161011 04:46:03< vultraz> then you can go directly to connect
20161011 04:46:03< vultraz> even with selecting a starting point.
20161011 04:47:24< vultraz> 'then again
20161011 04:47:35< vultraz> in gui2, we merge the connect and configure steps
20161011 04:48:01< vultraz> create and configure
20161011 04:51:51< vultraz> ..oh!
20161011 04:51:55< vultraz> ok, so it's the FLG 
20161011 04:51:59< vultraz> that's causing the problem
20161011 04:52:06< vultraz> the FLG isn't valid :/
20161011 04:53:14< vultraz> but why is the flg not valid
20161011 04:53:58< vultraz> or perhaps
20161011 04:54:01< vultraz> not that
20161011 04:54:04< vultraz> the button works
20161011 04:54:09< vultraz> let us investigate..
20161011 04:57:41-!- JyrkiVesterinen [~JyrkiVest@87-100-182-88.bb.dnainternet.fi] has quit [Quit: .]
20161011 04:59:13< vultraz> ah ha!
20161011 05:00:14< vultraz> I have isolated
20161011 05:00:16< vultraz> the crash
20161011 05:00:18< vultraz> it
20161011 05:00:20< vultraz> s not the flg
20161011 05:01:07< vultraz> ...in fact I think it's not even the code :|
20161011 05:01:26< vultraz> I was simply doing unit_types.find(current_leader)->
20161011 05:01:32< vultraz> without checking the validity 
20161011 05:01:50< vultraz> let's test without a check..
20161011 05:02:02< vultraz> in a mainline campaign
20161011 05:03:35< vultraz> it has now come back to bite me in the ass to assume a side always has a valid leader type :|
20161011 05:06:19< vultraz> the crash was caused by AtS E1S3 having sides with no_leader
20161011 05:07:09< vultraz> hmm
20161011 05:07:18< vultraz> what should I display in the absence of a leader. 
20161011 05:07:24< vultraz> no image, I guess
20161011 05:11:09< vultraz> note to self: find out why HTTT S2's sides display all in red.
20161011 05:15:21-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20161011 05:20:48-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161011 05:25:06-!- Kwandulin [~Miranda@p200300760F2C716720B6163B6364B398.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161011 05:32:10-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20161011 05:40:02< vultraz> what would be a good "no leader" image?
20161011 05:42:35< wedge009> A silhouette?
20161011 05:43:20< vultraz> yeah, the unknown unit image could work
20161011 05:55:25-!- Kwandulin [~Miranda@p200300760F2C716720B6163B6364B398.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161011 06:08:49< vultraz> so, hitting that config::attribute_value::to_bool() is not really a bool thing
20161011 06:08:59< vultraz> iirc we never decided how to deal with this
20161011 06:11:07< vultraz> or perhaps this is something else
20161011 06:13:19-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: End Transmission.]
20161011 06:17:44< vultraz> um
20161011 06:17:58< vultraz> does anyone know why the default here is true? https://github.com/wesnoth/wesnoth/blob/master/src/game_config_manager.cpp#L279
20161011 06:19:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 06:19:10< vultraz> changing that to false fixes the issue im having
20161011 06:19:23< vultraz> unless I'm mistaken, that's an error
20161011 06:19:52< vultraz> though
20161011 06:19:55< vultraz> to be fair
20161011 06:20:10< vultraz> I have absolutely no idea what the hell that's intended to be for anyway
20161011 06:21:01-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161011 06:21:42< vultraz> perhaps as a kind of validation step?
20161011 06:22:00< vultraz> but i'm making that to_bool(false) for now
20161011 06:23:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20161011 06:47:08-!- tad_ [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161011 06:52:56< tad_> I would be interested in feedback on the latest commit added to GL_Lua2. If it passes muster, I will have reverted or refactored all Wesnoth changes to Lua 5.2 and be ready to upgrade to 5.3 to begin testing. +
20161011 06:53:19< shadowm> vultraz: I think you told me there's a shorter form of listbox::add_row() for trivial data?
20161011 06:53:37< shadowm> s/form of/equivalent to/ (?)
20161011 06:53:50< tad_> I have a disabled inline function at the bottom I'm working on .. checking if it's needed in Windows (not needed for GCC scons strict) +
20161011 06:54:02< vultraz> there's an overload that takes a string_map only
20161011 06:54:06< tad_> My primary concern is the IEEE754 work.
20161011 06:54:09< vultraz> instead of map<string, string_map>
20161011 06:54:59< shadowm> What's the string_map supposed to look like?
20161011 06:55:07< shadowm> Namely, what are the keys?
20161011 06:56:05< vultraz> I'm not sure, since I never used it.
20161011 06:56:21< shadowm> Huh, I could swear you even gave me a code example.
20161011 06:56:26< vultraz> I assume the same contents as a single widget block
20161011 06:56:34< vultraz> label, tooltip, etc
20161011 06:56:51< shadowm> Well, that won't do since I have two widgets per row.
20161011 06:56:59< vultraz> then you need the map one
20161011 06:58:39< shadowm> tad_: I'm going to preface this with the disclaimer that I'm not in charge of maintaining anything in master since 1.13.3.
20161011 06:58:51< tad_> NP
20161011 06:59:03< shadowm> Consider renaming src/wesnothluaconfig.h to something with underscores between words.
20161011 06:59:14< vultraz> shadowm: thoughts on this as a new Unknown Unit icon? https://drive.google.com/file/d/0B-mR9s8FduLLQS1tM2dzX2pfTzQ/view?usp=sharing
20161011 06:59:24< shadowm> And we don't use #pragma once.
20161011 07:00:00< tad_> And I forgot a copyright notice. Noted. I'll adjust it.
20161011 07:04:16< shadowm> "Revert gratuitous change" -- Not gratuitous, see commit 12a7a5a1e0fee21e0c88042c6b3c7be1c73f30e3 .
20161011 07:04:30< shadowm> Maybe it's not needed anymore, but that doesn't make it gratuitous in context.
20161011 07:06:30< shadowm> I cannot comment "Move local changes to proper place".
20161011 07:06:33< shadowm> *on
20161011 07:06:43< tad_> I failed to check the commit. I'll read it, consider it and adjust accordingly. My primary concern was getting to the point where the files matched with diff so I knew I had moved aside what needed to be moved and put all the edits in one place.
20161011 07:06:55< shadowm> There's a extraneous commit in the set.
20161011 07:07:17< tad_> Drat. The font thing?
20161011 07:07:34< shadowm> "Suppress -Wmaybe-uninitialized in tlistbox::place()"
20161011 07:08:07< shadowm> OK. When my turn came to update Lua to version whatever, I made sure to read our history with git log -p to understand better the diff I generated from the previous vanilla Lua.
20161011 07:08:31< shadowm> Obviously my brain discarded most of that info 48 hours later.
20161011 07:10:40< tad_> When I compare for a PR (and cancel .. not yet) I don't see that extra commit.
20161011 07:10:41< shadowm> There's is a local change I begrudgingly reapplied that doesn't seem to be part of your series, the PI constant def.
20161011 07:11:04< shadowm> https://github.com/wesnoth/wesnoth/compare/master...GregoryLundberg:GL_Lua2
20161011 07:11:19< vultraz> didn't he merge the removal of that?
20161011 07:11:25< shadowm> I have no idea.
20161011 07:11:40< shadowm> I'm sure you do have the answer to your own question, though. :p
20161011 07:11:48< vultraz> https://github.com/wesnoth/wesnoth/commit/299b0cc55c70a8e32f3a7f0ef16d4323f063d7a4
20161011 07:11:58< shadowm> Okay, cool.
20161011 07:12:10< shadowm> Again, not maintaining anything -> not paying attention.
20161011 07:12:55-!- irker369 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161011 07:13:15< tad_> The PI thing .. Lua 5.2 and 5.3 have the binary correct value for 'double' .. the use of Boost for PI should give the exact same bits.
20161011 07:13:38< shadowm> Yeah, I'm not questioning the decision to not keep it.
20161011 07:13:58< shadowm> As I said, I wasn't too keen on reapplying it but did anyway because I was on a tight schedule.
20161011 07:14:23< tad_> Darn .. refreshed and that commit IS there. What's up with that? Well, I'll yank it. Maybe it will go away with a rebase? I'll figure it out.
20161011 07:15:30< tad_> shadowm, I will get the bit pattern for inside Lua and compare both versions. If Boost *DOES* give a different value, I'll revert that to go back to using Boost. But I'll be amazed if it makes a difference.
20161011 07:16:34< shadowm> I'd be more amazed if anyone cared.
20161011 07:16:53< shadowm> e.g. the "it's a game, not an X" principle.
20161011 07:17:00< shadowm> The src/lua/SConscript diff in the real first commit made me raise an eyebrow but I can't comment on it because looking at SCons code makes me want to puke, and the person in charge of that has always been loonycyborg anyway.
20161011 07:17:14< shadowm> And that's all I can say.
20161011 07:17:42< shadowm> It's good that you are working on this. Being able to keep up with upstream without so much effort would be great.
20161011 07:18:18< tad_> That, I'm actually pretty confident in. It was all Classical Greek to me so I spend a LOT of time searching the 'net for how to do what I needed.
20161011 07:18:44< tad_> scons ^
20161011 07:18:55< tad_> Same for CMake.
20161011 07:19:07< tad_> And Visual Studio.
20161011 07:19:32< shadowm> Reminds me I've been meaning for ages (literally over one year) to clean up the CMakeLists.txt files. <_<
20161011 07:20:08< tad_> So I need to do changes to CodeBlocks (both versions) and have someone feed me what's needed for XCode. No other platforms in master (?)
20161011 07:20:24< shadowm> Maybe I'll PR that after 1.13.6 so that people have a chance to add all their crap before I inevitably introduce a million merge conflicts.
20161011 07:21:13< shadowm> tad_: Technically, in my times we only required people to update SCons and CMake, and the rest was considered optional.
20161011 07:22:04< shadowm> Personally, I would not bother with XCode or any IDE that uses non-trivial file tables (XCode project files have opaque hashes all over the place). I do try to keep CodeBlocks' project files up to date since they are reasonably simple and I also used them before I figured out crosscompiling.
20161011 07:22:09< tad_> Oh, good. Well, I'd like to be complete and those platforms/toolsets are in master so I figure they need to keep instep
20161011 07:23:28< tad_> When I'm done with this and the dust settles (or, the fires die down, more likely) I want to refactor Lua throughout master. We're pulling a lot of junk into a lot of files which really should not be there.
20161011 07:24:46< tad_> It was an eye-opener, btw, to look at one of the scripting lua kernel files and find 101 (!!!) #includes all in a row.
20161011 07:25:36 * tad_ sings: Take one down and pass it around 100 #includes in a row ...
20161011 07:25:45< shadowm> They are in master, but I think the people who actually use them do a good enough job at keeping them up to date.
20161011 07:26:58< shadowm> Re includes, someone had the brilliant idea of running a tool to "clean up" includes at some point after master diverged from 1.12 (I think).
20161011 07:27:17< shadowm> It removed some and then added a lot of includes that are more or less guaranteed to be already there.
20161011 07:27:26< tad_> Oh geez. Bet that went swimingly
20161011 07:27:35< shadowm> They didn't really bother with cleaning them up afterwards despite my insistence.
20161011 07:27:45< shadowm> And neither did I because I had more important things to do.
20161011 07:28:13< shadowm> Open source software.
20161011 07:29:47-!- Kwandulin [~Miranda@p200300760F2C71B220B6163B6364B398.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161011 07:29:52< tad_> Well, I'm thinking of a pimpl lua class to hide all the implementation details like foisting <stdio.h> into every module which touches Lua.
20161011 07:30:47< JyrkiVesterinen> Instead of (or in addition to) that, I suggest splitting game_lua_kernel into smaller classes.
20161011 07:30:48< shadowm> That doesn't seem like a huge thing to worry about to me.
20161011 07:31:15< JyrkiVesterinen> A big reason for the huge number of #includes is that the class is simply too large.
20161011 07:31:45< vultraz> but there are already so many!
20161011 07:31:55< tad_> So many what?
20161011 07:32:22< shadowm> Anyway, I was thinking of the standard library includes; <utility> and <iterator> next to <map>, for example.
20161011 07:32:24< vultraz> lua-related classes
20161011 07:32:27-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20161011 07:32:45< shadowm> Or <SDL_something.h> next to <SDL.h> (hint: the latter includes all <SDL_everything.h>.
20161011 07:33:16< shadowm> Our own includes are considerably less trivially identifiable as redundant.
20161011 07:34:02< shadowm> Just clarifying since the odds that the unnamed person will see this are actually quite good.
20161011 07:36:42-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161011 07:38:13-!- tad_ [~lundberg@173.217.65.103] has quit [Ping timeout: 248 seconds]
20161011 07:38:46-!- tad_carlucci is now known as tad_
20161011 07:46:08-!- Bonobo [~Bonobo@2001:44b8:254:3200:1d2e:ccd5:5f75:5131] has joined #wesnoth-dev
20161011 07:47:50-!- Bonobo [~Bonobo@2001:44b8:254:3200:1d2e:ccd5:5f75:5131] has quit [Client Quit]
20161011 07:48:16-!- Bonobo [~Bonobo@2001:44b8:254:3200:1d2e:ccd5:5f75:5131] has joined #wesnoth-dev
20161011 07:51:23-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20161011 07:52:38< shadowm> Sigh.
20161011 07:52:49< shadowm> "Don't add generic GUI2 dialogs", he said.
20161011 07:53:20< shadowm> Well, now I'd get things done much faster/not have to skip a feature if I hadn't complied.
20161011 07:54:08< shadowm> Probably will do the latter unless I managed to squeeze it into my schedule after the PR is merged and before I run out of fuel.
20161011 07:54:12< shadowm> *manage
20161011 07:55:03< tad_> shadowm, That commit  12a7a5a1e0fee21e0c88042c6b3c7be1c73f30e3 .. I can't find it.
20161011 07:55:23< shadowm> tad_: `git show -p 12a7a5a1e0fee21e0c88042c6b3c7be1c73f30e3` works for me.
20161011 07:55:39< shadowm> I'd be extremely concerned if it was missing on your end.
20161011 07:55:59< shadowm> It's even part of master (566 commits past 1.11.6).
20161011 07:56:04< tad_> I'm on windows now and I can't find it on the web site wesnoth/wesnoth master history for the file.
20161011 07:56:21< shadowm> It's probably across a file rename boundary then.
20161011 07:56:35< shadowm> https://github.com/wesnoth/wesnoth/commit/12a7a5a1e0fee21e0c88042c6b3c7be1c73f30e3
20161011 07:57:21< shadowm> And it is. I had used log -p on the parent dir, that's why it was readily visible.
20161011 07:58:22< shadowm> Normally one would get around this with --follow.
20161011 07:58:59< shadowm> (Oh and yeah, as you can probably already tell, I almost never use GitHub to look at history I have on my own disk drive.)
20161011 07:59:05< tad_> Ah. Funny clang has/had a problem with the unused variables but VC and GCC don't. I s'pose I should add clang to my toolset to check that.
20161011 08:00:07< tad_> shadowm, Well git on windows is ssllooww .. like 30 to 45 seconds to 'git status' ..
20161011 08:00:17< tad_> s/on/on my/
20161011 08:00:17< JyrkiVesterinen> Likely Clang just has more advanced detection for unused variables.
20161011 08:01:17< tad_> Well, it's an upstream. Better would be to suppress the error for the lua directory. We're compiling a C source as C++ you have to expect junk like that.
20161011 08:01:49< shadowm> Back then it was likely compiled as C, actually.
20161011 08:02:15 * tad_ nods.
20161011 08:02:15< shadowm> I don't think we ever forced the compiler to compile *.c as C++.
20161011 08:03:17< tad_> Well, that's coming. I'm thinking the upgrade to Lua 5.3 will be a delete/add and add the switches to compile it as C++.
20161011 08:07:15< tad_> Part of the reason I am trying to get the Lua as clean as possible against the upstram is, if the time comes, it will make it a LOT easier to switch to LuaJIT
20161011 08:07:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 08:10:29-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161011 08:10:46< tad_carlucci> Well, that's something I didn't expect.
20161011 08:10:50-!- Kwandulin [~Miranda@p200300760F2C71B220B6163B6364B398.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161011 08:11:03< tad_carlucci> liblua.lib(lapi.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1800' doesn't match value '1900' in about.obj
20161011 08:11:28< tad_carlucci> So I guess I have some work to do on Windows.  Tomorrow.
20161011 08:11:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20161011 08:11:53 * tad_carlucci waves
20161011 08:11:54-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Client Quit]
20161011 08:12:21-!- tad_ [~lundberg@173.217.65.103] has quit [Ping timeout: 248 seconds]
20161011 08:12:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161011 08:21:19< vultraz> hm
20161011 08:21:41< vultraz> I am faced with a conundrum... 
20161011 08:22:35< vultraz> so, there;s an allow_player key that effects mp
20161011 08:22:56< vultraz> so you can specify whether a side allows a player, or not...
20161011 08:23:54< vultraz> and hides the side in mp game creation
20161011 08:24:03< vultraz> but I don't think anyone considered the no_leader key :/
20161011 08:24:18< zookeeper> a good "no leader" image could be the random leader silhouette, with the ? replaced with a red X or something
20161011 08:24:54< vultraz> so I'm not sure if i should make game creation only show a side if allow_player = true AND no_leader = false
20161011 08:25:14< vultraz> zookeeper: what do you think
20161011 08:25:27< zookeeper> about what?
20161011 08:25:40< zookeeper> oh, that
20161011 08:26:32< zookeeper> well i don't know the limitations so can't say
20161011 08:26:54< zookeeper> does allow_player=no actually hide the side in game creation?
20161011 08:27:06< vultraz> yes
20161011 08:27:09< vultraz> unless you're in debug mode.
20161011 08:27:33< zookeeper> mmkay
20161011 08:27:35< vultraz> but if you load up and sp campaign you can sometimes get sides with no leader displaying
20161011 08:27:46< vultraz> and yes, I know sp campaign loading is currently hidden in debug mode
20161011 08:27:54< vultraz> but still, this brings up a valid point
20161011 08:28:26< zookeeper> so is it possible to let a player play a no_leader=yes side?
20161011 08:28:54< vultraz> well, you cannot actually pick a leader
20161011 08:29:09< vultraz> since there are no leaders to choose from
20161011 08:29:21< vultraz> but it would still show up
20161011 08:29:40< zookeeper> so that's a yes?
20161011 08:32:27-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20161011 08:33:36< VultCave> in gui1, at least, and shown grayed out
20161011 08:33:57< VultCave> so you cannot play it
20161011 08:34:07< VultCave> but it's shown in the list disabled
20161011 08:34:10< VultCave> outside of debug mode
20161011 08:34:12< VultCave> so I think I will make it so no_leader sides do not
20161011 08:34:15< VultCave> display outside debug mode
20161011 08:34:37-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20161011 08:36:19-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Disconnected by services]
20161011 08:36:21-!- VultCave is now known as vultraz
20161011 08:36:23-!- Aginor_ [~andreas@apollo.alternating.net] has joined #wesnoth-dev
20161011 08:36:27-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20161011 08:36:27-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161011 08:36:47-!- ShikadiLord [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20161011 08:36:52< DeFender1031> is there a reason why no_leader shouldn't automatically imply allow_player=false?
20161011 08:37:47< vultraz> I suppose that could be done...
20161011 08:39:51< DeFender1031> On the other hand, that would further solidify the whole thing of "the game doesn't make it easy to have leaderless sides"
20161011 08:40:41-!- crimson_pingvin [~crimson_p@ec2.happyspork.com] has joined #wesnoth-dev
20161011 08:41:28-!- Netsplit *.net <-> *.split quits: shadowm, crimson_penguin, timotei_, Elsi_, Sirp, Aginor, zookeeper, EliDupree, new_one_
20161011 08:41:28-!- crimson_pingvin is now known as crimson_penguin
20161011 08:41:28-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has quit [Changing host]
20161011 08:41:28-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20161011 08:44:05-!- irker850 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161011 08:44:05< irker850> wesnoth: Charles Dang wesnoth:master 5aaa9bae4e54 / src/game_config_manager.cpp: Game Config Manager: [side] no_leader should not default to true if absent https://github.com/wesnoth/wesnoth/commit/5aaa9bae4e549d6161b72b8000dc7b6c5d003f4f
20161011 08:44:06< irker850> wesnoth: Charles Dang wesnoth:master ecaec3bf07b5 / src/game_initialization/ (connect_engine.cpp connect_engine.hpp): Connect Engine: include no_leader key in player allowed check https://github.com/wesnoth/wesnoth/commit/ecaec3bf07b5bf7c7f2107b803ea79270c2f32a8
20161011 08:44:07< irker850> wesnoth: Charles Dang wesnoth:master 3576f2ae43cb / src/gui/dialogs/multiplayer/mp_staging.cpp: MP Staging: fixed display of sides with no or invalid leaders https://github.com/wesnoth/wesnoth/commit/3576f2ae43cb51fc2e8a6c20ecafd0fe55cbe2d4
20161011 08:44:09< irker850> wesnoth: Charles Dang wesnoth:master 3197db5bf698 / data/gui/window/mp_staging.cfg: MP Staging: small UI tweaks https://github.com/wesnoth/wesnoth/commit/3197db5bf6981a52658734362d8c6a3f5f1e713e
20161011 08:49:52-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161011 08:49:52-!- EliDupree [~quassel@2604:a880:400:d0::9bb:2001] has joined #wesnoth-dev
20161011 08:49:52-!- Sirp [~Sirp@u17402953.onlinehome-server.com] has joined #wesnoth-dev
20161011 08:49:52-!- Elsi_ [~Elsi@luwin.ulrar.net] has joined #wesnoth-dev
20161011 08:49:52-!- new_one_ [~new_one@2604:a880:1:20::22e:d001] has joined #wesnoth-dev
20161011 08:52:20-!- ShikadiLord is now known as shadowm
20161011 08:52:54-!- Kwandulin [~Miranda@p200300760F2C71B2E0D2381B92452743.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161011 09:10:24-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161011 09:14:06-!- Kwandulin [~Miranda@p200300760F2C71B2E0D2381B92452743.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161011 09:30:36-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161011 09:32:46-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161011 09:55:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 10:00:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 248 seconds]
20161011 10:01:57-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20161011 10:04:35< shadowm>     Mandatory WML child missing yet untested for. Please report.
20161011 10:04:41< shadowm> Well, TELL ME WHAT TO REPORT THEN!?
20161011 10:05:17< zookeeper> no kidding. one of our most insightful error messages for sure :p
20161011 10:05:22< shadowm> Getting this in a nondescript piece of my own code is even worse than getting it from someone else's.
20161011 10:15:26< irker850> wesnoth: Charles Dang wesnoth:master 9be3356b890a / src/game_initialization/multiplayer.cpp: MP: Initial reimplementation of entry point selection in GUI2 https://github.com/wesnoth/wesnoth/commit/9be3356b890af3cda5e24dbc1133238f6276b7e3
20161011 10:18:28< vultraz> need to port the tree design to MP Join
20161011 10:18:45< vultraz> tedium ftw
20161011 10:20:45< shadowm> Admittedly, this is inevitable without the ability to print backtraces, for which we'd need an external library or wrapper etc. Blah blah blah too much work.
20161011 10:21:02< shadowm> Had to add breakpoints in config.cpp instead.
20161011 10:21:10< vultraz> also, rather sucks that MP Create does not display without  a window scrolbar at the standard screenshot resolution
20161011 10:21:12< vultraz> :(
20161011 10:21:31< vultraz> but we don't have time or possibly the tech to implement the proper ux fix 
20161011 10:22:23< shadowm> Whaaaaaaaaaaaaat the hell.
20161011 10:22:47< shadowm> #3  0x0000000000d27e65 in desktop::(anonymous namespace)::get_bookmarks_config () at src/desktop/paths.cpp:139
20161011 10:22:50< shadowm> #2  0x0000000000f048c1 in config::config (this=0x7fffffffb2e0, cfg=...) at src/config.cpp:461
20161011 10:22:56< shadowm> How does the constructor...?
20161011 10:23:17< shadowm> I?
20161011 10:23:18< JyrkiVesterinen> Might it be a corrupted stack trace? :/
20161011 10:23:44< shadowm> No, I'm sure it's fine (stack unwinding doesn't go haywire afterwards when the exception is thrown).
20161011 10:23:54< shadowm> #1  0x0000000000f04d87 in config::append_children (this=0x7fffffffb2e0, cfg=...) at src/config.cpp:542
20161011 10:24:01< shadowm> But apparently this is a thing the config constructor can do.
20161011 10:24:05< shadowm> For some reason.
20161011 10:24:20< vultraz> time to figure out why sp campaigns cannot start in networked mode
20161011 10:24:55< shadowm> I have:
20161011 10:24:58< shadowm>     const config& cfg = preferences::get_child("dir_bookmarks");
20161011 10:25:01< shadowm>     return cfg ? config{} : cfg;
20161011 10:25:09< shadowm> How on earth can this trip the validation?
20161011 10:25:18< shadowm> Oh wait, I know why.
20161011 10:25:26< vultraz> even though Ilce'than is assigned an ai controller
20161011 10:25:27< shadowm> It's because I got it backwards.
20161011 10:25:32< shadowm> Somehow.
20161011 10:25:57< vultraz> (is his name I, L, or I, I)
20161011 10:26:19< vultraz> IL I guess
20161011 10:26:21< shadowm> Not sure why I'm not allowed to copy the "invalid" config into a valid one, but what-ever.
20161011 10:27:00< shadowm> Hang on a moment.
20161011 10:27:14< shadowm> vultraz: Why are you messing around with AtS in MP mode? It's not for MP mode.
20161011 10:28:01< vultraz> using it as the test to see how stuff works in mp with my dialogs.
20161011 10:28:29< shadowm> You have an actual MP campaign in mainline.
20161011 10:28:31< shadowm> :\
20161011 10:28:45< vultraz> I'm testing sp campaigns
20161011 10:29:01< shadowm> You have a bazillion SP campaigns in mainline.
20161011 10:29:24< vultraz> yes, but I'd rather stare at AtS.
20161011 10:29:39< vultraz> plus it's a vigorous test case
20161011 10:29:57< vultraz> it has stuff like custom colors.
20161011 10:30:03< vultraz> empty sides
20161011 10:30:25< vultraz> anyway, I'm trying to get a networked game of AtS S1 started on the server.
20161011 10:30:35 * shadowm facepalms.
20161011 10:30:51< shadowm> Some things never change.
20161011 10:32:16-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161011 10:36:22< vultraz> ok, see, I have now found a bug because of this! :D
20161011 10:37:40< vultraz> also, for some reason it takes a *long* time
20161011 10:37:56< vultraz> for player 2 to enter the game.
20161011 10:38:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 10:39:29< vultraz> uh
20161011 10:39:30< vultraz> huh*
20161011 10:40:33< shadowm> Can I distance a forward iterator and a reverse iterator and get something meaningful?
20161011 10:40:34< vultraz> so actually, technically, sp-in-mp works!
20161011 10:40:57< vultraz> I have two clients here, one controlling galas and the other controlling Morzey.
20161011 10:41:49< JyrkiVesterinen> shadowm: I don't think so. Just convert the reverse iterator to forward iterator with base().
20161011 10:42:30< vultraz> and I can observe the two clients with a third
20161011 10:42:34< vultraz> who'd have thought
20161011 10:44:09< vultraz> ok, bug confirmed..
20161011 10:48:33< vultraz> hmmm
20161011 10:48:37< vultraz> but how to fix this..
20161011 10:52:07< shadowm> "Adds a bookmark for the selected folder or the current folder"
20161011 10:52:21< shadowm> vultraz: Suggestions?
20161011 10:52:44< shadowm> Or maybe I'll just stick to using the current folder, really.
20161011 10:53:10< shadowm> Yeah I'll just do that.
20161011 10:54:02< shadowm> Oh my.
20161011 10:54:16< vultraz> You should use "Bookmarks"
20161011 10:55:01< shadowm> No vultraz. Your answer doesn't match any questions I asked in the last 5 minutes.
20161011 10:55:28< vultraz> I'm commenting on the text in that tooltip.
20161011 10:55:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161011 10:55:43< shadowm> Same thing I said continues to apply.
20161011 10:55:57< shadowm> Unless you forgot how to grammar.
20161011 10:56:02< vultraz> You should say "Bookmarks the [..]"
20161011 10:58:49< shadowm> AND THIS IS WHY CONTEXT IS PARAMOUNT.
20161011 10:59:04< shadowm> Decided to not bother with pressing caps lock when I realized it was on.
20161011 11:01:09< shadowm> Hm.
20161011 11:02:38< shadowm> I'm imaginign things now.
20161011 11:02:55-!- knotwork [~markm@99.192.80.117] has joined #wesnoth-dev
20161011 11:02:55-!- knotwork [~markm@99.192.80.117] has quit [Changing host]
20161011 11:02:55-!- knotwork [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20161011 11:05:39< shadowm> I thought I had driven the dialog into a situation where the bookmark list and structure could be corrupted but I'm not seeing it anymore...?
20161011 11:06:05< shadowm> But maybe I was running the wrong build.
20161011 11:07:14< shadowm> And now I can't find any evidence of this in the terminal tab.
20161011 11:07:44< shadowm> Great, now I'm hallucinating bugs!
20161011 11:14:23< shadowm> Okay, updated my PR.
20161011 11:14:41< shadowm> celticminstrel: Still waiting on confirmation that the OS X version isn't horribly broken.
20161011 11:15:00-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161011 11:15:09< shadowm> Maybe eyeball that last commit extra hard since apparently I'm having some reality sync issues.
20161011 11:16:21< shadowm> (That last line is for vultraz I guess.)
20161011 11:26:50< shadowm> Okay, hold the phone, I think I just spotted the bug while rereading the code.
20161011 11:27:57< vultraz> I don't understand how this code is bugged..
20161011 11:28:40-!- Kwandulin [~Miranda@p200300760F2C71B21921683AF121C0F1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161011 11:28:57< shadowm> Yup, that was it. Pushed a fixed version.
20161011 11:29:08< shadowm> So turns out I wasn't hallucinating after all!
20161011 11:29:42< shadowm> I just somehow managed to lose the terminal tab (?) with the assertion failure.
20161011 11:30:38< shadowm> I love how I probably have a disproportionate number of private methods for such a tiny dialog.
20161011 11:31:20< shadowm> Hopefully this will pay off in a couple of years.
20161011 11:32:36< vultraz> ok, wtf 
20161011 11:32:58< vultraz> so somehow this is true when i change the controller... side->controller() == ng::CNTR_COMPUTER
20161011 11:33:18< vultraz> but that's not true when it goes to check if the side's ready??
20161011 11:38:10< vultraz> hm
20161011 11:38:11< vultraz> no
20161011 11:38:14< vultraz> that's just never called...
20161011 11:38:16< vultraz> what?
20161011 11:39:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 11:39:41< vultraz> wait
20161011 11:39:44< vultraz> know, I think, what to do
20161011 11:42:03< vultraz> ahh
20161011 11:42:04< vultraz> yes :D
20161011 11:44:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 11:46:33< irker850> wesnoth: Charles Dang wesnoth:master 0e2f05151f06 / src/gui/dialogs/multiplayer/mp_staging.cpp: MP Staging: fixed data not being processed if state had changed but no network d https://github.com/wesnoth/wesnoth/commit/0e2f05151f06db7b89889c2bfa40b15c0e4dd0dc
20161011 11:47:24< vultraz> now, let us deal with this bug with the colors
20161011 11:47:35< vultraz> in AtS E1S9, Elyssa has... Yellow
20161011 11:47:57< vultraz> GUI1 correctly displays this
20161011 11:48:01< vultraz> GUI2 has red.
20161011 11:48:03< vultraz> fuck
20161011 11:48:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20161011 11:49:28< DeFender1031> vultraz, could this be related to the bug I encountered a couple of weeks ago with ~TC()?
20161011 11:49:36< vultraz> no, I think it's my code
20161011 11:49:45< DeFender1031> okay.
20161011 11:52:23-!- gfgtdf [~chatzilla@x4e32b2c9.dyn.telefonica.de] has joined #wesnoth-dev
20161011 11:53:06< gfgtdf> vultraz: hmm what was the reason for the "make no leader default to true" commit ?
20161011 11:53:22< gfgtdf> vultraz: is there a specific sceario fixed by that ?
20161011 11:54:10< vultraz> gfgtdf: well first it seemed like a mistake that they key sets to true if it's not present. secondly, it means you cannot reliably check no_leader in ng::side_engine.cfg_
20161011 11:54:14< vultraz> since it's always true
20161011 11:54:35< gfgtdf> vultraz: its not always true, it just default to true in [scenario]
20161011 11:54:40< vultraz> i actually don't need to do that now since https://github.com/wesnoth/wesnoth/commit/ecaec3bf07b5bf7c7f2107b803ea79270c2f32a8
20161011 11:54:44< vultraz> but i think it's useful
20161011 11:54:46< vultraz> and makes more sense
20161011 11:54:48< vultraz> to be false
20161011 11:55:56< gfgtdf> vultraz: the reason why it defaults to true is that 'no leader' actualyl means 'do not use mp setup code to generate a leader if no type attribute is givend' since 1.13.3
20161011 11:56:15< gfgtdf> vultraz: and in sp ([scenario]) you usually dont want the mp setup code to mess with your code
20161011 11:56:17< irker850> wesnoth: Charles Dang wesnoth:master 066c34ae5e84 / src/game_initialization/ (connect_engine.cpp connect_engine.hpp): Connect Engine: fixed pango version of get_colors displaying incorrect values https://github.com/wesnoth/wesnoth/commit/066c34ae5e84016c4d91214745c8c4c9d0e8555f
20161011 11:56:20< vultraz> DeFender1031: that was the issue ^
20161011 11:56:59< vultraz> gfgtdf: that seems... very badly designed
20161011 11:57:36< gfgtdf> vultraz: how so? Now you just have to omit the 'type' attibute when you dotn want a leader in sp, hwile preivously you had to mess with some no_leader attribute
20161011 11:57:46< DeFender1031> vultraz, i see.
20161011 11:58:00< vultraz> gfgtdf: hm you mean no_leader is no longer needed?
20161011 11:58:44< vultraz> gfgtdf: well if you revert it would probably break ecaec3bf07b5, so would need to come up with a better solution for that
20161011 11:59:08< gfgtdf> vultraz: in sp. in [multiplayer], spüecialyl in randomly generatede maps, you usually want to omit the type= attribute and make the mp setup code generate a leader for you (from that selected faction)
20161011 11:59:46< vultraz> hm
20161011 12:00:13< vultraz> gfgtdf: well the issue ineeded it for was only about seeing sides with no_leader when you loaded an sp campaign in mp
20161011 12:00:19< gfgtdf> vultraz: what wwas teh reason for ecaec3bf07b5 in the first playce t quite possibel that oyu have leaaderless sides that can be plaed by a human, for exmapel because the give you a leader in the prestart evnet
20161011 12:00:31< vultraz> [23:00:07]	vultraz	gfgtdf: well the issue ineeded it for was only about seeing sides with no_leader when you loaded an sp campaign in mp
20161011 12:01:25< gfgtdf> vultraz: i dont see why you wouldn't want to se sides with no_leader=yes
20161011 12:01:45< DeFender1031> would it not be possible to default it one way for MP and the other for SP?
20161011 12:01:56< vultraz> well a lot of times they're used as invisible control sides
20161011 12:02:04< vultraz> or sides thatwill be filled later..
20161011 12:02:13< vultraz> so i guess it really depends on the scenario
20161011 12:02:57< gfgtdf> vultraz: i think most of the normla human sides in LoW have no_leader=yes
20161011 12:03:08< vultraz> hm
20161011 12:03:09< gfgtdf> vultraz: assuming that they are invisible control sides is just wrong
20161011 12:03:21< vultraz> i guess i should revert that then
20161011 12:03:42< gfgtdf> vultraz: you can just add allow_player=no to theose sides if you dotn want them to be shown
20161011 12:11:42-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161011 12:12:37< vultraz> gfgtdf: do you have any idea how I can preserve the settings from create if i select a new entry point?
20161011 12:13:40< gfgtdf> vultraz: hmm the prolem is that you cnnot just overwrite them with te values from the old scneario becasue you don't know which settings were left to the default and which onles where explicitly set to that new vlaue
20161011 12:16:05-!- clavi [~clavi@163-172-10-77.rev.poneytelecom.eu] has quit [Ping timeout: 248 seconds]
20161011 12:16:40-!- clavi [~clavi@163-172-10-77.rev.poneytelecom.eu] has joined #wesnoth-dev
20161011 12:17:15< vultraz> DeFender1031: ironically, I just discovered a "holy hell" design flaw in the connect engine's color handling :|
20161011 12:17:36< DeFender1031> vultraz, this sounds like a good story...
20161011 12:17:41 * DeFender1031 gets out the popcorn
20161011 12:17:56< vultraz> so, side.color() is an index...
20161011 12:18:16< vultraz> if no color= key is specified in [side], it simply increments through the 0 standard colors
20161011 12:18:40< DeFender1031> I assume you meant "9". Go on.
20161011 12:18:46< vultraz> ah, yes
20161011 12:19:05< gfgtdf> vultraz: why is that bad?
20161011 12:19:16< DeFender1031> gfgtdf, I assume that's not the end of the story.
20161011 12:19:40-!- Kwandulin [~Miranda@p200300760F2C71B21921683AF121C0F1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161011 12:19:59< vultraz> but if you DO specify a color= key, does it set the color to the appropriate index? it does not! instead, it will insert a 10th entry at the BEGINNING of the color list with may be a duplicate of any other color on the list. so say you do color="purple". the list will read Purple, Red, Blue, Green, Purple...... and side.color() is set to 0!. So if you then try to use that index to TC a...
20161011 12:20:00< vultraz> ...sprite, you'll get red!
20161011 12:20:02< vultraz> :|
20161011 12:20:33< vultraz> because, of course, ~TC respects the standard color index order!
20161011 12:20:41< vultraz> when passed a number!
20161011 12:20:56 * vultraz throws up hands
20161011 12:21:04< gfgtdf> vultraz: you sure this happens in the gui1 mo connect code aswell ?
20161011 12:21:10< DeFender1031> What in the name of something with a name was the person wrote that code thinking?!
20161011 12:21:25< DeFender1031> vultraz, are the "standard indexes" used for anything?
20161011 12:21:56< DeFender1031> vultraz, that also doesn't explain why TC for sides 2-6, which also had custom colors set, worked correctly, but side 7 did not.
20161011 12:23:05< vultraz> gfgtdf: the gui1 dialog didn't try to TC any sprites, so I think it's there but never discovered
20161011 12:25:22< vultraz> DeFender1031: TC-by-index was the old method for allying TC before someone came along and duplicated them with string ids.
20161011 12:25:27< vultraz> applying*
20161011 12:25:37< vultraz> it's kept around since it's useful to have in certain cases
20161011 12:26:05< DeFender1031> vultraz, indeed. I had to work around the issue by wrapping to looking up the side's color string and using ~RC instead.
20161011 12:26:19< DeFender1031> though being able to just use the side index would have been cleaner
20161011 12:26:48< vultraz> I actually am using RC here, actually.
20161011 12:27:00< DeFender1031> but that still doesn't explain why ~TC worked right for some but not others.
20161011 12:27:07< vultraz> ~RC(src>index) does work.
20161011 12:27:45< DeFender1031> oh, i wasn't aware that that would go to team index. I assumed that'd go to whatever [color_range] had that id.
20161011 12:27:46< vultraz> just that if there's a "custom color" the index here will always be 0 :|
20161011 12:28:05< vultraz> DeFender1031: the color ranges do have numerical IDs
20161011 12:28:26< vultraz> ie, color range id=red and id=1 are the same
20161011 12:28:52< DeFender1031> right, i was saying, i assume ~RC(src>1) would always be red, even if side 1 has a custom color set, since the color with the id "1" is red.
20161011 12:29:02-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20161011 12:29:06< vultraz> (yes
20161011 12:29:08< vultraz> yes*
20161011 12:29:19< vultraz> which is why I will need to use the proper string id here
20161011 12:29:19< DeFender1031> whereas ~TC should, presumably, color based on what the given sides ACTUAL color is.
20161011 12:29:29< DeFender1031> side's*
20161011 12:29:38< vultraz> hmm
20161011 12:29:48< vultraz> let us see!
20161011 12:30:16< DeFender1031> and like i was saying, in my case, it WAS using the actual color for sides 1-6, but somehow giving the default for side 7
20161011 12:31:02< vultraz> nah, tc not working here
20161011 12:31:20< vultraz> I'm going to refactor this absolute mess :|
20161011 12:31:41< DeFender1031> please do :P
20161011 12:36:49< vultraz> hmmmm
20161011 12:36:54< vultraz> how best to do this...
20161011 12:38:34< vultraz> so, IIUC, it's the fact that there are color ranges with the IDs "1" to "9" that gives the colors their order
20161011 12:39:38< vultraz> that's why there's that '9' limit for the number of colors
20161011 12:39:49< vultraz> since otherwise, there isn't really a good way to iterate in order :|
20161011 12:40:31< DeFender1031> It could use ids 1 to 50 just as easily though, no?
20161011 12:40:42< DeFender1031> (assuming 10-50 existed as well)
20161011 12:40:49< vultraz> sure
20161011 12:41:21< vultraz> it seems colors are stored in a map of <string, t_string> which is essentially id, name
20161011 12:42:14< vultraz> the connect engine takes numbers 1 to 9, makes them strings, and performs color lookup...
20161011 12:43:36< vultraz> I can perform color lookup directly with the color= key, yes...
20161011 12:43:44< vultraz> but I still need a good way to generate the list...
20161011 12:45:12< vultraz> ok
20161011 12:46:05< vultraz> what do I need the color index for
20161011 12:46:12< vultraz> selecting an entry in the color dropdown
20161011 12:58:30< vultraz> ah, I see the problem here..
20161011 12:59:21< vultraz> there is, essentially, no parity between the color ranges "1" and "red", except that they happen to have the same color values..
20161011 13:00:29< vultraz> I wonder if std::stio would be any use here...
20161011 13:00:56< vultraz> er, wait, no
20161011 13:00:58< vultraz> don't need that..
20161011 13:02:12< vultraz> ok, going to need to go deeper
20161011 13:05:42< vultraz> I got it
20161011 13:05:47< vultraz> well, in theory
20161011 13:05:51< vultraz> now to implement..
20161011 13:07:51-!- Appleman1234_ [~Appleman1@KD106154018160.au-net.ne.jp] has joined #wesnoth-dev
20161011 13:10:44-!- Appleman1234 [~Appleman1@KD106154010119.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20161011 13:10:53-!- Appleman1234_ is now known as Appleman1234
20161011 13:11:12-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 260 seconds]
20161011 13:27:28-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161011 13:29:31-!- Appleman1234 [~Appleman1@KD106154018160.au-net.ne.jp] has quit [Remote host closed the connection]
20161011 13:39:16-!- Appleman1234 [~Appleman1@KD106154018160.au-net.ne.jp] has joined #wesnoth-dev
20161011 13:42:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161011 13:57:36< vultraz> DeFender1031: I have done it :D
20161011 13:58:21< DeFender1031> vultraz, what have you done?
20161011 13:58:36< vultraz> I have successfully refactored this
20161011 13:58:45< vultraz> commit coming momentarily
20161011 14:01:54< DeFender1031> Does that mean TC should now use the actual current color for that side rather than being wonky?
20161011 14:03:52< vultraz> that's a different bug, I think :P
20161011 14:06:16-!- Bonobo [~Bonobo@2001:44b8:254:3200:1d2e:ccd5:5f75:5131] has quit [Quit: Leaving]
20161011 14:07:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 14:14:06< irker850> wesnoth: Charles Dang wesnoth:master 396267c9009f / data/game_config.cfg src/game_config.cpp src/game_config.hpp: Game Config: added default_color_list= key https://github.com/wesnoth/wesnoth/commit/396267c9009f4cacc0892bfed5b61074c2182686
20161011 14:14:09< irker850> wesnoth: Charles Dang wesnoth:master f37bf48562ba / src/game_initialization/ (connect_engine.cpp connect_engine.hpp): Connect Engine: refactored handling of colors https://github.com/wesnoth/wesnoth/commit/f37bf48562ba5994f49f9e92a00b705d13ddbe98
20161011 14:14:12< irker850> wesnoth: Charles Dang wesnoth:master 0d864e07ac99 / src/gui/dialogs/multiplayer/mp_staging.cpp: MP Staging: updated color handling to match new connect engine functionality https://github.com/wesnoth/wesnoth/commit/0d864e07ac991a880bc8107d05521798c5d761e9
20161011 14:15:23< vultraz> gfgtdf: ^ this means 9 is no longer a hardcoded max number of colors in the connect engine as long as you dont  use get_colors (which is used by gui1 and as such will be removed after the release)
20161011 14:17:43< vultraz> DeFender1031: you'll have to provide me some more details on your bug if i am to look into it
20161011 14:18:29-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161011 14:18:54< DeFender1031> vultraz, i actually have to go soon and i'll be AFK for the next day or so, but i'll put together a test case when I get back.
20161011 14:19:01< vultraz> ok, sure
20161011 14:19:14-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20161011 14:19:39< vultraz> important thing is that the color handling in the connect engine is no longer totally retarded
20161011 14:20:22< DeFender1031> yeah, that is certainly good
20161011 14:25:36-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 268 seconds]
20161011 14:33:30< celticminstrel> shadowm: Sorry, the OSX version of what? I forgot.3
20161011 14:34:05< celticminstrel> (Also, the simpler listbox::add_row is for when you're using a toggle_button instead of a toggle_panel. Or if you only need to set things in the toggle_panel, I suppose.)
20161011 14:38:40< vultraz> celticminstrel: the bookmark pr i think
20161011 14:38:49-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has quit [Ping timeout: 260 seconds]
20161011 14:40:15-!- DeFender1031 [~DeFender1@46-116-17-86.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20161011 14:42:31-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has joined #wesnoth-dev
20161011 14:45:34< irker850> wesnoth: Charles Dang wesnoth:master 3cd9d3436921 / src/game_initialization/ (connect_engine.cpp connect_engine.hpp): Revert "Connect Engine: include no_leader key in player allowed check" https://github.com/wesnoth/wesnoth/commit/3cd9d34369213ee6c868632129f88057b605e68b
20161011 14:45:37< irker850> wesnoth: Charles Dang wesnoth:master a1e602003fc3 / src/game_config_manager.cpp: Revert "Game Config Manager: [side] no_leader should not default to true if abse https://github.com/wesnoth/wesnoth/commit/a1e602003fc3e18ceda0f3bbc4bc5cd833867f7c
20161011 14:45:40< vultraz> gfgtdf: ^
20161011 14:46:31< celticminstrel> Oh, okay
20161011 14:57:07-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161011 14:59:28< gfgtdf> vultraz: it looks liek side_engine::get_color is now borken
20161011 15:01:03< gfgtdf> vultraz: also i just noticed that mpstatigng uses side->color()  rather than side->get_color()
20161011 15:02:13< gfgtdf> vultraz: i think the bug in the previous implementation was balsically that mp_Stating used side->color()  rather than side->get_color()
20161011 15:18:28-!- gfgtdf [~chatzilla@x4e32b2c9.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161011 15:19:40-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161011 15:54:13-!- gfgtdf [~chatzilla@x4e32b2c9.dyn.telefonica.de] has joined #wesnoth-dev
20161011 16:04:22-!- vincent_c [~bip@vcheng.org] has quit [Quit: Coyote finally caught me]
20161011 16:04:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 16:05:07-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20161011 16:12:24-!- boucman_work [~boucman@159.195.204.77.rev.sfr.net] has quit [Read error: Connection reset by peer]
20161011 16:42:17-!- JyrkiVesterinen [~JyrkiVest@87-100-182-88.bb.dnainternet.fi] has joined #wesnoth-dev
20161011 16:47:43-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161011 16:57:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161011 16:57:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 17:02:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20161011 17:05:36-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161011 17:05:37-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161011 17:06:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 17:08:22-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161011 17:11:00< irker850> wesnoth: mattsc wesnoth:master 7834b25b5779 / data/ai/micro_ais/cas/ (ca_forest_animals_move.lua ca_forest_animals_tusklet_move.lua): Forest Animals Micro AI: move only one unit per execution https://github.com/wesnoth/wesnoth/commit/7834b25b577953644d322173da938faf4abff620
20161011 17:12:04-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20161011 17:12:05-!- wedge010 is now known as wedge009
20161011 17:21:55< celticminstrel> I'm so behind on looking over commits added to master. >_>
20161011 17:29:25-!- mjs-de [~mjs-de@x4e31e62b.dyn.telefonica.de] has joined #wesnoth-dev
20161011 17:29:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 17:32:55-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161011 17:47:26-!- iceiceice [~chris@50-245-222-235-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20161011 17:47:26-!- iceiceice [~chris@50-245-222-235-static.hfc.comcastbusiness.net] has quit [Changing host]
20161011 17:47:26-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20161011 17:48:12< iceiceice> shadowm, i wanted to ask you a question about the mp server
20161011 17:48:45< iceiceice> so, one of the annoying things about 1.12 server recently (last few months) is that sometimes you will order an attack on a unit, and the game will lag
20161011 17:48:56< iceiceice> like, for 30 seconds or a minute
20161011 17:49:28< iceiceice> then it will proceed normally
20161011 17:49:45< iceiceice> i dont know why this would happen, currently the only theory i have is that the mp server runs out of entropy
20161011 17:50:08< iceiceice> and needs time to acquire in /dev/random
20161011 17:50:09< celticminstrel> Why is the server's entropy relevant?
20161011 17:50:18< iceiceice> because the server generates randomness used
20161011 17:50:21< iceiceice> for any attack or recruit
20161011 17:50:24< iceiceice> since 1.12
20161011 17:50:28< celticminstrel> Uhh. Really?
20161011 17:51:03< tad_carlucci> And access to the entropy source takes a few micro seconds.
20161011 17:51:08< celticminstrel> But even if that's true, entropy shouldn't be an issue.
20161011 17:51:12< celticminstrel> It doesn't need any entropy.
20161011 17:51:18< celticminstrel> It just needs a Mersenne twister.
20161011 17:51:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161011 17:51:34< iceiceice> celticminstrel i don't recall exactly how we set it up
20161011 17:51:35< celticminstrel> There's not need to have true randomness for a game.
20161011 17:51:38< celticminstrel> ^no
20161011 17:51:42< gfgtdf> iceiceice: i think the 1.12 server just uses rand()
20161011 17:51:45< iceiceice> i agree but i dont recall if we coded that
20161011 17:51:59< iceiceice> idk if there are useful logs that can help debug something like this?
20161011 17:52:04< iceiceice> its quite difficult to reproduce locally
20161011 17:52:53< iceiceice> tad_carlucci, no, if you poll dev/random it can take seconds if it is exhausted
20161011 17:53:06< iceiceice> if you poll /dev/urandom it is supposed to be guaranteed to return in microseconds
20161011 17:53:32< iceiceice> if it's not an issue with rng blocking, then honestly that's pretty unfortunate
20161011 17:53:40< iceiceice> because that means this will be very difficult to improve
20161011 17:54:13< gfgtdf> iceiceice: do you know whther other people goit this issue too? And does it only happen when the server is full?
20161011 17:54:23< iceiceice> yes, you can ask any regular mp player
20161011 17:54:47< iceiceice> it *might* be related to when the server shuts down, i'm not sure
20161011 17:54:57< gfgtdf> full like in 'a lot of player/games running'.
20161011 17:55:14< iceiceice> that's kind of hard to judge, there is not a counter of how many games are running usually
20161011 17:55:40< iceiceice> i dont think it particularly has to do with the server being busy
20161011 17:55:52< gfgtdf> iceiceice: can you do chat or receive chat while waiting the 30 mins ?
20161011 17:56:10< iceiceice> its not 30 min, its like 30 sec to a min
20161011 17:56:19< iceiceice> i'm not totally sure if you can send / recieve chat
20161011 17:56:25< iceiceice> usually people just chat "lag"
20161011 17:56:27< gfgtdf> yes i meant 30 secs
20161011 17:56:42< iceiceice> any order like, recruiting or attacking will cause the lag
20161011 17:56:46< iceiceice> i think moving is usually okay
20161011 17:56:50< iceiceice> thats why i thought it was rng related
20161011 17:56:58< iceiceice> usually what happens is your unit moves to the hex to attack
20161011 17:57:03< iceiceice> but then it doesn't actually attack
20161011 17:57:11< iceiceice> and the ui is in the "command locked" position
20161011 17:57:29< iceiceice> so you can mouse over things but you cannot issue new attacks or look at the stats window
20161011 17:57:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 17:58:01< gfgtdf> iceiceice: yes but moving unit haooens completeley locally, unless there is a moveto event with does rnadom stuf [set_variable]rand= it wont be sendted to the server before it is completed
20161011 17:58:19< iceiceice> yes that's why it hought it was rng related
20161011 17:58:36< iceiceice> but yah maybe its just the server blocking on handling traffic
20161011 17:58:55< iceiceice> i'm not sure how to get more info
20161011 17:59:55< iceiceice> is there like a server log file?
20161011 18:00:08< iceiceice> iirc when we run locally it writes some log data to a text file
20161011 18:00:45< iceiceice> it might be helpful to take a look at it when the lag happens
20161011 18:00:49< zookeeper> tad_carlucci, WRT https://github.com/wesnoth/wesnoth/pull/799/commits/ecb26b03d957b3b918235e8d039dcbf4281bc635 <- the reason for the per-hex variables was to ensure that spawns only happen once from a given village, instead of repeating if you capture it, enemy recaptures, you recapture.
20161011 18:01:57< gfgtdf> iceiceice: there is this page https://www.wesnoth.org/cgi-bin/drraw/drraw.cgi?Mode=view;Dashboard=1381050100.25669 but it doesnt really show how exhausted the server is
20161011 18:03:03< iceiceice> gfgtdf: i guess what i am talking about is like, the STDERR output of the wesnothd process on the server
20161011 18:03:10< iceiceice> it would be nice if we (developers) could get access to that somehow
20161011 18:03:21< iceiceice> like if it was just posted similar to wesnoth.org/irclogs or something
20161011 18:04:52< gfgtdf> iceiceice: afaik only shadowm has acces to that currently.
20161011 18:04:58< tad_carlucci> zookeeper, That is incorrect. The reason for the variables was unknown. The spawns are specifically programmed to respawn. See the deleted capture event just under "Pop up random bandits [...]" at the top of the commit.
20161011 18:05:15< iceiceice> gfgtdf: i think anyone with password to wesnoth server has that actually
20161011 18:05:16< tad_carlucci> zookeeper, I can change it if you feel 1.12 is wrong.
20161011 18:06:40< zookeeper> tad_carlucci, ah okay. that's something that was added after copying the code from DiD, so i didn't think it was there.
20161011 18:06:45< gfgtdf> iceiceice: hmm ye Soliton, loonycyborg, Rhonda might also have access to it.
20161011 18:09:17< zookeeper> tad_carlucci, so technically, yes the reason for the variables was what i said (i'd know because i wrote it :p), but when someone copied that code to THoT they didn't want that functionality so they added that deleted capture event to workaround it.
20161011 18:10:35< tad_carlucci> Most likely. I don't know why they showed up as artifacts since they're cleared but it cleaned up the logic so I went with it.
20161011 18:13:34< zookeeper> tad_carlucci, for https://github.com/wesnoth/wesnoth/pull/799/commits/1f6259921 , are you aware that they will still receive one random trait?
20161011 18:15:31< tad_carlucci> zookeeper, Yes, is that a problem? My intention was only to add loyal. Again, if you want a change, I can.
20161011 18:15:43< zookeeper> i don't care
20161011 18:16:54< tad_carlucci> Actually, since the used to get one random, if I'd have broken that I'd have backed out the loyal. But I'm using the fact elsewhere instead of setting a variable.
20161011 18:17:44< zookeeper> what does look a bit suspicious is losing the ability to recruit mages if and only if those two die. that doesn't really seem to be communicated to the player clearly, as far as i see.
20161011 18:18:38< tad_carlucci> Never was, but good point. I'll look at adding something real quick
20161011 18:19:14< zookeeper> could just name them in the message that explains it
20161011 18:19:24< zookeeper> "journeymen" is kind of too vague
20161011 18:19:31 * tad_carlucci nods.
20161011 18:20:04< tad_carlucci> That bothered me, too.
20161011 18:29:56< zookeeper> other than that i didn't spot anything objectionable. whether it all works, i don't know, since i was just glossing over them.
20161011 18:32:01< tad_carlucci> Well, I try to test. I probably miss some edge cases, but, hopefully between code reading and testing I found them all.
20161011 18:32:52 * tad_carlucci is switching to Unix and THoT
20161011 18:32:54-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Leaving]
20161011 18:35:13-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161011 18:45:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20161011 18:47:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 18:51:22< tad_carlucci> zookeeper, First thought: at the point Master Perrin sends one/two apprentice add a line from Perrin: While they are with you, you will have mages at your call.
20161011 18:51:40< tad_carlucci> zookeeper, "journeyman"/"journeymen" there makes sense.
20161011 18:52:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20161011 18:52:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 18:55:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161011 18:56:35-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 19:00:34-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161011 19:09:21< tad_carlucci> zookeeper, THoT PR updated, added 1 commit to name the mages. If that is all, it should be ready, now.
20161011 19:13:01-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161011 19:21:21< Shiki> Do I have to checkout the whole repo if I want to make a PR? Had to delete my clone because I screwed up sth with git, now downloading with ~40KB/s
20161011 19:25:02< tad_carlucci> Shiki, Did you delete the .git directory or the entire wesnoth directory?
20161011 19:28:13< tad_carlucci> Shiki, Once git has the repo copied, I'd do a checkout of master and git status to make sure you're clean. If you did not delete the old checked-out files that should be fairly fast. Otherwise, yes, it will create them all over again.
20161011 19:29:39< Shiki> I deleted the whole folder, containing the git repo
20161011 19:32:14< Shiki> Originally I made a git pull --rebase on my fork instead of an git pull upstream master --rebase, aborted it inbetween, and ended up with stuff staying in between. So I did what I usually do when I meet such problems, starting over with cloning... 
20161011 19:32:17< Shiki> But I saved the changed files
20161011 19:32:36< tad_carlucci> Then it won't matter if you checkout master or checkout a new branch, all the files will be created.  I'd do 'git checkout -b mynewbranch' but that won't same more than a few seconds if I checked out master, then created the branch. Either way git will create all the files.
20161011 19:33:44< tad_carlucci> I did that. Next time, be sure you're working on a branch. Them, save your changes, checkout master, delete -D the branch, check it out, and apply your changes.
20161011 19:34:53< Shiki> ok
20161011 19:35:23< Shiki> usually I just work on master and make little changes
20161011 19:35:31< tad_carlucci> It's a lot harded if you push the bad branch up but you can still recover from it.
20161011 19:36:05< tad_carlucci> I would recommend ALWAYS work on a branch and keep master cleanly in sync with upstream/master
20161011 19:37:01< tad_carlucci> If you make a mistake and change master, you can make a branch from the changes then back them out of master.
20161011 19:38:43< tad_carlucci> Don't feel bad, we all mess up our local copies at least once, especially when we're first learning git. You rarely need to wipe it out, but that's often the first reaction.
20161011 19:39:18< Shiki> I see. In this case. git log showed me the "old" commits on top. If I would have made a new branch afterwards, and then switched back to master, it would have been ok?
20161011 19:40:17< zookeeper> okay, 30 commits incoming...
20161011 19:40:25 * tad_carlucci covers his eyes.
20161011 19:40:34< tad_carlucci> Shiki, wait for the stormg to clear ...
20161011 19:40:45< irker850> wesnoth: Gregory A Lundberg wesnoth:master 397880d80d40 / data/campaigns/The_Hammer_of_Thursagan/scenarios/05_Invaders.cfg: THoT Remove variable artifacts https://github.com/wesnoth/wesnoth/commit/397880d80d40590eab96ead349f2c258818a7a4b
20161011 19:40:47< irker850> wesnoth: Gregory A Lundberg wesnoth:master 5674af58be11 / data/campaigns/The_Hammer_of_Thursagan/scenarios/02_Reclaiming_the_Past.cfg: THoT S02 Angarthing joins Aiglondur https://github.com/wesnoth/wesnoth/commit/5674af58be1145ca39799dbd9041741c57a64820
20161011 19:40:50< irker850> wesnoth: Gregory A Lundberg wesnoth:master 8fa0ba9bf2b6 / data/campaigns/The_Hammer_of_Thursagan/scenarios/03_Strange_Allies.cfg: THoT S03 Marth-Tak cannot be dead https://github.com/wesnoth/wesnoth/commit/8fa0ba9bf2b6e422305b8521440a411d88090c88
20161011 19:40:52< irker850> wesnoth: Gregory A Lundberg wesnoth:master 31da3d2aff93 / data/campaigns/The_Hammer_of_Thursagan/scenarios/04_Troll_Bridge.cfg: THoT S04 No pile of gold https://github.com/wesnoth/wesnoth/commit/31da3d2aff93148c9766818dfdc5a395d4e17ac3
20161011 19:40:53< irker850> wesnoth: Gregory A Lundberg wesnoth:master 58cf481945af / data/campaigns/The_Hammer_of_Thursagan/lua/spawns.lua: THoT S05 Fix bug: Deprecated Lua function https://github.com/wesnoth/wesnoth/commit/58cf481945afddade4ebb5c90195d546e38e7675
20161011 19:40:55< irker850> wesnoth: Gregory A Lundberg wesnoth:master 90b2c79861e2 / data/campaigns/The_Hammer_of_Thursagan/scenarios/05_Invaders.cfg: THoT S05 Fix bug: Variable artifacts https://github.com/wesnoth/wesnoth/commit/90b2c79861e26ae644c883c68027284c2c4e84c5
20161011 19:40:57 * Shiki searching for cover
20161011 19:40:57< irker850> wesnoth: Gregory A Lundberg wesnoth:master 8c3c557791e6 / data/campaigns/The_Hammer_of_Thursagan/scenarios/05_Invaders.cfg: THoT S05 Fix bug: No unit for role https://github.com/wesnoth/wesnoth/commit/8c3c557791e6cf4e923cd2592dbc66b3ce6f6a0c
20161011 19:41:00< irker850> wesnoth: Gregory A Lundberg wesnoth:master 3300dd3a7ac4 / data/campaigns/The_Hammer_of_Thursagan/lua/spawns.lua: THoT S05 Fix bug: Lua error https://github.com/wesnoth/wesnoth/commit/3300dd3a7ac49aa4e3b1828b7210af21f0418236
20161011 19:41:02< irker850> wesnoth: Gregory A Lundberg wesnoth:master 0cf9ba68dfd5 / data/campaigns/The_Hammer_of_Thursagan/ (lua/spawns.lua scenarios/05_Invaders.cfg): THoT S05 Fix bug: Too chatty https://github.com/wesnoth/wesnoth/commit/0cf9ba68dfd5da5a08fdf81bbad098270d0798ac
20161011 19:41:03< irker850> wesnoth: Gregory A Lundberg wesnoth:master dff12f8ae4c7 / data/campaigns/The_Hammer_of_Thursagan/scenarios/06_High_Pass.cfg: THoT S06 Fix bug: Missing objective https://github.com/wesnoth/wesnoth/commit/dff12f8ae4c73ac88f5e3198632e8feeeb3b3c91
20161011 19:41:05< irker850> wesnoth: Gregory A Lundberg wesnoth:master d4e65aef81e7 / data/campaigns/The_Hammer_of_Thursagan/scenarios/06_High_Pass.cfg: THoT S06 Fix bug: No Ratheln https://github.com/wesnoth/wesnoth/commit/d4e65aef81e7d40e4154fd1dabed1fbf40bf76ec
20161011 19:41:07< irker850> wesnoth: Gregory A Lundberg wesnoth:master 9db28696db5d / data/campaigns/The_Hammer_of_Thursagan/scenarios/06_High_Pass.cfg: THoT S06 Clean up target shroud https://github.com/wesnoth/wesnoth/commit/9db28696db5dc3aeedf614c058b383defdffdc91
20161011 19:41:09< irker850> wesnoth: Gregory A Lundberg wesnoth:master ce00a489193d / data/campaigns/The_Hammer_of_Thursagan/scenarios/07_Mages_and_Drakes.cfg: THoT S07 Fix bug: Units do not appear https://github.com/wesnoth/wesnoth/commit/ce00a489193d750e365a916b292301914f16f082
20161011 19:41:12< irker850> wesnoth: Gregory A Lundberg wesnoth:master f274beced428 / data/campaigns/The_Hammer_of_Thursagan/scenarios/07_Mages_and_Drakes.cfg: THoT S07 Fix bug: Units too late https://github.com/wesnoth/wesnoth/commit/f274beced428ad9eb872a3d08df5434c8681c0a5
20161011 19:41:13< irker850> wesnoth: Gregory A Lundberg wesnoth:master a373ee334bf8 / data/campaigns/The_Hammer_of_Thursagan/scenarios/07_Mages_and_Drakes.cfg: THoT S07 Mages are loyal https://github.com/wesnoth/wesnoth/commit/a373ee334bf8bab1db61e783a66b1510e1703e33
20161011 19:41:15< irker850> wesnoth: Gregory A Lundberg wesnoth:master 2c390ac20bab / data/campaigns/The_Hammer_of_Thursagan/scenarios/ (06_High_Pass.cfg 07_Mages_and_Drakes.cfg): THoT S07 Fix bug: Ratheln is a defeat condition https://github.com/wesnoth/wesnoth/commit/2c390ac20babe9d3c84165722d626f4260cd2057
20161011 19:41:18< irker850> wesnoth: Gregory A Lundberg wesnoth:master ab890425a0d2 / data/campaigns/The_Hammer_of_Thursagan/scenarios/07_Mages_and_Drakes.cfg: THoT S07 Ratheln leaves earlier https://github.com/wesnoth/wesnoth/commit/ab890425a0d2da5b1dc1ccfe060300c2a7b08812
20161011 19:41:20< irker850> wesnoth: Gregory A Lundberg wesnoth:master d089940f01e5 / data/campaigns/The_Hammer_of_Thursagan/ (7 files in 2 dirs): THoT Fix bug: Disallow Mage immediately https://github.com/wesnoth/wesnoth/commit/d089940f01e5c8bc49c89e3ecd74574661389004
20161011 19:41:21< irker850> wesnoth: Gregory A Lundberg wesnoth:master 3a3133629223 / data/campaigns/The_Hammer_of_Thursagan/scenarios/08_Fear.cfg: THoT S08 Fix bug: Villages don't just appear https://github.com/wesnoth/wesnoth/commit/3a3133629223e965cd729b6fe3b505f4aa003cef
20161011 19:41:23< irker850> wesnoth: Gregory A Lundberg wesnoth:master 2b5e9933c1ee / data/campaigns/The_Hammer_of_Thursagan/scenarios/08_Fear.cfg: THoT S08 Fix bug: No Ollin https://github.com/wesnoth/wesnoth/commit/2b5e9933c1ee8cf09d36a90caadfc484b821cf29
20161011 19:41:26< irker850> wesnoth: Gregory A Lundberg wesnoth:master 65405a6e00dd / data/campaigns/The_Hammer_of_Thursagan/scenarios/09_Forbidden_Forest.cfg: THoT S09 Fix bug: There can be only one https://github.com/wesnoth/wesnoth/commit/65405a6e00ddcb36cb8baa12d3a0ed9e0a2cddbf
20161011 19:41:28< irker850> wesnoth: Gregory A Lundberg wesnoth:master 3afb622136e1 / data/campaigns/The_Hammer_of_Thursagan/utils/macros.cfg: THoT S09 Find the staff https://github.com/wesnoth/wesnoth/commit/3afb622136e1babb8f7c909f6fbc22a6533334cd
20161011 19:41:29< irker850> wesnoth: Gregory A Lundberg wesnoth:master 743943c993ad / data/campaigns/The_Hammer_of_Thursagan/utils/macros.cfg: THoT S09 Use type_tree https://github.com/wesnoth/wesnoth/commit/743943c993ad171bdabdeb21a270b191ed3fd6eb
20161011 19:41:32< irker850> wesnoth: Gregory A Lundberg wesnoth:master 23e712ab84af / data/campaigns/The_Hammer_of_Thursagan/scenarios/10_The_Siege_of_Kal_Kartha.cfg: THoT S10 Be more specific https://github.com/wesnoth/wesnoth/commit/23e712ab84af041584841630e63d7828392d8e15
20161011 19:41:34< irker850> wesnoth: Gregory A Lundberg wesnoth:master 5379783c7b4b / data/campaigns/The_Hammer_of_Thursagan/scenarios/10_The_Siege_of_Kal_Kartha.cfg: THoT S10 Where is the West Gate https://github.com/wesnoth/wesnoth/commit/5379783c7b4b93146c8855e26562a46460a5c424
20161011 19:41:36< irker850> wesnoth: Gregory A Lundberg wesnoth:master 29934ea2af5f / data/campaigns/The_Hammer_of_Thursagan/ (scenarios/11_The_Court_of_Karrag.cfg units/Dwarvish_Rune_Lord.cfg): THoT S11 Fix bug: Karrag does not change https://github.com/wesnoth/wesnoth/commit/29934ea2af5f8a881538929e158f558e45638321
20161011 19:41:38< irker850> wesnoth: Gregory A Lundberg wesnoth:master 28adedf49902 / data/campaigns/The_Hammer_of_Thursagan/scenarios/13_Epilogue.cfg: THoT S13 Fix bug: Visual artifacts https://github.com/wesnoth/wesnoth/commit/28adedf49902f67bbb290aaa9f3991f046c7fd5d
20161011 19:41:40< irker850> wesnoth: Gregory A Lundberg wesnoth:master 31bd5fcb1ff5 / data/campaigns/The_Hammer_of_Thursagan/scenarios/12_The_Underlevels.cfg: THoT S12 Note no turn limit https://github.com/wesnoth/wesnoth/commit/31bd5fcb1ff5d6d5d1a61aa78094f035731c4251
20161011 19:41:42< irker850> wesnoth: Gregory A Lundberg wesnoth:master 8dd84fb01f61 / data/campaigns/The_Hammer_of_Thursagan/ (scenarios/08_Fear.cfg scenarios/12_The_Underlevels.cfg utils/macros.cfg): THoT S12 Fix bug: Masked Dwarf names https://github.com/wesnoth/wesnoth/commit/8dd84fb01f6195e109a0702724e8a732123b5ec4
20161011 19:41:44< irker850> wesnoth: Gregory A Lundberg wesnoth:master c3006b5321db / data/campaigns/The_Hammer_of_Thursagan/scenarios/07_Mages_and_Drakes.cfg: THoT S07 Name the journeymen https://github.com/wesnoth/wesnoth/commit/c3006b5321dbe46ace61717b19d1e47097ac37a0
20161011 19:41:46< irker850> wesnoth: Lari Nieminen wesnoth:master b1fb517614a2 / data/campaigns/The_Hammer_of_Thursagan/ (15 files in 4 dirs): Merge pull request #799 from GregoryLundberg/GL_THoT https://github.com/wesnoth/wesnoth/commit/b1fb517614a2e96578a4c757e64696d7b9aea1c2
20161011 19:41:59< matthiaskrgr> :o
20161011 19:42:11< tad_carlucci> And, now, I can clear out another branch! YEAH!
20161011 19:45:03< tad_carlucci> Shiki, You could have adjusted your master back in sync without a wipeout. There's a number of howtos about it. Google is your friend.
20161011 19:45:08< shadowm> iceiceice, gfgtdf: I gave loonycyborg access and instructions (the other two would have to figure things out) for the purpose of debugging wesnothd after the asio port.
20161011 19:45:24< shadowm> iceiceice, gfgtdf: And no-one has password access, not even me.
20161011 19:46:24-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161011 19:46:35< shadowm> iceiceice, gfgtdf: The log isn't public because it contains IP addresses and ban logs.
20161011 19:46:44< Shiki> tad_carlucci, ahhh, of course. head -> wall
20161011 19:47:04< shadowm> celticminstrel: Of the bookmarks PR.
20161011 19:48:42< shadowm> Aginor_: Did you see the update to https://bugzilla.libsdl.org/show_bug.cgi?id=3096 ?
20161011 19:49:37-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Remote host closed the connection]
20161011 19:50:30-!- mkdroid [~null@unaffiliated/matthiaskrgr] has joined #wesnoth-dev
20161011 19:51:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 19:56:55< Aginor_> shadowm: I did, I am most pleased
20161011 19:57:03< Aginor_> shadowm: I haven't had time to look at the patch though
20161011 19:57:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161011 19:59:32 * tad_carlucci notes his work plan for upgrading to Lua 5.3 has reached 'delete src/lua and copy in 5.3 sources' ...
20161011 19:59:40 * tad_carlucci takes a DEEP breath ...
20161011 19:59:46< tad_carlucci> Boy, I hope this works ...
20161011 20:00:28-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Ping timeout: 260 seconds]
20161011 20:01:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 20:05:08-!- mkdroid [~null@unaffiliated/matthiaskrgr] has quit [Quit: I'll be back!]
20161011 20:05:34-!- JyrkiVesterinen [~JyrkiVest@87-100-182-88.bb.dnainternet.fi] has quit [Quit: .]
20161011 20:06:32-!- Shiki [~Shiki@141.39.226.226] has quit [Ping timeout: 260 seconds]
20161011 20:11:46-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161011 20:27:01< Aginor_> tad_carlucci: experience says it'll not be entirely smooth :D
20161011 20:27:34< tad_carlucci> Aginor_, I'm sure it won't but one can always hope.
20161011 20:28:49-!- Shiki [~Shiki@141.39.226.226] has quit [Ping timeout: 268 seconds]
20161011 20:30:22< tad_carlucci> Aginor_, My GL_Lua and GL_Lua2 changesets moved as much of the clutter aside as possible. What was left was local changes to luaconf.h .. many/most/all of which won't be needed for 5.3.3 .. the changeout should go easy. But I expect the change will let the smoke out somewhere and there will be fires to put out all over the place.
20161011 20:34:31-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161011 20:34:58< Aginor_> that is traditional
20161011 20:37:46-!- Aginor_ is now known as Aginor
20161011 20:37:56-!- Aginor [~andreas@apollo.alternating.net] has quit [Changing host]
20161011 20:37:56-!- Aginor [~andreas@unaffiliated/aginor] has joined #wesnoth-dev
20161011 20:40:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20161011 20:40:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20161011 20:43:39-!- clavii [~clavi@163-172-10-77.rev.poneytelecom.eu] has joined #wesnoth-dev
20161011 20:45:16-!- clavi [~clavi@163-172-10-77.rev.poneytelecom.eu] has quit [Ping timeout: 260 seconds]
20161011 20:49:10-!- Shiki [~Shiki@141.39.226.226] has quit [Ping timeout: 268 seconds]
20161011 20:49:36-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161011 21:12:24-!- iwaim [~iwaim@124.146.179.10] has quit [Ping timeout: 260 seconds]
20161011 21:16:13-!- mjs-de [~mjs-de@x4e31e62b.dyn.telefonica.de] has quit [Remote host closed the connection]
20161011 21:17:17-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20161011 21:18:36< gfgtdf> shadowm: do you have an idea what coudl habve caused these lags in 1.12 ?
20161011 21:19:17< gfgtdf> shadowm: in teh last few months
20161011 21:25:13-!- iwaim [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev
20161011 21:26:33< shadowm> Depends on the time of day, really.
20161011 21:27:27< shadowm> And day of the week.
20161011 21:29:14< gfgtdf> iceiceice: ^
20161011 21:29:32< shadowm> It's pretty much impossible for me to say anything more useful without more information. I neither play MP or keep an eye on the MP server since as you know I've been pretty much absent here since March.
20161011 21:31:05-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20161011 21:32:53< shadowm> Plus, to give you an example, the log isn't as verbose as you might expect: http://pastebin.com/3wd8uv6u
20161011 21:34:54< gfgtdf> shadowm: that looks like it doesn't contain more information that the publig log at https://www.wesnoth.org/irclogs/2016/10/%23wesnoth-mp-lobby-stable.2016-10-11.log
20161011 21:35:15< shadowm> It contains more information, just not what you'd be looking for.
20161011 21:35:31< shadowm> Otherwise I'd not have had to redact several bits in there.
20161011 21:36:25< shadowm> Also, if it helps: 
20161011 21:36:27< shadowm>     03:27:49 shadowm@wesnothd:~$ uname -a
20161011 21:36:32< shadowm>     Linux wesnothd 2.6.32-19-pve #1 SMP Wed May 15 07:32:52 CEST 2013 x86_64 GNU/Linux
20161011 21:36:44< shadowm> *cue shock and horror* (Nope, can't do anything about it.)
20161011 21:40:46< gfgtdf> shadowm, iceiceice: i wonder whther we could somehow measure the time each pagage needs to be processed and log it if it took to long or whether doing this woudl slow the server down too much.
20161011 21:42:05< shadowm> Not much I can do there other than rebuild/patch and restart the server, etc. I've never been able to look at wesnothd's code for too long.
20161011 21:43:14< shadowm> vultraz: Okay, now users can enter labels for their bookmarks.
20161011 21:43:32< shadowm> So they don't all inevitably end up being labeled "maps".
20161011 21:43:44< shadowm> "maps" "maps" "maps" "map".
20161011 21:43:59< shadowm> Decided that this wouldn't be very nice.
20161011 21:44:40< tad_carlucci> shadowm, Why "can't do anything about it" ???
20161011 21:59:19< shadowm> I'm going to ignore that question for now because I don't feel like having another argument about semantics with one of the other admins.
20161011 22:00:26< shadowm> It is partially related to that backup thing I explained last time, if you were around. If not, well *shrug*.
20161011 22:00:40< tad_carlucci> shadowm, I understand. Upgrading a remote host's kernel is rather scary. And I recall the backup thing.
20161011 22:01:35< shadowm> If it were just a matter of upgrading the kernel alone it'd not be such a problem, but there's a lot of other things tied to it, and it's not a stock distribution or vanilla kernel.
20161011 22:02:59< tad_carlucci> I hate that. There's always some gotcha. "Why didn't you see we'd hacked that into the kernel source?" Like you're supposed to diff the source to see what was changed and know it's mission critical.
20161011 22:04:06< shadowm> Okay, you successfully coerced me into giving you the full answer with all those assumptions.
20161011 22:04:15< tad_carlucci> Nah. That's OK.
20161011 22:04:18< shadowm> We use Proxmox VE, a virtualization and containerization solution.
20161011 22:04:35< shadowm> For containers, it uses an OpenVZ-based kernel.
20161011 22:05:07< shadowm> Upgrading the kernel alone isn't feasible because literally everything would break without OpenVZ.
20161011 22:05:41< shadowm> Newer Proxmox (and kernels) do not use OpenVZ and use LXC instead.
20161011 22:06:56< shadowm> Upgrading without being able to restore from an off-site backup if something breaks during the process would be highly disastrous to say the least.
20161011 22:07:11< shadowm> Sure, there are local backups. On the same RAID array as everything else.
20161011 22:07:36< shadowm> So someone could take the risk and perform the upgrade without offsite backups and potentially doom us all. I'm not going to be that someone.
20161011 22:08:19< shadowm> As we all know, filesystem or RAID or LVM drivers aren't exactly failsafe and things can and will break if you hit an unpatched/unreported bug.
20161011 22:09:06< shadowm> It was just a couple of months ago that I got hit by a filesystem-level bug on my own desktop for the first time in 11 years of using Linux.
20161011 22:09:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20161011 22:09:41< shadowm> Furthermore, it has never been my responsibility to tend to the Proxmox host infrastructure, that's the other admins'.
20161011 22:10:45< shadowm> And I don't want to do like last time and assume responsibility for a single project and then be de facto tied to it forever.
20161011 22:10:57 * tad_carlucci smiles.
20161011 22:12:04< shadowm> Anyway, the Internet seems to says that if we are using /dev/random for time-critical stuff we should not be doing that.
20161011 22:12:10< shadowm> *say
20161011 22:12:57< shadowm> I have no clue how the wesnothd RNG works (or the client's RNG, for that matter!) so that's all I can say.
20161011 22:13:35-!- tad_carlucci [~lundberg@173.217.65.103] has quit [Quit: Leaving]
20161011 22:13:54-!- tad_carlucci [~lundberg@173.217.65.103] has joined #wesnoth-dev
20161011 22:14:10< gfgtdf> shadowm: i wone think we use dev/random like that on the server, we might call dev/random once for each started game in 1.13 but thts all.
20161011 22:14:17< gfgtdf> shadowm: 1.12 just uses rand()
20161011 22:14:43< shadowm> Starting a game on the MP server still counts as a time-critical task.
20161011 22:15:40< shadowm> If that task blocks for several seconds, it's going to keep the participating clients waiting, and pretty much everyone else trying to start a game at the same time really.
20161011 22:16:19< celticminstrel> Line 44 of RELEASE_NOTES is horrible, BTW.
20161011 22:16:26< tad_carlucci> Is there a single point where we read /dev/random? My first thought would be to confirm or deny that's the issue by adding logging before and after to compare the time it took. If the games lag and it shows no lag then it's not /de/vrandom
20161011 22:16:26< matthiaskrgr> do you guys want a bugticket with current gcc7-dev warnings on wesnoth build?
20161011 22:16:49< celticminstrel> That's not really a nice substitute.
20161011 22:17:53< tad_carlucci> matthiaskrgr, Are there a lot?
20161011 22:18:00< matthiaskrgr> there were some 
20161011 22:18:13< matthiaskrgr> it was mostly wimplicit fallthorough iirc
20161011 22:18:29< matthiaskrgr> I still have to compile it :P 
20161011 22:19:01< shadowm> Did anyone look into the test suite UB? Guess not, because I still get the invalid free() crash with -O0.
20161011 22:19:42< celticminstrel> vultraz: 1f1855300dad676b44f9b85aaed3f44a60954d92 needs to be fixed.
20161011 22:20:04< celticminstrel> You removed the [stack] tag altogether, which is unacceptable.
20161011 22:20:07< tad_carlucci> matthiaskrgr, While it might be good to look at them, if it's mainly fall-through warning I have a feeling most of them will garner comments about being overly-pedantic.
20161011 22:20:25< vultraz> celticminstrel: what? why?
20161011 22:20:34< celticminstrel> Because it breaks every addon ever that uses a stacked widget.
20161011 22:20:52< celticminstrel> What you need to do is check if there's a [stack] tag, and if so, issue a deprecation warning and get the layers from there.
20161011 22:20:56< vultraz> I don't think the stacked widget was exposed to lua.
20161011 22:21:24< celticminstrel> I don't remember whether it was exposed to Lua, but it's certainly possible for addons to use widgets that are not exposed to Lua.
20161011 22:21:34< celticminstrel> They just can't manipulate them.
20161011 22:21:58< shadowm> All widgets are "exposed" to Lua insofar they can be included in a dialog's definition, yes.
20161011 22:22:00< celticminstrel> I'll look for my commit to see if that covered stacked widgets... it's still a good idea to do it, but it's not super important if you're correct.
20161011 22:22:43< shadowm> The thing is that stacked widgets didn't have anything to manipulate before 1.13.0 or 1.13.1 I think.
20161011 22:23:07< shadowm> When I added the layer switch option in C++.
20161011 22:23:20< celticminstrel> Okay, in that case I'd say you need the deprecation test.
20161011 22:23:21-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 22:23:44< shadowm> You could still use them to achieve weird layouts like the titlescreen's though.
20161011 22:24:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20161011 22:25:01< shadowm> By the way, no OS X build of #821 yet?
20161011 22:25:21< shadowm> Or platform-agnostic code review?
20161011 22:25:46< celticminstrel> Not yet, but I imagine I'll get to reviewing it in the next little while.
20161011 22:26:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161011 22:26:39< shadowm> vultraz: Code review?
20161011 22:26:40< matthiaskrgr> tad_carlucci: at 12 % :  6 wimplicit-falltrough;  1 -Wformat-length
20161011 22:28:10< vultraz> curious to see celticminstrel's comments on my commits from last night
20161011 22:29:41< tad_carlucci> matthiaskrgr, Does not sound too bad, then. The format-length warning is probably important.
20161011 22:29:42< celticminstrel> There's a "?" picture that could work for leaderless sides, right?
20161011 22:30:45< vultraz> right now they display nothing
20161011 22:30:46< loonycyborg> proxmox maintains a log of load of all vms iirc, memory use etc
20161011 22:30:47< vultraz> which is good.
20161011 22:31:00< vultraz> the Unknown Unit image needs to be redrawn
20161011 22:31:02< tad_carlucci> matthiaskrgr, I'd say wait til it's done and do a PR on those which seem important to fix before GCC 7 comes out.
20161011 22:31:13< loonycyborg> that could be checked to debug that lag
20161011 22:31:22< celticminstrel> You can still use it even if it needs to be redrawn.
20161011 22:31:50< matthiaskrgr> http://pastebin.com/raw/5dwgMdT9     
20161011 22:31:51< shadowm> vultraz: https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20161011_193129.png
20161011 22:32:03< shadowm> vultraz: What would you do with the bookmark controls in read-only mode?
20161011 22:32:25 * celticminstrel curious what that looks like on Windows.
20161011 22:33:44< vultraz> shadowm: leave them be. bookmarks are unrelated to the content or mode of content being displayed, they're just there to help the user.
20161011 22:34:22< shadowm> So you aren't bothered by the empty space?
20161011 22:34:41< vultraz> between the + and -?
20161011 22:34:49< shadowm> To the right of both.
20161011 22:35:22< vultraz> no, that's fine.
20161011 22:35:29< tad_carlucci> matthiaskrgr, Ah. the format string is worried about variable c being char when unsigned char would be better.
20161011 22:35:47< shadowm> vultraz: Are you actually vultraz?
20161011 22:36:14< vultraz> Yes, without his coffee.
20161011 22:36:23< shadowm> The real vultraz would never not be bothered by a huge chunk of unused space.
20161011 22:37:13< vultraz> shadowm: the alternative (moving the controls into the bookmarks column) is worse, since then in non-read-only mode the buttons are not consistent
20161011 22:37:25< vultraz> ly placed
20161011 22:37:56< shadowm> That could be worked around with some clever grid swapping but I don't want to make the layout even more complex than it already is by wrapping the bookmarks bar in a grid with a placeholder at the bottom.
20161011 22:37:58< celticminstrel> So why did you revert those two commits?
20161011 22:38:15< celticminstrel> (Also, sorry - I don't have any comments on the colours thing.)
20161011 22:38:24< gfgtdf> celticminstrel, vultraz: [stacked_widget] ist supported in lau in 1.12
20161011 22:38:25< vultraz> celticminstrel: gfgtdf's request
20161011 22:38:38< celticminstrel> gfgtdf: What?
20161011 22:38:46< gfgtdf> celticminstrel, vultraz: in particular one of my own addons uses it
20161011 22:38:47-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161011 22:38:54< celticminstrel> So you're saying it is supported?
20161011 22:39:07< shadowm> celticminstrel: Here's the answer to your Windows question: https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20161011_193844.png
20161011 22:39:08< celticminstrel> Then we need that deprecation support.
20161011 22:39:17< gfgtdf> celticminstrel, vultraz: you cna use [stacked_widget] to force a minmum size of a widget
20161011 22:39:31< gfgtdf> celticminstrel, vultraz: like in the GUI_FORCE_WIDGET_MINIMUM_SIZE  macro, that same can be done in lua
20161011 22:39:31< celticminstrel> So it shows drive letters and drive labels?
20161011 22:39:38< celticminstrel> Nice.
20161011 22:39:39< shadowm> I can readily see that the antialiasing is worse on Windows.
20161011 22:39:57< shadowm> gg vultraz.
20161011 22:40:28< celticminstrel> So it's PR 821 right?
20161011 22:40:35< shadowm> Just look at the 'w' in "network" above. :p
20161011 22:40:42< vultraz> fuck fuck fuck fuck fuck
20161011 22:40:49< shadowm> celticminstrel: Yes.
20161011 22:41:25< shadowm> celticminstrel: There's nothing this fancy for OS X yet, I'm afraid. Just an entry for /Volumes, like /media and/or /mnt on Linux/BSD.
20161011 22:42:07-!- irker850 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161011 22:42:44< celticminstrel> Okay, done with commits, moving onto PRs.
20161011 22:42:51< shadowm> I decided to leave writing a better OS X version as an exercise for the reader.
20161011 22:43:22< celticminstrel> "reader"? :p
20161011 22:44:59< celticminstrel> It might make a lot of sense to name the "Volumes/" entry from the computer's host name. (At least, I think host name is the term I'm looking for.) In the Finder, there is a view named in that way which shows all mounted volumes plus "Network".
20161011 22:46:13< gfgtdf> celticminstrel: do you know how to get an instance of the ai lua table for the ai functions
20161011 22:47:00< gfgtdf> celticminstrel: in 1.12 i mean
20161011 22:47:36 * tad_carlucci crosses his fingers.
20161011 22:47:59< celticminstrel> In 1.12 it's passed as an argument to your script.
20161011 22:48:00< tad_carlucci> First trial-run compiling Lua 5.3.3 into Wesnoth.
20161011 22:48:26< celticminstrel> The wesnoth.debug_ai(side_num) function also returns it.
20161011 22:48:43< celticminstrel> But you should generally not use that.
20161011 22:49:35< gfgtdf> celticminstrel: to use it outside of an ai side, i know about wesnoth.debug_ai but afak that only works in debug mode
20161011 22:49:53< gfgtdf> celticminstrel: is there a way to get the ai table without having an ai side in your scneario ?
20161011 22:51:12< shadowm> celticminstrel: If it matches what `hostname` in the command line yields and has to be a DNS-valid name, then it's the host name. Otherwise it might be some freeform string like Windows' computer description option.
20161011 22:51:45< celticminstrel> shadowm: It's the output of "hostname" minus the .local suffix.
20161011 22:52:09< celticminstrel> gfgtdf: I don't think there's any way besides debug_ai. I think that does work out of debug mode in 1.12, but not in 1.13.
20161011 22:52:12< shadowm> Then it's probably the hostname.
20161011 22:52:31< shadowm> ("local" is probably the default domain.)
20161011 22:53:02< celticminstrel> gfgtdf: One possibility for 1.13 would be to add a "fallback to human" function to the AI table. Then you could write an AI that just stores the table somewhere and then lets a human player take over.
20161011 22:53:14< celticminstrel> shadowm: The default TLD, sure.
20161011 22:53:30< celticminstrel> Windows, somewhat annoyingly, does not use it.
20161011 22:53:38< tad_carlucci> Not always .local I've seen .localnet and some others
20161011 22:54:16< gfgtdf> celticminstrel: ok thy
20161011 22:59:46< vultraz> dammit
20161011 22:59:48< vultraz> I can't remember
20161011 22:59:58< vultraz> what bug i was supposed to work on
20161011 23:00:18< tad_carlucci> Now THAT is a target-rich environment.
20161011 23:01:05< vultraz> i remember putting something aside to work on today
20161011 23:02:26< vultraz> perhaps it was moving the Join dialog to the tree mode
20161011 23:04:26< vultraz> well, that has to be done anyway
20161011 23:05:11< tad_carlucci> I feel like I just jumped from an airplane with no parachute. I'm about to break out of the clouds and hope I put the landing bag in the right place .. scons strict is running and no errors so far ..
20161011 23:09:18-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161011 23:13:23< vultraz> i should write a common helper class for some of this functionality
20161011 23:14:07< vultraz> but that would be work!
20161011 23:17:28-!- vultraz changed the topic of #wesnoth-dev to: 1.13.6 planned for Sunday, October 16th | 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
20161011 23:18:01< vultraz> Giving everyone a little more time to finish their stuff.
20161011 23:18:01< tad_carlucci> Why not just say "Four days from now, and holding" ???
20161011 23:18:16< vultraz> tad_carlucci: because I don't want to change the topic every day :P
20161011 23:18:41< Shiki> will make a PR tomorrow 
20161011 23:18:54< vultraz> we still have some PRs to merge
20161011 23:18:58< vultraz> i have some mp stuff to deal with
20161011 23:19:14< tad_carlucci> vultraz, You keep pushing it back and I'm going to be done with the Lua upgrade.
20161011 23:19:14< vultraz> celticminstrel needs to look at that flg dialog issue
20161011 23:19:25< vultraz> (blocker)
20161011 23:19:40< vultraz> and I want the bookmark functionality in the release
20161011 23:20:04< vultraz> tad_carlucci: ETA?
20161011 23:20:42< tad_carlucci> vultraz, Unknown. First-ever compile is running. "OK so far" as I pass the 50th floor.
20161011 23:20:56< vultraz> It might be worth seeing if it can be in the release..
20161011 23:21:13< vultraz> Since it will likely be ~2 months or so before the next release.
20161011 23:21:22< vultraz> And we need that time for bug reports.
20161011 23:21:56< vultraz> It's why I need to finish this MP stuff
20161011 23:24:38< tad_carlucci> vultraz, The question is when you want the fireworks to start. 
20161011 23:24:57< vultraz> We need bug reports as early as possible.
20161011 23:25:20< tad_carlucci> "Nothing works! What did you do!" is what I expect right now.
20161011 23:25:48< vultraz> we have ~5 months left at a generous estimate, for 1.14.
20161011 23:25:48-!- Shiki [~Shiki@141.39.226.226] has quit [Ping timeout: 268 seconds]
20161011 23:26:25< vultraz> We should be aiming for RC no later than mid-February. 
20161011 23:26:57< vultraz> and there's still so much to do!
20161011 23:27:28< tad_carlucci> Well, if I get a clean compile and can play through HttT (random cave sounds like a good test) I'll put up a PR. We're going to want people on MP tring to get OOS errors from the float/integer changes.
20161011 23:27:28< vultraz> not just development-wise
20161011 23:28:05< vultraz> website update, forum backend update, bug tracker migration, steam release prep, announcement page design...
20161011 23:28:33< tad_carlucci> Sure am glad I didn't volunteer for all that :D
20161011 23:29:26< vultraz> and I'm not even sure of the status of the first 2
20161011 23:29:57< vultraz> I have to deal with the third, and I think I'm going to go with GH since no one has provided the service comparison.
20161011 23:30:16< vultraz> release prep, that's something we'll have to deal with with our packagers and the Board...
20161011 23:30:19< shadowm> vultraz: We absolutely need private bugs.
20161011 23:30:31< vultraz> the last... well, that's simpler
20161011 23:30:40< shadowm> If that's not something GitHub can provide then GitHub should be ruled out.
20161011 23:30:48< vultraz> we already did a major design update for 1.12
20161011 23:30:54< shadowm> s/should/must/
20161011 23:31:17< vultraz> But I need to convince the Board to throw money at  LB for a splash art commission.
20161011 23:31:37< vultraz> rest of the Board*
20161011 23:32:21< vultraz> we need to finalize the details of a deal for a new iOS port..
20161011 23:32:22< tad_carlucci> I do love running VMs instead of native. The compile pushed my CPUs and drives too hard and just caused a thermal shutdown. A can of air and a few minutes to cool down and back up without missing a beat.
20161011 23:32:29< vultraz> (we = the board)
20161011 23:33:18< vultraz> not to mention setting up an avenue for donations...
20161011 23:34:34< vultraz> We should get to work writing and designing the update page no later than January. 
20161011 23:35:35< tad_carlucci> Maybe what you should do is write up a plan with action items and commit it. Or use some of these new features of GitHub about projects?
20161011 23:35:43< vultraz> shadowm: anything new on the forum update?
20161011 23:35:59< vultraz> (and yes, your concern re the tracker is noted and I shall keep it in mind)
20161011 23:36:03< shadowm> Nah, I still haven't started doing the hard part.
20161011 23:36:18-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161011 23:36:22< shadowm> There's really quite a lot of documentation to read.
20161011 23:36:35< shadowm> We'll also lose functionality.
20161011 23:37:07< shadowm> I reserve the right to disclose the specifics for now, though, since things can change in the meantime.
20161011 23:40:36-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 268 seconds]
20161011 23:41:29-!- Shiki [~Shiki@141.39.226.226] has quit [Ping timeout: 265 seconds]
20161011 23:42:54-!- Shiki [~Shiki@141.39.226.226] has joined #wesnoth-dev
20161011 23:49:45< shadowm> Well, since vultraz died I'm just going to leave this here and see if anyone can spot the differences: https://dl.dropboxusercontent.com/u/21371130/screenshots/Screenshot_20161011_204918.png
20161011 23:59:02< shadowm> Oh my, I just realized that doofus-01's Li'sar is in.
20161011 23:59:14< tad_carlucci> And BOOM! Tad augers into the dirt! Well, it's not MY problem ... lua/lobject.cpp:283:24: error: invalid conversion from ‘const char*’ to ‘char*’
20161011 23:59:33 * tad_carlucci sighs
--- Log closed Wed Oct 12 00:00:53 2016