--- Log opened Sun Sep 04 00:00:30 2016
--- Day changed Sun Sep 04 2016
20160904 00:00:30< loonycyborg> iceiceice used scons on mac, he should know more about mac particulars
20160904 00:01:00< celmin> But he's not here.
20160904 00:01:34< loonycyborg> you could just copy/paste that command directly in command line and experiment with it
20160904 00:01:39 * vultraz is doing a change that might conflict slightly with the team_index_refactor branch
20160904 00:02:15< celmin> vultraz: A whole lot of things would conflict with that, so don't worry about it. It's probably got lots of conflicts already with master.
20160904 00:02:51< celmin> loonycyborg: Is release or debug build the default?
20160904 00:03:10< loonycyborg> release
20160904 00:04:59-!- irker066 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160904 00:04:59< irker066> wesnoth: Charles Dang wesnoth:master 6c637623857c / src/ (5 files in 2 dirs): Editor: move editor side info into a struct to avoid huge parameter lists https://github.com/wesnoth/wesnoth/commit/6c637623857cac6a7795e7c6d5678193be6f49ef
20160904 00:08:18< vultraz> (do remove that todo note in the branch, btw)
20160904 00:10:16< celmin> loonycyborg: I found extra_flags_*
20160904 00:10:33< celmin> Though it seems to cause the "check compiler works" test to fail.
20160904 00:10:36< celmin> So maybe I did it wrong.
20160904 00:10:51< loonycyborg> celmin: yes, but I'm not sure it's appropriate for -stdlib
20160904 00:11:09< celmin> Is there something more appropriate, then>
20160904 00:11:11< celmin> ^?
20160904 00:11:34< loonycyborg> you can set CXXFLAGS and LDFLAGS in environment
20160904 00:12:23< loonycyborg> extra_flags_* rely on same logic that is used for parsing output of pkg-config
20160904 00:12:58< loonycyborg> it automatically determines what flags must be passed to compiler and what to linker
20160904 00:13:08< loonycyborg> but it might fail in case of -stdlib
20160904 00:13:36< celmin> It said it defaults to compiler in that case, though I think it actually needs to be passed to both.
20160904 00:13:47< celmin> So how do I unset extra_flags_* now?
20160904 00:14:06< loonycyborg> extra_flags_*=
20160904 00:14:23< loonycyborg> you can just edit .scons-option-cache too
20160904 00:14:59< celmin> Looks like it'll work this time...
20160904 00:15:42< celmin> Seems like it's going now.
20160904 00:19:37< loonycyborg> cool
20160904 00:20:51< celmin> Ooh, lots of override warnings, cool.
20160904 00:21:37< celmin> Though I wonder if I'll be able to see them all in the terminal backscroll...
20160904 00:22:12< celmin> My backscroll is limited to 10,000 lines.
20160904 00:23:56-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 00:24:11-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 00:27:18< celmin> There's really a huge number of missing overrides. o.o
20160904 00:27:34< celmin> Well, to be more specific, "inconsistent missing overrides".
20160904 00:27:53-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160904 00:28:11< tad_> Is there an [ai] guru on?
20160904 00:28:36< tad_> celmin: Testing a lingering bug in TSG: error ai/engine/cpp: side 2 : UNKNOWN aspect[villages_per_scout*ai_default_rca::aspect_attacks]
20160904 00:28:51< celmin> Guessing it only triggers if a class has it on some members in a class but not others.
20160904 00:28:59< celmin> tad_: I tried to reproduce that awhile ago and faild.
20160904 00:29:01< celmin> ^+e
20160904 00:29:18< tad_> celmin: Removed the following from [ai]: {ATTACK_DEPTH 2 3 4}
20160904 00:29:24< celmin> I think I still have the breakpoints set at the places where it would trigger.
20160904 00:29:42< tad_> celmin: Not, after side2 recruit I get: Caught general exception: bad_lexical_cast
20160904 00:29:49< tad_> ^Now
20160904 00:29:59< celmin> After removing attack_depth?
20160904 00:30:04< tad_> Yep
20160904 00:30:11< celmin> That's… kinda weird...
20160904 00:30:39< tad_> I do wish y'all would not catch exceptions like that unless you're gonna re-throw. Usually makes it hard to debug 'em.
20160904 00:31:09< celmin> Well, if it's the exit catch, then you could always just comment it out for testing.
20160904 00:31:41< celmin> If it's a different catch, it's usually because the game is able to recover.
20160904 00:31:43< tad_> Yes. I still get the ai error .. then all the undead appear and it's time for side 1 to move (I guess) and the bad_lexical_cast appears
20160904 00:32:03< celmin> The weird thing is that attack_depth actually does nothing.
20160904 00:32:30< celmin> Wait, it's {ATTACK_DEPTH 2 3 4}, not {QUANTITY attack_depth 2 3 4}… are they equivalent, I wonder...?
20160904 00:32:45< tad_> The ai error does not occur on side 2 initially. Only after a modify_side to change the [ai] .. substantive change is recruitment pattern. Before and after both have the same other params,
20160904 00:33:02< tad_> celmin: I checked, yes, one becomes the other
20160904 00:33:53< tad_> celmin: and just to confuse things there's a third macro which does the exact same. So choose: unit macro, ai macro, or general macro :P
20160904 00:34:01< celmin> Unit macro?
20160904 00:34:16-!- Bonobo [~Bonobo@2001:44b8:254:3200:e8b4:537f:ddc4:425a] has joined #wesnoth-dev
20160904 00:34:28< tad_> ATTACK_DEPTH is in ... sorry .. utils.cfg
20160904 00:35:26< vultraz> tad_: see my comment on your user_team_name PR. I think my proposal would fix your issue and improve the status dialog at the same time.
20160904 00:35:32< tad_> Anyway. Two bugs. Removing deprecated (attack_depth) triggers bad_lexical_cast.  And modify_side [ai] causes that ai error.
20160904 00:35:55< tad_> vultraz: ok.  looking ...
20160904 00:36:09< celmin> attack_depth was not removed because there does seem to be a concept of attack depth in the AI code, but it's hard-coded to a specific value rather than using the aspect, so I thought maybe the aspect would become used at some point.
20160904 00:36:25< celmin> Not sure though.
20160904 00:37:42< tad_> wiki says it's no longer used, just not removed. To me that means deprecated but can appear .. jsut does nothing.
20160904 00:37:55< celmin> I guess it's deprecated.
20160904 00:38:14< tad_> The common elements of the two [ai] blocks are a village_value=3 setting
20160904 00:39:24< tad_> vultraz: gt's comment on the PR makes me think I should add his test. Your comment sounds plausible but I think should be a separate subject PR because I expect there's a bit more to it.
20160904 00:40:07< vultraz> well my proposed team_display_name key would behavior as the current 'buggy' u_t_n does 
20160904 00:40:23< celmin> The aspect warning triggers either at src/ai/default/engine_cpp.cpp:51 or at src/ai/lua/engine_lua.cpp:346.
20160904 00:40:25< vultraz> ie, only the key in the side with the first instance of a team_id would be used
20160904 00:40:28< celmin> (More likely the former.)
20160904 00:40:52< celmin> (In fact I think it's actually impossible for it to be the latter in this specific case.)
20160904 00:41:13< tad_> celmin: Yes, found the line. Don't see why it's ok in [side][ai] and triggers on a recruit in [modify_side][ai]
20160904 00:41:17-!- travis-ci [~travis-ci@ec2-54-144-74-161.compute-1.amazonaws.com] has joined #wesnoth-dev
20160904 00:41:18< travis-ci> wesnoth/wesnoth#10702 (master - 6c63762 : Charles Dang): The build was broken.
20160904 00:41:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157381642
20160904 00:41:18-!- travis-ci [~travis-ci@ec2-54-144-74-161.compute-1.amazonaws.com] has left #wesnoth-dev []
20160904 00:41:48< celmin> I set breakpoints there, opened TSG, skipped to scenario 2, gave the leader super move points, and moved him to the citadel.
20160904 00:41:55< celmin> But it didn't trigger the warning.
20160904 00:42:09< celmin> …maybe because the enemy AI hadn't been initialized yet, come to think of it.
20160904 00:42:21< celmin> I could try skipping a turn, then moving the leader.
20160904 00:42:28< tad_> celmin: after Min Hylas appears .. kill the henchmen (or not, I do) then end-turn to get an undead.
20160904 00:42:48< celmin> Huh? Wasn't it triggered just by moving to a specific location?
20160904 00:42:57< celmin> The aspect warning.
20160904 00:43:00< vultraz> blah i forgot to update the tests..
20160904 00:43:40< vultraz> hm
20160904 00:43:45< vultraz> but how should i update the tests
20160904 00:44:36< celmin> Add an instance of the struct as a member of the twrapper.
20160904 00:44:38< tad_> The moveto triggers hylas appearing and does a modify_side to change from human to undead recruits and then the error appears
20160904 00:44:46< celmin> And fill its values in the constructor.
20160904 00:45:06< vultraz> it takes arguments though
20160904 00:45:16< vultraz> guess i need an argument-less constructor
20160904 00:45:21< celmin> No?
20160904 00:45:33< celmin> You can do twrapper() : vals(…) {}
20160904 00:45:47< vultraz> wha?
20160904 00:45:57-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 250 seconds]
20160904 00:46:37< celmin> What's your confusion?
20160904 00:47:10< vultraz> what you just said
20160904 00:47:25< vultraz> the constructor takes a team object, and a side
20160904 00:47:36< celmin> There is a twrapper specialization somewhere in test_gui2.cpp, right?
20160904 00:47:41 * tad_ is going afk for a while.
20160904 00:47:46< vultraz> i guess it's ok to add a team object in the tests
20160904 00:47:59< celmin> Yeah, a team object is fairly lightweight.
20160904 00:48:10< celmin> (Doesn't the edit side dialog already have one?)
20160904 00:49:23< celmin> vultraz: So basically you just need to have a team object and an editor_team_info object defined in twrapper<tedit_side_info>
20160904 00:49:32< celmin> They must be defined in that order.
20160904 00:50:04< celmin> Then you just need to initialize them in the twrapper constructor.
20160904 00:51:04< vultraz> this, you mean? http://pastebin.com/5Df0mBLR
20160904 00:51:30< celmin> I think you can only use = initialization in that context.
20160904 00:51:41< celmin> I mean twrapper() : info(t, 1) {}
20160904 00:52:04< celmin> Though you might actually want twrapper() : t(some stuff), info(t, 1) {}
20160904 00:52:14< vultraz> . . .
20160904 00:52:28< vultraz> I see
20160904 00:52:36< celmin> And if "some stuff" needs to be a config, it could become twrapper() : cfg(config_of()()()), t(cfg), info(t, 1) {}
20160904 00:52:43< celmin> Of course it doesn't all need to be on one line.
20160904 00:53:09< celmin> (Though I guess you could just use config_of in t() if you wanted to...)
20160904 00:53:24< celmin> Does that make sense?
20160904 00:53:30< celmin> Your ellipsis makes me doubt.
20160904 00:53:45-!- exciton [~exciton@89.208.170.132] has joined #wesnoth-dev
20160904 00:57:45< vultraz> off topic a second
20160904 00:58:07< vultraz> but why can you sometimes do = initialization and sometimes you need ()
20160904 00:58:14< vultraz> it confuses me
20160904 00:58:17< celmin> Oh my.
20160904 00:58:37< celmin> I guess if I had to put it simply, it would be...
20160904 00:58:45< celmin> = is the original C way.
20160904 00:59:03< celmin> In C++, the () form was added, but it didn't support everything.
20160904 00:59:14< celmin> So you still needed = for arrays and structs.
20160904 00:59:34< celmin> The C++ standard noticed this and decided it was bad, so they introduced the generic {} form.
20160904 00:59:41< celmin> Which theoretically works for everything.
20160904 00:59:47< celmin> (That's {} without a preceding =)
20160904 00:59:56< vultraz>  one can do this: std::string a = "foo". or int a = 1. and I've also seen code that is vector a(foo()), but I've also seen vector a = foo() (where foo() returns a vector). and there's also vector a = {}... but then you can also do struct a {}
20160904 00:59:59-!- trewe [~trewe@2001:8a0:d12f:d901:22a:827a:b1e8:18d0] has quit [Quit: quit]
20160904 01:00:27< celmin> I think using = also is slightly different semantically from ()
20160904 01:01:13< vultraz> why do you not need to do string a("foo"), for example
20160904 01:01:46< celmin> string a = "foo" constructs a temporary string from "foo" and copy-constructs a from that, if I recall correctly.
20160904 01:02:10< celmin> While string a("foo") or string a{"foo"} would construct a directly from "foo".
20160904 01:02:21< celmin> (Not sure if string{"foo"} actually works, mind you.)
20160904 01:02:44< celmin> "struct a {}" is defining a struct, so that's completely different.
20160904 01:03:01< vultraz> er, right
20160904 01:03:15< vultraz> but I mean if a is a struct, one can initialize it with a {}
20160904 01:03:56< celmin> You can initialize anything with {} in C++11.
20160904 01:04:01< celmin> You can do int a{5}.
20160904 01:04:21< vultraz> so are you saying string a = "foo" is the same as string a = string("foo")
20160904 01:04:22< celmin> Or int b[6]{1,2,3,4,5,6}
20160904 01:04:47< celmin> I think the = form is slightly different, as mentioned above, but… it does have the same end result.
20160904 01:05:30< vultraz> i thought {} was an initializer list.. or does it have different forms based on type :|
20160904 01:05:55< celmin> {} is a "braced-init-llist
20160904 01:05:57< celmin>  "
20160904 01:06:06< celmin> If I recall the C++11 standard correctly.
20160904 01:06:17< celmin> It's the new unified C++11 construction syntax.
20160904 01:06:32< celmin> Unified because it works both on aggregates and non-aggregates.
20160904 01:06:43< celmin> (Where aggregates basically covers arrays and simple structs.)
20160904 01:12:18< vultraz> but our config class cannot use it, so I assume it's implemented on a per-type basis?
20160904 01:12:43< celmin> The config class can use a braced-init-list.
20160904 01:12:55< celmin> However it cannot support an initializer-list constructor.
20160904 01:13:10< vultraz> I... what??
20160904 01:13:20< celmin> I think the reason is that the value-type of the initializer-list would be too hard to deduce, or something.
20160904 01:13:35< celmin> Using a braced-init-list you can call any existing constructor.
20160904 01:13:59< celmin> However, if the class specifically defines a constructor taking an initializer_list, that either overrides that or takes priority (I don't remember exactly).
20160904 01:17:49< vultraz> that doesn't confuse me any less
20160904 01:19:56< tad_> = {} initializes constants into a basic type like array or class.  The function-form is for things which have a constructor like classes.
20160904 01:20:55-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160904 01:20:57< celmin> Though primitives also accept it.
20160904 01:22:14< tad_> You can do either 'int a = 4
20160904 01:22:20< tad_> or int a(4)
20160904 01:22:37< celmin> And C++11 adds int a{4}
20160904 01:23:08< vultraz> I still don't understand why config foo { "key" { "val"} }; isn't valid... 
20160904 01:23:25< celmin> Obviously that wouldn't be valid.
20160904 01:23:31< celmin> With an added comma, maybe.
20160904 01:23:39< celmin> Or wait, not even then.
20160904 01:23:51< celmin> I think you messed up your basic config structure there.
20160904 01:24:01< tad_> Or you get a job with IBM or Google, go the the C++ committee and get it added because you like .. same as a lot of the junk coming into the standard.
20160904 01:24:32< celmin> In theory I think it should be possible to enable config foo{ {"key", val}, {"child_tag", { {"key", val} } } };
20160904 01:24:42< vultraz> or would be it { "key," "value" }?
20160904 01:24:43< celmin> But my attempt at doing so hit a dead end.
20160904 01:24:56< celmin> Yeah, that.
20160904 01:25:05< vultraz> then again, that looks rather ugly
20160904 01:25:25< celmin> I can't even start a campaign now… :|
20160904 01:26:07< shadowm> "foo" "bar" in C and C++ is a single string literal "foobar".
20160904 01:26:20< shadowm> So "key," "value" is just "key,value".
20160904 01:26:39 * celmin assumed he meant to have the comma outside the quotes.
20160904 01:29:02< vultraz> er, yes
20160904 01:29:10< celmin> It consistently crashes while building terrain rules.
20160904 01:29:13< celmin> Is this just me?
20160904 01:29:20< vultraz> yes
20160904 01:29:25< celmin> Blargh.
20160904 01:34:07< vultraz> i should work on the statistics dialog next
20160904 01:34:14< vultraz> give it a nice redesign
20160904 01:38:16< tad_> OK. That's strange. TSG S02. If I let the enemy recruit before moving Deoran to the citadel, neither the [ai] nor the crash occur .. undead appear and no problems at all
20160904 01:38:45< shadowm> celmin: Has the tstring error been fixed yet?
20160904 01:39:09< tad_> BUT if I take the keep with a long move on turn 1 both appear if I don't have the attackdepth macro and the crash does not occur if I do have it
20160904 01:39:57< celmin> shadowm: I did fix it but haven't pushed. I'll probably have to revert what I was working on, so I can commit and push after that.
20160904 01:39:57< tad_> So I'm thinking uninitialized data maybe? Maybe related to that modify_side?
20160904 01:40:48< celmin> I don't suppose scons duplicates warnings to a nice convenient file?
20160904 01:41:15< shadowm> celmin: Are you asking me?
20160904 01:41:23< celmin> Anyone who might know.
20160904 01:41:48< shadowm> You mean warnings during configuration checks or warnings during the main build?
20160904 01:41:53< celmin> Main build.
20160904 01:41:58< tad_> Know? No. Be amazed if it did? /me waves his hand.
20160904 01:42:01< shadowm> Most likely not.
20160904 01:42:26< shadowm> Under the Unix philosophy yadda yadda yadda you'd be expected to use tee for that.
20160904 01:42:58< celmin> Which is only useful if you thought of it beforehand.
20160904 01:43:09< tad_> yep. and you're supposed to know the answer before you ask the question .. dran, too slow
20160904 01:43:16< shadowm> Warnings are thankfully reproducible.
20160904 01:43:32< celmin> That's only half true.
20160904 01:43:44< shadowm> It's 100% true.
20160904 01:43:52< celmin> Unless I'm mistaken, I would not get the warnings on a second build.
20160904 01:44:02< celmin> Because the files that generate them would be "clean" and not be rebuilt.
20160904 01:44:08< tad_> You need to treat them as errors or make all
20160904 01:44:12< shadowm> You can delete the files.
20160904 01:44:21< celmin> Well yes, you can do a lot of things to get around that.
20160904 01:44:23< tad_> Or touch *.hpp
20160904 01:44:55< shadowm> tad_: If someone did that without ccache they'd be in for a very long ride.
20160904 01:44:56< tad_> Question is do you want to wait 4 hours for make all.  Touch the cpp you want to check.
20160904 01:45:01< celmin> My terminal seems to be broken.
20160904 01:45:06< celmin> I guess I'll recreate it.
20160904 01:45:30< shadowm> Recreating a terminal sounds like hard work.
20160904 01:45:43< celmin> Nah, I just press Cmd+T or Cmd+N.
20160904 01:45:50< celmin> It even keeps me in the same working directory.
20160904 01:46:18< tad_> "New tab"?
20160904 01:46:34< celmin> Does "strict compilation" mean -Werroe?
20160904 01:46:38< shadowm> Yes.
20160904 01:46:40< celmin> ^-Werror
20160904 01:46:53< celmin> I guess I'll enable that for now then… at least that'll reproduce the warnings.
20160904 01:47:19< tad_> And if you use it wesnoth won't like because we have warnings from boost we can't fix
20160904 01:47:30< shadowm> Building Wesnoth with that on feels a lot like playing the lottery these days. It wasn't like that when I wasn't in charge. :V
20160904 01:47:47< shadowm> tad_: CMake and SCons both use -isystem.
20160904 01:47:48< celmin> I don't really care about that, since I intend to disable it once the warnings are addressed.
20160904 01:48:15< shadowm> Here's a complete version of my build time woes right now: http://pastebin.com/MEdJdnfC
20160904 01:48:25< shadowm> *when I was
20160904 01:48:49< celmin> I think vultraz was working on fixing the tests.
20160904 01:48:57< vultraz> celmin: can you fix the tests
20160904 01:49:01< shadowm> lol
20160904 01:49:05< celmin> :|
20160904 01:49:08< celmin> I guess maybe.
20160904 01:49:46< celmin> Okay, so I'm going to need to say "apply the stash below the top one"...
20160904 01:50:00< shadowm> git stash apply stash@{1}
20160904 01:50:08< tad_> shadowm: the strict alias issue is from celmin and ignore it until he gets around to fix it.  not seen the other
20160904 01:50:19 * tad_ nods
20160904 01:50:26< celmin> Seems like shadowm is using strict compilation, because it was an error when he reported it.
20160904 01:50:41< tad_> he is -Werror
20160904 01:50:48< shadowm> > Saved options: [...] strict = True
20160904 01:51:03< shadowm> Can't ignore warnings. We've never ignored warnings. ;)
20160904 01:51:51< shadowm> I could disable strict and get a fresh build done in 4 minutes but I'd rather pester people until the warning goes away like in old times.
20160904 01:51:52< tad_> There are a lot of warnings about deprecated headers we can't fix because they're from Boost. But I jump in here and tap my toe impatiently if I see any others ...
20160904 01:52:11 * tad_ is with shadowm on that ...
20160904 01:53:53< tad_> So, on TSG S02 I have a choice. Waste a day or so tracking down those two errors (on is a full bail-to-console crash). Or decide nobody but me will ever see them and try to forget about them ...
20160904 01:54:40< tad_> I'll be honest, even if mere-mortal players will never see the errors, they bother me.
20160904 01:54:53< celmin> The crash only occurred without attack depth, right?
20160904 01:55:15 * celmin is maybe trying to do too many things at once.
20160904 01:55:32< tad_> Yes, removing that macro seems to cause a crash-to-console with bad_lexical_cast
20160904 01:55:55< tad_> But .. ONLY if side 2 did not recruit before we did a [modify_side][ai]
20160904 01:57:22< tad_> Smells like uninitialzed data. And that's often a bad sign. Like, here, it's never going to be seen .. but we're just waiting for the GNA issue to arrive from elsewhere
20160904 01:58:44< celmin> How does side 2 not recruit first? By moving there on turn 1?
20160904 01:59:33< tad_> Yes
20160904 02:00:20< tad_> Then end-turn after Deoran is there (hylas appearing is the clue).
20160904 02:00:25< celmin> I suppose that likely makes it a "trying to modify AI before AI is initialized" thing.
20160904 02:00:44< tad_> Probably. But why would it care?
20160904 02:00:53< tad_> IT's jsut keys in a table.
20160904 02:01:00< celmin> AI usually is initialized at the start of the side's first turn, but I think it's initialized earlier if you view it in the inspector.
20160904 02:01:03< celmin> I dunno why it would care.
20160904 02:01:49< celmin> If it's a bug in [modify_side] it might be worth checking if it's fixed in the wml_tag_porting branch (merging it in, rather than switching to it, since it's a little out-of-date).
20160904 02:02:08< celmin> Only because that branch makes some changes to how [modify_side] works.
20160904 02:02:16< celmin> Nothing specific that I would point to as fixing it.
20160904 02:04:45< tad_> src/ai/.. stuff has some throws and catches for bad_lexical_cast. Maybe it's a missed recovery?
20160904 02:10:43< celmin> Building with scons again now.
20160904 02:11:03< celmin> But not sure what to do about the issue of the missing address sanitizer libs.
20160904 02:20:28< celmin> Ugh, how am I supposed to debug this TSG issue when I can't even get into TSG. :(
20160904 02:24:34< tad_> Grr. I can set a break at the catch but no backtrace because it's an exception.
20160904 02:24:56< celmin> I can set breakpoints at the throw point.
20160904 02:25:13< celmin> Symbolically it ends up pointing to something like __cxa_throw (but that's probably system-dependent).
20160904 02:25:27< celmin> (Or compiler-dependent at the very least.)
20160904 02:26:10-!- fabi [~fabi@176.0.22.31] has joined #wesnoth-dev
20160904 02:26:30< tad_> I thought std exception had a back reference ..
20160904 02:26:44< celmin> No, all it has is a message.
20160904 02:27:00< celmin> Which is usually useless because the standard library implementors can't be bothered to do something useful.
20160904 02:27:26< celmin> So it ends up just being the class name.
20160904 02:30:23< celmin> Huh, I didn't know about std::exception_ptr...
20160904 02:30:32< celmin> Only useful for rethrowing though.
20160904 02:30:46< celmin> Has no way to access the original exception.
20160904 02:31:32< tad_> gdt can catch it when thrown just gotta work out how ... been AGES
20160904 02:31:41< tad_> ^gdb
20160904 02:35:16< celmin> I wish MacPorts explained what all the port variants actually mean.
20160904 02:35:29< celmin> It's rarely obvious.
20160904 02:44:20< celmin> Ugh, even if I reset to HEAD it crashes.
20160904 02:44:33< celmin> Which suggests the crash isn't actually my fault.
20160904 02:46:37< tad_> Not if you've made commits to that HEAD
20160904 02:57:17< celmin> I mean backing out the commits I made.
20160904 02:57:41< celmin> I checked out the VC project commit, to be precise.
20160904 02:58:11< tad_> #2  0x0000000001a5be40 in ai::config_value_translator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::value_to_cfg (value="", cfg=...)     at /home/lundberg/wesnoth/src/ai/composite/value_translator.hpp:50
20160904 02:59:53< celmin> That gives a bad lexical cast?
20160904 03:00:04< celmin> value="" is the value of that parameter?
20160904 03:00:20< celmin> That shouldn't give a bad lexical cast...
20160904 03:00:38< tad_> That's the line ..
20160904 03:00:47< irker066> wesnoth: mattsc wesnoth:ai_high_xp_attack f76e2d0c595a / data/ai/ (lua/ca_high_xp_attack.lua scenarios/scenario-high_xp_attack.cfg): High XP attack CA: remove a debug message https://github.com/wesnoth/wesnoth/commit/f76e2d0c595a7d217f7a6940ea78df78baac80f0
20160904 03:00:49< irker066> wesnoth: mattsc wesnoth:ai_high_xp_attack 8e50c4ee066a / data/campaigns/Son_Of_The_Black_Eye/ (3 files in 2 dirs): SotBE: remove macros to force attacks on high-XP enemies https://github.com/wesnoth/wesnoth/commit/8e50c4ee066aee2ea9925d4964baa691c14f698c
20160904 03:00:51< irker066> wesnoth: mattsc wesnoth:ai_high_xp_attack d781e6263a49 / data/ (11 files in 6 dirs): High XP attacks: adapt other AIs to existence of new CA https://github.com/wesnoth/wesnoth/commit/d781e6263a49dc6daea8c49aec328f0cf15b46ca
20160904 03:02:10< mattsc> celmin: with that ^ I think I have done everything needed to merge in the new candidate action
20160904 03:02:23< tad_> #3  0x0000000001a86355 in ai::standard_aspect<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::to_config (this=0xc155d10)     at /home/lundberg/wesnoth/src/ai/composite/aspect.hpp:395
20160904 03:03:44< tad_> #4  0x0000000001a84ea0 in ai::composite_aspect<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::to_config (this=0xd3fbe10)     at /home/lundberg/wesnoth/src/ai/composite/aspect.hpp:331 #5  0x0000000001946caf in ai::readonly_context_impl::to_readonly_context_config (this=0xd3fb380) at /home/lundberg/wesnoth/src/ai/contexts.cpp:301
20160904 03:12:43< tad_> The crash is when trying to write the turn save file, attempting to add the [ai] by reading the config from the side's memory tables.
20160904 03:14:06< celmin> I wonder which aspect it is.
20160904 03:15:38< celmin> In stack frame #5, the value of a.first
20160904 03:15:44< celmin> Wait no, $3
20160904 03:15:45< celmin> #4
20160904 03:16:03< celmin> to_readonly_context_config
20160904 03:16:24< tad_> 		cfg.add_child("aspect",a.second->to_config());
20160904 03:16:59< celmin> I think it'd also be available from frame #2, maybe as this->id or so.
20160904 03:17:48 * celmin means, if you have the debugger open, something like "print a.first" or "print this->id".
20160904 03:18:44< tad_> no but give me a bit to get back to the point of failure
20160904 03:23:01< tad_> working to it. the cast is an empty string ""
20160904 03:24:49< celmin> That's one of the things that's confusing me.
20160904 03:24:56< vultraz> hm, I'll work on the status labels thing
20160904 03:25:08< vultraz> just need to decide on a good method
20160904 03:25:55 * vultraz ponders
20160904 03:26:51< vultraz> honestly, I don't know why register_label even exists in its current form...
20160904 03:27:10< tad_> celmin: does this help?   name_ = "composite_aspect", id_ = "grouping"}
20160904 03:27:12< vultraz> it's basically a wrapper for find_widget ... stuff .. set_label()
20160904 03:27:47< celmin> Blargh.
20160904 03:28:30< celmin> Well, given that it's a map, that does imply it's not just crashing on the first aspect...
20160904 03:28:40< vultraz> ok, so we need a new form of register_label
20160904 03:28:41< celmin> Not sure if that's worth anything.
20160904 03:28:46< vultraz> one that takes a widget 
20160904 03:29:11< vultraz> so instead of a text argument
20160904 03:29:13< vultraz> it takes a widget
20160904 03:29:23< vultraz> and gets the value of that widget, and prints it
20160904 03:29:39< celmin> Sounds like you're missing something.
20160904 03:29:49< vultraz> yes
20160904 03:29:54< vultraz> how to notify the field to update :|
20160904 03:30:05< celmin> ...
20160904 03:30:39< vultraz> what?
20160904 03:30:56< vultraz> optimally the field would update with no manual intervention 
20160904 03:31:16< vultraz> ie, any time the widget fires a MODIFIED event it would update
20160904 03:31:31< vultraz> wait...
20160904 03:31:50< vultraz> hmm
20160904 03:31:53< vultraz> ok, if I have a widget
20160904 03:31:57< vultraz> I can use connect_signal_notify_modified
20160904 03:36:34< vultraz> I think i got it
20160904 03:36:38< vultraz> well, theoretically
20160904 03:37:26< celmin> Still sounds like you're missing something.
20160904 03:37:42< vultraz> that being?
20160904 03:44:16< tad_> If I'm reading this correctly, it's trying to write the turn save. [ai] [aspect] [default] and an empty string is causing the bad cast exception. Not sure what else to look for.
20160904 03:51:29-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160904 03:54:22< irker066> wesnoth: Charles Dang wesnoth:master 4f95916bbf71 / data/campaigns/Heir_To_The_Throne/ (9 files in 2 dirs): Updated Battle Princess attack animations by doofus-01 https://github.com/wesnoth/wesnoth/commit/4f95916bbf71145249826d4b07c41b678b3d8825
20160904 03:54:44< celmin> Perhaps you should avoid committing animations before they are done?
20160904 03:55:10< vultraz> They are done.
20160904 03:55:16-!- travis-ci [~travis-ci@ec2-54-226-242-233.compute-1.amazonaws.com] has joined #wesnoth-dev
20160904 03:55:17< travis-ci> wesnoth/wesnoth#10703 (ai_high_xp_attack - d781e62 : mattsc): The build has errored.
20160904 03:55:17< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157394320
20160904 03:55:17-!- travis-ci [~travis-ci@ec2-54-226-242-233.compute-1.amazonaws.com] has left #wesnoth-dev []
20160904 03:55:29< celmin> Didn't you already commit them though>
20160904 03:55:30< celmin> ^?
20160904 03:55:54< vultraz> those were defense 
20160904 03:55:58< vultraz> these are attacks
20160904 03:56:27< celmin> Ah, okay.
20160904 03:58:08< vultraz> oh, bah 
20160904 03:58:18< vultraz> included whitespace addition :|
20160904 03:58:32< vultraz> will fix next time i edit the fle
20160904 04:00:52< vultraz> oh, hm
20160904 04:00:58< vultraz> might've pushed the old version
20160904 04:01:04< vultraz> just noticed that he had edited his post
20160904 04:01:10< celmin> :|
20160904 04:02:02< vultraz> oh, it's just another frame + leading
20160904 04:02:04< vultraz> ok
20160904 04:03:22< celmin> She has leadership?
20160904 04:03:43-!- JyrkiVesterinen [~JyrkiVest@87-100-134-69.bb.dnainternet.fi] has joined #wesnoth-dev
20160904 04:07:56< irker066> wesnoth: Charles Dang wesnoth:master 285372a2d1a2 / data/campaigns/Heir_To_The_Throne/ (5 files in 2 dirs): Further Battle Princess animation updates by doofus-01 https://github.com/wesnoth/wesnoth/commit/285372a2d1a211113aadec07fdfd194130f45e46
20160904 04:09:57< celmin> Ugh, mixing whitespace with semantics...
20160904 04:10:54< vultraz> I ran my editor's Strip Trailing Space command
20160904 04:11:45< celmin> That should have really been a separate commit though.
20160904 04:15:51< vultraz> i thought you hated my micro-committing :|
20160904 04:16:26< celmin> True.
20160904 04:16:40< celmin> If you want to fix whitespace, it would be preferable to fix it in every file and commit that.
20160904 04:17:16< celmin> But IMO it's better to commit a small whitespace-only change than mix lots of whitespace into a meaningful change.
20160904 04:19:41< pydsigner> Agreed
20160904 04:20:02< vultraz> does an inherited class constructor have to be called in the initializer list or can it be done in the constructor body?
20160904 04:21:58< shadowm> The former.
20160904 04:22:10< shadowm> It also has to go before all other member variables.
20160904 04:22:35< celmin> Well, it doesn't have to go before member variables, but it's good practice (and avoids warnings).
20160904 04:22:50< shadowm> <celmin> warnings
20160904 04:22:59< shadowm> Which means it has to go before all other member variables.
20160904 04:23:24< celmin> pydsigner seems to pop in when you least expect it.
20160904 04:23:49< vultraz> ok, that means I need to construct these calls in tdialog and pass them in
20160904 04:23:52< vultraz> got it
20160904 04:24:01< celmin> No idea what you're talking about.
20160904 04:24:10< shadowm> The thing that most people don't realize is that warnings aren't there just to be a pain in the butt for experienced coders.
20160904 04:24:15< vultraz> no need to
20160904 04:24:25< pydsigner> celmin: No one expects the pydsigner imposition!
20160904 04:24:29< shadowm> They are there to prevent newbies like vultraz from shooting themselves in the foot by making dangerous assumptions and generalizations.
20160904 04:24:29< celmin> Some of them are, some of them aren't.
20160904 04:24:42< shadowm> Okay, _the warnings we use_.
20160904 04:24:48< celmin> Fair enough, I guess.
20160904 04:25:18< shadowm> They are also there to account for platform variance in some cases (esp. around type sizes and such).
20160904 04:25:55< shadowm> Or to avoid non-deterministic behavior (e.g. use of uninitialized memory).
20160904 04:26:57< JyrkiVesterinen> I'll add: even if you don't care about the particular warning (such as initializing member variables in a wrong order, -Wreorder, that we're talking about here), you still want to fix the warnings so that you can notice when a new warning appears.
20160904 04:27:24< JyrkiVesterinen> It's a bad situation if a project has a large number of warnings, even if all of them are about harmless things.
20160904 04:27:35< celmin> Yeah.
20160904 04:27:50< JyrkiVesterinen> If all else fails, you want to silence warnings with #pragmas instead of leaving them there.
20160904 04:27:58< celmin> Yeah, I was about to say that too. XD
20160904 04:28:30< shadowm> Having member variables in the wrong order can actually have negative effects if their types have unusual requirements and side-effects.
20160904 04:28:45< celmin> That's not quite true.
20160904 04:28:53< shadowm> IIRC the compiler is required to follow the declaration order, but the human may fail to notice this.
20160904 04:28:58< celmin> Yes, exactly.
20160904 04:29:02< shadowm> celmin: Oh yes, it's quite true.
20160904 04:29:05< celmin> So having them in the wrong order is just misleading.
20160904 04:29:27< celmin> It does not (by itself) have negative effects.
20160904 04:29:39< shadowm> Nobody is stopping some fool from declaring three member variables, each of which is from a type that shares some global state with each other and expects them to be all present at a specific time.
20160904 04:29:54< shadowm> That'd be bad design, yes, but so is half of Wesnoth's code.
20160904 04:30:38< shadowm> It's about managing side-effects that the compiler might not know about because the implementation is part of a different translation unit.
20160904 04:39:49< vultraz> bah...
20160904 04:39:55< vultraz> tcontrol doesn't have get_value...?
20160904 04:40:22< vultraz> it has .label() but I dunno if that's what we want..
20160904 04:40:24< vultraz> likely not
20160904 04:40:55-!- travis-ci [~travis-ci@ec2-54-226-242-233.compute-1.amazonaws.com] has joined #wesnoth-dev
20160904 04:40:56< travis-ci> wesnoth/wesnoth#10705 (master - 4f95916 : Charles Dang): The build is still failing.
20160904 04:40:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157397760
20160904 04:40:56-!- travis-ci [~travis-ci@ec2-54-226-242-233.compute-1.amazonaws.com] has left #wesnoth-dev []
20160904 04:42:07< vultraz> templates
20160904 04:45:21< vultraz> hmmmmm
20160904 04:45:23< vultraz> ponder ponder
20160904 04:45:40< vultraz> restore is private...
20160904 04:45:49< vultraz> if I made it protected..
20160904 04:46:04< celmin> Isn't get_value() in tselectable_?
20160904 04:46:10< celmin> What is restore?
20160904 04:46:18< vultraz> sus
20160904 04:46:19< vultraz> h
20160904 04:47:06< shadowm> That's a line.
20160904 04:47:54< vultraz> hmmm
20160904 04:48:39< vultraz> AH
20160904 04:48:46< vultraz> tfield inherits from tfield_
20160904 04:49:12< vultraz> widget_restore, pure virtual...
20160904 04:49:18< vultraz> wait, that's in tfield_...
20160904 04:54:57< vultraz> hmmmmm
20160904 04:58:57-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160904 05:05:13-!- travis-ci [~travis-ci@ec2-54-144-74-161.compute-1.amazonaws.com] has joined #wesnoth-dev
20160904 05:05:14< travis-ci> wesnoth/wesnoth#10706 (master - 285372a : Charles Dang): The build is still failing.
20160904 05:05:14< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157398758
20160904 05:05:14-!- travis-ci [~travis-ci@ec2-54-144-74-161.compute-1.amazonaws.com] has left #wesnoth-dev []
20160904 05:05:15-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160904 05:10:49< vultraz> I think I got it
20160904 05:11:08< vultraz> theoretically, of course :P
20160904 05:11:49< celticminstrel> Looks like the tests actually just use a hard-coded set of resolutions, rather than testing all resolutions that the dialog or its widgets define.
20160904 05:17:56< celticminstrel> Hmm, it's pretty late, maybe I should let stuff build overnight... >_>
20160904 05:20:14< celticminstrel> Though I could push the strict aliasing fix right now...
20160904 05:21:03 * celticminstrel is rebuilding clang 3.8 with different options in the hope that it might gain address sanitizer support, though doesn't have high hopes... if this doesn't work I might just try downloading it from the website or something.
20160904 05:21:29< JyrkiVesterinen> Ouch. Rebuilding clang must take really long. :(
20160904 05:21:35< celticminstrel> Yeah.
20160904 05:23:03< celticminstrel> I still have that one annoying (presumably buggy) warning in menu_events.cpp.
20160904 05:23:22< celticminstrel> (Plus all those linker warnings, which are even more annoying.)
20160904 05:23:32< celticminstrel> (Also that has nothing to do with clang 3.8.)
20160904 05:24:07 * celticminstrel only chose 3.8 because I already had it. MacPorts seems to also offer 3.9 though.
20160904 05:25:26< celticminstrel> (And the latest is 4.0 as I understand.)
20160904 05:26:38< celticminstrel> Apparently the tooltip hasn't been getting tested all this time.
20160904 05:26:45< celticminstrel> (Or both of them, I think?)
20160904 05:27:07< celticminstrel> (There was no call to test the non-large one, but I think the test itself was dummied out as well.)
20160904 05:29:19 * celticminstrel is going to try enabling it, and will push if it doesn't crash, but if it crashes in Travis, anyone can feel free to put the #if 0 back.
20160904 05:31:06< vultraz> ..\..\src\gui\auxiliary\field.hpp|290|error: static assertion failed: Second template argument cannot be tcontrol|
20160904 05:31:10< vultraz> well this tells me a lot
20160904 05:31:34< celticminstrel> Yeah, tfield wants to be specialized for a subclass of tcontrol.
20160904 05:31:39< celticminstrel> Not for tcontrol directly.
20160904 05:32:08< celticminstrel> So basically that means you have tfield<X, tcontrol, Y> somewhere for some X and Y.
20160904 05:32:17< celticminstrel> The template trace should show you where.
20160904 05:32:25< vultraz> oh, I see
20160904 05:32:42< vultraz> only the version of tfield that uses callbacks
20160904 05:32:47< vultraz> is subject to that restriction 
20160904 05:42:29< vultraz> oh come *on*
20160904 05:42:39< vultraz> ..\..\src\gui\auxiliary\field.hpp|342|error: static assertion failed: Second template argument must be tcontrol|
20160904 05:42:41< vultraz> :|
20160904 05:42:43< vultraz> #Programming
20160904 05:44:34< celticminstrel> Why do you want the second template argument to be tcontrol?
20160904 05:44:55< celticminstrel> Pretty sure the second template argument is not supposed to be a descendant of twidget.
20160904 05:45:16< vultraz> somehow I've ended up with the constructor that requires it
20160904 05:45:31< celticminstrel> It's supposed to be something like tselectable_ or tinteger_selector.
20160904 05:47:05< vultraz> but why is this happening
20160904 05:47:15< vultraz> I called the full-argument constructor :|
20160904 05:47:59< celticminstrel> Does this really have anything to do with the choice of constructor?
20160904 05:48:09< celticminstrel> It's complaining about the template arguments.
20160904 05:49:50< vultraz> I have a feeling there may be something more complicated than I thought here
20160904 05:49:55< vultraz> perhaps you should look at the code
20160904 05:50:08< celticminstrel> I have a feeling that you're misinterpreting the cause of the error.
20160904 05:50:16< celticminstrel> I probably can't view a pastebin right now.
20160904 05:50:53< JyrkiVesterinen> Well, I could have a look.
20160904 05:51:37< vultraz> my own changes are rather minimal but i may be misunderstanding the implementation of tfield
20160904 05:52:56< vultraz> JyrkiVesterinen: https://github.com/Vultraz/wesnoth/commit/382562fd5a52298b964ff6dbe53997afc2debae0
20160904 05:53:49< vultraz> if I specify the second argument as tcontrol (like the other tfield_label) it says it cannot be tcontrol :/
20160904 05:54:12< vultraz> hmm
20160904 05:54:16< vultraz> maybe i should only specify...
20160904 05:54:20< vultraz> tlabel for the new one..
20160904 05:54:37< vultraz> no, that doesn't work
20160904 05:56:58< JyrkiVesterinen> I suspect you get the error from the contructor invocation in line 630.
20160904 05:57:17< JyrkiVesterinen> The invocation in lines 640-641 looks fine to my eyes.
20160904 05:57:39< vultraz> yes, I agree
20160904 05:58:37< vultraz> so if the former constuctor call needs to be tcontrol
20160904 05:58:44< vultraz> then the class needs to be specified as tcontrol
20160904 05:59:05< vultraz> meaning so does the second constructor call (my new one)
20160904 05:59:29< JyrkiVesterinen> Hmm, tfield has two constructors which take three parameters. The first one rejects tcontrol, the second requires it.
20160904 05:59:38< vultraz> yes, I need the first one
20160904 06:00:35< vultraz> er
20160904 06:00:56< vultraz> I mean Ineed the 4-argument constructor 
20160904 06:01:02< vultraz> which rejects tcontrol 
20160904 06:01:46< JyrkiVesterinen> The compiler is picking the second constructor because you pass linked_variable/value with a const reference.
20160904 06:02:09< JyrkiVesterinen> If you need the 4-argument constructor, call it. Your line 630 calls a 3-argument constructor.
20160904 06:02:46< vultraz> yeah I'm not using that
20160904 06:03:16-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160904 06:03:17-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160904 06:03:23< vultraz> I'm talking about 640/41
20160904 06:03:29< vultraz> that needs 4
20160904 06:03:32< vultraz> it calls 4
20160904 06:04:03< JyrkiVesterinen> Does the code compile if you remove the other constructor?
20160904 06:06:27-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160904 06:06:28< vultraz> no :|
20160904 06:07:15< JyrkiVesterinen> Hmm, that's strange.
20160904 06:07:32< vultraz> since it's not specified to tcontrol, tfield uses template specializations of tfield::save and tfield::restore that call get_value/set_value. tlabel does not have these
20160904 06:10:42-!- Kwandulin [~Miranda@p200300760F424141FC1F016144D2FA3F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160904 06:11:38< JyrkiVesterinen> Hmm. All this means that the tfield class simply doesn't support labels that get their value via a callback at present.
20160904 06:11:54< celticminstrel> I have 14 clang processes. No wonder I can't do much.
20160904 06:11:56< vultraz> That's the conclusion I've reashed, yes
20160904 06:12:04< celticminstrel> (Though only half of them are doing any work.)
20160904 06:12:16< celticminstrel> BTW, there's a specialization of tfield (or a subclass?) for tlabel.
20160904 06:12:19< vultraz> reached*
20160904 06:12:20< JyrkiVesterinen> If you want to implement it, you'll need to extend tfield.
20160904 06:12:30< vultraz> D:
20160904 06:12:36< vultraz> how so?
20160904 06:12:47< celticminstrel> So if you want to add callback support, that might be where to look.
20160904 06:13:33< vultraz> celticminstrel: eh??
20160904 06:13:39< JyrkiVesterinen> Well, I don't know what exactly would need to be changed.
20160904 06:13:51< celticminstrel> Ah, that's where you are looking already, I guess.
20160904 06:14:13 * vultraz groans
20160904 06:14:20< celticminstrel> I'm not sure why the second template argument cannot be tcontrol.
20160904 06:14:38< vultraz> nothing is ever simple
20160904 06:14:40< celticminstrel> That's a limitation manually installed by the programmer (ie mordante).
20160904 06:14:54< celticminstrel> You could of course just remove the static_assert, but I don't know if that would have negative side-effects.
20160904 06:14:59< vultraz> let's see what happens if we remove that
20160904 06:18:46< celticminstrel> BTW vultraz, you seem to have a lot of spare branches in your repo. Might want to clean that up a bit.
20160904 06:18:58< vultraz> yeah i should
20160904 06:19:18< celticminstrel> (At least you don't have a duplicate of every main repo branch though.)
20160904 06:22:42< vultraz> well, seems this happens
20160904 06:22:44< vultraz> .objs-release\src\gui\dialogs\addon\description.o:description.cpp|| undefined reference to `gui2::tfield_label* gui2::tdialog::register_label<version_info const>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, version_info const&, bool)'|
20160904 06:23:41< vultraz> im not even sure why o_O
20160904 06:24:29< JyrkiVesterinen> Template code is often complex.
20160904 06:24:52< vultraz> maybe it's because one of my register_label constructors is templated
20160904 06:25:14< vultraz> what if i template the other with an empty template ?
20160904 06:25:25< vultraz> specialize 
20160904 06:25:55< JyrkiVesterinen> Oh, wait. You implemented the template in the .cpp file.
20160904 06:26:22< JyrkiVesterinen> That doesn't work if you want to expose it publicly. You need to have the implementation in the header (.hpp).
20160904 06:26:37< JyrkiVesterinen> Otherwise you're going to get linker errors like above.
20160904 06:26:41< vultraz> oh, I remember something about this...
20160904 06:27:07< vultraz> celticminstrel mentioned something about templated functions must be fully defined in the declaration or something
20160904 06:29:35< vultraz> wait that's not right
20160904 06:29:42< vultraz> public functions?
20160904 06:30:26< JyrkiVesterinen> Right... to be more exact, I mean "when you want to access the template from a different translation unit".
20160904 06:30:44< JyrkiVesterinen> Most often it means that it's public.
20160904 06:31:15< JyrkiVesterinen> But it's fine to define a template in a .cpp file if you only use it in the same .cpp file.
20160904 06:31:16< vultraz> I see
20160904 06:31:44< vultraz> hmmm
20160904 06:31:47< vultraz> ..\..\src\gui\dialogs\dialog.hpp|309|error: incomplete type 'gui2::tfield_' used in nested name specifier|
20160904 06:32:15< vultraz> ah
20160904 06:32:30< JyrkiVesterinen> #include "src/gui/auxiliary/field.hpp"
20160904 06:32:34< JyrkiVesterinen> should fix it
20160904 06:32:41< vultraz> file included field-fwd
20160904 06:32:44< vultraz> instead of field
20160904 06:32:46< vultraz> yeah
20160904 06:33:26< vultraz> (I guess field-fwd was so modifications to field.hpp doesn't modify every dialog file?)
20160904 06:33:38< vultraz> or something?
20160904 06:36:31< celticminstrel> That's the general idea with most headers ending in fwd.
20160904 06:36:40< celticminstrel> Like <iosfwd>
20160904 06:37:36< vultraz> hmm
20160904 06:37:49< vultraz> ok, we haz problem :|
20160904 06:38:18< vultraz> the compiler doesn't know which version of the constructor to call if the 1st is called with 4 arguments :/
20160904 06:38:43< vultraz> if there a way to mark the other as "use this if not specialized?"
20160904 06:38:55< celticminstrel> Maybe?
20160904 06:39:25< celticminstrel> Is the constructor a template?
20160904 06:40:13< vultraz> one of them is
20160904 06:41:20< celticminstrel> vultraz: Why does editor_team_info take a separate side parameter instead of using team::side?
20160904 06:41:38< vultraz> uhhh....
20160904 06:41:43-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Ping timeout: 250 seconds]
20160904 06:41:50< vultraz> I left a comment for you regarding that
20160904 06:41:50< JyrkiVesterinen> How are the constructors declared?
20160904 06:42:24< celticminstrel> I remember this comment, but didn't think it explained that...
20160904 06:42:49< celticminstrel> So it's really side-1?.
20160904 06:43:11< vultraz> yes
20160904 06:43:19< celticminstrel> So why didn't you use team::side?
20160904 06:44:01< vultraz> there's team::side?
20160904 06:44:03< JyrkiVesterinen> Is your problem these two functions? https://github.com/Vultraz/wesnoth/blob/382562fd5a52298b964ff6dbe53997afc2debae0/src/gui/dialogs/dialog.hpp#L290-L299
20160904 06:44:23< vultraz> yes
20160904 06:44:28< vultraz> here's an updated commit https://github.com/Vultraz/wesnoth/commit/4dcaabb35c42d63c5e3a363bc94e82bfc6c498c4
20160904 06:44:35< celticminstrel> Yes?
20160904 06:44:46< JyrkiVesterinen> Then you need to change the upper function into a template specialization.
20160904 06:44:48< JyrkiVesterinen> See here: http://www.cprogramming.com/tutorial/template_specialization.html
20160904 06:45:20< JyrkiVesterinen> Then the compiler will automatically use the specialization if the caller passes a string as the source.
20160904 06:45:33< celticminstrel> Oh dear, swap problems.
20160904 06:45:45< vultraz> does that mean I also needs to move the implementation of that to the header?
20160904 06:46:07< celticminstrel> Oh, wait, it might not actually be a problem, because clang appears to have finished building.
20160904 06:46:41< JyrkiVesterinen> vultraz: Maybe. In any case, nothing prevents you from moving it. :)
20160904 06:47:52< vultraz> wha..
20160904 06:47:54< vultraz> ..\..\src\gui\dialogs\dialog.hpp|291|error: 'class std::__cxx11::basic_string<char>' is not a valid type for a template non-type parameter|
20160904 06:47:56< vultraz> :|
20160904 06:48:51< JyrkiVesterinen> Show the code.
20160904 06:50:57< celticminstrel> A template non-type parameter can only be one of the following:
20160904 06:51:07< celticminstrel> 1. An integral type (eg int, bool, char).
20160904 06:51:14< celticminstrel> 2. A pointer type.
20160904 06:51:19< celticminstrel> 3. A pointer-to-member type.
20160904 06:51:26< celticminstrel> 4. A pointer-to-member-function type.
20160904 06:51:36< celticminstrel> I think floating-point types are indeed excluded.
20160904 06:51:45< celticminstrel> And certainly class types are.
20160904 06:51:59< vultraz> I think I got it working
20160904 06:52:03< vultraz> let's see if it builds
20160904 06:52:23< celticminstrel> Note, template non-type parameter is when you have eg template<int x>
20160904 06:52:34< celticminstrel> Instead of template<typename T>
20160904 06:56:05< vultraz> I.. 
20160904 06:56:07< vultraz> ..\..\src\gui\dialogs\dialog.hpp|310|error: 'const class version_info' has no member named 'get_value'|
20160904 06:56:08< vultraz> :|
20160904 06:56:17< vultraz> why is it even calling this constructor!
20160904 06:56:32< celticminstrel> There is likely a good reason.
20160904 06:56:35< vultraz> that line should use the OTHER ONE
20160904 06:56:47< celticminstrel> As Jyrki said, show the code.
20160904 06:58:58< JyrkiVesterinen> I can answer already: some code is calling register_label and using version_info as the source.
20160904 06:59:29< JyrkiVesterinen> Version_info has implicit conversion to string, but the compiler selects the generic template anyway.
20160904 06:59:51< vultraz> ah, that seems to be the case
20160904 06:59:58< JyrkiVesterinen> (Which is a good preference IMO: compilers should try to avoid implicit conversions if they aren't necessary.)
20160904 07:00:30< JyrkiVesterinen> If there aren't too many callers which do that, you can just extract the string with version_info::str().
20160904 07:01:07< vultraz> there are a bunch :/
20160904 07:01:37< JyrkiVesterinen> Then how about adding another template specialization for version_info?
20160904 07:01:40< vultraz> maybe i can dispense with the template and use twidget...
20160904 07:01:55< vultraz> let's see if that works..
20160904 07:02:39< vultraz> sigh
20160904 07:02:41< vultraz> nope
20160904 07:02:42< vultraz> ..\..\src\gui\dialogs\dialog.hpp|310|error: 'class gui2::twidget' has no member named 'get_value'|
20160904 07:02:44< vultraz> ;_;
20160904 07:03:00< celticminstrel> By the way, what prevents you from passing a team reference directly to teditor_edit_side?
20160904 07:03:19< vultraz> celticminstrel: i can't remember
20160904 07:03:28< vultraz> i guess nothing, really..
20160904 07:03:47< vultraz> except then the fields will modify the team directly instead of the data in the struct
20160904 07:03:48< celticminstrel> Might mean you need to use callback forms of register for the non-labels, I suppose.
20160904 07:03:52< vultraz> if that's desired, go ahead
20160904 07:03:57< celticminstrel> I don't know, is it?
20160904 07:04:05< celticminstrel> Anyway, I'm not going to change anything that big right now.
20160904 07:04:17< vultraz> well then it would always write back to the team..
20160904 07:04:27< vultraz> right now the changes are only saved if you click OK
20160904 07:04:31< celticminstrel> Just getting the tests working and removing the redundant parameter.
20160904 07:04:46< celticminstrel> Are fields updated if you click cancel?
20160904 07:04:58< vultraz> good question...
20160904 07:05:18-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160904 07:05:19< vultraz> [18:03:46]	celticminstrel	Might mean you need to use callback forms of register for the non-labels, I suppose.
20160904 07:05:20< celticminstrel> tdialog::show should reveal all..
20160904 07:05:22< vultraz> and i dunno what this means
20160904 07:05:37< vultraz> how is it that twidget has no function for value..
20160904 07:05:47< celticminstrel> It means you'd need to use the form of register_integer that takes a getter/setter pair rather than a field reference.
20160904 07:06:38< vultraz> I'm not..using...r_i....
20160904 07:06:43< vultraz> here..
20160904 07:06:45< vultraz> what?
20160904 07:07:15< vultraz> (ugh, looks like widget sub-master-classes like tselectable implement get_value themselves as pure virtual)
20160904 07:07:20< vultraz> ;_;
20160904 07:07:29< celticminstrel> That's intentional, surely.
20160904 07:07:40< celticminstrel> Or, wait, what did you actually say?
20160904 07:07:54< vultraz> twidget has no getter for value
20160904 07:07:56< celticminstrel> Because "implement as pure virtual" sounds like a contradiction.
20160904 07:07:58< vultraz> virtual or otherwise
20160904 07:08:05< celticminstrel> Of course not.
20160904 07:08:32< vultraz> perhaps I don't want just any widget
20160904 07:08:36< vultraz> maybe just tselectable
20160904 07:08:47< celticminstrel> Probably something like that, yeah.
20160904 07:08:54< celticminstrel> tselectable_ or tinteger_selector.
20160904 07:13:51< celticminstrel> Protip, vultraz - any time you think you need a game_board in a dialog, see if you can make do with a display_context.
20160904 07:14:02< celticminstrel> Even better, a const display_context.
20160904 07:14:17< vultraz> eh?
20160904 07:14:36< celticminstrel> game_board extends display_context, but it's pretty difficult to use a game_board in the tests.
20160904 07:14:47< celticminstrel> However, it is possible to get a dummy const display_context.
20160904 07:16:06< celticminstrel> I was about to go "argh" about the transient message in game_stats, but then I realized that the tests don't go through the execute method.
20160904 07:22:53< vultraz> hmmm
20160904 07:22:55< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\gui\dialogs\dialog.cpp|198|error: invalid initialization of non-const reference of type 'gui2::event::tdispatcher&' from an rvalue of type 'gui2::tselectable_*'|
20160904 07:23:10< celticminstrel> dynamic_cast is your friend.
20160904 07:23:20< vultraz> that's what I'm using
20160904 07:23:54< celticminstrel> The two classes are actually unrelated, so do you need to downcast and then upcast?
20160904 07:23:58< celticminstrel> I dunno.
20160904 07:24:01< vultraz> 	gui2::event::connect_signal_notify_modified(&source, std::bind(&tfield_::widget_init, field, dynamic_cast<twidget&>(source).get_window()));
20160904 07:25:13< vultraz> ahh
20160904 07:25:47< vultraz> eh hm :/
20160904 07:26:21< vultraz> get_window returns a pointer..
20160904 07:28:00< JyrkiVesterinen> It seems to be complaining about the *first* parameter.
20160904 07:28:15< JyrkiVesterinen> It should probably be "source", not "&source".
20160904 07:29:20< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\gui\dialogs\dialog.cpp|198|error: invalid initialization of reference of type 'gui2::event::tdispatcher&' from expression of type 'gui2::tselectable_'|
20160904 07:29:58-!- celticminstrel is now known as celmin|sleep
20160904 07:30:02< vultraz> sigh
20160904 07:30:41< irker066> wesnoth: Celtic Minstrel wesnoth:master b82f4697cfe7 / src/tstring.cpp: Fix strict aliasing warning https://github.com/wesnoth/wesnoth/commit/b82f4697cfe7e22be77a8b03ab24bdc10a2ba115
20160904 07:30:43< irker066> wesnoth: Celtic Minstrel wesnoth:master 3e6fcc445074 / src/game_initialization/multiplayer.cpp utils/pofix.py: Make some translatable variable names more descriptive https://github.com/wesnoth/wesnoth/commit/3e6fcc445074a839070a656f1f1c81b76a4688b4
20160904 07:30:43-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160904 07:30:45< irker066> wesnoth: Celtic Minstrel wesnoth:master c29ea4e2612f / src/ (5 files in 3 dirs): Fix tests https://github.com/wesnoth/wesnoth/commit/c29ea4e2612fd919bb48ae25ebb2f01fccbc3231
20160904 07:31:10< JyrkiVesterinen> Then you need to get a GUI2 event dispatcher from somewhere, if the selectable is not one.
20160904 07:31:40< JyrkiVesterinen> Or if subclasses of tselectable inherit tdispatcher, then you can use dynamic_cast.
20160904 07:32:07< celmin|sleep> That should fix the tests, anyway. Hopefully it doesn't break something else.
20160904 07:32:11< celmin|sleep> Good night.
20160904 07:32:32< vultraz> i'd change this to just take a string id but then the parameter lists would be exactly the same :|
20160904 07:32:51< vultraz> blah
20160904 07:32:52< vultraz> ya know what
20160904 07:32:58< vultraz> I'll change the function name
20160904 07:33:28-!- Kwandulin [~Miranda@p200300760F424141FC1F016144D2FA3F.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
20160904 07:34:09< vultraz> oh wait, I don't have a window...
20160904 07:41:32-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160904 07:43:02-!- exciton [~exciton@89.208.170.132] has quit [Ping timeout: 250 seconds]
20160904 07:50:40-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 07:55:25-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Remote host closed the connection]
20160904 07:57:01-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160904 07:58:14< vultraz> blah
20160904 07:58:20< vultraz> I just noticed a giant hole in my plan
20160904 07:58:46< vultraz> fields are initialized before pre_show
20160904 07:59:02< vultraz> in order to pass a widget, I need to at least be in pre_show
20160904 08:04:30-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Quit: nurupo]
20160904 08:05:04-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160904 08:06:46< vultraz> ok, new plan...
20160904 08:07:14-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Client Quit]
20160904 08:07:44-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160904 08:09:14-!- travis-ci [~travis-ci@ec2-54-226-242-233.compute-1.amazonaws.com] has joined #wesnoth-dev
20160904 08:09:15< travis-ci> wesnoth/wesnoth#10707 (master - c29ea4e : Celtic Minstrel): The build was fixed.
20160904 08:09:15< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157411198
20160904 08:09:15-!- travis-ci [~travis-ci@ec2-54-226-242-233.compute-1.amazonaws.com] has left #wesnoth-dev []
20160904 08:22:47-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160904 08:38:56-!- Kwandulin [~Miranda@p200300760F42414125AB4833363F3615.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160904 09:15:05-!- Kwandulin [~Miranda@p200300760F42414125AB4833363F3615.dip0.t-ipconnect.de] has quit [Read error: No route to host]
20160904 09:23:35-!- _laco [~laco@static.183.80.201.138.clients.your-server.de] has joined #wesnoth-dev
20160904 09:39:05-!- edgrey [~edgrey@178.204.115.101] has joined #wesnoth-dev
20160904 09:39:23-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Quit: nurupo]
20160904 09:40:06-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160904 09:49:19-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160904 09:51:04-!- Kwandulin [~Miranda@p200300760F42414188B3CBDBBE11E583.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160904 09:53:09-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160904 09:53:09-!- wedge010 is now known as wedge009
20160904 10:17:24-!- JyrkiVesterinen [~JyrkiVest@87-100-134-69.bb.dnainternet.fi] has quit [Quit: .]
20160904 10:25:51-!- mjs-de [~mjs-de@x4e307068.dyn.telefonica.de] has joined #wesnoth-dev
20160904 10:25:53< zookeeper> shadowm, so how well back-upped are our forums? what would be the minimum it would take for everything to just be lost forever?
20160904 10:30:46-!- irker066 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160904 10:32:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160904 11:33:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160904 11:49:25-!- JyrkiVesterinen [~JyrkiVest@87-92-34-149.bb.dnainternet.fi] has joined #wesnoth-dev
20160904 12:05:02-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160904 12:07:10-!- celmin|sleep is now known as celticminstrel
20160904 12:09:22-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160904 12:13:49< celmin> What's with the chat log being "rebuilt" every time you view it...
20160904 12:21:03< mattsc> celmin, zookeeper: unless there are objections, I’m planning to merge the high_XP_attack PR soon(ish)
20160904 12:21:18< celmin> Objection! :P
20160904 12:22:20< celmin> Suddenly the healer attack CA score decreased.
20160904 12:22:33< celmin> And the return guardian score.
20160904 12:23:10< mattsc> yes?
20160904 12:23:44< celmin> Just wondering why.
20160904 12:24:49< celmin> Huh, previously SotBE used simple attack AI for that.
20160904 12:25:16< mattsc> right (on SotBE); there’s even an example on the wiki how to do that
20160904 12:25:42< celmin> I'm just kind of wondering, is TRoW15 really the only scenario that needs it to be explicitly disabled?
20160904 12:25:46< mattsc> The return guardian and healer attack where supposed to happen just after the default AI attacks.
20160904 12:26:31< mattsc> Thus, the CAs were giving a score of 99,990, to happen just after the combat CA (100,000).
20160904 12:26:57< mattsc> Now the attack CAs of the default AIs have 3 possible scores, ranging from 99,990 to 100,010
20160904 12:27:21< mattsc> Thus, in order to avoid conflicts, other CAs need to have scores outside that range.
20160904 12:27:30< celmin> Ah, that makes sense,
20160904 12:27:56< mattsc> Since the closest other default CAs have scores of 80k and 120k, there’s no problem with that whatsoever.
20160904 12:28:02< mattsc> As in, no behavior is changed.
20160904 12:28:28< mattsc> As for TRoW15, that’s the only one I found on pretty extensive grep-ing.
20160904 12:29:10< mattsc> There isn’t much in mainline that disables the combat CA.
20160904 12:29:31< mattsc> If you want to check yourself, I am happy to wait.
20160904 12:30:16< celmin> I probably wouldn't be qualified for that, given that I haven't played most of the mainline campaigns.
20160904 12:32:38-!- oldlaptop [~quassel@162.247.150.37] has quit [Read error: Connection reset by peer]
20160904 12:32:56< mattsc> This can be done from a code perspective alone though.  I looked for modfiy_ai and candidate_action (both case insensitive), as well as direct definitions of the AI throughout the entire data/ directory, and that’s what I found.
20160904 12:33:24< celmin> So, that includes multiplayer too.
20160904 12:33:30< mattsc> yes
20160904 12:33:40< celmin> …though I suppose there's probably very little multiplayer that uses AI.
20160904 12:33:48< celmin> Survival scenarios though.
20160904 12:34:09< mattsc> Probably.
20160904 12:36:24-!- Appleman1234 [~Appleman1@KD119104107133.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20160904 12:40:33-!- oldlaptop [~quassel@162.247.150.37] has joined #wesnoth-dev
20160904 12:42:02-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160904 12:43:52< celmin> mattsc: You're marked as away, so not sure if you can receive PMs right now?
20160904 12:44:15< mattsc> ugh; stupid irc client …
20160904 12:44:35< celmin> So you can't?
20160904 12:44:36< DeFender1031> celmin, i'm not familiar with any irc clients which don't accept pm on away
20160904 12:44:41< mattsc> I am used to other applications coming out of “away mode” once I start typing, so I always forget here.
20160904 12:44:49< mattsc> celmin: I still do get the PMs
20160904 12:44:53< celmin> Ah, okay.
20160904 12:45:23< DeFender1031> mattsc, many clients have a setting for that
20160904 12:45:58< mattsc> DeFender1031: I’ve looked for that and not found it.  I’m using Colloquy.
20160904 12:46:18< DeFender1031> not familiar with that one.
20160904 12:48:36< celmin> Pretty sure it doesn't have a setting.
20160904 12:48:42 * celmin uses it too.
20160904 12:49:27 * DeFender1031 uses konversation
20160904 12:54:38< zookeeper> mattsc, merge away as far as i'm concerned. although i doubt you were asking if _i_ had any objections :p
20160904 12:58:58-!- edgrey [~edgrey@178.204.115.101] has quit [Quit: Konversation terminated!]
20160904 12:59:12-!- edgrey [~edgrey@178.204.115.101] has joined #wesnoth-dev
20160904 12:59:47-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160904 12:59:59< mattsc> zookeeper: I was asking if anybody had objections, you included  :)
20160904 13:00:16-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160904 13:00:39< zookeeper> well admittedly it is a bit sad if i can no longer cheese my way out of a tricky situation with a 1xp-to-level unit...
20160904 13:01:32< mattsc> hehe; yeah, we’re evil™
20160904 13:01:43< celmin> …what… why the heck do palettes take a pointer to a pointer… o.o
20160904 13:04:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 13:04:14-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 13:05:28-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160904 13:08:34-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160904 13:09:32-!- Kwandulin [~Miranda@p200300760F42414188B3CBDBBE11E583.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160904 13:10:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 13:10:16-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 13:11:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 13:13:14< DeFender1031> celmin, yo dawg, I heard you like pointers, so we made your palettes take a pointer to a pointer.
20160904 13:17:57-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160904 13:18:34-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Remote host closed the connection]
20160904 13:18:58-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160904 13:20:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 13:20:28-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160904 13:22:35< celmin> "Default implementation, but defined out-of-line for efficiency reasons"
20160904 13:22:37< celmin> What
20160904 13:22:41< celmin> (It's a destructor)
20160904 13:22:45< celmin> Why is this even here
20160904 13:22:55< celmin> If it's default implementation, why is it even declared
20160904 13:25:21< celmin> Relatedly, we'll probably need a GUI2 palette eventually.
20160904 13:25:44< celmin> Probably using the matrix generator, so I guess I should fix that.
20160904 13:26:46-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has quit [Ping timeout: 252 seconds]
20160904 13:34:35< celmin> -Woverride is a valid warning right
20160904 13:35:43< shadowm> zookeeper: Very poorly because we don't have remote backups (blame Soliton and Rhonda for that, there's nothing I can do with potato Internet and limited to 20 GiB a month).
20160904 13:36:08< celmin> shadowm: So what about asio campaignd
20160904 13:36:23< shadowm> I have a backup of the database from January this year I'm using for testing purposes but that's it.
20160904 13:37:01< shadowm> The server internally keeps backups too and there are a lot of those, if it helps.
20160904 13:37:40< shadowm> Not just of the database.
20160904 13:37:52< shadowm> celmin: Can't right now, probably won't get to it today.
20160904 13:37:59< zookeeper> shadowm, hrhm. right. how big are the backups and/or how easy would it be to arrange for extra people to be able to download backups?
20160904 13:38:17< zookeeper> like, for some extra redundancy
20160904 13:38:30< shadowm> Absurdly large.
20160904 13:39:10< shadowm> I can't check right now because I'm not on my desktop but I'm fairly sure it's at least 200 GiB a day, full system files + data, no incremental storage/generation.
20160904 13:39:28< celmin> Why the heck are all these game-specific things methods in command_executor.
20160904 13:39:40< celmin> Like rename_unit or status_table
20160904 13:39:48< shadowm> I think it's perfectly reasonable of me to not be particularly inclined to allow people who don't already work with the server infrastructure to download backups that include highly sensitive data.
20160904 13:40:02< zookeeper> shadowm, 200 GiB huh? yeah that's a lot...
20160904 13:40:07< celmin> They include highly sensitive data?
20160904 13:40:21< celmin> Referring to password hashes, or something else?
20160904 13:40:22-!- prkc [~prkc@192.40.89.70] has joined #wesnoth-dev
20160904 13:40:28< shadowm> Everything.
20160904 13:40:40< celmin> Private posts?
20160904 13:40:54< shadowm> Password hashes, purportedly "private" message boxes, email addresses, hidden forums, the database auth info itself...
20160904 13:41:00< shadowm> And that's just the forums.
20160904 13:43:50< zookeeper> not having even a half-assed remote backup system gives me the creeps
20160904 13:44:36< shadowm> Can't disagree with that, but my insistence alone isn't going to fix that if nobody has the time and expertise to set up a better system on a trusted host (and without sucking Wesnoth Inc's bank account dry).
20160904 13:46:15< shadowm> A certain dev who is in fact still around has offered "advice" several times but doesn't seem to understand that I don't know what I'm doing and that the other two don't have time.
20160904 13:46:27< shadowm> And seems very reluctant to do anything himself.
20160904 13:47:14< celmin> Text box handling really needs improvement actually...
20160904 13:47:26< celmin> There's no by-word navigation for example...
20160904 13:48:51< zookeeper> shadowm, do you happen to have any ballpark estimate as to how much a better system would cost?
20160904 13:49:54< shadowm> Not at all (see the "I don't know what I'm doing" part).
20160904 13:50:51< zookeeper> okay
20160904 13:51:05< shadowm> Personally I'd be content with a dedicated backup HDD even on the same machine, as long as it's a different model than the duo in the RAID1 array that is particularly prone to dying.
20160904 13:51:59< shadowm> (Seagate 3 TB or 2 TB I believe, don't have the serial handy atm.)
20160904 13:52:42 * shadowm is off.
20160904 13:53:33< zookeeper> the server's backups are all on the same physical HDD's? oh dear.
20160904 14:00:41< mattsc> celmin: any further objections to merging the PR?
20160904 14:00:50< celmin> No.
20160904 14:01:02< celmin> Other than the trivial one that I'll have to rebase (but you can ignore that).
20160904 14:01:27< mattsc> Cool, I’ll go find the button and press it then …
20160904 14:02:48-!- irker203 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160904 14:02:48< irker203> wesnoth: mattsc wesnoth:master 6950ee1dd08a / / (5 files in 5 dirs): New high_xp_attack candidate action for default AI https://github.com/wesnoth/wesnoth/commit/6950ee1dd08a429394f7b0c38340f298c344d57f
20160904 14:02:48< irker203> wesnoth: mattsc wesnoth:master 390d1fdc10cd / data/ai/lua/ca_high_xp_attack.lua: High XP CA: simplify attack conditions with 1.13 syntax https://github.com/wesnoth/wesnoth/commit/390d1fdc10cd9fb878186fb1c123cd1e343bdb6d
20160904 14:02:49< irker203> wesnoth: mattsc wesnoth:master af0f49ae9a8c / data/core/macros/ai_candidate_actions.cfg: High XP CA: add missing braces to CA definition https://github.com/wesnoth/wesnoth/commit/af0f49ae9a8c907ff420c9e851fd44188c1ebb5d
20160904 14:02:50< irker203> wesnoth: mattsc wesnoth:master f76e2d0c595a / data/ai/ (lua/ca_high_xp_attack.lua scenarios/scenario-high_xp_attack.cfg): High XP attack CA: remove a debug message https://github.com/wesnoth/wesnoth/commit/f76e2d0c595a7d217f7a6940ea78df78baac80f0
20160904 14:02:51< irker203> wesnoth: mattsc wesnoth:master 8e50c4ee066a / data/campaigns/Son_Of_The_Black_Eye/ (3 files in 2 dirs): SotBE: remove macros to force attacks on high-XP enemies https://github.com/wesnoth/wesnoth/commit/8e50c4ee066aee2ea9925d4964baa691c14f698c
20160904 14:02:52< irker203> wesnoth: mattsc wesnoth:master d781e6263a49 / data/ (11 files in 6 dirs): High XP attacks: adapt other AIs to existence of new CA https://github.com/wesnoth/wesnoth/commit/d781e6263a49dc6daea8c49aec328f0cf15b46ca
20160904 14:02:54< irker203> wesnoth: mattsc wesnoth:master 56d30fc82b41 / / (19 files in 11 dirs): Merge pull request #764 from wesnoth/ai_high_xp_attack https://github.com/wesnoth/wesnoth/commit/56d30fc82b418ae71b6e8996fc426c91dfe78b71
20160904 14:03:03< zookeeper> \o/
20160904 14:05:00< mattsc> zookeeper: :)   [if you still wanted to check out the test scenario, it might make it easier to distinguish between the new CA and the other attacks if you reverted f76e2d0c595a locally for the tests; it’s not needed, but shows how things work more clearly]
20160904 14:05:53< mattsc> zookeeper: Should we reply in the “Pebbles in the Flood” bug post on the forum to let people know about this?
20160904 14:06:11< mattsc> I’ll also update the wiki.  And this should probably be in the release notes, right?
20160904 14:06:41< zookeeper> yes to all. you want to do the post or shall i?
20160904 14:07:25< mattsc> zookeeper: go ahead if you have time and don’t mind; otherwise I’ll do so later sometime
20160904 14:07:36< celmin> Release notes and also changelog.
20160904 14:07:43< celmin> Not sure if it belongs in player changelog? Maybe.
20160904 14:07:54< mattsc> celmin: it’s already in the changelog
20160904 14:07:59< celmin> Ah.
20160904 14:08:05< mattsc> put you’re right, it should be in the players changelog too
20160904 14:09:22< zookeeper> mattsc, sure i'll drop in a short post there
20160904 14:09:56< mattsc> zookeeper: thanks; I’ll take care of wiki, players changelog and release notes
20160904 14:11:34-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160904 14:12:45-!- Bonobo [~Bonobo@2001:44b8:254:3200:e8b4:537f:ddc4:425a] has quit [Quit: Leaving]
20160904 14:15:46-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160904 14:17:22-!- Kwandulin [~Miranda@p200300760F424141E56A47602F62CD03.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160904 14:19:32< irker203> wesnoth: mattsc wesnoth:master a6a7e7919409 / data/campaigns/The_Rise_Of_Wesnoth/scenarios/15_A_New_Land.cfg: TRoW S15: correct side numbers in AI setup https://github.com/wesnoth/wesnoth/commit/a6a7e79194098b1d9b815365529b0f93192eb77d
20160904 14:32:45< zookeeper> ah, but which of the many threads to post it in...
20160904 14:36:17< mattsc> zookeeper: I was thinking about this one: https://forums.wesnoth.org/viewtopic.php?f=4&t=41009
20160904 14:37:11< zookeeper> yeah i guess it's the logical one since the actual AI discussion is there too
20160904 14:42:14-!- markus__ [~mjs-de@x5ce33565.dyn.telefonica.de] has joined #wesnoth-dev
20160904 14:45:58-!- mjs-de [~mjs-de@x4e307068.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20160904 14:46:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: No route to host]
20160904 14:48:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160904 14:51:16-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 14:55:27-!- prkc [~prkc@192.40.89.70] has quit [Remote host closed the connection]
20160904 14:59:33-!- gfgtdf [~chatzilla@x4e369225.dyn.telefonica.de] has joined #wesnoth-dev
20160904 15:00:11< gfgtdf> is there somehwere a documatation of the editor ?
20160904 15:01:03< celmin> No idea.
20160904 15:01:15< celmin> Maybe it should be put in the manual...
20160904 15:01:23< celmin> I'd check there and the help pages, anyway.
20160904 15:01:32< celmin> (As well as the wiki, I suppose.)
20160904 15:02:24< vultraz> there are some help pages
20160904 15:03:22< vultraz> I think I need to rethink my approach with this status labels thing
20160904 15:03:32-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160904 15:03:38< vultraz> perhaps using tfield's interface isn't the right way to go..
20160904 15:03:47< gfgtdf> vultraz: in the wiki you mean ?
20160904 15:03:57< vultraz> gfgtdf: no in Help.
20160904 15:04:32< gfgtdf> vultraz: hmm couldn'^t find it in 1.12..6 is it 1.13 only ?
20160904 15:04:54< vultraz> maybe?
20160904 15:04:56< tad_> celmin: Testing bad_lexical_cast crash: (1) Add [modify_unit][ai] to prestart and the ai error appears (2) remove attack_depth and it crashes.
20160904 15:05:37< gfgtdf> oh and teh 1.12.6 help gives me a and erro when  try top open 'contributors' section: 'untermiated element: BreadyUnixer'
20160904 15:05:47< celmin> I still haven't gotten past the crash on loading the campaign, sorry. :(
20160904 15:06:19< celmin> vultraz: Is it specifically for sliders?
20160904 15:06:21< tad_> celmin: I am running sync'd clean on master + PT 766 for user_team_name
20160904 15:06:35< vultraz> celmin: ???
20160904 15:06:40< celmin> The status labels.
20160904 15:07:17< celmin> tad_: Including my commits that fixed Travis and the strict aliasing?
20160904 15:07:17< vultraz> celmin: right now, basically, yes. 
20160904 15:07:29< vultraz> celmin: honestly, it might be better to refactor sliders.
20160904 15:07:29< celmin> vultraz: Would it generalize to anything else?
20160904 15:07:51< tad_> celmin: this AM fetch upstream rebase upstream/master make
20160904 15:08:00-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160904 15:08:07< vultraz> well in prefs we also use them for other things, actually
20160904 15:08:09< vultraz> uh..
20160904 15:08:16< vultraz> toggle buttons display "yes" or "no"
20160904 15:08:23< celmin> tad_: Guessing that's a yes. I was getting the crash with those commits, so basically I'm on clean master too.
20160904 15:08:33< vultraz> and certain options display their status
20160904 15:09:16< celmin> So basically, tinteger_selector and tselectable_?
20160904 15:09:19< tad_> celmin: git log -1 master --> Merge pull request #764 from wesnoth/ai_high_xp_attack
20160904 15:09:25< celmin> Okay.
20160904 15:09:55< celmin> That PR shouldn't affect it, since it has no C++ changes, so even though I haven't pulled that, it seems like my build is equivalent to yours.
20160904 15:10:15< vultraz> celmin: yes
20160904 15:10:32< tad_> Well it's the HEAD. If your stuff is in the commit log below it, I have your stuff and it works for me
20160904 15:10:50< celmin> My stuff is HEAD^ through HEAD^^^ :P
20160904 15:11:36< tad_> Yep. I see it.
20160904 15:11:45< vultraz> celmin: how would you recommend I proceed?
20160904 15:11:50< tad_> Anyway, with your stuff in "Works for me"
20160904 15:13:01< tad_> celmin: Only off-the-wall thing I've done in the past couple days is clear .cache .config and .local/../1.13
20160904 15:13:20< celmin> I generally don't clear prefs.
20160904 15:13:41< celmin> And clearing userdata would mean deleting my testing scenario.
20160904 15:14:20< tad_> celmin: Well I wanted to be sure I was starting from a reproducible state.
20160904 15:14:49< vultraz> tad_: btw, as far as I know no one even knows side_name is a thing
20160904 15:14:58< vultraz> (anyone feel free to correct me)
20160904 15:15:29< tad_> vultraz: Istr using it in DM to clean up a mess with Menu|Statistics .. but I may be wrong
20160904 15:15:44< vultraz> Istr?
20160904 15:15:50< tad_> I seem to recall.
20160904 15:16:41< vultraz> Statistics, you say...
20160904 15:17:09< tad_> I'm re-checking DM and that fix is in the future. So I've not verified it yet. But I do remember seeing side_name and I think I used it to ensure 'Delfador" appeared when Kalenz was leading so the UI was consistent
20160904 15:17:45< vultraz> grepping all campaigns 
20160904 15:18:09< tad_> Well, you might need to look in my DM PR for my use of it.
20160904 15:18:20< vultraz> oh,
20160904 15:19:00< vultraz> side_name: (Version 1.13.5 and later only) 
20160904 15:19:06< tad_> IT's been a while and I'm not up to that point, yet, so it's all aged grey-matter storage ...
20160904 15:19:07< vultraz> eh? when did we add this...
20160904 15:19:52< vultraz> if we've added side_name, then... hm...
20160904 15:20:13< vultraz> why not use it in more places?
20160904 15:20:23< celmin> vultraz: gfgtdf added it like a month or two ago.
20160904 15:20:27< tad_> It comes from [leader]name= 
20160904 15:20:27< vultraz> if you issue is that user_team_name gets shuffled
20160904 15:20:30< gfgtdf> vultraz: i did this, but note that we has name= in [side] in 1.12 although it wasnt used
20160904 15:20:36< gfgtdf> often
20160904 15:20:39< tad_> Which is a different thing.
20160904 15:20:54< celmin> vultraz: user_team_name represents a different thing than side_name.
20160904 15:21:02< celmin> side_name is "the name of this side".
20160904 15:21:11< gfgtdf> vultraz: the issue in the pr is that the connect engine enfoces that same team_name implies same user_team_name
20160904 15:21:14< celmin> user_team_name is "a description of this side's alliance".
20160904 15:21:24< vultraz> celmin: except utn is *very very often* used as as a side_name
20160904 15:21:24< tad_> side_name is "the internal key I use for the side I am allied with"
20160904 15:21:28< celmin> True.
20160904 15:21:39< gfgtdf> vultraz: which makes sense somehow but it seems liek there were some campaign reliing on the opposute bahviour
20160904 15:21:43< vultraz> I believe we should disambiguate the usage.
20160904 15:21:46< tad_> user_side_name is "the name this side uses to refer to side_name"
20160904 15:22:01< tad_> or something like that.
20160904 15:22:03< celmin> Isn't side_name translatable?
20160904 15:22:10< tad_> It's all a confusing mess 
20160904 15:22:19< vultraz> because this is frankly ridiculous 
20160904 15:22:33< celmin> team_name isn't translatable, certainly.
20160904 15:22:42< vultraz> team_name is the team_id
20160904 15:22:43< gfgtdf> celmin: side_name is translatable
20160904 15:22:51< vultraz> (and should be renamed)
20160904 15:22:59< celmin> Right, so side_name identifies the specific side.
20160904 15:23:02< gfgtdf> celmin: specialla sicne it defautls to name= (the leaers name usually)
20160904 15:23:05< vultraz> yes
20160904 15:23:08< celmin> user_team_name identifies the side's "team".
20160904 15:23:10< gfgtdf> celmin: no
20160904 15:23:16< celmin> ?
20160904 15:23:18< gfgtdf> celmin: its meant as a visible name
20160904 15:23:23< gfgtdf> celmin: unline team_name
20160904 15:23:37< celmin> Yes, it's a visible name identifying the specific side.
20160904 15:23:38< gfgtdf> celmin: sides are identited by theor number
20160904 15:23:41< tad_> yes. and there's so many name-this and name-that and some are translated and some are not and some are copied for defaults and some are not and it really needs a document all its own for all the if's and therefor's
20160904 15:23:51< celmin> I was using "identify" more generally than you are.
20160904 15:24:23< celmin> Ugh, but somehow, it's not right to set the side_name to "Bandits" and "Undead" in that TSG case, is it...
20160904 15:24:43< gfgtdf> celmin: hmm why not?
20160904 15:24:45< celmin> So maybe I'm wrong and user_team_name actually is side_name.
20160904 15:24:54< celmin> gfgtdf: Because then you don't see the leader's name?
20160904 15:24:56< tad_> user_team_name is what displays.  team_name controls the [ai]
20160904 15:24:57< vultraz> of course it's used that way :|
20160904 15:25:38< vultraz> like, look at my campaign. I have side 1 with the utn "Niryone" (leader name), and then allied side 2 (same team_name) is "Defenders" or something.
20160904 15:25:47< tad_> The problem is, for that scene, the Bandits are temporarily allied with the Undead (ie., won't attack each other, there)
20160904 15:25:51 * celmin does seem to recall thinking that gfgtdf didn't think it through well when adding side_name.
20160904 15:26:39< vultraz> I have a rather... radical idea.
20160904 15:26:55< vultraz> And I know a certain keeper of zoos will be opposed to it
20160904 15:27:04< vultraz> Why don't we introduce an actual [team] tag
20160904 15:27:07< vultraz> with an id, and a name
20160904 15:27:14< tad_> And we need to be clear "side_name" is the name [side] displays for Menu|Statistics "user_team_name" is the name it uses for it's version of the team for Menu|StatusTable
20160904 15:27:15< vultraz> and [allied_with] subtags
20160904 15:27:28< vultraz> we could also have some mechanism to control when they're allied
20160904 15:27:35< gfgtdf> celmin: the the maoin issue back the was that current_player= sometimes reffereed to the sides name and sometimes to the players name.
20160904 15:27:40 * tad_ points to his comment on PR 766(?) about a design doc ...
20160904 15:27:53< vultraz> for example [allied_width] SSF [if] turn = 10
20160904 15:27:59< vultraz> or something like that
20160904 15:28:04< vultraz> maybe we don't need a subtag
20160904 15:28:05< gfgtdf> celmin: so the main intention then was to make 'current_player' always refer to thte pla<yers nick to fix issue sin mp connect.
20160904 15:28:16< vultraz> but my point is we introduce a more robust teams mechanism
20160904 15:28:24< vultraz> thoughts?
20160904 15:28:30 * celmin thinks vultraz isn't thinking this through well either.
20160904 15:28:36< vultraz> why not?
20160904 15:28:38< celmin> gfgtdf: What?
20160904 15:29:02< celmin> vultraz: [team] + [allied_with] somehow doesn't seem to fit.
20160904 15:29:25< vultraz> celmin: how come?
20160904 15:29:30< celmin> More specifically, it would make sense to me to have one of them, but not both.
20160904 15:29:35< tad_> I think there is a lot of not thinking it through and a lot of "For SP I need" fighting with "For MP I need" and "For THIS scene I need" vs "For the CAMPAIGN I need"
20160904 15:29:45< celmin> I can't think of any way to use [team] other than grouping allied sides.
20160904 15:29:48< vultraz> celmin: well, it couldbe allied_with = list of sides
20160904 15:30:06< celmin> Well, that's basically how it works now anyway, with team_name.
20160904 15:30:13< vultraz> celmin: keep in mind this would be a toplevel tag
20160904 15:30:20< celmin> Yeah, I get that.
20160904 15:30:31< vultraz> celmin: I simply thought it might be useful to have more robust filtering of allies
20160904 15:30:43< vultraz> using a Standard Sides filter
20160904 15:30:45< celmin> But the thing is that a team is the alliance, so it doesn't make sense to me for the team to have an allied_with tag/key.
20160904 15:30:55< celmin> It makes more sense for the side to have allied_with.
20160904 15:30:59< vultraz> why... not
20160904 15:31:06< vultraz> team a is allied with team b
20160904 15:31:11< celmin> (But of course that would mean the alliance as a whole isn't easily named.)
20160904 15:31:15< tad_> I am on "team tad" but, for one scene I'm allied with "team celmin" and on the next, it's "team vultraz" and when I'm playing MP and am the human, I handle it by hand, but if I'm on SP and the AI I need some help to know what to do ...
20160904 15:31:45< gfgtdf> i think a good step for less confusion would be to change the c++ cpode to match the wml keys, that is renaming team class to side etc.
20160904 15:31:47< celmin> Okay vultraz, what exactly is a "team" in your concept?
20160904 15:31:54< celmin> Perhaps we're thinking of different things.
20160904 15:32:01< vultraz> celmin: a group of allied sides
20160904 15:32:14 * celmin is not in favour of renaming the team class.
20160904 15:32:35< vultraz> celmin: if you're on the team you're allied with other people on the team
20160904 15:32:53< vultraz> celmin: I see your point about allied_width being in [side], though...
20160904 15:33:02< celmin> Okay, so what you're thinking is that each team_name would become a [team], but could also specify non-reciprocal allies with [allied_with]?
20160904 15:33:15< celmin> You added a D to with again.
20160904 15:33:22< vultraz> something like that
20160904 15:33:28< vultraz> yes.
20160904 15:33:45< tad_> Issue: how do I tell the AI to change "teams" mid-way .. and if I do, what changes on the UI? Does anything change? Is it up to the designer (s/b) or is there no choice (yuck)?
20160904 15:33:58< celmin> I guess that could work… but what are the advantages over simply having allied_with in [side]? I suppose that you could have a name key...
20160904 15:34:23< celmin> tad_: I think with [modify_side]team_name=, and pretty sure it updates the UI.
20160904 15:34:26< vultraz> celmin: the only advantage is that teams can have a global side name
20160904 15:34:37< celmin> You mean a global alliance name.
20160904 15:34:39< celmin> ?
20160904 15:34:42< vultraz> yes, sorry
20160904 15:35:07< tad_> celmin: Yes, but SHOULD it?  And, no, you have to [modify_side]user_team_name to change the UI ...
20160904 15:35:10< vultraz> user_team_name is bad since some people use it as side_name, some as a team name (not to be confused with team_name :| )
20160904 15:35:21< vultraz> which is why I propose we disambiguate 
20160904 15:35:34< vultraz> or whatever the word is it's 3 am
20160904 15:35:50< vultraz> we could very well support allied_with in [side]
20160904 15:35:51< celmin> tad_: Oh right, team_name isn't shown to the UI, so I guess it wouldn't update the UI.
20160904 15:35:57< tad_> [side]side=1 displays as "side_name" .. it is on team "team_name" (a key) and displays that as "user_team_name"
20160904 15:36:00< celmin> It should if you change user_team_name though.
20160904 15:36:21< vultraz> right now this is a ridiculous mess :|
20160904 15:36:39 * tad_ waves his arms! "What I been saying!"
20160904 15:36:57< vultraz> I propose we resolve this for 1.13.6 or 1.13.7
20160904 15:37:14< celmin> So, it's my impression that user_team_name as it currently stands should be renamed to side_description.
20160904 15:37:37< tad_> I think we need a document which addresses the SP/MP Human/AI Engine/Designer issues.
20160904 15:37:40< vultraz> no...
20160904 15:37:44< celmin> Sometimes it's used to represent the alliance.
20160904 15:37:44< vultraz> why would you do that
20160904 15:37:47< vultraz> we have side_name 
20160904 15:37:59< celmin> Yeah, side_name was probably a mistake though.
20160904 15:38:09< vultraz> not really
20160904 15:38:15< vultraz> it represents a used behavior
20160904 15:38:15< celmin> Plus, the way user_team_name is currently used isn't as the name of a side.
20160904 15:38:21< celmin> It's as the description of a side.
20160904 15:38:27< celmin> Or a name for a side's alliance.
20160904 15:38:31< tad_> To be honest, right now, I'm able to handle it .. the only issue I've seen is the end-scenario vs load-scenario issue for PR 766
20160904 15:38:32< vultraz> Well, yes
20160904 15:38:44< vultraz> but I see little distinction
20160904 15:39:06< celmin> The distinction is that side_name replaces the leader name.
20160904 15:39:12< vultraz> ... what... 
20160904 15:39:25< vultraz> ........... what kind of behavior is that
20160904 15:39:30< vultraz> that's totally the wrong behavior :|
20160904 15:39:44< celmin> I mean that it'll show instead of the leader name in UI, not that it sets the name of your leader. Just clarifying that.
20160904 15:39:46< tad_> I ignore the names and go with the effect.
20160904 15:40:05< tad_> "side_name" is the name displayed on Menu|Statistics
20160904 15:40:29< tad_> "user_team_name" is the name displayed on Menu|Status Table under "Team"
20160904 15:40:38 * vultraz flips and walks away
20160904 15:42:05< celmin> ...
20160904 15:42:23< tad_> I've not seen any other place where "side_name" displays, or "user_team_name" displays. So I treat them as the designer's, per side, ability to decide what to display to the user.
20160904 15:42:42< gfgtdf> https://github.com/wesnoth/wesnoth/blob/master/src/gui/dialogs/multiplayer/mp_create_game.cpp#L330 gives me a wanring about int to bool conversion
20160904 15:43:23< celmin> :|
20160904 15:44:00< celmin> …okay, how the heck is that even possible.
20160904 15:44:34< celmin> gfgtdf: What's the full message?
20160904 15:45:31< tad_> Anyway .. my concern about user_team_name is simply that it be consistent from end-scenario to load-scenario and my PR does that. Now, I'm concerned about an AI error message and a crash, both related to [modify_side][ai] and I'm thinking I need to check if my [modify_side]replace PR fixes it :P
20160904 15:46:05< celmin> Wasn't that [modify_unit]?
20160904 15:46:27< gfgtdf> mostlikeley attribute value have no operator  bool so it uses  operator int and then casts it to a bool
20160904 15:46:41< celmin> gfgtdf: But it's calling has_attribtue()
20160904 15:46:45< celmin> ^attribute
20160904 15:47:18< celmin> Oh, wait.
20160904 15:47:46< celmin> What does start_time actually control?
20160904 15:47:55< celmin> It sounds like an int, but apparently it's actually a bool.
20160904 15:48:09< celmin> Randomizing start time?
20160904 15:49:05< gfgtdf> celmin: yes
20160904 15:49:33< celmin> So your explanation makes sense, I guess.
20160904 15:49:52< celmin> Normally you'd use to_bool, but this is a macro. I suppose you could have two different versions of the macro.
20160904 15:50:27< celmin> (If you decide to do that, please also make the macro definition statement-safe either by adding "else" to the end or by wrapping it in do {} while(false))
20160904 15:50:41< celmin> vultraz removed that earlier without understanding the reasoning for it.
20160904 15:50:48< tad_> celmin: Yes. So maybe I need do it again for modify_side .. something to check which is easy and if it fixes the error great
20160904 15:51:06< vultraz> do while false is ugly :|
20160904 15:51:14< JyrkiVesterinen> Is it really necessary to make the macro statement-safe given that it's only used in one function?
20160904 15:51:15< celmin> vultraz: It's a necessary evil in macros.
20160904 15:51:27< vultraz> c++ code macros are ugly
20160904 15:51:32< celmin> JyrkiVesterinen: I suppose not, but I kind of like to do it just as a matter of course.
20160904 15:51:38< celmin> tad_: modify_side doesn't work analogously to modify_unit.
20160904 15:52:31< JyrkiVesterinen> Well, myself I prefer to make macros short if I feel I can afford to assume that it will always be used safely (in particular, if I'm the only user of the macro).
20160904 15:52:43< celmin> And [modify_ai][ai] is not equivalent to [side][ai] - it only supports aspects at the moment (plus goals in the wml_tag_porting branch).
20160904 15:52:56< celmin> JyrkiVesterinen: I guess that's fair
20160904 15:53:50< tad_> celmin: probably, but it's work a few minutes to check. And the issue is [modify_side][ai] for attack_depth and village_value
20160904 15:54:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 15:54:14-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 15:55:20< celmin> [modify_side] is currently implemented in C++, just for reference (in game_lua_kernel.cpp). Though I'd prefer not to have to deal with changes to that since I have a Lua version in the wml_tag_porting branch.
20160904 15:56:32< vultraz> celmin: putting aside this ridiculous utn thing for the moment, how would you suggest i proceed with the status label thing?
20160904 15:56:53< tad_> celmin: There is a modify_side hook in lua/utils
20160904 15:57:03< celmin> tad_: What?
20160904 15:58:13< tad_> celmin cf: data/lua/wml-tags.lua line 877
20160904 15:58:35< celmin> tad_: Which as I recall does nothing but forward its params to wesnoth.modify_side()
20160904 15:58:44< celmin> Which is why I said [modify_side] is implemented in C++.
20160904 15:58:58< celmin> It doesn't count as a Lua implementation in my opinion if it's just a stub like that.
20160904 15:59:16< tad_> celmin: so I can't .. ah .. ok
20160904 15:59:21< celmin> vultraz: Given that the idea is to update a label when a widget's state changes, the logical solution is to use the set_callback_state_changed; but that's poorly implemented right now.
20160904 15:59:38< zookeeper> it sounds like people are saying that there's something fundamentally wrong with what team_name/user_team_name do.
20160904 15:59:47< zookeeper> bugs aside, that is.
20160904 16:00:00< celmin> tad_: Admittedly it would be totally possible to do preprocessing on the config and then forward it, but I don't think that would help with implementing a replace type option.
20160904 16:00:25< tad_> zookeeper: I think it's a disconnect between what a team is and who gets to decide the name.
20160904 16:00:44< vultraz> hm
20160904 16:00:49< vultraz> what would an error such as thismean..
20160904 16:00:51< vultraz> C:\TDM-GCC-32\lib\gcc\mingw32\5.1.0\include\c++\type_traits|936|  required by substitution of 'template<class _Tp, class _Arg, class> static std::true_type std::__do_is_direct_constructible_impl::__test(int) [with _Tp = std::_Tuple_impl<1u, gui2::twindow>; _Arg = std::_Tuple_impl<1u, gui2::twindow>&&; <template-parameter-1-3> = <missing>]'|
20160904 16:01:10< zookeeper> a team is a set of allied sides, as has been said. the scenario designer decides the user-visible team names. if those are wrong, kick the scenario designer.
20160904 16:01:10< celmin> That's not the actual error. It's part of the template backtrace.
20160904 16:01:12< tad_> celmin: Yeah. I can change the [modify_side] attributes but not the side data ..
20160904 16:02:22< celmin> I think the only subtag of [modify_side] is [ai] actually, so on wml_tag_porting it'd probably be possible to make it replace instead of append the AI (though that's probably going to be very rarely desirable, and also would require to add support for adding stages through modify_side).
20160904 16:03:57< celmin> zookeeper: So you would not support one allied side having user_team_name=_"Bandits" while the other allied side has user_team_name=_"Undead"?
20160904 16:04:07< zookeeper> correct
20160904 16:04:12< zookeeper> that misrepresents the team
20160904 16:05:03< tad_> zookeeper: That's the point. Bandits are on team Bandits and only allied with team Undead for this scenario.
20160904 16:05:13< zookeeper> in some rare cases one might want to have team_names not perfectly correspond with user_team_names, but generally they should match.
20160904 16:05:28< celmin> Ah, I see.
20160904 16:05:41< zookeeper> tad_, all of this pertains only to a single scenario
20160904 16:05:47< zookeeper> what happens in another scenario is completely irrelevant
20160904 16:05:48< celmin> So in this case they are logically separate teams that happen to be allied, huh..
20160904 16:05:59< celmin> Maybe, yeah.
20160904 16:06:01< tad_> zookeeper: Rare cases being DM where the team names are all over the place and sides change teams more often than my wife changes shoes
20160904 16:07:17< vultraz> [03:05:11]	zookeeper	in some rare cases one might want to have team_names not perfectly correspond with user_team_names, but generally they should match.
20160904 16:07:18< vultraz> no no
20160904 16:07:21< vultraz> no no no :|
20160904 16:07:22< zookeeper> then it sounds likely that it's simply DM that is to blame, and not any sort of problem with the team name system in general
20160904 16:07:42< zookeeper> vultraz, what? that's how they're supposed to be used. explain yourself at once!
20160904 16:07:45< tad_> The problem is we have two 'team' concepts going. There is the AI 'team' which means who attack whom, and the human 'team' for MP which controls .. what? .. scoring?
20160904 16:08:58< celmin> Although there's also the complication that team_name is actually a comma-separated list.
20160904 16:09:10< tad_> celmin: And that.
20160904 16:09:12< vultraz> zookeeper: that is only applicable if there is a way to set a name for a side too
20160904 16:09:17< vultraz> and what celmin said
20160904 16:09:28< vultraz> zookeeper: if you want that, it *CANNOT* be a key set on a per-side basis
20160904 16:09:37< zookeeper> celmin, and that feature exists so that one _can_ make A allied with B allied with C not allied with A, etc
20160904 16:09:38< celmin> It can be.
20160904 16:09:42< celmin> And is. :P
20160904 16:09:52< vultraz> but then you have all this confusion!
20160904 16:09:56< celmin> True.
20160904 16:10:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 16:10:01< vultraz> zookeeper insists that utn not be used as a side *name*
20160904 16:10:06< vultraz> which many UMC do!
20160904 16:10:12< zookeeper> why would you need to set a name for a side?
20160904 16:10:16-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 16:10:16< vultraz> *I* do it!
20160904 16:10:18< vultraz> . . .
20160904 16:10:25< celmin> zookeeper: Probably only if there's no leader, I'd guess.
20160904 16:10:31< vultraz> . . . 
20160904 16:10:34< vultraz> . . .
20160904 16:10:42< celmin> Or maybe if you temporarily change leaders but want the side name to remain consistent.
20160904 16:10:44< vultraz> .   .   .
20160904 16:10:49< vultraz> none of those :|
20160904 16:10:54< celmin> Stop ellipsing, it's not helpful.
20160904 16:10:57< vultraz> it's simply flavor 
20160904 16:11:00< celmin> Once was enough.
20160904 16:11:10< vultraz> I just mention earlier an example from my campaign
20160904 16:11:11< zookeeper> so what's wrong with side_name for that purpose?
20160904 16:11:13< tad_> And now we have side_name (from leader name) to add to the confusion. Plus all these names effect different areas of the UI .. and it's all about "This is the string to display" and has NOTHING to do with how things work internally
20160904 16:11:21< vultraz> zookeeper: because it was just introduced??
20160904 16:11:31< zookeeper> vultraz, so in other words the problem has just been solved?
20160904 16:11:47< celmin> But side_name replaces the leader name in stats and similar places.
20160904 16:11:49< vultraz> no, because apparently this new key doesn't do what it's supposed to do
20160904 16:12:01< vultraz> or is expected to do
20160904 16:12:03< zookeeper> well then, let's talk about what it should do and how it doesn't, right now
20160904 16:12:07< zookeeper> not about team names
20160904 16:12:11< celmin> Yes, that would be a great idea.
20160904 16:12:31< celmin> It would also be a great idea to follow tad_'s suggestion.
20160904 16:12:47< tad_> A design document?
20160904 16:12:59< celmin> *nod* Draw up a design document about how all this should work, get it all figured out, then work on implementing it.
20160904 16:13:20< tad_> Yes. Helps to know where you want to end up before you start driving.
20160904 16:13:26< celmin> In particular, there seem to be conflicting expectations here.
20160904 16:13:27< vultraz> I proposed earlier this: * side_name be used as  user_team_name is now, and can be used as a flavor name. * user_team_name be used as a consistent identifier for the team. But I also suggested moving utn somewhere where it cannot be overridden on a per-side basis
20160904 16:13:33< tad_> Especially since we have so many people at the wheel ...
20160904 16:13:48< vultraz> that would satisfy both parties
20160904 16:14:14< vultraz> zookeeper would be happy since utn would be consistent, and I would be happy since sides can still specify a flavor name
20160904 16:14:15< celmin> BTW, where exactly is side_name currently shown?
20160904 16:14:21< vultraz> and keys would be renamed, of course
20160904 16:14:25 * tad_ has a feeling [team] is going to become a requirement ...
20160904 16:15:31< tad_> All I care about is that *some* variable give me control of what I see on Menu|Statistics and *some*other* variable give me control of what I see on Menu|Status Table.
20160904 16:15:43< zookeeper> the only thing i find confusing is why anyone is confused about team_name and user_team_name, when they're completely simple and straightforward as far as i can see.
20160904 16:15:51< tad_> Each UI element needs a string to display, and the designer needs full control.
20160904 16:16:45< tad_> zookeeper: The only confusion between team_name (an internal key, not translatable) and user_team_name (a user-visible, translatable string) and the similarity in naming.
20160904 16:17:08< vultraz> we can rename team_name to team_id
20160904 16:17:15< vultraz> and in fact should
20160904 16:17:34< tad_> vultraz: sure .. but changing user_team_name to team_name was where you went wrong, before ...
20160904 16:17:35< zookeeper> tad_, s/and/is?
20160904 16:17:41< vultraz> yes
20160904 16:17:44< vultraz> we will not do that again
20160904 16:18:12< vultraz> tad_: then again, if we introduce [team] we won't need to, as we can just use id and name :)
20160904 16:18:25< celmin> vultraz: Is team_id the right choice when it's a list?
20160904 16:18:36< vultraz> celmin: this is to be considered
20160904 16:18:50< vultraz> what would be the proper interface for defining alliances
20160904 16:19:22< zookeeper> tad_, i don't see what's confusing about it when that's exactly what they're supposed to be; the internal team identifier and its user-visible counterpart.
20160904 16:19:33< zookeeper> they're not intended to be anything else
20160904 16:19:42< celmin> Note that [team] does pose the (possibly minor) problem that suddenly you can't do what TSG does with the bandits/undead.
20160904 16:20:04< celmin> Also the more significant problem of how to display the team of sides that are on multiple teams.
20160904 16:20:32< vultraz> celmin: what does it do with bandits/undead?
20160904 16:20:50< vultraz> zookeeper: if that's all they are then don't insist utn must match team_name
20160904 16:21:05< zookeeper> vultraz, why?
20160904 16:21:22< tad_> The confusion to which I refer is that, in MP, after it randomized the sides, it says (or said, if 766 goes in) "Take the random now-first side for each team_name and use the user_team_name for all other sides which randomly follow usingthe same team_name" 
20160904 16:21:23< vultraz> because it's very often not used as such
20160904 16:21:39< celmin> vultraz: Same team, different user_team_name
20160904 16:21:49< vultraz> yes
20160904 16:22:08< zookeeper> vultraz, well duh, it's their problem then
20160904 16:22:22< vultraz> it's not a problem
20160904 16:22:25< vultraz> it's a legit usage
20160904 16:22:30< tad_> Seems to me that if MP has 1/A/"A" 2/A/"B" and 2/A/"C" you randomly end up with all 3 sides showing randomly "A", "B", or "C" and "Don't do that" is not a good rule.
20160904 16:22:35< vultraz> how is it now I'm the one defending umc choice? :|
20160904 16:23:10< zookeeper> i'm all for your ability to make your utn's be whatever you want
20160904 16:23:23< zookeeper> just don't use that as an argument for changing how it should work
20160904 16:23:30< tad_> zookeeper: Oh, good.
20160904 16:23:55< zookeeper> i mean if you want to implement [team] tags or something then that's fine
20160904 16:24:14< vultraz> maybe tad_'s fix is all we need
20160904 16:24:28< vultraz> but you were just complaining the other day that the status table had no indication of allegiance 
20160904 16:24:34< vultraz> zookeeper, that is
20160904 16:24:37< zookeeper> you already know the only thing i'm in strict opposition to: breaking existing code
20160904 16:24:40< celmin> I think [team] tags would be most easily implemented as a simple shorthand for team_name and user_team_name.
20160904 16:24:58< tad_> Well, it fixes the SP issue that what you see after end-scenario is different than what you see if you load-scenario. If it don't make the screen, I don't really care ...
20160904 16:25:23< celmin> Though that's probably an insufficient implementation really.
20160904 16:25:36< celmin> So I guess we should just merge tad_'s PR now, right?
20160904 16:25:53< tad_> First issue is to define 'team' because we have several ...
20160904 16:26:18< zookeeper> vultraz, i thought i was clear that i realized it wasn't actually an issue after all
20160904 16:26:20< tad_> We should gfgtdf a final check chance. Ask him to merge it if he's happy now
20160904 16:27:03< celmin> tad_: Several? I can only think of two.
20160904 16:27:22< celmin> In the C++, it's a side. In the WML, it's an "alliance" of sides.
20160904 16:27:47< tad_> And MP has human teams we probably want to think about.
20160904 16:27:56< celmin> Hm?
20160904 16:28:04< celmin> Isn't that the same as the second definition?
20160904 16:28:19< zookeeper> team_name is the team identifier(s). user_team_name is what should be shown to the user regarding that side's team(s). if you need to name sides in addition to that or do other sorts of fanciness, then those are missing features that you're welcome to add.
20160904 16:28:46< tad_> You-and-me against zookeeper-and-vultraz and we'll use "random sides" and ignore the WML/engine 'team' ...
20160904 16:29:03< vultraz> zookeeper: ok, then in which case tad_'s pr is the fix to the status quo
20160904 16:29:23< celmin> Pretty sure that uses team_name.
20160904 16:30:00< tad_> I **HOPE** .. getting there through all the global accesses and randomization ..
20160904 16:30:06< APic> ☺
20160904 16:31:06< zookeeper> now, i'm not completely sure whether tad_'s bug regarding side shuffling in MP is one which is just a bug that can/was fixed or whether it just fundamentally cannot perfectly mesh with current design of team_name/user_team_name.
20160904 16:32:01< tad_> zookeeper: "not completely sure" seems rational. But "current design" is probably the issue .. which is why I suggest a design doc.
20160904 16:32:10< zookeeper> i don't even know what the exact specs for that feature are
20160904 16:33:16< tad_> To be honest, as I read the code and traced down who whacked the variable it seemed like we have at least two concepts competing and they may mesh, or they may not.
20160904 16:33:41< tad_> Like the rule is simply "He who commits last, wins"
20160904 16:34:40< zookeeper> well it's not that rare that someone writes a new feature or changes an existing one without understanding something crucial about it which leads to subtle brokenness
20160904 16:35:30< tad_> zookeeper: nope. and looks like what happened here. hopefully I got the user-visible effect of that and we won't see more ...
20160904 16:35:36< zookeeper> tad_, could you summarize (again) what the actual remaining problem is _after_ your PR?
20160904 16:37:22< tad_> The issue to me, at this point, is gfgtdf comment about map boolean. And that he's happy with the check I added.  My concern is that my change has unknown effect on MP with or without randomization of sides.
20160904 16:37:46< tad_> Simply put: I don't use MP. 
20160904 16:38:51-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160904 16:39:05< zookeeper> ok, so no particular example
20160904 16:40:01< APic> B-)
20160904 16:40:19< tad_> zookeeper: Nope. Just noted that the randomization stuff (I think) builds a [team] (yes, like a tag) table with one entry or unique 'team_name' (source unknown but probably first-come) and uses that 'user_team_name' for all sides with that 'team_name'
20160904 16:41:19< zookeeper> why is the shuffle feature including the tn/utn in the shuffle in the first place? shouldn't it just shuffle which player gets put in control of which side?
20160904 16:41:43< zookeeper> there wouldn't be any problem if it just shuffled the players, not the actual sides
20160904 16:41:55< tad_> You'll have to ask the person who added the shuffle feature, would be my guess.
20160904 16:42:07< zookeeper> because it looks like they didn't think this through
20160904 16:42:38< tad_> Frankly, I'd have left the [scenario] config ALONE! And added a mapping-table to get a human mapped to a random human-playable-side.
20160904 16:42:54< tad_> But it re-writes the [scenario] on-the-fly, hence the confusion.
20160904 16:42:58< celmin> zookeeper: Guessing the point is to shuffle play order.
20160904 16:43:33< celmin> Though honestly, if that's so, why does it not just std::random_shuffle the teams vector and then go through and fix the side numbers?
20160904 16:44:25< tad_> It's a mess of calls down a class structure, reaches up a global(passed, common) "everything is here" structure, passing junk up, then back down and finally whacking a value.
20160904 16:45:22< zookeeper> if/because it actually shuffles the complete sides, then yes i'd certainly expect that to lead to all sorts of breakage, especially when used with scenarios beyond default multiplayer maps
20160904 16:46:08< tad_> It actually, truly re-reads (from memory) the original [scenario] removes all the [side] junk and re-writes it.
20160904 16:46:19< zookeeper> i'm not saying it's obvious how it should work, but that kind of deep-shuffling of the side data seems fundamentally too dangerous to do
20160904 16:47:40< tad_> So, all the translatable strings go back to un-translated state and have to be translated again. Other than that, I'm thinking it is part (if not all) of the memory leak Ithink I'm seeing when I play (and load over and over) for hours on end.
20160904 16:49:10< zookeeper> if you want to write a design doc, i'd very much suggest one for how the shuffle feature should work :J
20160904 16:49:23< celmin> Sounds like a good idea.
20160904 16:49:32 * tad_ runs away.
20160904 16:49:49 * celmin assumes tad_ is not the best person for that anyway.
20160904 16:50:11-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has joined #wesnoth-dev
20160904 16:50:49< tad_> It's probably a good idea. I don't have the knowledge. How about we all decide gfgtdf is da'man and dump it on him .. he's not here to run away :)
20160904 16:51:20< celmin> gfgtdf probably knows more than most of us about MP, too.
20160904 16:51:28-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 255 seconds]
20160904 16:52:09< zookeeper> i have some ideas for how it should work, but yeah i'd rather first hear the original rationale for doing it the current way
20160904 16:52:25< celmin> Who implemented it, then?
20160904 16:52:47-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160904 16:52:57< tad_> And I have some ideas and concerns but they all relate to SP and the UI/UX.  Internally, I'll deal with whatever shows up.
20160904 16:53:44< zookeeper> hmh, i thought it was a much newer feature, but it was already in 1.10
20160904 16:55:57< celmin> vultraz: Any ideas for where a grid listbox could be used?
20160904 16:56:09< vultraz> palette widget?
20160904 16:56:14-!- Kwandulin [~Miranda@p200300760F424141E56A47602F62CD03.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160904 16:56:26< vultraz> or perhaps if we need a grid display somewhere
20160904 16:56:31< vultraz> can't think where right now, though
20160904 16:56:48< celmin> I was indeed thinking of the palette widget earlier, but the question was more for a dialog where I could try it out.
20160904 16:56:56< vultraz> but like, maybe if we needed, say, a display of units in a grid
20160904 16:57:03< celmin> Hmm...
20160904 16:57:13< tad_> [inspect]?
20160904 16:57:27< vultraz> though that'd likely be a use of a palette widget
20160904 16:57:32< tad_> bunch of units in a grid there
20160904 16:57:54< celmin> Not sure if the palette could be done with a simple grid listbox.
20160904 16:58:02< celmin> Can toggle panels have more than two states?
20160904 16:58:21< tad_> preferences for loglevels?
20160904 16:58:27< zookeeper> so, considering i'm possibly not aware of the technical issues, the simple "fix" to the shuffle sides option would seem to be to just shuffle which player is assigned to which slot (ignoring players on sides with disallow_shuffle=yes).
20160904 16:58:29< celmin> The palette needs three (possibly four?) states.
20160904 16:59:06-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 16:59:20-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 16:59:23< celmin> left, right, both
20160904 16:59:46< tad_> zookeeper: That would have been my go-to design. But there may be other reasons for actually re-assigning the [side]side=N values and having to re-write because they MUST be [1..N] ordered with NO gaps.
20160904 17:01:53< zookeeper> ah, need to elaborate: shuffle which player is assigned to which slot (ignoring players on sides with disallow_shuffle=yes), retaining the players' faction choices if possible. if not possible because of faction locking or whatever, simply discard their choice.
20160904 17:01:54< vultraz> tad_: that restriction was removed, wasn't it?
20160904 17:02:34< celmin> Pretty sure it wasn't.
20160904 17:03:20< zookeeper> tad_, i don't really see any situation where shuffling the players only would result in gaps
20160904 17:03:42< tad_> vultraz: It's in the code and carefully checked .. and we crash if the rule is violated.
20160904 17:03:53< vultraz> eh?
20160904 17:04:04< celmin> zookeeper, tad_: In any case, I think shuffle sides would be better implemented after the teams are built.
20160904 17:04:06< vultraz> but why is it a necessity 
20160904 17:04:15< tad_> zookeeper: Nor I but the code checks for [1..N] and crashes to desktop if it's violated.
20160904 17:04:46< zookeeper> tad_, i'm sure wesnoth code checks for a great many things and crashes if violated
20160904 17:04:59< tad_> vultraz: there is a vector (think C-style array) which appears.
20160904 17:05:03< celmin> asserts littered everywhere
20160904 17:05:07< vultraz> :|
20160904 17:05:19< celmin> I think vultraz knows what a vector is.
20160904 17:05:26< vultraz> and yes I know what a vector is
20160904 17:05:29< zookeeper> celmin, why after teams are built?
20160904 17:05:36< celmin> Teams are a vector, so that's why the 1..N is enforced, I think.
20160904 17:06:11< vultraz> what about an std::list?
20160904 17:06:19< celmin> vultraz: Worse.
20160904 17:06:21< celmin> No indexing.
20160904 17:06:23< tad_> There are a lot of places I saw vectors which were nothing more than collections of references to searchable elements ..
20160904 17:06:24< vultraz> hm
20160904 17:07:26< vultraz> map maybe?
20160904 17:07:32< celmin> zookeeper: Because that means you don't need to modify the scenario config. Shuffle sides can probably be either std::random_shuffle and fix side numbers, or swap specific side attributes between sides.
20160904 17:07:33< vultraz> <int, team>?
20160904 17:07:38< zookeeper> why do you think it matters what the data structure is?
20160904 17:07:43< celmin> BTW there's also std::deque.
20160904 17:07:48< zookeeper> if it's a vector then it's a vector, who cares?
20160904 17:08:04< celmin> zookeeper: Well, to support gaps in the side numbering, you'd want it to be a map.
20160904 17:08:28< celmin> Although it could be done with a vector by filling those gaps with dummy null-controller teams.
20160904 17:08:40< zookeeper> well if you wish to discuss adding support for gaps, then maybe say so first? :p
20160904 17:09:08< tad_> Well, I'm betting a lot of that is junk because someone was hacking and didn't know, or didn't want to use, alternate access methods. Maybe to save a few CPU cycles, maybe just because of poor knowledge or understanding. We _are_ talking about 10+ year old code and hundreds of ppl hacking at it.
20160904 17:09:21< celmin> This might sound silly, but is there any compelling reason to support multiple sides with the same number?
20160904 17:09:42< tad_> celmin: Go to your corner!
20160904 17:09:46< celmin> XD
20160904 17:09:47< vultraz> I could have sworn we did something with [side] side=
20160904 17:09:53< vultraz> recently
20160904 17:10:02< celmin> vultraz: I think that was making it fail instead of warn on gaps.
20160904 17:10:04< zookeeper> celmin, shame on you for thinking such a thought
20160904 17:10:27< celmin> Yeah okay.
20160904 17:10:47< celmin> Speaking of sparse arrays, damage prediction.
20160904 17:10:47< tad_> I know, I know! Let's add a non-translatable "side_key" and add to the confusion!
20160904 17:10:51< celmin> Haha
20160904 17:11:04< zookeeper> well, the only thing that comes to mind is as part of some kind of hack to let two players control what would otherwise appear as a single side, but... uh, that seems completely arbitrary and kind of useless.
20160904 17:11:26 * zookeeper goes to pick some apples for a moment
20160904 17:11:38< tad_> zookeeper: hush or some UMC author will start demanding we add it!
20160904 17:12:23< celmin> zookeeper: And nore(?) is working on a proper way for two players to control a single side, anyway.
20160904 17:13:19< vultraz> we don't have to acquiesce to every umc demand 
20160904 17:13:27< nore> celmin: I am indeed trying to do that, but there still are problems
20160904 17:13:47< tad_> celmin: That's easy. Write a DDoS version of the engine and randomly send packets to every MP thread on the server ... "I did NOT move there!" "Well, someone did, deal with it!"
20160904 17:14:20-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20160904 17:14:37-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160904 17:16:07< tad_> nore: seems to me you're going to have a lot of race conditions, and have to deal with all sorts of network issues like dropped sessions. Sounds like a mess, to me.
20160904 17:17:03< nore> tad_: no, players share control by choosing which player controls and willfully giving control to the others
20160904 17:17:57< tad_> nore: Ah, so it's more "Here, I have to go, take over for me." ???
20160904 17:18:21< nore> Yeah, but not quite
20160904 17:18:24< celmin> From what I understand, it enables them to take turns controlling, one yielding to the other as desired.
20160904 17:18:28< vultraz> eh, why not concurrent control?
20160904 17:18:31< tad_> nore: That's probably do-able.
20160904 17:18:44< nore> Both players can view the controlled side, discuss strategy, etc
20160904 17:18:56< nore> But only one player gets to make the moves
20160904 17:19:34-!- irker203 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160904 17:19:47< vultraz> yes, why not all controlling players
20160904 17:19:51< tad_> nore: So then, you just have to deal with when that player losses connectivity .. either some means for the other(s) to take over or simply kill the game
20160904 17:20:28< nore> Yeah
20160904 17:20:38< nore> The others get to control
20160904 17:20:55< nore> And other problem is to share undoable moves
20160904 17:21:45< celmin> vultraz: Concurrent is pretty hard, you'd have to have OOS resolution.
20160904 17:21:56< vultraz> ;_;
20160904 17:22:06< vultraz> another thing we don't have
20160904 17:22:40< celmin> Maybe a simple OOS resolution would be possible… in the event of OOS, ask the host for the correct value...
20160904 17:22:57< celmin> No idea if that'd work though.
20160904 17:23:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 17:23:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 17:23:15< tad_> celmin: "There be dragons!" .. race conditions abound 
20160904 17:23:53< celmin> So I just discovered that generators don't implement create_walker.
20160904 17:23:56< celmin> I should fix this.
20160904 17:24:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 17:24:18< tad_> And I should get back to tracking down that [modify_side][ai] crash ...
20160904 17:28:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 17:36:07-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160904 17:39:26< celmin> What is HAVE_FRIBIDI
20160904 17:40:14< celmin> font.cpp:632 is using a deprecated function
20160904 17:40:17< celmin> Can anyone fix that?
20160904 17:41:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160904 17:42:10< vultraz> not me
20160904 17:43:54< vultraz> I wonder if I should just create another helper class like tgroup
20160904 17:43:58< vultraz> for this
20160904 17:44:03-!- fabi [~fabi@176.0.22.31] has quit [Ping timeout: 240 seconds]
20160904 17:46:26< vultraz> it needs to be used with both tinteger_selector_ and tselectable_..
20160904 17:50:04< celmin> Well, I think it needs to be linked to callback state change in order to work. Which is a problem.
20160904 17:50:26< vultraz> why?
20160904 17:50:34< vultraz> why not event::NOTIFY_MODIFIED?
20160904 17:50:39< celmin> Because there's only one state change callback per widget.
20160904 17:50:44< celmin> Of course, that event would work too.
20160904 17:51:13< celmin> Do tslider, ttoggle_button, ttoggle_panel, tmenu_button all trigger NOTIFY_MODIFIED?
20160904 17:51:47< vultraz> I have no idea
20160904 17:52:04< celmin> Grep to the rescue? :P
20160904 17:52:10< vultraz> one would thin the dispatcher would handle every event :|
20160904 17:52:14< vultraz> like uh whatdoyoucallit
20160904 17:52:16< vultraz> um..
20160904 17:52:16< celmin> That's only four files to serach, even.
20160904 17:52:20< vultraz> monitor?
20160904 17:52:24< celmin> I'm talking about triggering, not handling.
20160904 17:52:40-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160904 17:53:13< vultraz> scrollbar does..
20160904 17:53:29< vultraz> text does..
20160904 17:53:36< vultraz> and tlist..
20160904 17:53:38< vultraz> :|
20160904 17:54:35< celmin> When?
20160904 17:54:39< celmin> In set_value or something?
20160904 17:54:47< vultraz> why do not all widgets fire a MODIFIED event when their state changes..
20160904 17:54:49< celmin> ^something similar
20160904 17:54:55< celmin> Oversight maybe?
20160904 17:54:55< vultraz> celmin: scrollbars is when position changes..
20160904 17:55:23< vultraz> ttext, when you change anything in the textbox
20160904 17:55:24< celmin> I think the MODIFIED event may be less fine-grained than the state change callback though.
20160904 17:55:28< celmin> Not entirely sure.
20160904 17:55:39< celmin> Oh, so when you type something.
20160904 17:55:56< celmin> BTW, do text boxes internally support tab-complete?
20160904 17:56:03< celmin> I noticed the internally support history.
20160904 17:56:08< celmin> ^they
20160904 17:56:09< vultraz> not sure
20160904 17:56:13< vultraz> i know the lobby chatbox does
20160904 17:56:22< celmin> Lua console does, as I recall.
20160904 17:56:30< celmin> Actually...
20160904 17:56:55< celmin> Some API things are nearly-empty tables with a metatable. It'd be nice if tab-complete could work with those.
20160904 18:00:10< vultraz> hm
20160904 18:00:25< vultraz> tfield_bool actually takes a callback_change function..
20160904 18:00:34< vultraz> this is... interesting..
20160904 18:00:44< vultraz> I shall need to ponder this
20160904 18:04:04< celmin> But for sliders it should be tfield_integer, right?
20160904 18:04:13< celmin> Hmm...
20160904 18:04:25< celmin> Would that actually work though?
20160904 18:04:47< vultraz> perhaps we should be extending tfield_integer
20160904 18:04:52< vultraz> instead of tfield_label?
20160904 18:04:54< celmin> Do fields track their linked widget?
20160904 18:05:04< vultraz> no
20160904 18:05:11< vultraz> that's the problem
20160904 18:05:12< vultraz> well...
20160904 18:05:27< celmin> Well, the difference between what you want and tfield is that you need two widgets, while tfield links a widget with a variable or get/set callback pair.
20160904 18:05:28< vultraz> if you call get_widget_value it updates the field
20160904 18:05:49< vultraz> yes, this is tue..
20160904 18:05:58< vultraz> perhaps I can pass a function to register_integer..
20160904 18:06:11< celmin> The function would be something that sets the label.
20160904 18:06:18< vultraz> but then again, I cannot do that in preshow :|
20160904 18:06:35< vultraz> needs to be before preshow
20160904 18:06:37< celmin> However, the problem is that (according to you), fields don't actually track their widget in real time.
20160904 18:06:37< vultraz> unless...
20160904 18:06:41< vultraz> I use the old register_label..
20160904 18:06:52< vultraz> then pass another argument to register_integer..
20160904 18:06:57< celmin> It doesn't need to be before preshow if it only relies on the label's ID.
20160904 18:07:03< celmin> I mean in preshow.
20160904 18:07:15< celmin> (That's how fields work anyway, right?)
20160904 18:07:38< vultraz> fields are initialized before pre_show is fired
20160904 18:08:31< vultraz> tfield bool binds a set_callback_state_change call to the field's widget
20160904 18:08:36< vultraz> if we can do that with tfield integer..
20160904 18:08:54< vultraz> we then just need a widget to set
20160904 18:08:57< celmin> Wait, tfield binds a state change callback?
20160904 18:09:03< vultraz> no
20160904 18:09:03< celmin> This is slightly dangerous. :(
20160904 18:09:06< vultraz> tfield_bool
20160904 18:09:22< celmin> Well, I guess it could be easily added to tfield_integer though, right?
20160904 18:09:26< vultraz> I think so
20160904 18:09:28< celmin> Assuming tinteger_selector has one.
20160904 18:09:43< celmin> (And of course if it doesn't that could be added, probably without much difficulty.)
20160904 18:10:06< vultraz> only problem is that tfield_integer doesn't have an implementation
20160904 18:10:23< celmin> Yes it does.
20160904 18:10:52< celmin> The default implementation, to be specific.
20160904 18:11:01< vultraz> I see
20160904 18:11:12< vultraz> but we need a custom implementation
20160904 18:11:19< celmin> Do we?
20160904 18:11:37< vultraz> if we want to be able to pass a callback function, yes
20160904 18:11:44< vultraz> unless...
20160904 18:11:52< vultraz> I have an idea..
20160904 18:11:56< celmin> Well, what happens if you add the callback stuff to the default implementation?
20160904 18:11:56< vultraz> blah
20160904 18:11:58< vultraz> wait
20160904 18:12:03< celmin> Just try it quickly and see if it compiles.
20160904 18:12:04< vultraz> yeah I could.. do that
20160904 18:12:42< vultraz> oh curses
20160904 18:12:43 * celmin could try it but is in the middle of adding override annotations to various places that clang 3.8 warned about.
20160904 18:12:51< vultraz> set_callback_state_change is exclusive to tselectable_ :|
20160904 18:12:57< vultraz> mutter mutter
20160904 18:13:09-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 18:13:21< celmin> Well, you could…
20160904 18:13:23-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 18:13:27< celmin> 1. Add it to tinteger_selector.
20160904 18:13:45< celmin> 2. Move it to a new base class that both tinteger_selector and tselectable_ extend.
20160904 18:13:55< celmin> 3. Merge tinteger_selector and tselectable_.
20160904 18:14:09< celmin> Not all of those options are necessarily good ones.
20160904 18:14:16< celmin> They're just things that popped into my head.
20160904 18:14:17< vultraz> 1 is simplest
20160904 18:14:22< celmin> Yeah, it is indeed.
20160904 18:14:45< celmin> Obviously that means you need to add it to tslider as well.
20160904 18:15:49< vultraz> I really wish we had anura's prototype system right now >_>
20160904 18:16:38< celmin> I have no idea what you're talking about.
20160904 18:16:48< celmin> Is it something like JS/Lua prototypes?
20160904 18:17:06-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160904 18:17:09< celmin> (Well, Lua calls them metatables, but very similar concept.)
20160904 18:17:31< celmin> (Though actually, does Lua check metatables recursively?)
20160904 18:18:07< vultraz> basically, you can set an object as a prototype of another and it inherits all its members, except ones you override.
20160904 18:18:14< celmin> So that's a yes.
20160904 18:18:19< celmin> I want that too, for units.
20160904 18:18:37< celmin> That's exactly how JS prototypes / Lua metatables work.
20160904 18:19:40-!- Kwandulin [~Miranda@p200300760F42414129F542709518F4A2.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160904 18:22:06< JyrkiVesterinen> Yes, Lua does check metatables recursively.
20160904 18:22:38< JyrkiVesterinen> I have worked on two mobile games written almost entirely in Lua. We had even fairly deep Lua "class" hierarchies in some places.
20160904 18:23:54< celmin> I wrote a game in JS using prototypes for something very similar to what I want to do with units here.
20160904 18:24:23< celmin> Specifically, each item instance set the item definition as its prototype, and the item definition set the base Item "class" as its prototype.
20160904 18:25:02< celmin> I think the Item "class" also had a "base class" Entity or something.
20160904 18:30:23< vultraz> ok so tfield_bool is.. tfield<bool, tselectable_>
20160904 18:30:36< vultraz> tfield_integer is tfield<int, tinteger_selector_>..
20160904 18:30:53< vultraz> and tfield is template <class T, class W, class CT>
20160904 18:31:08< vultraz> so I guess I can cast to W*?
20160904 18:31:15< celmin> Probably?
20160904 18:32:10< celmin> I actually think that maybe tmenu_button should not be tselectable_, and the latter should only handle binary-state widgets.
20160904 18:32:39< celmin> On the other hand… it doesn't make sense for tmenu_button to be a tinteger_selector (since it doesn't support setting min/max).
20160904 18:33:54< zookeeper> for reference: the shuffle sides option was added in https://github.com/wesnoth/wesnoth/commit/22243cb1ba92d
20160904 18:34:02 * celmin pokes gfgtdf about PR 766.
20160904 18:34:17< celmin> I have no idea who that even is.
20160904 18:34:33< celmin> And his avatar is OOTS.
20160904 18:34:35< vultraz> oh yeah, zaroth
20160904 18:34:37< vultraz> I remember him
20160904 18:34:44< vultraz> he's the original 
20160904 18:34:51< celmin> "original"?
20160904 18:34:52< vultraz> "unify sp and mp" guy
20160904 18:34:55< celmin> Ah.
20160904 18:35:03< vultraz> he had ambitious plans
20160904 18:35:04< celmin> Did you accidentally hit enter there?
20160904 18:35:10< vultraz> including mp playing of sp games
20160904 18:35:12< vultraz> and stuff
20160904 18:35:13< vultraz> and yes
20160904 18:35:27< vultraz> i guess in the end we kinda got that with RiftWalker
20160904 18:35:33< zookeeper> celmin, who?
20160904 18:35:51< celmin> zookeeper: Zaroth, and also "quetzalcoatl".
20160904 18:35:52< gfgtdf> i actuall see no reason why it shodul be impossible to play sp games on the server, but on the other hand ai alos dont see a readon why peopel woudl want that.
20160904 18:36:07< zookeeper> celmin, right
20160904 18:36:14< gfgtdf> celmin: what is with that pr ?
20160904 18:36:19< celmin> gfgtdf: There's no strong reason why it should be impossible and no strong reason why it should be possible.
20160904 18:36:24< celmin> gfgtdf: Can we merge that PR?
20160904 18:36:46< celmin> So the experimental lobby already existed that long ago, huh...
20160904 18:37:32< gfgtdf> celmin: hmm well i dont see a reason against mergign that pr but i think we shodul also fix those scnearios to use better user_team_name attributes
20160904 18:38:11< celmin> Maybe. Since you have no reason against it though, I'll go ahead and do it (unless you want to be the one to do it).
20160904 18:38:34< gfgtdf> celmin: the erros he gets indicates that theose scnairo have sides with the same team_name but differet user_team_name.
20160904 18:39:12< celmin> It should still be consistent though.
20160904 18:39:39< celmin> Either the first user_team_name for a team_name should always take priority (probably bad), or the given user_team_name should always be used.
20160904 18:39:45< celmin> Rather than sometimes one and sometimes the other.
20160904 18:41:42< celmin> So...
20160904 18:41:56-!- louis94 [~~louis94@91.178.242.195] has joined #wesnoth-dev
20160904 18:42:04< celmin> Side shuffle and random FLG need to resolved before converting the level to a gamestate?
20160904 18:42:18< celmin> I'm guessing converting the level to a gamestate is where the team builder comes into play.
20160904 18:42:27< zookeeper> gfgtdf, any chance you might want to look into re-writing/fixing/something the "shuffle sides" option?
20160904 18:42:40< zookeeper> the shuffling logic itself, that is
20160904 18:42:58< gfgtdf> zookeeper: i am not aware of bug in the shuffle sides option
20160904 18:43:30< celmin> ...
20160904 18:43:41< zookeeper> we talked about it a lot just a few hours ago. basically as far as i can tell, the problem is that it actually shuffles the side data instead of just shuffling which player is given control of which side.
20160904 18:43:46< gfgtdf> zookeeper: except http://gna.org/bugs/?23650 that is
20160904 18:45:05< gfgtdf> zookeeper: well shuffle sides is an option designed for mp games, you it keep the playes with theor assocuated faction (this imples recuitlist etc) but siignes diferent starting opsitions to them
20160904 18:45:07< celmin> Fisher-Yates shuffle, huh.
20160904 18:45:58< gfgtdf> zookeeper: it rather complated last time  i looked at this, but i dont think its related to the team name issues.
20160904 18:46:42< zookeeper> gfgtdf, i take that as a "no i don't know why it was originally written to work in such a seemingly crazy manner" :p
20160904 18:48:42< Ravana_> if it should only change starting locations, then it could be done as [modification]
20160904 18:49:03< Ravana_> I don't think any is included with core currently
20160904 18:49:32< gfgtdf> zookeeper: it places the players (together with their factions) randomly on the given starting locations.
20160904 18:50:01< zookeeper> gfgtdf, well tad claimed it did much more deep shuffling of the side data
20160904 18:50:02< gfgtdf> Ravana_: well not only startign position but everythign associated to it like startign village control etc.
20160904 18:50:42< zookeeper> <tad_> It actually, truly re-reads (from memory) the original [scenario] removes all the [side] junk and re-writes it.
20160904 18:52:00< zookeeper> so, presumably, if you save the game the [side]s will actually be in the shuffled order, not the original. only with the side numbers (and maybe something else) changed.
20160904 18:53:53< gfgtdf> hmm yes i don't know why it was originally written to work in such a seemingly crazy manner
20160904 18:53:59< zookeeper> ok :P
20160904 18:54:38< celmin> gfgtdf: Firstly, tad confirmed that it is related to the team name issues. :P
20160904 18:55:10< gfgtdf> celmin: how did he so that?
20160904 18:55:16< celmin> Debugging.
20160904 18:55:21< zookeeper> surely it would be so much simpler and safer to just shuffle the players, not the actual sides. of course there's some extra considerations (like if you give one player different starting gold, should that be for the player or for the side?).
20160904 18:55:30< gfgtdf> celmin: more details please
20160904 18:55:34< celmin> gfgtdf: Secondly, would simply reordering the teams vector (and fixing side numbers) satisfy the requirement of shuffle sides? Or would that shuffle too much?
20160904 18:55:41-!- fabi [~fabi@176.0.22.31] has joined #wesnoth-dev
20160904 18:56:02< celmin> gfgtdf: It'd be better to ask him for the details, but he spent a lot of time tracking down where user_team_name was being overwritten and came up with that PR, so...
20160904 18:56:48< gfgtdf> celmin: well i see that pr and te function hwer eis is oiverridden is side_engine::new_config which woudl be teh same evne if we didnt have teh shuffle sides feature
20160904 18:57:05< celmin> Huh?
20160904 18:58:08< celmin> Hmm, what is a connect::side?
20160904 18:58:09< gfgtdf> abotu shuffle sides: i perosnalyl think it woudl make most sense if we just moves the players (and assicated factiosn) around and leave the rest intact
20160904 18:58:35< gfgtdf> i actuall think we have alreada  fcuntion for that (side_engine::swap_sides_on_drop_target)
20160904 18:58:45< celmin> I get the impression that that's exactly what happens in the original config that zookeeper linked...
20160904 18:59:00< gfgtdf> tht is used by the 'drag adn drop' feature of the gui1 mp connect ui
20160904 18:59:04< celmin> No idea what the current state of the feature is though, maybe it has changed greatly since then.
20160904 18:59:19< gfgtdf> so i wonde why teh shuffle sides feature doesnt use it
20160904 18:59:53< celmin> gfgtdf: Maybe shuffle sides needs to be resolved before side_engines are initialized?
20160904 18:59:55< celmin> I dunno.
20160904 19:01:11< gfgtdf> celmin: no shzuffle sides actuall operates on side negine objects, see this code: https://github.com/wesnoth/wesnoth/blob/master/src/game_initialization/connect_engine.cpp#L449
20160904 19:01:56< celmin> Ah, okay, it has changed quite a bit then, though it appears the basic concept is the same.
20160904 19:02:45< celmin> gfgtdf: Is the line 423 TODO doable now?
20160904 19:03:41< gfgtdf> celmin: well i code wasnt really changed since that comment was written i'd guess
20160904 19:04:04< gfgtdf> celmin: but of could this can be fixed somehow.
20160904 19:04:13< celmin> I guess side_engine is basically what connect::side was back in 1.10.
20160904 19:04:43< gfgtdf> celmin: although it mostlikeley not reall important since the 'random faction' is a 'mp maps' only feature where nontrivial temas are quite rare.
20160904 19:04:57-!- irker195 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160904 19:04:57< irker195> wesnoth: Gregory A Lundberg wesnoth:master 2ecacdf5fed7 / src/game_initialization/connect_engine.cpp: Fix bug: user_team_name is wrong https://github.com/wesnoth/wesnoth/commit/2ecacdf5fed7644272dd29a61c914974b12cdd3a
20160904 19:04:57< irker195> wesnoth: Celtic Minstrel wesnoth:master 5141021234b7 / src/game_initialization/connect_engine.cpp: Merge pull request #766 from GregoryLundberg/GL_fix_user_team_name https://github.com/wesnoth/wesnoth/commit/5141021234b7c2ad5449eaee0a799db8d4916e50
20160904 19:05:07-!- iceiceice [~chris@pool-71-172-187-9.nwrknj.east.verizon.net] has joined #wesnoth-dev
20160904 19:05:08-!- iceiceice [~chris@pool-71-172-187-9.nwrknj.east.verizon.net] has quit [Changing host]
20160904 19:05:08-!- iceiceice [~chris@unaffiliated/iceiceice] has joined #wesnoth-dev
20160904 19:05:12< celmin> Maybe, but I think it'd be good to cover the edge cases anyway.
20160904 19:06:03-!- fabi [~fabi@176.0.22.31] has quit [Ping timeout: 240 seconds]
20160904 19:12:16< zookeeper> the current method seems (i didn't check) like it'd retain alliances and only the order of sides changes, whereas simply shuffling players wouldn't, but i don't know if anyone would care.
20160904 19:13:28< celmin> I still don't quite understand the intended behaviour of shuffle sides.
20160904 19:14:19< zookeeper> seems like it's to simply shuffle the sides
20160904 19:14:48< celmin> But somehow it's not obvious what is meant by that.
20160904 19:15:52< zookeeper> the same thing as if you took the turn 1 autosave, shuffled the [side] blocks and re-numbered them accordingly, i think.
20160904 19:27:40-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has quit [Remote host closed the connection]
20160904 19:34:29-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 258 seconds]
20160904 19:37:50< gfgtdf> vultraz: the loadgame dialog now shows a listbox the the leaders in the panel, is this intentioal?
20160904 19:41:11-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 19:41:13< vultraz> yes
20160904 19:41:25< vultraz> human-controlled leaders
20160904 19:41:41-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160904 19:42:25-!- louis94 [~~louis94@91.178.242.195] has quit [Ping timeout: 252 seconds]
20160904 19:44:41< vultraz> gfgtdf: preferably it wouldn't use a toggle panel but we dont have support for lists without toggle panels since tlist was never complated
20160904 19:45:00< vultraz> so i made it at least not select an option by default
20160904 19:46:11-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160904 20:01:29< celmin> What's the problem with it not using a toggle panel?
20160904 20:01:35< celmin> ^with it using
20160904 20:01:52-!- iceiceice [~chris@unaffiliated/iceiceice] has quit [Quit: Ex-Chat]
20160904 20:05:05-!- JyrkiVesterinen [~JyrkiVest@87-92-34-149.bb.dnainternet.fi] has quit [Quit: .]
20160904 20:08:24< irker195> wesnoth: Celtic Minstrel wesnoth:master 39a6726516db / src/ (8 files in 3 dirs): Enable tests for tooltips and several previously excluded dialogs https://github.com/wesnoth/wesnoth/commit/39a6726516dba7607a895c58a3ea911493cf6c36
20160904 20:08:26< irker195> wesnoth: Celtic Minstrel wesnoth:master 0b15dfd0fc72 / src/ (28 files in 9 dirs): Add many missing override annotations https://github.com/wesnoth/wesnoth/commit/0b15dfd0fc725f367ae91f58bbfdc17c62e39372
20160904 20:19:32-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160904 20:19:38-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160904 20:22:24-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160904 20:36:32-!- Kwandulin [~Miranda@p200300760F42414129F542709518F4A2.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160904 20:39:54-!- louis94 [~~louis94@91.178.242.195] has joined #wesnoth-dev
20160904 20:50:49-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160904 21:00:39-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160904 21:02:56< celmin> So I have downloaded clang 3.9 from the website. I confirmed it has the asan dylib, so hoping that it'll work with scons. Not gonna try right now though.
20160904 21:03:12< celmin> (Hopefully I don't have to actually compile it myself to get it to work on my old OS.)
20160904 21:04:05-!- markus__ [~mjs-de@x5ce33565.dyn.telefonica.de] has quit [Remote host closed the connection]
20160904 21:09:22-!- fabi [~fabi@176.0.22.31] has joined #wesnoth-dev
20160904 21:11:37-!- gfgtdf [~chatzilla@x4e369225.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20160904 21:13:46-!- stikonas_ is now known as stikonas
20160904 21:15:02< celmin> Does anyone think it's worth making all table-like userdatas iterable?
20160904 21:15:12< celmin> For example, units and sides.
20160904 21:15:32< celmin> (This is in Lua, if the word "userdata" failed to make that clear.)
20160904 21:26:30< vultraz> [07:01:28]	celmin	What's the problem with it not using a toggle panel?
20160904 21:26:36< vultraz> because it should not use a toggle panel
20160904 21:26:57< vultraz> this is a case where you want a visual list only
20160904 21:27:27< celmin> Why not? Given that you can just force no selection?
20160904 21:27:32< vultraz> I cannot
20160904 21:28:47< vultraz> I said I can force no *initial* selection
20160904 21:30:06< vultraz> ie, has_minimum = false
20160904 21:31:37< vultraz> I'm going to give tinteger_selector a custom implementation
20160904 21:31:46< celmin> ?
20160904 21:32:15< vultraz> ie, not make callback functions a base-tfield thing
20160904 21:32:40< celmin> I don't know what you're talking about.
20160904 21:32:44< celmin> Oh, wait.
20160904 21:32:50< celmin> Um, is there any other instantiation though?
20160904 21:32:56< vultraz> sorry I mean tfield_integer
20160904 21:33:00< celmin> I'm guessing not.
20160904 21:34:39< celmin> Just, what's the point of having the default implemetation if nothing uses it?
20160904 21:35:03< vultraz> I'm not sure what you mean
20160904 21:35:10< celmin> ^implementation
20160904 21:35:17< celmin> The default definition of tfield.
20160904 21:35:28< vultraz> Don't ask me
20160904 21:35:44< celmin> I forget, are tfield_bool and tfield_label a specialization or a subclass?
20160904 21:36:37< vultraz> all former
20160904 21:38:07< celmin> I've written a concept of my Lua-formula bridge idea. Maybe that'll help me figure out the implementation.
20160904 21:38:22< celmin> I can show you if you want.
20160904 21:38:59< vultraz> eh what /
20160904 21:39:01< vultraz> ?
20160904 21:39:28< celmin> Basically a way to implement WFL functions in Lua.
20160904 21:39:47< vultraz> I see
20160904 21:41:00< celmin> Do you want me to show you? Input might be nice.
20160904 21:41:19< vultraz> sure
20160904 21:43:09< celmin> http://celmin.pwcsite.com/wesnoth/lua_wfl_bridge_concept.lua
20160904 21:43:16< celmin> Is that fine or should I also pastebin?
20160904 21:43:29< celmin> Geh.
20160904 21:43:49< vultraz> The requested URL /wesnoth/lua_wfl_bridge_concept.lua was not found on this server.
20160904 21:43:52< celmin> …it's not there yet, apparently. :|
20160904 21:44:12< celmin> Bah.
20160904 21:44:35< celmin> I'm sure it'll appear… eventually…
20160904 21:44:55< celmin> If not I'll have to kill it. :/
20160904 21:45:00< celmin> The text editor, I mean.
20160904 21:45:20< vultraz> #JustCelmin'sComputerThings
20160904 21:45:27< celmin> What.
20160904 21:47:28< celmin> (I expected it to take mere moments to upload, but I guess swap got in the way or something.)
20160904 21:48:07< vultraz> ah there it is
20160904 21:48:52< celmin> It's not the intent of it, but this (along with some additional support in the Lua AI engine) would allow the entire FormulaAI engine to be implemented in Lua.
20160904 21:50:08< vultraz> interesting
20160904 21:50:43< vultraz> this is interesting
20160904 21:50:46 * celmin fixes line 21.
20160904 21:51:05< vultraz> you would still keep the wml, yes?
20160904 21:51:10< celmin> The what?
20160904 21:51:29< vultraz> wfl*
20160904 21:51:52< celmin> I'm not quite sure what you're asking, but removing WFL is not on the table.
20160904 21:52:11< celmin> Does it make sense? Maybe I should've added more explanatory comments.
20160904 21:52:17< vultraz> that is, WFL would call this lua implementation?
20160904 21:52:29< vultraz> and people would not use the lua directly?
20160904 21:52:40< celmin> Well, I'm not sure.
20160904 21:53:11< vultraz> it seems we should be moving towards more lua integration with WML
20160904 21:53:45< celmin> Or WFL integration with WML?
20160904 21:53:53< vultraz> Well...
20160904 21:54:14< vultraz> Then we come back to suggestion of integrating the formula engine in the config class :/
20160904 21:54:30< vultraz> But.. if we were to merge fabi's work, and could use lua anywhere...
20160904 21:54:35< celmin> Which I still think is infeasible, for the same reasons as before.
20160904 21:54:46< vultraz> it could be possible to remove WFL entirely.
20160904 21:54:53< celmin> I know fabi has done a lot of hard work on that, but I really don't see any reason to merge it.
20160904 21:55:06< vultraz> I dunno
20160904 21:55:18< vultraz> Lua anywhere is a really nice idea.
20160904 21:55:29< vultraz> But it has some shortcomings.
20160904 21:55:38< celmin> I don't much like the concept of using Lua to define the data.
20160904 21:55:48< vultraz> Neither do I
20160904 21:56:04< vultraz> even Anura keeps separate data and scripting structures.
20160904 21:56:11< vultraz> (FSON and FFL)
20160904 21:56:18< celmin> Hah.
20160904 21:56:22< celmin> I knew that wasn't FFL. :P
20160904 21:56:48< celmin> Even though some of its values obviously defined FFL functions.
20160904 21:57:06< vultraz> Yes, FFL can be used as values for FSON keys
20160904 21:57:31< celmin> So do you understand how that bridge stuff works?
20160904 21:57:40< vultraz> command: def()-> command .. stuff 
20160904 21:57:55 * celmin referring to the Lua-WFL bridge stuff.
20160904 21:58:09< vultraz> not...really
20160904 21:58:28< celmin> Should I explain, or do you have questions?
20160904 21:59:00< vultraz> and your class doesn't load again :|
20160904 21:59:05< celmin> Huh?
20160904 21:59:08< vultraz> site
20160904 21:59:10< vultraz> >_>
20160904 21:59:11< celmin> Oh.
20160904 21:59:11< vultraz> jesus
20160904 21:59:14< vultraz> too much time in c++
20160904 21:59:18< vultraz> I'm talking in programming
20160904 21:59:38< celmin> Might also be a bit slow sometimes.
20160904 21:59:54< vultraz> do you host your own server?
20160904 22:00:06< celmin> No, it's on a VPS.
20160904 22:02:13< celmin> So… should I explain, or do you have questions?
20160904 22:02:23< celmin> (I can also duplicate it to a pastebin if you want.)
20160904 22:02:31< vultraz> do explain
20160904 22:02:52< celmin> Okay, so a Lua function intended to be called form WFL needs to return two values.
20160904 22:03:10-!- fabi [~fabi@176.0.22.31] has quit [Remote host closed the connection]
20160904 22:03:53< celmin> The first is the actual value, and the second is a string indicating the type. The second may be optional if it can be deduced, but especially in the case of int vs decimal this is not possible in Lua.
20160904 22:04:47< celmin> Each argument to the function is essentially a mini-formula and can be called in the same way as a formula returned by wesnoth.compile_formula(), except that it probably won't accept passing a function table. (It'll accept an arguments table though.)
20160904 22:04:52-!- Appleman1234 [~Appleman1@KD119104114246.au-net.ne.jp] has joined #wesnoth-dev
20160904 22:05:00< celmin> Normally you'll want to call it with no arguments, but there could be exceptions.
20160904 22:05:31< celmin> A formula function has a minumum and maximum number of arguments. The implementation will inspect your Lua function to determine what the min and max is.
20160904 22:05:44< celmin> Trailing parameters whose name end with "_opt" will be considered optional.
20160904 22:06:07< celmin> If the Lua function is variadic (ie, it has … as the last pseudo-parameter), then the formula function will have no maximum number of arguments.
20160904 22:07:00< celmin> So the example functions have: exactly 0 args; exactly one arg; either 1 or two args; two or more args; and exactly two args.
20160904 22:07:18< celmin> If you called them with a different number it would be an error.
20160904 22:08:11< celmin> The function's name in WFL is basically the key containing it in the function table.
20160904 22:08:21< celmin> Is that explanation enough? Any further questions?
20160904 22:11:25< vultraz> I... se
20160904 22:11:27< vultraz> e
20160904 22:12:05< vultraz> seems staightforward
20160904 22:16:04< vultraz> blah, tfield bool is broken..
20160904 22:16:22< celmin> So no questions?
20160904 22:17:24< vultraz> not right now
20160904 22:17:30< vultraz> currently cursing at my compiler
20160904 22:19:01< celmin> I started a clean build in hopes that it would fix my bizarre crashes.
20160904 22:19:18< celmin> Not sure how likely it is, but...
20160904 22:19:25< vultraz> how the hell does something stop compling when i hasn't even changed it
20160904 22:19:55< celmin> No clue.
20160904 22:20:07< celmin> There are probably ways.
20160904 22:20:13< celmin> Especially if templates are involved.
20160904 22:20:36-!- louis94 [~~louis94@91.178.242.195] has quit [Ping timeout: 244 seconds]
20160904 22:20:42< vultraz> ..\..\src\gui\auxiliary\field.hpp|565|error: wrong number of template arguments (2, should be 3)|
20160904 22:20:50< vultraz> it was working fine with 2 before!
20160904 22:22:16< vultraz> does it not like specialization for bool vs int or something?
20160904 22:22:43< celmin> Did you change the line template<typename W, typename W, typename CT = const T>?
20160904 22:23:08< celmin> Or, are you defining a new specialization?
20160904 22:23:33< vultraz> oh yeah, I removed that..
20160904 22:23:51< celmin> Might've been a reason for it, no idea if that's gone as of C++11.
20160904 22:24:31< vultraz> how would i translate that..
20160904 22:24:41< celmin> Translate what?
20160904 22:26:36< vultraz> readding that line to fwd
20160904 22:26:44< vultraz> let's see if it builds..
20160904 22:27:12-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160904 22:27:20< vultraz> I think the point was to allow 2-argument specialization 
20160904 22:28:04< vultraz> since tfield is initialized with const T for its third template parameter 
20160904 22:29:59< vultraz> this should be made clear
20160904 22:32:11-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160904 22:33:50< vultraz> seems the note just applied to the const
20160904 22:33:58< vultraz> Note the const needs to be
20160904 22:34:00< vultraz>  *                                in the template otherwise compilation on
20160904 22:34:01< vultraz>  *                                GCC-4.3 fails (not sure whether compiler bug
20160904 22:34:03< vultraz>  *                                or not)
20160904 22:36:46-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20160904 22:41:33-!- fabi [~fabi@176.0.22.31] has joined #wesnoth-dev
20160904 22:48:48< vultraz> note to self: redo Custom TOD dialog at some point
20160904 22:48:58< vultraz> I designed it very badly.
20160904 22:49:18< vultraz> also note to self: get someone to fix that dialog not updating the tod 
20160904 22:49:54< vultraz> third note to self: why is the icon in the wesnoth notification popups blurry after the windows 10 anniversary update
20160904 22:51:51< vultraz> fourth note to self: figure out why I keep getting ads for Chevron with Techron in Pandora
20160904 22:53:36< vultraz> ok, this builds
20160904 22:55:09< vultraz> hm..
20160904 22:55:17< vultraz> so callback state change...
20160904 22:55:27< vultraz> it's actually manually fired 
20160904 22:55:29< vultraz> :|
20160904 22:56:22< celmin> Yay notes to self.
20160904 22:56:38< celmin> And yes it's manually fired by each widget that supports it, so you need to add that to tslider.
20160904 22:56:56< vultraz> I thought you just said earlier we should remove custom firings?
20160904 22:57:56< vultraz> and anywhere, where should it be handled..
20160904 22:58:39< vultraz> there isn't really a good place for it..
20160904 22:59:34< vultraz> this type of thing should be handled in tscrollbar::scroll
20160904 22:59:43< vultraz> but that doesn't inherit from integer_selector....
20160904 23:00:01< vultraz> but it does keep tslider as a friend class...
20160904 23:00:25< vultraz> so wait
20160904 23:01:08< vultraz> class b inherits from class a and class b is also a friend of class a
20160904 23:01:11< vultraz> that seems...
20160904 23:01:17< vultraz> weird
20160904 23:01:19< vultraz> ?
20160904 23:02:38< vultraz> perhaps..
20160904 23:02:44< vultraz> perhaps I need to hook into modified directly?
20160904 23:02:46< vultraz> celmin: thoughts?
20160904 23:03:53< celmin> Friendship is non-recoprocal… it does seem very weird for a derived class to be declared as a friend though...
20160904 23:06:14-!- EliDupree [~quassel@idupree.com] has quit [Ping timeout: 250 seconds]
20160904 23:06:36< vultraz> blahaaaaaaa
20160904 23:08:31< vultraz> ..\..\src\gui\core\event\dispatcher.hpp|280|note: candidate: template<gui2::event::tevent E> typename std::enable_if<gui2::event::has_key<boost::mpl::set<mpl_::int_<0>, mpl_::int_<1>, mpl_::int_<4>, mpl_::int_<6>, mpl_::int_<9>, mpl_::int_<10>, mpl_::int_<11>, mpl_::int_<12>, mpl_::int_<15>, mpl_::int_<16>, mpl_::int_<17>, mpl_::int_<18>, mpl_::int_<21>, mpl_::int_<22>, mpl_::int_<23>,...
20160904 23:08:32< vultraz> ...mpl_::int_<24> >, E>::value>::type gui2::event::tdispatcher::connect_signal(const tsignal_function&, gui2::event::tdispatcher::tposition)|
20160904 23:08:37< vultraz> oh good god
20160904 23:08:45-!- irker195 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160904 23:08:47< vultraz> ;_;
20160904 23:10:03< vultraz> what even does this code do
20160904 23:10:05< vultraz> 	template <tevent E>
20160904 23:10:07< vultraz> 	typename std::enable_if<has_key<tset_event, E>::value>::type
20160904 23:10:51< celmin> It ensures that the template is not instantiated unless has_key<tset_event, E>::value ends up being true.
20160904 23:11:29< celmin> That ends up true if E exists in the definition of tset_event.
20160904 23:11:50< celmin> You should look at the actual definition to understand it, since it uses symoblic names there rather than numbers as in the error message.
20160904 23:12:44< vultraz> sigh
20160904 23:12:47< vultraz> maybe ill ignore this
20160904 23:13:05< vultraz> celmin: where in tslider do you think wouldbe a good place to fire the callback?
20160904 23:13:22< celmin> set_value maybe? Where does ttoggle_button fire it?
20160904 23:13:38< celmin> You'd need to make sure that the value is never assigned directly except in set_value.
20160904 23:14:18< celmin> ^symbolic
20160904 23:15:08< vultraz> well there is a set_value
20160904 23:15:10< vultraz> but...
20160904 23:15:21< vultraz> that doesn't account for sliding the slider
20160904 23:16:07< celmin> Why not?
20160904 23:16:45< vultraz> slider sliding uses tscrollbar::scroll
20160904 23:16:47< vultraz> then again...
20160904 23:16:50< vultraz> hm
20160904 23:17:00< vultraz> actually, we want sliders to snap to value, right?
20160904 23:17:04< celmin> Yes.
20160904 23:17:05< vultraz> this might be an opportunity to do so...
20160904 23:17:31< vultraz> instead of handling the scroll, we calculate the mouse movement and call set_value 
20160904 23:18:50< vultraz> hmm
20160904 23:18:52< vultraz> ITEM_BACKWARDS...
20160904 23:19:27< vultraz> im thinking scrolling is actually handled by scrollbar...
20160904 23:19:50< vultraz> so maybe that wouldn't work
20160904 23:20:11< vultraz> eh for now ill just fire in handle_key_increase/handle_key_decrease
20160904 23:20:19< vultraz> sounds good enough for now
20160904 23:20:25< vultraz> and in set_value, ofc
20160904 23:27:07-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160904 23:28:39-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160904 23:45:32-!- EliDupree [~quassel@idupree.com] has joined #wesnoth-dev
20160904 23:51:31< vultraz> hm
20160904 23:51:40< vultraz> the actual interface for this comes out looking rather ugly
20160904 23:55:16-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160904 23:56:15-!- fabi_ [~fabi@176.4.56.57] has joined #wesnoth-dev
20160904 23:58:56-!- edgrey [~edgrey@178.204.115.101] has quit [Ping timeout: 244 seconds]
20160904 23:59:14< vultraz> for one, I need to register all the status labels as label fields :|
20160904 23:59:15-!- fabi [~fabi@176.0.22.31] has quit [Ping timeout: 264 seconds]
20160904 23:59:45< vultraz> oh come on...
--- Log closed Mon Sep 05 00:00:05 2016