--- Log opened Tue May 20 00:00:38 2014
20140520 00:11:41-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Quit: Ik ga weg]
20140520 00:12:14-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Ping timeout: 240 seconds]
20140520 00:14:18-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140520 00:16:50-!- mjs-de [~mjs-de@f048238126.adsl.alicedsl.de] has quit [Remote host closed the connection]
20140520 00:33:50< mattsc> gfgtdf: the defeat_condition thing, have you done this only for 1.12 so far, or for master also?
20140520 00:34:31< gfgtdf> mattsc: its currently only on master, but it will be on 1.11.15 too.
20140520 00:34:56< mattsc> gfgtdf: hmm, I tested it on master with the animals MAI scenario and it didn’t work.
20140520 00:36:19< gfgtdf> mattsc: on masrter there is currentyl a type on the code =no_unit instead of =no_units, i didn't fixed it yet because i didnt know whether it should be called no_unit or no_units.
20140520 00:36:27< gfgtdf> typo
20140520 00:36:44< mattsc> gfgtdf: ah, okay.  Let me try that quickly.
20140520 00:36:51< gfgtdf> mattsc: what do you think maked more sense no_unit or no_units ?
20140520 00:36:55< gfgtdf> makes
20140520 00:37:34< mattsc> no_units_left
20140520 00:38:45< mattsc> of the two you mention, I would definitely go with no_units though
20140520 00:39:13< mattsc> ‘zero’ or ‘none’ is a plural form in English  :)
20140520 00:39:33< mattsc> which does not apply to ‘no’, of course, but ...
20140520 00:39:45< gfgtdf> mattsc: shoudl i also say no_leaders then ?
20140520 00:40:11< mattsc> gfgtdf: okay, using ‘no_unit’ works.  I’ll wait until you have the syntax figured out before I changed the MAI test scenarios.
20140520 00:40:30< mattsc> gfgtdf: that’s a tough one.  Personally, I would go with an entirely different syntax...
20140520 00:40:53< gfgtdf> mattsc: which syntax woudl you use ?
20140520 00:40:57< mattsc> ‘leader_killed’ or ‘lost_leader’ or something would make more sense to me.
20140520 00:41:20< mattsc> But TBH, I don’t really care much about these kinds of things.  So whatever you decide works for me.
20140520 00:41:43< mattsc> shadowm and happygrue are good with things like that, ask them.
20140520 00:41:55< gfgtdf> mattsc: hmm leader_killed wouldn't be correct in the case you ahve 2 leaders since you wnt loose if only one dies
20140520 00:41:56< mattsc> (as are a bunch of other people who aren’t around much these days)
20140520 00:42:11< gfgtdf> won't
20140520 00:42:15< mattsc> gfgtdf: true
20140520 00:42:58< mattsc> In that case I’d personally probably go with ‘no_leaders_left’ and ‘no_units_left’.
20140520 00:43:11< mattsc> but again, see my comment a couple lines above.
20140520 00:45:04< gfgtdf> hmm ok i'll ask one of them then.
20140520 00:45:13< happygrue> I agree with this:  [20:42:57] <mattsc> In that case I’d personally probably go with ‘no_leaders_left’ and ‘no_units_left’.
20140520 00:45:17< mattsc> Oh, _8680_ and vultraz are much better with language than I am as well.
20140520 00:45:34< mattsc> As are probably >80% of the people here and in the world.  :P
20140520 00:45:48< happygrue> these are boolean?
20140520 00:46:40< gfgtdf> happygrue: its about defeat_condition see http://wiki.wesnoth.org/SideWML
20140520 00:46:40< happygrue> well, regardless, adding the _left makes sense to me
20140520 00:47:12< happygrue> ugh
20140520 00:47:24< happygrue> so no_leader = no is the default which means there IS a leader
20140520 00:47:25< happygrue> right?
20140520 00:48:05< happygrue> that is not ideal IMO, should not be using a double negative.
20140520 00:48:06< gfgtdf> defeat_condition= "no_leader" is the default
20140520 00:48:24< gfgtdf> which means "a side is considered defeated as soon as it las no leader"
20140520 00:48:27< gfgtdf> has
20140520 00:48:51< happygrue> oh, sorry hit the wrong no_leader
20140520 00:49:02< happygrue> there is another one above it
20140520 00:51:47< happygrue> well, think it would be better to have _left on each of them, except that this is exactly the kind of thing zookeeper was posting about in the backwards compatibility thread I guess?
20140520 00:52:12< happygrue> so in light of that, perhaps just fixing the typo and leaving it as is would be best?
20140520 00:52:31< gfgtdf> well is was added 1day ago so no worries abotu backwards compabilty
20140520 00:53:23< happygrue> ah, I see
20140520 00:55:19< gfgtdf> happygrue: maybe we should name the attribute defeated_when=never/always/no_leader_left/no_units_left?
20140520 00:55:22< gfgtdf> idk
20140520 00:56:39< happygrue> have you asked zookeeper?  I would think he may have the best handle on what would be more/less confusing in actual use
20140520 00:56:56< happygrue> to me, it looks like no_leader already has a use (first mention in http://wiki.wesnoth.org/SideWML)
20140520 00:57:01< gfgtdf> no i have only asked mattsc and you yet
20140520 00:58:10< happygrue> I would go with what you just suggested last I think.
20140520 00:58:22< happygrue> that makes sense to me.
20140520 01:04:03< shadowm> Ask me what?
20140520 01:05:55< gfgtdf> whether we should name defeat_codition=no_units/no_leader/never/always to defeated_when=never/always/no_units_left/no_leader_left 
20140520 01:06:03< gfgtdf> shadowm: ^
20140520 01:07:05< gfgtdf> defeat_condition*
20140520 01:15:26< shadowm> Hm.
20140520 01:20:04< shadowm> *In my view*, there's a causal nuance between defeat_condition=no_leader vs. defeated_when=no_leader_left. The latter implies dependence upon a previous state (e.g. the check is performed after an action) whereas the former doesn't (the check is performed unconditionally). But this might be pushing it and the difference is probably inconsequential to the common user.
20140520 01:20:52< shadowm> Why shouldn't it be just 'defeat', though? Most WML syntax seems to be more laconic like that.
20140520 01:21:01-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140520 01:21:48< shadowm> Is there a possibility that a side's defeated status might be provided by WML before gameplay even begins?
20140520 01:22:28< gfgtdf> shadowm: i think one of the main reasons agains no_leader was that we alreeady have no_leader as a [side] key, A reason against 'defeat' si the we already have a 'lost' key which is used to determine whether a side shojudl be removed wron carryover
20140520 01:22:49< gfgtdf> s/wron/from
20140520 01:22:51< shadowm> Hm, as I suspected then.
20140520 01:23:55-!- iceiceice [~chris@207-237-132-90.ny.subnet.cable.rcn.com] has quit [Ping timeout: 240 seconds]
20140520 01:24:07-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 252 seconds]
20140520 01:24:49< shadowm> What would 'never' and 'always' mean? A side that cannot be defeated/is always considered defeated, respectively?
20140520 01:25:01< gfgtdf> yes
20140520 01:26:29< shadowm> I'd be inclined to choose a blend of both, `defeat_condition=never|always|no_units_left|no_leader_left`, but `defeat_condition=never|always` doesn't make a lot of sense without reading the documentation, so it ought to be `defeated_when` in that case.
20140520 01:26:39< shadowm> Although you might want to consult zookeeper on the matter too.
20140520 01:30:39< gfgtdf> i can make a forum poll :p
20140520 01:30:41< gfgtdf> shadowm: ok but that means at least we have a consensus about how the possible values should be called (which was the original question).
20140520 01:33:06< shadowm>  I'm not too sure why there's an 'always' value if the defeated status (not condition) can be specified by WML, but... *shrug*.
20140520 01:33:46< gfgtdf> shadowm: you mean how can teh defeated status be set by wml? you mean endlevel ?
20140520 01:34:12< shadowm> You said above "we already have a 'lost' key which is used to determine whether a side shojudl be removed wron carryover".
20140520 01:34:39< gfgtdf> yes but 'lost' ony only used for carryover not for exampel to determine who sins or whether teh scenario shoudl be ended
20140520 01:34:45< gfgtdf> wins
20140520 01:35:31< shadowm> Being defeated and not being allowed to progress to the next scenario would be different things then?
20140520 01:37:06< gfgtdf> shadowm: defeated is also a condition for non persistent ai sides, also 'lost' doesn't mean you don't get into the next level, it means you'll loose all your recruits in the next level.
20140520 01:37:30< vultraz> gfgtdf: you need help with a string?
20140520 01:37:45< shadowm_desktop> Ahhh, okay.
20140520 01:38:28< gfgtdf> shadowm: see https://gna.org/bugs/index.php?21933
20140520 01:38:51< gfgtdf> shadowm: see http://forums.wesnoth.org/viewtopic.php?f=8&t=32384&start=3195#p570637
20140520 01:39:40< gfgtdf> vultraz: we arent sure whether it should be defeat_codition=never/always/no_units_left/no_leader_left to defeated_when=never/always/no_units_left/no_leader_left 
20140520 01:40:26< gfgtdf> condition*
20140520 01:41:19< vultraz> shadowm is technically right, there is a small nuance, but it doesn't really factor in to a typical user 
20140520 01:41:54< vultraz> I think perhaps simply "defeat"
20140520 01:41:59-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 255 seconds]
20140520 01:42:47< vultraz> "defeat_condition=never" doesn't really make a lot of sense
20140520 01:43:32< vultraz> either does defeat_when. However, "defeat=" immediately make sense with all four proposed keys
20140520 01:43:57< vultraz> And by reading the logs it seems shadowm thinks the same
20140520 01:44:48< gfgtdf> vultraz: then maybe changing the 'lost' key to 'lost_carryover' ?
20140520 01:45:21< shadowm> loonycyborg: Have you had a chance to look at https://gna.org/bugs/?21891 ?
20140520 01:45:55< shadowm> At least I'm assuming the anon who can't capitalize 'i' in that issue isn't you.
20140520 01:45:56< vultraz> gfgtdf: what;s it do, exactly?
20140520 01:46:15< gfgtdf> vultraz: sides with lost=true will be removes from teh carryover at the end of teh scenario
20140520 01:46:20< gfgtdf> removed*
20140520 01:46:53< vultraz> So they don't go on to the next scenario? Isn't that the current default behavior?
20140520 01:48:02< gfgtdf> vultraz: no usually sides with persist =yes will always go to teh next scenario (whcih makes me wonder why we have 2 different keys for that.)
20140520 01:48:20< gfgtdf> persist= defaults to true for human player and to false for ai palyers.
20140520 01:48:35< vultraz> Never understood why there's save_id AND persist
20140520 01:49:06-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140520 01:49:19< shadowm> save_id: the save id. persist: whether to save or not.
20140520 01:49:40< vultraz> I see
20140520 01:49:45< shadowm> vultraz: In AtS E3S4 I have a persistent side (carried over from E3S3) suddenly stop being persistent.
20140520 01:50:01-!- Necrosporus_ is now known as Necrosporus
20140520 01:50:02< shadowm> So I specify both its save_id and negate its persistentness.
20140520 01:50:02< vultraz> alright, then where will lost= come in
20140520 01:50:29< shadowm> (Or E3S4.2 and E3S4.1, to be more specific.)
20140520 01:53:16< gfgtdf> ok it seems like it makes sense with lost, on scenario end should happen: persistent=no -> ignorign carryover. persistent=yes + lost=no ->store in carryover, persistent=yes + lost=yes -> remove form carryover.
20140520 01:53:50< gfgtdf> wesbot: senn thunderstruck
20140520 01:53:55< gfgtdf> wesbot: seen thunderstruck
20140520 01:53:55< wesbot> gfgtdf: Queried user last spoke 5d 6h ago.  thunderstruck is currently here and on the channel #wesnoth.
20140520 01:54:43< gfgtdf> having typed that i forgot what i wanted to ask him...
20140520 01:55:45< gfgtdf> thunderstruck: do you think we should rename the 'lost' key to 'lost_carryover' (i think you are the one who implemented it)?
20140520 02:00:06< Necrosporus> shadowm, an ability to throw messages at stderr might be useful as it copyable unlike [message] or probably [chat] to, though the problem is I do not want to clutter code with debug stuff as it might be hard to remove after you finish debugging
20140520 02:01:50< irker728> wesnoth: gfgtdf wesnoth:master 8dbeefef9a7e / src/team.cpp: rename values of [side]defeat_condition= http://git.io/Q2VKqQ
20140520 02:06:29 * shadowm glares at Necrosporus.
20140520 02:06:50< shadowm> What are you trying to tell me that I didn't already know?
20140520 02:08:54-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140520 02:14:52< Necrosporus> shadowm, if you know that's fine
20140520 02:15:24-!- Kexoth [~kex@78.157.29.205] has quit [Remote host closed the connection]
20140520 02:15:34< shadowm> Yeah, you apparently got the point of contention backwards.
20140520 02:15:58-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20140520 02:17:09-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140520 02:18:06< iceiceice> gfgtdf: for what its worth i like defeat_condition better than defeat
20140520 02:18:17< iceiceice> if you tell me the key is defeat_condition i already know what to expect
20140520 02:18:23< iceiceice> if you just tell me its "defeat" i have no idea
20140520 02:18:57< iceiceice> i dont think defeat_condition = always is particularly incorrect gramatically speaking, its just vacuous... but that's the point
20140520 02:20:16-!- SigurdFD [~SigurdFD@24.154.98.89] has joined #wesnoth-dev
20140520 02:20:19< shadowm> "The condition for defeat is always."
20140520 02:20:29-!- kex [~kex@78.157.29.205] has quit [Ping timeout: 255 seconds]
20140520 02:20:46< shadowm> "Defeat will take place if always."
20140520 02:21:14< iceiceice> if (circumstance), then defeated
20140520 02:21:22< iceiceice> if (no leaders), then defeated
20140520 02:21:30< iceiceice> if (no units), then defeated
20140520 02:21:35< iceiceice> if (never), then defeated
20140520 02:21:40< iceiceice> if (always), then defeated
20140520 02:21:51< shadowm> If you use pseudocode then of course it makes sense, but we were looking at the statement as a piece of natural language.
20140520 02:22:09< shadowm> Nobody says "this will happen if always".
20140520 02:22:34< shadowm> Or "the condition that must be reached for X to happen is always".
20140520 02:22:58< Necrosporus> defeated_if = true,false,no_leaders,no_units
20140520 02:22:58< iceiceice> so you could make it "defeated_when"
20140520 02:23:01< fabi_> I have seen descriptive languages for modeling concurrent processes that do so. 
20140520 02:23:19< iceiceice> idk its not actually natural language...
20140520 02:23:24< iceiceice> wml is already pretty far from natural language
20140520 02:23:41< iceiceice> just saying...
20140520 02:23:52< shadowm> Really? To me it seems to be just a few steps below BASIC (and it just as irritating, if not more).
20140520 02:24:00< shadowm> *is
20140520 02:24:06< iceiceice> BASIC isn't natural langauge either
20140520 02:24:24< shadowm> But it's inspired by it.
20140520 02:24:47< iceiceice> okay but i'm not sure it succeeds more than any other language
20140520 02:24:49< Necrosporus> By the way, canrecruit is written without underscore while most other attributes has it
20140520 02:24:58< iceiceice> no one says "FOR ... NEXT" as part of a natural langauge construct
20140520 02:25:20< Necrosporus> I don't think basic syntax is any good
20140520 02:25:25< shadowm> Where we looking at statements or macroconstructs?
20140520 02:25:31< shadowm> *Were       ARGH
20140520 02:25:41< iceiceice> ok fair enough
20140520 02:25:53< iceiceice> why dont we look for comparable examples in wml though
20140520 02:26:11< shadowm> can recruit: yes
20140520 02:26:24< shadowm> Does this happen on the first time only? Yes.
20140520 02:27:08< shadowm> Should we use delayed variable substitution? Yes, by all means. Also, let's set this variable bar to the value of the variable foo.
20140520 02:27:10< vultraz> We try to make key names sound natural when coupled with their values in a logical english sentence
20140520 02:27:28< vultraz> As well as the general structural progression
20140520 02:27:35< shadowm> ^ The last one really should be mentioned somewhere as a valid mnemonic for set_variable.to_variable, it'd make things easier.
20140520 02:27:44< iceiceice> for [command] [move] tags the new attribute is
20140520 02:27:56< iceiceice> skip_sighted = 'all', 'only_ally', 'no
20140520 02:28:13< iceiceice> (i'm just goign to try to generate examples)
20140520 02:28:43< shadowm> I don't know why we are discussing this. It's like a thousand kilometers away from the point.
20140520 02:28:48< iceiceice> ok
20140520 02:29:31-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 240 seconds]
20140520 02:30:05< shadowm> But I maintain that `[set_variable] name=foo value=bar [/set_variable]` ("set the variable named 'foo' to the value 'var'") isn't as nice as:
20140520 02:30:10< shadowm>   foo=bar
20140520 02:30:17< iceiceice> y i wish we allowed foo = bar
20140520 02:30:38< shadowm> Sadly, we got stuck with WML forever.
20140520 02:30:40< iceiceice> i got super confused by that earlier today
20140520 02:30:48< iceiceice> i had writen m.x = 1
20140520 02:30:52< iceiceice> instead of {VARIABLE m.x 1}
20140520 02:30:52< vultraz> which is why we all use {VARIABLE foo bar}
20140520 02:30:55< iceiceice> and it gave me like
20140520 02:31:04< iceiceice> a parsing error in an ai configuration file
20140520 02:31:09< iceiceice> instead of pointing out the problem
20140520 02:31:12< shadowm> vultraz: It's papering over the issue.
20140520 02:31:14< iceiceice> in my file
20140520 02:31:30< Necrosporus> shadowm, there's also Tcl with 'set foo bar' without =
20140520 02:31:30-!- SigurdFD [~SigurdFD@24.154.98.89] has quit []
20140520 02:31:31< shadowm> Macros have historically been used to deal with all kinds of deficiencies in C and C++ too.
20140520 02:31:32< vultraz> shadowm: we have lua for that
20140520 02:31:45< shadowm> vultraz: We didn't at first.
20140520 02:31:47< gfgtdf> foo=bar wouldn't allow us variable substitution in foo.
20140520 02:31:57< shadowm> And it's still a bit awkward because it requires a context switch on behalf of the programmer.
20140520 02:32:46< iceiceice> ok despite the complaints I have to say, i like WML quite a bit actually, i think its very effective
20140520 02:32:49< shadowm> Although it's really more ridiculous than that if you take into account that about 80% [citation needed] of the WML action tags are currently implemented in Lua.
20140520 02:33:33< shadowm> [lua] is kind of like asm directives.
20140520 02:33:50< Necrosporus> I wonder what if Wesnoth first devs picked up Tcl instead of WML
20140520 02:34:19< shadowm> Except that unlike assembler languages, it doesn't require you to buy a massive expensive book to learn it.
20140520 02:34:44< vultraz> Who write in assembly?
20140520 02:34:53< shadowm> People who have no option but to do so.
20140520 02:34:58 * Necrosporus did ometimes
20140520 02:35:05< shadowm> Firmware developers. System developers.
20140520 02:35:29< shadowm> Virtualization software developers.
20140520 02:35:42< Necrosporus> and people who want to have their binaries as compact as possible
20140520 02:36:05< shadowm> No, those people get depressed and quit coding altogether.
20140520 02:36:29< gfgtdf> people who want to change existent binaries-
20140520 02:37:07-!- Ivanovic_ [~ivanovic@frnk-5f75246d.pool.mediaWays.net] has joined #wesnoth-dev
20140520 02:39:19< iceiceice> hmm you know
20140520 02:39:28< iceiceice> i was just thinking about why it didnt give me a parsing error in my file
20140520 02:39:34-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 265 seconds]
20140520 02:39:40< iceiceice> it must be because... it doesnt parse each file as a unit
20140520 02:39:46< iceiceice> right?
20140520 02:39:53< Necrosporus> I have out of sync errors in replays and it seems to be caused by [move_unit]. I guess I need to debug it somehow. Could you hint where to look to determine exact problem and whenever I should be trying to debug it at all as it happens in 1.10.7?
20140520 02:40:13< iceiceice> necrosporus: look at the first error
20140520 02:40:17< iceiceice> then just think about it
20140520 02:40:37< iceiceice> i dont think theres any other way as far as i know
20140520 02:40:38< Necrosporus> it mentions coordinates the unit came from
20140520 02:40:54< Necrosporus> it's why I think OOS is caused by [move_unit]
20140520 02:41:01-!- Ivanovic_ is now known as Ivanovic
20140520 02:41:39< iceiceice> hmm well i have fixed broken replays but not one like this i guess
20140520 02:41:44< iceiceice> but one thing you could try is,
20140520 02:41:53< iceiceice> delete all the replay commands inlcuding that move_unit and after
20140520 02:41:57< iceiceice> then play it and see what the situation is
20140520 02:42:04< iceiceice> and look at what the move_unit is
20140520 02:42:08< shadowm> The preprocessor goes over an inclusion tree, feeds the results to the parser, the parser figures out where it is in the event of a catastrophe by finding the closest <0xFE>line directive.
20140520 02:42:08< iceiceice> and try to figure out how you got there
20140520 02:42:21< iceiceice> shadowm: so heres' the thing thoguh
20140520 02:42:30< shadowm> But yeah, the parser receives a massive monolithic data stream from the preprocessor. Normally.
20140520 02:42:50< shadowm> It is also able to operate on actual files (this is how add-on .pbl and _info.cfg reads are implemented).
20140520 02:42:52< iceiceice> suppose _main.cfg is {terrain_graphics} \\ {core} \\ ...
20140520 02:43:08< iceiceice> if i understand correctly,
20140520 02:43:18< iceiceice> it will preprocess terrain graphics,
20140520 02:43:25< iceiceice> get a body of text,
20140520 02:43:31< iceiceice> then paste that with what it gets from core,
20140520 02:43:33< iceiceice> and continue
20140520 02:43:51< iceiceice> in principle if i had a really crazy add-on, i could do something like
20140520 02:43:57< iceiceice> {file1} \\ {file2}
20140520 02:44:00< shadowm> It's really more like the following: the preprocessor starts reading _main.cfg, copies its contents to its output stream.
20140520 02:44:01< iceiceice> where {file1} contains an [if]
20140520 02:44:07< iceiceice> closed by [/if] in {file2}
20140520 02:44:08< iceiceice> right?
20140520 02:44:17< shadowm> If it finds substitution braces, it resolves them and throws the results onto the original output stream too.
20140520 02:44:21< iceiceice> y
20140520 02:44:29< shadowm> Rinse and repeat recursively until it reaches the original file's EOF.
20140520 02:44:44< iceiceice> so maybe it would be nice if there was a "strict inclusion mode"
20140520 02:44:52< iceiceice> which checks that each piece parses properly
20140520 02:44:55< iceiceice> before returning
20140520 02:45:14< iceiceice> because then i wouldnt get syntax errors reported in completely different parts of the tree
20140520 02:45:36< shadowm> It'd be a fun experiment, but I have no idea about the logistics compared to the monolithic approach.
20140520 02:45:57< iceiceice> y i guess it depends what the preprocessor implementation is
20140520 02:46:20< shadowm> I mean whether it's faster to go over every individual file or just go over the monolithic pp output.
20140520 02:46:47< shadowm> The former would certainly remove some of the power that's currently available to content creators.
20140520 02:46:49< iceiceice> if i'm developing an add-on i'd rather get meaningful error messages
20140520 02:47:41< shadowm> For example, map files are currently passed in [scenario] as part of the map_data attribute. The value of map_data is a massive string resolved by a brace substitution.
20140520 02:47:41< iceiceice> idk i guess what i had in mind was something like {!filename} would parse the result strictly 
20140520 02:48:10< shadowm> Right.
20140520 02:48:48< shadowm> We'd still be left with the most common cause for obscure errors: macros.
20140520 02:49:42< shadowm> We still have a few parametric macros that do not describe valid WML, such as FOREACH... although in this day and age, I'm not sure why we haven't written a [foreach] statement in Lua yet.
20140520 02:53:26-!- gfgtdf [~chatzilla@e176189249.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0.1/20140506152807]]
20140520 02:54:17< fabi_> shadowm: Please fill a FR for the [foreach] lua statement.
20140520 02:54:55< shadowm> I've been wanting to do it myself for my own add-on since a while, actually.
20140520 02:55:58< shadowm> Since I already break strict compatibility with mainline WML in other regards anyway.
20140520 02:58:24< vultraz> Wouldn't it just be passing a WML table through lua's 
20140520 02:58:28< vultraz> 'for' statement
20140520 03:01:16-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Remote host closed the connection]
20140520 03:07:28< shadowm> vultraz.
20140520 03:07:59< shadowm> You should know by now that you don't need to nudge me like that. I know what I'm doing more than you know what I did when you stole my code.
20140520 03:08:50-!- sachith500 [~kvirc@112.134.104.160] has joined #wesnoth-dev
20140520 03:09:00< shadowm> And if it were literally 'just' as you suggest, then I'm afraid it'd be completely useless.
20140520 03:09:40< vultraz> I'm not nudging you
20140520 03:09:50< vultraz> It's so you can tell me if my notion is right or wrong
20140520 03:09:53< vultraz> Since I don't know
20140520 03:10:02< shadowm> It's right but too basic.
20140520 03:10:20< shadowm> The full cake needs more ingredients than just flour.
20140520 03:21:42-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140520 03:29:28-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20140520 03:32:34-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Ciao]
20140520 03:32:48< Necrosporus> > "victory_when_enemies_defeated = false", then it will further continue so long as 1.) There is a human controlled side, OR, 2.) There are no locally controlled sides. 
20140520 03:32:56< Necrosporus> I guess it should be 'no'
20140520 03:33:15< Necrosporus> citation from sidewml page
20140520 03:33:25< shadowm> false and no are equivalent.
20140520 03:38:10< iceiceice> hmm so if we have just pushed changes to check victory, 
20140520 03:38:15< iceiceice> i think i'm also going to change the implementation of that one
20140520 03:38:18< iceiceice> it should be
20140520 03:38:30< iceiceice> 1.) there is a human controlled side or 2.) there is a "network" (remote human) controlled side
20140520 03:39:41< shadowm> What was the justification for changing the API mid-feature-freeze, again, so I can pass it on to our users in the next announcement?
20140520 03:40:15< iceiceice> when we made the sync changes, one of the things that happened is that we began to run check_victory much more often than before
20140520 03:40:27< iceiceice> at the end of any synced context
20140520 03:40:36< iceiceice> because apparently if you dont do that, you can get scenarios that strangely continue
20140520 03:40:54< iceiceice> however, most umc did not try to port or test until now,
20140520 03:40:54< iceiceice> and there was much complaints
20140520 03:41:17< iceiceice> anyone who killed all the units and builds a randomized map probably gets killed
20140520 03:41:25< iceiceice> dugi got killed when he did things like,
20140520 03:41:37< iceiceice> make all the players jump throguh a "portal" and disappear at the end of the scenario,
20140520 03:41:53< iceiceice> because with the new carryover loss rules, every time the characters jumped thorugh they got removed from carryover
20140520 03:41:56< shadowm> RIP Dugi.
20140520 03:42:01< iceiceice> :(
20140520 03:42:10< iceiceice> so ....
20140520 03:42:22< iceiceice> the api change is just to make everyone able to easily cope with the new system
20140520 03:42:25< iceiceice> which will ultiamtely be better for everyone
20140520 03:42:41< iceiceice> i'm actually really glad about the new changes, its much better than fight on
20140520 03:42:55< shadowm> OK make sure to mention that in R_N in words that Jane the WML coder can understand.
20140520 03:42:59< iceiceice> also i stupidly introduced a bug when i implemented fighton
20140520 03:43:30< iceiceice> ok
20140520 03:43:53< shadowm> Also try not to make it sound like "we did something wrong" unless that's really the case.
20140520 03:44:05< shadowm> Uhhh... yeah.
20140520 03:44:27< shadowm> I guess we did something wrong. ._.
20140520 03:45:31< iceiceice> idk its normal give and take of development
20140520 03:45:41< iceiceice> if anything we can blame it on them for not testing earlier :)
20140520 03:46:06< shadowm> It's mysterious, though. 1.10 and 1.12 both took much longer than every other stable series after 1.0 to reach gold.
20140520 03:47:23< shadowm> I'd like to put it all on a graph to extrapolate the trend for 1.14, but I surmise 1.12's development cycle has either already surpassed 1.10's in length, or is about to.
20140520 03:47:59< fabi_> The question is if a major project really needs fast development cycles anymore.
20140520 03:48:59< shadowm> WML features.
20140520 03:49:23< shadowm> There is no other way to get them to the main audience.
20140520 03:50:26< shadowm> Us UMC authors tend to like WML features a lot, and even though Lua gives us the power to backport or emulate some stuff, even I started neglecting support for 1.10.x in my add-on after some point.
20140520 03:51:19< vultraz> I dropped 1.10 support around 1.11.2
20140520 03:51:42< shadowm> Yeah well, you don't count because your add-on is still an early work in progress.
20140520 03:52:13< shadowm> It's harder to drop support when you have an established userbase (as microscopic as it may be) and over 75% of the campaign finished.
20140520 03:52:54< vultraz> And unfortunately I didn't get a feature I wanted into 1.12 so now I'll have to workaround
20140520 03:52:58< vultraz> ._.
20140520 03:53:07< iceiceice> i think 1.12 will be a really good release, we fixed a lot of bugs already
20140520 03:53:08< iceiceice> and a lot of really old ones
20140520 03:53:11< iceiceice> and theres great new art and content
20140520 03:53:51< shadowm> It's also very annoying that: 1) we can't force stable users to update every time a new point release happens; and 2) point releases are very few and far between.
20140520 03:53:52< fabi_> I am a lot behind in bug fixing. 
20140520 03:54:28< vultraz> shadowm: we could if we used steam
20140520 03:54:29< shadowm> (Cue vultraz answering point 1 with "Steam" in 3... 2... 1...)
20140520 03:54:32< shadowm> -1
20140520 03:55:17< shadowm> Point 2 remains unsolved.
20140520 03:55:47< iceiceice> idk why dont we put something on the add-on server "additional core wml (.lua)" that we update when we feel like it
20140520 03:55:48< shadowm> I suppose in a way Steam would also solve that -- less crap to upload and download.
20140520 03:55:54-!- sachith500 [~kvirc@112.134.104.160] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140520 03:56:01< iceiceice> err, "additional core lua"
20140520 03:56:15< iceiceice> oh i get it :doh:
20140520 03:56:16< shadowm> iceiceice: Oh, if only all bugs came from Lualand.
20140520 03:56:21< Necrosporus> You would have make distribution maintainers update stable releases every time then users will get the update automatically
20140520 03:56:35< iceiceice> y its too hard probly
20140520 03:56:39< shadowm> That doesn't work in practice, hence I didn't bring it up.
20140520 03:57:00< vultraz> shadowm: iceiceice and  I had discussed the possibility of putting 1.12 on greenlight
20140520 03:57:01< shadowm> It especially doesn't if _we_ don't make point releases often.
20140520 03:57:06< vultraz> and seeing what the response it
20140520 03:57:07< vultraz> is
20140520 03:57:30< shadowm> vultraz: It has to be someone from our legal team, I believe.
20140520 03:57:37< iceiceice> y
20140520 03:57:48< vultraz> Well, who would that be
20140520 03:57:57< shadowm> You know who those three are.
20140520 03:58:01< iceiceice> also, someone who can get $100 in wesbucks, that is apparently the fee
20140520 03:58:02< shadowm> Classified information, though.
20140520 03:58:50< iceiceice> shadowm: does it actually have to be someone from the legal team?
20140520 03:58:53< shadowm> And you'll also need to convince Ivanovic that it's worth it, since he'll probably wind up bearing the load unless someone else steps up to maintain it forever.
20140520 03:59:04< iceiceice> was that needed for the android releases etc.?
20140520 03:59:35< shadowm> iceiceice: I think I read Steam required this, or an authorized representaive.
20140520 03:59:37< vultraz> shadowm: wouldn't each update on steam just be equivalent to a new stable point release now?
20140520 03:59:48< iceiceice> oh y i remember that too now
20140520 03:59:56< shadowm> No idea how those appstore releases were done, because a lot more things happen in secret here than even I know.
20140520 04:00:21< shadowm> vultraz: Yeah, with whatever additional overhead Steam requires to support other platforms?
20140520 04:00:46< shadowm> Ivanovic releases source code. Somehow I doubt Steam requires or accepts application maintainers to upload just source code.
20140520 04:00:53< vultraz> shadowm: hm, that's true
20140520 04:01:13< shadowm> So no idea how that'd be handled -- best ask people who maintain an app/game on Steam already.
20140520 04:01:28< vultraz> I know just the people to ask
20140520 04:01:33< shadowm> I think there's a couple of GPL engine (not art) games that do.
20140520 04:01:49< shadowm> vultraz: Don't say "frogatto".
20140520 04:01:58< vultraz> (NOT frogatto, they're only through greenlight not on steam)
20140520 04:01:58< shadowm> They have made exactly zero releases on Steam so far.
20140520 04:02:04< shadowm> Yep.
20140520 04:02:14< shadowm> Oh, you mean the planething stuff?
20140520 04:02:26< shadowm> Planes. Something to do with planes.
20140520 04:03:00< iceiceice> fabi_: i am thinking i might take a stab at the path finder caching thing soon
20140520 04:03:01< vultraz> no
20140520 04:03:03< shadowm> Or was it flight? You always complained about Git and them before you started using Git for your own stuff.
20140520 04:03:26< iceiceice> i read two papers that gave me a simple idea that i think will work well
20140520 04:03:26< vultraz> FlightGear
20140520 04:03:34< vultraz> but theyre not on steam
20140520 04:03:35< shadowm> Otherwise, I don't know who else you might possibly know who has made releases on Steam.
20140520 04:03:43< iceiceice> http://www.diku.dk/PATH05/CRC-book1.pdf
20140520 04:03:45< iceiceice> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.4485
20140520 04:03:45< iceiceice> if anyone cares :)
20140520 04:03:47< vultraz> Terraria
20140520 04:04:04< iceiceice> i havent read the pathfinder cod ehtough
20140520 04:04:04< shadowm> vultraz: I didn't know you knew the devs.
20140520 04:04:30< vultraz> The devs hang out in their IRC channel, including the creator
20140520 04:04:33-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20140520 04:05:13< shadowm> Well, cool I guess.
20140520 04:05:27< shadowm> I assume they support at least two different platforms?
20140520 04:07:22< vultraz> Eh, well I think they're Windows only, but Red might know
20140520 04:07:46< shadowm> We were discussing multi-platform releases. :p
20140520 04:08:10< shadowm> It's pretty much impossible to do multi-platform when you only have one platform.
20140520 04:08:54-!- kex [~kex@78.157.29.205] has quit [Ping timeout: 240 seconds]
20140520 04:09:30< vultraz> Their project is still the closest I've seen to ours
20140520 04:09:52< vultraz> Though theirs is a closed dev environment, no public repo access
20140520 04:12:05< Necrosporus> iceiceice, I have tried to remove content from replay, seems like my [move_unit] moves unit from some point, then AI moves other units and then  'unfound location for source of movement', maybe AI thought there was a unit still unaware about it being moved or something?
20140520 04:13:03< iceiceice> when you say "your" move unit is this something you added with WML?
20140520 04:13:28< iceiceice> so it might be that you used move unit at an unsynced time
20140520 04:14:07< iceiceice> synchronization in 1.10 is really tricky ...
20140520 04:14:17< iceiceice> gfgtdf made it all better in 1.12
20140520 04:14:32< iceiceice> now i will never have to decipher the wierdness of 1.10 myself
20140520 04:14:53< iceiceice> you can get lists on the wiki though of which events are unsynced,
20140520 04:15:04< iceiceice> if you do anything to alter the game state at an unsynced time your replays go kablooie
20140520 04:15:43< iceiceice> the only really bizarre oos i ever successfully debugged in 1.10 was one in mabuse's scenario
20140520 04:16:08< iceiceice> *one of mabuse's scenarios
20140520 04:20:50< Necrosporus> iceiceice, move_unit is what I performed in a custom event, yes
20140520 04:21:01< iceiceice> ok but what is firing the custom event
20140520 04:21:12< Necrosporus> attack event
20140520 04:21:18< iceiceice> is that synced?
20140520 04:21:28< Necrosporus> Where 's the list?
20140520 04:21:32< Necrosporus> I dunno
20140520 04:21:52< iceiceice> Necrosporus: nope.
20140520 04:21:53< iceiceice> http://wiki.wesnoth.org/Eventwml#Multiplayer_safety
20140520 04:23:24< Necrosporus> attack (not tested "attack" but i suppose it is because the other attack related evens are also unsafe.) 
20140520 04:41:59< Necrosporus> iceiceice, so does it mean I could stop trying to debug and just remove the cutscene?
20140520 04:42:56< iceiceice> just do the things at different times
20140520 04:43:31< iceiceice> it shouldnt be necessary to use "attack" events in a cutscene, no?
20140520 04:44:59< iceiceice> hmm ok i think i understand 
20140520 04:44:59< iceiceice> yeah more or less you have to not use the cutscene, or move ot 1.11
20140520 05:18:50-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20140520 05:20:01< irker728> wesnoth: Chris Beck wesnoth:master aa83190e07e5 / src/editor/map/map_fragment.cpp: pre-empty a division by zero http://git.io/HtXRtg
20140520 05:20:03< irker728> wesnoth: Chris Beck wesnoth:master 1bd43bb6a998 / src/play_controller.cpp: refactor is_observer out of check_victory http://git.io/4X9QQw
20140520 05:20:05< irker728> wesnoth: Chris Beck wesnoth:master c211bc4b7eaf / src/team.cpp: Merge branch 'master' of git://github.com/wesnoth/wesnoth http://git.io/eWemwA
20140520 05:22:58-!- kex [~kex@78.157.29.205] has quit [Ping timeout: 240 seconds]
20140520 05:31:59-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 252 seconds]
20140520 05:34:18-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140520 05:37:16< irker728> wesnoth: Chris Beck wesnoth:master 4b64eea0a6c7 / src/play_controller.cpp: always flush streams when logging in play_controller http://git.io/WSFEXQ
20140520 05:42:44-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140520 05:50:38-!- Guest23773 [~cib@p5DD22404.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140520 05:50:42-!- Ivanovic [~ivanovic@frnk-5f75246d.pool.mediaWays.net] has quit [Changing host]
20140520 05:50:42-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140520 05:51:08< irker728> wesnoth: Chris Beck wesnoth:1.12 e209cd26fdd5 / src/editor/map/map_fragment.cpp: preempt a division by zero http://git.io/03KS9g
20140520 06:01:22-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20140520 06:35:41-!- Guest23773 [~cib@p5DD22404.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
20140520 06:50:02-!- Appleman1234 [~Appleman1@pool-173-74-87-52.dllstx.fios.verizon.net] has quit [Ping timeout: 255 seconds]
20140520 06:54:24-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140520 07:02:25-!- Appleman1234 [~Appleman1@pool-173-74-87-52.dllstx.fios.verizon.net] has joined #wesnoth-dev
20140520 07:07:40-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20140520 07:11:54-!- kex [~kex@78.157.29.205] has quit [Ping timeout: 240 seconds]
20140520 07:13:04-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140520 07:18:41-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140520 07:32:04-!- iceiceice_ [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140520 07:34:47-!- mjs-de [~mjs-de@f048238126.adsl.alicedsl.de] has joined #wesnoth-dev
20140520 07:37:44-!- Netsplit *.net <-> *.split quits: iceiceice
20140520 07:43:03-!- 77CAAKH5L [~cib@132.231.178.32] has joined #wesnoth-dev
20140520 07:44:36-!- groggy [~chatzilla@71-82-37-181.dhcp.hckr.nc.charter.com] has joined #wesnoth-dev
20140520 07:47:14-!- 77CAAKH5L is now known as cib1
20140520 07:55:00-!- groggy [~chatzilla@71-82-37-181.dhcp.hckr.nc.charter.com] has quit [Remote host closed the connection]
20140520 08:01:20-!- cib1 [~cib@132.231.178.32] has quit [Ping timeout: 255 seconds]
20140520 08:02:02-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 255 seconds]
20140520 08:25:22-!- prophile [~alynn@oftn/member/prophile] has joined #wesnoth-dev
20140520 08:29:20-!- mjs-de [~mjs-de@f048238126.adsl.alicedsl.de] has quit [Remote host closed the connection]
20140520 08:38:26-!- prophile [~alynn@oftn/member/prophile] has quit [Quit: The Game]
20140520 08:39:09-!- lipkab [~the_new_l@2001:738:5404:192:9e4e:36ff:fe7c:534c] has joined #wesnoth-dev
20140520 08:39:14-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140520 08:40:54-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Ping timeout: 240 seconds]
20140520 08:42:50-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140520 08:51:11-!- irker728 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140520 08:56:49-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20140520 09:01:14-!- kex [~kex@78.157.29.205] has quit [Ping timeout: 240 seconds]
20140520 09:05:15-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140520 09:19:07-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20140520 09:23:31-!- kex [~kex@78.157.29.205] has quit [Ping timeout: 240 seconds]
20140520 09:23:46-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140520 09:28:13-!- RiftWalk1r [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140520 09:28:20-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140520 09:32:41-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Ping timeout: 255 seconds]
20140520 09:42:25-!- lipkab [~the_new_l@2001:738:5404:192:9e4e:36ff:fe7c:534c] has quit [Ping timeout: 252 seconds]
20140520 09:58:55-!- Kexoth [~kex@89.205.75.19] has joined #wesnoth-dev
20140520 10:02:47-!- lipkab [~the_new_l@2001:738:5404:192:9e4e:36ff:fe7c:534c] has joined #wesnoth-dev
20140520 10:02:47-!- spoffy [~spoffy@152.78.175.8] has joined #wesnoth-dev
20140520 10:34:48-!- mjs-de [~mjs-de@f048238126.adsl.alicedsl.de] has joined #wesnoth-dev
20140520 10:35:15< thunderstruck> 20140520 01:55:45< gfgtdf> thunderstruck: do you think we should rename the 'lost' key to 'lost_carryover' (i think you are the one who implemented it)?
20140520 10:35:46< thunderstruck> gfgtdf: well, 'lost' indicates that side had lost, so I'm not sure why do you want to rename it so.
20140520 10:53:00-!- lipkab [~the_new_l@2001:738:5404:192:9e4e:36ff:fe7c:534c] has quit [Quit: Vannak idők, mikor menni kell]
20140520 11:09:10< loonycyborg> shadowm: I always log on to comment at gna.org :P
20140520 11:38:51< loonycyborg> shadowm: I have no idea why Saved Games is used on 1.10 for him. I only see our SHGetSpecialFolderPath code in 1.10 branch, and it got My Games hardcoded
20140520 11:41:10< loonycyborg> I'm not against adding some Vista+ code to handle this but I still have no way of testing it. Still got only winxp due to lack of disk space..
20140520 12:01:03-!- spoffy [~spoffy@152.78.175.8] has quit [Ping timeout: 240 seconds]
20140520 12:22:22-!- aquileia [863c36b4@gateway/web/freenode/ip.134.60.54.180] has joined #wesnoth-dev
20140520 12:22:52-!- Kexoth [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140520 12:23:28-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140520 12:28:19-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 276 seconds]
20140520 12:40:41-!- markus_ [~mjs-de@f049171204.adsl.alicedsl.de] has joined #wesnoth-dev
20140520 12:43:55-!- mjs-de [~mjs-de@f048238126.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20140520 12:46:48-!- aquileia [863c36b4@gateway/web/freenode/ip.134.60.54.180] has quit [Ping timeout: 240 seconds]
20140520 12:47:08-!- cib [~cib@132.231.178.71] has joined #wesnoth-dev
20140520 12:47:32-!- cib is now known as Guest48896
20140520 12:50:32-!- markus_ is now known as mjs-de
20140520 13:17:03-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140520 13:17:16-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140520 13:18:55-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140520 13:24:51-!- sachith500 [~kvirc@112.135.200.137] has joined #wesnoth-dev
20140520 13:37:04-!- sachith500 [~kvirc@112.135.200.137] has quit [Read error: Connection reset by peer]
20140520 13:37:22-!- sachith500 [~kvirc@112.135.200.137] has joined #wesnoth-dev
20140520 13:39:36-!- boucman_work [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140520 13:55:49-!- sachith500 [~kvirc@112.135.200.137] has quit [Read error: Connection reset by peer]
20140520 13:56:06-!- sachith500 [~kvirc@112.135.200.137] has joined #wesnoth-dev
20140520 14:04:45-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140520 14:07:23-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Computer's napping]
20140520 14:08:47-!- Guest48896 [~cib@132.231.178.71] has quit [Ping timeout: 255 seconds]
20140520 14:28:09-!- Guest48896 [~cib@132.231.178.2] has joined #wesnoth-dev
20140520 14:28:13-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140520 14:30:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140520 15:26:20-!- irker448 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140520 15:26:20< irker448> wesnoth: Chris Beck wesnoth:master c73b5945d994 / src/ (10 files in 5 dirs): add static const members ZERO, default_dirs, of map_location http://git.io/YTF0KQ
20140520 15:26:20< irker448> wesnoth: Chris Beck wesnoth:master c5838b9513a6 / src/ (43 files in 11 dirs): inline the definition map_location::null_location http://git.io/ScVILQ
20140520 15:26:21< irker448> wesnoth: Chris Beck wesnoth:master 302b0a831bfd / src/ (filesystem.cpp filesystem.hpp preferences.cpp): fixup travis (failure to find preferences is not reported as error) http://git.io/hQWxTg
20140520 15:28:04-!- sachith500 [~kvirc@112.135.200.137] has quit [Ping timeout: 265 seconds]
20140520 15:29:05-!- sachith500 [~kvirc@112.134.34.13] has joined #wesnoth-dev
20140520 15:29:20-!- Guest48896 [~cib@132.231.178.2] has quit [Ping timeout: 255 seconds]
20140520 15:37:03-!- iceiceice_ [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Ping timeout: 240 seconds]
20140520 15:47:12-!- sachith500 [~kvirc@112.134.34.13] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140520 15:49:27-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140520 15:52:26-!- boucman_work [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140520 15:55:28< Necrosporus> What happens when you try to assign role several times? can several units have same role or it's cleared each time?
20140520 16:06:31-!- iceiceice_ [~chris@207-237-132-91.ny.subnet.cable.rcn.com] has joined #wesnoth-dev
20140520 16:08:02< irker448> wesnoth: Chris Beck wesnoth:master 8bffd6c5cf6b / travis_wml_unit_tests.sh: enable full debugging the first time travis runs scripts http://git.io/zwlOGg
20140520 16:10:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140520 16:13:02-!- vernon [~quassel@77-234-83-36.pool.digikabel.hu] has joined #wesnoth-dev
20140520 16:13:55-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 240 seconds]
20140520 16:15:57-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140520 16:34:56-!- cib [~cib@p5DD22404.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140520 16:35:20-!- cib is now known as Guest72616
20140520 16:41:34-!- Jetrel_ [~Jetrel@c-75-73-180-126.hsd1.mn.comcast.net] has joined #wesnoth-dev
20140520 16:43:53-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20140520 16:44:19-!- Jetrel [~Jetrel@c-75-73-180-126.hsd1.mn.comcast.net] has quit [Ping timeout: 240 seconds]
20140520 16:54:32-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has joined #wesnoth-dev
20140520 17:00:47-!- vernon [~quassel@77-234-83-36.pool.digikabel.hu] has quit [Remote host closed the connection]
20140520 17:20:56-!- DCW [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has quit [Remote host closed the connection]
20140520 17:29:17< Necrosporus> error gui/general: vertical_scrollbar [_vertical_scrollbar] recalculate: Can't recalculate size, force a window layout phase.
20140520 17:29:26< Necrosporus> What does it mean?
20140520 17:33:58< iceiceice_> C++ trivia question:
20140520 17:34:07< iceiceice_> is `static bool foo = true` ok at file scope?
20140520 17:34:10< iceiceice_> because "bools are ints"?
20140520 17:34:39-!- SigurdFD [~SigurdFD@24.154.98.89] has joined #wesnoth-dev
20140520 17:35:21< iceiceice_> s/file scope/at times when `static int foo = 1` is okay
20140520 17:40:18< irker448> wesnoth: Chris Beck wesnoth:master 1e16b9a7e12f / src/ (game_controller.cpp log.cpp log.hpp): refactor strict logging http://git.io/F_4EuA
20140520 17:40:34-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140520 17:41:08< lipkab> iceiceice_: Bools are not ints.
20140520 17:41:27< lipkab> But it's okay nonetheless.
20140520 17:42:17< iceiceice_> lipkab: okay thanks
20140520 17:43:24< Necrosporus> iceiceice_, moveto has its problems too
20140520 17:43:52< Necrosporus> I want to have specific dialogs when a new enemy is introduced
20140520 17:44:06< Necrosporus> As I use 1.10, sighted event won't work
20140520 17:44:25< iceiceice_> Necrosporus: y idk what to tell you, these are all fixed now
20140520 17:44:32< Necrosporus> SIGHTED macro doesn't work for me as well
20140520 17:44:50< Necrosporus> So I tried to use moveto
20140520 17:45:07< Necrosporus> but setting it correctly is somewhat tricky
20140520 17:45:18< iceiceice_> y i mean you are putting yourself through a lot of pain here
20140520 17:45:23< iceiceice_> esp. given that 1.12 will be soon
20140520 17:45:56< iceiceice_> if you test it in 1.12 and any of those things dont work, that would be something i would really want to hear about
20140520 17:46:03-!- _8680_ [~8680@2002:4404:712c:0:c470:9a8:3a56:65a4] has quit [Ping timeout: 252 seconds]
20140520 17:46:16< Necrosporus> But 1.11 is said to be bugged, how could I distinguish my mistake from engine bug?
20140520 17:46:22-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140520 17:46:35< iceiceice_> whats bugged in 1.11
20140520 17:46:47-!- _8680_ [~8680@2002:4404:712c:0:cce1:d89a:a591:b6b5] has joined #wesnoth-dev
20140520 17:46:51< Necrosporus> > 1.11.14 (1.12 beta 5) is too buggy to be announced
20140520 17:47:18< iceiceice_> thats just some interface clicking issue that slipped by us
20140520 17:47:19< iceiceice_> in general 1.11 is much much less buggy than 1.10
20140520 17:47:51< iceiceice_> if you can build master, or even just use 1.11.13 all of these events you are talking about should work perfectly
20140520 17:48:10< iceiceice_> and anyways... i want you to find engine bugs and report them (!)
20140520 17:48:16< iceiceice_> you won't encounter fewer in 1.10
20140520 17:49:22< Necrosporus> By the way even 1.10.0 was quite stable... from player point of view... though when I started to write, it turned out to be ... not as stable
20140520 17:49:43< Necrosporus> iceiceice_, is there any point to report 1.10 bugs now?
20140520 17:50:14< zookeeper> if they're 1.10-only, then probably not
20140520 17:50:56< Necrosporus> Should I put my addon on server if it has 1 mostly working scenario out of (maybe 6-9)?
20140520 17:51:53< Necrosporus> And it's 1.10 so if I switch on 1.11 it will stay 1 scenario forever
20140520 17:54:06< SigurdFD> Is someone around who can assign a bug? I found the cause of the last half of bug #20895.
20140520 17:54:08< SigurdFD>  Also I'm wondering if it'd be best to split it into it's own report.
20140520 17:54:19-!- gfgtdf [~chatzilla@e176189249.adsl.alicedsl.de] has joined #wesnoth-dev
20140520 17:55:17< iceiceice_> wesbot: bug#20895
20140520 17:55:24< iceiceice_> wesbot: bug #20895
20140520 17:55:25< wesbot> Bug #20895  Assigned to: None  Status: None  Priority: 5 - Normal
20140520 17:55:25< wesbot> Summary: Using the default random map generator in sp causes assertation failure
20140520 17:55:28< wesbot> Original submission: Whenever the default random map generator is used in a si
20140520 17:55:31< wesbot> ngle player campaign, the following happens:Assertion failed!\src\random.c
20140520 17:55:33< wesbot> URL: http://gna.org/bugs/?20895
20140520 17:55:36< wesbot> Attached file (1st): http://gna.org/bugs/download.php?file_id=18082
20140520 17:56:06< SigurdFD> there's two separte issues in it: the assert, which gfgtdf's rng changes fixed
20140520 17:56:33< SigurdFD> and multiplayer start of scenario saves using default mapgen not working.
20140520 17:56:59< Necrosporus> gfgtdf, are you going to fix attack OOS errors in 1.10? it's said to be fixed, but not for 1.10
20140520 17:57:39< iceiceice_> SigurdFD: thanks for the very detailed report, i will take a look at this
20140520 17:57:57< gfgtdf> Necrosporus: i dotn change anytign related to OOS in 1.10 since my changes 1) might rely n other code done in 1.11, 2) caus incompabilty to older clients
20140520 17:58:02< gfgtdf> won't
20140520 17:58:59< SigurdFD> iceiceice_ at this point only comment #10 and above is relevant.
20140520 17:59:58< iceiceice_> Necrosporus: the sync changes are not something that can be easily backported to 1.10, it required new architecture, it wouldnt be appropriate to send it back
20140520 18:00:01< gfgtdf> Necrosporus: also attacsl beeng unsave usually only means that you cannot use sm sync that means [unstore_unit]  with advancements, [get_global_variable] and [message] with [option]s inside eeverythign else shoudl work
20140520 18:00:19< gfgtdf> s/sm/mp
20140520 18:00:53< Necrosporus> gfgtdf, I have problem with [move_unit]
20140520 18:00:58< Necrosporus> you didn't mentioned it
20140520 18:01:31< gfgtdf> hm i dont think [move_unit] uses one of teh above internaly so i dont see a reason not to use it instide an attack event.
20140520 18:01:32< Necrosporus> I could send you replay, but I guess you won't be able to play it back without my addon
20140520 18:02:12< gfgtdf> Necrosporus: you should try to find a minimalisirtc case wherethat error happened
20140520 18:02:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140520 18:03:03< gfgtdf> Necrosporus: ideally a which has < 100 lines after macros has been expanded or even better with no marcos at all
20140520 18:03:48< gfgtdf> Necrosporus: custon unit are also dislikes in this case
20140520 18:03:51< gfgtdf> disliked
20140520 18:04:40< gfgtdf> iceiceice_: is teh moveto bug fixed on current master ?
20140520 18:04:50< gfgtdf> the animation bug
20140520 18:04:58< iceiceice_> y should be
20140520 18:05:09< iceiceice_> you mean the jitery movement mattsc reported right?
20140520 18:05:21< gfgtdf> ye
20140520 18:05:33< iceiceice_> y if it is happening for you please let me know
20140520 18:05:43< iceiceice_> i think i fixed it though
20140520 18:07:05< irker448> wesnoth: gfgtdf wesnoth:master 3dbc78f85f81 / src/game_events/ (action_wml.cpp pump.cpp pump.hpp): add "write_to" parameter to wml_message http://git.io/w35T3A
20140520 18:07:07< irker448> wesnoth: gfgtdf wesnoth:master 7c69fcb3be8f / src/game_events/ (action_wml.cpp pump.cpp pump.hpp): replace write_to with to_chat in [wml_message] http://git.io/mlP0kA
20140520 18:07:09< irker448> wesnoth: gfgtdf wesnoth:master e422aa60d31f / src/game_events/ (action_wml.cpp pump.cpp pump.hpp): Merge pull request #166 from gfgtdf/wml_message http://git.io/gnpPCw
20140520 18:08:57< irker448> wesnoth: gfgtdf wesnoth:master bc110604fd8b / src/minimap.hpp: #include <map.hpp> -> #include "map.hpp" http://git.io/0MMNZQ
20140520 18:09:40< gfgtdf> iceiceice_: are there still blockers for 1.11.15 ?
20140520 18:12:44< iceiceice_> i dont know
20140520 18:12:55< iceiceice_> i still didnt get throw LoW networked yet
20140520 18:12:58< iceiceice_> i might try again though
20140520 18:13:03< iceiceice_> i'm trying to fix the travis script thing
20140520 18:17:16< gfgtdf> iceiceice_: are sou sure this: c73b5945d9946553386bc66b92c7021e6df3dc83 speeds up ? the getter for zero location  uses a static function variable which means the we need to check everytimewhether the object is initilized i thought.
20140520 18:17:31< iceiceice_> i think compiler will optimize that though
20140520 18:17:43< iceiceice_> the advantage of this is that
20140520 18:17:51< iceiceice_> other compilation units know what the value is at runt ime
20140520 18:17:58< iceiceice_> they know its (0,0)
20140520 18:18:05< iceiceice_> or for null location, (-999,-999)
20140520 18:18:27< iceiceice_> i think if the actual values in map_location.cpp it might not know them, or at least not until later in the process
20140520 18:18:42< iceiceice_> i could be wrong though
20140520 18:18:52< iceiceice_> not a c++ expert
20140520 18:19:12< iceiceice_> *other compilation units will know what the value is going to be, statically
20140520 18:20:20< iceiceice_> you are right, it might actually be slower if -O0 is on i guess
20140520 18:20:53< gfgtdf> iceiceice_:  what does -O0 do ?
20140520 18:20:58< iceiceice_> no optimizations
20140520 18:21:13< iceiceice_> if you build debug with scons, you will get -O0
20140520 18:21:18< gfgtdf> iceiceice_: hm i'd say optimizing of the map_location contructors seems easier than optmisation of the 'check whether this values is already initialised'.
20140520 18:21:45< iceiceice_> so i did it partly because there is a note in map_location.hpp 
20140520 18:21:58< iceiceice_> that we made operators ==, <=, >= inline, for efficeincy reasons
20140520 18:22:18< iceiceice_> if you are inlining ==, a lot of times you are checking "== map_location::null_location"
20140520 18:22:19< iceiceice_> but,
20140520 18:22:40< iceiceice_> if the acutal value of map_location::null_location is in map_location.cpp
20140520 18:22:51< iceiceice_> then i think the other compilation units wont know what it is, its just a black box
20140520 18:22:58< iceiceice_> maybe after linking there is more optimizations or smething
20140520 18:23:22< iceiceice_> i think the static getter is a common idiom,
20140520 18:24:04< iceiceice_> i think with optmizations on it will get inlined
20140520 18:24:38< iceiceice_> idk if you dont like it feel free to revert
20140520 18:25:01< Necrosporus> Seems like tropical forest changed appearance... Could I get palms from 1.10 back in 1.11?
20140520 18:27:14-!- happygrue_ [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140520 18:27:55-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 240 seconds]
20140520 18:27:56-!- happygrue_ is now known as happygrue
20140520 18:27:58< irker448> wesnoth: Chris Beck wesnoth:master ca0d21abd9ab / src/ (filesystem.cpp preferences.cpp): always flush filesystem errors (so we can see on travis) http://git.io/zcXHFQ
20140520 18:28:00< irker448> wesnoth: Chris Beck wesnoth:master f4ac89c400df / src/ (4 files in 2 dirs): Merge branch 'master' of git://github.com/wesnoth/wesnoth http://git.io/-8_KdA
20140520 18:29:07< SigurdFD> Necrosporus: I think they redid those palms and moved them to a different terrain code in the editor
20140520 18:32:10< gfgtdf> iceiceice_: hm  i just don't know how the compiler can optimise the static variable check aways if the same variable is shared betewwen different compilastio units, which i think the contructorcall map_location(0,0) can easily be optimised.
20140520 18:32:53< iceiceice_> gfgtdf: y but when i am compiling "action_wml.cpp" i can see the header map_location.hpp
20140520 18:33:05< Necrosporus> 1.11 says "error config: Multiple [unit_type]s with id=some_id encountered." but loads my addon without modifications nevertheless
20140520 18:33:11< iceiceice_> but not the .cpp file
20140520 18:33:30< iceiceice_> so action_wml compilation unit doesnt ever see "map_location(0,0)"
20140520 18:33:30< iceiceice_> thats only in the .cpp file
20140520 18:34:04< gfgtdf> iceiceice_: where is that in the .cpp file ?
20140520 18:34:28< iceiceice_> if you look before my commit
20140520 18:35:44< iceiceice_> i think when it says "class map_location { ... \\ map_location null_location; \\ }" thats just a declaration, not initialization
20140520 18:36:02-!- kex [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140520 18:36:04< gfgtdf> iceiceice_: ok i am more taklking about https://github.com/wesnoth/wesnoth/blob/master/src/map_location.hpp#L48 curretnyl
20140520 18:36:47< gfgtdf> iceiceice_: about we are better of with the 'static' + returning referecent or 'no static' + returning copy. 
20140520 18:36:48-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140520 18:37:13< iceiceice_> gfgtdf: before my commit heres the initialization of null_location, in map_location.cpp: https://github.com/wesnoth/wesnoth/blob/c73b5945d9946553386bc66b92c7021e6df3dc83/src/map_location.cpp#L48
20140520 18:38:07< iceiceice_> gfgtdf: im not sure if it matters as long as its in the header
20140520 18:38:19< iceiceice_> most likely it would get inlined i think?
20140520 18:38:33< iceiceice_> otherwise then yeah it makes a difference if its static or not, or reference vs value
20140520 18:38:36< gfgtdf> iceiceice_: even if it gets inlined teh bahaviourt pof teh code wont change
20140520 18:38:51< iceiceice_> y but it would be a lot faster
20140520 18:39:06< iceiceice_> it would mean that checking ml == map_location::null_location
20140520 18:39:10< gfgtdf> so it woudl still ahve to do teh 'is it already initiiased' check somhow even if iniled
20140520 18:39:16< iceiceice_> would become ml.x == ..., ml.y == ...
20140520 18:39:17-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 264 seconds]
20140520 18:40:34< iceiceice_> i think if the compiler can prove statically that map_location::ZERO().x = 0, map_location::ZERO().y =0 then it will replace those with constants
20140520 18:40:43< iceiceice_> and optimize away the static variable entirely
20140520 18:40:57< gfgtdf> iceiceice_: i dotn see how teh cimpler cha prove taht withotu seeign all teh cimliöation units
20140520 18:41:01-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140520 18:41:06< gfgtdf> can prove that without
20140520 18:41:08< iceiceice_> if its all in the header i think it can
20140520 18:41:14-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 255 seconds]
20140520 18:41:23< iceiceice_> when the variable is a local static variable in a function like that,
20140520 18:41:29< iceiceice_> it doesnt need to look at other compilation units to know
20140520 18:41:58< iceiceice_> it might not make a difference, maybe static const for the local var is the same as const
20140520 18:42:28< iceiceice_> it depends if , in the case that it doesnt inline, you would rather it reconstruct every time, or retrieve from memory
20140520 18:42:56< iceiceice_> maybe better to reconstruct idk, i guess you could change the static const variable to const
20140520 18:43:24< iceiceice_> at this point i really dont know enough to say what of those two is better, it hink the important thing is just that its in the header
20140520 18:43:31< gfgtdf> well some cppfiel coudl use const_cast<map_location>(map_location::ZERO()).x = 9
20140520 18:43:38< gfgtdf> we dont know
20140520 18:43:41-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: Ciao]
20140520 18:43:49< gfgtdf> without watching at all cppfiles
20140520 18:44:15< iceiceice_> hmmm
20140520 18:45:23< iceiceice_> yeah thats something i dont know about
20140520 18:45:37< iceiceice_> i guess i would hope that that's undefined behavior and the optimizer would assume that wouldnt happen
20140520 18:45:49< iceiceice_> but yeah maybe should make it a local const and not static
20140520 18:45:59< Necrosporus> gfgtdf, I tried to write minimalistic test case but the problem was not reproduced
20140520 18:46:26< Necrosporus> Also it doesn't always reproduces even with original code
20140520 18:46:47< gfgtdf> Necrosporus: do you use costim unit in your scenario ?
20140520 18:46:55< gfgtdf> custom*
20140520 18:46:58< Necrosporus> Yes
20140520 18:47:06< iceiceice_> gfgtdf: http://stackoverflow.com/questions/357600/is-const-cast-safe
20140520 18:47:26< Necrosporus> gfgtdf, a lot of with custom abilities
20140520 18:47:40< gfgtdf> iceiceice_: hm ok i didnt knew of thia
20140520 18:47:44< gfgtdf> this
20140520 18:48:12< Necrosporus> By the way thank to iceiceice, at least my custom ability works again ([hides] one)
20140520 18:48:15< iceiceice_> y idk, if it wasnt this way then i dont see how the compiler could make optimizations based on const
20140520 18:49:45< Necrosporus> Also in 1.11 there's still: error engine: failed to auto-store $this_unit at 
20140520 18:50:01< iceiceice_> hmm ok actually i do see, but still
20140520 18:50:15< Necrosporus> though it doesn't seem to affect the game other than spitting this message on console
20140520 18:50:18< gfgtdf> iceiceice_: how ?
20140520 18:50:26< iceiceice_> if its like what you were saying
20140520 18:50:30< iceiceice_> you have some locally scoped const 
20140520 18:50:30-!- lipkab [~the_new_l@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 276 seconds]
20140520 18:50:38< iceiceice_> then you can see that theres no way it will be const casted
20140520 18:51:03< iceiceice_> but anyways i guess it takes the stronger view, if it was defined const you can't const_cast it 
20140520 18:52:49< gfgtdf> Necrosporus: maybe bug can happen is you use $this_unit in a standard unit filter on a locatipon when there is no unit ?
20140520 18:53:36< shadowm> loonycyborg: If you post a patch I can test it myself (unless it's for the installer, in such case not really).
20140520 18:53:37< Necrosporus> gfgtdf, it's same hides' ability
20140520 18:54:00< Necrosporus> I use it only in [hides][filter]
20140520 18:54:58< gfgtdf> Necrosporus: nothign else than the ability bneeded t reprodice that bug ?
20140520 18:55:56< Necrosporus> gfgtdf, I have only one line with this_unit in my code
20140520 18:56:39< gfgtdf> Necrosporus: wel it is also possible that this bug onyl appears if you use this ability in a specialy event
20140520 18:57:09< Necrosporus> afair I never filter this ability in even
20140520 18:58:10-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140520 19:01:28< gfgtdf> Necrosporus: which version fo 1.11 do you use ?
20140520 19:01:31< gfgtdf> of*
20140520 19:01:44< Necrosporus> 13
20140520 19:02:45< gfgtdf> Necrosporus: i i can reproduce this error with 1.11
20140520 19:03:02-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140520 19:04:24-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140520 19:04:44< gfgtdf> Necrosporus:  looks liek a off by one erro to me
20140520 19:04:57-!- DDR [~david@ec2.happyspork.com] has quit [Quit: DDR is not Dance Dance Revolution]
20140520 19:04:57-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has quit [Quit: ZNC - http://znc.sourceforge.net]
20140520 19:05:57< gfgtdf> Necrosporus: no its something different
20140520 19:07:35< Necrosporus> So you reproduced it?
20140520 19:08:55< gfgtdf> Necrosporus: ye but my wesnoth needs a complete rebuild because teh file log.hpp was changes since my ast change
20140520 19:09:00< gfgtdf> compliation
20140520 19:09:37-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140520 19:09:56< lipkab> wesbot: seen mordante
20140520 19:09:56< wesbot> lipkab: The person with the nick mordante last spoke 1d 23h ago.  1d 23h ago was here and on the channel #wesnoth-de with the message: Quit: Leaving
20140520 19:16:48-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has joined #wesnoth-dev
20140520 19:16:48-!- crimson_penguin [~crimson_p@ec2.happyspork.com] has quit [Changing host]
20140520 19:16:48-!- crimson_penguin [~crimson_p@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20140520 19:16:51-!- DDR [~david@ec2.happyspork.com] has joined #wesnoth-dev
20140520 19:19:51< gfgtdf> Necrosporus: hm i thnk i knoqw the ereason why this happens
20140520 19:22:04< gfgtdf> Necrosporus: but i dont really know what that code does. It seems to be realtes to storing whether a unit is hidden in thewhiteboard.
20140520 19:22:32< Necrosporus> gfgtdf, my code or other?
20140520 19:22:54< gfgtdf> 	Necrosporus: the engine c++ code
20140520 19:23:04-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20140520 19:23:13< Necrosporus> That's great
20140520 19:24:09< Necrosporus> But what should I do if my minimalistic test scenario's replay is working fine?
20140520 19:25:59< gfgtdf> Necrosporus: did you create xour minimalistic case by stepwise removing tigns from your original scenario ?
20140520 19:26:37< gfgtdf> your
20140520 19:29:13< Necrosporus> nope, I tried to write it from scratch
20140520 19:32:15< gfgtdf> 	Necrosporus: maybe your minismlisitc case is just wrong and its seomthign else that causes your bug ?
20140520 19:32:29< Necrosporus> Possibly
20140520 19:33:50-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 258 seconds]
20140520 19:34:11-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140520 19:35:17-!- aquileia [2edf524c@gateway/web/freenode/ip.46.223.82.76] has joined #wesnoth-dev
20140520 19:38:01< aquileia> Ivanovic: I'm unfamiliar to the way libs are packaged on the Pandora... "there is no explicit boost-random lib available"
20140520 19:38:22< aquileia> do you mean a separate file or pnd?
20140520 19:39:46< aquileia> That is... would it help you if there was a full boost 1.51 library including libboost_random.[a,so] ?
20140520 19:54:50-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 255 seconds]
20140520 19:56:55-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has joined #wesnoth-dev
20140520 19:59:37-!- SigurdFD [~SigurdFD@24.154.98.89] has quit []
20140520 20:02:14-!- lipkab [~lipkab@host-91-147-212-189.biatv.hu] has quit [Ping timeout: 240 seconds]
20140520 20:04:51< irker448> wesnoth: Chris Beck wesnoth:master 3c9844889bab / src/ (109 files in 29 dirs): Make sure all error logs flush with std::endl, so we get on travis. http://git.io/u8Dq3Q
20140520 20:04:53< irker448> wesnoth: Chris Beck wesnoth:master 03a956d05ce0 / src/ (37 files in 14 dirs): Make sure all warning logs are flushed, so travis gets the results. http://git.io/-h948A
20140520 20:04:55< irker448> wesnoth: Chris Beck wesnoth:master f09d40562966 / src/ (46 files in 13 dirs): cleanup previous two find and replace results http://git.io/6InGJQ
20140520 20:09:01< Ivanovic> aquileia: the base OS does not come with this package
20140520 20:09:03< Ivanovic> meaning
20140520 20:09:04< iceiceice_> ok i think i am going to configure travis to require the unit tests to pass
20140520 20:09:05< iceiceice_> is that something i need to discuss on the list?
20140520 20:09:15< Ivanovic> i would have to build it myself and include it in the pnd of wesnoth
20140520 20:09:36< aquileia> including - yes. building, no
20140520 20:10:03< aquileia> http://repo.openpandora.org/?page=detail&app=codeblocks6022&p=3 has boost 1.51
20140520 20:10:18< aquileia> so you probably could grab it from there
20140520 20:11:09< aquileia> Just thought I'd mention it
20140520 20:11:39-!- Guest72616 is now known as cib1
20140520 20:11:59-!- spoffy [~spoffy@152.78.175.8] has joined #wesnoth-dev
20140520 20:13:02< Ivanovic> have you already extracted that PND to check if it really includes boost random?
20140520 20:13:04< aquileia> Ivanovic: And it includes sdl_mixer 1.2 as well, though I didn't look at the minor version number - perhaps that might help with another PR discussed in the ML. That one is just a random guess though
20140520 20:13:10< aquileia> Yes
20140520 20:13:26< aquileia> Icodeblocks.pnd\usr\lib\libboost_random.a\
20140520 20:14:51< aquileia> And it has a newer GCC version as well? But IIRC you cross-compile anyhow...
20140520 20:15:09< Ivanovic> yes, i crosscompile because compiling wesnoth on the pandora would be freaking slow
20140520 20:15:36< Ivanovic> 600mhz single core arm cpu
20140520 20:15:43< Ivanovic> with 512mb ram in the version i have
20140520 20:15:47< aquileia> Oh...
20140520 20:15:52< Ivanovic> building wesnoth would easily take like 5h
20140520 20:17:39< Ivanovic> which version of sdl is in the bundle?
20140520 20:17:48< Ivanovic> is there also libsdl2 prepackaged?
20140520 20:18:00< aquileia> It has both sdl2 and 1.2
20140520 20:18:27< aquileia> As I said I don't know the minor version number
20140520 20:18:44< aquileia> I'm on a different PC right now
20140520 20:19:00< Ivanovic> oookay
20140520 20:19:18< aquileia> There's a reason for that 1.3 GB
20140520 20:19:29< Ivanovic> if that is the case and if i can get the crosscompiler to use these libs and the resulting binaries will actually work i think i am good regarding "bump many versions of libs!!!"
20140520 20:19:45< aquileia> Hope I could help
20140520 20:20:06< aquileia> At least your internet connection isn't as bad as mine
20140520 20:20:12< Ivanovic> one day i will just try if they work as drop in replacement
20140520 20:20:52< Ivanovic> but probably later this week since right now i am tired and the weather forecast for the rest of the week sounds too promising to sit in front of the computer after sitting in front of the computer all working day
20140520 20:20:54< Ivanovic> ;)
20140520 20:21:20< aquileia> I know, I'm not too far from you
20140520 20:21:58< Ivanovic> :)
20140520 20:24:20< Ivanovic> running unsquashfs
20140520 20:27:32< Ivanovic> usr/lib/libSDL-1.2.so.0.11.3
20140520 20:27:40< Ivanovic> usr/lib/libSDL2-2.0.so.0.0.0
20140520 20:28:20< aquileia> may I ask about sdl_mixer?
20140520 20:28:21< iceiceice_> ok, i think i am just going to make travis builds contingent on the unit tests, and if it causes a problem for someone they can just revert 
20140520 20:28:32< iceiceice_> the travis change
20140520 20:28:46< Necrosporus> error replay: found init_side in replay while is_synced=true // wesnoth: wesnoth-1.11.13/src/synced_context.cpp:328: void set_scontext_synced::init(): ??????????? ??????????? <<synced_context::get_syced_state() == synced_context::UNSYNCED>> ?? ?????????.
20140520 20:28:48< Ivanovic> usr/lib/libSDL_mixer-1.2.so.0.12.0
20140520 20:28:54< iceiceice_> that doesnt seem like a big deal
20140520 20:28:59< Ivanovic> is there a way to get the real version number out of the lib file?
20140520 20:29:00< Necrosporus> Wesnoth seem to crash when trying to open replay from 1.10
20140520 20:29:11< iceiceice_> Necrosporus: yes. it is not compatible in the slightest
20140520 20:29:22< Necrosporus> but crash?
20140520 20:29:26< Ivanovic> since the plain filename is identical to the one in the pandora toolchain
20140520 20:29:27< aquileia> because mixer 1.2.12 is necessary for PR 155
20140520 20:29:48< iceiceice_> Necrosporus: y it should probably just throw game::game_error, but gfgtdf dropped asserts in some places
20140520 20:30:08< iceiceice_> its not that different, its not like a segfault
20140520 20:30:27< iceiceice_> idk are you getting segfault or assertion failure?
20140520 20:30:30< iceiceice_> i would expect assertion
20140520 20:31:40< aquileia> Ivanovic: sdl_mixer.h line 43
20140520 20:31:54< aquileia> Assuming that lib and header correspond
20140520 20:32:48< Ivanovic> if they correspond: 1.2.12
20140520 20:32:58< Necrosporus> iceiceice_, it says "Aborted"
20140520 20:33:08< Necrosporus> not a segmentation fault
20140520 20:33:18< iceiceice_> can you get a return code?
20140520 20:33:23< iceiceice_> what platform are you on
20140520 20:33:24< aquileia> \me dances a jig
20140520 20:33:31< Necrosporus> GNU/Linux
20140520 20:33:43< iceiceice_> i think you can like, echo $?
20140520 20:33:45< iceiceice_> after wesnoth has crashed
20140520 20:33:48< iceiceice_> and it will tell you a number
20140520 20:33:53< iceiceice_> thats what i do in my script
20140520 20:34:01< gfgtdf> Necrosporus: "src/synced_context.cpp:328 .." realy looks liek a  assertion failure, and i also know that there is an assert for "synced_context::get_syced_state() == synced_context::UNSYNCED"
20140520 20:34:22< Ivanovic> iceiceice_: but that is exactly the same version as in the old package
20140520 20:34:39< aquileia> AI0867: Pandora <i>might<\i> have SDL_mixer 1.2.12 !
20140520 20:35:12< Ivanovic> so for both the "normal" libsdl as well as sdl_mixer the version number itself is unchanged
20140520 20:35:13< gfgtdf> Necrosporus: you cannot load replays from older versions with 1.11.13+ you'll get OOS erros first and assertion falures after that
20140520 20:36:05< Ivanovic> but the lib files themselves differ, probably have been rebuilt
20140520 20:36:06< aquileia> Ivanovic: But the chance is there...
20140520 20:36:06< Necrosporus> 134
20140520 20:36:18< Necrosporus> Does it say anything?
20140520 20:36:38< gfgtdf> Necrosporus: even if you click ignore at the OOS messages and the assertion failures, it wont work
20140520 20:36:42< Ivanovic> at least the boost version is significantly updated
20140520 20:36:49< Ivanovic> what else was keeping us back so far?
20140520 20:37:17-!- thunderstruck [~zaibotren@cpc13-sgyl31-2-0-cust696.18-2.cable.virginm.net] has quit [Quit: leaving]
20140520 20:37:22< Necrosporus> gfgtdf, even saves won't work?
20140520 20:37:42< Necrosporus> 1.10 could load 1.8 saves
20140520 20:37:43< aquileia> Ivanovic: I don't know other than the two PRs
20140520 20:38:18-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140520 20:38:19< gfgtdf> Necrosporus: start-of-scenario saves will work, also you can laod 1.10 saved but the replays from 1.10 saves continued with 1.11.13+ will be corrupt
20140520 20:38:26< gfgtdf> saves
20140520 20:38:42< gfgtdf> Necrosporus: those replay cannot be watched with any version then
20140520 20:38:48< aquileia> AI0867: What was the name of that new function added in SDL_mixer 1.2.12?
20140520 20:40:02< irker448> wesnoth: Chris Beck wesnoth:master e89d94d5cdf0 / / (4 files): travis requires all unit tests to pass. also refactor run_wml_tests. http://git.io/oWr3gQ
20140520 20:41:16< iceiceice_> Necrosporus: 134 is the code for assertion failure
20140520 20:41:30< aquileia> Ivanovic: I think "nm sdl_mixer.a | grep Mix_LoadMUSType_RW" might work
20140520 20:42:14< aquileia> I learned about nm in a lesson today, so I'm not sure it'll work
20140520 20:42:36< aquileia> Mix_LoadMUSType_RW was added in 1.2.12
20140520 20:42:40< Ivanovic> that line is available in both
20140520 20:42:47< Ivanovic> just a different hex value
20140520 20:43:01< aquileia> AI0867, Ivanovic: Yay!
20140520 20:46:15< Ivanovic> off to bed, n8
20140520 20:46:48< aquileia> night
20140520 20:49:15< aquileia> iceiceice_: The boost_random issue on Pandora <i>could<\i> be resolved...
20140520 20:49:26< iceiceice_> y i am following :)
20140520 20:50:23< iceiceice_> i wonder if pandora has a boost random_device
20140520 20:50:41< aquileia> yes
20140520 20:50:47< iceiceice_> really?
20140520 20:50:55< iceiceice_> thats kind of surprising to me actually
20140520 20:50:57< iceiceice_> good job pandora
20140520 20:51:32< aquileia> When I opened codeblocks.pnd\usr\lib\libboost_random.a\ it included two files, and one of them was random_device IIRC
20140520 20:56:43-!- RiftWalk1r [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Ping timeout: 252 seconds]
20140520 20:58:43-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140520 20:59:00< iceiceice_> hmm well thats all very convenient
20140520 20:59:13< iceiceice_> i guess i'll leave the compiler flags for no boost random device in there but strictly we probably dont need htem
20140520 20:59:23< iceiceice_> assuming htis all works out
20140520 21:03:53< iceiceice_> gfgtdf: maybe we should do something about bug #21906
20140520 21:04:13< iceiceice_> wesbot: bug #21906
20140520 21:04:13< wesbot> Bug #21906  Assigned to: None  Status: None  Priority: 5 - Normal
20140520 21:04:13< wesbot> Summary: replays can change global variables
20140520 21:04:13< wesbot> Original submission: we currently check for beeing in a replay in set_global_v
20140520 21:04:16< wesbot> ariable with 'if (get_replay_source().at_end() || (network::nconnections() != 0)
20140520 21:04:19< wesbot> URL: http://gna.org/bugs/?21906
20140520 21:05:05< iceiceice_> it basically means global variables are not replay safe, right?
20140520 21:06:06< gfgtdf> iceiceice_: well  consider the (get_replay_source().at_end() || (network::nconnections() != 0) qiuet hacky anyway, althought i dont like it eigher i'd use a (dynamic_cast<replay_controller>(resource::controller) == NULL)
20140520 21:07:52< iceiceice_> so its also an oos vector though right?
20140520 21:08:03< iceiceice_> if a scenario reads a global variable at the beginning, and canges it later
20140520 21:08:03< iceiceice_> then the replay will be corrupted
20140520 21:08:33< iceiceice_> unless im mistaken
20140520 21:08:48< gfgtdf> iceiceice_: hm no: replays never read global_variables, 
20140520 21:09:10< iceiceice_> they are cached at start of scenario?
20140520 21:09:33< gfgtdf> it liek teh ghame automaticly wrapps get_global_variable inside a synconize_choice
20140520 21:09:36< gfgtdf> like the
20140520 21:09:41< gfgtdf> it's
20140520 21:09:44< iceiceice_> oh
20140520 21:09:45< iceiceice_> thats goo
20140520 21:09:46< iceiceice_> d
20140520 21:11:55< iceiceice_> i guess alternative is to make "set_global_variable_helper" a virtual member of play_controller
20140520 21:12:09< iceiceice_> sort of the same though
20140520 21:12:34< gfgtdf> iceiceice_: ye usually citual function calls are better than dynamic_cast<>.
20140520 21:12:37< gfgtdf> virtual
20140520 21:21:10< gfgtdf> iceiceice_: hm i personly don't consider this bug that important, but it shouldnt be that hard to fix anyway especialy if we already have 2 (similar) solutions.
20140520 21:21:34< iceiceice_> y idk
20140520 21:21:52< iceiceice_> i guess the other thing to do is try to play through LoW fully, perhaps without debug mode but using a cheat patch
20140520 21:22:32< iceiceice_> if that works we probably dont have many bugs left
20140520 21:23:01< iceiceice_> i guess i also found some bugs when i tried to run my looping test scenario
20140520 21:23:04< iceiceice_> i havent tried that in a while
20140520 21:23:32< iceiceice_> i have to run,
20140520 21:23:51< iceiceice_> btw gfgtdf, if you didnt see in the logs earlier, i have set up travis to require the C++ and WML unit tests to pass for hte build to be considered a success
20140520 21:24:34-!- iceiceice_ [~chris@207-237-132-91.ny.subnet.cable.rcn.com] has quit [Quit: Leaving]
20140520 21:25:52-!- gfgtdf_ [~chatzilla@e177122054.adsl.alicedsl.de] has joined #wesnoth-dev
20140520 21:28:43-!- gfgtdf [~chatzilla@e176189249.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20140520 21:28:47-!- gfgtdf_ is now known as gfgtdf
20140520 21:29:36-!- cib1 [~cib@p5DD22404.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
20140520 21:43:02-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Ping timeout: 255 seconds]
20140520 21:44:39-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140520 21:45:40< aquileia> noy: Would you have time to discuss khalifate history?
20140520 21:45:48< noy> at work unfortunately
20140520 21:45:50< noy> sorry
20140520 21:45:58< aquileia> no problem
20140520 21:46:15< aquileia> just wanted to ask
20140520 21:46:39-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 240 seconds]
20140520 21:47:37-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20140520 22:11:31-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Ping timeout: 252 seconds]
20140520 22:13:14-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has joined #wesnoth-dev
20140520 22:15:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds]
20140520 22:25:26-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20140520 23:03:30-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20140520 23:12:47-!- aquileia [2edf524c@gateway/web/freenode/ip.46.223.82.76] has quit [Quit: Page closed]
20140520 23:13:25-!- mjs-de [~mjs-de@f049171204.adsl.alicedsl.de] has quit [Remote host closed the connection]
20140520 23:16:15-!- kex [~kex@78.157.29.205] has joined #wesnoth-dev
20140520 23:28:39-!- gfgtdf [~chatzilla@e177122054.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds]
20140520 23:43:20-!- RiftWalker [~nathan@ip24-252-126-205.no.no.cox.net] has quit [Remote host closed the connection]
--- Log closed Wed May 21 00:00:43 2014