--- Log opened Wed Jun 03 00:00:01 2015
20150603 00:01:01< vultraz> so it looks like gfgtdf was  right, share_view = no is needed to be added to the test
20150603 00:03:18< vultraz> shadowm: can you run it with share_view=no
20150603 00:03:25< shadowm> Where do I put that?
20150603 00:03:46< shadowm> There are four sides.
20150603 00:04:01< vultraz> ummm
20150603 00:04:04< vultraz> try all 4
20150603 00:04:07< shadowm> And two teams, 1,4 and 2,3.
20150603 00:04:24< matthiaskrgr> for the record: link-time optimized build (-flto) is only 17 M big (wesnoth binary)
20150603 00:04:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20150603 00:04:47< matthiaskrgr> gn 
20150603 00:05:07< shadowm> Also, why do we need to change the test? The purpose of the tests is to ensure we don't change existing behavior without a good reason.
20150603 00:05:40< shadowm> It passes with all four sides having share_view=no set.
20150603 00:06:30< vultraz> Ok
20150603 00:06:34< vultraz> Good
20150603 00:08:13< vultraz> I'm actually not sure why it passed before....
20150603 00:09:04< shadowm> There are two possibilities: 1) the test was based on incorrect master-specific behavior, or 2) the new behavior is different from 1.12.
20150603 00:09:34< shadowm> Since I'm not the one writing the PR, I'd assume (2) by default. ;)
20150603 00:10:26< gfgtdf> shadowm: it is 2). the pr makes share_view true by default
20150603 00:11:00< shadowm> Is this good or bad?
20150603 00:11:22< vultraz> I would say good, since it'd be consistent with mp
20150603 00:11:28< vultraz> and you expect it to be true
20150603 00:11:30< vultraz> I guess?
20150603 00:11:33< shadowm> Except I think we usually assume share_view=no in SP.
20150603 00:11:47< shadowm> For example, in HttT's Plunging into the Darkness or whatever its name was scenario.
20150603 00:11:57< shadowm> As well as the scenario immediately following that.
20150603 00:12:27< shadowm> Is the MP case just for player-configured sides or all sides?
20150603 00:12:29< gfgtdf> shadowm: in sp fog and shoud are usually false by default and shre_vision should have any effect in this case
20150603 00:12:45< shadowm> The scenarios I mentioned have shroud=true for side 1.
20150603 00:12:46< gfgtdf> in case they are true*
20150603 00:12:57< gfgtdf> shadowm: yes but not for teh ai sides
20150603 00:13:02< gfgtdf> or maybe yes
20150603 00:13:04< gfgtdf> idk
20150603 00:13:16< shadowm> No, not for the AI sides since AI IIRC ignores shroud so it's useless.
20150603 00:13:37< shadowm> Except when the AI side is meant to share its shroud map with a human player.
20150603 00:14:06< shadowm> In the general case, it isn't, so the player is supposed to have its own independent shroud map.
20150603 00:14:21-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 00:14:51< gfgtdf> shadowm: yes that still teh case by default becasue ai sides have fog/shoud= no by default
20150603 00:14:52-!- Appleman1234 [~Appleman1@s108.BMT-e1.vectant.ne.jp] has quit [Read error: Connection reset by peer]
20150603 00:15:10< gfgtdf> shadowm: share_view shares this sides view with allied sides if this side has fog/shoud active
20150603 00:15:12< vultraz> shadowm: allied sides without shroud or fog will not share vision
20150603 00:15:18< shadowm> So what happens if share_view=yes for side 1 with shroud and an allied AI with no shroud?
20150603 00:16:17< shadowm> vultraz: And that's the intended behavior, right?
20150603 00:16:27< gfgtdf> shadowm: share_view=yes copied this sides shroud to the other sides.
20150603 00:16:45< vultraz> no allied vision because you're "sharing" with yourself
20150603 00:16:54< vultraz> vision of allies*
20150603 00:16:57< vultraz> what gfgtdf said
20150603 00:17:02< gfgtdf> cleaned shourd*
20150603 00:17:08< shadowm> Okay, I just checked both of the scenarios in question on a PR build and nothing seems to have changed since 1.12.
20150603 00:17:45< shadowm> What does appear to have changed is AtS E2S1.
20150603 00:18:17< shadowm> The initial side 2 units are no longer covered in fog.
20150603 00:19:06< vultraz> Bu the Moonlight?
20150603 00:19:09< vultraz> by*
20150603 00:19:14< shadowm> Yes.
20150603 00:19:35< shadowm> The WML initially sets shroud,fog=yes,yes for both sides, share_maps/share_view are not specified.
20150603 00:21:50< vultraz> Hmmm
20150603 00:22:15< vultraz> Yeah you'll now need to either remove that from the town side, or add share_view=no
20150603 00:22:55< gfgtdf> shadowm: what is the intended behaviour for having fog/shoud n those sides ?
20150603 00:22:58< shadowm> So the question here is whether it's really worth complicating things for authors on 1.12 with this change.
20150603 00:24:01< gfgtdf> shadowm: does it have an effect without share_view=no (default)?
20150603 00:24:38< shadowm> I'm not sure how to check that, should I add share_view=yes somewhere?
20150603 00:24:58-!- ancientcc [~ancientcc@114.111.166.47] has quit [Remote host closed the connection]
20150603 00:25:11< vultraz> the sp/mp thing already screwed with this, I think
20150603 00:25:17< gfgtdf> shadowm: no the question was why those sides has fog/shoud=yes in your scenario
20150603 00:25:37< shadowm> vultraz: But the SP/MP thing isn't in 1.12, and ultimately the reference point should be 1.12 and not 1.13.0.
20150603 00:25:43< vultraz> when I first reported the bug, it was that allied sides could not be shrouded UNLESS they had shroud=yes. thankfully that got fixed along the way somewhere
20150603 00:26:26< vultraz> honestly, I think merging these keys makes sense
20150603 00:26:31< shadowm> gfgtdf: The scenario is set up so that side 1 starts in a corner of the map with shroud and fog enabled, so it can't see anything other than a small fogged (but not shrouded) patch where two units controlled by side 2 stand.
20150603 00:26:39< vultraz> or at least, simplifies things
20150603 00:26:50< shadowm> Side 2 is initially controller=null, so it can't move or alter its own fog/shroud map.
20150603 00:27:35< gfgtdf> shadowm: so you ctualy use rteh share_maps = true, share_view= false behaviour.
20150603 00:27:48< shadowm> If that's the default in 1.12, yes.
20150603 00:28:05< gfgtdf> shadowm: which is basicly the behaviour which this pr removes.
20150603 00:29:09< gfgtdf> vultraz: hm if there is a usecase for this behaviour i think we should maybe not merge them.
20150603 00:29:32< gfgtdf> i still think having share_view= yes in sp by default is good idea
20150603 00:29:38< vultraz> :/
20150603 00:30:29< shadowm> By all means, what I do here can be replicated with remove_shroud and radial SLFs if it comes to that.
20150603 00:30:38< vultraz> but without this patch, people will need to set BOTH keys to no in order to place shroud over hexes visible by shrouded allied 
20150603 00:30:41< shadowm> However, I'm just one UMC author.
20150603 00:31:29< vultraz> ally*
20150603 00:31:30< shadowm> That's why I referred you to zookeeper before, since he usually understands better how to keep things simple without introducing disruptive changes.
20150603 00:31:56< gfgtdf> vultraz: hm we can have share_view=true, share_maps=false by default, do you'd just have to set share_view=false, so you'd just have to set share_view=no in this case
20150603 00:32:37< vultraz> hm
20150603 00:33:54< vultraz> but don't we want to share maps (shroud) by default?
20150603 00:35:49< vultraz> doesn't 1.12 share allied vision by default?
20150603 00:37:54< vultraz> ok yes
20150603 00:38:00< vultraz> 1.12 has the equivalent of share_maps=yes
20150603 00:38:03< gfgtdf> vultraz: I persoanlly woudl sy that we only want share_maps=yes in some rare cases (wasnt that why you pr actualyl remove this case). But i also didnt write that many scenario to to say.
20150603 00:38:18< gfgtdf> s/case/case?
20150603 00:38:26< vultraz> gfgtdf: your pr would completely switch things around from 1.12
20150603 00:38:28< vultraz> er
20150603 00:38:29< vultraz> proposal
20150603 00:38:31< vultraz> not pr
20150603 00:40:06< vultraz> and im pretty sure that was the default before my patch too
20150603 00:40:40< gfgtdf> vultraz: yes i know but i also think its good to be consistent with mp.
20150603 00:40:51< vultraz> yes
20150603 00:40:58< vultraz> and you said it's always yes in mp
20150603 00:41:10< gfgtdf> vultraz: it by default ye sin mp
20150603 00:41:31< gfgtdf> vultraz: i orignally thought it was always yes in mp but it just the default
20150603 00:41:43< gfgtdf> vultraz: (thats the line in connect engine)
20150603 00:42:53< gfgtdf> vultraz: the current (1.12) behavviour where they  are different in sp and mp means for example that campaigns like LoW which are playable in sp and mp have to specify it anyway becasue they have no reliable default value.
20150603 00:44:14< vultraz> we should give a reliable default then
20150603 00:44:38< vultraz> ok so the 1.12 default is share_view=no, share_maps=yes
20150603 00:44:43-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20150603 00:45:33< gfgtdf> vultraz: yes
20150603 00:45:42< gfgtdf> vultraz: but in mp this default makes no sense
20150603 00:45:59< vultraz> right
20150603 00:46:05< vultraz> in mp the default SHOULD be both yes
20150603 00:46:15< shadowm> The problem is that SP and MP have different needs, so you'll never come up with a default configuration that's fully adequate for both.
20150603 00:46:44< vultraz> so what should we do here
20150603 00:46:50< shadowm> That's pretty much why I've been skeptical about making SP content run in MP since 1.13.x.
20150603 00:46:54< shadowm> I mean 1.3.x.
20150603 00:46:54< gfgtdf> shadowm: yes but in this case is dont see why share_view=yes by defautl ais bad thing
20150603 00:47:27< gfgtdf> shadowm: in sp it wont have an effect in most cases anyway since you usually use fog/shroud = no for ai sides
20150603 00:48:01< shadowm> It's not a bad thing, it's just a change people need to be fully aware of.
20150603 00:49:32< vultraz> So should we merge?
20150603 00:49:32< shadowm> And whoever does the change should also go over every potentially affected mainline scenario and patch it in the process rather than wait for the bug reports to (never) come.
20150603 00:49:48< vultraz> yeah I was gonna look for cases 
20150603 00:50:24< shadowm> So, no, you shouldn't merge because AFAIU the PR removes one of the attributes.
20150603 00:50:40< vultraz> yes
20150603 00:50:55< shadowm> Which will result in loss of functionality.
20150603 00:51:13< vultraz> no, because view handles both now
20150603 00:51:30< shadowm> Then what if someone wants to share one but not the other?
20150603 00:52:02< shadowm> Which would be the AtS E2S1 case.
20150603 00:52:53< vultraz> Well, we just wouldn't support that anymore
20150603 00:53:44< shadowm> Then yes, it will result in loss of functionality.
20150603 00:53:47< vultraz> Which..may be a bad thing since that's the 1.12 default
20150603 00:54:25< shadowm> I already said that's but one use case. I can't possibly fathom more complicated use cases that may exist in other UMC.
20150603 00:56:58< vultraz> so we should keep both keys
20150603 00:57:41< shadowm> That's my gut feeling, yes.
20150603 00:58:00-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 00:58:03< vultraz> Alright
20150603 00:58:14< vultraz> so we come back to the problem of what to do with the bloody defaults in 1.13
20150603 00:59:00< shadowm> We're supposed to strive for a clean and family-friendly environment, so I'd prefer them to not have any blood if possible.
20150603 00:59:10< shadowm> :p
20150603 00:59:15< vultraz> *facepalm*
20150603 01:00:15< vultraz> so as far as I can tell, even before my patch share_view is initialized as true because of the sp/mp thing
20150603 01:00:20< vultraz> and then overrides share_maps
20150603 01:00:22< vultraz> for some damn reason
20150603 01:00:37< vultraz> meaning share_maps cannot be no without share_view also being no
20150603 01:01:12< vultraz> but since it's set in the connect engine, that would mean changing it back to a default of no would mean that in mp too
20150603 01:01:14< vultraz> you see?
20150603 01:01:17< vultraz> so what do we do here
20150603 01:02:35-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 250 seconds]
20150603 01:03:24< vultraz> the other option is to make it so share_maps no longer relies on the vlue of share_view
20150603 01:04:34< vultraz> ie, fixing share_maps = !share_view && cfg["share_maps"].to_bool(true); and info_.share_maps = !info_.share_view && share_maps;
20150603 01:04:48< vultraz> shadowm, gfgtdf: which do you prefer
20150603 01:05:58< gfgtdf> vultraz: i still prever swicth defaltults to match mp. And rmeove teh "delayed share maps" thing
20150603 01:06:48< vultraz> so, make maps no longer rely on the value of view?
20150603 01:08:43< gfgtdf> vultraz: it sshould rely on the value of view.
20150603 01:09:04< gfgtdf> vultraz:  teh borblem is that we have 3 staes but 2 boolean variables which gives 4 states
20150603 01:09:15< vultraz> yes
20150603 01:09:28< vultraz> and it's annoying yo set two values just to shroud allied sides!
20150603 01:09:29< vultraz> ugh
20150603 01:09:35< gfgtdf> vultraz: teh current code is made to enure share_view=true, share_maps=true, behaves teh same as share_view=true,share_maps=no
20150603 01:10:01< vultraz> that makes sense
20150603 01:10:06< vultraz> that case is useless
20150603 01:13:34-!- gfgtdf_ [~chatzilla@f054163236.adsl.alicedsl.de] has joined #wesnoth-dev
20150603 01:14:53< shadowm> I forgot how to reproduce the mixer crash bug.
20150603 01:15:06< vultraz> gfgtdf, so as far as i can tell, yes yes is the default for 1.13
20150603 01:15:15< vultraz> gfgtdf, do you agree with that
20150603 01:15:19< gfgtdf_> vultraz: yes
20150603 01:15:28< vultraz> and that is the same as mp
20150603 01:15:45< gfgtdf_> vultraz: team.cpp sets teh share_maps default to yes and connect_engine.cpp sets teh sare_view default to yes
20150603 01:15:47-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has joined #wesnoth-dev
20150603 01:15:54< vultraz> ok
20150603 01:15:56< gfgtdf_> vultraz: yes, but for unit test share_vire is by default false
20150603 01:15:59< shadowm> Hi ancestral.
20150603 01:16:06< gfgtdf_> vultraz: becasue unti test dont run though connect engin
20150603 01:16:10< ancestral> Hi
20150603 01:16:15< ancestral> Did I need to test something else?
20150603 01:16:16< vultraz> so
20150603 01:16:27< shadowm> ancestral: Yes but first test that.
20150603 01:16:28< vultraz> IMO both values should be set in the same place
20150603 01:16:29-!- gfgtdf [~chatzilla@f054155064.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds]
20150603 01:16:31< vultraz> is that possible
20150603 01:16:44-!- gfgtdf_ is now known as gfgtdf
20150603 01:16:57< shadowm> I still have a patch you agreed to test several weeks ago but never did.
20150603 01:18:01< shadowm> What the.
20150603 01:18:47< gfgtdf> vultraz: we coudl move teh true default from connect_engine to team.cpp
20150603 01:19:02< vultraz> ok
20150603 01:19:29< shadowm> /home/shadowm/src/wesnoth/src/server/simple_wml.cpp:189:30: runtime error: null pointer passed as argument 2, which is declared to never be null
20150603 01:19:41< vultraz> gfgtdf: wouldn't it make more sense to make the check share_view = !share_maps && share_view?
20150603 01:19:51< shadowm> There is no way that can be true.
20150603 01:21:05< gfgtdf> shadowm: why can that never be true ?
20150603 01:21:26< shadowm> Are these messages 0-based or not?
20150603 01:21:42< shadowm> I'm confused because it says column 30 but argument 2.
20150603 01:21:55< shadowm> At column 30 I have argument 3.
20150603 01:22:10< shadowm> If the actual argument 2 to memcpy was NULL this would crash immediately.
20150603 01:23:15< vultraz> gfgtdf: bc then with view=yes maps=no... wait wouldn't that make view still yes?
20150603 01:23:16< vultraz> or would itb e no
20150603 01:23:41< gfgtdf> vultraz: no i think teh current code is better.
20150603 01:23:51< gfgtdf> vultraz: you code makes both to yes act strangeley
20150603 01:24:06< ancestral> shadowm: I’ll try to test your patch later tonight, worst case tomorrow night
20150603 01:24:08< vultraz> ok
20150603 01:24:16< ancestral> On my way out very soon
20150603 01:24:31< shadowm> ancestral: Hmph. Okay.
20150603 01:24:39< vultraz> gfgtdf: so we basically agree that for 1.12, an additional share_view=no is necessary to disable share_maps
20150603 01:24:41< vultraz> er
20150603 01:24:45< vultraz> gfgtdf: 1.13
20150603 01:25:02< vultraz> and say that umc users must now specify both keys if they want maps= no?
20150603 01:25:18< gfgtdf> vultraz: we can make maps=no by default
20150603 01:25:30< gfgtdf> make*
20150603 01:25:33-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 01:26:02< shadowm> By the way, if there's a combination of maps/view that doesn't work then maybe warn in stderr?
20150603 01:26:38< shadowm> As well as the wiki, if it's not the case already.
20150603 01:27:36< gfgtdf> shadowm: hm accorign to the code share_view mans "share_ fog and shroud" and share_maps means "share shroud". So what the code doesnt liek is both beeing yes.
20150603 01:27:43-!- ancientcc [~ancientcc@114.111.166.47] has quit [Remote host closed the connection]
20150603 01:27:45< gfgtdf> shadowm: which falls back to share_maps beeing fasle
20150603 01:28:08< gfgtdf> shadowm: i tink this is rather strange form from eth user perspective
20150603 01:28:17< shadowm> There's a much better way to put it.
20150603 01:28:18-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 01:28:31< shadowm> "share_view's value overrides share_maps if specified".
20150603 01:29:00< gfgtdf> shadowm: no thas not the case, if share_view= fasle it does not overrride share_maps
20150603 01:29:44< shadowm> ¬_¬
20150603 01:30:16< vultraz> JHAGSDGHDHUIHDUIWHUIDFHUIEHFUIHF
20150603 01:30:20< vultraz> CAN WE JUST DECIDE ON SOMETHING
20150603 01:30:27< vultraz> a SENSIBLE default
20150603 01:30:33< gfgtdf> shadowm: i think cleaner would ba a single member like share=all/maps/none
20150603 01:30:35< vultraz> on who overrides whom
20150603 01:30:40< shadowm> I need a functional brain to investigate the stack corruption bug, so if you'll excuse me.
20150603 01:30:50< vultraz> because this is turning MY brain to jelly
20150603 01:31:37< shadowm> I'm not really opposed to deprecating this nonsense for 1.14 and removing it in 1.16, replacing it with a single tristate option.
20150603 01:31:54< vultraz> gfgtdf: if you turn share_maps tono then it's a full 180 from 1.12
20150603 01:31:56< vultraz> to no*
20150603 01:32:04< vultraz> so maybe we should just go with a tristate option 
20150603 01:32:46-!- ancientcc [~ancientcc@114.111.166.47] has quit [Remote host closed the connection]
20150603 01:33:18-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150603 01:34:15< gfgtdf> vultraz: maybe we coudl make teh tristate option share_view=yes/no/only_shroud.
20150603 01:35:02< shadowm> Just 'shroud' would suffice IMO.
20150603 01:35:16< gfgtdf> vultraz: I think the cases where this would break current scenarios are rare.
20150603 01:35:18-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150603 01:35:24< shadowm> But keeping the same attribute makes it harder to do the wmllint check.
20150603 01:35:24< vultraz> why not
20150603 01:35:35< vultraz> share_vision=fog/shroud/none
20150603 01:35:48-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150603 01:36:38< gfgtdf> vultraz: using share_view=ys/no/shroud woudl be more compatible with current wml
20150603 01:37:06< shadowm> Oh also, I forgot one thing.
20150603 01:37:48< vultraz> gfgtdf: why yes/no?
20150603 01:37:50< shadowm> From now on, I'd prefer if WML features were removed *only* after being deprecated for a stable series.
20150603 01:38:06-!- ancientcc [~ancientcc@61.164.211.210] has quit [Remote host closed the connection]
20150603 01:38:18-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20150603 01:40:47-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 01:42:55-!- ancientcc [~ancientcc@114.111.166.47] has quit [Client Quit]
20150603 01:44:38-!- gfgtdf_ [~chatzilla@f054163236.adsl.alicedsl.de] has joined #wesnoth-dev
20150603 01:45:27< gfgtdf_> hm so you want a period where we support both?
20150603 01:45:49< shadowm> If it's not too much trouble, yes.
20150603 01:46:29< shadowm> ==24786== Conditional jump or move depends on uninitialised value(s)
20150603 01:46:29< shadowm> ==24786==    at 0x11FE431: (anonymous namespace)::get_hotkey(int, int, int, int, int, bool, bool, bool, bool) (hotkey_item.cpp:51)
20150603 01:46:34< shadowm> Hm.
20150603 01:48:50-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 01:48:52< gfgtdf_> shadowm: dont you inspect a server error?
20150603 01:49:20< shadowm> ==24786== Use of uninitialised value of size 8
20150603 01:49:22< shadowm> ==24786==    at 0xF825C13: ogg_page_serialno (in /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2)
20150603 01:50:15< shadowm> No, I'm investigating the mixer segfault.
20150603 01:50:38-!- ancientcc [~ancientcc@114.111.166.47] has quit [Read error: Connection reset by peer]
20150603 01:51:13< shadowm> Unfortunately I still don't know how to get it to happen deterministically and I can't reproduce on 1.13.0+dev right now for some reason.
20150603 01:51:58< gfgtdf_> shadowm: is there a bugreport aboutmixer error?
20150603 01:52:24< shadowm> Yes, multiple.
20150603 01:52:52< gfgtdf_> shadowm: thats the crash when sound enabled error?
20150603 01:53:09< shadowm> #23599, #23026, #23203.
20150603 01:53:58< shadowm> Also http://forums.wesnoth.org/viewtopic.php?f=4&t=42429 and Debian #780853.
20150603 01:54:32< gfgtdf_> shadowm: so you are debugging the sdl code or libogg code?
20150603 01:54:33< shadowm> Also AtS commit 2b3469fa44f7f0703c98ac4c12fdce24073cafbe.
20150603 01:54:34-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 01:54:50-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150603 01:55:09< shadowm> I'm debugging neither yet, I'm first retracing the steps that led me to AtS 2b3469fa44f7f0703c98ac4c12fdce24073cafbe before deciding where to go from there.
20150603 01:55:37-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 01:55:42< shadowm> More specifically, which libraries and versions I'm going to have to build and test.
20150603 01:56:22< shadowm> It's really weird that the lobby must be involved in the sequence of events leading up to the invalid read.
20150603 01:56:45< shadowm> You'd figure just switching music on and off repeatedly would be a good trigger.
20150603 01:58:20< shadowm> And it seems to only really happen with optimized builds.
20150603 01:58:42< shadowm> With a debug build I get no crash and valgrind only sees the uninit value, but...
20150603 01:59:33< shadowm> ==30496== Invalid read of size 1
20150603 01:59:33< shadowm> ==30496==    at 0xF825C13: ogg_page_serialno (in /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2)
20150603 01:59:42< shadowm> A release build winds up hitting this.
20150603 01:59:51-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150603 01:59:58< shadowm> It could be a timing-based bug.
20150603 02:00:23-!- ancientcc [~ancientcc@118.187.21.44] has joined #wesnoth-dev
20150603 02:00:26< shadowm> Or we might be trampling over SDL_mixer/libvorbisfile/libogg's state at some point.
20150603 02:00:41-!- ancientcc [~ancientcc@118.187.21.44] has quit [Remote host closed the connection]
20150603 02:02:02< shadowm> I'm going to try the -fsanitizer options.
20150603 02:02:21-!- ancientcc [~ancientcc@118.187.21.44] has joined #wesnoth-dev
20150603 02:03:25< vultraz> I'm gonna have to learn how 2 enum
20150603 02:03:59< gfgtdf_> vultraz: what you want to do ?
20150603 02:04:53< vultraz> im thinking how to implement share_vision  as a tristate
20150603 02:05:07< gfgtdf_> vultraz: you can use MAKE_ENUM macro
20150603 02:05:24< gfgtdf_> vultraz: thats also used for controller in team.hpp
20150603 02:07:17-!- ancientcc [~ancientcc@118.187.21.44] has quit [Quit: Leaving]
20150603 02:07:49-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 02:10:10< shadowm> enum ENUM_TYPE_NAME { ENUM_MEMBER1, ENUM_MEMBER2, ENUM_MEMBER3 };
20150603 02:10:20< shadowm> ENUM_TYPE_NAME foo = ENUM_MEMBER1;
20150603 02:10:25< shadowm> It's not that hard.
20150603 02:11:47< gfgtdf_> shadowm: but make enum generates string to enum convertion functions which are useful when reading from config.
20150603 02:13:48< shadowm> I'm not familiarized with it because it was introduced like last year or so.
20150603 02:14:28< shadowm> To my knowledge nobody has tried to make it a convention to use that either.
20150603 02:15:27< gfgtdf_> shadowm: what you mean ?
20150603 02:15:34-!- irker604 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150603 02:15:57< shadowm> That it's still fairly non-standard.
20150603 02:16:35< gfgtdf_> shadowm: well enums that dont get written todiskdont have to use that
20150603 02:17:30< shadowm> What I mean is that there's plenty of code that needs to (de)serialize enum values that predates the introduction of that macro.
20150603 02:18:12< vultraz> gfgtdf_: so what's the values we wanted again? 
20150603 02:18:14< vultraz> yes/no/both?
20150603 02:18:34< gfgtdf_> vultraz: accoring to  shadowm the new plan is o ae differnt key 
20150603 02:18:49< vultraz> yeah but what values should it have
20150603 02:19:04< shadowm> I didn't specify a plan for you to follow.
20150603 02:19:06< gfgtdf_> vultraz: so hm maybe none/shroud/all
20150603 02:19:27< gfgtdf_> vultraz: idk
20150603 02:19:31< shadowm> That's ultimately your decision and not mine. I'm just a user as far as this feature is concerned.
20150603 02:19:50< vultraz> so... none is basically no,no, all is yes yes, and shroud would be... no yes 
20150603 02:21:12-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150603 02:24:18-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 02:24:24-!- gfgtdf_ [~chatzilla@f054163236.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.1/20150513174244]]
20150603 02:28:35-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150603 02:30:06-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 02:30:56< shadowm> I just find it hard to believe libvorbisfile or libogg could be at fault since they are used by. So. Much. Stuff.
20150603 02:31:26< shadowm> SDL_mixer, though? My opinion of upstream isn't very positive right now.
20150603 02:32:26< shadowm> Also, `-fsanitize=address,undefined -g3 -fno-omit-frame-pointer -O3` takes forever.
20150603 02:34:00< shadowm> Hm, also it does happen on 1.13.0+dev, I guess I was just unlucky earlier.
20150603 02:35:58< shadowm> Or.. I was using the -O0 build, that must be it.
20150603 02:36:09< shadowm> So many builds I'm losing track.
20150603 02:39:06< shadowm> ==29979==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000000f (pc 0x7fae5d1d3c13 bp 0x000000001130 sp 0x7ffdb1d87438 T0) #0 0x7fae5d1d3c12 in ogg_page_serialno (/usr/lib/x86_64-linux-gnu/libogg.so.0+0x1c12)
20150603 02:39:24< shadowm> Nothing I didn't already know, really.
20150603 02:40:36< shadowm> Alright, I'll compile my own SDL_mixer, libogg and libvorbisfile with full debug symbols.
20150603 02:46:13-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 02:47:40< shadowm> Okay.
20150603 02:48:13< shadowm> I'd prefer if gdb showed me full paths, hm.
20150603 02:48:56< shadowm> k, much better.
20150603 02:51:29-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 265 seconds]
20150603 02:52:11< shadowm> The faulty structure is instantiated in vorbisfile land from stack.
20150603 02:52:17-!- ancientcc [~ancientcc@114.111.166.47] has quit [Quit: Leaving]
20150603 02:52:52-!- c74d3 is now known as c74d
20150603 02:53:19< shadowm> (gdb) p vf->os->header
20150603 02:53:19< shadowm> $8 = '\000' <repeats 281 times>
20150603 02:53:26< shadowm> Hm.
20150603 02:54:45-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 02:55:22-!- ancientcc [~ancientcc@114.111.166.47] has quit [Remote host closed the connection]
20150603 02:56:51< shadowm> Probably unrelated.
20150603 02:59:02< shadowm> data/game_config.cfg:27:    lobby_music="silence.ogg"
20150603 02:59:18< shadowm> In the AtS case I concluded that the solution was to use a larger silence.ogg.
20150603 02:59:58-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 03:02:47-!- ancientcc_ [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 03:04:13-!- ancientcc_ [~ancientcc@114.111.166.47] has quit [Read error: Connection reset by peer]
20150603 03:04:28-!- ancientcc_ [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 03:04:48-!- ancientcc [~ancientcc@114.111.166.47] has quit [Ping timeout: 272 seconds]
20150603 03:07:28-!- ancientcc_ [~ancientcc@114.111.166.47] has quit [Read error: Connection reset by peer]
20150603 03:08:34-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 03:09:21-!- ancientcc [~ancientcc@114.111.166.47] has quit [Read error: Connection reset by peer]
20150603 03:09:56-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 03:10:53-!- ancientcc [~ancientcc@114.111.166.47] has quit [Read error: Connection reset by peer]
20150603 03:11:13-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 03:11:35-!- ancientcc is now known as 17SACP70X
20150603 03:12:03-!- 17SACP70X [~ancientcc@114.111.166.47] has quit [Read error: Connection reset by peer]
20150603 03:14:34-!- ancientcc [~ancientcc@118.187.21.44] has joined #wesnoth-dev
20150603 03:15:10-!- ancientcc [~ancientcc@118.187.21.44] has quit [Read error: Connection reset by peer]
20150603 03:15:30-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 03:16:35< shadowm> Yeah, it's not us.
20150603 03:18:10-!- ancientcc [~ancientcc@183.131.105.166] has quit [Read error: Connection reset by peer]
20150603 03:19:31< shadowm> http://pastebin.com/HPQCkbHh
20150603 03:19:55< shadowm> I wrote a short C program that plays and stops our silence.ogg several times, the result is the same crash.
20150603 03:19:57-!- abacabadabacaba [~abacabada@128-75-234-130.broadband.corbina.ru] has joined #wesnoth-dev
20150603 03:21:47< shadowm> It doesn't happen if I don't mistype the LD_LIBRARY_PATH like in the paste, but since I got the crash in Wesnoth with the path, timing is most certainly involved.
20150603 03:22:33-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150603 03:23:01< shadowm> Since I really doubt I'll figure out what's wrong with libvorbisfile or libogg (the structure involved is internal so I doubt it's SDL_mixer's fault), I think the safest course of action is to apply the AtS method to mainline and make a bigger silence.ogg.
20150603 03:24:02-!- ancientcc [~ancientcc@61.164.211.210] has quit [Read error: Connection reset by peer]
20150603 03:24:07< shadowm> 5.2 KiB.
20150603 03:24:18< shadowm> Our smallest sfx .ogg is 4.8 KiB. Hm.
20150603 03:24:31-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150603 03:25:29-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150603 03:25:47-!- gfgtdf [~chatzilla@f054163236.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.1/20150513174244]]
20150603 03:26:57-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150603 03:28:15-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has joined #wesnoth-dev
20150603 03:31:28-!- ancientcc [~ancientcc@61.164.211.210] has quit [Remote host closed the connection]
20150603 03:33:10< shadowm> It apepars that anything smaller than sounds/explosion.ogg is a possible trigger.
20150603 03:33:37< shadowm> That's pretty much every .ogg sfx file we have.
20150603 03:37:05< shadowm> But only as music, it seems.
20150603 03:37:37< shadowm> I'm guessing that uninit value is the involved somehow.
20150603 03:39:24-!- abacabadabacaba [~abacabada@128-75-234-130.broadband.corbina.ru] has left #wesnoth-dev []
20150603 03:40:32-!- ancientcc [~ancientcc@118.187.21.44] has joined #wesnoth-dev
20150603 03:41:24-!- ancientcc [~ancientcc@118.187.21.44] has quit [Remote host closed the connection]
20150603 03:55:06-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 04:00:54-!- ancientcc [~ancientcc@183.131.105.166] has quit [Read error: Connection reset by peer]
20150603 04:03:01-!- Kwandulin [~Miranda@p5B009CF5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150603 04:03:17-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20150603 04:03:54-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has joined #wesnoth-dev
20150603 04:07:23-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 04:09:29-!- ancientcc [~ancientcc@114.111.166.47] has quit [Client Quit]
20150603 04:21:36-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 04:28:26-!- ancientcc [~ancientcc@183.131.105.166] has quit [Quit: Leaving]
20150603 04:29:08-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 04:30:54-!- ancientcc [~ancientcc@114.111.166.47] has quit [Read error: Connection reset by peer]
20150603 04:31:20-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 04:33:35-!- ancientcc [~ancientcc@114.111.166.47] has quit [Remote host closed the connection]
20150603 04:34:34-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 04:35:29-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 04:36:54-!- ancientcc_ [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 04:38:48-!- ancientcc_ [~ancientcc@183.131.105.166] has quit [Client Quit]
20150603 04:39:24-!- ancientcc_ [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 04:39:50-!- ancientcc_ [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150603 04:39:56-!- ancientcc [~ancientcc@183.131.105.166] has quit [Ping timeout: 256 seconds]
20150603 04:39:56-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 272 seconds]
20150603 04:40:20-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 04:40:51-!- ancientcc [~ancientcc@114.111.166.47] has quit [Remote host closed the connection]
20150603 04:41:16-!- ancientcc [~ancientcc@114.111.166.47] has joined #wesnoth-dev
20150603 04:45:18-!- ancientcc [~ancientcc@114.111.166.47] has quit [Client Quit]
20150603 04:49:14-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150603 04:50:21< shadowm> ancestral, loonycyborg, vultraz, zookeeper, gfgtdf, Elvish_Hunter: I've sent an email to the mailing list regarding Wesnoth 1.12.3 and 1.13.1.
20150603 04:51:40-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150603 04:52:31-!- mode/#wesnoth-dev [+o shadowm] by ChanServ
20150603 04:53:00-!- mode/#wesnoth-dev [+b-o *!*ancientcc@*$##FIX_YOUR_CONNECTION shadowm] by shadowm
20150603 05:04:50-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20150603 05:12:20< vultraz> shadowm: I'll be traveling for at least 2 weeks starting tomorrow (June 4th) , so I won't be able to help with the release or any blocker bugs until then. I'm putting off the implementation of the share_vision tristate key for now as well.
20150603 05:12:31< vultraz> s/then/I return
20150603 05:14:17< shadowm> Okay, have fun with that.
20150603 05:14:32< shadowm> I have a replacement vultraz anyway.
20150603 05:15:16< vultraz> D: who
20150603 05:15:29 * shadowm points at c74d.
20150603 05:15:36< c74d> ?
20150603 05:15:46< shadowm> He'll proofread the announcements.
20150603 05:16:00< c74d> How am I supposed to fix BfW bugs— oh.
20150603 05:16:30< vultraz> And give you in-depth etymology lectures.
20150603 05:16:43< shadowm> Those I can fairly easily tune out.
20150603 05:16:44< c74d> Unlikely.
20150603 05:17:27< vultraz> Oh wait, that's espreon, not number-san.
20150603 05:17:30< c74d> I'm not particularly well-versed in etymology.
20150603 05:17:45< c74d> Ah, yes, that makes more sense.
20150603 05:17:46< vultraz> Number-san gives you lectures on ISO standards.
20150603 05:20:02< shadowm> This $%$@!&# minimap buttons bug.
20150603 05:20:53-!- irker491 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20150603 05:20:53< irker491> wesnoth: Charles Dang wesnoth:master bc07e2ab2474 / src/hotkey/hotkey_command.cpp: "Custom Time of Day Creator" -> "Time Schedule Editor" http://git.io/vkFq4
20150603 05:20:53< shadowm> Every time I think I've fixed it, it resurfaces somehow.
20150603 05:24:19< irker491> wesnoth: Charles Dang wesnoth:master bf7e2daf02b9 / data/gui/default/window/custom_tod.cfg: tcustom_tod: shortened title http://git.io/vkFmf
20150603 05:42:48 * shadowm finally got around to filing https://gna.org/bugs/index.php?23633 .
20150603 05:44:24< shadowm> Hm, I forgot I also released 1.12.1, so that's also in that list.
20150603 05:46:16< shadowm> loonycyborg: Did we figure out which libogg/libvorbis version set was used to work around the sound crashes on Windows?
20150603 05:53:27< shadowm> Great, I produced an even smaller silence.ogg.
20150603 05:53:49< shadowm> I don't want to use the same method I used for AtS, which was inaudible pink noise.
20150603 05:55:57< shadowm> Huh, turns out that encoding a wav that's 10 seconds of real silence using oggenc produces a 86.6 KiB output.
20150603 05:56:13< shadowm> The wav is 1.7 MiB somehow.
20150603 06:03:07-!- mjs-de [~mjs-de@f053180207.adsl.alicedsl.de] has joined #wesnoth-dev
20150603 06:03:55< shadowm> The big silence.ogg works with my test program.
20150603 06:04:14< shadowm> Oh wait, spoke too soon.
20150603 06:04:56< shadowm> It'll eventually happen anyway but the odds are much smaller.
20150603 06:05:39< shadowm> grumble grumble mutter mutter
20150603 06:06:17< shadowm> At this point I think it's crucial to determine what versions of libogg/libvorbis* first made everything horrible and crashy.
20150603 06:14:52-!- Appleman1234 [~Appleman1@s108.BMT-e1.vectant.ne.jp] has joined #wesnoth-dev
20150603 06:21:20< shadowm> Smaller with my test program, anyway.
20150603 06:21:36< shadowm> I get the same odds as before with Wesnoth.
20150603 06:22:42-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 06:23:17< shadowm> Ah no, I had the wrong file symlinked.
20150603 06:23:41< shadowm> With the big silence.ogg Wesnoth doesn't seem to have a chance to crash.
20150603 06:27:19-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 245 seconds]
20150603 06:31:24-!- [Relic] [~Relic]@2602:306:33a3:6d30:9dcc:7533:8364:8c75] has quit [Quit: Leaving]
20150603 06:39:36-!- prkc [~prkc@catv-89-134-173-244.catv.broadband.hu] has quit [Remote host closed the connection]
20150603 06:40:08-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 272 seconds]
20150603 06:42:40-!- aeonchild [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 272 seconds]
20150603 06:52:03-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20150603 07:06:50-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth-dev
20150603 07:49:15-!- mjs-de [~mjs-de@f053180207.adsl.alicedsl.de] has quit [Remote host closed the connection]
20150603 08:10:53-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 08:15:39-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 252 seconds]
20150603 08:42:07-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20150603 09:10:51-!- Kwandulin [~Miranda@p5B009CF5.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150603 09:11:45-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 240 seconds]
20150603 09:13:34-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150603 09:32:33-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 240 seconds]
20150603 09:56:01-!- hay207 [~haythamme@41.34.13.94] has joined #wesnoth-dev
20150603 09:59:10-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 10:03:48-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 252 seconds]
20150603 10:03:49-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 250 seconds]
20150603 10:12:12-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150603 10:15:43-!- Frainz [~Frainz@mmisc.de] has quit [Ping timeout: 255 seconds]
20150603 10:17:22-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 272 seconds]
20150603 10:36:11-!- prkc [~prkc@catv-89-134-173-244.catv.broadband.hu] has joined #wesnoth-dev
20150603 10:40:48-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth-dev
20150603 11:40:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150603 11:47:24-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 11:52:27-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 256 seconds]
20150603 12:04:04-!- gfgtdf [~chatzilla@f054163236.adsl.alicedsl.de] has joined #wesnoth-dev
20150603 12:07:24< gfgtdf> shadowm: I currently am not sure anymoe about whether reverting spmp would be hard. I think i could be eought to restorre the old game_launcher::new_campaign function which (which does not call mpconnect) and dont touch the mp_connect/mp_create... changes
20150603 12:11:01-!- horrowind [~Icedove@2a02:810a:8b00:5298:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20150603 12:15:55< gfgtdf> vultraz: are you still wokring on the share_view/maps pr ?
20150603 12:19:13< vultraz> gfgtdf: no, I have a flight in the morning and I won't be around for at least 2 weeks. I've never worked with enums and it will take me awhile to get it right, and wire in all the conditionals, and add deprecation warnings for the old syntax, so I'm not starting now
20150603 12:19:22< vultraz> gfgtdf: feel free to do it instead, though
20150603 12:19:52< gfgtdf> vultraz: hm mayabe i'll do it.
20150603 12:21:04< vultraz> that'd be great 
20150603 12:22:37-!- irker491 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150603 12:23:18< vultraz> since you'd probably do it better than I could :)
20150603 12:28:24-!- gfgtdf [~chatzilla@f054163236.adsl.alicedsl.de] has quit [Ping timeout: 264 seconds]
20150603 13:35:38-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 13:35:57-!- hay207 [~haythamme@41.34.13.94] has quit [Remote host closed the connection]
20150603 13:40:37-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 264 seconds]
20150603 15:01:57-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 15:16:14-!- irker305 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20150603 15:16:14< irker305> wesnoth: gfgtdf wesnoth:master 430eab79fc15 / src/play_controller.cpp: remove 'delayed map sharing' http://git.io/vkAsm
20150603 15:26:20-!- Greg-Boggs [~quassel@173.240.247.62] has joined #wesnoth-dev
20150603 15:32:39-!- Kwandulin [~Miranda@p5B009CF5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150603 15:50:12-!- [Relic] [~Relic]@2602:306:33a3:6d30:5032:6984:a183:5be2] has joined #wesnoth-dev
20150603 16:37:45-!- kex [~kex@31.11.67.182] has quit [Read error: Connection reset by peer]
20150603 16:38:56-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 16:40:41-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20150603 16:41:35< vultraz> gfgtdf: what about team::copy_ally_shroud(), shouldn't that be removed along with that?
20150603 16:42:08-!- boucman_work [~jrosen@wesnoth/developer/boucman] has quit [Ping timeout: 276 seconds]
20150603 16:42:20-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20150603 16:49:02-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 246 seconds]
20150603 16:49:27-!- gfgtdf [~chatzilla@f054163236.adsl.alicedsl.de] has joined #wesnoth-dev
20150603 16:50:20< gfgtdf> vultraz: hm yes but that was a webintreface commit which only allows to change 1 file at a time, and removing a memeber function needs to edit 2 files (the hpp and thre cpp file). Will do that later
20150603 16:50:36< vultraz> I can do it now if you'd like
20150603 16:53:57-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20150603 16:54:00< gfgtdf> vultraz: that woudl be nice
20150603 16:56:10< irker305> wesnoth: Charles Dang wesnoth:master 759ab3d4cb58 / src/ (team.cpp team.hpp): Removed unused (as of 430eab79fc15) copy_ally_shroud function http://git.io/vkxIk
20150603 17:00:27-!- travis-ci [~travis-ci@ec2-184-72-184-133.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 17:00:28< travis-ci> wesnoth/wesnoth#6565 (master - 430eab7 : gfgtdf): The build was broken.
20150603 17:00:28< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/65262202
20150603 17:00:28-!- travis-ci [~travis-ci@ec2-184-72-184-133.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 17:16:12-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150603 17:18:50-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth-dev
20150603 17:40:45-!- travis-ci [~travis-ci@ec2-54-159-247-204.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 17:40:46< travis-ci> gfgtdf/wesnoth-old#468 (master - 1cebfff : gfgtdf): The build was broken.
20150603 17:40:46< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65272438
20150603 17:40:46-!- travis-ci [~travis-ci@ec2-54-159-247-204.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 17:59:33-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20150603 18:14:17-!- travis-ci [~travis-ci@ec2-54-159-247-204.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 18:14:18< travis-ci> gfgtdf/wesnoth-old#469 (master - 248c133 : gfgtdf): The build was broken.
20150603 18:14:18< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65282080
20150603 18:14:18-!- travis-ci [~travis-ci@ec2-54-159-247-204.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 18:32:14-!- travis-ci [~travis-ci@ec2-54-159-247-204.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 18:32:15< travis-ci> gfgtdf/wesnoth-old#470 (master - b30a3ec : gfgtdf): The build was broken.
20150603 18:32:15< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65283533
20150603 18:32:15-!- travis-ci [~travis-ci@ec2-54-159-247-204.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 18:33:36-!- noy [~Noy@24.244.23.152] has joined #wesnoth-dev
20150603 18:33:44-!- noy [~Noy@24.244.23.152] has quit [Changing host]
20150603 18:33:44-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20150603 18:38:10-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20150603 18:42:44-!- ancestral [~ancestral@c-107-4-212-240.hsd1.mn.comcast.net] has joined #wesnoth-dev
20150603 18:44:31-!- ancestral [~ancestral@c-107-4-212-240.hsd1.mn.comcast.net] has quit [Client Quit]
20150603 18:51:42-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20150603 19:03:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20150603 19:06:22-!- cib0 [~cib@p5DC758AD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150603 19:18:03-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20150603 19:41:35-!- cib0 [~cib@p5DC758AD.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150603 19:41:55-!- cib0 [~cib@p5DC758AD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150603 19:46:25-!- travis-ci [~travis-ci@ec2-54-89-7-22.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 19:46:26< travis-ci> gfgtdf/wesnoth-old#472 (master - 88f88fa : gfgtdf): The build is still failing.
20150603 19:46:26< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65295447
20150603 19:46:26-!- travis-ci [~travis-ci@ec2-54-89-7-22.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 19:53:47-!- kex [~kex@31.11.67.182] has quit [Remote host closed the connection]
20150603 19:55:59-!- gfgtdf [~chatzilla@f054163236.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.5/20150525141253]]
20150603 20:06:53-!- Kwandulin [~Miranda@p5B009CF5.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150603 20:29:11-!- irker305 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150603 20:32:15-!- travis-ci [~travis-ci@ec2-54-166-48-223.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 20:32:16< travis-ci> gfgtdf/wesnoth-old#473 (master - fd4e896 : gfgtdf): The build is still failing.
20150603 20:32:16< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65304506
20150603 20:32:16-!- travis-ci [~travis-ci@ec2-54-166-48-223.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 20:50:28-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20150603 20:54:27-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 21:12:49-!- travis-ci [~travis-ci@ec2-54-166-48-223.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 21:12:50< travis-ci> gfgtdf/wesnoth-old#475 (master - 7b1f115 : gfgtdf): The build failed.
20150603 21:12:50< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65310134
20150603 21:12:50-!- travis-ci [~travis-ci@ec2-54-166-48-223.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 21:23:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150603 21:28:48-!- horrowind [~Icedove@2a02:810a:8b00:5298:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20150603 21:33:51-!- travis-ci [~travis-ci@ec2-54-89-7-22.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 21:33:52< travis-ci> gfgtdf/wesnoth-old#476 (master - f704b85 : gfgtdf): The build failed.
20150603 21:33:52< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65312912
20150603 21:33:52-!- travis-ci [~travis-ci@ec2-54-89-7-22.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 21:45:49-!- cib0 [~cib@p5DC758AD.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
20150603 21:49:35-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20150603 21:50:54-!- cib0 [~cib@p5DC758AD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150603 22:02:34-!- kex [~kex@31.11.67.182] has quit [Read error: Connection reset by peer]
20150603 22:03:27-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150603 22:17:59-!- gfgtdf [~chatzilla@f054163236.adsl.alicedsl.de] has joined #wesnoth-dev
20150603 22:26:22-!- new_one [~new_one@2604:a880:1:20::22e:d001] has quit [Quit: WeeChat 1.1.1]
20150603 22:26:30-!- new_one [~new_one@2604:a880:1:20::22e:d001] has joined #wesnoth-dev
20150603 22:37:23-!- travis-ci [~travis-ci@ec2-54-159-247-204.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 22:37:24< travis-ci> gfgtdf/wesnoth-old#477 (master - 92cc7cb : gfgtdf): The build has errored.
20150603 22:37:25< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65318072
20150603 22:37:25-!- travis-ci [~travis-ci@ec2-54-159-247-204.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 22:42:18-!- [Relic] [~Relic]@2602:306:33a3:6d30:5032:6984:a183:5be2] has quit [Quit: Leaving]
20150603 22:43:52-!- [Relic] [~Relic]@2602:306:33a3:6d30:5032:6984:a183:5be2] has joined #wesnoth-dev
20150603 23:03:30-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20150603 23:12:43-!- travis-ci [~travis-ci@ec2-54-166-48-223.compute-1.amazonaws.com] has joined #wesnoth-dev
20150603 23:12:44< travis-ci> gfgtdf/wesnoth-old#478 (master - eacd352 : gfgtdf): The build is still failing.
20150603 23:12:44< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65323018
20150603 23:12:44-!- travis-ci [~travis-ci@ec2-54-166-48-223.compute-1.amazonaws.com] has left #wesnoth-dev []
20150603 23:46:32-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has joined #wesnoth-dev
20150603 23:50:01-!- cib0 [~cib@p5DC758AD.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
--- Log closed Thu Jun 04 00:00:03 2015