--- Log opened Fri Sep 09 00:00:24 2016
--- Day changed Fri Sep 09 2016
20160909 00:00:24-!- fabi [~fabi@176.0.92.222] has quit [Ping timeout: 276 seconds]
20160909 00:00:33< celmin> Okay, so you want to set the default value of background_x, right?
20160909 00:00:35< celmin> Or something like that.
20160909 00:00:52< celmin> And you want the default value to be based on the width of the image.
20160909 00:01:02< vultraz> for this dialog
20160909 00:01:15< celmin> Why not just make the default value 0?
20160909 00:01:23< vultraz> no reason
20160909 00:01:33< vultraz> but then *how do I adjust the placement*?
20160909 00:01:35< celmin> Wait, what do you mean by "for this dialog"?
20160909 00:02:18< vultraz> I'm either adding a new definition borderless_with_background or adding this to borderless with default values
20160909 00:02:19< vultraz> but
20160909 00:02:25< vultraz> different borderless dialogs
20160909 00:02:28< vultraz> might want images
20160909 00:02:31< vultraz> in different places
20160909 00:02:34< vultraz> so how
20160909 00:02:36< vultraz> does one
20160909 00:02:37< vultraz> adjust the placement
20160909 00:02:39< vultraz> of the image
20160909 00:02:41< vultraz> on the canvas
20160909 00:03:09< vultraz> if not by using formula variables
20160909 00:03:12< vultraz> then how?
20160909 00:03:52< celmin> Obviously by using formula variables.
20160909 00:04:19< celmin> Hmm.
20160909 00:04:27< celmin> Looking at canvas.hpp.
20160909 00:04:35-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160909 00:05:00< celmin> You could 1) add a get_variable or 2) add a set_variable that takes a formula&
20160909 00:05:13< celmin> Both would be trivial.
20160909 00:05:59< vultraz> ok, if the latter is done
20160909 00:06:02< vultraz> how would that work
20160909 00:06:08< vultraz> it passes a formula, then what
20160909 00:07:20< vultraz> this is why i proposed allowing canvas access on a per-window basis, instead of just in definitions :/
20160909 00:07:29< vultraz> from wml, that is
20160909 00:07:55< vultraz> I don't see how that's impossible
20160909 00:08:50< celmin> void set_variable(formula& f) {variables_.add(f(variables_));} or something like that.
20160909 00:08:56< celmin> (And set the dirty flag.)
20160909 00:09:01< vultraz> you can access the window canvas from c++ on a dialog basis. why cannot wml canvas tags be applied when a window is constructed?
20160909 00:09:13< celmin> What?
20160909 00:10:15< vultraz> we have [*_definition] [resolution]  [background] [draw] [/draw] [/background] [foreground] [draw] [/draw] [/foreground [/resolution]
20160909 00:10:19< vultraz> why not in [window] too
20160909 00:10:49< celmin> That seems kinda...
20160909 00:11:00< celmin> Well, if you need to do that, why not just make a custom definition?
20160909 00:12:08< vultraz> because custom definitions on a per-window basis are a horrible, horrible paradigm to follow, especially if they're exactly the same except for one canvas tag
20160909 00:12:25< celmin> I don't see what's so horrible about it.
20160909 00:12:32< vultraz> it's messy?
20160909 00:12:35< vultraz> extra wml?
20160909 00:12:37< celmin> What's messy about it?
20160909 00:12:43< vultraz> you haven't forgotten that less wml == good, right?
20160909 00:12:47< celmin> Maybe if they're almost the same.
20160909 00:12:53< celmin> That part I can accept.
20160909 00:12:59< celmin> But in general, it seems fine.
20160909 00:13:10< vultraz> so far the uses are alright
20160909 00:14:25< tad_> What I think vultraz is concerned about is if the same-ness should actually BE the same and not simply appear to be at the moment.  Single-point-of-control 
20160909 00:14:59< celmin> Huh?
20160909 00:15:44< tad_> For example, if the rule is "all canvas have this background" then duplicating the background allows violation of the rule
20160909 00:17:16< vultraz> I'm more opposed to, for example, having three definitions that differ in only 6 lines each
20160909 00:17:24< vultraz> Not to mention, then there's no master control
20160909 00:17:34< vultraz> if I want to update the very back background
20160909 00:17:41< vultraz> I have to go to each one
20160909 00:17:45< vultraz> and update it
20160909 00:17:48< vultraz> instead of having one
20160909 00:17:55< celmin> Oh right, was Travis fixed yet… I seem to recall there was still a weird error...
20160909 00:18:13< vultraz> so..
20160909 00:18:15< vultraz> actually, yeah
20160909 00:18:17< vultraz> what tad_ said
20160909 00:20:08< vultraz> we already abuse macros due to a lack of prototype system 
20160909 00:20:15< vultraz> let's not perpetrate it :|
20160909 00:20:34< celmin> Not sure that's the only reason we abuse macros...
20160909 00:20:45< vultraz> not only, surely
20160909 00:20:58< vultraz> but look at a lot of the stuff in GUI2's WML
20160909 00:21:08< vultraz> different widget definitions, and only one small thing is changed
20160909 00:21:20< vultraz> yet ALLLLL the wml needs to be duplicated 
20160909 00:22:14< vultraz> we could likely cut the gui2 wml loading time by half
20160909 00:22:16< vultraz> or more
20160909 00:22:21< vultraz> with a prototype system in config
20160909 00:23:55< tad_> You mean something like [ThisWidget : baseWidget]optionMakingThisDifferent=value[/ThisWidget] ??
20160909 00:24:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160909 00:24:47< celmin> A prototype system in config would make the prototypal units thing fairly easy, but it would also reverse all gfgtdf's work to make it not directly access a config (which is supposed to make it faster or something?).
20160909 00:25:03-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 264 seconds]
20160909 00:25:20< vultraz> tad_: exactly like that, yes
20160909 00:25:35< celmin> Not quite like that.
20160909 00:25:52< celmin> [ThisWidget][base_widget] is probably more likely.
20160909 00:26:12< tad_> pfft. That would be nice to have in campaign WML, too.
20160909 00:26:31< celmin> Where?
20160909 00:26:41< celmin> It's currently supported in [unit_type] and nowhere else.
20160909 00:26:50< vultraz> I feel like [tag : id] would be a good syntax.
20160909 00:26:59< celmin> Ugh.
20160909 00:27:20< vultraz> or one could just do [tag] prototype_id = id
20160909 00:27:30< celmin> Yeah sure whatever.
20160909 00:27:31< vultraz> and anything inside [tag], subtags included, is considered a prototype
20160909 00:27:55< tad_> vultraz: if there is a good way to declare the base [id] tag, which allows "pure virtual tags"
20160909 00:28:00< celmin> I was thinking of prototypes only from the C++ side, not the WML side.
20160909 00:28:34< tad_> It's a **huge** language change. Probably not a good idea for 1.x series.
20160909 00:28:44< vultraz> well, protypes on the WML side would simply stuff like unit types.
20160909 00:29:01< celmin> No, I meant something like, add config::set_prototype()
20160909 00:29:05< celmin> But that's it.
20160909 00:29:37< vultraz> unit types already have a hacky prototype system of their own
20160909 00:29:40< vultraz> with inherits=
20160909 00:29:49< celmin> I think it's [base_unit]
20160909 00:29:52< celmin> Not inherits=
20160909 00:30:11< vultraz> inherits is for variations
20160909 00:30:18< celmin> What?
20160909 00:31:19< vultraz> inherit: if yes, inherits all the properties of the base unit, which are then overwritten by the keys and tags of this variation. Defaults to no.
20160909 00:31:24-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Read error: Connection reset by peer]
20160909 00:31:31< celmin> Ah.
20160909 00:31:34< vultraz> [base_unit]: Contains one attribute, id, which must be the ID of a unit type. If specified, the UnitTypeWML for that unit is copied into this one. Attributes in this unit overwrite the copy. Tags modify the corresponding tag of the original, so for example the first [attack] tag in the derived unit would modify the first attack of the base unit rather than defining a new attack. Additionally, the 
20160909 00:31:35< vultraz> unit will be marked as variation of the base unit in its own help page, but not in the help page of the base unit.
20160909 00:31:39< vultraz> so, similar
20160909 00:32:11< vultraz> introducing prototypes into wml would allow this to be separated from the unit type system.
20160909 00:33:03< vultraz> I don't think this would be that hard to implement, either
20160909 00:33:10< vultraz> we already have config::merge
20160909 00:33:14< tad_> It's probably a very good idea and, if I took a couple hours, I could probably come up with some reasonable use cases.
20160909 00:33:21< celmin> Well, this is totally different from merge though
20160909 00:33:50< vultraz> or perhaps inherit::from
20160909 00:33:53< vultraz> 	/**
20160909 00:33:54< vultraz> 	 * Merge config 'c' into this config, preserving this config's values.
20160909 00:33:56< vultraz> 	 */
20160909 00:33:59< celmin> ?
20160909 00:34:01< vultraz> inherit_from
20160909 00:34:05< vultraz> config::inherit_from
20160909 00:34:13< celmin> config::set_prototype
20160909 00:34:31< vultraz> inherit_from is an existing function
20160909 00:34:37< celmin> ?
20160909 00:34:51< celmin> So it's sort of a reverse merge?
20160909 00:34:54< vultraz> yes
20160909 00:35:01< vultraz> the functionality we need already exists
20160909 00:35:03< celmin> Could probably just remove that then.
20160909 00:35:10< celmin> No, that's not the functionality we want.
20160909 00:35:33< vultraz> how would you implement it, then?
20160909 00:35:36< tad_> I'd want to see a bit of analysis and design, though. It may be as simple as copy a base config into this (empty) config before processing the attributes and tag (ie., merge to init) but there may be issues which don't immediately come to mind which might need more work than a simple merge
20160909 00:36:01< celmin> config::set_prototype stores a reference to (or possibly copy of) the passed config.
20160909 00:36:13< celmin> Then operator[] looks there if it doesn't exist in the base config.
20160909 00:36:40< vultraz> set_prototype doesn't exist yet, just saying
20160909 00:36:43< celmin> For children I think it'd probably look there if no child of that tag exists in the base config.
20160909 00:36:45< celmin> Obviously.
20160909 00:37:07-!- irker852 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160909 00:38:04< vultraz> either way, I don't think this would be that difficult 
20160909 00:38:19< vultraz> it could likely be done in a few days if we wanted
20160909 00:38:35< celmin> Yeah, it's easy to implement it into config.
20160909 00:38:45< celmin> The only minor question is how it works with child tags.
20160909 00:40:14-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 00:40:18< tad_> Assume we have a reference to a base type for this WML tag. Let's say it's a [tad] tag which is a die event .. how do we (1) have [tad] require users to give an id= for [tad]s filter, or (2) allow users to remove [tad]s [endsenenrio]result=defeat?
20160909 00:40:28< vultraz> merge recursively. SO [foo] [a] [b] [/b] [/a] [/foo] ... [bar] [a] [b] [/b] [/a] [/bar] becomes [foo] [a] [b] [/b] [b] [/b] [/a] [/foo]
20160909 00:41:02< celmin> vultraz: That's too hard to understand on one line.
20160909 00:41:12< vultraz> I shall make a pastebin
20160909 00:41:22< celmin> But I have Firefox closed… guess I can open it.
20160909 00:41:40-!- gfgtdf [~chatzilla@x4e3697bb.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160909 00:41:41< tad_> vultraz: nah "merge recusively" is enough 
20160909 00:42:40< vultraz> eh ok
20160909 00:42:49< celmin> vultraz: The other possibility is to treat each possible tag as a "variable".
20160909 00:42:53< vultraz> i made a mistake in my example anyway
20160909 00:43:14< tad_> My point being, merge is fine for adding and probably can handle replacing, but how would it handle deleting?
20160909 00:43:40< celmin> Good point.
20160909 00:43:46< vultraz> good point
20160909 00:44:07< tad_> As I said, needs analysis.
20160909 00:44:33< vultraz> what about [tag : ignore]. Any contents of this tag is ignored from the prototype.
20160909 00:44:39< celmin> ...
20160909 00:44:41< vultraz> syntax pending, of course :P
20160909 00:45:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160909 00:45:55< vultraz> perhaps should be some control for subtags as to whether they merge or override
20160909 00:46:18< vultraz> ya know what, let me ask the anura people how they handle this...
20160909 00:46:23< celmin> Why?
20160909 00:46:35< vultraz> because they already have a design that works? :PP
20160909 00:46:36< celmin> I doubt the Anura people have this problem though.
20160909 00:46:49< celmin> They don't use WML, after all.
20160909 00:47:15-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160909 00:47:22< celmin> We could also make prototypes only apply to attributes.
20160909 00:47:27< vultraz> no, but it's similar in some ways https://github.com/anura-engine/wesnoth2/blob/master/data/object_prototypes/unit_avatar.cfg
20160909 00:47:54< vultraz> for example, I would equate properties : {} there to a subtag in wml
20160909 00:48:04< celmin> Doubt it.
20160909 00:48:50< vultraz> though, for the record
20160909 00:48:54< tad_> My suggestion would be to look to other languages. Java and Javascript, to start. The concept is not uncommon.
20160909 00:49:01< celmin> Java does not have the concept.
20160909 00:49:13< celmin> In JS it'd just be like what I said earlier.
20160909 00:49:14< vultraz> I do wonder why, in tad's example, in the inherited tag, one could not just say [evenlevel] result=newresult
20160909 00:49:22< vultraz> if what he wants to do is get rid of result=
20160909 00:49:39< celmin> Well, I guess JS doesn't have the multichild concept though.
20160909 00:50:41< tad_> In my example, I was thinking of a user/programmer saying "I want everything [tad] does, except I don't want to [endlevel] at all."
20160909 00:51:23< tad_> In C++ we'd say .. "So refactor [tad] to inherit from [tadbase] which does not have [endlevel] then you inherit [tadbase] instead"
20160909 00:51:40< vultraz> that's one method
20160909 00:52:53< celmin> I feel like we're not all talking about the same thing.
20160909 00:53:03< tad_> It's not very literate, but it works. The problem is when we do that on C++ we break so much and end up with a bazillion special-purpose classes .. often duplicated .. because it grew and nobody looked at any else's worl
20160909 00:53:29< tad_> celmin: I think we are, but at different levels.
20160909 00:53:32< vultraz> (for the record, anura does have "+property":, and we already do have a [+tag] syntax. What if we made subtags override prototype subtags unless [+tag[ is used)
20160909 00:53:37< vultraz> that's another possibility
20160909 00:54:01< tad_> [-tag] --> remove this from [tag]
20160909 00:54:18< vultraz> yup
20160909 00:54:25< vultraz> [+tag] add to tag
20160909 00:54:31< vultraz> [tag] overwrite tag
20160909 00:54:46< celmin> vultraz is talking about a WML thing.
20160909 00:54:52< celmin> I wasn't talking about a WML thing.
20160909 00:55:04< tad_> Ah.
20160909 00:56:38< vultraz> this would be consistent with the existing [+tag] syntax
20160909 00:56:55< celmin> No it wouldn't.
20160909 00:57:37< vultraz> (though for the record, the existing [+tag] syntax is rather ugly and I kinda agree with fabi_ should be deprecated)
20160909 00:57:41< tad_> Where vultraz and I have headed is to the realization that doing a 'base widget' thingy for the UI is a specific example of a more general problem. unit_type already has hit this issue and has a special feature for it. So the question is how to generalize it, then use the generalized solution for his concerns in the UI
20160909 00:57:59< celmin> Fairly sure it can't be deprecated.
20160909 00:58:12 * tad_ agrees on [+tag] being sorta ugly.
20160909 00:58:21< celmin> I don't think it needs to be generalized at the WML level.
20160909 00:58:28< celmin> Most things don't need it.
20160909 00:58:54< vultraz> I think it's perfectly reasonable to do so
20160909 00:59:16< vultraz> implementing it specifically in gui2 means then there are 2 places in the code that implement duplicate functionality
20160909 00:59:17< celmin> I suspect it's not possible.
20160909 00:59:23< celmin> At the WML level.
20160909 00:59:33< celmin> I'm fairly sure even JSON doesn't support prototypes.
20160909 00:59:37< vultraz> not to mention it would allow more freedom for umc authors
20160909 00:59:47< tad_> Actually, I see it being done right now. Just using macros instead of WML. At least, the add and change parts ...
20160909 00:59:48< vultraz> and reduce macro usage
20160909 01:00:02< celmin> What we need is a) a general way to do it in the C++ and 2) special support for it somewhere in GUI2.
20160909 01:00:13< vultraz> I disagree strongly :|
20160909 01:00:30< vultraz> Implementing this in config would also allow doing it from the c++
20160909 01:00:39< celmin> I'm talking about implementing it in config, yes.
20160909 01:00:52< vultraz> and if it's in config, we can use it in wml\
20160909 01:00:52< tad_> I mildly disagree with special support.
20160909 01:01:02< celmin> And then GUI2 reads certain tags and uses that with to set up the prototype in its config.
20160909 01:01:07< celmin> No, you're wrong.
20160909 01:01:16< celmin> Putting it in config doesn't mean we can use it in WML.
20160909 01:01:28< vultraz> ok, why cannot we use it in wml?
20160909 01:01:46< tad_> Need to whack the interpreter to recognize it
20160909 01:01:57< celmin> I think it's something that is very difficult to represent in a flat text format.
20160909 01:02:02< celmin> YML manages it, admittedly.
20160909 01:02:14< celmin> ^YAML
20160909 01:02:15< vultraz> FSON manages it :|
20160909 01:02:22< celmin> I haven't seen the proof of this yet.
20160909 01:03:12< vultraz> take another look at the file i linked
20160909 01:03:13< vultraz> https://github.com/anura-engine/wesnoth2/blob/master/data/object_prototypes/unit_avatar.cfg
20160909 01:03:16< vultraz> that's the prototype
20160909 01:03:19< celmin> What am I looking for?
20160909 01:03:26< vultraz> and here's an inherited object
20160909 01:03:27< vultraz> https://github.com/anura-engine/wesnoth2/blob/master/data/objects/units/unit_avatar_dwarves_lord.cfg
20160909 01:03:57< celmin> And how does that solve it?
20160909 01:04:06< vultraz> what is "it"
20160909 01:04:09< celmin> It's certainly not a general solution.
20160909 01:04:12< celmin> Prototypes.
20160909 01:04:35< vultraz> how is it not a general solution?
20160909 01:04:55< tad_> Actually, I see the C++ solution there.  If unit_avatar has something you don't want in dwarves_lord you're going to have to refactor
20160909 01:05:01< celmin> Requires the prototypes to be declared in a separate area.
20160909 01:05:15< vultraz> of course
20160909 01:05:30< vultraz> I've been assuming that's what we'd be doing :|
20160909 01:05:41< tad_> Why?
20160909 01:05:57< vultraz> prototype in one place, inherited tags somewhere else
20160909 01:06:15< tad_> in that dwarves_lord you could say prototype: { bunchastuff } .. sorta silly to do that, but you probably could.
20160909 01:06:58< vultraz> I don't know if that's work
20160909 01:07:01< vultraz> and it's rather foolish
20160909 01:07:09< vultraz> since then you can't use it anywhere else
20160909 01:07:27< tad_> Hey .. NEVER underestimate the ability of programmers to try something foolish.
20160909 01:07:32< vultraz> heh
20160909 01:09:04< vultraz> if what tad_ calls the c++ solution is the simplest way to handle stuff, then let's do that
20160909 01:09:17< vultraz> no need to over-engineer wml
20160909 01:09:19< celmin> I can't focus on this conversation right now, but I'll try to give a more detailed description of what I mean soon.
20160909 01:10:11< tad_> There are a lot of ways. Personally, I'd suggest looking to Lua, first.
20160909 01:10:36< vultraz> We could implement fabi_'s moonscript patch and then use metatables :P
20160909 01:10:52< celmin> Please no.
20160909 01:10:56< tad_> A tag is a table, it has attributes and sub-tables/sub-tags.
20160909 01:11:44< vultraz> if necessary, we could even declare a toplevel [prototype] tag.
20160909 01:11:46< tad_> So how does Lua approach the issue of add/change/delete an attribute or a sub-table?
20160909 01:12:28< vultraz> I don't know
20160909 01:13:01< tad_> vultraz: One thing .. to sell the idea .. you're going to have to show how a #define macro can't do the job, or would be very hard to get right.
20160909 01:13:16< vultraz> Oh, I'm sure a macro could do the job
20160909 01:13:20< vultraz> with twice the WML :)
20160909 01:14:25< vultraz> tad_: look at this macro https://github.com/wesnoth/wesnoth/blob/master/data/gui/widget/button_default.cfg#L122
20160909 01:14:39< vultraz> now look at its macro includes
20160909 01:14:50< vultraz> (ie, from there back to the top of the file)
20160909 01:15:06< vultraz> then realize all that
20160909 01:15:11< vultraz> is duplicated *three times*
20160909 01:15:18< vultraz> because a few attributes are different
20160909 01:19:30< tad_> Well, to be honest, the file looks pretty clean to me. Are you referring to the three [button_definition] blocks at the bottom?
20160909 01:19:44< vultraz> yes
20160909 01:20:13< vultraz> the file looks clean because it's wrapped in a macro
20160909 01:20:25< vultraz> until you realize the string preprocessor expands that all :/
20160909 01:21:20< vultraz> and there's the key word: string preprocessor.
20160909 01:21:34< vultraz> and important thing will be to ensure prototypes don't become pseudo-macros
20160909 01:21:52< tad_> That's my point .. the current macros get you there (or almost there). But, yeah, if we expand the macros it's huge.
20160909 01:22:23< vultraz> the macros are huge and it's all parsed and stored in the cache :)
20160909 01:22:31< tad_> Just so you know .. my problem is the macros actually string-replace. Sure, it's easy to write, but it's ssoooo wasteful.
20160909 01:22:41< vultraz> yes!
20160909 01:22:56< tad_> But that can be fixed without changing the language.
20160909 01:23:31< vultraz> there are three reasons to use macros: as pseudo-prototypes (bad!), pseudo-functions (bad!), or common data insertion (good)
20160909 01:24:21< vultraz> for the second, we have lua
20160909 01:24:25< vultraz> and custom tags
20160909 01:24:26< tad_> Actually, all three are good use cases.  It's the implementation in the Wesnoth engine with is bad
20160909 01:24:39< vultraz> true
20160909 01:25:14< vultraz> if macros were not just string replaces and in fact something smarter, and we could get rid of the string preprocessor, we'd be golden
20160909 01:25:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160909 01:25:47< vultraz> personally, I really like Anura's FSON format
20160909 01:26:01< vultraz> since you can have either variables or functions as the values of keys
20160909 01:27:04< vultraz> it's just... really nice to work with
20160909 01:27:13< vultraz> I can attest :)
20160909 01:27:33< tad_> Well, they have the advantage of having just started and not having to deal with supporting a 10+ year old code base.
20160909 01:27:43< vultraz> they haven't just started, actually
20160909 01:28:24< vultraz> they started, oh, 2010? at the time, they were just the Frogatto game, before splitting their engine from the game about 2/3 years ago or so
20160909 01:28:39< vultraz> it's built by the some of same people who did Wesnoth
20160909 01:28:50< tad_> Well, they did "rm -fR /wesnoth/data" .. something we can't do
20160909 01:28:53< vultraz> designed to do what wesnoth did better
20160909 01:29:05< vultraz> did, but better*
20160909 01:29:38< tad_> Give me a few weeks with it and I'm sure I'll be able to point out how they can't get there from here someplace in their language.
20160909 01:29:52< vultraz> heh :P
20160909 01:30:09< tad_> But the issue is not what they did. The issue is how do *we* get 'there' from 'here' with what we have.
20160909 01:30:17< vultraz> right
20160909 01:31:20< tad_> Of course, we need to know where 'there' is .. traditionally, for a project this old, it's "just a little that way from where we are now" because we can't up and toss everything and start over
20160909 01:31:28< vultraz> the extreme option is rm -Rf wesnoth and start over with their engine, but that's not going to happen :P
20160909 01:31:44< vultraz> so we need to consider what we can do here to make it bette
20160909 01:31:46< vultraz> r
20160909 01:31:57< vultraz> and not just "a little bit better"
20160909 01:32:30< tad_> Well, we do have a lot of horses .. and we'd really like to have them both find the water AND drink!
20160909 01:33:14< vultraz> yeah..
20160909 01:33:26< vultraz> see
20160909 01:33:37< tad_> And many of them, it seems, will need to learn what 'water' is before either can happen :P
20160909 01:33:45< vultraz> there's a difference between "i want to do this" and "I need to build the stuff to enable me to do this"
20160909 01:33:57< vultraz> sadly, in wesnoth, you spend 95% of the time doing the latter :(
20160909 01:34:40< tad_> you and me, sure. but most of the forums just do the former and wait for someone like us dumb enough to try the latter
20160909 01:34:58< vultraz> well, that's why they're the users! :P
20160909 01:35:54< celmin> Catching up on the discussion now.
20160909 01:36:33< vultraz> about the prototype business, I maintain it can be done
20160909 01:36:46< vultraz> but we should consider a design, and implement it in steps
20160909 01:36:49< vultraz> first, in config
20160909 01:36:52< vultraz> then, in WML, possibly
20160909 01:37:14< tad_> I was just going to say something along those lines.
20160909 01:37:37< celmin> [Sep 08@9:11:46pm] tad_: So how does Lua approach the issue of add/change/delete an attribute or a sub-table?
20160909 01:37:38< vultraz> having in in config is already an improvement 
20160909 01:37:39< celmin> Deleting is "setting to nil". The table handles its attributes, subtables need to take care of their own.
20160909 01:39:38< tad_> We have one use case in WML (unit_type) and we've identified another (widgets) so it sounds like a reasonable case to try to generalize a solution. Taking it in stages and, first, seeing if it does the job for widgets the, later, seeing if it can be retro-fitted into unit_type sounds like a good plan. Just keep in mind that the goal is a more general solution and what you're doing is designing by prototype.
20160909 01:43:44< celmin> If it's in config, the engine can decide when to hook in prototypes based on the WML.
20160909 01:50:25< tad_> On a completely different subject .. I was running through DM a while ago and noticed my memory use was very high. I had to quit and reload and the memory usage was quite low. So, is there something I'm missing or doesn't this point to a memory leak?
20160909 01:50:51< celmin> Probably points to a memory leak.
20160909 01:51:00< celmin> Wesnoth is probably a very leaky bucket.
20160909 01:51:26 * tad_ sighs.
20160909 01:52:01< tad_> You were supposed to say, "Oh, well it .." and show I'm not considering something.
20160909 01:52:18< celmin> Well, I don't really know enough to say something like that.
20160909 01:53:23< tad_> I did some tests. If I load a scenario, then re-load it, by the second or third re-load memory use has settled down. It's running scenarion after another for a logn time where I see a problem.
20160909 01:59:42< tad_> Well, while you're working on the config stuff if you happen to notice some references or pointers being over-written ...
20160909 02:05:43< vultraz> anyway
20160909 02:05:52< vultraz> I guess for now I'll use a macro and a custom window definition
20160909 02:06:12< tad_> probably best
20160909 02:06:24< vultraz> celmin: will you implement the new behavior of ADJUST_ALPHA?
20160909 02:06:45< celmin> My todo list is already way out of control, but I'll add that anyway...
20160909 02:06:56< vultraz> ok
20160909 02:11:32< vultraz> ..apparently [drawing] cannot be used in stacked widgets? o_O
20160909 02:11:43< vultraz> oh wait
20160909 02:11:48< vultraz> i forgot [row]
20160909 02:17:04< celmin> What are you doing now? :|
20160909 02:18:35< celmin> So anyway, I did say I'd try to describe better what I meant about the prototypes.
20160909 02:19:12< celmin> First, config::set_prototype works similarly to Lua's setmetatable(t, {__index = {…}})
20160909 02:19:45< celmin> That is, it sets a config to be used for lookup if a key does not already exist in the config.
20160909 02:20:01< celmin> And something similar for children.
20160909 02:20:32< celmin> When loading WML from a string (ie, a file), the configs would not have prototypes.
20160909 02:22:20< celmin> The GUI2 code and the unit type code would be responsible for setting prototypes based on the WML.
20160909 02:22:37< celmin> (And any other code that uses prototypes.0
20160909 02:22:38< celmin> ^)
20160909 02:26:12< celmin> And I think that's it.
20160909 02:28:59< vultraz> sounds reasonable for now
20160909 02:29:05< celmin> "for now", huh.
20160909 02:30:44< vultraz> it's a start
20160909 02:30:58< celmin> "a start", huh.
20160909 02:31:57< celmin> I wonder if it should be standard that a copied config references the original as its prototype… I think it'd be good in many cases, but might be problematic in others, not sure...
20160909 02:35:33 * vultraz picks out art for each of the categories
20160909 02:35:55< celmin> Categories?
20160909 02:36:34< vultraz> i figured each of the game types should get their own picture
20160909 02:36:37< vultraz> what do you think
20160909 02:38:37< celmin> Which picture are you talking about? The background, or an icon?
20160909 02:38:44< vultraz> background
20160909 02:39:05< vultraz> optimally, they'd crossfade nicely between each other, but...
20160909 02:39:07< vultraz> engine :P
20160909 02:39:57< vultraz> though i suppose such a thing wouldn't be that hard to do
20160909 02:40:22-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160909 02:40:42< vultraz> also. should the image be on the right, or left..
20160909 02:40:46< celmin> Well...
20160909 02:41:57< celmin> Optimally, the scenario/campaign would specify the image.
20160909 02:45:40< vultraz> our art supply isn't that extensive
20160909 02:46:17< vultraz> and campaign images that display in the campaign dialog are wayyy too small 
20160909 02:46:36< celmin> They're not meant as a background, so that wouldn't be a good choice anyway.
20160909 02:47:15< vultraz> maybe these should go on the left
20160909 02:47:23< vultraz> on the right, it obscures certain options
20160909 02:47:36< celmin> But I still think the scenario/campaign should be able to specify the image.
20160909 02:47:44< vultraz> perhaps
20160909 02:47:45< celmin> A new key in [campaign] and [multiplayer].
20160909 02:47:56< vultraz> i guess it can be added
20160909 02:48:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 02:49:02< vultraz> that way campaigns with storyart can be set to display that
20160909 02:49:04< vultraz> and stuff
20160909 02:53:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 265 seconds]
20160909 02:53:37< vultraz> hmmm
20160909 02:53:44< vultraz> a larger image actually looks kinda better
20160909 02:55:03 * vultraz ponders
20160909 03:21:19-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20160909 03:21:25-!- janebot_ [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20160909 03:21:25-!- janebot_ is now known as janebot
20160909 03:22:00< celmin> We should probably consider signing the Wesnoth.app.
20160909 03:22:03< celmin> Somehow.
20160909 03:28:41< celmin> Do we have auto-close yet in [message]?
20160909 03:28:47< celmin> (And if not, do we want it?)
20160909 03:31:32< vultraz> there was a patch submitted for that once
20160909 03:31:36< vultraz> was never accepted
20160909 03:32:33< vultraz> there's auto-close functionality in gui2
20160909 03:35:14< tad_> How would auto-close work?  Flash the message too quickly to read? 
20160909 03:37:39< celmin> No. After a delay.
20160909 03:39:35< tad_> I know. But, of course one man's eternity waiting is an irritating flash to another.
20160909 03:39:45< celmin> True
20160909 03:40:12< celmin> Maybe should be just auto_close=yes and not delay=n
20160909 03:41:03< celmin> And make it a pref
20160909 03:41:22< celmin> Could include option of disabling altogether too
20160909 03:41:30< celmin> And scale it by text size
20160909 03:42:25< celmin> Uh-oh
20160909 03:42:42< celmin> Sorry wrong channel
20160909 03:44:20< vultraz> hmm
20160909 03:44:33< vultraz> i could just make the image stretch to the whole background..
20160909 03:50:40-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160909 04:03:06-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160909 04:03:18-!- JyrkiVesterinen [~JyrkiVest@87-100-223-188.bb.dnainternet.fi] has joined #wesnoth-dev
20160909 04:07:05< vultraz> yeah i can't decide on something that looks goof
20160909 04:07:09< vultraz> good
20160909 04:07:29-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160909 04:07:32< celmin> Don't forget the resolution is not fixed, either.
20160909 04:08:33< vultraz> maybe I'll consult with some UI people
20160909 04:09:17< vultraz> do some mockups
20160909 04:14:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 04:14:30< vultraz> HMM
20160909 04:14:33< vultraz> hmmm
20160909 04:16:06< vultraz> I have an idea...
20160909 04:16:15< celmin> ?
20160909 04:16:16< vultraz> but... I haven't been able to get [drawing] working in a stack
20160909 04:18:08< vultraz> ah...hm
20160909 04:18:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160909 04:18:49< vultraz> celmin: real quick while i'm thinking of it, do you have any objection to remove [stack] from [stacked_widget] and just having it take [layer] directly?
20160909 04:19:04< celmin> Well, that depends.
20160909 04:19:22< celmin> Can you imagine a situation in which you might want multiple stacks?
20160909 04:19:29< vultraz> no
20160909 04:19:33< celmin> And does it do anything in the C++?
20160909 04:19:38< vultraz> no
20160909 04:19:50< celmin> I assume you say that based on the stacked_widget_builder.
20160909 04:19:55< vultraz> yes
20160909 04:19:58< celmin> …or _definition? One of those, I forget.
20160909 04:20:04< celmin> Okay, then no objections.
20160909 04:20:22< vultraz> though... I wonder if 'different stacks' could be utilized to hold like.. different stacks for different tabs in the same widget
20160909 04:20:23< celmin> While you're at it, why not remove [row] and [column] from [grid]? :P
20160909 04:20:24 * vultraz ponders
20160909 04:20:42< celmin> Well, for that you could always have a stacked widget containing stacked widgets.
20160909 04:21:27< vultraz> STACKCEPTION
20160909 04:21:29< celmin> ?
20160909 04:22:00< celmin> What do you think about removing [row] and [column] BTW?
20160909 04:22:05< vultraz> wait
20160909 04:22:07< celmin> Instead you'd have a cols=n key.
20160909 04:22:09< vultraz> you were serious??
20160909 04:22:17< celmin> Yeah.
20160909 04:22:22< vultraz> this seems like a bad idea
20160909 04:22:29< celmin> Why?
20160909 04:22:40< celmin> Oh, wait, rows and columns do have keys though, so that could be troublesome.
20160909 04:23:12< celmin> I guess you'd still need at least [cell] or something.
20160909 04:23:13< vultraz> exactly
20160909 04:25:57< celmin> But it would drastically reduce indentation levels, I think, so if it can be done somehow, I would be happy.
20160909 04:36:29< vultraz> celmin: https://drive.google.com/file/d/0B-mR9s8FduLLY0JFamJfTVZQWXc/view?usp=sharing
20160909 04:37:11< vultraz> (taken in-game, but using some magic numbers I'd definitely have to tweak)
20160909 04:37:14< celmin> Oh right, did the Travis ever get fixed?
20160909 04:37:37< vultraz> dont think so
20160909 04:37:42< celmin> Bah.
20160909 04:40:55< celmin> Hm, bad_alloc in GUI2 tests? o.o
20160909 04:41:28< JyrkiVesterinen> 20160909 01:37:39< celmin> Deleting is "setting to nil". The table handles its attributes, subtables need to take care of their own.
20160909 04:41:45< JyrkiVesterinen> I need to mention that a child table can't remove an attribute of the parent table in Lua.
20160909 04:41:48< celmin> By which I mean, have their own metatables to handle it if they want to.
20160909 04:41:55< celmin> Hmm? Not sure why that would be relevant?
20160909 04:42:08< JyrkiVesterinen> If the value is set to nil, the value will be fetched from the parent table.
20160909 04:42:42< JyrkiVesterinen> Well, I saw the discussion, and an important point there was "derived config must be able to delete stuff that the prototype has".
20160909 04:42:50< celmin> I'm somehow confused at what's being talked about here.
20160909 04:42:56< celmin> Wait what?
20160909 04:44:48< celmin> Oh, right, I get it.
20160909 04:44:48< celmin> If you set the value to nil, Lua will then fetch from the metatable instead.
20160909 04:44:48< celmin> But I don't think it's important for the derived config to be able to delete attributes that are in the prototype...
20160909 04:44:48< celmin> For children it might be a different story, though.
20160909 04:47:05< celmin> Oh right, I have to look at vultraz's screenshot.
20160909 04:47:13< celmin> o.o
20160909 04:47:32< celmin> Not bad!
20160909 04:49:16< vultraz> the top/bottom bars are hardcoded into the window background, though
20160909 04:49:18< vultraz> :/
20160909 04:49:36< celmin> Try using a matrix.
20160909 04:49:42< celmin> ?
20160909 04:50:09< vultraz> well, the drawing wouldn't reach the window edge then...
20160909 04:50:13< vultraz> unless it had no border..
20160909 04:50:20< vultraz> and borders were enforced by the dialog..
20160909 04:50:21< vultraz> gmm
20160909 04:50:28< vultraz> thought
20160909 04:50:32< celmin> I don't know for sure if the [matrix] works, mind you.
20160909 04:50:39< celmin> But worth trying IMO
20160909 04:51:18-!- JyrkiVesterinen [~JyrkiVest@87-100-223-188.bb.dnainternet.fi] has quit [Quit: .]
20160909 04:51:34< celmin> I was actually thinking of trying it in MP Create anyway.
20160909 04:51:47< vultraz> what's the syntax?
20160909 04:52:13< celmin> [matrix] contains [main] and optionally [left] / [right] / [top] / [bottom] IIRC
20160909 04:52:29< celmin> Check the builder (or wiki) if you need all details.
20160909 04:58:57< celmin> And let me know if it works, because I'm actually curious.
20160909 04:59:09< vultraz> what is..this pane it's looking for :|
20160909 04:59:22< celmin> No idea! Check source?
20160909 05:00:38< celmin> I know [pane] is a thing, but no idea how it differs from other things.
20160909 05:02:42< vultraz> btw
20160909 05:02:44< vultraz> bug
20160909 05:02:56< vultraz> if you get an error message such as that from a widget not found
20160909 05:03:01< vultraz> and get thrown back to titlescreen
20160909 05:03:06< vultraz> the titlescreen will lag massively
20160909 05:03:15< vultraz> input will take multiple seconds to register
20160909 05:06:37< vultraz> ok, I found an example to look at for reference
20160909 05:06:43< vultraz> but now it can't find the widgets..
20160909 05:06:47< celmin> There was an example?
20160909 05:06:59< vultraz> debug clock
20160909 05:07:02< celmin> Ah.
20160909 05:07:20< celmin> Don't tell me the matrix's find() function is a stub...
20160909 05:07:48< vultraz> no, it's implemented
20160909 05:08:06< vultraz> but don't tell me i need to refactor every single find_widget call in the dialog :|
20160909 05:08:25< celmin> Huh? No, find_widget calls the widget's find() function.
20160909 05:08:46< vultraz> oh, I think it's the fields...
20160909 05:08:53< celmin> ?
20160909 05:09:07< vultraz> yeah, it fails on the first field
20160909 05:09:21< vultraz> fields can only find widgets directly in the window
20160909 05:09:35< celmin> Eh?
20160909 05:09:49< celmin> Surely they use find_widget too?
20160909 05:10:03< celmin> Or the window's find() function, which is equivalent.
20160909 05:10:11< vultraz> hm
20160909 05:10:12< vultraz> yes
20160909 05:10:45< vultraz> but for some reason it cannot find them
20160909 05:10:47< vultraz> sigh
20160909 05:11:03< celmin> Set a breakpoint in find_widget?
20160909 05:11:09< celmin> Maybe matrix's find() is buggy?
20160909 05:12:56< vultraz> no idea
20160909 05:15:56< vultraz> i dont really feel like investigating this further :|
20160909 05:17:40-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160909 05:18:21-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160909 05:19:59< vultraz> ok
20160909 05:20:03< vultraz> it's not just the fiends
20160909 05:20:05< vultraz> fields
20160909 05:20:18< vultraz> nothing can be found
20160909 05:21:15< vultraz> which is odd
20160909 05:21:38< celmin> Does matrix's find() function look okay?
20160909 05:22:36< vultraz> yes
20160909 05:22:43< vultraz> perhaps because those widgets are in stacks...
20160909 05:22:47< vultraz> hmm
20160909 05:23:02< celmin> Should be fine as long as all stack layers are visible.
20160909 05:23:22< celmin> Which you can do temporarily if necessary.
20160909 05:23:28< celmin> And in post_show
20160909 05:23:38< vultraz> they are
20160909 05:23:40< vultraz> :?
20160909 05:23:43< celmin> (I think I already did in MP Create.)
20160909 05:23:44< vultraz> blahh
20160909 05:23:48< vultraz> yes you did
20160909 05:24:32< celmin> At which point are they not found? Field initialization, pre_show, during show…?
20160909 05:25:35< celmin> Is everything not found?
20160909 05:29:58< celmin> I guess there can't be anything wrong with pane's find() since that's used in the title screen.
20160909 05:31:21-!- jamibaraki [3d7d7260@gateway/web/freenode/ip.61.125.114.96] has joined #wesnoth-dev
20160909 05:38:41-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160909 05:41:55-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160909 06:00:59-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160909 06:02:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 06:03:33< vultraz> celmin: preshow
20160909 06:03:37< vultraz> nothing is being found at all
20160909 06:05:48< celmin> Sounds like a buggy find() to me, yet it looks okay...
20160909 06:07:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20160909 06:09:08< vultraz> yeah...
20160909 06:13:50< vultraz> anyway, maybe i dont need a matrix
20160909 06:14:09< celmin> I'll try it sometime i guess
20160909 06:16:05< vultraz> ya know, maybe ill just leave out the top/bottom bars
20160909 06:16:08< vultraz> celmin: thoughts?
20160909 06:16:15< celmin> Uhh...
20160909 06:16:48< celmin> If you mean put background behind title and buttons, I think that'd be fine.
20160909 06:17:14< celmin> It could still be changed to matrix later if we get that working.
20160909 06:22:55< vultraz> might be nice to give it a blur effect
20160909 06:22:59< vultraz> but blurring is broken
20160909 06:32:19< vultraz> there's no DARKEN ipf..
20160909 06:32:44< celmin> Easily added I'd think?
20160909 06:33:01< celmin> Though I guess lighten/darken are actually more complicated than they sound.
20160909 06:33:19< zookeeper> what do you even mean by "darken"?
20160909 06:33:23< celmin> Even so, there's an obvious naive implementation.
20160909 06:33:28< vultraz> reduce brightness
20160909 06:33:34< zookeeper> ~CS
20160909 06:33:42< vultraz> doesn't work like I want
20160909 06:34:01< zookeeper> are you sure you know what you want?
20160909 06:34:30< celmin> CS is colour-shift.
20160909 06:34:54< vultraz>  I guess i should pre-prepare images in gimp for now
20160909 06:35:03< zookeeper> WML is wesnoth markup language
20160909 06:35:04< celmin> Colour-shift is not darken.
20160909 06:35:17< celmin> And, I'm fairly sure, cannot darken.
20160909 06:35:37< zookeeper> <zookeeper> what do you even mean by "darken"?
20160909 06:35:40< vultraz> well, it can
20160909 06:35:48< vultraz> but not in a visually-appealing way
20160909 06:36:34< vultraz> I guess I'm thinking of almost like
20160909 06:36:53< vultraz> masking the image with a varying-transparency mask
20160909 06:36:54< celmin> Actually… how does CS work?
20160909 06:37:12< celmin> Maybe it can darken?
20160909 06:37:17< zookeeper> sadly, it looks like we also still don't have a proper invert function either
20160909 06:37:25< vultraz> maybe I want ~BLEND(0,0,0,80)
20160909 06:37:26< celmin> Really? Somehow I thought there was one.
20160909 06:37:36< celmin> Still, invert rarely looks good.
20160909 06:37:48< zookeeper> NEG operates on rgb only, thus cannot invert alpha which is super useful
20160909 06:37:58< celmin> Ah.
20160909 06:38:24< zookeeper> i was trying to get whoever implemented it to include alpha but they didn't
20160909 06:38:35 * vultraz shrieks
20160909 06:38:40< vultraz> oh my god
20160909 06:38:42< celmin> Normally you wouldn't want that.
20160909 06:39:12< vultraz> ~BLEND(0,0,0,80) turns the image into a psychedelic mess of random noise
20160909 06:39:20< zookeeper> sounds awesome!
20160909 06:39:21< celmin> Oh wow.
20160909 06:39:34< celmin> What about 0.8 instead of 80?
20160909 06:40:35< vultraz> that actually works more to what i want
20160909 06:44:09< vultraz> though I don't have gradient..
20160909 06:44:22< vultraz> so should i use separate images anyway
20160909 06:44:40< celmin> So it wasn't a percentage. :P
20160909 06:45:02< vultraz> it can be, apparently..
20160909 06:45:08< vultraz> I guess itn eeds %
20160909 06:45:56< celmin> Probably
20160909 06:46:23< vultraz> sadly, we don't have... that much interesting story art to display :|
20160909 06:47:33< vultraz> we have a lot of nice portraits, though..
20160909 06:48:13< vultraz> (one of these days we'll need to commission a new storyart set for HTTT)
20160909 06:50:17< celmin> I think that's lower priority than sprites and portraits though.
20160909 06:50:18< vultraz> (that will be something the new board can decide on! :D)
20160909 06:50:50< celmin> Also, if you're doing it for HTTT, don't you need to do it for all the campaigns?
20160909 06:51:03< vultraz> oh yes
20160909 06:51:11< celmin> And what about generic storyscreen art?
20160909 06:51:20< vultraz> less a priority
20160909 06:51:38< celmin> I feel like that should be at least as high a priority as campaign storyscreen art.
20160909 06:51:51< vultraz> meh
20160909 06:52:21< celmin> Speaking of the board, I still haven't checked my PMs.
20160909 06:58:23-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Ping timeout: 265 seconds]
20160909 07:01:00-!- celmin [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160909 07:23:48-!- boucman_work [~boucman@47.15.204.77.rev.sfr.net] has joined #wesnoth-dev
20160909 07:37:24-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160909 07:50:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 07:55:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 276 seconds]
20160909 08:15:48-!- horus2 [~1@91.82.241.207.pool.invitel.hu] has joined #wesnoth-dev
20160909 08:24:24< celmin> Well, I don't have any PMs or emails from Dave, so whatever?
20160909 08:56:19-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160909 08:59:07-!- horus2 [~1@91.82.241.207.pool.invitel.hu] has left #wesnoth-dev []
20160909 09:02:36-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160909 09:19:29-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has joined #wesnoth-dev
20160909 09:39:07-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 09:43:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds]
20160909 09:50:36-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160909 09:59:12-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160909 10:05:32-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160909 10:08:25-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160909 10:11:04< vultraz> celmin: odd
20160909 10:11:12< vultraz> i got mine days ago
20160909 10:11:23< vultraz> granted, awhile after he posted saying they were sent, but...
20160909 10:33:50-!- Bonobo [~Bonobo@2001:44b8:254:3200:e03a:828a:23ef:3eee] has joined #wesnoth-dev
20160909 10:46:20-!- Duthlet [~Duthlet@dslb-188-104-247-024.188.104.pools.vodafone-ip.de] has quit [Read error: Connection reset by peer]
20160909 11:07:06-!- gfgtdf [~chatzilla@x4e36343d.dyn.telefonica.de] has joined #wesnoth-dev
20160909 11:11:54-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160909 11:12:47-!- Duthlet [~Duthlet@dslb-188-104-255-138.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20160909 11:17:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160909 11:27:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 11:31:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20160909 11:37:52-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160909 13:41:22-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160909 13:50:37-!- nore [~ncourant@sas.eleves.ens.fr] has quit [Quit: WeeChat 1.4]
20160909 13:52:52-!- JyrkiVesterinen [~JyrkiVest@nblzone-242-23.nblnetworks.fi] has quit [Quit: .]
20160909 13:57:28-!- jamibaraki [3d7d7260@gateway/web/freenode/ip.61.125.114.96] has quit [Quit: Page closed]
20160909 14:25:20-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160909 14:37:17-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160909 14:40:34-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160909 14:42:28-!- DeFender1031 [~DeFender1@46-116-114-128.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20160909 14:51:24-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160909 15:08:01< celmin> Maybe something to do with how my name has an underscore?
20160909 15:11:27-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Remote host closed the connection]
20160909 15:12:56< zookeeper> i submit to your consideration that the least useful choice is to keep theorizing about possible reasons when the answer is bound to be a few keystrokes away
20160909 15:14:06< celmin> Meh.
20160909 15:17:32-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160909 15:18:14< tad_> Got a question about advancing a unit using WML.
20160909 15:20:42< tad_> I was told that doing [modify_unit]type="" would advance it. But it's doing it wrong. Is there a better/preferred way to force a unit to advance.
20160909 15:20:47-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160909 15:22:02< zookeeper> tad_, https://wiki.wesnoth.org/DirectActionsWML#.5Btransform_unit.5D should do it
20160909 15:22:08< celmin> There's [transform_unit] which directly calls the advance function.
20160909 15:22:18 * celmin too slow
20160909 15:22:54< zookeeper> hmh. what goes wrong with the [modify_unit] method? the core ADVANCE_UNIT macro uses that.
20160909 15:23:17< tad_> It's advancing Delfador from Journeyman Mage to Red Mage.
20160909 15:23:28< tad_> Not honoring the custom unit type
20160909 15:24:18< tad_> zookeeper: I was just about to tell you I'm done with updating my DM PR and doing a final run-through when I noticed he's suddenly a Red Mage.
20160909 15:24:49< zookeeper> huh. i presume it works all right if there's no [base_unit]ing going on.
20160909 15:24:50< celmin> Uhhh… what? How the heck does it get Red Mage from that?
20160909 15:25:06< zookeeper> because journeyman mage base_units from mage
20160909 15:25:20< celmin> Okay, but still...
20160909 15:25:31< zookeeper> i mean, that's the only logical connection so i'm assuming it must be because of that
20160909 15:25:57< tad_> I would tend to agree with zookeeper
20160909 15:26:20< tad_> BTW, it advances Chantal from Druid to Shyde with no apparent issues.
20160909 15:26:26< zookeeper> would you be inclined to test whether the same happens in 1.12, as in whether it's an old or new bug?
20160909 15:26:52< tad_> I can test that. It will take a while to set up the mod for 1.12
20160909 15:27:01< tad_> Hang on
20160909 15:27:01-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160909 15:28:06< zookeeper> also, i should note that i don't exactly maintain DM nor am i very familiar with it, so i can only do cursory reviewing
20160909 15:29:46< tad_> Well, the idea I added (some time ago) was that after 26 years, the characters should be (1) fully healed [they weren't] and (2) bumped a unit because 26 years have passed.
20160909 15:29:58< zookeeper> oh and i think i found "[if] must have [then]" rather misleading in some earlier PR too, since that's just not true
20160909 15:30:48< tad_> As a language requirement, correct. As a style requirement, you got after me long ago for copying an [if][else] so I check for it.
20160909 15:30:58< zookeeper> i did?
20160909 15:31:35< zookeeper> i like that construct myself and prefer it over wrapping the condition in a [not] so are you sure it was me? :P
20160909 15:32:05< tad_> well, might have been someone else. it's been several months.
20160909 15:32:11< celmin> Might've been me.
20160909 15:32:23< zookeeper> my money's on celmin too :P
20160909 15:32:29 * tad_ shrugs
20160909 15:33:17< zookeeper> anyway, not something i particularly care about
20160909 15:33:35< tad_> Frankly, while I like the brevity of [if][else] it can be easy to make a mistake. And I've seen [if][else][then] as well .. which really was odd ...
20160909 15:35:43< tad_> I go with what I'm told. And removing a commit only takes a few minutes. No sweat.
20160909 15:40:36< zookeeper> tad_, on an unrelated note, is "HttT General Improvements" ready?
20160909 15:41:18< tad_> Running 1.12.6 when I [modify_unit]type="" on Delfador he becomes "Mage Leader" so I'm thinking it's a 1.13 change gone wrong
20160909 15:41:45< zookeeper> good to know
20160909 15:43:09< tad_> zookeeper: I believe so. There was a change a few days ago but it'd been a while since before that. At this point it'd make as much sense to commit the PR and start a new one as wait for one more change in a couple months ...
20160909 15:43:32< zookeeper> ok, i'll go through it next then
20160909 15:44:21< tad_> I've been updating the OP with change notes, btw
20160909 15:44:37< tad_> zookeeper: on those HttT PRs, that is.  Same notes for all ofthem
20160909 15:47:48-!- Bonobo [~Bonobo@2001:44b8:254:3200:e03a:828a:23ef:3eee] has quit [Quit: Leaving]
20160909 15:54:34-!- gfgtdf [~chatzilla@x4e36343d.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.2/20160823121617]]
20160909 15:55:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 15:56:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160909 15:56:58< tad_> So, anyone have any idea how far back to look for 1.13 breaking type="" or should I spend a day bisecting to find it?
20160909 15:57:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 15:57:52< celmin> You could maybe start with trying the dev releases?
20160909 15:58:00< celmin> I have no idea, anyway.
20160909 15:58:32< tad_> OK. And, yes, I usually start with the tagged releases because they're easy to find.
20160909 15:59:17< celmin> Well, I also mentioned them because (at least for Windows users) they have prebuilt binaries.
20160909 16:00:02< tad_> zookeeper: Once I get this Red Mage thing worked, I'm declaring my work on DM done, pending requests and disapprovals.
20160909 16:00:39-!- boucman_work [~boucman@47.15.204.77.rev.sfr.net] has quit [Remote host closed the connection]
20160909 16:04:26< tad_> ok. nap time while doing a make on 1.13.3 ... I'll be back when I find what broken type="" advancing a unit. prolly tomorrow.
20160909 16:04:32-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160909 16:09:18-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.]
20160909 16:13:37-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20160909 16:17:28< bumbadadabum> In file included from src/gui/dialogs/lobby/lobby.cpp:36:0:
20160909 16:17:28< bumbadadabum> src/gui/widgets/chatbox.hpp:128:50: error: declaration of ‘lobby_info& gui2::tchatbox::lobby_info()’ [-fpermissive]
20160909 16:17:28< bumbadadabum>   lobby_info& lobby_info() { return *lobby_info_; }
20160909 16:17:28< bumbadadabum>                                                   ^
20160909 16:17:28< bumbadadabum> In file included from src/gui/dialogs/lobby/lobby.hpp:21:0,
20160909 16:17:30< bumbadadabum>                  from src/gui/dialogs/lobby/lobby.cpp:16:
20160909 16:17:30-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160909 16:17:32< bumbadadabum> src/gui/dialogs/lobby/info.hpp:25:7: error: changes meaning of ‘lobby_info’ from ‘class lobby_info’ [-fpermissive]
20160909 16:17:35< bumbadadabum>  class lobby_info
20160909 16:17:37< bumbadadabum>        ^
20160909 16:17:38< bumbadadabum> vultraz: can you stop breaking the wesnoth build?
20160909 16:34:51-!- ancestral [~ancestral@75-168-189-115.mpls.qwest.net] has joined #wesnoth-dev
20160909 16:47:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160909 16:49:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 16:58:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160909 16:59:41< celmin> Not quite sure what the issue is there…?
20160909 17:00:35< celmin> It's certainly not that the compiler sees two things with the same name and can't distinguish them.
20160909 17:01:02< celmin> Because class names and functions are totally separate namespaces.
20160909 17:02:45< celmin> I mean, it's easy to change the name of a function if you're really annoyed by this, but I don't see why it's a compiler error.
20160909 17:02:55< celmin> What are you building with, BTW?
20160909 17:03:12< celmin> (Or is that from Travis?)
20160909 17:03:49< celmin> bumbadadabum: ^
20160909 17:04:51< celmin> (Maybe it needs to be declared as 'class lobby_info& lobby_info() {return *lobby_info); }'?)
20160909 17:05:25< celmin> (ie, put the "class" keyword in front of the function declaration.)
20160909 17:12:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 17:15:54-!- JyrkiVesterinen [~JyrkiVest@78-27-122-160.bb.dnainternet.fi] has joined #wesnoth-dev
20160909 17:17:11-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160909 17:18:37< bumbadadabum> celmin: sorry, this was my local build with scons
20160909 17:20:03-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Read error: Connection reset by peer]
20160909 17:28:18-!- Duthlet [~Duthlet@dslb-188-104-255-138.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20160909 17:28:57-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20160909 17:31:08< celmin> scons and gcc?
20160909 17:45:12-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20160909 17:50:50-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160909 18:02:02< bumbadadabum> y
20160909 18:12:38-!- gfgtdf [~chatzilla@x4e36343d.dyn.telefonica.de] has joined #wesnoth-dev
20160909 18:21:04< vultraz> that wasn't me..
20160909 18:22:05< celmin> On an unrelated note, gfgtdf - you did some sort of refactoring before to make the unit class not directly access a config except during (de)serialization, right? Why was that?
20160909 18:24:57< bumbadadabum> <vultraz> that wasn't me..
20160909 18:24:58< bumbadadabum> sorry then
20160909 18:25:05< bumbadadabum> i just blamed you because I saw "gui"
20160909 18:25:54< vultraz> heh
20160909 18:25:54< celmin> Well, it's in the chatbox, so could be gfgtdf.
20160909 18:26:15< celmin> Also, I still don't understand why GCC is giving you an error there.
20160909 18:30:34< gfgtdf> celmin: well for muliple reasons 1) to reduce memory use and to improve perfroamcne when getting attributes. 2) It was quite unclear form looking at the c++ code which attributes are uported in unit since not all of them were handled in the unit ctor.
20160909 18:31:20-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has joined #wesnoth-dev
20160909 18:31:20-!- mordante [~mordante@2001:984:5786:1:7a24:afff:fe8c:dea8] has quit [Changing host]
20160909 18:31:20-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20160909 18:31:23< gfgtdf> what problems are ther with the chatbox ?
20160909 18:31:35< mordante> servus
20160909 18:31:39< gfgtdf> mordante: hi
20160909 18:31:47< mordante> hi gfgtdf 
20160909 18:31:58< celmin> gfgtdf: bumbadadabum got a compiler error
20160909 18:32:06< celmin> For some reason.
20160909 18:32:46< zookeeper> mordante got resurrected?
20160909 18:33:03< mordante> zookeeper, kind of
20160909 18:35:10< JyrkiVesterinen> vultraz: I figured out why the GUI2 MP test crashes.
20160909 18:35:11< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/8a80af4c6901cdeb35d0dc94be95a109be94536c/src/gui/dialogs/lobby/lobby.cpp#L823
20160909 18:35:33< JyrkiVesterinen> You store the lambda in a local variable. The lifetime of the lambda ends when the function returns.
20160909 18:35:54< JyrkiVesterinen> When it returns, the memory area where the lambda had stored the "this" pointer is freed.
20160909 18:36:24< JyrkiVesterinen> And when the join script calls the join() function, the lambda attempts to use that freed memory as the this pointer.
20160909 18:36:44< celmin> So it needs to be captured by value instead of by reference.
20160909 18:37:07< JyrkiVesterinen> No, the problem isn't capturing.
20160909 18:37:09< celmin> Or possibly even better, moved out to a member function?
20160909 18:37:32< celmin> Huh?
20160909 18:37:36< JyrkiVesterinen> Yes, I plan to make get_game_index_from_id a member function.
20160909 18:38:15< JyrkiVesterinen> As I said: the problem isn't how get_game_index_fromid captures the this pointer. It's that the lambda *itself* is destroyed before it's called.
20160909 18:38:32< celmin> I meant how the other lambdas capture get_game_index_from_id.
20160909 18:39:02< JyrkiVesterinen> Oh, that. Indeed, capturing the *lambda* by value would work.
20160909 18:39:16< JyrkiVesterinen> But I think a named member function is a better option.
20160909 18:39:19< celmin> I agree.
20160909 18:39:22< JyrkiVesterinen> Vultraz overuses lambdas. :P
20160909 18:39:28< celmin> Little bit. :P
20160909 18:41:31< celmin> So it seems at least one of the Travis builds also has bumbadadabum's error...
20160909 18:41:36< celmin> Why is this an error?
20160909 18:42:29< celmin> Why is a type name clashing with a function name?
20160909 18:42:54< celmin> It wouldn't clash with a variable name, and functions and variables share the same "namespace", don't they?
20160909 18:43:48< celmin> (For the record if you missed it, the error is basically "declaration of 'lobby_info& gui2::tchatbox::lobby_info()' changes meaning of 'lobby_info' from 'class lobby_info'.)
20160909 18:45:00< celmin> So the GCC builds get that error, and the clang build crashes in unit testing...
20160909 18:45:58< gfgtdf> hmm not sure why its on gcc that dfoesnt liek it but we shoudl just change the game of that function then, mabe 'get_lobby_info' or something
20160909 18:46:27< celmin> gfgtdf: We could change the name of the function, yes. Alternatively, it may work if you add "class" or "::" in front of the return value.
20160909 18:54:36< celmin> So, anyone have any idea what to do about this? https://travis-ci.org/wesnoth/wesnoth/jobs/158584160#L3064
20160909 18:57:20< gfgtdf> for some reason travis links takes forever to load here.
20160909 18:58:18< gfgtdf> actual it takes so lon, that i usuall look at such travis rpoerts at https://s3.amazonaws.com/archive.travis-ci.org/jobs/158584160/log.txt whihc is way faster, but doesn't offer line numbers.
20160909 18:58:21< gfgtdf> long*
20160909 18:59:03< celmin> You should be able to find it by searching for test_gui2 I think.
20160909 18:59:14< celmin> It's right at the end of the unit tests.
20160909 18:59:18< celmin> Or bad_alloc for that matter.
20160909 18:59:27-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160909 19:00:21< tad_> Still working on type="" but thought I'd report that it broke somewhere between 1.12.6 and 1.13.3
20160909 19:01:06-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160909 19:01:59< gfgtdf> hmm not sure waht casues this, it migth be that travis just hasnt very muhc ran or that at some point we just allocate at too long array, possile where the size is taken form an uninitilized value.
20160909 19:02:20< gfgtdf> unfortunatley it doesnt give us a tacktrace
20160909 19:02:27< celmin> Yeah, that is unfortunate.
20160909 19:03:05< gfgtdf> celmin: can you reproduce it locally ?
20160909 19:03:39< celmin> If it had happened last time I ran the tests locally, I'm pretty sure I would've noticed.
20160909 19:03:59< celmin> I wouldn't be surprised if my computer just goes to swap rather than throwing bad_alloc.
20160909 19:04:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160909 19:17:51-!- nore [~ncourant@sas.eleves.ens.fr] has joined #wesnoth-dev
20160909 19:25:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160909 19:30:48-!- irker261 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160909 19:30:48< irker261> wesnoth: Jyrki Vesterinen wesnoth:master adc598b3889a / join-gui2.lua: Apply recent MP test fixes to the GUI2 MP test, too https://github.com/wesnoth/wesnoth/commit/adc598b3889a4d6e5dc2ad4a9445ef0b81b14130
20160909 19:30:48< irker261> wesnoth: Jyrki Vesterinen wesnoth:master 3366e9c683a4 / src/gui/dialogs/lobby/ (lobby.cpp lobby.hpp): Fix crash in GUI2 multiplayer tests https://github.com/wesnoth/wesnoth/commit/3366e9c683a4ff2352e118a057f391c0129df3a1
20160909 19:30:49< irker261> wesnoth: Jyrki Vesterinen wesnoth:master cd779200a1be / src/gui/dialogs/lobby/lobby.cpp: Fix crash in GUI2 multiplayer test https://github.com/wesnoth/wesnoth/commit/cd779200a1bed0b6babcf7fcfb50a79814467fb0
20160909 19:31:08< JyrkiVesterinen> The tests no longer crash. They get stuck though.
20160909 19:31:43< JyrkiVesterinen> The join script stays in the leader select dialog. Same problem that the GUI1 test used to have.
20160909 19:32:04< JyrkiVesterinen> Because GUI2 tests are run without --nogui, the automatic plugin context isn't added.
20160909 19:32:29< celmin> …why are they run without --nogui?
20160909 19:32:43< JyrkiVesterinen> I don't know. That's how the scripts are.
20160909 19:32:53< celmin> vultraz: ^
20160909 19:33:10< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/cd779200a1bed0b6babcf7fcfb50a79814467fb0/utils/travis/mp_test_executor.sh
20160909 19:33:15< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/blob/cd779200a1bed0b6babcf7fcfb50a79814467fb0/utils/travis/mp_test_executor-gui2.sh
20160909 19:33:48< celmin> I wouldn't be surprised if it's solely because Vultraz was running without --nogui for testing purposes.
20160909 19:34:05< celmin> (So that he could see what's happening or something.)
20160909 19:39:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 19:43:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 250 seconds]
20160909 19:45:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160909 19:58:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 19:59:18-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160909 19:59:19< travis-ci> wesnoth/wesnoth#10787 (master - cd77920 : Jyrki Vesterinen): The build is still failing.
20160909 19:59:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158825575
20160909 19:59:19-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160909 20:05:19-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160909 20:05:45-!- knotwork [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20160909 20:09:06-!- JyrkiVesterinen [~JyrkiVest@78-27-122-160.bb.dnainternet.fi] has quit [Quit: .]
20160909 20:15:08-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20160909 20:38:01< gfgtdf> vultraz: do you plan to implement https://gna.org/bugs/?21653in the mp create dialog `?
20160909 20:40:52< gfgtdf> vultraz: also this one from the easycoding page: "Make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)"
20160909 20:41:16-!- edgrey [~edgrey@178.204.144.92] has joined #wesnoth-dev
20160909 20:59:27< celmin> Okay, so I could remove the *vcxproj.user files from the repository by installing yet another hack at wesnoth.cpp:990..1018, but… is that really a good idea? :|
20160909 21:01:42< celmin> …wait, the assertion is even before that?
20160909 21:03:06< celmin> Oh, maybe the debugger simply can't handle the process restarting itself. Which explains why the environment variable was also set.
20160909 21:03:11< celmin> :|
20160909 21:03:56< celmin> And I can't seem to get the parameters to work when included in the *.vcxproj...
20160909 21:08:03< celmin> Oh wait.
20160909 21:08:12< celmin> Putting them after all those imports seems to work. \o/
20160909 21:12:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160909 21:17:56< irker261> wesnoth: Celtic Minstrel wesnoth:master ab6369098f97 / / (5 files in 2 dirs): Remove *.vcxproj.user files https://github.com/wesnoth/wesnoth/commit/ab6369098f97cb028041b7c86e7a24d66c2317c7
20160909 21:18:25-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160909 21:18:53< celmin> Maybe the imports overwrote them or something.
20160909 21:28:37< vultraz> gfgtdf: not really, no
20160909 21:29:38< vultraz> celmin: the last of --nogui was for testing purposes only
20160909 21:29:56< vultraz> lack
20160909 21:29:59< celmin> So you can put it in then?
20160909 21:30:33< celmin> Try it and see if it works with --nogui
20160909 21:31:37< vultraz> mordante was here O_O
20160909 21:31:47< celmin> Oh, he left?
20160909 21:31:50< celmin> I didn't notice.
20160909 21:32:36< vultraz> would be nice if we actually stuck around for once
20160909 21:32:38< vultraz> he*
20160909 21:32:58< celmin> #21653 probably requires turning the listbox into a treeview, unless you can have "disabled" rows.
20160909 21:33:09< vultraz> you can
20160909 21:34:22< celmin> So if you have three rows, with row 1 disabled and row 2 selected, I assume it reports that row 2 is selected rather than treating row 1 like it doesn't exist?
20160909 21:35:30< vultraz> i believe so
20160909 21:35:39< vultraz> never tried it
20160909 21:36:57< vultraz> running the gui2 tests
20160909 21:37:24< vultraz> for some reason it just keeps spitting\ out "idling in dialog waiting for lobby"
20160909 21:37:28< vultraz> continuously
20160909 21:38:47-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160909 21:39:10< celmin> Then that would need to be accounted for somehow… I don't like iceiceice's suggestion of using a "dummy" level.
20160909 21:47:19-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160909 21:48:25-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160909 21:48:26< travis-ci> wesnoth/wesnoth#10788 (master - ab63690 : Celtic Minstrel): The build is still failing.
20160909 21:48:26< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158857226
20160909 21:48:26-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160909 21:48:37< celmin> Oh right.
20160909 21:48:45< celmin> I guess I can at least fix the one thing.
20160909 21:49:54-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 260 seconds]
20160909 21:49:54-!- wedge010 is now known as wedge009
20160909 21:50:01< vultraz> I decided I'm not going to commit the backgrounds thing yet
20160909 21:51:32< vultraz> I'll commit some framework stuff, though
20160909 21:52:33-!- Appleman1234 [~Appleman1@KD119104100141.au-net.ne.jp] has quit [Ping timeout: 265 seconds]
20160909 21:53:11-!- mjs-de [~mjs-de@x5ce33812.dyn.telefonica.de] has joined #wesnoth-dev
20160909 21:54:46< irker261> wesnoth: Charles Dang wesnoth:master 7ade61cfc2f5 / data/gui/default.cfg: Load widgets before dialogs https://github.com/wesnoth/wesnoth/commit/7ade61cfc2f599f5fc2e8f3eec413673dfab2141
20160909 21:54:49< irker261> wesnoth: Charles Dang wesnoth:master da2027c27455 / data/gui/ (widget/window_borderless.cfg window/mp_create_game.cfg): MP Create: added framework for background images https://github.com/wesnoth/wesnoth/commit/da2027c27455e1ff1405b24912c7dbafcee66d2e
20160909 21:54:53-!- celticmistral [~celticmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20160909 21:55:03-!- celmin [~celticmin@unaffiliated/celticminstrel] has quit [Read error: Connection reset by peer]
20160909 21:55:04-!- celticmistral is now known as celmin
20160909 21:56:59< vultraz> I need to perform some other UI changes
20160909 21:57:06< celmin> Why is the window definition ID "mp_create"?
20160909 21:57:28< vultraz> because right now it's just for create
20160909 21:57:54< celmin> Oh right.
20160909 22:00:02< irker261> wesnoth: Celtic Minstrel wesnoth:CelticMinstrel-travis-fix 9c3634b8cfe8 / src/gui/widgets/chatbox.hpp: Fix a Travis compile error https://github.com/wesnoth/wesnoth/commit/9c3634b8cfe8f11b09fb37870beca83c5e6173a2
20160909 22:02:38< celmin> (Just for the record, you should probably consider using that strategy for other Travis fixes instead of "Attempt to blah blah". >_> )
20160909 22:02:53< celmin> (And I don't mean using the github edit iterface.)
20160909 22:02:58< vultraz> only if you delete the branches later
20160909 22:03:01< celmin> (Or even necessarily a PR.)
20160909 22:03:05< celmin> Of course I will, duh.
20160909 22:03:12< celmin> Did I delete maybe-travis-fix yet though...
20160909 22:03:23< celmin> Looks like I did.
20160909 22:04:06< vultraz> anyway, I need to do some improvements
20160909 22:04:09< vultraz> to the UI
20160909 22:04:11< vultraz> first
20160909 22:04:36< celmin> Hm?
20160909 22:08:09< vultraz> I'm going to make a few misc widget design improvements
20160909 22:09:43< vultraz> firstly, I should move the tint to the listbox and not the toggle_panel
20160909 22:11:00< vultraz> so you don't get situations where items < height and you have untinted areas
20160909 22:24:58-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160909 22:25:18-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160909 22:25:19< travis-ci> wesnoth/wesnoth#10789 (master - da2027c : Charles Dang): The build is still failing.
20160909 22:25:19< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158865579
20160909 22:25:19-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160909 22:25:39-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160909 22:26:07< mattsc> hi vultraz 
20160909 22:26:12< vultraz> hello
20160909 22:27:04< mattsc> I did some more testing, and the crash I describe at 20160908 14:07:26 seems to happen whenever a unit has more than one attack of the same range and you disable one or several of those.
20160909 22:27:45< mattsc> When the unit only has one attack at the range, the attack dialog does not crash the game, independent of whether there’s another attack at a different range.
20160909 22:29:00< mattsc> vultraz: you think you can fix that sometime?
20160909 22:30:28< irker261> wesnoth: Charles Dang wesnoth:master 9630ed493712 / src/gui/dialogs/unit_attack.cpp: Unit Attack: removed assert in favor of min https://github.com/wesnoth/wesnoth/commit/9630ed4937123e49413693e9606add738a8b140d
20160909 22:30:30< vultraz> mattsc: ^
20160909 22:31:35< vultraz> it may not be the "proper" fix, but it should stop the crash
20160909 22:31:47< vultraz> I shall have to ponder a proper fix
20160909 22:32:05< mattsc> vultraz: I’ll check it out, thanks.
20160909 22:33:49-!- edgrey [~edgrey@178.204.144.92] has quit [Quit: Konversation terminated!]
20160909 22:34:07< zookeeper> on #wesnoth they say that "you can't set sides as empty in local games anymore" which if true sounds awfully lot like a bug.
20160909 22:34:25< zookeeper> oh wait. i didn't read to the end, apparently.
20160909 22:35:02< mattsc> vultraz: yes, that fixes the crash, thanks.  I haven’t had time to try out all possible combinations yet, but so far so good.
20160909 22:35:03< vultraz> they can be set to empty
20160909 22:47:47< vultraz> mattsc: the underlying problem seemed to be that the 'best' weapon was past the number of options being shown
20160909 22:47:58-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160909 22:47:59< travis-ci> wesnoth/wesnoth#10790 (CelticMinstrel-travis-fix - 9c3634b : Celtic Minstrel): The build failed.
20160909 22:47:59< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158866647
20160909 22:47:59-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160909 22:48:32-!- Appleman1234 [~Appleman1@KD119104118011.au-net.ne.jp] has joined #wesnoth-dev
20160909 22:48:36< mattsc> vultraz: Ah, I see.
20160909 22:48:57< mattsc> So that means that the weapon selection code is not taking the disable special into account correctly?
20160909 22:49:20< celmin> :|
20160909 22:49:22< mattsc> Which, maybe not accidentally at all, is what’s causing the AI bug I am currently looking into as well.
20160909 22:49:30< celmin> Stupid GCC, why are you given that warning.
20160909 22:49:40< vultraz> I'm looking at fill_weapon_choices
20160909 22:50:05< celmin> Okay, if GCC is going to insist on giving the missing field initializers warning there, I'm thinking it should be disabled.
20160909 22:50:10< celmin> The warning, that is.
20160909 22:50:34< celmin> All I want to do is default-initialize the stupid struct.
20160909 22:53:30-!- enchi is now known as enchi139
20160909 22:54:12-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection]
20160909 22:57:07< mattsc> vultraz: that’s not one of the functions I am looking into.
20160909 22:57:37< mattsc> mine are all part of battle_Context in actions/attack.cpp
20160909 22:58:15< vultraz> I'm looking there too
20160909 22:58:24< vultraz> fill_weapon_choices is where it gets the value for best attack, though
20160909 22:58:46< mattsc> well, it’s where the menu gets this number, maybe
20160909 22:59:06< mattsc> the actual calculations are done in  get_best_*_weapon()
20160909 22:59:16< mattsc> which is what the AI calls also
20160909 22:59:42< mattsc> but the consideration for disabled weapons is not done inside those functions, but as part of the calling functions
20160909 23:00:33< mattsc> which, in order for the AI to be as fast as possible, probably needs to be done that way
20160909 23:00:35< vultraz> then it should be moved inside
20160909 23:01:04< mattsc> not if you consider my last sentence
20160909 23:01:13< vultraz> true..
20160909 23:01:23< mattsc> by the way, those functions are called choose_*_weapon (I misremembered)
20160909 23:02:16< mattsc> The problem with the AI is that sometimes those choose_* functions are not called at all (nothing to choose if there is only one weapon)
20160909 23:02:38< mattsc> … or that the battle simulation is skipped (again, when not necessary).
20160909 23:02:54< mattsc> In those case, the disabled flag is not set, and the information needs to be gotten separately.
20160909 23:03:12< mattsc> And, as far as I can tell, all of that is done to avoid any sort of unnecessary calculation for the AI.
20160909 23:04:12< vultraz> blah
20160909 23:04:17< vultraz> I have discovered a crash in tje editor
20160909 23:05:56< mattsc> vultraz: actually, I think what I said was partially wrong.
20160909 23:06:40< mattsc> The disabled assessment is done inside those functions.  It’s just that the AI does not always calls them (for the reasons mentioned) and then they need to be queried separately.
20160909 23:06:55< mattsc> But for your purpose that should be entirely usable.
20160909 23:07:06< mattsc> For the attack dialog, I mean.
20160909 23:07:18< vultraz> uhhh..
20160909 23:07:48< mattsc> You don’t care about calculation time if you only need to do three attack simulations.
20160909 23:07:51< vultraz> perhaps you could patch this yourself?
20160909 23:09:30< mattsc> I’ll patch the AI, yes.
20160909 23:09:41< mattsc> I’ll see about the dialog if I run into other problems.
20160909 23:09:57< mattsc> Right now I need to be off again, I’m already later for something else.
20160909 23:11:09< irker261> wesnoth: Charles Dang wesnoth:master eea7bc0c6387 / src/editor/map/map_context.cpp: Editor: fixed crash when loading scenarios https://github.com/wesnoth/wesnoth/commit/eea7bc0c63877d526f1d984a114a1f46bd8c14ba
20160909 23:13:34-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20160909 23:25:12-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has joined #wesnoth-dev
20160909 23:25:13< travis-ci> wesnoth/wesnoth#10792 (master - 9630ed4 : Charles Dang): The build is still failing.
20160909 23:25:13< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158872519
20160909 23:25:13-!- travis-ci [~travis-ci@ec2-54-163-12-205.compute-1.amazonaws.com] has left #wesnoth-dev []
20160909 23:30:23< celmin> To answer your TODO, no, it's not supposed to be loaded there. Duh.
20160909 23:31:00< celmin> The game board is a display_context used in a game. In the editor, you have a map_context instead.
20160909 23:31:15< celmin> So basically, that assignment is unreachable.
20160909 23:31:28< vultraz> I see
20160909 23:31:47< vultraz> I think it used to do an assignment on gameboard::teams
20160909 23:31:51< vultraz> er
20160909 23:31:53< vultraz> resources::teams
20160909 23:32:40< celmin> Yeah.
20160909 23:33:31< vultraz> so I should just remove that line completely?
20160909 23:34:13< celmin> Hm, that depends on why it was there in the first place...
20160909 23:34:57< celmin> Just removing it probably won't hurt, I guess? Particularly since Jyrki fixed some things to properly use the map_context.
20160909 23:36:48< irker261> wesnoth: Charles Dang wesnoth:master 3a9caf70f4bd / src/editor/map/map_context.cpp: Removed problem line from eea7bc0c6387 altogether https://github.com/wesnoth/wesnoth/commit/3a9caf70f4bde193e882331ef0c26389bf37fe29
20160909 23:45:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 255 seconds]
20160909 23:46:32-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20160909 23:46:33< travis-ci> wesnoth/wesnoth#10793 (master - eea7bc0 : Charles Dang): The build has errored.
20160909 23:46:33< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/158880976
20160909 23:46:33-!- travis-ci [~travis-ci@ec2-23-20-205-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20160909 23:55:04-!- mjs-de [~mjs-de@x5ce33812.dyn.telefonica.de] has quit [Remote host closed the connection]
--- Log closed Sat Sep 10 00:00:16 2016