--- Log opened Mon Sep 05 00:00:05 2016
20160905 00:00:09< vultraz> this is just ridiculous now 
20160905 00:00:24< vultraz> it always comes down to a missing twindow argument :|
20160905 00:00:47< vultraz> but how in hell am I supposed to get a twindow argument here
20160905 00:01:31 * celmin implements server magic to apply syntax colouring to the Lua file I linked earlier. :D
20160905 00:01:38 * celmin wasted way to much time on this though. >_>
20160905 00:01:41< celmin> ^too
20160905 00:01:48-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160905 00:02:11< vultraz> like, look at this lovely line (which doesn't even work)
20160905 00:02:13< vultraz> status(*label->widget(), source->get_widget_value(*dynamic_cast<twidget&>(*label->widget()).get_window()));
20160905 00:02:15< vultraz> :|
20160905 00:02:38< celmin> What does status() do?
20160905 00:02:48< vultraz> dynamic_cast<tcontrol&>(widget).set_label(value);
20160905 00:02:58< vultraz> this is way ugly
20160905 00:03:00< vultraz> I cannot use this :|
20160905 00:03:11< celmin> Is that an answer to my question?
20160905 00:03:11< vultraz> it comes down to this
20160905 00:03:17< vultraz> (yes)
20160905 00:03:32< vultraz> if I want to bind a function to these integer fields..
20160905 00:03:36< celmin> Also, deep internal stuff may often look ugly. Not much you can do, since its purpose is to make other parts of the code not ugly.
20160905 00:03:37< vultraz> it needs to be done in the constructor
20160905 00:04:02< vultraz> except the functions need stuff that isn't available until pre_show :|
20160905 00:04:04< vultraz> what do I do
20160905 00:04:08< celmin> I don't quite get what you need the window for.
20160905 00:04:23< celmin> Also, why does it need to be done in the constructor?
20160905 00:04:24< vultraz> get_widget_value finds the widget and gets its value
20160905 00:04:47< vultraz> because all fields are initialized before preshow
20160905 00:05:10< vultraz> this function isn't executed then, just bound
20160905 00:05:28< celmin> Why does that mean it needs to be done in the constructor?
20160905 00:05:51< vultraz> A. because nothing is executed between pre_show and the constructor
20160905 00:06:03< vultraz> B. even if there were, pre_show is the first function with a window parameter
20160905 00:06:26< vultraz> so in order to set up these callback functions, I need a window argument
20160905 00:06:32< celmin> Which constructor, anyway?
20160905 00:06:42< vultraz> working with tgenerator_settings right now
20160905 00:07:02< vultraz> I could really use solid advice here
20160905 00:07:38< vultraz> how do I pass a function that needs a window argument when I don't have a window argument...
20160905 00:07:44< vultraz> I guess I could std::bind..
20160905 00:07:56< vultraz> but I don't understand how that works if you placehold an argument
20160905 00:08:26< vultraz> does that mean you can never use that argument?
20160905 00:09:38< vultraz> like if you have func(foo& a), then do std::bind(func, _1, _2)
20160905 00:09:45< vultraz> celmin: how is func then called?
20160905 00:11:07< celmin> If you have func(foo& a) and do f = std::bind(func, _1, _2), the f(a, b) calls func(a) and ignores b.
20160905 00:11:12< celmin> I think.
20160905 00:11:45< vultraz> that... doesn't help me
20160905 00:12:08< celmin> How do you need f to be called and how do you need func to be called?
20160905 00:12:23< vultraz> (this makes my brain hurt)
20160905 00:12:32< vultraz> f is a void(twidget&) function
20160905 00:12:33< celmin> I don't really understand what you're up to, either.
20160905 00:12:51< celmin> So, in other words, the callback must take a widget argument.
20160905 00:12:51< vultraz> hm..
20160905 00:12:53< vultraz> I might.. have an idea..
20160905 00:13:00< vultraz> yes
20160905 00:13:18< vultraz> that's why I need to initialize label fields in order to use field->widget()
20160905 00:13:36< vultraz> because I don't actually HAVE the widget..
20160905 00:14:31< vultraz> e
20160905 00:14:32< vultraz> r
20160905 00:14:34< vultraz> wait
20160905 00:14:36< vultraz> hm...
20160905 00:15:34< vultraz> I have a ... small idea.
20160905 00:16:59< mattsc> celmin: quick question: in 1.13.x, I can get the number of attacks a unit has with #unit.attacks, but ipairs(unit.attacks) does not iterate over the attacks in Lua?
20160905 00:17:15< celmin> I might have implemented that? Not sure.
20160905 00:17:25< celmin> If not, I should be able to do so fairly quickly.
20160905 00:17:48< mattsc> Well, are you supposed to be able to do so?  I just tried and unless I am missing something, it doesn’t work.
20160905 00:18:21< celmin> Ideally you should be able to.
20160905 00:18:30< celmin> It requires specific support C++-side now.
20160905 00:18:56< mattsc> It’s not a big deal, I can just iterate over from 1 to #attacks.
20160905 00:19:05< celmin> Yeah, that'll work for now.
20160905 00:19:08< celmin> I will add it, though.
20160905 00:19:14< mattsc> Okay.
20160905 00:19:44< mattsc> I can wait for that, rather than doing it twice.
20160905 00:25:04< celmin> Okay, so there must be some way to register escape as a hotkey, right...?
20160905 00:25:17< celmin> Oh, right, the TSG thing.
20160905 00:25:23< celmin> Do you remember how to reproduce that.
20160905 00:25:25< celmin> ?
20160905 00:25:31< celmin> Skip to scenario 2, I know that much.
20160905 00:25:40< celmin> And trigger the modify_ai by moving to the citadale.
20160905 00:25:44< celmin> ^citadel
20160905 00:25:53< celmin> Can't remember if there was an additional condition though...
20160905 00:26:27< vultraz> hm
20160905 00:26:29< vultraz> C:\Users\Charles\Documents\wesnoth-git\src\gui\dialogs\editor\generator_settings.cpp|73|error: expression list treated as compound expression in mem-initializer [-fpermissive]|
20160905 00:26:42< celmin> What's the line?
20160905 00:26:46< vultraz> yeah I guess I can't pass something as a parameter to an argument of itself :P
20160905 00:26:52< vultraz> *plan falls apart again*
20160905 00:26:54< celmin> Okay?
20160905 00:27:04< vultraz> I was doing like
20160905 00:27:11< vultraz> field(foo(field))
20160905 00:27:32< vultraz> which i guess is illegal?
20160905 00:28:12< vultraz> it seems I cannot use the field thingy 
20160905 00:28:21< vultraz> I shall have to come up with another approach 
20160905 00:28:50< celmin> Still didn't get it though.
20160905 00:29:08< celmin> You were doing what exactly?
20160905 00:29:08< vultraz> what do you not get?
20160905 00:29:17< celmin> The TSG aspect warning.
20160905 00:29:18< vultraz> , players_(register_integer("players", true, data.nplayers, [&](twidget&) { status_default(players_); }))
20160905 00:29:46< celmin> That looks like it should work.
20160905 00:30:06< vultraz> eh? 
20160905 00:30:17< celmin> Or at least, I don't know a reason why it wouldn't.
20160905 00:32:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160905 00:34:10< vultraz> hmm
20160905 00:34:15< vultraz> now it works.. 
20160905 00:34:18< vultraz> after i removed some stuff
20160905 00:34:29< vultraz> but does it.. Work?
20160905 00:34:53< vultraz> it absolutely does not work! :P
20160905 00:38:51< vultraz> that is, it doesn't crash or anything
20160905 00:38:55< vultraz> the labels just don't show
20160905 00:40:24< celmin> Well, at least it doesn't crash.
20160905 00:42:32< celmin> You've been saying the window is unavailable before pre_show, yet it's available in post_build.
20160905 00:43:39< vultraz> wait, we have a post_build??
20160905 00:43:46< celmin> Yes.
20160905 00:43:52< celmin> You haven't noticed?
20160905 00:43:53 * vultraz flails
20160905 00:44:02< celmin> Several dialogs use it - titlescreen, lobby, for example.
20160905 00:44:17< vultraz> jesus christ
20160905 00:44:21< vultraz> why did I not see this
20160905 00:44:30< vultraz> good god
20160905 00:44:32< vultraz> :|
20160905 00:45:06< celmin> Why XCode must you always fail to respond when I'm trying to cancel the build at link stage.
20160905 00:49:29< vultraz> hmmm
20160905 00:49:46< vultraz> small hiccup, what about member fields that need status labels...
20160905 00:50:00< vultraz> i guess ill leave them a nullptrs in the constructor
20160905 00:59:44-!- jamit [~jamit@97-87-12-18.dhcp.mdsn.wi.charter.com] has joined #wesnoth-dev
20160905 01:05:48-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160905 01:06:54< vultraz> aww the labels still aren't showing :(
20160905 01:08:03-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20160905 01:08:04-!- wedge010 is now known as wedge009
20160905 01:10:33< vultraz> I don't think the function is actually called..
20160905 01:13:54< vultraz> yeah it doesn't seem to be called...
20160905 01:22:58< vultraz> how is this possible :|
20160905 01:23:44< celmin> Is it using set_callback_state_changed?
20160905 01:24:19< vultraz> yes
20160905 01:24:42< celmin> Is the dialog also using set_callback_state_changed to attach a callback?
20160905 01:24:48-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160905 01:25:03< celmin> Hi
20160905 01:25:08< vultraz> no
20160905 01:25:14< celmin> Are you sure?
20160905 01:25:35< vultraz> well one slider has an additional connect_signal_notify_modified
20160905 01:25:44< tad_> Interesting observation about bad_lexical_cast ...
20160905 01:25:48< celmin> Okay, sounds like a no.
20160905 01:26:20< tad_> If I include attack_depth=<any digit> .. no crash. Error message: UNKNOWN aspect[village_value*ai_default_rca::aspect_attacks]
20160905 01:26:36< vultraz> this would likely be so much easier if the dispatcher didn't take a tsignal_function
20160905 01:26:43< celmin> Unless connect_signal_notify_modified internally uses set_callback_state_changed, which I doubt.
20160905 01:26:47< vultraz> because it's impossible to use with a lambda 
20160905 01:26:49< celmin> Why would that be easier?
20160905 01:26:50< tad_> If I omit attack_depth .. crash. Error message: UNKNOWN aspect[villages_per_scout*ai_default_rca::aspect_attacks]
20160905 01:27:03< celmin> I doubt it's impossible to use with a lambda.
20160905 01:27:10< tad_> Note it changes from "village_value" to "villages_per_scout"
20160905 01:27:36< celmin> I'm getting the impression that there's bad memory access involved somehow.
20160905 01:27:52< celmin> Maybe I should retry the building with asan thing.
20160905 01:28:16< tad_> celmin: Oh, most likely. [modify_side][ai] must be executed to trigger the crash.
20160905 01:29:14< celmin> I wonder if asan can catch buffer overflows into memory still owned by the process.
20160905 01:29:25< tad_> And all this happens at the start of the next turn, during the write start-of-turn savefile
20160905 01:33:09< celmin> Surprisingly, Wesnoth seems to be hanging not due to swap.
20160905 01:33:23< celmin> ~95% CPU
20160905 01:33:40< celmin> Lobby hasn't yet even showed the MOTD or added me to the player list.
20160905 01:34:32< vultraz> celmin: this is what happens when you try to use a lambda: error: invalid initialization of reference of type 'const tsignal_notification_function& {aka const std::function<void(gui2::event::tdispatcher&, gui2::event::tevent, bool&, bool&, void*)>&}' from expression of type 'gui2::tgenerator_settings::bind_landform_status_label(gui2::twindow&)::<lambda(const tsignal_notification_function&)>'|
20160905 01:34:43< vultraz> just for the record.
20160905 01:35:46< celmin> Well, if you use a lambda, it does have to have a signature compatible with (tdispatcher&, tevent, bool&, bool&, void*).
20160905 01:36:03< celmin> So you may need dummy unnamed unused parameters.
20160905 01:37:25< vultraz> tsignal_notification_function is a typedef for that
20160905 01:37:52< celmin> No, it's not.
20160905 01:38:05< celmin> There's no such thing as a typdef for a parameter list.
20160905 01:38:17< vultraz> oh
20160905 01:38:19< vultraz> hm..
20160905 01:38:20< celmin> tsignal_notification_function is the whole function type including parameters and return type
20160905 01:38:31< celmin> You can't use it as the argument and expect that to work.
20160905 01:39:18< vultraz> oh, huh
20160905 01:39:22< vultraz> I see what you mean
20160905 01:39:55< vultraz> (in c++14 would 'auto' suffice?)
20160905 01:40:01< celmin> No.
20160905 01:40:14< celmin> There's no way to alias a parameter list.
20160905 01:40:28< celmin> Except as part of the full function type.
20160905 01:41:01< celmin> You could std::bind a lambda if you didn't want to have the dummy parameters.
20160905 01:41:52< vultraz> now that's an interesting idea
20160905 01:41:54< vultraz> hm hm
20160905 01:45:25< vultraz> ok
20160905 01:45:28< vultraz> ya know what
20160905 01:45:34< vultraz> I'm just gonna make a helper header class for this
20160905 01:45:41< celmin> A what now.
20160905 01:45:58< vultraz> or maybe just a helper function
20160905 01:46:05< celmin> ?
20160905 01:46:30< vultraz> something like tgroup
20160905 01:46:39< vultraz> except likely don't even need a class
20160905 01:54:39-!- irker719 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160905 01:54:39< irker719> wesnoth: mattsc wesnoth:master c03bd5411f69 / data/ai/ (8 files in 2 dirs): Various Lua AI code: use simpler and faster new syntax https://github.com/wesnoth/wesnoth/commit/c03bd5411f696ae755d9bbc4613aa9f97461a4db
20160905 01:55:15< celmin> Is ~2MB/sec normal Wesnoth lobby network usage?
20160905 01:56:21 * celmin notes that wesnoth.unit_types[unit.type].level could be different from unit.level in rare cases.
20160905 01:56:38< celmin> Or, wait.
20160905 01:56:52< celmin> I'm not entirely sure if it can, but I feel like there might be a possibility of it...
20160905 01:57:07< celmin> That field is read-only in Lua though, as I recall.
20160905 01:57:31< celmin> BTW mattsc, do you think there's any value in supporting pairs() on things such as units, attack definitions, unit types, side definitions, etc?
20160905 01:58:40 * celmin guesses that level might be editable via [modify_unit] but is not sure.
20160905 02:02:41< mattsc> celmin: I guess that theoretically the could be different (don’t know about practically), but in that case unit.level is actually what I want
20160905 02:03:33< mattsc> As for pairs() on such things, probably not very useful (at least not for AI purposes).
20160905 02:04:03< mattsc> Occasionally I need access to some “weird” key, but it is always a specific key, not an iterator over all of them
20160905 02:05:04< celmin> pairs(unit) would probably be useful for [modify_unit], but maybe not much else.
20160905 02:06:06< celmin> I don't have any specific ideas what use it would be for other things. Maybe pairs(side) could be useful for [modify_side], I guess.
20160905 02:06:59< tad_> mattsc: As I read the wiki attack_depth is deprecated. I don't know what it does or did. I tried removing it and [modify_side][ai] causes a bad_lexical_cast crash when I do.
20160905 02:08:19< tad_> mattsc: It does not crash if I don't [modify_side][ai] and the mod is no actual change.
20160905 02:08:30< mattsc> tad_: I’ve seen your messages about that (I get pinged whenever somebody uses ‘ai’)
20160905 02:08:56< mattsc> I’ve not spoken up about it since I really don’t know anything about the C++ implementation
20160905 02:09:18< mattsc> I can tell you what attack_depth did though.
20160905 02:09:42< mattsc> Essentially, it counts how many units simultaenously the AI should consider for attacks.
20160905 02:09:46< celmin> Sudden thought.
20160905 02:09:54< celmin> There is no direct Lua API for weapon filters.
20160905 02:10:07< mattsc> But IIRC, it’s been hard-coded to 5 ever since I have been working with the AI.
20160905 02:10:23< celmin> You can use a unit filter to check if a unit has a weapon matching a filter , but you cannot use the filter to get the specific matching attack.
20160905 02:10:24< tad_> mattsc: Makes sense. So why deprecate it? Or am I misunderstanding the wiki?
20160905 02:10:47< mattsc> Well, it got deprecated because the aspect does not do anything.
20160905 02:11:16< celmin> The alternative is of course to make it do something.
20160905 02:11:28< mattsc> But it’s been kept around because it’s used all over the place.  (It was in a lot of old mainline scenario, and lots of UMC just copied those [ai] tags.)
20160905 02:11:39 * tad_ nods
20160905 02:11:40< celmin> There's also no way to ask if a specific weapon matches a filter.
20160905 02:11:46< tad_> Looks like that in TSG
20160905 02:12:08< celmin> Though since weapons are usually a short list, I guess you could easily loop through them all to test manually...
20160905 02:12:09< mattsc> Well, only if it did something useful.
20160905 02:12:19< mattsc> And as far as I can tell, it does not.
20160905 02:12:26< mattsc> But as I said, that was all before my time.
20160905 02:12:29< tad_> OK. Well, I'll keep digging. It's slow and hard and I might stop trying to use gdb and adding some checks in the C++ to find the error
20160905 02:12:30< celmin> I dunno if a more direct interface to weapon filters would be that useful...
20160905 02:13:01< mattsc> tad_: Do you know if this crash happened in 1.13.4 or before?
20160905 02:13:16< celmin> mattsc: Are you implying that it's not useful to change the limit of how many units will consider simultaneously?
20160905 02:13:43< tad_> mattsc: Hmm. No. Give me a few, I might be able to see if it's in 1.12.6 ..
20160905 02:13:43< mattsc> celmin: that’s my interpretation of why it is hardcoded, yes
20160905 02:14:21< mattsc> tad_: I’m asking because I think if that had been previous behavior, we’d know about it by now.
20160905 02:14:41< mattsc> So I am wondering if this is something that happened in celmin’s AI refactoring in 1.13.4+dev
20160905 02:15:34< tad_> mattsc: Well, the symptom is the AI aspect message but no crash. I was probing the cause of the message and tryied removing attack_depth and the crash appeared.
20160905 02:16:17< mattsc> tad_: hmm, I see
20160905 02:17:39< tad_> mattsc: I took out the attack_depth and am testing 1.12.6 .. wait
20160905 02:18:05-!- JyrkiVesterinen [~jyrki@87-100-160-95.bb.dnainternet.fi] has joined #wesnoth-dev
20160905 02:20:46< tad_> mattsc: OK. Neither the UNKOWN aspect, nor the crash occur in 1.12.6
20160905 02:21:37< tad_> mattsc: So maybe I can bisect for them .. it'll take forever to build each test but it should find the issue eventually.
20160905 02:22:46< mattsc> tad_: okay, sorry that I am not more helpful — but if you want a wild guess (to save some time bisecting), I’d say it might work in 1.13.4 and not in 1.13.5
20160905 02:23:25< mattsc> Don’t quote me on that though.  ;)
20160905 02:23:48< tad_> mattsc: NP. You did help .. I know now it's somewhere in 1.13 and not a legacy never reported 
20160905 02:24:35< tad_> I'll try rolling back to 1.13.4 tag and see if that shows the error.
20160905 02:26:28-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160905 02:32:33< mattsc> tad_, celmin: another wild guess: https://github.com/wesnoth/wesnoth/commit/17ea7fac6bab261d8401e7f9d28e6770a3cd46e6
20160905 02:33:01< mattsc> This changes the aspect syntax for other aspects, but not for attack_depth  (but there might be a different reason for this, of course)
20160905 02:43:33< celmin> mattsc: Huh?
20160905 02:46:51< mattsc> Yeah, probably not relevant.  I don’t know.
20160905 02:47:33< mattsc> I’ve looked around quite a bit now, also for any sort of explanation why attack_depth does not work, but I can’t find anything.
20160905 02:48:22< mattsc> It looks to me like get_attack_depth() exists, but that it is not used anywhere.
20160905 02:48:59< celmin> I found one place in the source where attack depth is used, but like you said earlier, it's hard-coded rather than fetched from the aspect.
20160905 02:50:07< vultraz> hm.
20160905 02:50:16< mattsc> Well, what’s hard-coded is called default-attack-depth, or something.
20160905 02:50:33< mattsc> So that sounds like it was meant to be changeable.
20160905 02:50:38< celmin> Is that value used anywhere though?
20160905 02:50:51< mattsc> But then that never happens.
20160905 02:50:54< mattsc> Not that I can find.
20160905 02:51:14< celmin> What's the file BTW?
20160905 02:51:32< mattsc> Actually, yes, it is used ...
20160905 02:51:39< mattsc> hold on
20160905 02:51:42 * celmin also sorta left attack_depth in so I could use it in a unit test, but that could easily be changed to a different numerical aspect.
20160905 02:52:27< mattsc> It’s used right after it’s been hard-coded to 5:
20160905 02:52:27< mattsc> https://github.com/wesnoth/wesnoth/blob/master/src/ai/default/aspect_attacks.cpp#L144
20160905 02:53:20< mattsc> So it looks like there’s a hook there for using a variable attack depth, but that that never got added.
20160905 02:53:30< celmin> What's cur_analysis.movements?
20160905 02:53:49< mattsc> I have no idea whether that’s because it doesn’t work, or because it was forgotten
20160905 02:53:58< mattsc> Well, it’s the movements in the current analysis   :P
20160905 02:54:08< celmin> Which is what?
20160905 02:54:10< celmin> Possible moves
20160905 02:54:11< celmin> ?
20160905 02:54:20< mattsc> My guess is that it’s the number of units in the attack currently being analyzed
20160905 02:54:29< mattsc> just based on context
20160905 02:54:58< celmin> Wait, what?
20160905 02:55:17 * celmin doesn't know much about the attack analysis structure.
20160905 02:55:38< mattsc> Me neither.
20160905 02:55:38< vultraz> celmin: ok, question. http://pastebin.com/5S1fphMn if I try to build that, I get error: use of deleted function 'formatter::formatter(const formatter&)'|. if I explicitly  set an std::string return type for the lambda where formatter() is used,, I get: C:\Users\Charles\Documents\wesnoth-git\src\gui\dialogs\editor\generator_settings.cpp|66|note:   cannot convert '<lambda closure object>gui2::tgener
20160905 02:55:40< vultraz> ator_settings::pre_show(gui2::twindow&)::<lambda(gui2::tslider&)>{}' (type 'gui2::tgenerator_settings::pre_show(gui2::twindow&)::<lambda(gui2::tslider&)>') to type 'std::function<std::__cxx11::basic_string<char>(gui2::tslider&)>*'|
20160905 02:55:50< vultraz> erm
20160905 02:55:57< vultraz> maybe i should have said that in multiple lines :/
20160905 02:55:58< mattsc> Have I mentioned before that I do not know much about the C++ code?
20160905 02:56:41< celmin> I thought you did know about the attack analysis though.
20160905 02:56:46< vultraz> I checked, and lambdas do have an implicit conversion to function pointers if they don't capture...
20160905 02:56:50< celmin> Weren't you using it in the high XP CA?
20160905 02:57:41< mattsc> What?
20160905 02:57:50< vultraz> it seems odd that it would have trouble if I specify a return value since the function argument requires that...
20160905 02:58:51< mattsc> Just because I know., more or less, what criteria are used in the attack analysis, doesn’t mean that I know how that is technically implemented in C++.
20160905 02:59:07< mattsc> And no, I was using nothing of that sort in the high-XP-attack CA.
20160905 02:59:12< celmin> I think the Lua structure roughly mirrors the C++, though there may still be some differences.
20160905 02:59:40< celmin> Oh, I guess I confused attack analyses with simulated combat.
20160905 02:59:57< mattsc> Ah, okay.  That’s different, yes.
20160905 03:00:01< vultraz> the argument types are right..
20160905 03:00:28< mattsc> Anyways, I’m off; family duties.  Sorry that I’m not more helpful with this.
20160905 03:00:30< vultraz> oh, I think I made a typo..
20160905 03:00:47< celmin> vultraz: What's the argument type to bind_status_label?
20160905 03:01:12< vultraz> uh..
20160905 03:01:25< vultraz> the argument list?
20160905 03:01:51< celmin> The function argument.
20160905 03:01:54< JyrkiVesterinen> If it helps, I know quite well how simulated combat works.
20160905 03:01:57< celmin> Third argument.
20160905 03:01:59< celmin> Heh.
20160905 03:02:01< vultraz> template<typename W>
20160905 03:02:02< vultraz> void bind_status_label(twindow& window, const std::string& id, std::function<std::string(W&)>* value_getter = nullptr)
20160905 03:02:17< JyrkiVesterinen> However, attack_analysis::movements is part of attack analysis, *not* simulated combat.
20160905 03:02:40< celmin> Do you know what it is?
20160905 03:02:48< JyrkiVesterinen> No.
20160905 03:04:58< celmin> vultraz: As far as I can see, adding -> std::string should be what you want.
20160905 03:05:41< celmin> Either that, or (formatter() << …).str()
20160905 03:06:03< vultraz> have tried both
20160905 03:06:24< JyrkiVesterinen> vultaz: you seem to be missing parentheses in a function call in line 29 of your paste.
20160905 03:06:25< JyrkiVesterinen> return formatter() << s.get_value << _("/1000 tiles");
20160905 03:06:34< JyrkiVesterinen> It should be s.get_value()
20160905 03:06:50< vultraz> have aleady fixed
20160905 03:06:53< vultraz> already
20160905 03:07:19< celmin> vultraz: It's that * on value_getter.
20160905 03:07:22< celmin> Just drop that.
20160905 03:07:37< celmin> std::function<std::string(W&)> value_gette = nullptr
20160905 03:07:41< celmin> I think that'll work.
20160905 03:07:45< celmin> ^value_getter
20160905 03:10:08 * celmin is pretty sure that an std::function is capable of being empty.
20160905 03:10:20< vultraz> huh, that works
20160905 03:10:22< vultraz> I wonder why
20160905 03:11:21< vultraz> hmm
20160905 03:11:28< vultraz> this is odd
20160905 03:11:51< mattsc> celmin: it’s a map_location pair listing the src and dst of a unit in an attack
20160905 03:11:55< vultraz> the 'custom' labels don't persist on change...
20160905 03:12:04< vultraz> oh, I think I see...
20160905 03:12:09< vultraz> or..
20160905 03:12:11< vultraz> hm...
20160905 03:12:13< vultraz> no, I don't..
20160905 03:12:41< vultraz> why should it initially work, but then revert to 'value'
20160905 03:12:54< vultraz> maybe..
20160905 03:13:02< vultraz> hm.
20160905 03:13:45< vultraz> so the getter isn't executed again, I guess
20160905 03:15:53< vultraz> interesting
20160905 03:16:04< vultraz> if I define the default as a function instead of a nullptr
20160905 03:16:15< vultraz> then it crashes beyond the initial setter
20160905 03:16:58< vultraz> after throwing bad_function_call
20160905 03:17:06< vultraz> ah!
20160905 03:17:12< vultraz> capturing the function by value works :D
20160905 03:17:25< celmin> Huh? You weren't?
20160905 03:17:30< vultraz> no
20160905 03:17:32< vultraz> reference
20160905 03:17:36< celmin> Why
20160905 03:17:54< vultraz> reference capture is my default go-to method
20160905 03:18:25< JyrkiVesterinen> You should consider object lifetimes when capturing.
20160905 03:18:35< JyrkiVesterinen> Reference capture doesn't extend lifetime.
20160905 03:18:39< vultraz> I see
20160905 03:18:40< celmin> Override that default with functions.
20160905 03:18:48< JyrkiVesterinen> You may access an object after it has already been destroyed.
20160905 03:18:57< JyrkiVesterinen> Capturing by value is always safe.
20160905 03:19:53< vultraz> ok, it's working
20160905 03:19:57< vultraz> just one more thing to add
20160905 03:25:11< vultraz> it works! \ o /
20160905 03:25:15< vultraz> god, this too way too long
20160905 03:25:18< vultraz> just goes to show
20160905 03:25:26< vultraz> sometimes the simplest way is best
20160905 03:25:28< mattsc> celmin, JyrkiVesterinen: this is the structure of attack_analysis: http://pastebin.com/MgJUNeYc
20160905 03:25:34< mattsc> Well, the Lua version of it.
20160905 03:25:36< vultraz> and when you try for generalization you can fail
20160905 03:27:38< celmin> mattsc: So, do you know what that string of movements means?
20160905 03:27:52< celmin> I guess srcs is a unit and dst is an enemy unit or something?
20160905 03:27:53< mattsc> yes
20160905 03:28:00< mattsc> no
20160905 03:28:04< celmin> ^src
20160905 03:28:13< mattsc> src is the AI unit location
20160905 03:28:28< mattsc> target is the enemy location
20160905 03:28:36< mattsc> dst is the hex from which that unit attacks the enemy
20160905 03:29:04< celmin> So, are those movements each possible attack routes for a single attack?
20160905 03:29:13< mattsc> So this is an attack analysis for 3 units in combination attcking one enemy
20160905 03:29:19< celmin> Ah.
20160905 03:29:47< celmin> Could it ever be longer than 6?
20160905 03:30:02< mattsc> Btw, what I showed you there is a dbms of the attacks aspect
20160905 03:30:03< celmin> Is it all possible attacks on that one unit?
20160905 03:30:07< mattsc> no, 6 is the max
20160905 03:30:26< mattsc> this is one of the possibilities
20160905 03:30:39< celmin> So if there's two possible attacks from a given dst, it has already selected the best?
20160905 03:31:17< mattsc> Well, IIRC, the attacks aspect gives you the best combination of those three units
20160905 03:31:38< mattsc> notice the [15] at the beginning; so there are at least 14 other combinations involving other unit combinations
20160905 03:32:00< celmin> Right.
20160905 03:32:03< mattsc> In C++, however, it considers all the combinations, I think  (up to a limit of 1000 total or something)
20160905 03:33:31< celmin> But attack depth was based on the length of movements, not the total number of combinations.
20160905 03:35:29< mattsc> Right - for each combination, it only considers those that have no more than attack_depth movements.
20160905 03:36:09< mattsc> Here’s an example of the full output for 2 units on one enemy:  http://pastebin.com/wJh5L2Bs
20160905 03:36:44< mattsc> There are 4 combinations: U1 by itself; U2 by itself; U1, then U2; U2, then U1  (not in that order)
20160905 03:37:18< mattsc> If we were to set attack_depth=1, only two of these would be considered.
20160905 03:38:31< celmin> Do you think that's useful?
20160905 03:39:12-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160905 03:41:50< mattsc> I cannot come up with a good reason for it to be useful, no.
20160905 03:44:49< mattsc> I just looked at Dave’s original commit in which he introduced it, but it contains no comments or extended commit message at all.
20160905 03:44:57< mattsc> https://github.com/wesnoth/wesnoth/commit/94815f7d5b6aed9abbf13713e86693899de38c80
20160905 03:45:04< JyrkiVesterinen> Maybe performance? The number of possible combinations would explode quickly if it was possible to attack with an arbitray number of units.
20160905 03:45:29< JyrkiVesterinen> 1 unit -> 1 combination. 2 -> 2, 3 -> 6, 4 -> 24, 5 (default) -> 120, 6 -> 72
20160905 03:45:34< JyrkiVesterinen> *720
20160905 03:45:38< mattsc> Yeah, maybe, but that’s not my interpretation of why it was there in the first place.
20160905 03:45:50< celmin> I'm starting to think that my only recourse will be to utterly disconnect the standard window key handling signal, but I have no idea if that's even possible...
20160905 03:45:52< mattsc> The attack combinations considered are limited to 1,000 anyway.
20160905 03:46:52< celmin> Because as far as I can see, you need the original function to disconnect a signal.
20160905 03:47:30< celmin> Although… if bind() with the same paramters twice produces functions that compare equal… maybe it can work...
20160905 03:48:51< mattsc> My fear would be that the AI would not attack a whole lot at all if attack_depth is too small.
20160905 03:49:26< mattsc> Actually ...
20160905 03:50:22< irker719> wesnoth: Charles Dang wesnoth:master 7c663bc0a95c / / (6 files in 4 dirs): Added an helper function for creating bound status labels https://github.com/wesnoth/wesnoth/commit/7c663bc0a95ce7e9dcbe989b311720878716188c
20160905 03:50:29< mattsc> From the wiki back in 2005: “If attack_depth is low, the AI won't want to attack unwounded units very much, because it doesn't think it can kill them in the attack.”
20160905 03:50:39< vultraz> JyrkiVesterinen, celmin ^ finally :D
20160905 03:50:53< celmin> Blargh, more files.
20160905 03:51:04< vultraz> just one new one
20160905 03:53:04< celmin> Bad vultraz 
20160905 03:53:11< celmin> Bad lambdas
20160905 03:53:14< celmin> Why
20160905 03:53:47< celmin> Why is landform_label a lambda instead of a function. Why is it then wrapped in another lambda.
20160905 03:54:27< JyrkiVesterinen> Nitpicking: you indented status_label_helper.cpp:36 with spaces.
20160905 03:54:49< JyrkiVesterinen> Easy to notice in GitHub because it uses tab witdth of 8.
20160905 03:56:33< celmin> What's update_height_label_?
20160905 03:56:52< celmin> Oh, I see.
20160905 03:58:30< mattsc> celmin: so my conclusion on the attack_depth is the same I reached last time I looked into this: it is hard-coded to 5 because the AI does not work very well with a lower value.
20160905 03:58:47< mattsc> After all, it’s basic strength lies in the fact that it is so brainlessly aggressive.
20160905 03:58:50< mattsc> *its
20160905 03:59:24< JyrkiVesterinen> Other than these things (landform_label beiong a lambda and not a function, landform_label needlessly being wrapped in another lambda, and one line being intended with spaces), the commit looks good to me. :)
20160905 04:00:29-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160905 04:01:03< celmin> There's one other problem.
20160905 04:01:29< celmin> You probably broke the build by updating scons and CMake.
20160905 04:01:41< celmin> Because that file does not exist.
20160905 04:02:08< vultraz> eh?
20160905 04:02:22< vultraz> oh
20160905 04:02:24< celmin> There is no status_label_helper.cpp
20160905 04:02:25 * vultraz :|
20160905 04:02:27< vultraz> dammit!
20160905 04:02:36< celmin> Either you forgot to commit it or you didn't need to update build files.
20160905 04:02:39< celmin> More likely the latter.
20160905 04:02:45< vultraz> latter
20160905 04:02:47< vultraz> yess
20160905 04:02:52< vultraz> yes*
20160905 04:02:53< vultraz> force of habit, sorry..
20160905 04:02:55< vultraz> I shall fixup
20160905 04:03:04< celmin> The other things too?
20160905 04:03:16-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160905 04:03:23< JyrkiVesterinen> Neither did you add the .hpp to CMakeLists and SConscript.
20160905 04:03:38< celmin> Well, it's not needed there though.
20160905 04:04:09< vultraz> yeah, only cpp files
20160905 04:04:24< JyrkiVesterinen> Ah, indeed. Sorry.
20160905 04:06:04< irker719> wesnoth: Charles Dang wesnoth:master 4d7df69428ad / src/ (4 files in 3 dirs): Some cleanup/fixups on 7c663bc0a95c https://github.com/wesnoth/wesnoth/commit/4d7df69428adcb274b4f1848423f3ea64df58c44
20160905 04:06:43< celmin> Well, that's one way of fixing the lambda problem.
20160905 04:07:03< vultraz> "One way"?
20160905 04:07:27< vultraz> guess it could have been a function
20160905 04:07:31< vultraz> no point, though
20160905 04:07:31< celmin> Yeah.
20160905 04:07:46-!- travis-ci [~travis-ci@ec2-50-16-10-20.compute-1.amazonaws.com] has joined #wesnoth-dev
20160905 04:07:47< travis-ci> wesnoth/wesnoth#10714 (master - 7c663bc : Charles Dang): The build was broken.
20160905 04:07:47< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/157546675
20160905 04:07:47-!- travis-ci [~travis-ci@ec2-50-16-10-20.compute-1.amazonaws.com] has left #wesnoth-dev []
20160905 04:08:21< vultraz> I've gotten into the habit of rather abusing lambdas :P
20160905 04:09:15< vultraz> they're just so damn convenient 
20160905 04:11:08< vultraz> I'll have to do a big cleanup of the Prefs dialog now
20160905 04:11:19< vultraz> put these status labels to use and such
20160905 04:17:01-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Remote host closed the connection]
20160905 04:26:16-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 255 seconds]
20160905 04:29:30-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160905 04:33:13-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160905 04:33:18-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160905 04:38:15-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 264 seconds]
20160905 04:38:16-!- exciton_ [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160905 04:40:41-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The minstrel departs, to spread the music to the masses!]
20160905 04:43:36-!- exciton_ [chuck-the-@89.208.170.132] has quit [Ping timeout: 244 seconds]
20160905 04:43:36-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160905 04:45:07-!- JyrkiVesterinen [~jyrki@87-100-160-95.bb.dnainternet.fi] has quit [Quit: Konversation terminated!]
20160905 04:46:12< celticminstrel> How do I control whether a field currently has input focus?
20160905 04:47:13< vultraz> what do you mean?
20160905 04:47:32< celticminstrel> "input focus" means that when you type, text appears in that field.
20160905 04:48:27< celticminstrel> Hmm, I found the place where you would implement move-by-word.
20160905 04:48:49< celticminstrel> vultraz: What keystroke would you expect to use to navigate one word to the right? Ctrl+right arrow?
20160905 04:48:50< vultraz> are you referring to a textbox, the tfield_text, or...
20160905 04:48:55< celticminstrel> Textbox, yes.
20160905 04:48:58< vultraz> something like that
20160905 04:49:46< vultraz> hm
20160905 04:49:53< celticminstrel> Ah, heh, there's already a todo note about it too.
20160905 04:50:08< celticminstrel> vultraz: So, do you know how to set which textbox has input focus?
20160905 04:50:46< vultraz> not sure..
20160905 04:50:55< vultraz> I know keyboard_capture can do it
20160905 04:52:13< celticminstrel> Where is keyboard_capture?
20160905 04:52:18< vultraz> twindow
20160905 04:52:28< vultraz> don;'t use add_to_keyboard chain
20160905 04:52:34< vultraz> that.. can be buggy
20160905 04:52:38< celticminstrel> Hmm, seems vaguely unlikely, but I'll try setting a breakpoint.
20160905 04:52:43< celticminstrel> Why?
20160905 04:53:18< vultraz> i noticed that it doesn't just set focus, it can grab input even if another widget is focused 
20160905 04:54:02< celticminstrel> Ah, maybe that should be used for the chatbox then.
20160905 04:54:12< celticminstrel> I'll try that.
20160905 04:54:26< celticminstrel> Possibly removing it when the filter text is active though...
20160905 04:55:33-!- Kwandulin [~Miranda@p200300760F4241340C1A106EBBA8302B.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160905 04:55:47< celticminstrel> But then how do I test if a widget has input focus?
20160905 04:56:55< vultraz> no idea
20160905 04:57:02< vultraz> what are you doing?
20160905 04:57:25< celticminstrel> Well, maybe I'll abandon that part, since it's not really that important.
20160905 04:58:18< celticminstrel> I'm trying to make a quit confirmation for the MP lobby, so that you can exit it with escape.
20160905 04:58:39< celticminstrel> And while I'm here I thought I'd fix the problem with the chat input not being initially ready for input.
20160905 04:59:01< celticminstrel> How did you make two widgets share keyboard input in unit create, again?
20160905 04:59:47< celticminstrel> Using keyboard_capture on boath?
20160905 04:59:49< celticminstrel> ^both
20160905 05:00:06< vultraz> keyboard capture and add to keyboard chanin
20160905 05:00:23< celticminstrel> So the field was added to keyboard chain and the listbox captured?
20160905 05:00:50< vultraz> 	window.keyboard_capture(filter);
20160905 05:00:52< vultraz> 	window.add_to_keyboard_chain(&list);
20160905 05:00:59-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160905 05:01:04< celticminstrel> Other way around, huh... I guess that works.
20160905 05:01:22< celticminstrel> Actually, it may be better.
20160905 05:03:43 * vultraz reminds himself one does not always need find_if/any_of
20160905 05:03:50< celticminstrel> ?
20160905 05:04:19< vultraz> i almost forgot I could use std::find here
20160905 05:04:34< celticminstrel> It's not a map or set, is it?
20160905 05:05:01< vultraz> no, I'm just adding a small helper function to unit_type to test if it has a gender variation
20160905 05:07:05< celticminstrel> Huh, why?
20160905 05:07:22< celticminstrel> (Useful, mind you. I was going to do that as part of my next Lua API thing.)
20160905 05:07:40< vultraz> im making unit create disable invalid gender choices for the selected type
20160905 05:07:52< celticminstrel> Can you add random while you're at it?
20160905 05:08:06< vultraz> D:
20160905 05:08:10< vultraz> perhaps
20160905 05:21:34< celticminstrel> Well, not easy to test that both share focus when there are no games...
20160905 05:22:17< celticminstrel> But I'll be satisfied if the chat at least gets focus.
20160905 05:24:15< celticminstrel> Looks like it didn't work. Reverse the order?
20160905 05:24:51< celticminstrel> I feel like that would break something, but I'll try...
20160905 05:30:28< irker719> wesnoth: JaMiT wesnoth:master e42f079d7818 / src/editor/toolkit/editor_toolkit.cpp: Use an existing typedef to simplify two declarations https://github.com/wesnoth/wesnoth/commit/e42f079d78184389d7cd031786b8eff7a59bfc4d
20160905 05:30:30< irker719> wesnoth: JaMiT wesnoth:master ee03df92ab39 / src/editor/toolkit/ (editor_toolkit.cpp editor_toolkit.hpp): Change a raw pointer to a shared pointer https://github.com/wesnoth/wesnoth/commit/ee03df92ab390f713cd72b9998cf50b3b85df417
20160905 05:30:32< irker719> wesnoth: JaMiT wesnoth:master a422e657a4a6 / src/editor/ (14 files in 2 dirs): Use editor_toolkit& instead of mouse_action** in palettes https://github.com/wesnoth/wesnoth/commit/a422e657a4a62df0ff077e4cfc470bddf4df8621
20160905 05:30:34< irker719> wesnoth: JaMiT wesnoth:master a6d23581e121 / src/editor/ (5 files in 3 dirs): Return mouse_action by reference instead of a not-null pointer https://github.com/wesnoth/wesnoth/commit/a6d23581e1210fc6b89bec360ecaa57e1da43357
20160905 05:30:36< irker719> wesnoth: JaMiT wesnoth:master 4212a3c66020 / src/editor/toolkit/editor_toolkit.hpp: Doxygen for new function https://github.com/wesnoth/wesnoth/commit/4212a3c66020f1423ad57837e584185546018d29
20160905 05:30:38< irker719> wesnoth: JaMiT wesnoth:master 44741dc36d86 / src/editor/ (3 files in 2 dirs): Add some const, virtual, and override qualifiers https://github.com/wesnoth/wesnoth/commit/44741dc36d86c6d6dbc4bb573d6cc3ce02e98c2b
20160905 05:30:40< irker719> wesnoth: JaMiT wesnoth:master 24a4dd8062a2 / src/editor/toolkit/ (editor_toolkit.cpp editor_toolkit.hpp): Replace raw pointer with shared pointer https://github.com/wesnoth/wesnoth/commit/24a4dd8062a24ecfd5d1113197d7e950746bc884
20160905 05:30:59< celticminstrel> Sudden something!?
20160905 05:31:33< vultraz> wha???
20160905 05:31:54< vultraz> a long dormant committer awakens 
20160905 05:32:33< zookeeper> O.o
20160905 05:33:00< celticminstrel> Also curious that it "fixes" the double-pointer I mentioned earlier today.
20160905 05:33:04< celticminstrel> Coincidence?
20160905 05:33:50< jamit> :) I checked in about a month ago, then I got side tracked.
20160905 05:34:07< vultraz> I see you do not like raw pointers
20160905 05:34:15< celticminstrel> Which is good.
20160905 05:34:25< celticminstrel> So that's all code cleanup?
20160905 05:34:57< jamit> I looked through the bug tracker and saw a memory leak. Smart pointers were the most effective way to fix that. Then there were some other things to clean up...
20160905 05:35:51< vultraz> ah, you fixed a bug?
20160905 05:35:51< jamit> Yes, all cleanup. Other than stopping a memory leak there should be no functional changes.
20160905 05:36:09< jamit> bug #24499
20160905 05:37:19< jamit> There's more cleanup that could be done, but I think that's it for me for now.
20160905 05:37:44< vultraz> will you now vanish for many years again? :P
20160905 05:38:16< jamit> Oh, aside from the Code::Blocks project. It looks like some files are missing from that.
20160905 05:38:30< vultraz> uh, that cannot be
20160905 05:38:33< vultraz> I use that to build
20160905 05:38:45< vultraz> (the codeblocks + scons project is way out-of-date, though)
20160905 05:38:53< celticminstrel> It could be if a) they're headers or b) he's talking about the other CB project.
20160905 05:38:58< jamit> It builds fine (scons). There are files missing from the tree.
20160905 05:39:40< celticminstrel> Some files also moved around.
20160905 05:40:06< celticminstrel> The keyboard capture + add to keyboard chain is not working.
20160905 05:40:23< jamit> editor/palette/location_palette.cpp
20160905 05:42:19< vultraz> that's there
20160905 05:42:31< celticminstrel> ?
20160905 05:42:32< vultraz> (though still unclear if you means the scons tree)
20160905 05:42:37< vultraz> mean
20160905 05:42:37< irker719> wesnoth: JaMiT wesnoth:master d46a327029db / projectfiles/CodeBlocks-SCons/wesnoth.cbp: Missing file, moved files, and alphabetical order https://github.com/wesnoth/wesnoth/commit/d46a327029db3691c5183cfa25c1f599351b1de6
20160905 05:42:42< vultraz> ah he did
20160905 06:12:31-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160905 06:17:33< irker719> wesnoth: Celtic Minstrel wesnoth:master a4655b5ede74 / src/gui/dialogs/lobby/ (lobby.cpp lobby.hpp): MP Lobby: Re-enable Esc key to exit, now with confirmation https://github.com/wesnoth/wesnoth/commit/a4655b5ede7486fcae41b1f55fa2d948a6ca0bc3
20160905 06:17:35< irker719> wesnoth: Celtic Minstrel wesnoth:master 4ad19506697b / src/gui/dialogs/multiplayer/mp_options_helper.cpp: MP Create: Honour developer's order for custom options https://github.com/wesnoth/wesnoth/commit/4ad19506697bab38f9b2f71d5c18af0c71f1b311
20160905 06:17:37< irker719> wesnoth: Celtic Minstrel wesnoth:master 36345ac56be7 / src/gui/dialogs/multiplayer/mp_options_helper.cpp: Fixup whitespace https://github.com/wesnoth/wesnoth/commit/36345ac56be7d9982d7eb7ecc0a72389fac034e6
20160905 06:17:40-!- celticminstrel is now known as celmin|sleep
20160905 06:26:38< vultraz> Honour :|
20160905 06:26:42< vultraz> *twitch* 
20160905 06:31:02< vultraz> let it be known i still very much disagree with having them in the defined order
20160905 06:34:44-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev
20160905 06:34:55< vultraz> it really doesn't look good
20160905 06:35:03< vultraz> we should assume the umc people are gonna screw up
20160905 06:51:07< zookeeper> how could they screw it up?
20160905 06:52:26< vultraz> make it look bad
20160905 06:52:58< vultraz> remember, the average UMC coder is a dugi not a shadow m.
20160905 06:53:33-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160905 06:56:38< zookeeper> yes i understand that by "screw up" you mean "look bad", i was asking how
20160905 06:57:06< vultraz> not grouping options by type
20160905 06:57:11< vultraz> or other logical order
20160905 07:00:21< zookeeper> ok so didn't celmin make them be listed in the tag order?
20160905 07:00:42< vultraz> yes
20160905 07:01:29< zookeeper> well... i guess i'd need an example of a screwed-up order then
20160905 07:26:48-!- atarocch_ [~atarocch@93.56.160.28] has joined #wesnoth-dev
20160905 07:28:37-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 252 seconds]
20160905 07:47:02-!- Kwandulin [~Miranda@p200300760F4241340C1A106EBBA8302B.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160905 08:25:39-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 260 seconds]
20160905 08:34:46-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160905 08:52:38-!- Kwandulin [~Miranda@p200300760F424134783FC2FC490988AB.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160905 09:06:27-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160905 09:18:14-!- irker719 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160905 09:31:05-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160905 09:37:33-!- jamit [~jamit@97-87-12-18.dhcp.mdsn.wi.charter.com] has left #wesnoth-dev []
20160905 10:08:05-!- elias [~allefant@allegro/developer/allefant] has quit [Ping timeout: 244 seconds]
20160905 10:08:38-!- elias [~allefant@allegro/developer/allefant] has joined #wesnoth-dev
20160905 10:28:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160905 10:44:33-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160905 11:15:26-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has joined #wesnoth-dev
20160905 12:10:13-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 252 seconds]
20160905 12:13:37< Rhonda> shadowm: As long as we don't have a place to pull backups too it's a bit tricky to shift blame anywhere.
20160905 12:22:45< loonycyborg> he wasn't shifting blame
20160905 12:23:45-!- louis94 [~~louis94@91.178.241.125] has joined #wesnoth-dev
20160905 12:24:24< loonycyborg> Rhonda: you can always request dave to fund a particular solution
20160905 12:24:31< loonycyborg> if you're willing to maintain it
20160905 12:24:52< Rhonda> "blame Soliton and Rhonda for that"
20160905 12:25:10< Rhonda> Sounds very much like putting blame on people.
20160905 12:25:18< loonycyborg> afaict just figure of speech :P
20160905 12:25:18< Rhonda> Not sure if you read id differently.
20160905 12:25:34< Rhonda> Then kill your self, figuratively?
20160905 12:25:45< loonycyborg> maybe later
20160905 12:26:50-!- Kwandulin [~Miranda@p200300760F424134783FC2FC490988AB.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160905 12:27:43-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160905 12:29:43-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160905 12:37:21-!- edgrey [~edgrey@178.204.2.238] has joined #wesnoth-dev
20160905 13:02:43-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160905 13:05:52-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160905 13:09:03-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 240 seconds]
20160905 13:09:04-!- wedge010 is now known as wedge009
20160905 13:09:47-!- irker943 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160905 13:09:47< irker943> wesnoth: gfgtdf wesnoth:master 486e3ec1ee40 / data/core/macros/abilities.cfg: fix comment https://github.com/wesnoth/wesnoth/commit/486e3ec1ee403172556ebdfc35c225b0682a522d
20160905 13:22:00-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160905 13:25:08-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Ping timeout: 244 seconds]
20160905 13:25:50-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160905 13:30:22-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160905 13:55:20-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160905 13:56:38-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160905 13:58:45-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160905 14:06:31-!- Kwandulin [~Miranda@p200300760F424134B4F4852CDAC4B0A1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160905 14:18:52-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160905 14:43:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160905 14:44:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160905 14:48:40-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Read error: Connection reset by peer]
20160905 14:49:48-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160905 15:00:35-!- boucman_work [~boucman@193.56.60.161] has quit [Ping timeout: 258 seconds]
20160905 15:10:43-!- celmin|sleep is now known as celticminstrel
20160905 15:12:23< celticminstrel> I still maintain that it's not our job to prevent addon devs from "screwing up" when doing so only makes it look bad.
20160905 15:17:30-!- boucman_work [~boucman@193.56.60.161] has joined #wesnoth-dev
20160905 15:38:56< vultraz> I think it's our job to take sensible measures to make sure UI options are presented in a consistent fashion
20160905 15:39:16< vultraz> you forget it's also simpler to parse when you have multiple options
20160905 15:39:42< vultraz> visually, that is
20160905 15:40:48< vultraz> it's not just about looking good
20160905 15:42:47< Ravana_> then put that guideline to referencewml
20160905 15:44:34-!- celmin [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160905 15:44:38-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Disconnected by services]
20160905 15:45:23-!- mattsc_ [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160905 15:45:26-!- Jetrel_ [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has joined #wesnoth-dev
20160905 15:45:35-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160905 15:46:53< vultraz> celmin: If one has several addons with selected options, having them grouped in a similar fashion enables one to quickly scan the list and mentally pre-sort them by function. A unordered list means one has to carefully look over each set of options to get a distinct sense of their purpose.
20160905 15:48:38-!- nurupo_ [~nurupo.ga@unaffiliated/nurupo] has joined #wesnoth-dev
20160905 15:48:55-!- nurupo [~nurupo.ga@unaffiliated/nurupo] has quit [Ping timeout: 260 seconds]
20160905 15:48:58-!- loonycyborg [~loonycybo@wesnoth/developer/loonycyborg] has quit [Ping timeout: 260 seconds]
20160905 15:48:59-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20160905 15:49:01-!- iwaim__ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has quit [Ping timeout: 260 seconds]
20160905 15:49:01-!- abruanese [~a@45.63.97.181] has quit [Ping timeout: 260 seconds]
20160905 15:49:01-!- Jetrel [~Jetrel@c-73-228-139-39.hsd1.mn.comcast.net] has quit [Ping timeout: 260 seconds]
20160905 15:49:02-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Ping timeout: 260 seconds]
20160905 15:49:02-!- mattsc_ is now known as mattsc
20160905 15:49:04-!- wedge010 is now known as wedge009
20160905 15:49:04-!- celmin [~celmin@unaffiliated/celticminstrel] has quit [Ping timeout: 264 seconds]
20160905 15:49:06-!- loonycyborg [~loonycybo@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20160905 15:49:09-!- abruanese [~a@45.63.97.181] has joined #wesnoth-dev
20160905 15:49:20-!- nurupo_ is now known as nurupo
20160905 15:53:53-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160905 15:56:42< celticminstrel> Last thing I saw was Ravana's comment about ReferenceWML.
20160905 15:57:22< celticminstrel> vultraz: But grouping them by type does not necessarily constitute "a similar fashion" or "an ordered list".
20160905 15:57:45< vultraz> [02:46:50]	vultraz	celmin: If one has several addons with selected options, having them grouped in a similar fashion enables one to quickly scan the list and mentally pre-sort them by function. A unordered list means one has to carefully look over each set of options to get a distinct sense of their purpose.
20160905 15:57:59< celticminstrel> Yeah, I saw that too, because it was just after I reconnected.
20160905 15:58:28< vultraz> :/
20160905 15:58:29< vultraz> ok
20160905 15:58:52-!- boucman_work [~boucman@193.56.60.161] has quit [Remote host closed the connection]
20160905 16:00:33-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Ping timeout: 240 seconds]
20160905 16:03:41-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160905 16:09:49-!- irker943 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160905 16:14:24-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20160905 16:14:45-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160905 16:16:16-!- iwaim__ [~iwaim@2001:2c0:40e:2002:0:4:14:80] has joined #wesnoth-dev
20160905 16:39:42< celticminstrel> What was the way to prevent a scrollbar from appearing in a listbox? vertical_scrollbar_mode=never didn't work. Maybe none?
20160905 16:43:42< celticminstrel> Is there a reason for the listbox footer being above the horizontal scrollbar?
20160905 16:50:40 * celticminstrel poke vultraz 
20160905 16:51:07< celticminstrel> Also, was it known that the header/footer currently scroll with the list?
20160905 16:51:55< vultraz> celticminstrel: yeah, that should be the key...
20160905 16:52:26< vultraz> and yes, it's known the header will scroll with a horizontal scrollbar
20160905 16:52:44< celticminstrel> It was scrolling with the vertical scrollbar though.
20160905 16:52:45< vultraz> why?
20160905 16:52:58< celticminstrel> Although I also seem to recall that that wasn't happening somewhere else... hotkeys?
20160905 16:53:08< vultraz> the header does not scroll with the list
20160905 16:53:12< vultraz> vertically
20160905 16:53:20< celticminstrel> :|
20160905 16:53:27< celticminstrel> Did I do something weird then.
20160905 16:53:42< vultraz> look at any list with a header
20160905 16:53:47< vultraz> hotkeys, game load
20160905 16:53:51< vultraz> game stats
20160905 16:53:58< vultraz> header stays put :|
20160905 16:54:03< celticminstrel> Hotkeys is good because it's easily accessible.
20160905 16:54:31-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has quit [Remote host closed the connection]
20160905 16:54:45< celticminstrel> Has any list ever used a footer?
20160905 16:54:53< celticminstrel> Oh right, I can grep that.
20160905 16:54:56< vultraz> no
20160905 16:55:03< vultraz> we could remove it
20160905 16:55:19< celticminstrel> Hmm.
20160905 16:55:24< celticminstrel> (Don't remove it yet.)
20160905 16:56:28< celticminstrel> Oh, could it be that the scrollbar I'm seeing is the window scrollbar, not the listbox scrollbar?
20160905 16:56:46-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 252 seconds]
20160905 16:56:57-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20160905 16:57:25< celticminstrel> That would explain the header moving with the list, as well as the vertical scrollbar mode not working.
20160905 16:57:34< vultraz> likely
20160905 16:57:36< vultraz> what are you doing?
20160905 16:57:49< celticminstrel> I'm trying to add scroll buttons to menus for when there's not enough space.
20160905 16:57:59< celticminstrel> Instead of having a scrollbar.
20160905 16:58:37< vultraz> heh
20160905 16:58:39< vultraz> good luck
20160905 16:59:06< vultraz> you'll need to change the nature of the widget to not dismiss on click, then, or make the button work when hovered
20160905 16:59:37< vultraz> window*
20160905 16:59:48< celticminstrel> The former is false, apparently.
20160905 17:00:08< vultraz> oh?
20160905 17:00:11< celticminstrel> I'm confused. I thought these checkboxes were fake, but they're not. :|
20160905 17:00:22< vultraz> what?
20160905 17:00:25< vultraz> they are o_O
20160905 17:00:29< celticminstrel> In the scenario editor music list.
20160905 17:00:50< celticminstrel> The radiobuttons in the time of day list are fake.
20160905 17:01:11< celticminstrel> Why aren't the checkboxes in the music list also fake?
20160905 17:01:12< vultraz> whaaa
20160905 17:01:32< celticminstrel> They're supposed to be fake.
20160905 17:01:34< vultraz> hm
20160905 17:01:37< vultraz> no, they're fake
20160905 17:01:46< celticminstrel> Because you click to dismiss, and when you next view, they're toggled.
20160905 17:01:47< vultraz> notice they don't light up when hovered :|
20160905 17:02:03< vultraz> it's the 'checked image' drawn
20160905 17:02:04< celticminstrel> Works correctl with planning mode...
20160905 17:02:07< celticminstrel> ^correctly
20160905 17:02:21< celticminstrel> Yeah, that's the idea.
20160905 17:02:31< vultraz> so yeah, they're fake
20160905 17:02:43< vultraz> i do want real checkboxes, though
20160905 17:03:02< vultraz> notice when you click a music track the list jumps to top?
20160905 17:03:03< celticminstrel> Ooh, I bet the music menu is set to show continuously in a loop as long as you select something. That could explain it.
20160905 17:03:11< vultraz> that's because it's being redrawn
20160905 17:03:12< celticminstrel> Yeah, okay.
20160905 17:03:38< vultraz> should we implement real checkboxes for his type of list?
20160905 17:03:51< vultraz> will also be useful for Mods in Campaign Selection
20160905 17:03:58< vultraz> ie, have a dropdown list with checkboxes
20160905 17:04:13< celticminstrel> Eh, I dunno...
20160905 17:04:33< vultraz> this type of hack is very bad, just saying
20160905 17:04:59< celticminstrel> Anyway, I added a repeating button in the header and footer, and clicking it does not dismiss the menu, so a button takes precedence over click-dismiss.
20160905 17:05:20< vultraz> ohhh right
20160905 17:05:24< vultraz> I forgot I discovered this
20160905 17:05:27< celticminstrel> I don't really see it as a hack in the general case, for example with planning mode or shroud updates in the main game, or the time of day menu.
20160905 17:05:31< vultraz> when I tested adding checkboxes to the list
20160905 17:05:59< celticminstrel> The music list maybe is a bit of a hack though, because there the behaviour of dismissing immediately is less desirable - you probably want to select several all at once.
20160905 17:06:12< vultraz> celticminstrel: having images isn't a hack. having images that *look* like a widget but aren't one is horrible
20160905 17:06:24< vultraz> celticminstrel: we just discovered that checking the box doesn't dismiss
20160905 17:06:28< celticminstrel> Well, feel free to swap out those images with something else.
20160905 17:06:42< celticminstrel> They don't have to look like checkboxes and radiobuttons.
20160905 17:07:34< vultraz> oh, you're saying we should be able to select a list item and not dismiss?
20160905 17:07:48< celticminstrel> I actually don't think they even need an image when unchecked - if you just had a checkmark (for checkboxes) or bullet point (for radiobuttons) next to the active one, that would suffice.
20160905 17:07:49< celticminstrel> What?
20160905 17:08:04< vultraz> blah
20160905 17:08:09< vultraz> [04:05:56]	celticminstrel	The music list maybe is a bit of a hack though, because there the behaviour of dismissing immediately is less desirable - you probably want to select several all at once.
20160905 17:08:12< vultraz> [04:06:21]	vultraz	celticminstrel: we just discovered that checking the box doesn't dismiss
20160905 17:08:13< celticminstrel> (Swapping out the images sounds like just replacing images, but those images are actually hardcoded in the source somewhere.)
20160905 17:08:20< celticminstrel> Oh.
20160905 17:08:27< vultraz> [04:07:31]	vultraz	oh, you're saying we should be able to select a list item and not dismiss?
20160905 17:08:29< celticminstrel> Yeah, I guess adding checkboxes would be good for that...
20160905 17:08:43< vultraz> ie, not have to click the checkbox
20160905 17:08:54< celticminstrel> Not having to click the checkbox is also good though...
20160905 17:09:04< celticminstrel> Maybe we need a different drop_down_list?
20160905 17:09:19< celticminstrel> A separate dialog with slightly different behaviour.
20160905 17:09:36< celticminstrel> Maybe it could share a base class with the existing one, not sure.
20160905 17:09:55< vultraz> no, just control this line:
20160905 17:09:56< celticminstrel> Music list and mod list are the only places we'd really want it, right?
20160905 17:09:57< vultraz> list.set_callback_item_change(std::bind(&tdrop_down_list::item_change_callback, this, std::ref(window), _1));
20160905 17:10:07< celticminstrel> Hmm, I suppose...
20160905 17:10:20< celticminstrel> I'm a little dubious about packing too much functionality into one class, but...
20160905 17:10:38< celticminstrel> (I already packed a lot in when I added support for replacing the text with an image.)
20160905 17:11:00< vultraz> make the constructor take a click_dismiss argument that defaults to true
20160905 17:11:36< celticminstrel> Well, keep in mind that we probably don't actually want to select list items in the music list.
20160905 17:11:46< vultraz> wha?
20160905 17:11:51< celticminstrel> We just want to toggle the checkbox.
20160905 17:12:01< vultraz> ... wha?
20160905 17:12:03< celticminstrel> Assuming we stick to the current aesthetic.
20160905 17:12:08< vultraz> no sense, do you make
20160905 17:12:34< celticminstrel> I don't get what's confusing you.
20160905 17:12:54< vultraz> the point is to make the dialog not dismiss when selecting a new item
20160905 17:12:58< celticminstrel> I'm saying we want clicking a list item to toggle the checkbox, but not outline the list item.
20160905 17:13:04< vultraz> false
20160905 17:13:29< celticminstrel> Why?
20160905 17:13:37< vultraz> why not?
20160905 17:13:58< celticminstrel> If you're going to say "false" like that you need to at least back it up with an alternative.
20160905 17:14:25< vultraz> just have the checkbox toggled/image set *and* select an item?
20160905 17:15:03< celticminstrel> What's the benefit to having an outline around the previously-toggled item?
20160905 17:15:34< vultraz> well, there isn't really one
20160905 17:15:40< vultraz> but how do you propose to fix it?
20160905 17:15:45< vultraz> new toggle_panel definition?
20160905 17:16:03< vultraz> with no 'extra drawing for the selected state?
20160905 17:16:16< celticminstrel> Well, you could do that, but I was just thinking a list selection callback that deselects the item, but again... this gets to the point where I think a separate class would be better.
20160905 17:16:24< celticminstrel> Separate dialog class, that is.
20160905 17:16:27< vultraz> *no*
20160905 17:16:37< vultraz> do not use such hacky methods
20160905 17:16:37< celticminstrel> Don't just say "no" all of a sudden.
20160905 17:16:49< vultraz> separate class, sure.
20160905 17:17:04< vultraz> but don't make something deselect the selection in a selection callback :|
20160905 17:17:17< celticminstrel> If it works, it works!
20160905 17:17:37< vultraz> *groans*
20160905 17:18:07< vultraz> wesnoth is full of stuff that "works"
20160905 17:18:11< celticminstrel> So somehow I need to force the listbox to get a scrollbar instead of the window...
20160905 17:18:13< celticminstrel> Any ideas?
20160905 17:18:42< vultraz> vertical_scrollbar_mode = always
20160905 17:19:11< celticminstrel> Hmm.
20160905 17:19:25< celticminstrel> If I do that and also hide the scrollbar from the code...
20160905 17:19:43< vultraz> you don't need to hide the scrollbar from the code...
20160905 17:19:50< vultraz> add a new definition of listbox 
20160905 17:20:04< celticminstrel> I tried that. It can't handle the nonexistence of a scrollbar.
20160905 17:20:05< vultraz> with your buttons in place of the standard scrollbar
20160905 17:20:11< vultraz> . . .
20160905 17:20:20 * vultraz groans
20160905 17:20:26< celticminstrel> What's wrong now?
20160905 17:20:38< vultraz> but wait, are not your buttons the scrollbar?
20160905 17:20:56< celticminstrel> My buttons are like those at the ends of the scrollbar, not the scrollbar itself.
20160905 17:20:56< vultraz> or does it literally need a scrollbar widget
20160905 17:20:59< celticminstrel> Yeah.
20160905 17:21:06< vultraz> #JustGUI2Things
20160905 17:21:50< celticminstrel> I considered making it not require a scrollbar, but the assumption that it exists is everywhere in the file.
20160905 17:21:53< vultraz> why not expand the abstract concept of a scrollbar to a scroll controller?
20160905 17:22:04< celticminstrel> Hm?
20160905 17:22:33< vultraz> instead of "we need a scrollbar", "we need something that controls scrolling, which may be a scrollbar"
20160905 17:22:46< celticminstrel> Hmm...
20160905 17:23:32< vultraz> you cannot really hide the scrollbar anyway
20160905 17:24:28-!- jamit [~jamit@97-87-12-18.dhcp.mdsn.wi.charter.com] has joined #wesnoth-dev
20160905 17:24:43< vultraz> celticminstrel: you *could* try disabling the scrollbars for the menu window
20160905 17:24:43< celticminstrel> Hm?
20160905 17:24:52< celticminstrel> Disabling?
20160905 17:24:58< celticminstrel> Like, set_active(false)?
20160905 17:25:01< vultraz> data/gui/widgets/window.cfg:189
20160905 17:25:06< jamit> celticminstrel: https://gna.org/bugs/index.php?25041
20160905 17:25:06< vultraz> make that 'never'
20160905 17:25:23< celticminstrel> Why am I being pinged on this bug?
20160905 17:25:29< vultraz> HSM should probably be 'never' too
20160905 17:25:33< jamit> Your commit caused it.
20160905 17:25:55< celticminstrel> Could you quote the title?
20160905 17:26:06< celticminstrel> vultraz: That file does not exist.
20160905 17:26:10< jamit> Unit types always exist in Lua (segmentation fault)
20160905 17:26:18< vultraz> window_default.cfg
20160905 17:26:19< vultraz> sorry
20160905 17:26:38< celticminstrel> Hm.
20160905 17:26:42-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160905 17:26:48< vultraz> though if you set both to never might as well just remove the scrollbar panel
20160905 17:27:31< vultraz> very likely this will break something, though :)
20160905 17:27:37< vultraz> because #GUI2
20160905 17:27:39< celticminstrel> The menu window is only used by dropdown list?
20160905 17:28:00< vultraz> yes
20160905 17:28:08< vultraz> that or nay future thing requiring similar behavior
20160905 17:28:11< vultraz> any*
20160905 17:28:19< celticminstrel> Trying that now.
20160905 17:28:49< celticminstrel> I'll comment out VSM for the drop down list for the test.
20160905 17:28:55< celticminstrel> Then try it again with "never".
20160905 17:28:55< vultraz> no
20160905 17:28:57< vultraz> set to never
20160905 17:29:06< celticminstrel> Trying both.
20160905 17:29:10< vultraz> the default is initial auto or auto
20160905 17:29:29< vultraz> if not specified 
20160905 17:29:40< celticminstrel> I suppose I might as well push the other thing I happened across while investigating for this, though.
20160905 17:30:17-!- gfgtdf [~chatzilla@x4e36ae3c.dyn.telefonica.de] has joined #wesnoth-dev
20160905 17:30:18< celticminstrel> Actually, I should double-check something first.
20160905 17:30:26< gfgtdf> vultraz: already process on the gui2 mp cpnnect ?
20160905 17:30:34< vultraz> gfgtdf: no
20160905 17:30:42< celticminstrel> vultraz: Where is the theme selection dialog?
20160905 17:30:44< vultraz> I'm rather burned out :/
20160905 17:30:56< vultraz> celticminstrel: where is its... definition? use?
20160905 17:31:01< celticminstrel> Code.
20160905 17:31:14< celticminstrel> Implementation.
20160905 17:31:21< gfgtdf> ok
20160905 17:31:37< vultraz> gui/dialogs/theme_list.*pp
20160905 17:31:38< vultraz> why?
20160905 17:31:55< vultraz> gfgtdf: if you want to start work on it i wouldn't mind.
20160905 17:32:03< celticminstrel> I just want to make sure that I didn't add conflicting prefs.
20160905 17:34:25-!- irker151 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160905 17:34:25< irker151> wesnoth: mattsc wesnoth:master 4ec5a811ae20 / RELEASE_NOTES: Clean up release notes for 1.13.5+dev https://github.com/wesnoth/wesnoth/commit/4ec5a811ae2071993de26f0486f228c245285e7f
20160905 17:34:25< irker151> wesnoth: mattsc wesnoth:master ea744e17070e / RELEASE_NOTES players_changelog: Update players_changelog and release notes https://github.com/wesnoth/wesnoth/commit/ea744e17070e5acb784749d7b1c8ebabaff5cfc2
20160905 17:34:43< celticminstrel> Well, so much for pushing it now.
20160905 17:35:08< celticminstrel> ...I suppose I could always reset and recommit though.
20160905 17:35:35< mattsc> celticminstrel: :(  Sorry, I wasn’t around before.
20160905 17:37:15< celticminstrel> It's not a big deal. I'll just push later, when I next have a clean working copy (so probably after I deal with the menus).
20160905 17:38:27< mattsc> celticminstrel: okay; I am done with updates for now, so hopefully there shouldn’t be any more “intereference” from my side
20160905 17:38:38< mattsc> I do have more stuff coming up, but probably not today.
20160905 17:39:10-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has joined #wesnoth-dev
20160905 17:39:39-!- fabi_ [~fabi@176.4.56.57] has quit [Ping timeout: 244 seconds]
20160905 17:39:59-!- fabi_ [~fabi@176.4.56.57] has joined #wesnoth-dev
20160905 17:44:30< irker151> wesnoth: Celtic Minstrel wesnoth:master 758315f53352 / / (5 files in 3 dirs): Enable GUI2 themes https://github.com/wesnoth/wesnoth/commit/758315f53352fff165347b2b0145f48cb5ca4fcb
20160905 17:50:07-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160905 17:52:18-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160905 17:54:30< tad_> celticminstrel: Need to talk about https://github.com/wesnoth/wesnoth/commit/29ca22b5dafbfc3f420cce6f3806a7c1bc3d582e what it does, why, and what to do to fix the spurious UNKNOWN aspect errors and bad_lexical_cast crash it causes.
20160905 17:57:43< celticminstrel> tad_: If that's the cause, it's very likely fixed in b757a67f8340ecbd8bc02c13058205e0fecd773e
20160905 17:57:53< celticminstrel> Which removes both the functions touched in that commit.
20160905 17:58:32< celticminstrel> vultraz: Unfortunately, setting scrollbar mode to never causes it to fail due to not fitting on the screen.
20160905 17:59:42< celticminstrel> If it's never in the window but auto in the listbox, that does work, apart from having the scrollbar which I don't want.
20160905 18:01:23< celticminstrel> Someone decided not to bother implementing demand_reduce_{height,width}... if those were implemented and wired in, I think this could be made to work.
20160905 18:04:26-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20160905 18:04:26-!- JyrkiVesterinen [~jyrki@89-166-100-155.bb.dnainternet.fi] has joined #wesnoth-dev
20160905 18:11:59< tad_> celticminstrel: bisect says it's the culprit.
20160905 18:12:23< celticminstrel> Okay.
20160905 18:12:34< celticminstrel> If you merge the mentioned commit, does that fix it?
20160905 18:13:45< tad_> I will check it in a bit.
20160905 18:15:10< tad_> celticminstrel: can you send a link. I cannnot find b757a67f8340ecbd8bc02c13058205e0fecd773e
20160905 18:15:26< celticminstrel> It's on the wml_tag_porting branch.
20160905 18:16:10< celticminstrel> Which is in the main repository.
20160905 18:16:50< tad_> 404 not found
20160905 18:17:32< celticminstrel> Could be found from something like https://github.com/wesnoth/wesnoth/tree/wml_tag_porting ? 
20160905 18:17:47< celticminstrel> If you wait a few more minutes I'll give you a definitely-working link.
20160905 18:17:51< tad_> There are a lot of commits there.
20160905 18:17:59< tad_> np
20160905 18:17:59< celticminstrel> It's the modify_side one.
20160905 18:18:04< celticminstrel> Or you can wait.
20160905 18:18:10< tad_> OK. I see one with that name
20160905 18:18:31< tad_> "Properly port [modify_ai] to Lua"
20160905 18:18:38< celticminstrel> No, modify_side.
20160905 18:18:42< celticminstrel> Not modify_ai.
20160905 18:19:01< tad_> next one in the list.
20160905 18:20:02< gfgtdf> celticminstrel: i wonder whetehr it'd make sense to add methods to lua side metatables like wesnoth.sides[1]:matches( { .. } ) or similar
20160905 18:20:03< tad_> That certainly will change things. Deletes the entire funtion where the error was created.  OK. I will test
20160905 18:20:14< celticminstrel> gfgtdf: Absolutely.
20160905 18:20:46< celticminstrel> gfgtdf: Do you think it would make sense to do something similar with unit attacks, though?
20160905 18:20:58-!- fabi_ [~fabi@176.4.56.57] has quit [Ping timeout: 265 seconds]
20160905 18:21:03< gfgtdf> celticminstrel: also wesnoth.get_starting_location(i) shoudl make be changes to wesnpt.sides[i].starting_location
20160905 18:21:22< celticminstrel> ...the way you phrased that suddenly made me possibly realize something.
20160905 18:21:23< gfgtdf> celticminstrel: hmm do you have an example method ?
20160905 18:21:36< gfgtdf> for attack i meant
20160905 18:21:51< celticminstrel> The unit methods could be put in the unit metatable, couldn't they? Instead of being returned by impl_unit_get.
20160905 18:22:10< celticminstrel> gfgtdf: Something like unit.attacks[1]:matches{range='melee'} ?
20160905 18:22:59< gfgtdf> celticminstrel: hmm yes makes sense to me.
20160905 18:23:39< gfgtdf> celticminstrel: hmm i tthought the unit are some lightuserdata objects that have on real metatalbe? Not sure though
20160905 18:23:50< celticminstrel> No, they're full userdata.
20160905 18:24:27-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160905 18:24:58< celticminstrel> I don't think Wesnoth uses light userdata for any API stuff (only for internal stuff).
20160905 18:25:33-!- fabi_ [~fabi@176.4.56.57] has joined #wesnoth-dev
20160905 18:27:22 * celticminstrel has an idea for naming a hypothetical drop-down list class that allows you to select any number of items before dismissing: drop_down_set.
20160905 18:29:45-!- fabi_ [~fabi@176.4.56.57] has quit [Ping timeout: 244 seconds]
20160905 18:30:01-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Ping timeout: 255 seconds]
20160905 18:31:27< celticminstrel> So, gfgtdf, are you planning to implement something along those lines?
20160905 18:33:24< gfgtdf> celticminstrel: no it was just a random thougth when i was looking at the wml_tag_porting branch.
20160905 18:33:45< celticminstrel> Okay, I'll add it to my list then. Not sure when I'll get to it though.
20160905 18:33:55< celticminstrel> Maybe soon, maybe not.
20160905 18:34:51-!- Polsaker [~Polsaker@wikimedia/botters.Polsaker] has quit [Ping timeout: 276 seconds]
20160905 18:38:54< gfgtdf> celticminstrel: https://gna.org/bugs/?25041
20160905 18:39:37-!- Kwandulin [~Miranda@p200300760F424134B4F4852CDAC4B0A1.dip0.t-ipconnect.de] has quit [Quit: Kwandulin]
20160905 18:40:40-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160905 18:47:38-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20160905 18:59:51< celticminstrel> gfgtdf: That was already brought to my attention.
20160905 19:00:17< celticminstrel> For some reason, after idling at the titlescreen for awhile, the game stops responding to input.
20160905 19:00:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 276 seconds]
20160905 19:04:42< gfgtdf> celticminstrel: hmm never happend to me
20160905 19:04:48< gfgtdf> celticminstrel: id you try debugging it ?
20160905 19:04:51< gfgtdf> did*
20160905 19:05:02< celticminstrel> Not yet.
20160905 19:05:17< celticminstrel> Might not bother.
20160905 19:06:15-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160905 19:07:04< gfgtdf> celticminstrel: i wonder whether we shodul try to add a [add_side] tag to add a side dynamically to a scneario, this can be useful specially in [modification]s. where its not possible to define sides
20160905 19:08:38< celmin> Also, I was unable to drag the size sliders when creating a new scenario.
20160905 19:08:41< celmin> Is that also just me?
20160905 19:09:07< celmin> gfgtdf: Well, there are two ways of interpreting this. Adding a side in [modifications] may be a different thing than adding a side dynamically during play.
20160905 19:09:55< gfgtdf> celmin: hmm any opinion about whetehr to implement any of them or which one would be better?
20160905 19:09:57< celmin> For the former, supporting [side] in [modifications] would probably be sufficient - it just needs to merge those sides into the scenario after the configure stage.
20160905 19:10:26< gfgtdf> celmin: you mean the random maps settings ?  I didnt encounter problmes there
20160905 19:10:46< celmin> No, not random maps. Map size.
20160905 19:11:03< celmin> For the latter, you'd be adding a new side to the existing teams vector. It would be more flexible, I guess, but are there any cases in which new sides are dynamically needed that cannot be anticipated at the start of the scenario?
20160905 19:11:13< celmin> I suspect the latter way might actually be easier to do, too.
20160905 19:11:33< celmin> Though both seem like they'd be fairly easy.
20160905 19:11:55< gfgtdf> hmm that is actuall he onyl slider i see in the mp create dialog.
20160905 19:12:09< celmin> This is in the scenario editor.
20160905 19:12:14< celmin> Sorry for ambiguity.
20160905 19:12:29< gfgtdf> ok will try
20160905 19:12:35< gfgtdf> in the editor i mean
20160905 19:13:08< gfgtdf> celmin: no problems for me in that slider
20160905 19:13:20< celmin> 'kay, weird
20160905 19:14:06-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has quit [Quit: Leaving]
20160905 19:14:31-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has joined #wesnoth-dev
20160905 19:16:06< celmin> Looks like #25041 is easily fixable, though the fix is not on the quoted line.
20160905 19:16:20< celmin> There should be no need for a check there.
20160905 19:19:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160905 19:21:15< gfgtdf> celmin: how exactly do i use impl_unit_type_lookup with unit varaiions ?
20160905 19:21:38 * celmin notes that I already have a fix for #25041 locally.
20160905 19:21:41< celmin> What do you mean?
20160905 19:22:12< celmin> It'll be called by wesnoth.unit_types["Walking Corpse"].variations.drake, for example.
20160905 19:23:17< gfgtdf> ah ok
20160905 19:23:32< celmin> So that answers your question, okay.
20160905 19:24:03< gfgtdf> celmin: wait, does for k,v in ipairs(wesnoth.unittypes)not alos iterate over each child type ?
20160905 19:24:16< celmin> It only iterates over base unit types.
20160905 19:24:32< celmin> To interate over all variations you'd need a nested loop as well.
20160905 19:25:00< celmin> Also, currently male/female variations aren't iterated over.
20160905 19:25:15< celmin> Iteration excludes the keys male, female, base.
20160905 19:25:33< celmin> I think that should probably change, though.
20160905 19:28:42< shadowm> Rhonda: I've told you and Soliton that Dave is (or was, at the time) willing to buy us anything we could need for that purpose, we just needed someone able to tell him _what_, and then maintain it.
20160905 19:29:08-!- ancestral [~ancestral@209.181.254.220] has joined #wesnoth-dev
20160905 19:29:16< gfgtdf> celmin: ah ok the UnitTypeTable is used for bowth wesnoth.types and unit.variations
20160905 19:29:22< celmin> Yeah.
20160905 19:30:06< celmin> Why is visible_itmes_ 1 for this listbox scrollbar… :|
20160905 19:30:08< celmin> ^items
20160905 19:31:45< gfgtdf> celmin: hmm maybe the listbox is very small so that onyl 1 item is visible?
20160905 19:32:10< celmin> No, it has lots of items and some are not visible.
20160905 19:32:42< celmin> Ah, I see.
20160905 19:32:47< shadowm> Rhonda: And yes, the expression "blame" there was intended tongue-in-cheek but not without a certain degree of factual truth. I honestly have no idea why the person with the least energy and experience seems to be expected to become responsible for us paying for a service that costs actual money. I thought I made it very clear during the wesnoth.org migration that I didn't know what I was ...
20160905 19:32:53< shadowm> ... doing and that I was extremely anxious throughout the whole ordeal in fear of screwing things up for everyone.
20160905 19:32:53< celmin> It's related to the fact that it was called from pre_show. :|
20160905 19:34:27< celmin> gfgtdf, vultraz: Any idea how I can test if a listbox's items are all visible from pre_show?
20160905 19:34:41< celmin> It seems like it doesn't calculate this until after, normally.
20160905 19:34:45< shadowm> Rhonda: Finally, I don't see how blaming someone for something that has not happened and that has not turned into a disaster _yet_ can be compared to telling someone to kill themselves? Or was that intended as a retort? Because I'd be honestly disappointed if it's the latter.
20160905 19:36:18< celmin> I also need to make this button fill all the horizontal space...
20160905 19:42:14-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160905 19:43:46< tad_> celmin: I can't get that commit from the wml_tags.... branch to merge. I think I have it downloaded but can't figure out how to merge it to master so I can test it. 
20160905 19:44:09< tad_> celmin: What I do know is if I revert that old commit, the engine does not give the errors, or crash
20160905 19:45:04< tad_> celmin: So, I wondering if it might not be best to revert and not worry because your branch for the wml changes completely replaces the bad function, anyway.
20160905 19:45:41< celmin> Possibly. That commit did also fix an issue in [modify_side][ai], though.
20160905 19:52:20< tad_> celmin: So, it seems there's three ways to go: ignore the errors and await your rewrite, revert the commit which causes the errors, or try to dig into the change from that commit and try to fix what it broke.
20160905 19:52:44< celmin> mattsc: What do you think?
20160905 19:52:50< celmin> Do you remember what issue that fixed?
20160905 19:58:30-!- JyrkiVesterinen [~jyrki@89-166-100-155.bb.dnainternet.fi] has quit [Quit: .]
20160905 19:58:57-!- Polsaker [~Polsaker@wikimedia/botters.Polsaker] has joined #wesnoth-dev
20160905 19:59:55< mattsc> celmin: “20160803 02:17:28< mattsc> Does [modify_side][ai]aggression=1 … not work any more?"
20160905 20:00:10< mattsc> That’s the issue it fixed, according to the logs leading up to that commit.
20160905 20:00:40-!- ancestral [~ancestral@209.181.254.220] has quit [Quit: i go nstuf kthxbai]
20160905 20:01:06< tad_> Sounds like revert is not a good idea. So finding the bug it is?
20160905 20:01:29< celmin> Finding the bug doesn't feel useful if it'll soon be overwritten.
20160905 20:01:40< celmin> On the other hand, vultraz does want a new dev release soon.
20160905 20:03:03< tad_> At present, the effect of the bug is spurious errors from unknown aspects after a modify_side .. unless there is no attack_depth .. if someone removes attack_depth, it's a hard crash if they did it in a modify_side
20160905 20:04:18< celmin> Hmm.
20160905 20:04:58< tad_> I'm happy enough to know where to look if it because a serious problem. For now a note about a known problem works for me.
20160905 20:04:58< celmin> Looking at the commit, I honestly can't see how that could cause a problem unless a) there's something wrong in the config class or b) one or more of the used functions has subtly different semantics than I expected.
20160905 20:05:33< celmin> In particular, as far as I can tell, the configs here are always copied, not referenced.
20160905 20:05:57< tad_> That old commit is pretty simple. So it's a subtle error deeper in .. my guess would be uninitialized data someplace or a faulty assumption somethign exists which doesn't
20160905 20:07:23< celmin> If I recall correctly, it only happened in one of the two following cases? 1) If the modify_side is triggered before that side gets a chance to move. 2) If the modify_side is triggered during that side's move or after they have moved at least once.
20160905 20:07:35< tad_> I tracked  it down because mattsc asked if it was related to a refactoring celmin did. So I wanted to find which. Makes it easier because it was beating me up trying just to find it. Now I know where to look, at least.
20160905 20:08:33< tad_> The bad_lexical_cast crash occurs after (1) [modify_side][ai] omits attack_depth, then (2) side recruits and (3) during save-turn write phase for next turn
20160905 20:08:58< celmin> So, only the else branch in modify_side_ai_config.
20160905 20:10:27 * tad_ shrugs. I'm not really started to analyze it. To this point I've been simply bisecting and testing that a revert of that specific commit causes the crash and errors to go away. Don't know what it re-introduces (sounds bad, though, now). And have not started debugging what the commit did and why the change causes the crash
20160905 20:12:02< Rhonda> shadowm: I don't get "why the person with the least energy and experience seems to be expected to become responsible", at all.  Totally lost there with that reasoning.
20160905 20:13:37< tad_> celmin, mattsc so I'm giving it a bit here in the hopes of a face-palm before I start in with a code-read and some gdb
20160905 20:13:47< Rhonda> And the kill "yourself" was related to figuratively speech, solely.  I don't like that as an excuse, and I don't like to be blamed publicy, that rather makes me do way less then more.  If you want me out just say it, you (not you personally, but in general) don't have to play blame games for that.
20160905 20:14:03< celmin> I'll take a quick look at add_aspect.
20160905 20:14:10< celmin> Sorry, add_facet.
20160905 20:15:22< tad_> side 2 : UNKNOWN aspect[villages_per_scout*ai_default_rca::aspect_attacks] .. without atack_depth .. with attack_depth the message is about village_value
20160905 20:15:57< celmin> I guess I can look at expand_simplified_aspects too...'
20160905 20:19:03-!- jamit [~jamit@97-87-12-18.dhcp.mdsn.wi.charter.com] has left #wesnoth-dev []
20160905 20:19:29< gfgtdf> tad_: can you easily find the lexical_cast with 'break on throw' ine the debugge and then suporround it with a try catch ?
20160905 20:20:04< celmin> gfgtdf: He already found it. The throw should not happen in that context.
20160905 20:20:18< tad_> gfgtdf: Been there done that and walked the back-trace. I can see it's trying to cast something from "" to something else. Issue is why
20160905 20:20:56< gfgtdf> tad_: you still have teh stacktrace ?
20160905 20:21:10< celmin> It was lexical_cast<std::string>(s) where s is ""
20160905 20:21:44< tad_> celmin: Looks to me at first blush that what you're doing is trying to replace [side][ai] with [modify_side][ai] and I know the original is === the new so it must be something got changed during the recruit and so a ref go orphaned ???
20160905 20:22:06< celmin> What?
20160905 20:22:08< tad_> gfgtdf: No but I can get it back any time.
20160905 20:22:12< celmin> I dunno.
20160905 20:23:34< tad_> celmin: I know that what [side][ai] said and what [modify_side][ai] said are the same because it's a macro common to both. The difference as I see it is a recruit cycle happened after the modify side tag executed.
20160905 20:24:39< tad_> And the issue pops up because we're seralizing for the start-of-turn save.
20160905 20:25:46< tad_> gfgtdf: So we know where the cause is (in general) and where it blows up (specifically) and the question is the best way to fix what broke without un-fixing what needed to be fixed :P
20160905 20:31:40< celmin> I can't see anything obviously bad in add_facet.
20160905 20:38:37< tad_> hmm .. "for (const config& cfg : ai_parameters) {" .. for each parameter in the [modify_side][ai] sub-tag, add to the [side][ai] sub-tag .. did the original get removed or is this adding a scond copy?
20160905 20:39:42< tad_> Oh .. target (cfgs) is default initialized. OK.
20160905 20:39:52< celmin> ai_paramaters is an iterator range (so, like a reference).
20160905 20:40:04< celmin> So it's basically making a copy.
20160905 20:42:51< tad_> I'm code-reading .. up to your add_facet you just looked at. It's slowly making sense to me. but then, it's add_facet and I wonder if the facet is already there
20160905 20:43:39< celmin> It shouldn't matter if it is - it would just add a redundant duplicate.
20160905 20:44:45-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Remote host closed the connection]
20160905 20:45:35< tad_> Still, what if that duplicate is what's causing the problem .. first copy writes something .. second can't find that thing and it's using "" as a fallback?
20160905 20:45:46-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160905 20:46:02< tad_> I'm just throwing out ideas here .. still trying to read the code. 
20160905 20:46:37< tad_> What bothers me is that we know something needs to change after because we need a recruit cycle after this code runs and before serialization to cause the error.
20160905 20:46:46< tad_> So we may be in the wrong area, anyway.
20160905 20:48:05< celmin> I think I misunderstood something earlier.
20160905 20:48:40< celmin> So, it happens if modify_side occurs before the AI recruits.
20160905 20:48:43< celmin> ?
20160905 20:50:12< tad_> The [side][ai] reads the same. No errors on first recruit. We take the citadel which executes the [modify_side][ai], end-turn to recruit (undead, now) and it crashes serializing the save for the upcoming turn
20160905 20:50:38< celmin> I see.
20160905 20:51:14< tad_> And note: we MUST NOT have attack_depth to crash. If we have attack_depth all we see is message about UNKNOWN aspect when the recruit happens (for undead)
20160905 20:52:20< tad_> And the unknown aspect message changes from village_value (attack_depth present) to villages-per-scout (nor present).
20160905 20:53:08< celmin> I don't suppose removing the recruit list change affects anything.
20160905 20:53:27< tad_> Give me a moment to test that.
20160905 20:53:34< celmin> I guess it's unlikely.
20160905 20:53:43< celmin> Oh, the recruitment pattern maybe.
20160905 20:54:41< tad_> I am half-way through a rebuild to current master. 
20160905 20:54:50< tad_> so it'll be a while befire I can test reliably.
20160905 20:55:46< tad_> But I can easily yank the other changes and have just the [modify][ai] with no real change and test with and without attack_depth
20160905 20:58:20< tad_> I can also run a test with gold=0 to suppress the actual undead recruitment and see if that's really part of the crash 
20160905 20:58:34< celmin> Okay.
20160905 20:59:13< tad_> I will need to drop offline to link with debug symbols so I'll do a series of tests and get back to you when they're done.
20160905 20:59:32< celmin> Okay.
20160905 20:59:36-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160905 21:03:29-!- prkc [~prkc@catv-80-98-160-168.catv.broadband.hu] has quit [Read error: Connection reset by peer]
20160905 21:04:33-!- edgrey [~edgrey@178.204.2.238] has quit [Ping timeout: 240 seconds]
20160905 21:04:54-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160905 21:05:31-!- gfgtdf [~chatzilla@x4e36ae3c.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160905 21:06:03< vultraz> [06:34:24]	celmin	gfgtdf, vultraz: Any idea how I can test if a listbox's items are all visible from pre_show?
20160905 21:06:36< vultraz> celmin: list.get_rows_shown().size() == list.get_item_count()
20160905 21:07:02< celmin> That definitely works in pre_show?
20160905 21:07:27< vultraz> as long as you do it *after* adding the rows :P
20160905 21:07:38< vultraz> (I think)
20160905 21:07:39< celmin> Obviously. :P
20160905 21:07:47< celmin> I'll try it.
20160905 21:08:34< celmin> Hmm, thinking about it, it seems like it wouldn't work… but I'll try it anyway.
20160905 21:08:34< vultraz> btw, i expected it would fail without the scrollbar
20160905 21:09:37< celmin> Hm?
20160905 21:10:40< vultraz> the placement code isn't that great at accounting for not enough space sometimes
20160905 21:11:02< celmin> Because no-one bothered to implement demand_reduce_size.
20160905 21:11:13< vultraz> oh?
20160905 21:12:23< celmin> demand_reduce_height and demand_reduce_width, that is.
20160905 21:12:49< celmin> They're just stubs, but they were supposed to be a fallback in the event that request_reduce_* failed.
20160905 21:12:55< vultraz> sounds like something we need to do
20160905 21:13:07< celmin> If possible.
20160905 21:13:40< celmin> Not sure if they're unimplemented for everything, I was only looking at grids.
20160905 21:14:53 * vultraz is pondering a design decision for tgroup.
20160905 21:15:02< celmin> Oh?
20160905 21:16:06< vultraz> I realized a small oversight: if you disable (gray out) a member of the group for some reason, it should not remain selected
20160905 21:16:35< celmin> Hmm.
20160905 21:16:51< celmin> I feel like maybe that should be handled by whoever's graying out the member.
20160905 21:17:15< celmin> Since there's no general way to select an alternate option that I can think of.
20160905 21:17:57< vultraz> I'm thinking of a general 'first available option'
20160905 21:18:58< celmin> I guess
20160905 21:19:35< celmin> So basically something like group.set_item_active(i, true|false)?
20160905 21:19:47< vultraz> yes
20160905 21:20:13-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds]
20160905 21:20:43< vultraz> also, remind me again why group.members() returns an iterator range?
20160905 21:21:06< vultraz> was that for BOOST_FOREACH before we had range-for?
20160905 21:21:11< celmin> Hm, I can't navigate menus with the keyboard.
20160905 21:21:28< Aginor> celmin: has that ever been supported?
20160905 21:21:40< vultraz> you need to keyboard capture the list
20160905 21:21:43< celmin> Aginor: No idea, but it should be trivial to add now.
20160905 21:22:30< vultraz> window.keyboard_capture, that is.
20160905 21:23:01< celmin> vultraz: Looks like testing shown items against item count does not work.
20160905 21:23:07< vultraz> hm.. tgroup includes utils/iterable_pair.hpp.. but does tgroup need an iterator pair?
20160905 21:23:11< vultraz> that's what I'm wondering
20160905 21:23:51< vultraz> celmin: meh. perhaps you wanted some other form of 'shown'?
20160905 21:24:09< vultraz> that function tells you if the row is not hidden ie with set_row_shown
20160905 21:24:17< celmin> I don't think shown is actually related to whether the row is visible on the screen.
20160905 21:25:08< vultraz> you likely want something with content_visible_area
20160905 21:25:17< vultraz> which is a rect
20160905 21:26:48< celmin> My suspicion is that that would fail for the same reason that list.vertical_scrollbar_at_end() failed.
20160905 21:26:59< vultraz> bah!
20160905 21:27:13< celmin> Namely, that the layout hasn't yet been calculated.
20160905 21:27:39< vultraz> post_build? :)
20160905 21:27:45< celmin> That's before pre_show.
20160905 21:27:50< vultraz> ah
20160905 21:27:52< vultraz> hm
20160905 21:27:56< vultraz> I thought there was something else
20160905 21:28:23< vultraz> no 
20160905 21:30:01-!- mjs-de [~mjs-de@x4db5a2dc.dyn.telefonica.de] has joined #wesnoth-dev
20160905 21:41:39< celmin> Now I'm trying to get it to work with a timer.
20160905 21:43:09< vultraz> what is the problem now?
20160905 21:43:51< celmin> I think the trigger point between "it doesn't work" and "it works" is the draw event, actually, so I could also try conecting a signal to that (though that feels really hacky).
20160905 21:44:37< celmin> The problem is basically that the window layout has not yet been done when pre_show is called, but I need to be able to hide buttons if there's no need for scrolling.
20160905 21:46:34< vultraz> does it work otherwise?
20160905 21:46:40< vultraz> do the buttons scroll?
20160905 21:47:01< celmin> If I leave them visible initially, then it works. They scroll, and hide when not needed.
20160905 21:47:03-!- irker151 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160905 21:49:51< celmin> A timer of 100 works, but leaves an artifact.
20160905 21:51:32-!- Appleman1234 [~Appleman1@KD119104114246.au-net.ne.jp] has quit [Ping timeout: 240 seconds]
20160905 21:52:09< vultraz> why not hide the buttons in pre_show?
20160905 21:52:29< vultraz> oh, I see
20160905 21:52:47< celmin> So, tscroll::ITEM_FORWARD is utterly useless.
20160905 21:52:54< celmin> It scrolls by one pixel.
20160905 21:53:13< celmin> Maybe I'll change it to scroll by 5 or 10 pixels.
20160905 21:53:24< celmin> That'd help a bit, at least, though it's still not doing what it claims.
20160905 21:53:35< vultraz> that's odd
20160905 21:53:40< vultraz> the sliders use that
20160905 21:53:46< vultraz> and it jumps to the next item
20160905 21:53:57< vultraz> I think it must be an implementation thing..
20160905 21:54:01< celmin> The reason isn't really ITEM_FORWARD's fault though, it's that the concept of "items" in a scrollbar is apparently linked to pixels.
20160905 21:54:19< vultraz> yeah..
20160905 21:54:22< vultraz> which is not great :/
20160905 21:54:34< celmin> Yeah, but it's probably not generically fixable.
20160905 21:54:53< vultraz> but I have observed this 1-pixel behavior in certain cases..
20160905 21:55:02< vultraz> where scrolling isn't properly handled..
20160905 21:56:04< celmin> If you want to observe it, edit the scrollbar definitions in data/gui/macros and change the button IDs to _line_up and _line_down (something like that)
20160905 21:57:39< vultraz> (if I use find_if with end, begin, will it search in reserve order?)
20160905 21:57:56< celmin> No.
20160905 21:58:08< celmin> There's rbegin and rend for that.
20160905 21:58:16< celmin> rbegin points to the end, rend to the beginning.
20160905 21:58:24< celmin> However, there's a small caveat there too.
20160905 22:01:33-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160905 22:02:59-!- mjs-de [~mjs-de@x4db5a2dc.dyn.telefonica.de] has quit [Remote host closed the connection]
20160905 22:04:12-!- Appleman1234 [~Appleman1@KD119104108239.au-net.ne.jp] has joined #wesnoth-dev
20160905 22:07:13< celmin> vultraz?
20160905 22:07:22< vultraz> hm?
20160905 22:08:06< celmin> Not using that?
20160905 22:08:14< vultraz> what?
20160905 22:08:19< vultraz> rbegin/rend is fine
20160905 22:08:37< celmin> Were you only testing that an element exists?
20160905 22:09:09< celmin> …well, whatever.
20160905 22:09:24< celmin> The caveat only occurs if you really need a normal 
20160905 22:09:29< vultraz> hm..
20160905 22:09:33< celmin> (non-reverse) iterator.
20160905 22:09:52< vultraz> well I did need that :P
20160905 22:10:03< celmin> Did? Not do?
20160905 22:10:14< vultraz> but I just realized this is rather unexpected behavior, so perhaps I shouldn't do it
20160905 22:10:21< celmin> What is it?
20160905 22:10:36< vultraz> I was going to loop backwards through all members and activate the first enabled one...
20160905 22:11:00< vultraz> really, I might be over-engineering this
20160905 22:11:07< vultraz> and should just go with 'first in group'
20160905 22:11:24< celmin> First enabled in group seems easiest.
20160905 22:13:57< vultraz> but what if the first is also disabled...
20160905 22:14:02< celmin> Ooh, cppreference.com has a nice diagram.
20160905 22:14:13< vultraz> guess i should do... first non-disabled
20160905 22:14:23< celmin> Unlike cplusplus.com...
20160905 22:14:49< vultraz> I prefer cppreference.com, 
20160905 22:15:19< celmin> So basically the caveat is that if you have a reverse iterator and need to get a regular iterator, it's it.base() - 1.
20160905 22:15:44< celmin> Not just it.base().
20160905 22:15:44< vultraz> I see
20160905 22:18:40< celmin> So the cause of this is tscrollbar_container::place().
20160905 22:25:58-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160905 22:31:15-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160905 22:31:59< tad_> celmin: Testing complete. The errors depend on the macro.  Full results in https://github.com/GregoryLundberg/wesnoth/issues/28
20160905 22:34:15-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160905 22:34:16< tad_> mattsc: [modify_side][ai] error and crash I'm using TSG S02 to test, results are in my issue.
20160905 22:34:45< celmin> Ugh, why can't I just view the file online. :(
20160905 22:35:09< tad_> I can paste it .. hang on
20160905 22:35:11< celmin> So when you say "no effect" you mean there's no crash, and no warning?
20160905 22:35:14< celmin> No, I got it.
20160905 22:35:17< tad_> correct
20160905 22:35:41< tad_> Or it still crashed or errored.
20160905 22:35:47< tad_> Sorry.
20160905 22:36:00< tad_> "No effect" means it did not appear to be related to the issue.
20160905 22:36:24< celmin> So it means "warning with attack depth, crash without"?
20160905 22:37:21< tad_> I tested those against master(clean) then modified that one factor. I got the error message and no crash so I declared it not related. I may be wrong, of course.
20160905 22:37:30< celmin> Okay.
20160905 22:37:56< tad_> I tested the 16 combinations for the macro. I didn't test the other several-hundred adding those in would make.
20160905 22:38:18< celmin> So it's interesting that if village_value is commented, the warning is instead for {NO_SCOUTS} which sets villages_per_scout...
20160905 22:38:58< tad_> What it makes clear to me is we're looking at two problems. One causing the error message and the other causing the crash. And it seems the macro lines for one are not related to the other.
20160905 22:39:44< tad_> {NO_SCOUTS} and village_value for the message.  attack_depth and grouping=no for the crash
20160905 22:40:48< tad_> Or that's how it seems
20160905 22:41:19< celmin> Interesting.
20160905 22:41:36< celmin> So disabling attack depth crashes, but disable grouping too and it works.
20160905 22:41:43< tad_> Yep.
20160905 22:42:25< tad_> And the error message seems related to the last two lines, but possibly related to removing one, two, or three things .. sorta hard to tell.
20160905 22:42:51-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20160905 22:43:07< tad_> But note the sequence on screen: [message] recruit undead / error message [message] crash-or-not
20160905 22:43:29< celmin> Huh?
20160905 22:44:22< tad_> The message appears when the first undead appears. The crash when we do the [message] triggered by the undead appearing and proceed to prepare for End Turn to be pressed (during serialization)
20160905 22:45:09< celmin> Ah.
20160905 22:45:56< tad_> The WML does a [message] then side 2 recruits and the appearance of the undead triggers a [message] .. the error is on console at that point .. then when I <enter> past the message it crashes and I know the crash is during serialization getting set for End Turn
20160905 22:48:11< tad_> Oh, and "Why now?" .. I'm up to the point on my code-read of DM where I know I'm going to start seeing these same messages (unknown aspect) so I decided to work on it with TSG because it's so much less to play with and so early in the campaign.
20160905 22:49:36< tad_> I could probably boil down a test-case scenario if we need one.
20160905 22:50:52< celmin> Have you gotten them in DM before?
20160905 22:52:30< celmin> I don't know how much a test-case would help, since I'm unable to reproduce it, but if it would help you, then go for it.
20160905 22:52:59-!- fabi_ [~fabi@176.4.56.57] has joined #wesnoth-dev
20160905 22:53:02< tad_> celmin: I believe so. But it's been a long time and my notes are old and scattered. I got up to the point where I think the changing leaders was causing problems and I seem to recall having them but having them go away when I cleaned up the side-changes for leader-changes.
20160905 22:53:10< shadowm> Rhonda: Why would I want one of the people with the most experience out? In your own words, I'm totally lost here with that reasoning.
20160905 22:53:35< tad_> celmin: can you run TSG atm?
20160905 22:53:57< tad_> I will put up my steps to produce the error on my issue if that would help.
20160905 22:54:01< celmin> Yes, I got past the crash on starting it (I think I must've had a bad build).
20160905 22:54:22< tad_> OK. Give me a minute to write up a repo for it. 
20160905 22:54:28< celmin> I've tried to reproduce it twice without any luck, but I suppose it's possible I wasn't quite doing it right.
20160905 22:55:03< shadowm> Rhonda: The facts are that wesnoth.org's migration was postponed for an enormous amount of time (over a *year*) because neither you nor Soliton ever got around to doing it, and because I had the time (but not the expertise) I ended up taking responsibility for it. By not being able to get it done much sooner, I became single-handedly responsible for wasting Wesnoth Inc's money by having to pay ...
20160905 22:55:09< shadowm> ... for two servers at once.
20160905 22:57:31< tad_> celmin: My steps are on my issue, now.
20160905 22:57:32< shadowm> Rhonda: I repeatedly asked for help throughout the entire process, I stated several times that I didn't know what I was doing, and while I did get help in the form of general instructions and answers to specific questions, I still had to do pretty much all the work, reading manuals, inputting commands, rethinking past design decisions that weren't my own, and at the same time serving as the ...
20160905 22:57:38< shadowm> ... front face for the community and taking responsibility for anything that could have gone wrong.
20160905 22:58:38< shadowm> Rhonda: After that ordeal I simply don't want to be responsible for big wesnoth.org things again and that's why I haven't gone and taken a course on how to safely backup things remotely.
20160905 22:59:32< celmin> I never got Sir Gerrick when I tested.
20160905 22:59:41< shadowm> Rhonda: Which means that 1) I cannot recommend or request any specific service from Wesnoth Inc and I expect the people who actually know what they are doing to do it so I don't waste anyone's time or money again; 2) I cannot even consider helping until I actually know what it is we will be using.
20160905 22:59:54< celmin> Maybe that's relevant.
20160905 23:00:25< shadowm> Rhonda: And honestly, I'm not sure why you keep reading everything I say as a personal attack on people. It's a very common expression here and in other English-speaking communities to say "blame xyz" without actually meaning it in a hostile fashion.
20160905 23:02:13< shadowm> Rhonda: And comparing it to telling someone to kill themselves is not at all acceptable or reasonable. I actively avoid using the latter expression because I usually don't know who I am talking to and whether they might take it seriously. Having dealt with people with suicidal thoughts and being one myself I feel I'm not being unreasonable if I ask you to not do that.
20160905 23:02:59< shadowm> There, I said it in a logged channel. I hope people feel happier now.
20160905 23:03:23< shadowm> Because I haven't for the past 10 years.
20160905 23:05:23 * celmin hugs shadowm 
20160905 23:05:58 * Aginor gives shadowm support
20160905 23:05:59 * vultraz sends shadowm kittens
20160905 23:25:02< shadowm> Rhonda: So, to make things clear, I consider you a much more valuable asset to the wesnoth.org team than I am, I do not want you out or replaced. All I'm asking for here is a little understanding that I'm not technically qualified to take care of certain stuff, so if that stuff isn't being taken care of, that responsibility falls back on my seniors i.e. you and Soliton. That's all.
20160905 23:25:47< celmin> Blargh, it seems I can't use std::accumulate because the generator does not provide iterator access to the items...
20160905 23:29:06< shadowm> Rhonda: And I'm sorry if that offends you in some way. And if we can't reach an understanding, I can always remove myself and I don't think that will impact things very much since I don't really do (or have to do) much anymore other than menial housekeeping tasks with the wiki and forums and tending to the occasional support request.
20160905 23:29:38 * shadowm is off again.
20160905 23:37:45-!- louis94 [~~louis94@91.178.241.125] has quit [Ping timeout: 276 seconds]
20160905 23:39:20< Rhonda> shadowm: And yet you think "blame xyz" can't be taken offensive?  Interesting approach.
20160905 23:39:50< Rhonda> But yes, blame me for not feeling too well about being blamed.
20160905 23:41:01< celmin> I seem to recall that multi-row horizontal listboxes aren't supported. Wonder if that would be hard or worthwhile.
20160905 23:42:24< Rhonda> From what I understood the amount that people would liked to have backuped is quite huge, and we simly don't have the place anywhere to store it.  What is needed to decide what really should get backed up first, account to how much it is and how regularly it's needed, and we could look for a way.  Last we tried to figure it out wasn't it something around 120G or such?  Or am I remembering […]
20160905 23:42:30< Rhonda> […]things wrongly?  It was quite a lot though, maybe not that much but still too much that I could host the backup myself.
20160905 23:43:09-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160905 23:43:38< Rhonda> And no, I consider you much more valuable to the project than me.  You might consider me an elder, but you are more active, so don't belittle your contributions please. :)
20160905 23:48:57< celmin> He's not all that active nowadays though.
20160905 23:49:02< celmin> Probably about as active as you are.
--- Log closed Tue Sep 06 00:00:41 2016