--- Log opened Thu Aug 25 00:00:52 2016
20160825 00:01:26-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has joined #wesnoth-dev
20160825 00:10:42-!- Shiki [~Shiki@141.39.226.227] has quit [Remote host closed the connection]
20160825 00:14:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 00:22:12< mattsc> celticminstrel: did you figure out what is causing this: https://github.com/GregoryLundberg/wesnoth/issues/28 ?
20160825 00:22:47< celmin> I haven't investigated that yet.
20160825 00:23:26< mattsc> okay; will you, or do you want me to look into it?
20160825 00:23:36< mattsc> It looks like it’s more your domain than mine.
20160825 00:29:44< celmin> I'll go set breakpoints, I guess, and try TSG2.
20160825 00:32:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160825 00:37:07< mattsc> okay
20160825 00:50:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160825 00:54:54-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160825 00:55:27< tad_> celmin: OK. PR is up. "Works for me!" but needs peer-review.
20160825 00:57:34-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160825 01:06:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160825 01:07:03-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160825 01:08:00< celmin> Huh, that was surprisingly easy.
20160825 01:10:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 01:14:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160825 01:29:31-!- ancestral [~ancestral@67-4-224-82.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160825 01:53:25-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Quit: leaving]
20160825 02:47:16-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Quit: nurupo]
20160825 02:47:26-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160825 03:04:39-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 264 seconds]
20160825 03:09:57-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160825 03:10:51-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Client Quit]
20160825 03:55:14< irker098> wesnoth: Celtic Minstrel wesnoth:master 404568c21213 / src/ (9 files in 5 dirs): Fix gamestate inspector unit tests https://github.com/wesnoth/wesnoth/commit/404568c21213a826cb1cb40b07698f92a1747fc0
20160825 03:55:16< irker098> wesnoth: Celtic Minstrel wesnoth:master 679565a5fd52 / src/gui/dialogs/multiplayer/plugin_executor.hpp: Fix MP Lobby / Create unit tests https://github.com/wesnoth/wesnoth/commit/679565a5fd52c9c859167af9acf2f7644c8f7635
20160825 03:55:18< irker098> wesnoth: Celtic Minstrel wesnoth:master 22763798c7ed / changelog src/units/filter.cpp: New type_tree key in SUF - matches the unit type or its advancements https://github.com/wesnoth/wesnoth/commit/22763798c7ed840c221f2aaef4b799d29044651e
20160825 03:55:20< irker098> wesnoth: Celtic Minstrel wesnoth:master 6b3f2ac4cd74 / src/tests/gui/test_gui2.cpp: Fix spurious deprecated campaign difficulties WML from unit tests https://github.com/wesnoth/wesnoth/commit/6b3f2ac4cd74190976aab872b05c9e519931785b
20160825 04:02:45-!- JyrkiVesterinen [~JyrkiVest@87-92-44-130.bb.dnainternet.fi] has joined #wesnoth-dev
20160825 04:13:21< vultraz> sigh
20160825 04:13:29< vultraz> mp tests are still just sitting with 'playing multiplayer'
20160825 04:13:44< celmin> Locally or on Travis?
20160825 04:14:18-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160825 04:14:44< vultraz> locally
20160825 04:15:35-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160825 04:16:18< celticminstrel> That seems to mean it's stuck in the lobby...
20160825 04:16:25< celticminstrel> Uh, I mean the title screen.
20160825 04:22:33< vultraz> so I'm curious why you used constructed the tooltip for the options widgets when adding them instead of using set_tooltip
20160825 04:22:46< celticminstrel> What?
20160825 04:22:54< vultraz> in create
20160825 04:23:07< vultraz> you added the descriptions as tooltips
20160825 04:23:14< vultraz> why didn't you do set_tooltip?
20160825 04:24:02< celticminstrel> No reason. It makes no difference anyway.
20160825 04:24:38< vultraz> slight bug, though
20160825 04:24:43< celticminstrel> What?
20160825 04:24:50< vultraz> the label of an option will get the tooltip of the previous option :)
20160825 04:25:06< vultraz> since you didn't clear before adding the label
20160825 04:25:24< celticminstrel> Ah, I see what you mean.
20160825 04:25:31< celticminstrel> Wait, no.
20160825 04:25:40< celticminstrel> item is reconstructed on each loop iteration.
20160825 04:25:52< celticminstrel> Oh, wait, two levels of loops.
20160825 04:26:04< vultraz> yes, two levels
20160825 04:26:16< celticminstrel> Uhh...
20160825 04:26:23< celticminstrel> I still don't see it though?
20160825 04:27:05< celticminstrel> BTW, weren't you supposed to add the options in order using all_children_range, rather than all checkboxes followed by etc etc?
20160825 04:27:26< vultraz> I could, but I don't really like it :/
20160825 04:27:40< celticminstrel> Oh, I see, I was looking at checkboxes. That's why I didn't see it.
20160825 04:27:48< celticminstrel> The problem only exists with non-checkboxes.
20160825 04:27:57< celticminstrel> I think you should respect the order the designer chose.
20160825 04:28:16< vultraz> but it could look rather ugly :/
20160825 04:28:26< vultraz> it's nicer to group options by type anyway, for players
20160825 04:28:37< vultraz> it's visually organized and easier to parse
20160825 04:28:39< celticminstrel> It's not our job to force designers to make their scenarios pretty.
20160825 04:29:02< vultraz> granted
20160825 04:29:06< celticminstrel> And if the designer wants to group options in a certain way, we should assume they have a good reason for it.
20160825 04:29:08< vultraz> but my second point stands
20160825 04:29:53< celticminstrel> The logical grouping may be to have a checkbox followed by two sliders, followed by another checkbox and then a text field, because the first checkbox is closely related to the sliders and the second is related to the text field.
20160825 04:30:08< celticminstrel> So while your second point is, indeed, correct, it's also entirely irrelevant.
20160825 04:30:43< vultraz> I suppose
20160825 04:30:57< vultraz> sadly, doing so will also introduce another level of indent
20160825 04:31:00 * vultraz sighs
20160825 04:31:54-!- TC02 [~quassel@venus.arosser.com] has quit [Ping timeout: 260 seconds]
20160825 04:32:05< celticminstrel> In any case, designers who agree on your reasoning need only arrange their tags by type in the WML.
20160825 04:32:39< vultraz> you give designers too much credit :P
20160825 04:32:48< celticminstrel> Maybe we should offer the ability for them to insert spacers wherever they want...
20160825 04:33:49-!- travis-ci [~travis-ci@ec2-54-158-184-207.compute-1.amazonaws.com] has joined #wesnoth-dev
20160825 04:33:50< travis-ci> wesnoth/wesnoth#10551 (master - 6b3f2ac : Celtic Minstrel): The build is still failing.
20160825 04:33:50< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/154937774
20160825 04:33:50-!- travis-ci [~travis-ci@ec2-54-158-184-207.compute-1.amazonaws.com] has left #wesnoth-dev []
20160825 04:34:09< celticminstrel> I think you're not giving them enough.
20160825 04:34:52< vultraz> *coughLOTIcough*
20160825 04:35:18-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20160825 04:47:06-!- mjs-de [~mjs-de@x4db6df9c.dyn.telefonica.de] has joined #wesnoth-dev
20160825 04:56:26< irker098> wesnoth: Charles Dang wesnoth:master d63cfbf3750b / src/gui/dialogs/multiplayer/mp_create_game.cpp: MP Create: fixed options tooltips being partially assigned to wrong options https://github.com/wesnoth/wesnoth/commit/d63cfbf3750b9912776dd04f126e40b4d2e516d5
20160825 04:56:40-!- TC02 [~quassel@venus.arosser.com] has quit [Ping timeout: 250 seconds]
20160825 04:57:59< vultraz> celticminstrel: how did you get a crash with the Players slider?
20160825 04:58:02< vultraz> or did you fix that
20160825 04:59:33-!- TC02 [~quassel@venus.arosser.com] has joined #wesnoth-dev
20160825 04:59:40-!- JyrkiVesterinen [~JyrkiVest@87-92-44-130.bb.dnainternet.fi] has quit [Quit: .]
20160825 05:02:55< celticminstrel> I didn't fix it.
20160825 05:03:08< celticminstrel> I selected the basic random map, moved the slider to max, then back down.
20160825 05:04:07< vultraz> cannot reproduce
20160825 05:09:15-!- Kwandulin [~Miranda@p200300760F0533BAE0D195ED29E808EF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160825 05:09:41< vultraz> hm
20160825 05:09:53< vultraz> it seems random map settings aren't remembered once you switch away from that map
20160825 05:11:58-!- mjs-de [~mjs-de@x4db6df9c.dyn.telefonica.de] has quit [Remote host closed the connection]
20160825 05:12:09< vultraz> seems to happen in the gui1 version too..?
20160825 05:19:58< irker098> wesnoth: Charles Dang wesnoth:master 27f8bbebb7e4 / data/gui/window/mp_create_game.cfg: MP Create: add tooltip to Password field https://github.com/wesnoth/wesnoth/commit/27f8bbebb7e4c367252513b5ee38641d9ee8aa86
20160825 05:20:01< irker098> wesnoth: Charles Dang wesnoth:master 701a8dd21378 / src/gui/dialogs/multiplayer/mp_create_game.cpp: Mp Create: regenerate map when changing settings https://github.com/wesnoth/wesnoth/commit/701a8dd2137858e3b4254d72219382dcd6773865
20160825 05:20:45< vultraz> I guess I'll leave the behavior consistent for now
20160825 05:21:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 05:24:03-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 240 seconds]
20160825 05:25:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160825 05:27:11-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160825 05:28:51< vultraz> hmm
20160825 05:29:20< vultraz> if you change type with a filter applied, the filter doesn't re-apply
20160825 05:30:11< aeth> vultraz: are you messing with the menu gui stuff?
20160825 05:30:18< vultraz> what?
20160825 05:30:57< aeth> vultraz: you should add some secret hotkeys to make testing faster. lots of clicks or keypresses required to test that stuff.
20160825 05:34:08< aeth> vultraz: one thing that could save a split second is mapping the main menu to 1 2 3 4 5 6 7 8 9 0 (going over to q w e r t y or - = if it goes more)
20160825 05:35:04< celticminstrel> What?
20160825 05:35:14< aeth> (assuming SDL scankeys are used so q w e r t y makes sense on e.g. azerty keyboards)
20160825 05:35:18-!- travis-ci [~travis-ci@ec2-54-224-50-50.compute-1.amazonaws.com] has joined #wesnoth-dev
20160825 05:35:19< travis-ci> wesnoth/wesnoth#10552 (master - d63cfbf : Charles Dang): The build is still failing.
20160825 05:35:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/154943147
20160825 05:35:19-!- travis-ci [~travis-ci@ec2-54-224-50-50.compute-1.amazonaws.com] has left #wesnoth-dev []
20160825 05:35:40< aeth> celticminstrel: what I'm saying is add some hidden keyboard navigation to the main menu menus so navigating them is faster
20160825 05:35:54< aeth> the mouse travel time takes too long
20160825 05:35:57< celticminstrel> Some of the buttons at least have hotkeys already.
20160825 05:36:16< aeth> return for forward and esc for backwards doesn't work in 1.12, it might in 1.13
20160825 05:37:47< vultraz> hm..
20160825 05:38:39< vultraz> so I think the problem is that the list of rows to show expires
20160825 05:38:58< vultraz> dunno why calling the function that regenerates the list helps, though..
20160825 05:39:05< vultraz> oh
20160825 05:39:13< vultraz> yeah, ok that makes sense
20160825 05:39:29 * vultraz ponders what to do
20160825 05:41:23< vultraz> level filters are applied to all game types..
20160825 05:44:50-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 265 seconds]
20160825 05:48:13-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160825 05:50:11-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Read error: Connection reset by peer]
20160825 05:50:17-!- celmin [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160825 05:57:44< vultraz> ughh
20160825 05:57:46< vultraz> y u no work :|
20160825 06:00:26-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160825 06:06:58< celmin> I somehow got an infinite loop in the loading screen.
20160825 06:07:26< celmin> Seemed like the worker thread somehow died or something, I dunno. Not reproducible though, apparently.
20160825 06:10:00< celmin> Hmm, so about the infinit "playing multiplayer"...
20160825 06:10:04< celmin> ^+e
20160825 06:11:26< celmin> It seems that the titlescreen doesn't actually run its plugin context periodically. Instead, it calls it twice before showing the dialog.
20160825 06:12:36< celmin> But... that's in a loop, so I'm not sure if it's a problem or just a weird quirk.
20160825 06:15:11< vultraz> hm
20160825 06:15:16< vultraz> so I never use lambdas with [=]
20160825 06:15:20< vultraz> I wonder why
20160825 06:15:56< celmin> Hmm, I'm actually kind of confused how the plugin even gets a chance to yield after calling play_multiplayer...
20160825 06:16:47< celmin> Because play_multiplayer directly starts up the lobby, and by extension its plugin context.
20160825 06:17:16< celmin> I'm almost certainly missing something.
20160825 06:18:51< celmin> Oh, maybe play_multiplayer{} doesn't actually call the callback immediately but instead schedules it to be called after it yields.
20160825 06:21:15< vultraz> so I just tried this small test code:
20160825 06:21:31< vultraz> 		auto set_id = [](ttoggle_button& widget, const std::string& id) {
20160825 06:21:33< vultraz> 			widget.set_id(id);
20160825 06:21:34< vultraz> 		};
20160825 06:21:36< vultraz> it indeed works in c++11
20160825 06:22:11< celmin> Yeah, why wouldn't it?
20160825 06:22:23< vultraz> because... you implied it wouldn't?
20160825 06:22:25< vultraz> :|
20160825 06:22:37< celmin> When?
20160825 06:22:45< vultraz> earlier?
20160825 06:22:50< celmin> What did I say to imply that?
20160825 06:23:22< vultraz> [10:22:14]	celmin	Well, to assign that lambda to a variable, I think you need template variables, and if I recall correctly (which I may not), that's C++17.
20160825 06:23:39< celmin> Wasn't that a lambda with an auto parameter type?
20160825 06:23:50< vultraz> well, yes
20160825 06:24:16< vultraz> but you implied simply assigning a lambda to a variable required c++14/17 
20160825 06:24:28< celmin> Only a generic lambda, with auto parameters.
20160825 06:24:38< vultraz> I see
20160825 06:25:05< celmin> Auto parameters are C++14, I thought template variables or whatever weren't, but I guess I was wrong.
20160825 06:28:22< vultraz> still good to know we can use lambda variables at least
20160825 06:28:46< vultraz> I still don't really understand the whole variable template thing
20160825 06:31:26< celmin> Does this look alright? http://celmin.pwcsite.com/wesnoth/ts_reduced_borders.png
20160825 06:31:38< vultraz> is it like..variables with templated types?
20160825 06:31:49< celmin> Not really.
20160825 06:31:56< vultraz> then what is it?
20160825 06:32:07< celmin> It's like a "family" of variables of various types.
20160825 06:32:23< vultraz> so... a struct?
20160825 06:32:37< vultraz> (and your link doesn't work)
20160825 06:32:41< celmin> If there's one template parameter, you could think of it as a tuple of unlimited size.
20160825 06:33:28< vultraz> but you said tuples have unlimited size anyway?
20160825 06:33:43< celmin> No, any given tuple has a fixed size.
20160825 06:34:13< celmin> A template variable or whatever potentially has one element for every type imaginable.
20160825 06:34:23< celmin> (Never two elements of the same type.)
20160825 06:34:32< celmin> If you're thinking of it as a tuple or struct, that is.
20160825 06:34:43< vultraz> so like
20160825 06:34:49< vultraz> to take the example on the page
20160825 06:34:55< vultraz> template<class T>
20160825 06:34:56< vultraz> constexpr T pi = T(3.1415926535897932385);  // variable template
20160825 06:35:01< celmin> My link looks correct, so why doesn't it work for you...
20160825 06:35:04< vultraz> does that mean 'pi' can be of any type T?
20160825 06:35:24< celmin> Sort of.
20160825 06:35:42< vultraz> so pi<std::string> would be a string of pi
20160825 06:35:43< celmin> It is however constrained by its definition - only types that can be constructed from that number will work.
20160825 06:35:44< vultraz> ?
20160825 06:36:06< celmin> std::string might work, but if it does, it wouldn't be what you expect.
20160825 06:36:19< vultraz> oh?
20160825 06:36:37< celmin> std::string does not have a constructor that takes a double and represents it as a string.
20160825 06:36:56< vultraz> I see
20160825 06:37:12< celmin> The link works for me.
20160825 06:37:23< celmin> There's something wrong on your end, I think.
20160825 06:37:37< vultraz> I frequently have trouble accessing your site
20160825 06:38:19< celmin> You've never mentioned trouble before.
20160825 06:39:01< celmin> Why are you marked as away?
20160825 06:39:24< vultraz> (what if you had... template<class T> consexpr T* widget = new(twidget()). Could one then do... widget<tcontrol>= find_widget() bla?)
20160825 06:39:30< celmin> I guess a server IP isn't really something secret though. Does it work like this? http://23.226.229.74/wesnoth/ts_reduced_borders.png
20160825 06:39:44< vultraz> yes
20160825 06:39:57< vultraz> where is Cores
20160825 06:40:04< celmin> I'm moving it to prefs.
20160825 06:40:06< vultraz> and what have you done with the buttons
20160825 06:40:10< celmin> Nothing.
20160825 06:40:19< vultraz> why are they so big
20160825 06:40:28< celmin> Because you made them big.
20160825 06:40:36< vultraz> not THAT big
20160825 06:40:39< celmin> Yes you did.
20160825 06:41:02< celmin> The dark area overlapped the edge of the h.
20160825 06:41:03< vultraz> is that 800x600?
20160825 06:41:08< celmin> Yes.
20160825 06:41:46< celmin> If you haven't figured out yet what I changed, it's the padding in the dark areas.
20160825 06:42:26< vultraz> yes, the padding looks smaller..
20160825 06:42:45< vultraz> your font size is significantly smaller than mine, though
20160825 06:42:56< celmin> Oh yeah, I think I have it on 80%.
20160825 06:43:09< vultraz> ph
20160825 06:43:11< vultraz> oh
20160825 06:43:12< vultraz> whew
20160825 06:44:01-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Quit: No Ping reply in 180 seconds.]
20160825 06:44:45< celmin> I want to change the buttons to default (instead of large), but it'd be a real pain...
20160825 06:44:51< celmin> I'd have to duplicate the entire thing.
20160825 06:44:57< celmin> Just for that one little change.
20160825 06:45:19-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has joined #wesnoth-dev
20160825 06:49:17< celmin> I suppose I could make large behave the same as default if the resolution is 800x600.
20160825 06:51:36-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160825 06:52:14< celmin> Incidentally, the reason the titlescreen doesn't redraw behind dialogs is probably because it's not open.
20160825 06:52:46< celmin> Clicking any button at the titlescreen closes the dialog.
20160825 06:52:54< celmin> Well, except previous and next.
20160825 06:54:14< vultraz> ahh
20160825 06:55:57< vultraz> did you know the titlescreen's retvals are hardcoded into gui2 :|
20160825 06:56:18< celmin> Where?
20160825 06:56:55< vultraz> twindow::get_retval_by_id
20160825 06:57:21< vultraz> you should fix this
20160825 07:00:31< vultraz> especially since moving cores is relevant
20160825 07:00:36< vultraz> er
20160825 07:00:48< vultraz> you need to touch that code to move cores, I mean
20160825 07:01:09< vultraz> celmin: you should also hide the cores button if there are no custom ones
20160825 07:01:41-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160825 07:03:03< celmin> For the record, I'm putting it on the first page, right next to Cache.
20160825 07:06:39< vultraz> do you want to move Language too?
20160825 07:06:48< celmin> No, that's super-important.
20160825 07:07:11< celmin> Forcing people to go through prefs in a language they may have a poor grasp of, just to switch languages, isn't good.
20160825 07:07:21< vultraz> true
20160825 07:07:41< vultraz> FTR, I still don't agree with the existence of Cores at all
20160825 07:09:13< vultraz> it's an attempt to make wesnoth into a general gamedev platform
20160825 07:09:18< vultraz> but it's not useful at all
20160825 07:09:30 * zookeeper wonders where gfgtdf has disappeared to
20160825 07:09:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 07:10:53< vultraz> Anura and "Wesnoth 2" are far more suited to that task, since it's actually one of its goals.
20160825 07:11:09< vultraz> we really shouldn't waste effort on a feature that's not properly executes or designed
20160825 07:11:20< vultraz> on a platform where it was never intended for
20160825 07:11:28< vultraz> instead, we should focus on making our UMC platform better
20160825 07:11:30< zookeeper> vultraz, well it's useful in principle, what i disagree with is merely shoving it in the menu even when there are no additional cores installed.
20160825 07:11:44< celmin> We're not wasting effort on it. It's just sitting there.
20160825 07:11:55< celmin> zookeeper: I'm moving it to prefs, beside Cache.
20160825 07:11:56< vultraz> it's useful in theory, yes
20160825 07:11:56< zookeeper> cores are still UMC, just a different category of UMC.
20160825 07:12:06< vultraz> but in practice, it is not
20160825 07:13:10< vultraz> think of what it's for
20160825 07:13:17< zookeeper> celmin, how does that make sense though? it's not a preference any more than choosing a campaign is
20160825 07:13:19< vultraz> to replace wesnoth's core resources with something else
20160825 07:13:36< vultraz> why do we even support this :|
20160825 07:13:41< celmin> True, but it seems better than just shoving it in the menu to me.
20160825 07:13:46< vultraz> it's not WORTH it.
20160825 07:13:56< vultraz> Personally, I would propose removing it entirely.
20160825 07:14:07< zookeeper> yes everyone knows that
20160825 07:14:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160825 07:14:38< zookeeper> celmin, but what's the problem with making it visible only when you actually have cores to choose from (disregarding the failsafe core)?
20160825 07:14:40< vultraz> as I said, it's a sad attempt to turn wesnoth into a more generalized gamedev platform
20160825 07:14:53< celmin> zookeeper: I suppose that's a possibility...
20160825 07:15:06< vultraz> and I cannot understand why we keep it around
20160825 07:15:17< vultraz> what are you objections to getting rid of it, really?
20160825 07:15:19< vultraz> your*
20160825 07:15:24< celmin> Probably easier too, though I've already done most of the work anyway.
20160825 07:15:39< zookeeper> vultraz, we keep it around so that when someone wants/needs to use it, we don't need to add it back.
20160825 07:16:07< celmin> And we have evidence that there are people who want to use it, even if they're few.
20160825 07:16:25 * vultraz sighs
20160825 07:16:38< vultraz> My point is we shouldn't LET people do it :|
20160825 07:16:45 * zookeeper sighs too
20160825 07:16:48< vultraz> Not add it back
20160825 07:16:52< vultraz> Just not support it
20160825 07:17:17< zookeeper> willfully removing total conversion support from an engine that already has it is just plain dumb
20160825 07:17:47< vultraz> then do it properly :|
20160825 07:17:49< celmin> It's there and it's not hurting us and, as far as I know, it's not full of bugs (like the whiteboard).
20160825 07:18:04< celmin> Admittedly I haven't heard as much about it.
20160825 07:18:14< vultraz> it's a half-assed feature
20160825 07:18:19< vultraz> doing it right or not at all
20160825 07:18:29< vultraz> do*
20160825 07:18:43< shadowm> You can probably get your point across using more polite language to refer to it.
20160825 07:18:50< zookeeper> or actually making a point
20160825 07:19:04< zookeeper> instead of just screaming "boohoo it's baaaaaad"
20160825 07:19:56< vultraz> it's not total conversion support
20160825 07:20:05< vultraz> it's replacing resources
20160825 07:20:13< vultraz> does it replace data/ or core/ ?
20160825 07:20:29< celmin> I'm not entirely sure.
20160825 07:20:32< vultraz> what is in core/ but ... resources!
20160825 07:20:38< celmin> But probably more than just core/
20160825 07:20:38< zookeeper> that's what total conversion support means as far as i can tell
20160825 07:20:51< celmin> Or maybe not. I dunno.
20160825 07:20:56< vultraz> if it replaces data/ it also removes all of the gui code AND lua code
20160825 07:21:00< vultraz> meaning tags are broken
20160825 07:21:06< celmin> No.
20160825 07:21:07< vultraz> and the gui has to be recoded
20160825 07:21:15< vultraz> therefor, it logically does not do this
20160825 07:21:20< celmin> GUI is loaded separately.
20160825 07:21:29< celmin> So that's irrelevant.
20160825 07:21:34< vultraz> ok
20160825 07:21:37< vultraz> what about our lua code?
20160825 07:21:50< celmin> I think that's in data/_main.cfg, right?
20160825 07:22:03< celmin> The WML tags, at least.
20160825 07:22:22< vultraz> no, core/_main.cfg
20160825 07:22:29< celmin> Ah.
20160825 07:22:41< celmin> Well, custom cores are welcome to include it themselves though.
20160825 07:22:52< vultraz> without the lua, the engine is broken
20160825 07:22:58< zookeeper> yeah, seems trivial enough to include them manually
20160825 07:23:08< celmin> The engine is not broken without the Lua.
20160825 07:23:10< vultraz> honestly, this sounds more and more like an over-engineered attempt to override game_config
20160825 07:23:20< celmin> Except maybe WML tags, but those are easily included.
20160825 07:24:04< vultraz> if people want to do a total conversion they shou;d be using something other than wesnoth
20160825 07:24:27< zookeeper> if people want to do a total conversion they should use whichever game/engine that suits them best
20160825 07:24:29< vultraz> go use wesnoth2/anura that actually has proper support for this!
20160825 07:24:39< celmin> Maybe Anura doesn't do what they want.
20160825 07:24:46< vultraz> instead of us hacking together a ridiculous half-baked feature 
20160825 07:24:54< vultraz> because *one dev* wanted it
20160825 07:24:58< vultraz> you forget that :|
20160825 07:25:00< zookeeper> two
20160825 07:25:05< zookeeper> or more, i don't know
20160825 07:25:47< zookeeper> so, based on the above, GUI and lua seem to not be issues after all. what issues are there?
20160825 07:28:50-!- Kwandulin_2 [~Miranda@p200300760F05338DE0D195ED29E808EF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160825 07:29:20< celmin> Okay, if I understand correctly, the second built-in core is supposed to be "Wesnoth without addons", right?
20160825 07:29:41-!- Kwandulin [~Miranda@p200300760F0533BAE0D195ED29E808EF.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160825 07:29:59< zookeeper> that's what it says
20160825 07:30:01< celmin> But as far as I know, it doesn't actually disable addons, so should I just remove it?
20160825 07:30:33< celmin> Unless I'm wrong.
20160825 07:30:43< zookeeper> well make sure you're not wrong, first? :p
20160825 07:30:52< celmin> Supposing I'm right though.
20160825 07:33:30< zookeeper> well, in that case either it'd need to be fixed or removed. being able to temporarily disable all add-ons seems like a valuable feature, but it doesn't need to be done with core of course.
20160825 07:35:42-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 250 seconds]
20160825 07:39:12-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160825 07:39:27< vultraz> like, I dunno, implementing shadow m's addons toggle proposal?
20160825 07:39:47< vultraz> anyway, I guess I don't have more technical objections to cores right now
20160825 07:39:49< celmin> Yeah, I think that belongs more under "addons" than "cores".
20160825 07:39:53< zookeeper> whatever that is, it sounds great
20160825 07:39:53< vultraz> but i still think they were implemented poorly
20160825 07:40:03< vultraz> and I still object to it
20160825 07:40:17< vultraz> (and for the record, I could simply remove it if I wanted)
20160825 07:40:33< zookeeper> (and anyone could revert the removal)
20160825 07:40:54< vultraz> yeah, no
20160825 07:41:15< celmin> :|
20160825 07:42:13< vultraz> this project isn't an FFA
20160825 07:42:28< zookeeper> yeah exactly? :P
20160825 08:07:22-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160825 08:08:50-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160825 08:12:39-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160825 08:21:28-!- celmin is now known as celmin|sleep
20160825 08:36:29< shadowm> I thought we were moving away from that tone of discourse, not back to it.
20160825 08:36:39< vultraz> celmin|sleep: can lambdas capture by scope?
20160825 08:36:45< celmin|sleep> ?
20160825 08:36:59< vultraz> ie, 'capture everything within the scope of this function' or something
20160825 08:37:05< irker098> wesnoth: Celtic Minstrel wesnoth:master c194c41cd255 / src/tests/gui/test_gui2.cpp: Refactor GUI2 tests to allow non-static dialog-specific data to persist through  https://github.com/wesnoth/wesnoth/commit/c194c41cd255bb1f0a6e5106e74167a2eeaa8e45
20160825 08:37:07< irker098> wesnoth: Celtic Minstrel wesnoth:master 136f5a864ffd / data/gui/window/title_screen.cfg src/gui/dialogs/title_screen.cpp: Minor title screen cleanup https://github.com/wesnoth/wesnoth/commit/136f5a864ffd03905f3273787067031aec9542ee
20160825 08:37:09< irker098> wesnoth: Celtic Minstrel wesnoth:master 381200979a01 / src/ (4 files in 3 dirs): Add tests for missing dialogs https://github.com/wesnoth/wesnoth/commit/381200979a0181644325f6f481e1f0a991eb0728
20160825 08:37:11< irker098> wesnoth: Celtic Minstrel wesnoth:master 2cde73888c91 / / (5 files in 4 dirs): Tweaks to the title screen, mainly for 800x600 https://github.com/wesnoth/wesnoth/commit/2cde73888c91e599dcebaacdff1fc24ef701ed4d
20160825 08:37:11< celmin|sleep> That's what [&] or [=] does.
20160825 08:37:26< celmin|sleep> The latter captures everything by taking a copy, the former holds a reference.
20160825 08:37:34< vultraz> I see
20160825 08:38:12< celmin|sleep> If you want most by reference but some copied, you can do [&, blah]. For the reverse, [=, &blah]
20160825 08:38:45< vultraz> so if you have string a; auto bar = [&]() { a = "text"; }; bar(), 'a' will equal "text"?
20160825 08:38:55< celmin|sleep> Yse.
20160825 08:38:58< celmin|sleep> ^Yes
20160825 08:39:42< vultraz> ahh
20160825 08:39:43< vultraz> thanks
20160825 08:42:44< vultraz> hm..
20160825 08:43:00< vultraz> apparently in c++17, [*this] is a by-copy capture
20160825 08:44:28< vultraz> and [this] is by-reference
20160825 08:44:37< vultraz> I had thought [this] was capturing a pointer
20160825 08:51:39-!- Ivanovic [~ivanovic@p4FC534B6.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160825 08:53:32< JyrkiVesterinen> Semantically it doesn't make any difference if a lambda captures a variable by pointer or by reference.
20160825 08:53:51< vultraz> I suppose not
20160825 08:57:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 09:02:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20160825 09:14:26-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Remote host closed the connection]
20160825 09:22:55-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160825 09:30:18< vultraz> celmin|sleep: I don't really see the point of using Default buttons on the titlescreen at small res when the large ones fit file
20160825 09:30:22< vultraz> fine*
20160825 09:34:04-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160825 09:40:48-!- Kwandulin_2 [~Miranda@p200300760F05338DE0D195ED29E808EF.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160825 10:00:50< vultraz> celmin|sleep: this is especially bad since resolutions aren't re-selected on window resize
20160825 10:01:18< vultraz> meaning if you start wesnoth small and maximize it, your titlescreen layout will be weird :/
20160825 10:06:46< vultraz> I'm afraid I need to partially revert your commit for now.
20160825 10:06:53< irker098> wesnoth: Charles Dang wesnoth:master 1701031e1b96 / data/gui/widget/ (button_default.cfg panel_title_screen.cfg): Partially revert "Tweaks to the title screen, mainly for 800x600" https://github.com/wesnoth/wesnoth/commit/1701031e1b96c04130ccf0063de2554c885e364f
20160825 10:13:11-!- Kwandulin [~Miranda@p200300760F05338D482C897403F8B0FB.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160825 10:15:35< zookeeper> loonycyborg, jenkins seems to be failing again?
20160825 10:17:20< loonycyborg> zookeeper: seems that someone didn't update buildfiles or something
20160825 10:22:48< loonycyborg> I'll look into fixing it now
20160825 10:22:53< loonycyborg> unless it's fixed already
20160825 10:30:57-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160825 10:40:07-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160825 10:43:52-!- travis-ci [~travis-ci@ec2-54-81-200-97.compute-1.amazonaws.com] has joined #wesnoth-dev
20160825 10:43:53< travis-ci> wesnoth/wesnoth#10555 (master - 1701031 : Charles Dang): The build is still failing.
20160825 10:43:53< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/155007535
20160825 10:43:53-!- travis-ci [~travis-ci@ec2-54-81-200-97.compute-1.amazonaws.com] has left #wesnoth-dev []
20160825 10:46:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 10:50:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160825 10:54:06< vultraz> I've come up with a workaround for this thing with the load game dialog not showing leader mages properly
20160825 10:56:54< loonycyborg> zookeeper: seems the issue was already fixed, next build should be fine
20160825 10:57:05< loonycyborg> which is already in progress
20160825 10:58:07< zookeeper> loonycyborg, ok, great
20160825 10:59:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160825 11:01:08-!- Ivanovic [~ivanovic@p4FC534B6.dip0.t-ipconnect.de] has quit [Changing host]
20160825 11:01:08-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160825 11:12:13-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160825 11:13:35< irker098> wesnoth: loonycyborg wesnoth:master 5497b09321b4 / src/tests/gui/test_gui2.cpp: Fix -Wreorder warning from gcc https://github.com/wesnoth/wesnoth/commit/5497b09321b457721c99e7524e6d77b5e193cd34
20160825 11:30:19-!- horrowind [~Icedove@2a02:810a:83c0:404:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160825 11:34:17< irker098> wesnoth: Charles Dang wesnoth:master ca58a6b7c3ab / data/gui/window/game_load.cfg src/gui/dialogs/game_load.cpp src/save_index.cpp: Load Game: display all human-controlled leaders https://github.com/wesnoth/wesnoth/commit/ca58a6b7c3ab5593be72f6a8f208d1783c706a7b
20160825 11:34:25< vultraz> zookeeper: ^ is this solution acceptable?
20160825 11:40:07-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160825 11:44:26-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20160825 11:44:26-!- wedge010 is now known as wedge009
20160825 11:50:57-!- travis-ci [~travis-ci@ec2-54-81-200-97.compute-1.amazonaws.com] has joined #wesnoth-dev
20160825 11:50:58< travis-ci> wesnoth/wesnoth#10556 (master - 5497b09 : loonycyborg): The build was fixed.
20160825 11:50:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/155021287
20160825 11:50:58-!- travis-ci [~travis-ci@ec2-54-81-200-97.compute-1.amazonaws.com] has left #wesnoth-dev []
20160825 11:59:58< vultraz> :O
20160825 12:02:47< vultraz> zookeeper: also, do you think custom options in MP Create should appear by the tag order in the cfg file?
20160825 12:19:18-!- vincent_` [~bip@vcheng.org] has joined #wesnoth-dev
20160825 12:19:29-!- esr [~esr@wesnoth/developer/esr] has quit [Ping timeout: 258 seconds]
20160825 12:19:33-!- vincent_c [~bip@vcheng.org] has quit [Ping timeout: 250 seconds]
20160825 12:19:46-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20160825 12:19:46-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20160825 12:19:46-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160825 12:22:56-!- celmin|sleep [~celmin@unaffiliated/celticminstrel] has quit [Ping timeout: 258 seconds]
20160825 12:23:08-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160825 12:33:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 12:38:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160825 12:47:08< Kwandulin> celticminstrel: What's your opinion on this? https://forums.wesnoth.org/viewtopic.php?p=601252#p601252
20160825 12:51:49< vultraz> hmmm
20160825 12:51:56< vultraz> possibly a good idea, yes
20160825 13:07:44-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160825 13:15:35-!- Kwandulin [~Miranda@p200300760F05338D482C897403F8B0FB.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160825 13:21:13-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160825 13:57:42-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160825 14:35:13-!- irker098 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160825 14:42:30-!- Shiki [~Shiki@141.39.226.227] has quit [Quit: Verlassend]
20160825 14:45:57-!- fabi_ [~fabi@176.0.54.96] has joined #wesnoth-dev
20160825 14:45:59-!- fabi [~fabi@176.0.91.28] has quit [Read error: Connection reset by peer]
20160825 14:49:40-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc]
20160825 14:53:44-!- Kwandulin [~Miranda@p200300760F05338D792A95B2E268729C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160825 15:02:39< zookeeper> vultraz, i'll know if it's acceptable once i see it...
20160825 15:03:41< zookeeper> as for custom options order, i'm not sure. using the tag order seems like the most versatile way, though, since then one can order their options whichever way they want.
20160825 15:08:04< zookeeper> of course that doesn't say anything about whether option sets from different add-ons should be ordered like that, but it certainly seems less harmful than for example ordering all of them alphabetically in which case no logical grouping whatsoever would be possible.
20160825 15:08:45< zookeeper> (well, except by using a common prefix for all of one's own options... but that doesn't seem very nice)
20160825 15:09:30< zookeeper> so, yeah, i'd say have them appear by the tag order unless someone makes a good case for something else? :p
20160825 15:14:09-!- oldlaptop [~quassel@162.247.150.37] has quit [Ping timeout: 276 seconds]
20160825 15:15:02-!- oldlaptop [~quassel@162.247.150.37] has joined #wesnoth-dev
20160825 15:16:56-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160825 15:21:05-!- oldlaptop [~quassel@162.247.150.37] has quit [Ping timeout: 250 seconds]
20160825 15:22:12-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160825 15:23:49-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160825 15:25:00< tad_> vultraz: When you get some time, I'm getting some messages from [inspect]: error gui/layout: tgrid [] place: Failed to place a grid, we have 315,64 space but we need 332,64 space.
20160825 15:30:00-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160825 15:39:47-!- JyrkiVesterinen [~JyrkiVest@87-92-22-156.bb.dnainternet.fi] has joined #wesnoth-dev
20160825 15:54:20-!- boucman_work [~boucman@193.56.60.161] has quit [Quit: Leaving.]
20160825 15:56:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 15:58:45-!- oldlaptop [~quassel@162.247.150.37] has joined #wesnoth-dev
20160825 16:18:17-!- vincent_` is now known as vincent_c
20160825 16:23:32-!- irker591 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160825 16:23:32< irker591> wesnoth: Jyrki Vesterinen wesnoth:master 883848659173 / projectfiles/VC12/ (wesnoth.vcxproj wesnoth.vcxproj.filters): Update Visual Studio project https://github.com/wesnoth/wesnoth/commit/8838486591733248a5ffac15a56cae0f645b77ea
20160825 16:33:51-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160825 16:34:59-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160825 16:40:54< celticminstrel> vultraz: You're wrong. They don't fit fine at all. There was a good reason for those tweaks you randomly reverted for no reason - to prevent the buttons from overlapping the logo text. Also, finally the build was fixed, yay! \o/
20160825 16:41:06-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160825 16:50:57< celmin> vultraz: Since your complaint was about resizing, would you be okay reverting the panel change (padding) if I made it update on resize? (Maybe both changes, even.)
20160825 16:51:19-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160825 16:56:32< celmin> (Are large buttons used anywhere other than in the title screen?)
20160825 16:57:05-!- mjs-de [~mjs-de@x4e306b69.dyn.telefonica.de] has joined #wesnoth-dev
20160825 17:05:05-!- travis-ci [~travis-ci@ec2-54-81-200-97.compute-1.amazonaws.com] has joined #wesnoth-dev
20160825 17:05:06< travis-ci> wesnoth/wesnoth#10558 (master - 8838486 : Jyrki Vesterinen): The build passed.
20160825 17:05:07< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/155102837
20160825 17:05:07-!- travis-ci [~travis-ci@ec2-54-81-200-97.compute-1.amazonaws.com] has left #wesnoth-dev []
20160825 17:12:21-!- Kwandulin [~Miranda@p200300760F05338D792A95B2E268729C.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160825 17:13:00< celmin> BTW zookeeper: Options are already grouped by their source (the era, mod, etc that provided them), so even by showing them in order you'd never get options from different addons intermingled.
20160825 17:13:37-!- fabi [~fabi@176.7.55.102] has joined #wesnoth-dev
20160825 17:13:47-!- Kwandulin [~Miranda@p200300760F6F2FD3792A95B2E268729C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160825 17:14:23-!- fabi_ [~fabi@176.0.54.96] has quit [Read error: Connection reset by peer]
20160825 17:22:10< irker591> wesnoth: Jyrki Vesterinen wesnoth:master dae453fe43df / changelog src/actions/attack.cpp src/units/unit.cpp: A new way to make units invulnerable for debugging https://github.com/wesnoth/wesnoth/commit/dae453fe43df444e15cf10efed1bedc3b2ca43dc
20160825 17:24:45< JyrkiVesterinen> nore: The above commit introduces a way to make units invulnerable without increasing their HP to ridiculous levels.
20160825 17:25:03< nore> JyrkiVesterinen: oh, thanks
20160825 17:25:14< JyrkiVesterinen> You're welcome. :)
20160825 17:25:56 * celmin pokes vultraz again.
20160825 17:27:23< nore> oh, btw: I working on a way to allow several players to control a side together (with players passing control to one another when they want to to avoid concurrency issues), but I'm fairly new to wesnoth's codebase: could someone look at it and tell me if something I have done is not good or should be done in another way? The code is at https://github.com/Ekdohibs/wesnoth/tree/network-share Thanks!
20160825 17:28:33< celmin> What's the random TODO set in the middle of game_state.cpp?
20160825 17:31:49< nore> It's that notes are marked as belonging to that side, which has player name a comma-separated list of players controlling it
20160825 17:32:51< nore> So the note needs to be ignored if any (or all?) players controlling the team are ignored
20160825 17:33:30< celmin> I think I'd go with any, to be on the safe side. (Though it could be an advanced pref, I suppose.)
20160825 17:36:40< celmin> It's not necessary to mark functions inline when they're defined in a class. Thus only the operator<< needs the inline keyword.
20160825 17:37:11< celmin> Well, I don't see anything wrong jumping out at me.
20160825 17:43:27< zookeeper> celmin, oh, okay. then the ordering doesn't seem very important, but i guess it still makes sense to let the author specify the ordering, or in other words use the tag order.
20160825 17:58:44-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160825 17:59:37< celmin> vultraz: So, I just noticed that the scroll label in left WML messages has definition=wml_message, whereas that in right WML messages has definition=default. Do you think this is intentional, or an oversight?
20160825 18:09:31-!- Kwandulin [~Miranda@p200300760F6F2FD3792A95B2E268729C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160825 18:12:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160825 18:14:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160825 18:15:17-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20160825 18:47:55-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160825 18:48:48-!- Kwandulin [~Miranda@p200300760F6F2FD3317EF1F1347E1175.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160825 19:03:51-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160825 19:04:47-!- Kwandulin [~Miranda@p200300760F6F2FD3317EF1F1347E1175.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160825 19:17:00-!- JyrkiVesterinen [~JyrkiVest@87-92-22-156.bb.dnainternet.fi] has quit [Quit: Going to bed]
20160825 19:17:35-!- fabi_ [~fabi@176.0.125.135] has joined #wesnoth-dev
20160825 19:20:37-!- fabi [~fabi@176.7.55.102] has quit [Ping timeout: 265 seconds]
20160825 19:29:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160825 19:40:11< celmin> Also vultraz, any chance of MP Create responding to enter?
20160825 19:40:22< celmin> I think the old one didn't either, but it's weird.
20160825 19:54:07< celmin> http://celmin.pwcsite.com/wesnoth/double_message.png
20160825 20:04:51-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Ping timeout: 244 seconds]
20160825 20:10:39< vultraz> celticminstrel: what todo?
20160825 20:12:11< vultraz> celticminstrel: the wml_message scroll label has transparent scrollbars
20160825 20:12:17< vultraz> celticminstrel: it does respond to enter
20160825 20:13:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 20:14:40< vultraz> celticminstrel: large buttons are used in the mp lobby
20160825 20:15:04< vultraz> celticminstrel: if you make resolution be properly chosen on resize, you may un-revert you commit.
20160825 20:22:34< celticminstrel> MP Create doesn't respond to enter.
20160825 20:22:41-!- irker591 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160825 20:22:55< celticminstrel> Anyway, the wml_message scroll label should be used regardless of where the image is, right?
20160825 20:24:00< vultraz> um.... yeah
20160825 20:24:03< vultraz> I guess so
20160825 20:27:35-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160825 20:29:08-!- irker894 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160825 20:29:08< irker894> wesnoth: Celtic Minstrel wesnoth:master b1141fe45785 / / (4 files in 3 dirs): Allow the WML message dialog to show a portrait on both sides https://github.com/wesnoth/wesnoth/commit/b1141fe45785344c3e15568edf012a4a6a28d89c
20160825 20:29:08< irker894> wesnoth: Celtic Minstrel wesnoth:master 201abc9d7e17 / / (4 files in 3 dirs): Make title screen rebuild its layout when the window is resized https://github.com/wesnoth/wesnoth/commit/201abc9d7e1725f706cf17124e62e4963a27591a
20160825 20:32:13< vultraz> blah
20160825 20:32:22< vultraz> the titlescreen uses an external gameloop :|
20160825 20:32:23< vultraz> :| :| :|
20160825 20:32:52< vultraz> I N C O N S I S T E N T E V E N T H A N D L I N G
20160825 20:36:19< vultraz> also looks like mordante never got around to implementing his global hotkey handler
20160825 20:36:38< vultraz> even though these code comments indicate it was supposed to be for 1.19
20160825 20:41:01< fabi_> 1.19?
20160825 20:42:13< fabi_> He did plan for years into the future. 
20160825 20:42:34< vultraz> er, 1.9 
20160825 20:42:36< vultraz> xD
20160825 20:44:35< vultraz> I suppose it wouldn't be that hard to set up a global hotkey context...
20160825 20:46:52-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20160825 20:48:25-!- mjs-de [~mjs-de@x4e306b69.dyn.telefonica.de] has quit [Remote host closed the connection]
20160825 20:49:29< vultraz> celticminstrel: can you help me look into a bug in create?
20160825 20:50:04< vultraz> im trying to figure out why the filter doesn't apply correctly when you change the type when its applied..
20160825 20:50:39< vultraz> well, it initially does
20160825 20:50:55< vultraz> but then changing it doesn't change the visible options correctly
20160825 20:53:10< celmin> I was thinking about how to change the titlescreen's event loop, actually.
20160825 20:54:03< vultraz> the code looks like it should work... but it's not
20160825 20:54:48< vultraz> hm..
20160825 20:57:10< vultraz> (also, why did you defer the mp configure options to a sub-context? they're in the same dialog, they should be in the same context)
20160825 20:57:16< vultraz> (plugin options*)
20160825 21:00:25< celmin> Putting them in the same context would break existing plugins.
20160825 21:01:12< celmin> Even though the MP test is quite likely the only actual use of a plugin, as long as it was in a stable build (which admittedly is an assumption), we mustn't arbitrarily break API.
20160825 21:01:54< vultraz> plugins were in 1.12?
20160825 21:02:03< vultraz> I recall this not
20160825 21:02:19< celmin> Well, it's easy to find out.
20160825 21:03:30< celmin> They weren't. Here's proof: https://github.com/wesnoth/wesnoth/tree/1.12/src/scripting
20160825 21:03:38< vultraz> iceiceice added them in november 2014
20160825 21:03:50< vultraz> or you can do that
20160825 21:03:59< vultraz> therefor we can break the API
20160825 21:04:02< celmin> I suggest you don't change it until after you get the MP test to work though.
20160825 21:04:19< vultraz> don't they work because travis passed?
20160825 21:04:36< celmin> Travis doesn't have the new lobby enabled.
20160825 21:05:07< celmin> So yes, they work, on the new lobby.
20160825 21:05:15< celmin> ^old
20160825 21:05:17< vultraz> ah
20160825 21:05:22< vultraz> finally, the tests do something
20160825 21:05:25< celmin> You said they weren't working for you, right?
20160825 21:05:27< vultraz> they crash! :D
20160825 21:05:27< celmin> Huh?
20160825 21:05:33< celmin> Oh.
20160825 21:05:38< celmin> Client crash?
20160825 21:05:46< vultraz> ./utils/travis/mp_test_executor.sh: line 15: 12160 Segmentation fault      ./wesnoth --plugin=host.lua --server=localhost:12345 --username=host --nogui --mp-test --noaddons
20160825 21:06:33-!- travis-ci [~travis-ci@ec2-54-242-95-114.compute-1.amazonaws.com] has joined #wesnoth-dev
20160825 21:06:34< travis-ci> wesnoth/wesnoth#10560 (master - 201abc9 : Celtic Minstrel): The build was broken.
20160825 21:06:34< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/155164145
20160825 21:06:34-!- travis-ci [~travis-ci@ec2-54-242-95-114.compute-1.amazonaws.com] has left #wesnoth-dev []
20160825 21:06:44< celmin> Does it produce a core dump file?
20160825 21:06:51< celmin> Oh, I forgot to add the new dialog to the tests, didn't I.
20160825 21:06:54< vultraz> a what?
20160825 21:07:26< celmin> https://en.wikipedia.org/wiki/Core_dump#Core_dump_files
20160825 21:07:41< celmin> http://stackoverflow.com/questions/5745215/getting-stacktrace-from-core-dump
20160825 21:08:40< vultraz> I see no such thing
20160825 21:08:58< celmin> That's unfortunate.
20160825 21:09:12< celmin> Well, you can try starting the program in the debugger, then.
20160825 21:09:33< celmin> Putting "gdb" in front of each "wesnoth" line in the shellscript should do it, I think.
20160825 21:09:39< celmin> Oh.
20160825 21:09:42< vultraz> attempted to run again, now it's stuck doing nothing again
20160825 21:09:47< vultraz> :(
20160825 21:09:56< celmin> Since you know the crash was in the host, then you could debug just the host, not both. Probably better.
20160825 21:10:24< celmin> Does "doing nothing" mean "infinitely printing something" or "printing nothing at all"?
20160825 21:11:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160825 21:12:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 21:13:08< vultraz> it's not printing anything anymore
20160825 21:13:16< celmin> Okay.
20160825 21:13:27< vultraz> last thing was a whole lot of "playing multiplayer"
20160825 21:13:32< celmin> That implies the plugin is having control handed back to it.
20160825 21:13:44< celmin> And "playing multiplayer" is what it prints when at the titlescreen.
20160825 21:14:22< vultraz> control by whom
20160825 21:14:38< celmin> The C++ code is not handing control off to the plugin.
20160825 21:15:48< celmin> ie, play_slice() is not being called.
20160825 21:15:48< vultraz> well that's a problem
20160825 21:16:04< celmin> But it's kinda weird for it to be happening at the titlescreen.
20160825 21:16:44< celmin> What happens if you disable the --nogui flag?
20160825 21:17:05< celmin> Maybe it's something about the difference between GUI1 and GUI2 event loops or something.
20160825 21:19:12< vultraz> ahh
20160825 21:19:14< vultraz> a crash!
20160825 21:19:23< celmin> Are you in the debugger?
20160825 21:19:36< vultraz> it's a crash in gui2
20160825 21:19:41< celmin> Oh fun.
20160825 21:19:50< vultraz> i think it's the same one I saw when i switched to Campaigns in tinyres..
20160825 21:19:53< vultraz> did you fix that?
20160825 21:20:00< vultraz> index < items.size()
20160825 21:20:13< vultraz> generator_private.hpp:650
20160825 21:20:20< celmin> I thought I did, but can't remember...
20160825 21:20:47< celmin> You know how to get a stack trace, right?
20160825 21:20:52< vultraz> ok, the crash is in select_item..
20160825 21:21:21< celmin> The problem is probably where the listbox function to select an item was called by the MP Lobby.
20160825 21:21:35< vultraz> for the record, the game is successfully hosted 
20160825 21:21:59< celmin> Huh? Was it the join client that was stuck on "playing multiplayer" then?
20160825 21:22:06< vultraz> yes?
20160825 21:22:10< vultraz> I thought I said this?
20160825 21:22:15< celmin> I think I missed it.
20160825 21:22:20< vultraz> oh
20160825 21:22:22< vultraz> maybe i didn't
20160825 21:22:47< vultraz> but yeah, I have two wesnoth screens here, one with the game hosted and the other in the lobby with the assertion
20160825 21:22:57< vultraz> and i don't see the game in the lobby yet
20160825 21:23:23< celmin> BTW, I haven't wired double-portrait into [message] yet.
20160825 21:23:39< irker894> wesnoth: Celtic Minstrel wesnoth:master e2a2f519bcc2 / src/tests/gui/test_gui2.cpp: Add new dialog to unit tests https://github.com/wesnoth/wesnoth/commit/e2a2f519bcc20fa9c43e3e9cd10ce42a842d3a87
20160825 21:23:43< celmin> I thought you said the game was successfully hosted?
20160825 21:23:59< vultraz> yes
20160825 21:24:07< celmin> But you don't see it in the lobby?
20160825 21:24:11< vultraz> but it takes a sec or two to appear in the lobby
20160825 21:24:20< vultraz> there's a 100 ms delay or something on the refresh timer
20160825 21:24:21< celmin> So it does show up then?
20160825 21:24:31< celmin> Okay, so that's all it is then.
20160825 21:24:49< celmin> It'd be better if it could be a produce-and-consume type loop instead of a timer.
20160825 21:24:59< celmin> ie, it wakes up when there's input.
20160825 21:26:16< vultraz> looks like the script runs through Create fine
20160825 21:26:21< vultraz> it is indeed the lobby with the issue
20160825 21:26:34< celmin> What?
20160825 21:26:51< celmin> Doesn't it go through the lobby before create?
20160825 21:27:00< vultraz> these two instances of wesnoth run simultaneously 
20160825 21:27:16< fabi_> ?
20160825 21:27:17< celmin> So you're saying the joiner's issue is in the lobby.
20160825 21:27:20-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20160825 21:27:21< vultraz> yes
20160825 21:27:23< celmin> Okay.
20160825 21:28:28< vultraz> it's probably this line that's the problem: context.select_game({id = test_game})
20160825 21:28:51< celmin> test_game is a variable right
20160825 21:29:07< celmin> Why do you think that's the problem?
20160825 21:29:37< vultraz> because select_game is the function calling gamelistbox_->select_row(i);
20160825 21:29:42< fabi_> Running "wesnoth -t" gives me a crash every time.
20160825 21:29:48< celmin> Ah.
20160825 21:30:02< vultraz> let's try removing that line
20160825 21:30:09< celmin> Don't remove that line.
20160825 21:30:16< celmin> There's no possible way it can work without that line.
20160825 21:30:28< vultraz> ok then what do you advise
20160825 21:30:43< celmin> Instead, fix the code to only call select_row if the input is in the range [0, gamelistbox_.get_row_item_count() )
20160825 21:30:52< celmin> (I think that's the right function name.)
20160825 21:31:39< fabi_> Can you reproduce that?
20160825 21:31:57< celmin> fabi_: Does it happen before the map displays?
20160825 21:32:03< fabi_> after
20160825 21:32:19< celmin> I used to get a crash at turn end or something.
20160825 21:32:24< fabi_> I can see the map.
20160825 21:32:33< fabi_> But only for a little bit of a second.
20160825 21:32:39< celmin> I see.
20160825 21:32:54< fabi_> It is a Segmentation fault
20160825 21:35:52< vultraz> hm
20160825 21:35:55< vultraz> still crashing..
20160825 21:35:56< celmin> Reproduced it.
20160825 21:36:12< fabi_> It is not that bad.
20160825 21:36:20< celmin> ?
20160825 21:36:24< fabi_> Using "wesnoth -t" is part of my usual workflow.
20160825 21:36:42< celmin> Why do you say it's not that bad.
20160825 21:36:55< fabi_> Because it seems not to affect the rest of Wesnoth that much.
20160825 21:37:02< celmin> Ah.
20160825 21:37:27< fabi_> I can learn to develop for some time without using the test scenario.
20160825 21:37:59< vultraz> hm
20160825 21:38:00< celmin> Ah, I was wrong. I hit a breakpoint, not a segfault.
20160825 21:38:04< vultraz> lua doesn't have a 'wait' function
20160825 21:38:16< celmin> I forgot that breakpoint was there.
20160825 21:38:23< celmin> Why do you need a wait function?
20160825 21:38:47< vultraz> was thinking of telling it to wait 100 ms
20160825 21:39:10< vultraz> hm
20160825 21:39:16< celmin> It shouldn't be necessary for it to wait though.
20160825 21:39:19< vultraz> actually, it already loops until a game is found..
20160825 21:39:22< celmin> Currently it… yeah, that.
20160825 21:39:41< vultraz> i really dunno what to do
20160825 21:39:42< celmin> Okay, I cannot reproduce the segfault after all.
20160825 21:40:01< celmin> Though I get a Lua error.
20160825 21:40:19< vultraz> the gamelist is updated
20160825 21:40:25< vultraz> but the listbox hasn't updated yet
20160825 21:40:33< celmin> Ah, wait, I get a segfault after dismissing the objectives.
20160825 21:40:45< celmin> vultraz: Okay, so make the network handler update the listbox?
20160825 21:40:50< Aginor> introducing delays arbitrary to work around problems is not a good thing :/
20160825 21:41:05< vultraz> it does
20160825 21:41:56< celmin> Starting to sound like a race condition...
20160825 21:41:59-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20160825 21:43:09< vultraz> it is
20160825 21:44:17< vultraz> I can mark gamelist_dirty_ = true and call network_handler() manually... but where
20160825 21:44:24-!- Appleman1234 [~Appleman1@KD036012026220.au-net.ne.jp] has quit [Ping timeout: 260 seconds]
20160825 21:48:17< vultraz> i really dunno
20160825 21:48:51< vultraz> i could also loop until it shows up in the list :/
20160825 21:49:08< celmin> As long as you know it will.
20160825 21:49:17< vultraz> it will
20160825 21:49:21< vultraz> it just takes time
20160825 21:49:32< celmin> No, I mean, what if they requested a game that doesn't actually exist.
20160825 21:49:33< vultraz> the gamelist is updated before the gamelistbox, apparently
20160825 21:49:40< Aginor> umm
20160825 21:49:46< Aginor> what's the problem?
20160825 21:49:56< Aginor> as in, actual problem?
20160825 21:50:04< celmin> There are two timers.
20160825 21:50:14< celmin> One reads network data and updates the game list.
20160825 21:50:25< celmin> The other potentially may need to access the game list.
20160825 21:50:47< celmin> Are timers executed each in their own thread, or what?
20160825 21:50:53< Aginor> no
20160825 21:50:58< Aginor> they interrupt the main thread
20160825 21:51:08< celmin> Like signal handlers?
20160825 21:51:19< Aginor> are run to completion, and then control is returned to the running code
20160825 21:51:23< Aginor> kind of, yeah
20160825 21:51:30< Aginor> or an interrupt ;)
20160825 21:51:43< celmin> So one timer could potentially interrupt the other.
20160825 21:51:46< celmin> ?
20160825 21:51:56< Aginor> that, I do not know
20160825 21:52:08< Aginor> read the docs for SDL_Timer ;)
20160825 21:52:18 * vultraz flails
20160825 21:52:21< celmin> Good point.
20160825 21:52:50< celmin> BTW, I think the network read timer shouldn't be a timer but should instead be based on the presence of data waiting in the stream, any idea how to do that?
20160825 21:53:02< vultraz> blah, I can't check the listbox since it can't return a config
20160825 21:53:08< celmin> Huh?
20160825 21:53:13< vultraz> no i do not
20160825 21:53:22< Aginor> celmin: there's a bunch of different ways to do that
20160825 21:53:25< vultraz> turns out the timer is actually 4000
20160825 21:53:34< vultraz> not 100 :|
20160825 21:53:50< vultraz> I think
20160825 21:54:09< Aginor> you could go multithreaded, or do an select() with a timeout
20160825 21:54:16< Aginor> busy wait on a non-blocking read...
20160825 21:54:42< Aginor> I don't know that part of the code well so I don't know what's appropriate
20160825 21:55:00< Aginor> but leaving network data unattended for too long isn't a great thing ;)
20160825 21:55:07< celmin> Yeah
20160825 21:55:17< vultraz> o shit
20160825 21:55:57< vultraz> I've made an infinite loop
20160825 21:56:06< celmin> Oh?
20160825 21:56:25< vultraz> yeah calling update_gamelist(); at the start of select_game
20160825 21:56:47< celmin> I wonder how this constitutes an infinite loop.
20160825 21:57:37< vultraz> dunno
20160825 21:58:01< celmin> I think it would be fine to not update the listbox - just set the game in the create_engine.
20160825 21:58:21< vultraz> what?
20160825 21:58:35< celmin> Oh wait, do you do that in post_show too?
20160825 21:58:40< vultraz> ......what???
20160825 21:58:42< vultraz> you make no sense
20160825 21:59:01< celmin> When the user selects a game from the listbox, you select it in the create_engine, right>
20160825 21:59:02< celmin> ^?
20160825 21:59:18< vultraz> this is the lobby...
20160825 21:59:21< vultraz> not create..
20160825 21:59:26< celmin> Oh, duh. XD
20160825 21:59:32< vultraz> yah :|
20160825 21:59:49< celmin> Okay.
20160825 22:00:31< vultraz> create runs through fine
20160825 22:00:40< celmin> So, when you select a game from the listbox, is something updated to specify that that's the game that was selected? Or is it just the listbox itself that tracks that?
20160825 22:00:50< vultraz> in the lobby?
20160825 22:00:53< celmin> Yeah.
20160825 22:00:56< vultraz> I'm not sure
20160825 22:01:04< celmin> Is the listbox queried when you click join?
20160825 22:01:25-!- travis-ci [~travis-ci@ec2-54-81-200-97.compute-1.amazonaws.com] has joined #wesnoth-dev
20160825 22:01:26< travis-ci> wesnoth/wesnoth#10561 (master - e2a2f51 : Celtic Minstrel): The build was fixed.
20160825 22:01:26< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/155177397
20160825 22:01:26-!- travis-ci [~travis-ci@ec2-54-81-200-97.compute-1.amazonaws.com] has left #wesnoth-dev []
20160825 22:01:27-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160825 22:02:01< vultraz> yes
20160825 22:02:15< celmin> I see.
20160825 22:02:35< vultraz> it then uses that index for lobby_info_.games()[idx];
20160825 22:03:13< celmin> Oh, I feel like an idea is forming.
20160825 22:03:28< vultraz> I'm listening
20160825 22:05:09< celmin> Unrelated: What's with the commented out line 1520?
20160825 22:05:21< celmin> There seem to be four different functions handling joining a game...
20160825 22:05:31< vultraz> that's the lobby for you :|
20160825 22:05:45< vultraz> I have no idea what the designer was doing
20160825 22:06:05< vultraz> and i have no idea
20160825 22:09:16< celmin> So do_game_join does the real work...
20160825 22:09:30< vultraz> ja ja ja
20160825 22:10:12< celmin> The others are the button callbacks.
20160825 22:10:18< vultraz> yeah
20160825 22:10:28< vultraz> sadly the lobby is hooked into the gui1 gameloop :|
20160825 22:10:32< celmin> One is probably a double-click callback, I guess.
20160825 22:10:58< celmin> MP Create isn't though, right?
20160825 22:11:09< vultraz> it is
20160825 22:11:12< vultraz> everything i
20160825 22:11:14< vultraz> s
20160825 22:11:28< vultraz> and I can't begin to disentangle it 
20160825 22:11:32< vultraz> yet
20160825 22:11:52< celmin> Well, we can disentangle it only when the GUI1 version is removed, I guess.
20160825 22:12:35< celmin> So basically what I'm thinking is that the join and observe plugin callbacks could call do_game_join instead of the button callbacks.
20160825 22:12:42< celmin> create too
20160825 22:12:49< vultraz> i see
20160825 22:13:18< vultraz> that needs an index, though
20160825 22:13:24< celmin> Right.
20160825 22:13:31< vultraz> dost std::find?
20160825 22:13:40< celmin> Hmm.
20160825 22:13:54< celmin> (And select_game would not go through the listbox either.)
20160825 22:14:03< celmin> Hmm.
20160825 22:15:00< celmin> Trying to think if this would work.
20160825 22:15:51-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160825 22:15:51-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160825 22:17:59< celmin> Another idea would be for a selection callback on the listbox to store the selected index in a member variable. Then the join game callbacks would access that variable instead of querying the listbox, and the select_game callback would also set that variable.
20160825 22:18:16< celmin> Instead of setting the listbox.
20160825 22:18:34< celmin> For plugins, updating the UI is just a bonus - it's not really needed.
20160825 22:18:54< celmin> So if it causes trouble and we can't think of a way to work around it, then we can just skip it.
20160825 22:19:27< vultraz> there's an int member called selected_game_id_...
20160825 22:20:07< vultraz> let's use this
20160825 22:20:09< celmin> So fabi_'s crash is cause by the unit_status report generator...
20160825 22:20:21< celmin> Note that game ID is not the same as index.
20160825 22:20:59 * vultraz curses profusely
20160825 22:21:04< celmin> ?
20160825 22:21:15< vultraz> we need an index for do_game_join
20160825 22:21:30-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160825 22:22:14< vultraz> guess I'll add a new member anyway
20160825 22:22:20< celmin> Didn't I already do that?
20160825 22:22:24< celmin> Converting ID to index.
20160825 22:22:27< celmin> In select_game.
20160825 22:22:54< vultraz> but it's not saved
20160825 22:22:57< celmin> The reverse is even easier.
20160825 22:23:20< celmin> lobby_info_.games()[idx]->id or something like that
20160825 22:23:47< vultraz> what...?
20160825 22:23:49< vultraz> whattttt???
20160825 22:23:51< vultraz> you make no sense
20160825 22:24:02< celmin> You said there's a selected_game_id_ field, right?
20160825 22:24:07< vultraz> yes...?
20160825 22:24:08< celmin> So set that, right?
20160825 22:24:17< vultraz> yes
20160825 22:24:38< vultraz> *but you said that's not the same as the index, and do_game_join takes an index!*
20160825 22:24:42< celmin> Lines 992-3 convert the game ID to an index.
20160825 22:24:58< vultraz> I see
20160825 22:25:23< vultraz> why didn't you say that earlier
20160825 22:25:28< celmin> And what I said above, or something similar, converts the index to an ID, if you want to support select_game{index = blah}
20160825 22:25:43< celmin> I said it earlier, just didn't point out the exact lines.
20160825 22:28:10< celmin> 0 isn't a valid Lua stack index, right?
20160825 22:28:19< celmin> Maybe it is?
20160825 22:28:26< celmin> I dunno.
20160825 22:28:43< celmin> Oh wait, could it be that the stack is empty...
20160825 22:30:05< celmin> Basically it seems that lua_absindex(L, -1) is returning 0.
20160825 22:31:36< vultraz> are you talking about something different now?
20160825 22:31:44< celmin> Yeah, fabi_'s crash
20160825 22:33:38< celmin> Is fabi_ even still here?
20160825 22:35:18< vultraz> oh deer
20160825 22:35:35< celmin> Elk is cooler.
20160825 22:35:47< vultraz> now the join game crashes D:
20160825 22:36:00< celmin> I thought it already did that.
20160825 22:36:14< vultraz> now it crashes silently
20160825 22:37:00< celmin> What do you mean?
20160825 22:37:20< vultraz> it just crashes without a message at all when trying to join a game
20160825 22:37:36< celmin> Okay, so there's probably an exception or something.
20160825 22:41:07< fabi_> celmin: ja
20160825 22:41:16-!- Appleman1234 [~Appleman1@KD036012030198.au-net.ne.jp] has joined #wesnoth-dev
20160825 22:41:58< vultraz> dammit
20160825 22:42:02< vultraz> I don't know how to debug this
20160825 22:46:23< irker894> wesnoth: Charles Dang wesnoth:master 53bb5bfa06b6 / src/gui/dialogs/lobby/lobby.cpp: MP Lobby: avoid handling listbox in plugins context https://github.com/wesnoth/wesnoth/commit/53bb5bfa06b6557bc9247b564c21f2030eaf70a8
20160825 22:46:33-!- jswensen [~jswensen@s48075040.temp.wsu.edu] has joined #wesnoth-dev
20160825 22:46:33< vultraz> celticminstrel: ^ ok, that's what I have...
20160825 22:46:51< vultraz> anything look dangerous off-the-bat?
20160825 22:47:22< jswensen> I looked through the repository and could see any audio based on MOD files. Is it necessary to build SDL2 with mikmod support in order to compile Wesnoth?
20160825 22:47:32< jswensen> *couldn’t see and MOD audio files.
20160825 22:47:56< celmin> fabi_: It's not a long-term solution, but commenting out lines 1168-1180 of the test scenario prevents the crash.
20160825 22:48:12< celmin> jswensen: Wesnoth doesn't use MOD files.
20160825 22:48:39< fabi_> celmin: This bug should be easy to bisect.
20160825 22:49:02< celmin> If you want to do that, feel free.
20160825 22:49:08< fabi_> okay
20160825 22:49:17< jswensen> celmin: Thanks. I am working on getting all the dependencies built to start an attempt on the iOS port of >=1.13. The fewer I have to worry about the better. My initial list of dependencies came from a recursives deps check on Ubuntu.
20160825 22:49:48< celmin> Most of its audio is ogg and wav, I think.
20160825 22:50:03< fabi_> Does anyone have a hint when the test scenario last worked? I wonder if anybody is still using it nowadays.
20160825 22:50:14< celmin> It worked for me not too long ago.
20160825 22:50:24< celmin> Like, less than a week, I think?
20160825 22:51:15< jswensen> ogg built fine. I’m not sure which library supports wav, but didn’t see an explicit dependency in the Wesnoth lists.
20160825 22:52:19< jswensen> Maybe SDL has built-in support for wav? It is a pretty simple file format.
20160825 22:53:18< celmin> vultraz: I commented on your commit.
20160825 22:53:27< vultraz> good point about the id thing
20160825 22:55:09-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160825 22:59:55< vultraz> how might i attach the 'join' session to a debugger?
20160825 23:00:22< celmin> You could start it in a debugger to begin with.
20160825 23:01:18< vultraz> eh?
20160825 23:01:28< vultraz> tell me more
20160825 23:01:42< celmin> Just put "gdb" in front of the command line.
20160825 23:01:59< celmin> So instead of "./wesnoth etc etc" you have "gdb ./wesnoth etc etc"
20160825 23:02:01< celmin> I think.
20160825 23:02:51< vultraz> uh..
20160825 23:02:55< vultraz> command line in the file?
20160825 23:03:00< celmin> Yes.
20160825 23:03:16< celmin> Either edit the file or copy-paste it to a command line.
20160825 23:05:09< vultraz> 'gdb: unrecognized option '--plugin=join.lua'
20160825 23:05:27< celmin> Maybe "gdb -- ./wesnoth etc etc"?
20160825 23:05:59< vultraz> 'unknown option -- ./wesnoth'
20160825 23:06:28< fabi_> vultraz: Maybe you want to use a frontend. I am a big fan of the command line. But when it comes to the gnu debugger I like to have a gui.
20160825 23:06:33< celmin> Ah, --args
20160825 23:06:40< celmin> "gdb --args ./wesnoth etc etc"
20160825 23:08:15< vultraz> well now it doesn't error but the window doesn't show up
20160825 23:10:47< celmin> What?
20160825 23:11:31< vultraz> dunno
20160825 23:11:38< vultraz> it doesn't launch :/
20160825 23:12:36< celmin> So it terminates before the window appears?
20160825 23:13:35< vultraz> something like that
20160825 23:13:41< vultraz> ok, so the crash is in join
20160825 23:14:26< celmin> Does the debugger say anything when the program terminates?
20160825 23:14:41< vultraz> no
20160825 23:14:59< vultraz> i tried running gdb for both sessions to see if anything launched at all and that caused a whole mess
20160825 23:15:07< celmin> An exception is usually SIGABRT, but I dunno if that applies when you're on Windows.
20160825 23:15:23< celmin> I'm assuming you do know how to use the debugger.
20160825 23:15:45< vultraz> not really
20160825 23:15:49< vultraz> I've only used it through codeblocks
20160825 23:16:28< celmin> If I recall correctly, it doesn't start the program until you type "run" at the debugger prompt.
20160825 23:18:11< celmin> You're not getting confused by that, right?
20160825 23:18:15< vultraz> no
20160825 23:21:02< vultraz> ok there it is
20160825 23:21:12-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 250 seconds]
20160825 23:21:15< vultraz> segfault
20160825 23:21:17< vultraz> now what
20160825 23:21:42-!- jswensen [~jswensen@s48075040.temp.wsu.edu] has quit [Quit: jswensen]
20160825 23:22:14< vultraz> hmm
20160825 23:22:34< vultraz> 'backtrace stopped. previous frame inner to this frame (stack corrupt?)'
20160825 23:22:40< vultraz> corrupt stack*
20160825 23:22:51< vultraz> i guess i need a debug build!
20160825 23:22:53< celmin> ...what.
20160825 23:23:06< celmin> Oh, yeah, you should generally use a debug build when debugging.
20160825 23:23:24< vultraz> le sigh
20160825 23:23:25< irker894> wesnoth: Celtic Minstrel wesnoth:master 8bd632f18cd7 / src/scripting/game_lua_kernel.cpp: Fix wesnoth.find_vacant_tile https://github.com/wesnoth/wesnoth/commit/8bd632f18cd742c91a3d763823c6682db27a9e31
20160825 23:23:33< vultraz> time for 25 minutes of building
20160825 23:23:55< vultraz> interesting that you just need to type 'where' to get a stacktrace
20160825 23:24:13< celmin> Is that how it works?
20160825 23:24:18< celmin> I thought it was bt.
20160825 23:24:21< celmin> Maybe that's lldb.
20160825 23:25:20-!- jswensen [~jswensen@s48075040.temp.wsu.edu] has joined #wesnoth-dev
20160825 23:37:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160825 23:40:07-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160825 23:42:52-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20160825 23:42:52-!- wedge010 is now known as wedge009
20160825 23:48:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160825 23:50:45< vultraz> blagh
20160825 23:50:49< vultraz> this is useless!
20160825 23:50:52< celmin> ?
20160825 23:51:01< vultraz> Program received signal SIGSEGV, Segmentation fault.
20160825 23:51:03< vultraz> 0x0000002b in ?? ()
20160825 23:51:04< vultraz> (gdb) where
20160825 23:51:06< vultraz> #0  0x0000002b in ?? ()
20160825 23:51:07< vultraz> #1  0x760d2a5f in Sleep () from C:\WINDOWS\SysWoW64\KernelBase.dll
20160825 23:51:09< vultraz> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
20160825 23:51:10< vultraz> (gdb)
20160825 23:51:32< celmin> I see.
20160825 23:51:57< celmin> That's not very useful.
20160825 23:55:32< vultraz> more like no at all
20160825 23:55:44< Aginor> buffer overflow on an array allocated on the stack?
20160825 23:56:39< vultraz> uh...
--- Log closed Fri Aug 26 00:00:37 2016