--- Log opened Wed Sep 07 00:00:56 2016
20160907 00:03:29< celmin> I guess I can't actually see the values of the config keys.
20160907 00:04:33< celmin> And it doesn't have a nice debug console where I can type commands, such as printing the value of some expression (though I think there's some way to do that).
20160907 00:04:42< celmin> Still.
20160907 00:11:52-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160907 00:12:05< celmin> mattsc: I think the problem here is actually that "merge" is the wrong operation.
20160907 00:14:07< celmin> Okay, so this is weird. I connect a static function to the key down event, but when it's called, it has become a null pointer.
20160907 00:18:03-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 240 seconds]
20160907 00:21:59-!- louis94 [~~louis94@91.178.242.33] has quit [Ping timeout: 260 seconds]
20160907 00:23:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160907 00:26:19-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160907 00:26:20< celmin> So anyway, I think the cause of the aspect error has been found.
20160907 00:26:42< celmin> But I have no idea if the crash has the same effect. I reproduced the aspect error on Windows, so let me see if I can reproduce the crash too...
20160907 00:28:49< celmin> It seems like Wesnoth doesn't terminate when I quit it.
20160907 00:34:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 00:38:36< celmin> Nope, no crash, just the warning.
20160907 00:39:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160907 00:40:42< vultraz> celmin: can you confirm something for me
20160907 00:41:06< celmin> Maybe.
20160907 00:41:14< vultraz> celmin: toggle fullscreen in prefs, do you observe a 'ghost' of the menu box hanging around?
20160907 00:41:43< celmin> That's the sort of thing that I can't really confirm effectively over VNC.
20160907 00:41:51< Aginor> vultraz: be more spefic, where from?
20160907 00:42:07< Aginor> GUI1 and GUI2 may behave differently
20160907 00:42:12< Aginor> they normally do
20160907 00:42:45< vultraz> hm... im getting wesnoth crashes...
20160907 00:43:03< vultraz> Aginor: what do you mean, where from?
20160907 00:43:22< vultraz> it looks like this https://www.dropbox.com/s/33sqmkbfsoflfv5/Screenshot%202016-09-07%2011.42.10.png?dl=0
20160907 00:43:34< vultraz> only seems to happen when toggling fs on
20160907 00:44:24< celmin> vultraz: That would probably be because the titlescreen is not redrawn.
20160907 00:44:49< celmin> Does it happen for preferences in-game? In MP lobby?
20160907 00:44:54< celmin> Or only at titlescreen?
20160907 00:45:29< vultraz> ill have to test
20160907 00:45:45< vultraz> right now testing if a change of mine caused a crash
20160907 00:48:58< vultraz> celmin: does not happen in-game
20160907 00:49:56< celmin> I was thinking about rewriting the titlescreen game loop to make it redraw properly.
20160907 00:53:45< Aginor> celmin: the titlescreen should already have a dirty flag of some form, it should redraw if that's been set
20160907 00:53:54< Aginor> celmin: make sure that it is set appropriately
20160907 00:54:10< celmin> That's not the issue here.
20160907 00:54:11< Aginor> it should already have been set on a window event when toggling FS thogh
20160907 00:54:27< celmin> The reason it doesn't redraw is because it has been closed, but was never undrawn.
20160907 00:55:12< Aginor> don't add more undrawing :/
20160907 00:55:24< celmin> Well, undrawing would just turn the screen black in this case.
20160907 00:56:09< celmin> My intent was to rewrite the titlescreen loop so that prefs and other dialogs actually appear on top of it, rather than closing the titlescreen dialog and then opening the next dialog.
20160907 00:56:25< celmin> Thus allowing the normal redrawing mechanism to handle the titlescreen.
20160907 00:56:44< vultraz> I support this
20160907 00:56:50< vultraz> please do do
20160907 00:57:23< celmin> I would still close and re-open the titlescreen every time you do something (except tips), but not until after the subsidiary dialog has been shown.
20160907 00:57:48< celmin> (This would also mean that the tip no longer changes randomly if you click a button but then cancel the dialog, though I could preserve this behaviour if desired.)
20160907 00:58:47< celmin> BTW, whose idea was it to remove End Turn from the menu?
20160907 00:59:00< gfgtdf> celmin: it is afaik posible to configure msvc to also how the config::attribute_valud ina  human redable form.
20160907 00:59:25< celmin> gfgtdf: Really? I might look into that at some point if I keep using MSVC enough.
20160907 00:59:53< gfgtdf> celmin: well there is a reall by button and a hotkeys for it, i wasnt the one who removed it buti liek that change
20160907 01:00:31< celmin> But I can't tell what the hotkey is if it's not somewhere in a menu. I think it should be in the actions menu. Either that, or show the hotkey somewhere, maybe as a tooltip when hovering over the button.
20160907 01:00:41< celmin> (Yes, I know you can figure it out by going to prefs.)
20160907 01:00:46< celmin> (That doesn't count.)
20160907 01:01:08< celmin> I do agree that it didn't make sense for it to be in the right-click menu.
20160907 01:01:42< gfgtdf> celmin: isnt it in teh actions menu?
20160907 01:01:48< celmin> I didn't see it.
20160907 01:01:59< gfgtdf> celmin: maybe we shodul add it there then
20160907 01:12:49-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160907 01:12:55-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160907 01:23:55< irker836> wesnoth: Charles Dang wesnoth:master 717aa892d2e5 / / (6 files in 3 dirs): Preferences Dialog: extensive refactor https://github.com/wesnoth/wesnoth/commit/717aa892d2e52e670f6deda6182f5f4f688eac99
20160907 01:24:00< vultraz> *feelsgood*
20160907 01:24:26-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160907 01:26:30-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160907 01:26:31-!- gfgtdf [~chatzilla@x4e36a54d.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20160907 01:45:45-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160907 01:49:53< celmin> o.o Vultraz used a lambda as a default parameter o.o
20160907 01:50:49< tad_> um .. ok ..
20160907 01:53:23< tad_> hopefully it's one that a smart compiler can look at, optimize and say, instead, "43"
20160907 01:53:28< irker836> wesnoth: Celtic Minstrel wesnoth:master 7db4527b0f8c / src/config.cpp: Simplify config::merge_children_by_attribute https://github.com/wesnoth/wesnoth/commit/7db4527b0f8cb23eef88a8e498d09dc53f525bec
20160907 01:53:30< irker836> wesnoth: Celtic Minstrel wesnoth:master be7670bea580 / src/ai/manager.cpp: Fix [modify_side][ai] again https://github.com/wesnoth/wesnoth/commit/be7670bea580d07087d1cd52aca384c1e355c1f1
20160907 01:53:56 * tad_ runs off to test ...
20160907 01:53:58< celmin> tad_: If you still get the crash, then I have no idae.
20160907 01:54:00< celmin> ^idea
20160907 01:54:07< celmin> But that fixes the warnings.
20160907 01:55:13< tad_> I'll let you know. How long depends upon how forgiving the make gods are ...
20160907 01:55:17< celmin> I wish vultraz hadn't done things like this: https://github.com/wesnoth/wesnoth/commit/717aa892d2e52e670f6deda6182f5f4f688eac99#diff-f679bbddcb8e796b532c2f0614f98eefL256
20160907 01:56:25 * celmin is going to force-push wml_tag_porting in a bit.
20160907 01:58:30< mattsc> celmin (and tad_): cool; I just got back, I’ll test it in a moment as well.
20160907 01:59:04< vultraz> [12:49:49]	celmin	Vultraz used a lambda as a default parameter
20160907 01:59:06< vultraz> hm?
20160907 01:59:09< vultraz> and is that bad?
20160907 01:59:32< celmin> I don't know.
20160907 01:59:43< celmin> It feels ugly to me, but I don't know any reason for it to be bad.
20160907 01:59:55< celmin> I'd wonder what its scope is.
20160907 02:00:01< tad_> Depends on what it does. If it runs off and thinks about the answer for 20 minutes, then, yeah, its bad
20160907 02:00:05< celmin> I suppose the most logical is "all parameters".
20160907 02:00:11< celmin> Ha ha.
20160907 02:00:19< celmin> But no, it wouldn't do that.
20160907 02:00:21< vultraz> I assume you mean in the status label helper?
20160907 02:00:27< celmin> It's just creating the lambda, not calling it.
20160907 02:00:28< celmin> Yes
20160907 02:01:11< irker836> wesnoth: Celtic Minstrel wesnoth:wml_tag_porting b9a7195ff85d / / (9 files in 4 dirs): Properly port [modify_side] to Lua https://github.com/wesnoth/wesnoth/commit/b9a7195ff85de79f04317b1cf6c44a05e999d607
20160907 02:01:13< irker836> wesnoth: Celtic Minstrel wesnoth:wml_tag_porting b322cd86d73e / data/lua/wml-tags.lua src/ai/manager.cpp src/scripting/game_lua_kernel.cpp: Properly port [modify_ai] to Lua https://github.com/wesnoth/wesnoth/commit/b322cd86d73ed22241c2ca673decb286ca9f5f0e
20160907 02:01:15< irker836> wesnoth: Celtic Minstrel wesnoth:wml_tag_porting fed1c22722bb / / (4 files in 4 dirs): Properly port [heal_unit] to Lua https://github.com/wesnoth/wesnoth/commit/fed1c22722bb0802f7b3e9603a93a5f8abfe86cf
20160907 02:01:33< celmin> Huh, I forget it was only three commits.
20160907 02:01:36< celmin> ^forgot
20160907 02:01:40< vultraz> why is that not merged?
20160907 02:01:50< celmin> Because it's not done.
20160907 02:02:06< vultraz> yet?
20160907 02:02:07< celmin> I have up to 10 more tags to tackle.
20160907 02:02:17< celmin> But I keep get distracting by other stuff.
20160907 02:02:18< celmin> :|
20160907 02:02:21< celmin> ^distracted
20160907 02:02:41< vultraz> anyway, I'm heading to lunch
20160907 02:02:56< vultraz> I need to clean up the friends list handling when i get back
20160907 02:03:03< vultraz> it's doing unnecessary list recreation
20160907 02:03:11< celmin> I see.
20160907 02:04:14< vultraz> and closing the dialog if you press enter
20160907 02:04:16< vultraz> in the textbox
20160907 02:04:46< celmin> I bet that can be fixed by setting halt and/or handled to true.
20160907 02:05:36< celmin> Just connect the SDL_KEY_DOWN signal to that textbox and cancel the event if it's an enter or return key.
20160907 02:05:57< vultraz> yes
20160907 02:06:04< celmin> It might not work...
20160907 02:06:11< vultraz> all in-all, though, i'm amazed how much cleanup i could do on prefs
20160907 02:06:16< vultraz> goes to show
20160907 02:06:17< celmin> Depending on the queues.
20160907 02:06:19< vultraz> don't reinvent wheels
20160907 02:06:45< celmin> The window's default key handler might be set up to be absolutely the first handler ever called, so installing a handler on the textbox might not work.
20160907 02:07:35< vultraz> mp lobby does it
20160907 02:07:46< celmin> I thought that disabled return.
20160907 02:07:58< vultraz> oh.. hm
20160907 02:08:03< vultraz> yeah prefs should probably do that too
20160907 02:08:26< celmin> Which brings up option two - connect focus handlers that disable return in the window when the textbox gains focus and enables it when it loses focus.
20160907 02:08:40< celmin> That's two separate events.
20160907 02:08:53< vultraz> there's really no reason to ever want enter dismiss in prefs
20160907 02:08:58< celmin> I disagree.
20160907 02:09:03< celmin> I totally want enter to dismiss prefs.
20160907 02:09:11< vultraz> but you have Esc :|
20160907 02:09:22< celmin> True, though one could argue that Esc should be cancel.
20160907 02:09:30< mattsc> celmin, tad_: both the error message and the crash are gone for me.  (clap)
20160907 02:09:33< celmin> Yay!
20160907 02:09:38< vultraz> I set always_save_fields
20160907 02:09:46< vultraz> meaning settings are saved even if you use Esc
20160907 02:09:51< tad_> one would expect esc to be cancel
20160907 02:09:55< celmin> Though the fact that the crash is gone also is a little worrying.
20160907 02:10:05< celmin> tad_: The thing here is that prefs doesn't even have cancel.
20160907 02:10:52< mattsc> celmin: next up for me is the AI ignoring [disable] weapon instructions bug.
20160907 02:10:55 * tad_ is jealous .. the make gods frown upon him
20160907 02:11:07< mattsc> Which is actually two separate bugs.
20160907 02:11:23< mattsc> Or the same bug in two different parts of the code, applying to different situations.
20160907 02:11:24< celmin> It's worrying because it suggests there may be an issue with how the game deals with invalid aspects.
20160907 02:11:53< tad_> np there 'bad lexical cast' :P
20160907 02:12:00< celmin> I wonder if explicitly placing a full aspect tag setup with name=ai_default_rca::aspect_attacks in the facet name would cause that sort of crash.
20160907 02:12:21< celmin> I mean actually having that in the WML file.
20160907 02:12:52< mattsc> You could try ...
20160907 02:13:03< celmin> Well, I couldn't reproduce the crash though.
20160907 02:13:18< celmin> On the Mac I never even got to reproducing the message.
20160907 02:13:28< mattsc> Hmm.
20160907 02:13:41< mattsc> I guess I could try ...
20160907 02:14:46< celmin> Or an attacks aspect with name=standard_aspect.
20160907 02:15:20-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160907 02:15:21< tad_> Feel free to try anything. I'm sure at some point some UMC author will ...
20160907 02:16:08< celmin> vultraz: Why is resolutions now a member variable?
20160907 02:16:38< celmin> Ugh, more formatting changes mixed in,
20160907 02:17:16< celmin> And you didn't even fix the spelling while you were there. :P https://github.com/wesnoth/wesnoth/commit/717aa892d2e52e670f6deda6182f5f4f688eac99#diff-43f8d21537d836c5770fbe4e639ecadfR146
20160907 02:19:38< celmin> vultraz: Whyyy the ->void :( https://github.com/wesnoth/wesnoth/commit/717aa892d2e52e670f6deda6182f5f4f688eac99#diff-43f8d21537d836c5770fbe4e639ecadfR262
20160907 02:20:03< mattsc> tad_: indeed
20160907 02:20:09< mattsc> celmin: how’s this?  http://pastebin.com/vxVwAzm2
20160907 02:20:16< mattsc> I’ll try it one at a time, of course.
20160907 02:20:48< celmin> I was thinking in [ai] rather than [modify_ai], actually.
20160907 02:20:53< mattsc> Umm, I guess I need a ‘value=2’ or something in the first
20160907 02:20:54< celmin> Like in [side][ai]..
20160907 02:21:06< mattsc> Hmm.  Ok.
20160907 02:21:19< celmin> Well, technically, to conform to the "schema", you'd put the filters in the first and the value in the second.
20160907 02:21:23< mattsc> So with the wrong name in the aspect or in the facet?
20160907 02:21:29< celmin> The facet.
20160907 02:21:36< mattsc> okay
20160907 02:21:40< celmin> In practice the value/filters probably don't matter, I'd think.
20160907 02:21:52< mattsc> methinks so too
20160907 02:22:05< celmin> If you put name in [aspect] it wouldn't even load the facets.
20160907 02:22:11< celmin> (Unless it was name=composite_aspect)
20160907 02:23:30< celmin> The name determines what it looks for besides the basic keys; composite_aspect has [facet]/[default], simple_aspect has value=/[value], ai_default_rca::aspect_attacks has [filter_own]/[filter_enemy], lua_aspect has value=/code=.
20160907 02:24:04< celmin> But I think that probably occurs only after the point where the warning triggers, so it probably doesn't matter. That's entirely a guess.
20160907 02:24:23 * celmin isn't sure whether it's worth trying [modify_ai] in addition to [side][ai].
20160907 02:24:33< mattsc> celmin: like this?  http://pastebin.com/fX7m39Nq
20160907 02:24:53< celmin> Sure.
20160907 02:25:29< celmin> I wonder to what extent the current schema validator is capable of validating the main game config.
20160907 02:29:43< mattsc> celmin: in both cases I get the unknown aspect warning, but no crash
20160907 02:29:55< celmin> Okay, that would be the correct behaviour.
20160907 02:30:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 02:31:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160907 02:32:29< tad_> src/gui/dialogs/multiplayer/mp_create_game.cpp:326:34: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
20160907 02:32:35< tad_> many repeats
20160907 02:32:54< celmin> Ugh, why.
20160907 02:33:09< tad_> macro with ; following would be my guess
20160907 02:33:14< celmin> Yes.
20160907 02:33:28< celmin> I meant more, "why must it give this warning here"
20160907 02:34:04< tad_> I'd have to read the #define to be sure.
20160907 02:34:28< tad_> gui/dialogs/multiplayer/mp_create_game.cpp: In lambda function:
20160907 02:34:36< celmin> Yeah, I just tagged an else on the end since I was touching it anyway, but I guess I should've a) done nothing or b) restored the whole do{}while(false_
20160907 02:34:37< tad_> might be something to do with it :P
20160907 02:35:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160907 02:43:02< mattsc> I guess I should set up test cases for the [disable] bug.  Sigh …
20160907 02:47:32< celmin> So vultraz broke everything! \o/
20160907 02:47:58< celmin> I wonder what happened to the Travis builds… still going?
20160907 02:48:09< celmin> Or did it just fail to annouce?
20160907 02:48:11< celmin> ^announce
20160907 02:48:22< celmin> travis-ci isn't here at the moment.
20160907 02:52:25< tad_>  #10741 failed   Elapsed time 41 min 9 sec  Total time 1 hr 35 min 24 sec  5 minutes ago
20160907 02:53:46< celmin> Is that for 717aa89?
20160907 02:54:05< tad_> One of my HttT PRs
20160907 02:54:15< celmin> Oh.
20160907 02:54:17< tad_> brb
20160907 02:54:21-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160907 02:57:11-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160907 02:57:13< vultraz> celmin: what did I do?
20160907 02:57:20< celmin> You broke everything.
20160907 02:57:28< celmin> Unfortunately my error messages are useless. :(
20160907 02:57:42< vultraz> [13:16:04]	celmin	vultraz: Why is resolutions now a member variable? < - it always was
20160907 02:57:46< celmin> Both my XCode and MSVC builds have errors.
20160907 02:57:47< celmin> Ah.
20160907 02:57:54< celmin> I made a few comments on the commit BTW.
20160907 02:58:16< vultraz> noted
20160907 02:58:19< vultraz> I will incorperate
20160907 02:58:26< celmin> ?
20160907 02:59:37< celmin> Incorporate what?
20160907 03:00:03< vultraz> your suggestions
20160907 03:00:24< celmin> I might delete the ->void myself while fixing the build.
20160907 03:00:44< vultraz> already have locally
20160907 03:00:56< celmin> Then maybe push soon before I get too far. >_>
20160907 03:02:02-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160907 03:02:05< celmin> Does that file have 'using namespace preferences'?
20160907 03:02:13< vultraz> yes
20160907 03:02:18< celmin> Ah.
20160907 03:02:32< celmin> Well, I think it's well-justified in this case, though.
20160907 03:03:37-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160907 03:05:16< tad_> Yeah! make finished and I concur with mattsc: the [modify_side][ai] is no longer giving the error message nor crashing
20160907 03:10:05< vultraz> celmin: you done?
20160907 03:10:10< celmin> Done what now?
20160907 03:10:18< vultraz> commenting
20160907 03:10:34< celmin> Not yet.
20160907 03:12:40< celmin> Now I'm done.
20160907 03:13:47< irker836> wesnoth: Charles Dang wesnoth:master 4f6c8690a2e5 / src/gui/dialogs/preferences_dialog.cpp: Preferences Dialog: some cleanup suggested by @celticminstrel https://github.com/wesnoth/wesnoth/commit/4f6c8690a2e50322b1a4537bf5fc637e9ba515b0
20160907 03:14:05< celmin> Let's see if that fixes anything. (Probably won't.)
20160907 03:14:19< vultraz> now to do moar cleanup
20160907 03:14:24< vultraz> I missed a few things
20160907 03:15:45< mattsc> Ugh — the [disable] weapon special does not appear to work for the player either in 1.13.
20160907 03:15:49< mattsc> It does in 1.12.
20160907 03:16:05< mattsc> Who here would know about this?
20160907 03:16:17< celmin> Does the use of ∞ indicate that you decided it looks good now?
20160907 03:16:42< vultraz> it's rather small
20160907 03:16:44< vultraz> but it's alright
20160907 03:19:35< Aginor> is that a small infinity?
20160907 03:20:35< vultraz> yes
20160907 03:21:56< celmin> Heh, oxymoron. :P
20160907 03:22:14< celmin> Though I guess aleph-null could be called a small infinity.
20160907 03:22:33< Aginor> celmin: I was thinking the same thing :D
20160907 03:22:38< vultraz> t'is true
20160907 03:22:51< celmin> Does anyone else have a broken build? mattsc? tad_?
20160907 03:23:15< celmin> Oh, right, I guess both of you don't.
20160907 03:24:11< celmin> Because you pulled my fix which was rebased on top of the culprit commit.
20160907 03:24:16< mattsc> celmin: mine builds just fine
20160907 03:24:21< celmin> :|
20160907 03:26:06< celmin> vultraz: Just checking, did you add the 3-callback register_bool or was it there already?
20160907 03:26:23< vultraz> latter
20160907 03:26:38< celmin> Ooh, I think I know why the error.
20160907 03:27:02< tad_> I reported the warnings .. not checked since then
20160907 03:29:27< celmin> Looks like my guess was wrong?
20160907 03:29:39< vultraz> what even is the problem
20160907 03:30:03< celmin> No matching function for call to register_bool
20160907 03:30:17< celmin> Without any explanation for why the candidate functions didn't qualify.
20160907 03:30:25< vultraz> whut
20160907 03:30:33< celmin> Yeah, it's kinda weird really.
20160907 03:30:54< vultraz> btw, just realized the 'initial_fire' argument doesn't make sense for the 3 argv ersion
20160907 03:31:02< vultraz> i should revert that part.
20160907 03:31:07< celmin> It doesn't?
20160907 03:31:13< vultraz> no
20160907 03:31:15< celmin> I'm poking at that code though.
20160907 03:31:17< vultraz> there's nothing to fire
20160907 03:31:23< celmin> There isn't?
20160907 03:31:27< vultraz> no
20160907 03:31:33< vultraz> or is there?
20160907 03:31:35< vultraz> im not looking at it
20160907 03:32:02< celmin> I'm not sure.
20160907 03:32:10< celmin> I could tell you in a minute when I'm looking at it again.
20160907 03:32:14< celmin> Maybe.
20160907 03:32:24< celmin> Wait no, I'm looking at tdialog, so I guess that's a bit different.
20160907 03:33:09-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Remote host closed the connection]
20160907 03:36:00 * vultraz considers making an empty friends list say "You have no friends" :3
20160907 03:36:37< celmin> I forget, are friends and ignored listed separately?
20160907 03:36:40< Aginor> vultraz: better not making it judgemental :/
20160907 03:37:13< celmin> Line 282 of dialog.hpp :|
20160907 03:38:00< vultraz> what about it
20160907 03:39:15< celmin> The comment.
20160907 03:39:26< celmin> It implies use_markup is available in WML.
20160907 03:39:43< celmin> I'm editing dialog.hpp right now BTW.
20160907 03:39:49< vultraz> ah, yes
20160907 03:39:52< vultraz> that needs to be added
20160907 03:42:30< mattsc> celmin, vultraz: do you know who might know why the [disable] weapon special does not work in current master (or rather, on works on defense)
20160907 03:42:43< mattsc> *only works
20160907 03:42:56< celmin> I have no idea.
20160907 03:43:02< vultraz> no idea
20160907 03:43:15< mattsc> okay …
20160907 03:43:34< mattsc> Works in 1.12, but in 1.13 the weapon is available on attack, but not on defense.
20160907 03:44:03< celmin> I thought the official way to disable a weapon was by setting attack_weight / defense_weight?
20160907 03:44:18< celmin> (To 0)
20160907 03:46:13< mattsc> There’s a [disable] special that let’s you filter for all kinds of things.  I was told it’s important to have that.
20160907 03:46:20< mattsc> Actually, gfgtdf might know ...
20160907 03:46:21< tad_> celmin: Do you want a PR to fix that macro in mp_create_game?
20160907 03:46:58< celmin> Oh that. I can manage it, I think.
20160907 03:47:38-!- JyrkiVesterinen [~JyrkiVest@87-100-240-82.bb.dnainternet.fi] has joined #wesnoth-dev
20160907 03:48:19< tad_> mattsc: I see a commit comment "Support for the disable weapon special." give me a bit and I'll find the commit ..
20160907 03:48:49< mattsc> tad_: thanks!  In the meantime, I did a quick check and it works in 1.13.0, but not in 1.13.5.
20160907 03:49:08< tad_> Bah. From 2013 commit a4f6249627a1df6cf5f25d45e96ee0b657fb5eb2 Author: fendrin <fabianmueller5@gmx.de> Date:   Thu Sep 26 02:28:38 2013 +0200      Support for the disable weapon special.
20160907 03:49:39< mattsc> tad_: yeah, I know about that one; the problem is much more recent.
20160907 03:49:42< celmin> Oh, that's true, making it a special would allow filters.
20160907 03:50:07< mattsc> It works in 1.12.6 and 1.13.0, but not in 1.13.5 — so I’ll do a refactor sometime tomorrow.
20160907 03:51:11< tad_> commit c7de7ce9d428ed82f67a157b92b97cfd5608f54c Author: Celtic Minstrel <celtic.minstrel.ca@some.place> Date:   Sun Mar 6 18:28:23 2016 -0500      Fix backstab always showing augmented damage in sidebar          Until now, [damage] (and possibly other) specials which relied on filters involving the opponent would display     in the sidebar as if the augmentation were always active (though when attacking, it worked correctly).     
20160907 03:51:33< tad_> I'm just scanning the log
20160907 03:51:46< celmin> mattsc: Refactor? Do you possibly mean bisect?
20160907 03:51:55< tad_> That would do it.
20160907 03:52:03< celmin> ?
20160907 03:52:05< tad_> git bisect
20160907 03:53:05< tad_> You know a good tag and a bad tag bisect will eventually find it. But it can take a long time if there's a lot of commits to go through. Like, for me, a day or so because it takes so bloomin' long to make
20160907 03:56:19< celmin> Yeah, I know how it works. Don't think I've ever used it (I started once, but someone else got to it first).
20160907 03:57:54< mattsc> celmin: rafactor, bisect, what’s the difference anyway  ;)
20160907 03:58:06< celmin> Everything. :P
20160907 03:58:31< mattsc> I can’t possibly keep all those technical terms apart in my mind
20160907 03:59:51< pydsigner> That's like two of them
20160907 04:00:14< tad_> "refactor" is what a programmer does to break things.  "bisect" is how you ask git to find his commit which broke it.
20160907 04:00:22< celmin> Haha
20160907 04:00:36< celmin> I guess it's not wholly false though.
20160907 04:01:04< tad_> No, but it is hopelessly cynical. 
20160907 04:01:29< mattsc> I’ve used git bisect before.  The main problem for me is whenever the Xcode project was not updated until some time after the commit that required it to be updated.
20160907 04:01:39< Aginor> vultraz: bisect is useful, it does a binary search
20160907 04:01:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 04:03:49< mattsc> What I did not follow: are we assuming that commit c7de7ce9d4 broke the diable special, or was that related to something else?
20160907 04:04:14 * celmin gives up on most of the dialog.hpp thing.
20160907 04:04:27< tad_> No assumption.  Jsut a grep for the words.  AT best it's a wild-ass-guess
20160907 04:05:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160907 04:12:18< celmin> I think the unreferencization didn't fix prefs, if I recall correctly...
20160907 04:13:33< celmin> Yeah. :|
20160907 04:14:43< celmin> …the errors were there but now they vanished...
20160907 04:15:18< celmin> So did it fix it or not?
20160907 04:16:05< celmin> Seems not.
20160907 04:20:03< celmin> Oooh, one of them now has Explanations?
20160907 04:23:25< celmin> The register_* interface has several weird things in it, huh.
20160907 04:25:01-!- travis-ci [~travis-ci@ec2-54-167-102-14.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 04:25:02< travis-ci> wesnoth/wesnoth#10746 (master - 8d6e513 : Celtic Minstrel): The build is still failing.
20160907 04:25:02< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158028736
20160907 04:25:02-!- travis-ci [~travis-ci@ec2-54-167-102-14.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 04:25:28< tad_> guess who!
20160907 04:25:48< celmin> What? Unrecognized -Qunused-arguments? :|
20160907 04:26:38< celmin> tad_: Yes?
20160907 04:27:19< tad_> travis-ci is back
20160907 04:27:23< celmin> Oh, that.
20160907 04:34:14< celmin> Oh, I get the problem. The function signature does not match.
20160907 04:37:06< celmin> Hahah, squelched it!
20160907 04:37:25< celmin> That took annoyingly long.
20160907 04:37:52< celmin> And one of the downsides of MSVC is not giving additional error information in these sorts of cases, though I don't get why clang also failed to do so.
20160907 04:43:51< celmin> I guess std::bind / std::function became more permissive in later versions of libc++ though.
20160907 04:49:56< celmin> The fix works for MSVC too, so yay.
20160907 04:53:53-!- JyrkiVesterinen [~JyrkiVest@87-100-240-82.bb.dnainternet.fi] has quit [Quit: .]
20160907 04:54:22< vultraz> celmin: did i screw something up?
20160907 04:54:45< celmin> I guess?
20160907 04:55:13< vultraz> how so?
20160907 04:55:24< celmin> set_music returns bool rather than void.
20160907 04:55:32< celmin> (And the other three similar functions.)
20160907 04:55:39< celmin> I fixed it, so don't worry about it.
20160907 05:00:50< vultraz> this friends list code is rather annoying
20160907 05:01:36< celmin> If I can get this working I should be able to push very soon, but it somehow managed to set a null function for the signal even though I specifically passed a real function.
20160907 05:01:50-!- Kwandulin [~Miranda@p200300760F42415195A69E5564E2555B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160907 05:02:19< vultraz> ugh
20160907 05:02:33< vultraz> i might have to refactor this in prefs itself
20160907 05:02:37< celmin> ?
20160907 05:02:58< vultraz> the code dealing with the friends list is rather messy
20160907 05:03:08< celmin> Is that so.
20160907 05:03:50< vultraz> i don't want to recreate the list every time you add/remove an entry..
20160907 05:04:02< celmin> Load game tried to load a garbage filename.
20160907 05:04:26< celmin> Steps to reproduce: Click Load Game, type something that clears the list (eg `), press Esc.
20160907 05:04:36< celmin> I feel like there's at least two distinct issues here.
20160907 05:04:48< celmin> 1) It tries to load a game when you press Esc? :S
20160907 05:04:55< vultraz> what? o_O
20160907 05:04:58< vultraz> ugh
20160907 05:04:59< celmin> 2) It tries to load a game even though no game is selected?
20160907 05:05:01< vultraz> more stuff for me to fix
20160907 05:06:48-!- travis-ci [~travis-ci@ec2-54-167-102-14.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 05:06:49< travis-ci> wesnoth/wesnoth#10748 (master - 84759a2 : Charles Dang): The build is still failing.
20160907 05:06:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158038763
20160907 05:06:49-!- travis-ci [~travis-ci@ec2-54-167-102-14.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 05:07:11< celmin> (My fix should handle that failure when it lands, hopefully.)
20160907 05:10:03< celmin> Guessing the load game issue would also occur if you pressed enter instead of esc.
20160907 05:11:36< vultraz> this code is confusing..
20160907 05:12:03< celmin> Yay for confusing code?
20160907 05:12:22-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160907 05:12:32< vultraz> it seems to keep a static map of acquaintances
20160907 05:13:02< vultraz> that's... 
20160907 05:13:11< vultraz> saved to and from ...
20160907 05:13:13< vultraz> somewhere
20160907 05:13:17< vultraz> every time you modify it
20160907 05:13:19< vultraz> what??/
20160907 05:13:34< vultraz> why...
20160907 05:13:43< vultraz> this makes no sense :|
20160907 05:14:05< celmin> In preferences.cpp?
20160907 05:14:11< celmin> That seems somewhat logical to me though.
20160907 05:14:21< vultraz> game_preferences.cpp
20160907 05:14:25< celmin> Close enough.
20160907 05:15:44< vultraz> every single time it's accessed load_acquaintances() is called
20160907 05:15:46< vultraz> :|
20160907 05:15:52-!- Bonobo [~Bonobo@2001:44b8:254:3200:25ec:b21d:8b2f:ea76] has joined #wesnoth-dev
20160907 05:16:16< celmin> I think it's logical to keep a static… vector at least.
20160907 05:16:21< vultraz> yes..
20160907 05:16:22< celmin> (Why is it a map?)
20160907 05:16:27< vultraz> I guess..
20160907 05:16:35< vultraz> map[nick] details
20160907 05:16:41< celmin> Ah, right.
20160907 05:16:56< celmin> Why are you looking at the storage code anyway?
20160907 05:17:13< vultraz> I need to get add_friend to return the data for the added person
20160907 05:17:47< vultraz> a pointer, actually
20160907 05:17:49< celmin> That sounds pretty trivial?
20160907 05:18:23< vultraz> yes
20160907 05:19:02< celmin> Use map::insert (or emplace) instead of operator[], since that returns the added data.
20160907 05:19:21< vultraz> so..
20160907 05:19:23< celmin> Except if it's already there, it instead returns the old data, so you'll have to remember to update it.
20160907 05:19:47< vultraz> return &map.emplace(stuff), right?
20160907 05:19:52< vultraz> what do you mean, update it?
20160907 05:20:00< celmin> Let me explain in more detail
20160907 05:20:15< celmin> First of all, insert/emplace only inserts it if the key was not already present in the map.
20160907 05:20:22< celmin> It returns a pair<iterator, bool>
20160907 05:20:23< vultraz> yes
20160907 05:20:49< celmin> The iterator points to the location of the pair with that key - either the newly-inserted pair, or the existing one with a conflicting key.
20160907 05:21:12< celmin> The bool distinguishes those two cases, so if it's false, then you need to set ->second = the acquaintance.
20160907 05:21:19< celmin> Otherwise it won't be updated.
20160907 05:21:28< celmin> This is a good place for std::tie. :P
20160907 05:21:42< celmin> (Though sadly that requires predeclaring the variables, but whatever._
20160907 05:21:43< celmin> ^)
20160907 05:21:51< vultraz> set....->second?
20160907 05:21:53< vultraz> why second
20160907 05:21:58< celmin> Because it's a pair?
20160907 05:22:04-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160907 05:22:09< vultraz> but you said .second is a bool :|
20160907 05:22:22< celmin> Oh, .first->second
20160907 05:22:34< vultraz> I see
20160907 05:23:26< celmin> With this method you'd want to assign preferences::acquaintance to a variable.
20160907 05:23:47< vultraz> that's... a class
20160907 05:23:54< celmin> Sure.
20160907 05:24:26< celmin> But the existing code does acquaintances[nick] = acquaintance(…), so instead do acquaintance varname(...).
20160907 05:24:36< celmin> Followed by the insert/emplace stuff.
20160907 05:24:46< vultraz> how do I use tie?
20160907 05:24:59< celmin> First, declare an iterator and bool variable.
20160907 05:25:11< celmin> If you call them iter and success respectively, then:
20160907 05:25:22-!- mjs-de [~mjs-de@x4db68d36.dyn.telefonica.de] has joined #wesnoth-dev
20160907 05:25:23< celmin> std::tie(iter, success) = map.insert(…)
20160907 05:25:33< celmin> (Or emplace. The two are semantically equivalent.)
20160907 05:25:58< vultraz> an iter of what type?
20160907 05:26:09< celmin> It's kind of like how in Lua you can do things like 'x, y = unit.loc' (not sure if loc was the correct name but you get the idea)
20160907 05:26:21< celmin> The iterator type is that of the map's iterator. Non-const, I think.
20160907 05:26:29< celmin> So, acquaintances_map::iterator
20160907 05:26:49< celmin> …yeah, non-const. Wouldn't make sense otherwise, I think.
20160907 05:26:49 * vultraz declares a typedef
20160907 05:26:52< celmin> Heh...
20160907 05:27:05< celmin> decltype is also an option
20160907 05:27:11< celmin> auto won't work here, sadly
20160907 05:27:27< celmin> Well, I suppose you make it work by assigning eg map.begin()
20160907 05:27:31< celmin> ^assigning
20160907 05:28:08-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160907 05:29:13-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 05:29:14< travis-ci> wesnoth/wesnoth#10749 (master - 717aa89 : Charles Dang): The build is still failing.
20160907 05:29:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158050361
20160907 05:29:14-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 05:30:27< vultraz> something like this> http://pastebin.com/BSn4V5dk
20160907 05:31:00< celmin> That's pretty much correct up to line 11.
20160907 05:31:24< vultraz> oh yeah, missing the ;
20160907 05:31:33< celmin> But the original version also updated the friend if it already existed.
20160907 05:31:51-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160907 05:31:51-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160907 05:32:22< vultraz> .. so what's the point of using emplace
20160907 05:32:26< celmin> So, on !success, set iter->second = new_entry, and then the stuff in your if(success) becomes unconditional.
20160907 05:32:47< celmin> The point of using emplace is that you get back an iterator to what was added or already present.
20160907 05:33:01< vultraz> I see
20160907 05:33:08< celmin> I honestly think it's better to return a reference rather than a pointer as well.
20160907 05:33:19< celmin> You should avoid using pointers if you can, in my opinion.
20160907 05:33:24< vultraz> hm
20160907 05:33:34< vultraz> well since there's always something I guess I can..
20160907 05:33:41< vultraz> these functions returned bool before
20160907 05:33:48< celmin> Oh?
20160907 05:33:50< vultraz> yes
20160907 05:33:55< vultraz> for success/fail
20160907 05:34:03< vultraz> so I was using the pointer so I could keep the check
20160907 05:34:06< celmin> Oh.
20160907 05:34:13< celmin> There is a failure condition, huh.
20160907 05:34:26< celmin> What's with this wildcard thing though...
20160907 05:35:04< celmin> Unless you want to investigate what that is and whether it's needed, I guess you have to stick with a pointer.
20160907 05:36:12< celmin> Maybe it's so that you can add a friend matching a pattern, eg "Brackdon_Cawr*" which always matches me.
20160907 05:36:23< celmin> Even if I double-connect or disconnect and reconnect or whatever.
20160907 05:38:25< vultraz> I'm starting to really dislike the word 'acquaintance"
20160907 05:38:27< vultraz> :|
20160907 05:38:59< celmin> Oh! I get why the function became null. It was because it was disconnecting itself.
20160907 05:39:02< celmin> Duh!
20160907 05:39:09< celmin> I guess I really do need to set handled and halt.
20160907 05:40:14-!- mjs-de [~mjs-de@x4db68d36.dyn.telefonica.de] has quit [Remote host closed the connection]
20160907 05:42:02< celmin> Okay, assuming this works, I should be able to push in, say, half an hour or so.
20160907 05:42:14< celmin> If this works I still have one other thing to test.
20160907 05:43:32< celmin> Ah, now that I think about it, it's not gonna work, is it...
20160907 05:43:47< celmin> Because of the item change callback...
20160907 05:44:27< celmin> I need to disconnect that too.
20160907 05:45:50< celmin> Actually, surely I could remove selected_item_?
20160907 05:46:04< celmin> And instead test which one is selected in post_show?
20160907 05:46:39< celmin> Ugh, this is quite a bit more complicated than it looks.
20160907 05:47:17-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 05:47:17< celmin> Maybe instead of an item change callback it should be a click callback...
20160907 05:47:18< travis-ci> wesnoth/wesnoth#10750 (master - be7670b : Celtic Minstrel): The build is still failing.
20160907 05:47:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158053502
20160907 05:47:18-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 05:48:38< celmin> The listbox probably sets handled/halt in its click callback though...
20160907 05:50:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 05:50:02< celmin> Hmm, surprisingly, it seems like it doesn't.
20160907 05:50:56< celmin> So setting the selected item programmatically doesn't trigger the callback.
20160907 05:51:56< celmin> (Probably should, honestly.)
20160907 05:54:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160907 05:55:03< celmin> Random though: Did you make it skip the faction choice dialog when you have only one option?
20160907 05:55:09< celmin> ^thought
20160907 05:55:49< celmin> I wonder if [multiplayer_side] is valid within [multiplayer].
20160907 05:57:57< celmin> I wonder if we can make top menus appear on mousedown instead of mouseup.
20160907 05:58:09< celmin> ^thoughts
20160907 05:58:11< celmin> >_>
20160907 05:59:42< celmin> Oh dear.
20160907 05:59:59< celmin> It seems like the listbox item change callback does not fire when the selection is changed by keyboard.
20160907 06:00:07< celmin> Though that's convenient for me, it's still wrong.
20160907 06:01:15-!- travis-ci [~travis-ci@ec2-54-167-102-14.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 06:01:16< travis-ci> wesnoth/wesnoth#10751 (wml_tag_porting - fed1c22 : Celtic Minstrel): The build is still failing.
20160907 06:01:16< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158054367
20160907 06:01:16-!- travis-ci [~travis-ci@ec2-54-167-102-14.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 06:01:43< celmin> Oh, I see. The "value change" callback triggers, but not the "item changed" callback. Alright, I won't change it then, since it is after all convenient for me.
20160907 06:08:10-!- nore [~ncourant@sas.eleves.ens.fr] has quit [Ping timeout: 250 seconds]
20160907 06:09:33-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160907 06:09:33-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160907 06:09:45< vultraz> [16:57:52]	celmin	I wonder if we can make top menus appear on mousedown instead of mouseup.
20160907 06:09:46< vultraz> is it worth it?
20160907 06:10:06< celmin> I don't know. It's expected behaviour both on Mac and Windows, I think.
20160907 06:10:07-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160907 06:10:23-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160907 06:11:02-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160907 06:11:23< celmin> I guess it's been almost half an hour and still no push.
20160907 06:11:36< celmin> And I should sleep. But it feels like I'm close.
20160907 06:11:43< vultraz> what are you even doing
20160907 06:11:53< celmin> Keyboard selection for menus.
20160907 06:11:58-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160907 06:12:07< vultraz> did you abandon the scrollbuttons?
20160907 06:12:11-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160907 06:12:13< celmin> For now, yes.
20160907 06:12:24< celmin> I intend to come back to it at some point.
20160907 06:12:33< vultraz> im not sure why you can't just keyboard capture the list in the dialog...
20160907 06:13:00< celmin> It seems to ignore keyboard input if no item is selected.
20160907 06:13:13< vultraz> well of course
20160907 06:13:19< celmin> No, not of course.
20160907 06:13:23< vultraz> if nothing is selected, how do you intend to use the keyboard?
20160907 06:13:35< celmin> There's an obvious action.
20160907 06:13:39< vultraz> which is?
20160907 06:13:54< celmin> Up arrow selects the last item. Down arrow selects the first item.
20160907 06:14:04< celmin> (Similarly for a horizontal list and left/right arrows.)
20160907 06:14:45< celmin> Which is what I implemented, though now that you mention it, I wonder if I should've done it generally in listboxes instead...
20160907 06:17:34< vultraz> possibly
20160907 06:25:47-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 06:25:48< travis-ci> wesnoth/wesnoth#10752 (master - 4f6c869 : Charles Dang): The build is still failing.
20160907 06:25:48< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158062103
20160907 06:25:48-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 06:26:35-!- boucman_work [~boucman@2a02-8428-034f-f800-9e32-0c7c-b391-6223.rev.sfr.net] has quit [Remote host closed the connection]
20160907 06:30:49-!- Kwandulin [~Miranda@p200300760F42415195A69E5564E2555B.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160907 06:36:43-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160907 06:44:51< irker836> wesnoth: Charles Dang wesnoth:master 5ee75aa473be / src/ (5 files in 3 dirs): Preferences Dialog: refactored handling of friends list https://github.com/wesnoth/wesnoth/commit/5ee75aa473be88d158e30493ee472f399e30876e
20160907 06:44:54< irker836> wesnoth: Charles Dang wesnoth:master 8dfaac367bc8 / src/gui/dialogs/ (preferences_dialog.cpp preferences_dialog.hpp): Preferences Dialog: cleaned up Animate Map toggle code https://github.com/wesnoth/wesnoth/commit/8dfaac367bc83e93975a3efd819baf23b05edaf6
20160907 06:45:12< celmin> Well, I can't really complain, since my stuff still isn't done. :/
20160907 06:45:38< celmin> But now that I have two working copies to sync that might be a bit more of a pain than usual…
20160907 06:46:49< celmin> I guess I'll have to make sure you didn't break anything again, too. :P
20160907 06:47:16< irker836> wesnoth: Charles Dang wesnoth:master 6f510ad07dc0 / data/gui/window/preferences/05_multiplayer.cfg: Forgot to commit some WML for 5ee75aa473be https://github.com/wesnoth/wesnoth/commit/6f510ad07dc0fdd4116297a4f5b7e477078ed6f3
20160907 06:50:18-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160907 06:51:47< celmin> I wish you wouldn't do pointless changes like changing friend_list to friends_list or resolutions to resolutions_
20160907 06:52:28< vultraz> hm?
20160907 06:52:35< vultraz> oh
20160907 06:52:53< celmin> Or at least separate them into a different commit.
20160907 06:53:06< celmin> It's kind of like whitespace changes - no semantic difference, just clutter.
20160907 06:55:30< irker836> wesnoth: Charles Dang wesnoth:master 0034c8a3785e / src/gui/dialogs/preferences_dialog.cpp: Cleaned up includes https://github.com/wesnoth/wesnoth/commit/0034c8a3785e2903cca1571a08ee8190e61737fa
20160907 06:56:40< vultraz> for the record, resolutions to resolutions_ was because it was now using the member variable
20160907 06:59:24< vultraz> so today, I reduced the file size by 230 lines
20160907 06:59:30< vultraz> length
20160907 06:59:41-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 06:59:42< travis-ci> wesnoth/wesnoth#10753 (master - 8dfaac3 : Charles Dang): The build is still failing.
20160907 06:59:42< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158088267
20160907 06:59:42-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 07:01:10-!- Jetrel_ [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has quit [Quit: "The highest possible stage in moral culture is when we recognize that we ought to control our thoughts." - Charles Darwin]
20160907 07:02:25-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has joined #wesnoth-dev
20160907 07:04:45< celmin> It works! \o/
20160907 07:09:10-!- travis-ci [~travis-ci@ec2-54-167-102-14.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 07:09:11< travis-ci> wesnoth/wesnoth#10754 (master - 6f510ad : Charles Dang): The build is still failing.
20160907 07:09:12< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158088634
20160907 07:09:12-!- travis-ci [~travis-ci@ec2-54-167-102-14.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 07:10:37< vultraz> celmin: the keyboard?
20160907 07:10:57< celmin> In menus, yes.
20160907 07:17:39< celmin> This comment makes me really suspicious: "Default implementation, but defined out-of-line for efficiency reasons"
20160907 07:18:09< celmin> There are 20 cases of it in the code, and I suspect all 20 of them annotate destructors that do nothing and can be removed.
20160907 07:18:39< celmin> (Though some may be virtual destructors which cannot be removed, but even so they could be defined inline. I don't see how that would be inefficient.)
20160907 07:19:16< celmin> Sorry, 21
20160907 07:19:34< vultraz> I'll let you deal with that
20160907 07:19:44< celmin> Not going to do it right now.
20160907 07:23:37-!- Kwandulin [~Miranda@p200300760F424151A0EF523482A8AE29.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160907 07:28:38-!- atarocch [atarocch@nat/redhat/x-evlqbvurnutytfoc] has joined #wesnoth-dev
20160907 07:30:22-!- atarocch_ [atarocch@nat/redhat/x-jqlbgalbfxsnkgxt] has joined #wesnoth-dev
20160907 07:31:04-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160907 07:31:44-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160907 07:33:12-!- atarocch [atarocch@nat/redhat/x-evlqbvurnutytfoc] has quit [Ping timeout: 240 seconds]
20160907 07:33:58-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 265 seconds]
20160907 07:33:58-!- wedge010 is now known as wedge009
20160907 07:37:27< vultraz> prefs seems more responsive 
20160907 07:37:31< vultraz> this is good
20160907 07:38:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 07:42:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160907 07:44:33< irker836> wesnoth: ln-zookeeper wesnoth:master 15241cd0a61f / data/ (4 files in 3 dirs): Convert remaining – to × in strings describing attack stats https://github.com/wesnoth/wesnoth/commit/15241cd0a61f24223aa8fdb82eb52c7520c80c59
20160907 07:44:43< zookeeper> would be handy if that was pofixable...
20160907 07:45:42< celmin> Seems like it should be?
20160907 07:46:28< zookeeper> well, would be handy if someone pofixed that, then
20160907 07:46:48-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160907 07:49:59-!- atarocch [atarocch@nat/redhat/x-xvpguikndhuicdwk] has joined #wesnoth-dev
20160907 07:59:47-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 07:59:48< travis-ci> wesnoth/wesnoth#10756 (master - 15241cd : ln-zookeeper): The build is still failing.
20160907 07:59:49< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158097830
20160907 07:59:49-!- travis-ci [~travis-ci@ec2-54-161-215-1.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 08:00:08 * celmin does have a fix for Travis, probably.
20160907 08:02:22-!- boucman_work [~boucman@bob75-2-81-56-46-209.fbx.proxad.net] has joined #wesnoth-dev
20160907 08:03:54< irker836> wesnoth: Charles Dang wesnoth:master a281e16bc4dc / src/chat_command_handler.cpp: Something else I forgot to commit with 5ee75aa473be https://github.com/wesnoth/wesnoth/commit/a281e16bc4dc44e79ca63c2d2ecf0495c1dd571e
20160907 08:10:24< vultraz> hmm
20160907 08:10:35< vultraz> so get_rows_shown is actually a vector mask...
20160907 08:10:55< vultraz> ie, a vector of bools that says whether rows are shown...
20160907 08:13:48< vultraz> one would think vectors of bools would have some clever way to check if it's all true or false
20160907 08:18:02< JyrkiVesterinen> I recommend just using a standard algorithm.
20160907 08:18:49< JyrkiVesterinen> if (std::find(my_vector.begin(), my_vector.end(), false) == my_vector.end()) { // all are true
20160907 08:20:10< vultraz> oh yeah
20160907 08:41:24-!- travis-ci [~travis-ci@ec2-54-92-226-132.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 08:41:25< travis-ci> wesnoth/wesnoth#10757 (master - a281e16 : Charles Dang): The build is still failing.
20160907 08:41:25< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158101526
20160907 08:41:25-!- travis-ci [~travis-ci@ec2-54-92-226-132.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 08:41:56-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160907 09:06:18-!- Kwandulin [~Miranda@p200300760F424151A0EF523482A8AE29.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160907 09:06:51-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160907 09:12:48-!- Kwandulin [~Miranda@p200300760F42415108240029B5AC66E1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160907 09:26:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 09:30:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160907 10:10:42-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160907 10:25:38-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160907 10:31:21-!- Kwandulin [~Miranda@p200300760F42415108240029B5AC66E1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160907 10:58:48-!- Kwandulin [~Miranda@p200300760F424151AC6F28264DC9971F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160907 11:01:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160907 11:04:27-!- irker836 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160907 11:14:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 11:19:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20160907 11:29:14-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160907 11:47:53-!- coproduit [~coproduit@hott.coq.sexy] has left #wesnoth-dev ["WeeChat 1.5"]
20160907 12:20:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 12:24:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160907 13:08:33-!- Bonobo [~Bonobo@2001:44b8:254:3200:25ec:b21d:8b2f:ea76] has quit [Quit: Leaving]
20160907 13:17:16-!- Kwandulin [~Miranda@p200300760F424151AC6F28264DC9971F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160907 13:35:08 * celmin awakes
20160907 13:35:43< celmin> I feel like std::all_of would be great for a vector<bool>...
20160907 13:36:52< celmin> The only thing vector<bool> has though that normal vector doesn't is flip(), apparently.
20160907 13:37:21< celmin> And I doubt more stuff will be added. I think it might've been deprecated at some point after C++98?
20160907 13:41:48-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160907 13:45:25-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Client Quit]
20160907 13:52:57< celmin> So, uhh… I joined my game and got MP wait, then on the other computer clicked "I'm Ready".
20160907 13:53:11< celmin> The other computer is already in the game, but I'm still on MP wait.
20160907 13:55:31-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160907 13:57:28< JyrkiVesterinen> IIRC, the property that vector<bool> takes only one bit of memory per element has been deprecated since C++98, meaning that programs shouldn't depend on that.
20160907 13:58:04< JyrkiVesterinen> Of course, even once the property is lifted, storing booleans in vectors is going to remain possible.
20160907 13:58:11< celmin> Of course.
20160907 13:58:30< celmin> I wonder if I should go through and replace all the vector<bool> in Wesnoth with boost::dynamic_bitset.
20160907 13:58:55< JyrkiVesterinen> Sounds like a good idea.
20160907 14:00:15< celmin> So is it just my changes, or is multiplayer broken?
20160907 14:00:34< celmin> I just changed how the connecting phase was shown though.
20160907 14:02:04-!- gfgtdf [~chatzilla@x4e36aca5.dyn.telefonica.de] has joined #wesnoth-dev
20160907 14:02:40< celmin> Hmm, the non-host did manage to get past MP wait eventually...
20160907 14:02:45< celmin> Maybe I was just too impatient?
20160907 14:04:23< celmin> Mind you, it got past as an observer.
20160907 14:06:39< celmin> Okay, so apparently MP wait doesn't end for non-hosts until after the host reaches the objectives screen. Weird.
20160907 14:14:20< celmin> I feel like there might be a bug in the MP lobby. I created a game, but needed to relog the other client to see it.
20160907 14:15:31-!- ancestral [~ancestral@225.sub-174-219-6.myvzw.com] has joined #wesnoth-dev
20160907 14:20:39-!- Netsplit *.net <-> *.split quits: crimson_penguin, DeFender1031, DDR, JyrkiVesterinen, Duthlet, boucman_work, Soliton
20160907 14:24:53< gfgtdf> celmin: mp wait shodul actuall end for non-host when the host clicks stat game
20160907 14:25:11-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160907 14:25:12< celmin> Yeah, that's what I would expect too.
20160907 14:25:16< celmin> But it's not what I got.
20160907 14:25:26< gfgtdf> celmin: i locally had some issues wit it that it ends for thme later, but i couldnt reproduce thme on offical mp ser ver.
20160907 14:25:58< gfgtdf> celmin: what you coudl try it, afer the hosts clicks start, post something in chat in the mp wait, maby that'll start the game then
20160907 14:27:09< gfgtdf> s/it/is
20160907 14:30:45-!- ancestral [~ancestral@225.sub-174-219-6.myvzw.com] has quit [Quit: i go nstuf kthxbai]
20160907 14:41:33< celmin> vultraz: Is the new add-ons manager fullscreen?
20160907 14:41:42< mattsc> Assume I have a commit number from something a long time ago, and I want to see the list of commits just before and after that, is there and easy way to get to that?
20160907 14:41:55< mattsc> I don’t really care if it’s on the website or the CL.
20160907 14:42:11-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160907 14:42:11-!- DeFender1031 [~DeFender1@46-116-114-128.bb.netvision.net.il] has joined #wesnoth-dev
20160907 14:42:11-!- DDR [~david@ec2.happyspork.com] has joined #wesnoth-dev
20160907 14:42:11-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20160907 14:42:11-!- Soliton [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev
20160907 14:42:22< celmin> git log COMMIT_HASH should show commits up to and including it.
20160907 14:42:44< celmin> I'm not sure how to see subsequent commits though.
20160907 14:43:18< mattsc> Okay, that answers half my question, thanks.
20160907 14:48:38< mattsc> I guess I could just do a git log, which gets piped into less, and then search for the hash
20160907 14:48:49< mattsc> might take a little, but should work
20160907 14:49:06< celmin> I've set git log to automatically use less.
20160907 14:49:25< celmin> And yeah, I'd expect that to work.
20160907 14:49:37< celmin> Another thing you could try is git log with a date range.
20160907 14:49:55< celmin> I never use that so I don't know the syntax off the top of my head.
20160907 14:50:31< mattsc> Oh, yeah, I didn’t know that that exists, but I am not surprised that it does.  I’ll check that out.
20160907 14:51:09< mattsc> In any case, all the builds around where I am trying to bisect at the moment are failing.  :-(
20160907 14:51:11< celmin> If you don't remember the date of the key commit, git show COMMIT_HASH
20160907 14:51:15< celmin> Aww.
20160907 14:51:23< celmin> Failing meaning won't build?
20160907 14:52:48< mattsc> Yep.
20160907 14:53:37< mattsc> and the one that did build gave me that segfault at start-up error that was around for quite some time IIRC.
20160907 15:03:05< celmin> Hmm.
20160907 15:03:30< celmin> Can dialogs in the background handle the RESIZE event?
20160907 15:03:37< celmin> Or only the front dialog?
20160907 15:05:13-!- Kwandulin [~Miranda@p200300760F4241512902D3600B240C70.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160907 15:09:51< celmin> Aginor: Any idea?
20160907 15:10:58 * celmin has the following situation: the title screen should close when the window is resized, so as to rebuild its layout (and reopen); however, sometimes another dialog may be open over it. In this case it should close once that dialog is dismissed.
20160907 15:11:33< celmin> Hmm. Can I test this...
20160907 15:12:32< celmin> Aha, looks like it does indeed work.
20160907 15:30:22-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Remote host closed the connection]
20160907 15:30:56-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160907 15:34:02-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Remote host closed the connection]
20160907 15:34:42-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160907 15:48:27-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Ping timeout: 244 seconds]
20160907 15:49:36< mattsc> Phew, I finally managed to build the 1.13.4 tag.
20160907 15:50:16< mattsc> And the [disable] special not working is already in it, but not in 1.13.2.  Babysteps …
20160907 15:50:33-!- prkc [~prkc@46.166.137.223] has joined #wesnoth-dev
20160907 15:50:39< celmin> Was 1.13.3 the skipped one?
20160907 15:50:45< mattsc> yeah
20160907 15:51:15< mattsc> And the 1.13.4 dmg never worked for me, because the internal references in the dylibs are wrong.
20160907 15:51:44-!- prkc [~prkc@46.166.137.223] has quit [Client Quit]
20160907 15:52:41-!- prkc [~prkc@46.166.137.223] has joined #wesnoth-dev
20160907 15:54:28-!- prkc [~prkc@46.166.137.223] has quit [Remote host closed the connection]
20160907 15:57:43-!- atarocch [atarocch@nat/redhat/x-xvpguikndhuicdwk] has quit [Ping timeout: 252 seconds]
20160907 15:57:48-!- atarocch_ [atarocch@nat/redhat/x-jqlbgalbfxsnkgxt] has quit [Ping timeout: 250 seconds]
20160907 16:02:44-!- prkc [~prkc@46.166.137.223] has joined #wesnoth-dev
20160907 16:04:50-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160907 16:05:52-!- prkc [~prkc@46.166.137.223] has quit [Client Quit]
20160907 16:07:40-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160907 16:09:08-!- prkc [~prkc@46.166.137.223] has joined #wesnoth-dev
20160907 16:10:25-!- prkc [~prkc@46.166.137.223] has quit [Remote host closed the connection]
20160907 16:11:04-!- Kwandulin [~Miranda@p200300760F4241512902D3600B240C70.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160907 16:11:17-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 16:11:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 16:11:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 16:16:37-!- JyrkiVesterinen [~JyrkiVest@78-27-107-170.bb.dnainternet.fi] has joined #wesnoth-dev
20160907 16:23:01-!- mjs-de [~mjs-de@x4db68d36.dyn.telefonica.de] has joined #wesnoth-dev
20160907 16:26:31-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160907 16:26:31-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160907 16:27:26< celmin> Blargh, refactoring the campaign list will not be as easy as refactoring the MP selector.
20160907 16:27:40< celmin> I could make it fullscreen instead...
20160907 16:27:46< celmin> vultraz: Thoughs?
20160907 16:27:49< celmin> ^Thougts
20160907 16:27:52< celmin> ^Thoughts
20160907 16:27:54< celmin> Blargh.
20160907 16:33:01-!- gfgtdf [~chatzilla@x4e36aca5.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160907 16:45:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 16:46:05-!- prkc [~prkc@46.166.137.223] has joined #wesnoth-dev
20160907 16:48:16-!- prkc [~prkc@46.166.137.223] has quit [Client Quit]
20160907 16:48:26-!- prkc [~prkc@46.166.137.223] has joined #wesnoth-dev
20160907 16:53:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 16:55:13-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20160907 16:55:20< celmin> Yeah, needs a create_engine. Not touching that.
20160907 16:58:04< fabi> Aginor: Regarding the steam controller.
20160907 16:58:16< fabi> I have only tested it on Linux so far.
20160907 16:58:49< fabi> And I only recently configured it to work when the steam client is not started.
20160907 16:59:11< fabi> It then emulates the xbox controller.
20160907 16:59:32-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 240 seconds]
20160907 16:59:42< fabi> I am not sure on support based on the steam client.
20160907 17:00:34< fabi> Especially if general support for it also means proper support for every gamepad/joystick/thing.
20160907 17:00:37-!- prkc [~prkc@46.166.137.223] has quit [Remote host closed the connection]
20160907 17:02:55-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 17:05:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160907 17:07:31-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160907 17:08:43-!- prkc [~prkc@46.166.137.223] has joined #wesnoth-dev
20160907 17:12:50-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20160907 17:20:04-!- Ivanovic_ [~ivanovic@p4FC53EA4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160907 17:20:04-!- Ivanovic_ [~ivanovic@p4FC53EA4.dip0.t-ipconnect.de] has quit [Changing host]
20160907 17:20:04-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160907 17:20:29-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 260 seconds]
20160907 17:20:56-!- gfgtdf [~chatzilla@x4e36aca5.dyn.telefonica.de] has joined #wesnoth-dev
20160907 17:22:00-!- Ivanovic_ is now known as Ivanovic
20160907 17:23:13-!- prkc [~prkc@46.166.137.223] has quit [Remote host closed the connection]
20160907 17:40:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160907 17:54:23-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160907 17:56:48-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160907 17:57:06-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160907 18:28:54-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160907 18:32:55< celmin> If I register hotkeys in pre_show instead of post_build, will they still work...
20160907 18:37:13< celmin> From the implementation, I see no reason why they wouldn't.
20160907 18:45:36< mattsc> vultraz: the [disable] weapon special is currently broken on offense.  The disabled weapon will show in the attack dialog and you can use it just fine.  By contrast, on defense it is disabled.
20160907 18:45:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 18:46:40-!- ancestral [~ancestral@225.sub-174-219-6.myvzw.com] has joined #wesnoth-dev
20160907 18:47:48< mattsc> I’ve been bisecting and tracked the culprit down to a series of commits you made in January on tunit-*.  Probably tunit_attack, would be my guess, but I cannot prove that, as the commits compile individually, but the attack dialog crashes for intermediate builds.
20160907 18:48:15< mattsc> The last non-broken commit I can demonstrate is e7fb4521af9
20160907 18:49:47< mattsc> The first definitely broken one is 8ae305f1
20160907 18:50:11-!- Kwandulin [~Miranda@p200300760F424151D91D6ECECD93880F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160907 19:00:06-!- ancestral [~ancestral@225.sub-174-219-6.myvzw.com] has quit [Quit: i go nstuf kthxbai]
20160907 19:02:19< celmin> Just at a glance, I guess potentially suspicious ones would be 698a5b1d, 2c487ffd, 3641525c, 8f8b18c8, but that's without looking at diffs.
20160907 19:02:33< celmin> Just based on the commit message.
20160907 19:11:36< vultraz> [03:27:22]	celmin	Blargh, refactoring the campaign list will not be as easy as refactoring the MP selector.
20160907 19:11:39< vultraz> what?
20160907 19:11:46< mattsc> vultraz, celmin: actually, I have found the commit that makes the attack dialog, so I can narrow it down a bit more.
20160907 19:11:57< mattsc> I’m off right now though, will get back to this in a couple hours.
20160907 19:12:04< vultraz> celmin: what are you doing
20160907 19:12:10< celmin> Titlescreen
20160907 19:12:34< vultraz> and why does that touch the campaign dialog
20160907 19:13:09< vultraz> [01:41:29]	celmin	vultraz: Is the new add-ons manager fullscreen?
20160907 19:13:10< vultraz> yes
20160907 19:14:04< celmin> Because the intent was for the campaign dialog to be displayed above the titlescreen, but that seems to be impossible with how it currently works.
20160907 19:14:14< vultraz> how so?
20160907 19:15:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 19:16:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 19:20:50< celmin> The desired execution path is as follows:
20160907 19:20:57< celmin> 1. User clicks Campaigns button.
20160907 19:21:00< mattsc> vultraz: okay, I did have a few more minutes finishing it
20160907 19:21:09< celmin> 2. Campaign select dialog is shown. User selects a campaign.
20160907 19:21:11< mattsc> the culprit is one of these three: 1c3d207ce1, fbb2f58959 or 2c487ffd489
20160907 19:21:25< mattsc> And looking at the commit message, probably the last of those
20160907 19:21:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160907 19:21:43< celmin> 3. Titlescreen closes, and single-player mode is entered.
20160907 19:21:52< celmin> The current execution path is as follows:
20160907 19:21:57< celmin> 1. User clicks Campaigns button.
20160907 19:22:07< celmin> 2. Titlescreen closes, and campaign select dialog is shown.
20160907 19:22:12< celmin> User selects a campaign.
20160907 19:22:19< celmin> 3. Single-player mode is entered.
20160907 19:22:41< gfgtdf> celmin: so why can't we change that ?
20160907 19:23:00< celmin> It's not that we can't, it's that it's hard.
20160907 19:23:25< celmin> game_launcher::new_campaign initializes a create_engine, passes it to the campaign select dialog, and then enters single-player mode.
20160907 19:23:44< celmin> First, the fact that a create_engine is needed at all is a problem.
20160907 19:24:04< gfgtdf> celmin: well you dotn need the create engine after the game is created
20160907 19:25:15< celmin> But, the title screen does now hold a reference to the game_launcher, so I suppose I could add a unique_ptr<create_engine> in the game_launcher...
20160907 19:27:43< celmin> Maybe this is resolvable after all.
20160907 19:28:40< gfgtdf> well in any case it needs to refactor wesnoth.cpp whcih previousl just calls gui2::ttitle_screen().show(game->video()); and then handles the return value of the dialog, if we want tho keep the dialog open we should make gui2::ttitle_screen open those other dialogs (loadgame, sp create, changelanguage) directly.
20160907 19:28:52< gfgtdf> s/previousl/currently*
20160907 19:29:00< vultraz> yes
20160907 19:29:09< vultraz> we should do that
20160907 19:29:17< celmin> Yes, I already did that.
20160907 19:31:06< vultraz> btw, I'm working on the load game issues
20160907 19:32:09< gfgtdf> then i'd say the titltescreen dialog jsut calls game_launcher::new_campaign and game->launch_game is called after the dialog has closed liek before.
20160907 19:32:30< celmin> Wait...
20160907 19:33:37< celmin> I guess you're right after all… somehow I thought new_campaign was actually launching the game.
20160907 19:34:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160907 19:43:24< celmin> What was the reason for including .vcxproj.user files in the repo?
20160907 19:43:26< celmin> wedge009: ^
20160907 19:43:49< celmin> Or maybe gfgtdf or JyrkiVesterinen knows?
20160907 19:44:21< JyrkiVesterinen> I don't recall what exactly VS stores in .vcxproj.user.
20160907 19:45:41< gfgtdf> celmin: well the commit message of the commit that adds them says '*.vcproj.user files contain general settings, e.g. for the debugger, which
20160907 19:45:43< gfgtdf> are required for our unit tests.'
20160907 19:46:19< celmin> The VC solution doesn't even include unit tests though?
20160907 19:47:23< gfgtdf> celmin: dont know since i usually dont use them but update my local projectfiles instead, aquileia might know.
20160907 19:50:06-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:05:19< celmin> Hmm. I was going to close the titlescreen after the dialog to select the type of multiplayer game, but I suppose I could only close it once you accept the MP connect screen… though I kinda don't like the idea of a loading screen over the title screen for some reason...
20160907 20:06:16< gfgtdf> hmm what do you mena by accept the mp connect screen ?
20160907 20:07:18< celmin> Clicking "I'm Ready"
20160907 20:09:27-!- Kwandulin [~Miranda@p200300760F424151D91D6ECECD93880F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160907 20:09:42< gfgtdf> celmin: hmm so why canot su close it after the dialog to select the type of multiplayer game?
20160907 20:10:05< celmin> I can. I already coded that too, so I'll probably stick with it.
20160907 20:10:19< celmin> But then it's inconsistent with how SP is handled.
20160907 20:10:26< celmin> Maybe that doesn't actually matter though.
20160907 20:13:12< celmin> This should_reload stuff seems a bit annoying.
20160907 20:20:35-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Ping timeout: 244 seconds]
20160907 20:22:35-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160907 20:23:23< vultraz> celmin: since you're on the titlescreen could you test something for a moment
20160907 20:23:48< celmin> Not if you want it right away.
20160907 20:23:59< celmin> What is it>
20160907 20:24:01< celmin> ^?
20160907 20:24:46< vultraz> try to load a campaign with change difficulty on, and see if clicking Cancel on the difficulty dialog still makes it lod
20160907 20:25:21< celmin> What does "with change difficulty on" mean?
20160907 20:25:47< vultraz> there's a checkbox to change difficulty if you're loading a start-of-scenario save
20160907 20:25:52< vultraz> check it
20160907 20:26:46< celmin> So what you're really asking me isn't to start a campaign after all.
20160907 20:27:06< celmin> Well, my build is currently broken, so I can try once it works if you still need it then.
20160907 20:27:20-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160907 20:27:22< celmin> (It has to be a campaign rather than MP?)
20160907 20:27:34< celmin> (Oh right, only campaigns have difficulty.)
20160907 20:27:37< vultraz> anything where that checkbox is enabled
20160907 20:28:49< vultraz> from the code it looks like it won't
20160907 20:28:53< vultraz> but just want to confirm
20160907 20:29:36< celmin> I can test it, but it'll be faster if you ask someone else since I'm in the middle of stuff.
20160907 20:30:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:30:19< vultraz> gfgtdf maybe?
20160907 20:30:34< celmin> Or Jyrki or mattsc?
20160907 20:30:52 * celmin listing everyone who has spoken here since I woke up.
20160907 20:31:04< JyrkiVesterinen> Not me. I'm going to bed soon.
20160907 20:32:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:39:39< vultraz> nevermind, I guess
20160907 20:39:43< vultraz> I've fixed it
20160907 20:39:50< vultraz> to behave correctly
20160907 20:42:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:42:43< celmin> I am using lambdas for all of the button callbacks. >_>
20160907 20:42:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:42:53< celmin> (Well, except two, but I might end up changing that.)
20160907 20:42:55< vultraz> \o/
20160907 20:43:00< vultraz> come to the dark side
20160907 20:43:06< celmin> Hey, don't cheer for something silly like that. :P
20160907 20:44:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:44:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:45:04< celmin> The only titlescreen buttons that already had a callback bound were… debug clock, next/previous tip, and info.
20160907 20:45:09-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:46:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:46:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:46:20< vultraz> Hm
20160907 20:46:44< vultraz> I just realized that maybe loading when canceling the difficulty dialog was the desired behavior
20160907 20:46:46< vultraz> ie, 
20160907 20:46:55< vultraz> load game.. oh wait, I don't want to change difficulty
20160907 20:46:57< vultraz> hm
20160907 20:47:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:47:06< vultraz> celmin: which do you think is better?
20160907 20:47:33< gfgtdf> hm i'll try to widgetize the mp chatbox.
20160907 20:47:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:47:36< celmin> vultraz: Cancelling the difficulty dialog should return you to load game. If you decided not to change the difficulty after all, you cancel, uncheck the box and load.
20160907 20:48:05< vultraz> that might be rather difficult..
20160907 20:48:13< celmin> Shouldn't be.
20160907 20:48:22< vultraz> I'd need... a dialog loop :|
20160907 20:48:23-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:48:25< celmin> No?
20160907 20:48:27< vultraz> or
20160907 20:48:35< vultraz> move the difficulty dialog call to tload_game
20160907 20:48:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:48:41< celmin> Or...
20160907 20:49:04< vultraz> except then I'd need one of those exit hooks :/
20160907 20:49:17< celmin> Do you know what the saved game's current difficulty is?
20160907 20:49:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:49:30< vultraz> I think so
20160907 20:49:40< celmin> Can you make it select that as the default?
20160907 20:49:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:50:06< vultraz> maybe
20160907 20:50:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:50:27< celmin> Incidentally, in the general case, looping a dialog show isn't what you want.
20160907 20:50:33< celmin> Because the entire layout resets.
20160907 20:50:36< vultraz> another time, perhaps
20160907 20:50:45< celmin> This doesn't matter for the title screen since the layout never changes to begin with.
20160907 20:50:53< celmin> But for load game, that would be terrible.
20160907 20:51:11< celmin> I don't think it should continue to load if you click cancel at any point, though.
20160907 20:51:20-!- irker744 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160907 20:51:20< irker744> wesnoth: Charles Dang wesnoth:master 9ea794e5a4bb / src/gui/widgets/ (listbox.cpp listbox.hpp): Listbox: added getter to check if any row is visible https://github.com/wesnoth/wesnoth/commit/9ea794e5a4bbb841349519502e905325687c9196
20160907 20:51:21< irker744> wesnoth: Charles Dang wesnoth:master a0ad80299b66 / src/ (gui/dialogs/game_load.cpp gui/dialogs/game_load.hpp savegame.cpp savegame.hpp): Fixed a bunch of issues with game loading https://github.com/wesnoth/wesnoth/commit/a0ad80299b66aea1396837049a59b84eabbd178f
20160907 20:51:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:51:41< celmin> Travis is still broken, right?
20160907 20:51:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:51:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:52:04< vultraz> will likely break more if there was a load game test
20160907 20:52:11< celmin> I haven't pushed my thing that I fixed yet.
20160907 20:52:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:52:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:53:06< celmin> Mind if I remove that getter later?
20160907 20:53:20< vultraz> turns out the load game dialog had this really ridiculous design..
20160907 20:53:26< celmin> In favour of get_rows_shown().any()
20160907 20:53:27< vultraz> it registered local bool fields
20160907 20:53:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:53:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:53:49< vultraz> then passed the value of that to local member variables in post_show
20160907 20:54:09< vultraz> then used getter methods to get those values in loadgame::show_dialog if you clicked OK
20160907 20:54:11< celmin> At least, I think .any() is correct.
20160907 20:54:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:54:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:54:44< vultraz> instead, I moved the data into a struct (as I am wont to do :P ) and then passed the struct directly into the fields.
20160907 20:54:48-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:54:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:54:55< vultraz> celmin: hm?
20160907 20:54:57< vultraz> .any()?
20160907 20:55:03< celmin> I want to remove any_rows_shown
20160907 20:55:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:55:23< celmin> I had a plan to replace vector<bool> with boost::dynamic_bitset, which offers that functionality directly.
20160907 20:55:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:55:41< vultraz> sure
20160907 20:55:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:56:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:56:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:56:49-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:57:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:57:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:58:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:58:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 20:59:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 20:59:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:00:31< vultraz> celmin: btw, do confirm if the issues you experienced are fixed when you have a chance
20160907 21:00:38-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:00:46< celmin> Sure
20160907 21:00:51-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:01:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:01:49-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:02:04-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:02:14< vultraz> I need to consider implementing that dialog exit hook
20160907 21:02:31-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:03:01-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:03:17-!- mjs-de [~mjs-de@x4db68d36.dyn.telefonica.de] has quit [Remote host closed the connection]
20160907 21:03:54-!- JyrkiVesterinen [~JyrkiVest@78-27-107-170.bb.dnainternet.fi] has quit [Quit: .]
20160907 21:04:10-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:04:27-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:05:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160907 21:06:10< celmin> What?
20160907 21:06:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:06:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:07:15< vultraz> it seems the best way to handle the difficulty dialog is some hook on exit
20160907 21:07:27< celmin> Huh?
20160907 21:07:55< vultraz> the campaign dialog returns to the campaign selection screen using a loop
20160907 21:08:00< vultraz> loops aren't great
20160907 21:08:09< celmin> Lies.
20160907 21:08:13< celmin> Loops are great.
20160907 21:08:15-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:08:19-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:08:29< vultraz> [07:50:23]	celmin	Incidentally, in the general case, looping a dialog show isn't what you want.
20160907 21:08:41< celmin> (That said, that's not a good use of them. Why not make the dialog put up the difficulty choice before exiting?)
20160907 21:08:54< vultraz> that's exactly what I'm saying :|
20160907 21:08:59< vultraz> we need an on_exit hook
20160907 21:09:03< celmin> BTW, I called that "the general case", but it only applies to Wesnoth.
20160907 21:09:04< vultraz> that can return to the dialog
20160907 21:09:13-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:09:22-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:09:34< celmin> I don't really see why we need an on exit hook, but I can't see any reasons against it, I guess
20160907 21:09:45< vultraz> post_show happens *after* the dialog closes
20160907 21:09:55< vultraz> we need something that happens before it closes
20160907 21:09:57-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:10:00-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:10:04< celmin> We don't really need it.
20160907 21:10:08< vultraz> why?
20160907 21:10:12< celmin> Just attach a callback to the OK button.
20160907 21:10:30< vultraz> yes, and as in mp create, all the toggle panels in the listbox :|
20160907 21:10:47< vultraz> not even counting Enter
20160907 21:10:48-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:10:49-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:11:00< vultraz> which I'm not even sure MP Create handles.
20160907 21:11:13< celmin> I think it doesn't. The GUI1 version didn't either, but I think that should change.
20160907 21:11:42-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:11:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:12:21< vultraz> yeah, Enter selects a campaign without showing difficulty
20160907 21:12:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:13:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:13:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:13:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:14:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:14:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:14:49< celmin> I wonder if windows trigger an event on close()...
20160907 21:14:56-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:14:57-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:15:05< celmin> Repeatedly showing a dialog is problematic, but repeatedly showing a window should be fine.
20160907 21:15:25-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20160907 21:15:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:15:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:16:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:16:30-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:16:45-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:17:12-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:17:24-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:17:51-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:18:21-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:18:47-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:18:48-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 21:19:01-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:19:06-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160907 21:19:23-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:19:25-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160907 21:19:31< vultraz> im not sure where such a function would be called from, though
20160907 21:19:46-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 21:20:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 252 seconds]
20160907 21:20:45< vultraz> there's a CLOSE_WINDOW_EVENT...
20160907 21:20:51< celmin> Perfect.
20160907 21:20:57< vultraz> wait, that's only for auto-close :|
20160907 21:21:09< vultraz> and it's an SDL_event
20160907 21:21:27< vultraz> not perfect
20160907 21:21:30< celmin> Oh, if it's an SDL event, it's probably "clicking the X".
20160907 21:21:50< vultraz> no, it's a custom event
20160907 21:21:57< vultraz> #define CLOSE_WINDOW_EVENT (SDL_USEREVENT + 4)
20160907 21:22:01< celmin> Oh.
20160907 21:22:09< celmin> So where is it triggered?
20160907 21:22:14< vultraz> it's for the auto-close functionality
20160907 21:22:18< vultraz> ie, close window after n time.
20160907 21:22:34< celmin> So where is it triggered and handled?
20160907 21:22:39< vultraz> and all it does is set the window's retval :/
20160907 21:22:50< vultraz> handler.cpp:367
20160907 21:23:04< celmin> window.cpp, lines 617 and 622.
20160907 21:23:07< vultraz> constructed at
20160907 21:23:09< vultraz> yeah
20160907 21:23:14< vultraz> wait
20160907 21:23:25< vultraz> yeah, I guess
20160907 21:23:40< vultraz> there's also this REQUEST_CLOSE thing, but only window.close() uses that...
20160907 21:24:13< celmin> Why the heck is -W used for "function context".
20160907 21:24:26< celmin> Wait, that's not actually what I wanted.
20160907 21:24:36< celmin> I want -p
20160907 21:24:42< celmin> (git grep -p)
20160907 21:25:09< celmin> Okay, so in twindow::show.
20160907 21:25:17< vultraz> yes
20160907 21:25:28< celmin> It redundantly assigns type twice.
20160907 21:25:54< celmin> SDL_Event is a union, so "event.user = data" overwrites "event.type = CLOSE_WINDOW_EVENT".
20160907 21:25:54-!- travis-ci [~travis-ci@ec2-54-159-31-87.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 21:25:55< travis-ci> wesnoth/wesnoth#10758 (master - a0ad802 : Charles Dang): The build is still failing.
20160907 21:25:55< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158286593
20160907 21:25:55-!- travis-ci [~travis-ci@ec2-54-159-31-87.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 21:26:06-!- nore [~ncourant@sas.eleves.ens.fr] has joined #wesnoth-dev
20160907 21:26:17< vultraz> ok
20160907 21:26:44< celmin> Hmm, but since it's an SDL event, you can't connect a signal to it, right?
20160907 21:27:12< celmin> So I guess that doesn't help too much...
20160907 21:27:21< vultraz> yeah...
20160907 21:27:48< celmin> Well...
20160907 21:27:58< vultraz> hmmm
20160907 21:28:00< vultraz> set_retval...
20160907 21:28:10< vultraz> it has a second parameter 
20160907 21:28:14< celmin> Eh?
20160907 21:28:14< vultraz> close_window o_O
20160907 21:28:19< vultraz> it defaults to true
20160907 21:28:19< celmin> Oh wow.
20160907 21:28:42< vultraz> this is... surprising 
20160907 21:28:46< celmin> Yeah.
20160907 21:28:48< vultraz> I must consider the implications
20160907 21:29:18< celmin> Probably means there are some places that are redundantly closing the window after setting the retval.
20160907 21:30:08< vultraz> one plac ei ca think of
20160907 21:31:09< celmin> ?
20160907 21:31:21< vultraz> one place i can think of
20160907 21:31:23< vultraz> in the dropdown list
20160907 21:31:36< celmin> Think so, yeah.
20160907 21:32:02< vultraz> hmm
20160907 21:32:17< vultraz> so this means we can set retvals without closing the dialog
20160907 21:32:26< celmin> What's the benefit of that?
20160907 21:32:49< vultraz> well, it doesn't help if we can't actually trigger the event
20160907 21:33:38< vultraz> ok, so close sets REQUEST_CLOSE...
20160907 21:33:45< vultraz> and there's a loop here.. for(status_ = SHOWING; status_ != REQUEST_CLOSE;) {
20160907 21:34:53< vultraz> I think
20160907 21:35:10< celmin> Closing the window may not necessarily mean closing the dialg.
20160907 21:35:13< celmin> ^dialog
20160907 21:35:18-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160907 21:35:21< vultraz> true...
20160907 21:35:22< vultraz> :|
20160907 21:35:39< celmin> You might be able to implement an exit hook with a looped window.show() in dialog::show.
20160907 21:35:57< celmin> But whether that's a good way, I dunno.
20160907 21:36:02< vultraz> though once the window is closed it then just goes to postshow
20160907 21:36:04< vultraz> I was thinking
20160907 21:36:27< vultraz> inside the events pump loop, check fi status == REQUEST_CLOSE
20160907 21:36:43< vultraz> allow twindow to be passed a bool(twindow&) function
20160907 21:36:46< vultraz> then say..
20160907 21:37:22< vultraz> if(status == REQUEST_CLOSE) { if(!func(*this)) { status = SHOWING; } }
20160907 21:37:34< celmin> Perhaps.
20160907 21:40:01< vultraz> I think that'd be acceptable
20160907 21:44:27-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160907 21:49:59< mattsc> hi vultraz
20160907 21:50:33< mattsc> Just want to confirm that you saw my messages to you about the [disable] special problem and that (whenever you get to it) you’ll look into it.
20160907 21:51:11< mattsc> I’m trying to fix an unrelated bug of the AI ignoring that special under some circumstances, but I can do that with 1.12.6.
20160907 21:52:39-!- Appleman1234 [~Appleman1@KD119104109119.au-net.ne.jp] has quit [Ping timeout: 264 seconds]
20160907 21:54:59< vultraz> mattsc: im really not sure why you keep pinging me about the [disable] special, since I don't really have anything to do with it :/
20160907 21:55:13< mattsc> vultraz: because you broke it
20160907 21:55:18< mattsc> as I explained in my messages
20160907 21:55:21< vultraz> oh
20160907 21:55:23< vultraz> I see...
20160907 21:55:41< celmin> Something to do with the new attack dialog, seemingly.
20160907 21:56:03< mattsc> Yeah; my guess is that the special itself isn’t borken, but that the attack dialog does not account for it.
20160907 21:56:06< mattsc> Or something.
20160907 21:56:25< celmin> I doubt the special itself actually does anything.
20160907 21:56:40< mattsc> True.
20160907 21:56:44< vultraz> so, wait, what is the issue?
20160907 21:57:08< mattsc> If I [disabe] a weapon, the attack dialog let’s me use it anyway.
20160907 21:57:32< vultraz> ah, I see the problem
20160907 21:58:32< mattsc> Before the commit I mention above, it woudl say “no available weapon” (or list only those that remained enabled)
20160907 21:58:51< mattsc> Now you can continue to use it.
20160907 22:00:58-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Ping timeout: 244 seconds]
20160907 22:01:03-!- clavi [~clavi@163-172-10-77.rev.poneytelecom.eu] has quit [Ping timeout: 276 seconds]
20160907 22:01:19< irker744> wesnoth: Charles Dang wesnoth:master 67f31138084b / src/gui/dialogs/unit_attack.cpp: Unit Attack: attempt to fix disabled weapons showing https://github.com/wesnoth/wesnoth/commit/67f31138084bd6ba5a0e8d095002aafa3217ee3f
20160907 22:01:33< vultraz> mattsc: ^ could you see if that works?
20160907 22:01:37-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160907 22:01:51< celticminstrel> Bah, slipped right in the crack there.
20160907 22:02:19 * vultraz is sneaky
20160907 22:06:17-!- clavi [~clavi@163-172-10-77.rev.poneytelecom.eu] has joined #wesnoth-dev
20160907 22:07:46-!- Appleman1234 [~Appleman1@KD119104101149.au-net.ne.jp] has joined #wesnoth-dev
20160907 22:10:50< vultraz> celmin: hm... about this loop in twindow::show.. if status is set to REQUEST_CLOSE, then the loop won't fire, meaning the exit hook won't be reached, right?
20160907 22:12:42< vultraz> I think I need a while loop here, maybe.. do { .. stuff ...  if(status == REQUEST_CLOSE) { if(!func(*this)) { status = SHOWING; } } } while(status_ == SHOWING)
20160907 22:13:09< celmin> What.
20160907 22:13:09< vultraz> then again
20160907 22:13:14< vultraz> same problem, maybe?
20160907 22:13:19< vultraz> yeah...
20160907 22:14:06< vultraz> maybe I just loop and then break?
20160907 22:14:32< celmin> I don't know what you're talking about, so...
20160907 22:14:49< vultraz> right now the loop is for(status_ = SHOWING; status_ != REQUEST_CLOSE;) {
20160907 22:15:09< vultraz> but I also want to perform actions inside the loop if status_ == REQUEST_CLOSE
20160907 22:15:14< celmin> And the content is something like events::pump if I recall correctly?
20160907 22:15:20< vultraz> yes
20160907 22:16:04< celmin> Are there only two possible values?
20160907 22:16:27< vultraz> I think any loop that predicates status == SHOWING or status != REQUEST_CLOSE would never reach a point where status == REQUEST_CLOSE is true inside the loop
20160907 22:16:47< vultraz> celmin: there's also NEW and CLOSED
20160907 22:17:10< celmin> You could change the check to status != CLOSEd
20160907 22:17:13< celmin> CLOSED
20160907 22:17:26< celmin> And add a check to the end of the loop for REQUEST_CLOSE that then sets it to CLOSED.
20160907 22:18:02< vultraz> in which case, should this notbecome a do{ } while() loop instead of for?
20160907 22:21:46< celmin> I don't think it makes a difference what kind of loop it is.
20160907 22:22:01< celmin> So I'd opt for not changing the loop type unless I had a very good reason.
20160907 22:25:39< mattsc> vultraz: sorry, needed full reset and recompile and RL stuff going on at the same time ...
20160907 22:25:48< mattsc> vultraz: now I get this: “Assertion failed: (best_weapon < static_cast<int>(weapon_list.get_item_count())), function set_weapon_info, file /mats/misc/Wesnoth/wesnoth/src/gui/dialogs/unit_attack.cpp, line 179.”
20160907 22:26:04< vultraz> wellll that's not good :|
20160907 22:26:22< celmin> All weapons disabled?
20160907 22:26:26< mattsc> I’m going to be away for the next couple hours, and as I said, I can work in 1.12 anyway for the time being.  So no rush.
20160907 22:26:35< mattsc> Yes, all weapons disabled.
20160907 22:26:52< mattsc> I’m going to do tests with individual weapons, and with sepcific filters later.
20160907 22:27:03< vultraz> all weapons disabled..
20160907 22:27:04< vultraz> hm...
20160907 22:27:05< mattsc> Right now I just have a blanket [disable][/disable]
20160907 22:27:19< vultraz> the dialog should not show at all in that case
20160907 22:27:24< mattsc> … for a unit that has only one weapon
20160907 22:27:39< mattsc> It doesn’t show.  It just crashes.  ;)
20160907 22:27:48< vultraz> because it's trying to show
20160907 22:28:34< mattsc> Right.
20160907 22:28:47< mattsc> Anwyays, I’ll be afk for at least 1.5 hours right now.  TTYL.
20160907 22:28:54< celmin> I'm up to my ears in template errors. :/
20160907 22:31:56< celmin> Bind errors, to be precise.
20160907 22:32:09< celmin> And it's a bind call that was in the original version that I haven't changed… :|
20160907 22:34:36< vultraz> letopkek
20160907 22:37:32-!- travis-ci [~travis-ci@ec2-54-221-43-200.compute-1.amazonaws.com] has joined #wesnoth-dev
20160907 22:37:33< travis-ci> wesnoth/wesnoth#10759 (master - 67f3113 : Charles Dang): The build is still failing.
20160907 22:37:33< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158302897
20160907 22:37:33-!- travis-ci [~travis-ci@ec2-54-221-43-200.compute-1.amazonaws.com] has left #wesnoth-dev []
20160907 22:38:33< vultraz> HM
20160907 22:38:46< vultraz> my dialog exit hook is not working as expected :/
20160907 22:40:39< vultraz> ah, I see
20160907 22:40:57-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20160907 22:40:57-!- esr [~esr@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20160907 22:40:57-!- esr [~esr@wesnoth/developer/esr] has joined #wesnoth-dev
20160907 22:41:04< vultraz> eh, now it's the opposite problem :/
20160907 22:43:28< vultraz> hmmm
20160907 22:44:25-!- Greg-Bog_ [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160907 22:47:45< celmin> I seem to have solved all but one. Somehow.
20160907 22:50:17< vultraz> ok, I seem to have gotten it working
20160907 22:52:05< celmin> Okay, I think maybe I should use a typedef here.
20160907 22:52:57< celmin> (By which I mean "using". I call them typedefs either way.)
20160907 22:55:19< vultraz> does using work with typename?
20160907 22:59:59< vultraz> I think it does
20160907 23:00:10< celmin> What?
20160907 23:00:18< celmin> typename is totally unrelated to typedefs.
20160907 23:00:26< celmin> It's a disambiguation mechanism.
20160907 23:00:51< celmin> (And a template argument type.)
20160907 23:01:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160907 23:02:10< vultraz> hmm
20160907 23:02:15< vultraz> yeah, that does make sense..
20160907 23:02:28< vultraz> what exactly does it do, though?
20160907 23:02:44< vultraz> I never bothered to find out
20160907 23:03:08< celmin> In the definition of a template, the compiler often cannot tell whether a name refers to a type, variable, or template without additional help.
20160907 23:03:24< celmin> If it finds itself in this situation, it assumes it is a template, unless disambiguation is used.
20160907 23:03:34< celmin> ^variable, not template
20160907 23:05:00< celmin> You disambiguate using either the typename keyword or the template keyword.
20160907 23:05:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160907 23:06:26< vultraz> so template<typename T> means T is explicitly a name of a type, whereas template<class T> means T is a class name?
20160907 23:07:20< gfgtdf> it means teh same
20160907 23:07:35< vultraz> ..huh
20160907 23:08:02< gfgtdf> vultraz: what celmin means is when you write typename T::value_type
20160907 23:09:24< gfgtdf> vultraz: since the cimpiler doesnt know the type of T it cannot tell whether value_type is a variable a type or a function.
20160907 23:11:15< gfgtdf> vultraz: in wesnoth for example i thos code "template<typename T> typename std::enable_if<std::is_base_of<enum_tag, T>::value, attribute_value &>::type operator=(const T &v) {...}"
20160907 23:11:35 * vultraz blinks
20160907 23:11:40< celmin> gfgtdf: No.
20160907 23:11:52< vultraz> for the record, I don't understand the enable_if stuff
20160907 23:11:52< celmin> That's the use of template and typename when declaring a template, which is totally different.
20160907 23:12:26< gfgtdf> celmin: 'no' to which statement exactly ?
20160907 23:12:34< celmin> Template for disambiguation would be eg "typename some_class<template_parm>::template some_other_class<more_template_parms>"
20160907 23:12:42< celmin> [Sep 07@7:06:26pm] vultraz: so template<typename T> means T is explicitly a name of a type, whereas template<class T> means T is a class name?
20160907 23:12:52< celmin> template<typename T> and template<class T> are entirely equivalent.
20160907 23:12:58< vultraz> I see
20160907 23:13:05< vultraz> so why do we use one or the other?
20160907 23:13:28< celmin> Taste?
20160907 23:13:37< gfgtdf> well, thats what i said.
20160907 23:13:43< vultraz> I see
20160907 23:14:17< vultraz> I think perhaps in order to understand this fully I need to understand ::type and ::value..
20160907 23:14:20< celmin> gfgtdf: Sorry, pinged wrong person there.
20160907 23:14:34< celmin> vultraz: Uhhhh… what?
20160907 23:14:38< celmin> You know what :: means, right?
20160907 23:14:54< vultraz> blah, yes,
20160907 23:14:55< vultraz> I meant
20160907 23:15:05< vultraz> like in gfgtdf's example
20160907 23:15:07< vultraz> std::enable_if<std::is_base_of<enum_tag, T>::value
20160907 23:15:09< vultraz> what is ::value
20160907 23:15:25< celmin> It's a static variable defined in the std::is_base_of class.
20160907 23:15:35< vultraz> ohh
20160907 23:15:57< vultraz> that makes sense
20160907 23:17:36< vultraz> as is type?
20160907 23:19:22-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds]
20160907 23:24:19< celmin> No, type is a typedef defined in the std::is_base_of class.
20160907 23:31:40< irker744> wesnoth: Charles Dang wesnoth:master d858c6b739be / src/gui/widgets/ (window.cpp window.hpp): GUI2/Window: implement dialog exit hooks https://github.com/wesnoth/wesnoth/commit/d858c6b739be5b2e5b621e774537f8c25dc61e62
20160907 23:31:43< irker744> wesnoth: Charles Dang wesnoth:master 969018f7df17 / / (6 files in 3 dirs): MP Create: make use of window exit hook for showing the difficulty dialog https://github.com/wesnoth/wesnoth/commit/969018f7df17535c9912ed4b2f583dd41e152d54
20160907 23:31:46< irker744> wesnoth: Charles Dang wesnoth:master 276047ce96d5 / data/gui/window/preferences/05_multiplayer.cfg: Preferences Dialog: tweaked some labels in Friends List view https://github.com/wesnoth/wesnoth/commit/276047ce96d57badd9bb37814f3113ee553dea4e
20160907 23:32:17 * vultraz dusts off hands
20160907 23:32:49 * vultraz awaits inevitable review
20160907 23:33:52< celmin> set_exit_hook_ok_only could be made a bit more general, but I suppose it's not that important.
20160907 23:34:17< celmin> Especially since (with my titlescreen refactor) there's generally only three results.
20160907 23:34:54< celmin> Huh, a default value for the hook.
20160907 23:35:30< vultraz> Indeed
20160907 23:35:50< vultraz> I have found setting default values for such function members is much cleaner than having to check their existence.
20160907 23:36:11< celmin> You should still check their existence though/
20160907 23:36:28< celmin> If nothing else, in the setter, to make sure someone doesn't do set_exit_hook(nullptr) and break everything.
20160907 23:38:43< gfgtdf> whatever is called 'config' in gui2::widget/control we shodul rename it.
20160907 23:38:50< celmin> Heh.
20160907 23:39:09< celmin> Was it a function?
20160907 23:39:28< celmin> You can always access the config class as ::config, so while annoying it's not insurmountable.
20160907 23:39:37< gfgtdf> celmin: not sure but it forces meto always write ::config in widgets
20160907 23:41:22< vultraz> hmmmmm
20160907 23:41:35< vultraz> the change difficulty box in mp load doesn't work..
20160907 23:41:54< vultraz> yeah so it seems there are two different functions to show the difficulty dialog
20160907 23:42:00< vultraz> loadgame::show_difficulty_dialog
20160907 23:42:33< vultraz> create_engine::select_campaign_difficulty
20160907 23:42:54< vultraz> s/mp load/mp create's load game invocation 
20160907 23:44:09< vultraz> not.. sure what to do about this :?
20160907 23:44:24-!- Jetrel_bot is now known as trollio
20160907 23:44:30< celmin> What's the difference between them?
20160907 23:44:37-!- trollio is now known as Jetrel_bot
20160907 23:45:18-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160907 23:45:49< celmin> Still drowning in template errors.
20160907 23:46:33< vultraz> not much
20160907 23:46:45< vultraz> except create_engine's handled explicit pre-pass values
20160907 23:47:03< vultraz> and uses the current level's data
20160907 23:47:22< vultraz> loadgame's uses data from [campaign] directly
20160907 23:47:44< vultraz> and does not handle passed values
20160907 23:48:20< vultraz> and obviously, the former requires the create engine
20160907 23:48:51< vultraz> so, integrating the load game dialog with the difficulty dialog would be bad
20160907 23:49:02< vultraz> hmm..
20160907 23:49:16< vultraz> I'll need a quick fix for this issue, though..
20160907 23:54:56< vultraz> hmm
20160907 23:55:45-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
--- Log closed Thu Sep 08 00:00:26 2016