--- Log opened Tue Jun 02 00:00:12 2015
20150602 00:03:26-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 00:08:40-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 272 seconds]
20150602 00:59:38-!- shadowm_desktop2 [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20150602 01:00:25-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 264 seconds]
20150602 01:00:41-!- shadowm_desktop2 is now known as shadowm_desktop
20150602 01:21:17-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Read error: Connection reset by peer]
20150602 01:23:25-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20150602 01:23:29-!- ancientcc [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 01:24:12-!- gfgtdf_ [~chatzilla@f054144237.adsl.alicedsl.de] has joined #wesnoth-dev
20150602 01:24:14-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20150602 01:26:04-!- gfgtdf [~chatzilla@f054131162.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds]
20150602 01:26:07-!- gfgtdf_ is now known as gfgtdf
20150602 01:32:32-!- ancientcc [~ancientcc@114.111.166.42] has quit [Remote host closed the connection]
20150602 01:35:47-!- Lohengramm [sid1929@gateway/web/irccloud.com/x-mswufmhyijsrrjxh] has quit [Read error: Connection reset by peer]
20150602 01:36:29-!- gfgtdf [~chatzilla@f054144237.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.1/20150513174244]]
20150602 01:39:00-!- Lohengramm [sid1929@gateway/web/irccloud.com/x-gubscjagwyjtfdax] has joined #wesnoth-dev
20150602 01:41:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20150602 01:50:02-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 01:50:53 * shadowm was pretty sure up this point that disabling or hiding a grid affected all children.
20150602 01:51:32-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 01:52:05-!- ancientcc [~ancientcc@61.164.211.211] has quit [Remote host closed the connection]
20150602 01:52:32< shadowm> Wha, it worked now.
20150602 01:53:19< shadowm> Hm.
20150602 01:53:47< shadowm> I don't think it's gui2's fault...
20150602 01:54:53< shadowm> Yes indeed, the mod authentication flag never gets reset.
20150602 01:55:20< shadowm> So if I join the server with a mod account, leave, and come back with a normal account, the client still believes it's a mod.
20150602 01:56:32-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 265 seconds]
20150602 02:03:38-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 02:05:25-!- irker376 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20150602 02:05:25< irker376> wesnoth: Ignacio R. Morelle wesnoth:1.12 dab5668e4d73 / / (3 files in 3 dirs): gui2/tmp_cmd_wrapper: Regroup mod options into a grid that's hidden by default http://git.io/vky3Q
20150602 02:05:26< irker376> wesnoth: Ignacio R. Morelle wesnoth:master 049d2afbb13c / / (3 files in 3 dirs): gui2/tmp_cmd_wrapper: Regroup mod options into a grid that's hidden by default http://git.io/vky37
20150602 02:06:11-!- ancientcc [~ancientcc@61.164.211.211] has quit [Remote host closed the connection]
20150602 02:06:42-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 02:17:23-!- ancientcc [~ancientcc@61.164.211.211] has quit [Quit: Leaving]
20150602 02:19:17-!- ancientcc [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 02:19:40-!- ancientcc [~ancientcc@114.111.166.42] has quit [Client Quit]
20150602 02:26:22-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20150602 02:41:38 * shadowm loves it when Git manages to resolve patches across rename operations.
20150602 02:43:19< irker376> wesnoth: Ignacio R. Morelle wesnoth:master e4af763f31f4 / src/gui/dialogs/mp_cmd_wrapper.cpp: gui2/tmp_cmd_wrapper: Update documentation http://git.io/vkyWC
20150602 02:43:22< irker376> wesnoth: Ignacio R. Morelle wesnoth:master d105aa86c4f1 / src/ (game_initialization/multiplayer.cpp game_preferences.cpp game_preferences.hpp): mp: Reset authentication flag after disconnecting http://git.io/vkyWW
20150602 02:43:25< irker376> wesnoth: Ignacio R. Morelle wesnoth:1.12 68980114dc9e / src/gui/dialogs/mp_cmd_wrapper.cpp: gui2/tmp_cmd_wrapper: Update documentation http://git.io/vkyWl
20150602 02:43:28< irker376> wesnoth: Ignacio R. Morelle wesnoth:1.12 a50252907a7d / src/ (game_preferences.cpp game_preferences.hpp multiplayer.cpp): mp: Reset authentication flag after disconnecting http://git.io/vkyW8
20150602 02:58:14< shadowm>     #if !defined(ALWAYS_USE_MP_CONTROLLER)
20150602 02:58:27< shadowm> How very curious.
20150602 03:01:22< vultraz> is that even a syntax
20150602 03:02:37< shadowm> You've not read much C++ or C, have you?
20150602 03:03:01< vultraz> nope
20150602 03:03:07< shadowm> `#ifdef SYMBOL` is shorthand for `#if defined(SYMBOL)`.
20150602 03:03:31< shadowm> The full `#if` syntax is a little more powerful than that.
20150602 03:05:51< vultraz> so that thing before is the equivalent of #ifndef?
20150602 03:08:30< shadowm> Yes.
20150602 03:12:28-!- Kwandulin [~Miranda@p5B009CB8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150602 03:22:26-!- ancientcc [~ancientcc@183.131.105.167] has joined #wesnoth-dev
20150602 03:22:46-!- ancientcc [~ancientcc@183.131.105.167] has quit [Remote host closed the connection]
20150602 03:31:15-!- ancientcc [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 03:31:26-!- ancientcc [~ancientcc@114.111.166.42] has quit [Client Quit]
20150602 03:39:28-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 03:39:51-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 03:43:09-!- ancientcc [~ancientcc@61.164.211.211] has quit [Client Quit]
20150602 03:45:16-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 272 seconds]
20150602 03:52:49-!- ancientcc_ [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 03:53:58-!- ancientcc_ [~ancientcc@114.111.166.42] has quit [Remote host closed the connection]
20150602 03:55:44-!- ancientcc [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 03:55:58-!- ancientcc [~ancientcc@114.111.166.42] has quit [Client Quit]
20150602 03:57:40-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 03:57:55-!- ancientcc [~ancientcc@61.164.211.211] has quit [Client Quit]
20150602 03:58:23-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 03:58:53-!- ancientcc [~ancientcc@61.164.211.211] has quit [Remote host closed the connection]
20150602 03:59:21-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 04:00:21-!- hay207 [~haythamme@41.34.13.94] has joined #wesnoth-dev
20150602 04:01:01-!- ancientcc [~ancientcc@61.164.211.211] has quit [Client Quit]
20150602 04:01:28-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 04:09:35-!- ancientcc [~ancientcc@61.164.211.211] has quit [Quit: Leaving]
20150602 04:11:57-!- Kwandulin [~Miranda@p5B009CB8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150602 04:19:55-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 04:24:14-!- ancientcc [~ancientcc@61.164.211.211] has quit [Quit: Leaving]
20150602 04:29:22-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 04:30:18-!- ancientcc [~ancientcc@61.164.211.211] has quit [Remote host closed the connection]
20150602 04:36:08-!- ancientcc [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 04:41:00-!- ancientcc [~ancientcc@114.111.166.42] has quit [Quit: Leaving]
20150602 04:43:15-!- ancientcc [~ancientcc@61.164.211.211] has joined #wesnoth-dev
20150602 04:43:59-!- ancientcc [~ancientcc@61.164.211.211] has quit [Remote host closed the connection]
20150602 04:51:22-!- ancientcc [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 04:52:12-!- ancientcc [~ancientcc@114.111.166.42] has quit [Remote host closed the connection]
20150602 04:52:57-!- ancientcc [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 04:55:37-!- ancientcc [~ancientcc@114.111.166.42] has quit [Client Quit]
20150602 05:06:11< shadowm> Yep, the disappearing bars+ellipse+orb bug happens with SP replays too.
20150602 05:06:31< shadowm> It's easiest to reproduce using the Play Side Turn option with Skip animations checked.
20150602 05:06:45-!- ancientcc [~ancientcc@114.111.166.42] has joined #wesnoth-dev
20150602 05:07:53< shadowm> I'm trying to see if it's a problem with the move action code.
20150602 05:08:02-!- ancientcc [~ancientcc@114.111.166.42] has quit [Remote host closed the connection]
20150602 05:10:07< shadowm> Great, I have to inspect the innards of the animation engine again.
20150602 05:10:19-!- hay207 [~haythamme@41.34.13.94] has quit [Quit: Leaving]
20150602 05:17:40< shadowm> Eh.
20150602 05:18:15< shadowm> I didn't realize display had a static method to retrieve a pointer to the unique instance.
20150602 05:19:01< shadowm> <_< So I _could_ have added combobox support to generic GUI1 dialogs without too much trouble.
20150602 05:27:10< shadowm> actions/move.cpp: unit_mover::try_actual_movement() calls do_move() after starting the animation.
20150602 05:27:32< shadowm> do_move() disables unit bars.
20150602 05:27:59-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 05:28:09< shadowm> But after returning from do_move(), the animation ends IF the unit iterator is still valid.
20150602 05:28:40< shadowm> unit_mover::finish() restores unit bars regardless of the animate toggle.
20150602 05:29:03< shadowm> It also invalidates the start and end locations.
20150602 05:29:19< shadowm> So the renderer should redraw the bars next.
20150602 05:31:40< vultraz> disables unit bars, you say?
20150602 05:32:10< shadowm> Time to get a debug build and use breakpoints.
20150602 05:32:44-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 245 seconds]
20150602 05:32:50< shadowm> Also, NTS check what the hell is up with Load Game and filtering on long filenames.
20150602 05:35:55< shadowm> Wait.
20150602 05:36:52< shadowm> We call the set_standing method once to disable bars and again to reenable them.
20150602 05:37:03< shadowm> Why does it need to be called the first time...
20150602 05:37:53< shadowm> Is this how partial path movement is implement?
20150602 05:38:03< shadowm> ed
20150602 05:39:03< shadowm> So... a single move is actually multiple calls to the move animator.
20150602 05:39:36< shadowm> One for each hex along the path, probably.
20150602 05:39:59< shadowm> Because we need to update shroud and fog and dispatch WML events for every step.
20150602 05:40:04< shadowm> Right.
20150602 05:40:30< shadowm> So...
20150602 05:41:06< shadowm> Throwing an exception from the path loop would be an obvious cause for the unit bars not being restored.
20150602 05:42:41< shadowm> But no, that's not it.
20150602 05:46:47< shadowm> Okay.
20150602 05:48:23< shadowm> A single unit_mover can move multiple units.
20150602 05:48:36< shadowm> Or.
20150602 05:48:47< shadowm> Wait no, I'm jumping to conclusions and that's a stack address.
20150602 05:50:28< shadowm> The unit pointer can change due to WML event handling, hm.
20150602 05:51:22< shadowm> I probably should've used a replay of a simpler scenario for this.
20150602 05:54:01< shadowm> What the hell.
20150602 05:54:15-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 05:54:24< shadowm> set_standing() was never called with with_bars=true at any point before ending the turn replay.
20150602 05:55:17< shadowm> But I added probes to ensure the iterator remains valid and no exceptions are thrown.
20150602 05:56:46< shadowm> unit_mover::finish() will only abort if...
20150602 05:56:47-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 05:57:09< shadowm> !( disp_  &&  !disp_->video().update_locked()  && !disp_->video().faked()  &&  path.size() > 1 )
20150602 05:58:51-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 05:59:04< shadowm> > CANNOT DRAW, DISPLAY IS LOCKED
20150602 05:59:17< shadowm> Well, there it is. Mystery half-solved.
20150602 06:01:38< shadowm> Now I need to find out who is locking the display and why.
20150602 06:03:08-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has joined #wesnoth-dev
20150602 06:04:00< shadowm> It's replay::do_replay().
20150602 06:05:23< shadowm> It only does this Quick replays/Skip animation. Makes sense. So I think I just need to patch the unit_mover logic to restore unit bars even if it's not "supposed" to draw.
20150602 06:05:28-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150602 06:05:33< shadowm> *this with
20150602 06:05:58-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 06:06:17< shadowm> Wait, but it's not the unit_mover's responsibility to disable bars for non-fake units.
20150602 06:06:31< shadowm> Unless animating, then...
20150602 06:07:43-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150602 06:07:47< shadowm> This is probably an oversight introduced by mid-move events and partial fog/shroud updates.
20150602 06:13:21< shadowm> Bleh I'm undecided exactly where to deploy the fix.
20150602 06:14:25< shadowm> By all means this should be the action engine's unit_mover's responsibility. not the animation engine's unit_mover's.
20150602 06:14:43< shadowm> But I don't want to call set_standing() more times than necessary because it starts an animation each time.
20150602 06:16:33< shadowm> And it shouldn't be the animation unit_mover's responsibility to deal with the idiosyncrasies of the gameplay code.
20150602 06:16:34< irker376> wesnoth: Charles Dang wesnoth:master ff4fe33b4b05 / data/gui/default/window/title_screen.cfg: Add border around titlescreen version label http://git.io/vkyNO
20150602 06:16:34< irker376> wesnoth: Charles Dang wesnoth:master 80b22f2b18d6 / data/gui/default/window/title_screen.cfg: Fixed some non-standard indent http://git.io/vkyN3
20150602 06:17:01< shadowm> On the other hand, either option means I'll call set_standing() an extra time unless I make the animation engine's unit_mover expose an implementation detail.
20150602 06:20:51< shadowm> No.
20150602 06:21:25< shadowm> I'm overcomplicating things. Only the animation engine's unit_mover logic needs to be patches.
20150602 06:21:28< shadowm> patched
20150602 06:21:41< shadowm> Otherwise the unit facing isn't set either!
20150602 06:22:14-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 06:22:27< shadowm> OTOH the action engine's unit_mover actually takes care of that for every path step right now. Hm.
20150602 06:22:52-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 06:23:50< shadowm> set_facing() is actually a trivial setter, so making the animation engine call that even when the display is locked shouldn't hurt anything.
20150602 06:35:10< shadowm> \o/
20150602 06:36:29< shadowm> Hm. An animation engine unit_mover is instantiated at some point in start/prestart in AtS E3S3 while the display is locked and not in a replay.
20150602 06:37:57< shadowm> It's only that scenario for some reason.
20150602 06:39:32< shadowm> Oh, it's the [teleport] tag.
20150602 06:39:54< shadowm> Nothing to worry about then.
20150602 06:50:31-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 256 seconds]
20150602 06:52:03< shadowm> :|
20150602 06:52:49-!- boucman_work [~jrosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150602 06:54:06< shadowm> Okay.
20150602 06:59:08< vultraz> Hm... so configure_engine::shroud_game_default() returns false as default, as is expected
20150602 06:59:57< shadowm> BLARGH I polluted my patch with debug garbage.
20150602 07:00:05< vultraz> so something must be initializing shroud somewhere
20150602 07:00:24< shadowm> Someone get working on a git revert -p option stat.
20150602 07:03:05< irker376> wesnoth: Ignacio R. Morelle wesnoth:master e249945b3621 / changelog players_changelog src/actions/move.cpp src/unit_display.cpp: Restore unit bars after moving even if the animator is disabled http://git.io/vkSJL
20150602 07:03:08< irker376> wesnoth: Ignacio R. Morelle wesnoth:1.12 dd36c4ed5ff6 / changelog players_changelog src/actions/move.cpp src/unit_display.cpp: Restore unit bars after moving even if the animator is disabled http://git.io/vkSJt
20150602 07:03:34-!- [Relic] [~Relic]@2602:306:33a3:6d30:404c:c9d9:f618:d328] has quit [Quit: Leaving]
20150602 07:04:33< shadowm> God that was intense.
20150602 07:06:35< shadowm> And now to deal with that annoying Load Game bug.
20150602 07:07:23< shadowm> Eh.
20150602 07:07:28< shadowm> What?
20150602 07:07:38< shadowm> Save file names are actually ellipsized on disk?!
20150602 07:10:32< shadowm> !commit f38efa0446cbb4300d99b0288c7abacca5737172
20150602 07:10:33< shikadibot> shadowm: Revision f38efa0446cb (Jörg Hinrichs) on Tue Apr  7 18:46:14 2009:
20150602 07:10:33< shikadibot> shadowm: Savegame code goes OO...
20150602 07:10:33< shikadibot> shadowm:  
20150602 07:10:33< shikadibot> shadowm: Further optimizing the save_game functionality. I gave this quite some
20150602 07:10:33< shikadibot> shadowm: (+4 discarded lines)
20150602 07:10:33< shikadibot> shadowm: Web interface URL: https://github.com/wesnoth/wesnoth/commit/f38efa0446cb
20150602 07:11:07< shadowm> !commit 369d88c5690c8d92abef107c9aee136a6124f9c6
20150602 07:11:09< shikadibot> shadowm: Revision 369d88c5690c (Jörg Hinrichs) on Sun Nov 20 18:44:44 2005:
20150602 07:11:11< shikadibot> shadowm: Replay functionality
20150602 07:11:13< shikadibot> shadowm:  
20150602 07:11:16< shikadibot> shadowm: - added main menu support
20150602 07:11:18< shikadibot> shadowm: (+8 discarded lines)
20150602 07:11:21< shikadibot> shadowm: Web interface URL: https://github.com/wesnoth/wesnoth/commit/369d88c5690c
20150602 07:12:27< vultraz> Ok, I just caused a crash somehow..
20150602 07:12:28< shadowm> wtf @ diff LHS
20150602 07:13:00< shadowm> The save code predates this commit, it can't possibly have popped out of nowhere.
20150602 07:14:17< vultraz> Ok, I can consistently reproduce this 
20150602 07:15:24< vultraz> ok wtf, when did share_view become default true
20150602 07:15:45< vultraz> er, maps
20150602 07:16:08< vultraz> ok, lemme test without my change..
20150602 07:16:21-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 07:16:24< shadowm> Well, whatever, I decided it's a stupid decision.
20150602 07:17:07< shadowm> I'm going to make it so we ellipsize on-disk at a more reasonable char count (127?) and let the GUI deal with it.
20150602 07:17:28< vultraz> Ok for god's sake, anther bloody sp/mp bug
20150602 07:18:13< vultraz> ugh, one thing at a time
20150602 07:18:25-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth-dev
20150602 07:18:33< vultraz> (I think this may actually be related to that place_shroud bug I filed previously)
20150602 07:18:43< shadowm> Why am I not surprised I'm the first campaign author to notice this is a stupid thing that takes place and inconveniences people.
20150602 07:19:42< vultraz> If I comment out the block at game_initialization/connect_engine.cpp#L1077, shroud gets applied correctly to scenarios
20150602 07:20:38< vultraz> hmm..
20150602 07:21:14-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 272 seconds]
20150602 07:21:35< vultraz> What does this code even do
20150602 07:21:37< vultraz> (res["shroud"].to_bool(true) == true && res["shroud"].to_bool(false) == false))
20150602 07:21:39< shadowm> Are you kidding me.
20150602 07:21:51< shadowm> The ellipsizing is done glyph length-wise.
20150602 07:23:38< shadowm> Words escape me.
20150602 07:24:09< vultraz> So the connect engine is called from enter_connect_mode
20150602 07:24:36< vultraz> Which is called AFTER engine.set_default_values()
20150602 07:25:11-!- grzywacz [~grzywacz@ec2-52-16-235-23.eu-west-1.compute.amazonaws.com] has joined #wesnoth-dev
20150602 07:25:11-!- grzywacz [~grzywacz@ec2-52-16-235-23.eu-west-1.compute.amazonaws.com] has quit [Changing host]
20150602 07:25:11-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20150602 07:26:15< vultraz> so... I assume the new side_configs just don't respect those default values for some reason
20150602 07:33:10< shadowm> Next: the libvorbis memory corruption bug from hell.
20150602 07:33:53< shadowm> I'm probably going on vacation after that.
20150602 07:54:12< vultraz> parent_.params_.shroud_game equals..... 1??
20150602 07:54:19< vultraz> ok what is this
20150602 08:09:22< vultraz> ok so..
20150602 08:09:31< vultraz> I seem to have fixed this bug, in a way
20150602 08:09:45< vultraz> but I'm not sure if it's the right way
20150602 08:14:14-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20150602 08:21:40< vultraz> shikadibot: seen gfgtdf
20150602 08:21:40< shikadibot> vultraz: The person with the nick gfgtdf 6h 45m ago they left with the message: Quit: ChatZilla 0.9.91.1 [Firefox 38.0.1/20150513174244]
20150602 08:22:13< vultraz> dat english 
20150602 08:29:37-!- Crendgrim [~crend@wesnoth/forum-moderator/crendgrim] has joined #wesnoth-dev
20150602 08:32:31-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Quit: :wq]
20150602 08:53:18< shadowm>     return ( const_cast<uint1*>(reinterpret_cast<const uint1*>("")));
20150602 08:53:42< shadowm> ¬_¬
20150602 08:54:12-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 08:55:16< shadowm> Doesn't the resulting pointer have a chance to refer to a RO page?
20150602 08:56:09< shadowm> Or maybe not since it's not actually properly declared as a static const.
20150602 08:58:12-!- Elvish_Hunter [~irssi@wesnoth/developer/elvish-hunter] has joined #wesnoth-dev
20150602 09:09:58< shadowm> The more I think about it, the worse it sounds.
20150602 09:10:42< shadowm> There isn't a real guarantee the caller won't overwrite the result and corrupt the stack.
20150602 09:11:57< shadowm> Luckily this is only used to generate MP map hashes to detect the "remote scenario" situation.
20150602 09:12:03< shadowm> :\
20150602 09:15:24-!- Kexoth [~kex@89.205.79.252] has joined #wesnoth-dev
20150602 09:17:58< irker376> wesnoth: Elvish_Hunter wesnoth:master 0e36bedb843d / changelog data/multiplayer/factions/rebels-aoh.cfg players_changelog: Removed Silver Mage from the Rebels' leaders in Age of Heroes http://git.io/vkSoH
20150602 09:18:26-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 244 seconds]
20150602 09:18:32< shadowm> Oh man.
20150602 09:19:11< shadowm> I think Wesnoth has been running with a bomb strapped to its back.
20150602 09:25:16< shadowm> >.<
20150602 09:25:26< shadowm> Yep, this is bad.
20150602 09:26:02< shadowm> I can't believe we've gotten away with this UB for so long.
20150602 09:27:43< Elvish_Hunter> Tell me about it... I just fixed a two and half years old bug... :-(
20150602 09:34:26-!- shadowm_desktop [ignacio@wesnoth/developer/shadowm] has quit [Ping timeout: 246 seconds]
20150602 09:36:26-!- Kexoth [~kex@89.205.79.252] has quit [Remote host closed the connection]
20150602 09:39:19-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 09:44:20-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 265 seconds]
20150602 09:45:58-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 09:55:57-!- kex [~kex@31.11.67.182] has quit [Remote host closed the connection]
20150602 10:12:38-!- Elvish_Hunter [~irssi@wesnoth/developer/elvish-hunter] has quit [Quit: Ciao!]
20150602 10:14:18-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 265 seconds]
20150602 10:39:05-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth-dev
20150602 10:40:32-!- ancestral [~ancestral@71-34-1-180.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20150602 10:47:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150602 10:53:27< matthiaskrgr> shadowm: the overflow I found via ASAN? :s 
20150602 11:04:12-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 11:04:54-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150602 11:07:03-!- hay207 [~haythamme@41.34.13.94] has joined #wesnoth-dev
20150602 11:29:40-!- ancientcc [~ancientcc@118.187.21.47] has joined #wesnoth-dev
20150602 11:30:26-!- ancientcc [~ancientcc@118.187.21.47] has quit [Client Quit]
20150602 11:35:21-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 11:40:00-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 244 seconds]
20150602 11:41:55-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 11:42:00-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 11:43:36-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 11:43:58-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 11:44:47-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 11:45:25-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150602 11:51:19-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 11:51:43-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 11:57:55-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 11:57:59-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 12:00:07-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 12:03:16-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 255 seconds]
20150602 12:04:13-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 12:04:31-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:05:24-!- ancientcc [~ancientcc@114.111.166.43] has quit [Read error: Connection reset by peer]
20150602 12:06:23-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:06:59-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 12:10:11< Soliton> shadowm: "Someone get working on a git revert -p option stat." maybe you want git reset -p.
20150602 12:10:17-!- mjs-de [~mjs-de@f048199213.adsl.alicedsl.de] has joined #wesnoth-dev
20150602 12:14:20-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:14:58-!- ancientcc [~ancientcc@114.111.166.43] has quit [Remote host closed the connection]
20150602 12:15:53< vultraz> gfgtdf: ping me when you get back
20150602 12:18:32-!- irker376 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150602 12:20:15-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:20:15-!- ancientcc [~ancientcc@114.111.166.43] has quit [Remote host closed the connection]
20150602 12:20:52-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 12:23:37-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:23:38-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 12:24:38-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:24:42-!- ancientcc [~ancientcc@114.111.166.43] has quit [Remote host closed the connection]
20150602 12:26:28-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:26:37-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 12:27:26-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth-dev
20150602 12:28:59-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:29:15-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 12:31:03-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 12:49:39-!- irker803 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20150602 12:49:39< irker803> wesnoth: Charles Dang wesnoth:master f3867261b784 / data/campaigns/Descent_Into_Darkness/scenarios/09_A_Small_Favor3.cfg: DiD S9: lock view during starting sequence http://git.io/vk9iM
20150602 12:51:49-!- ancientcc [~ancientcc@114.111.166.43] has quit [Quit: Leaving]
20150602 13:01:10-!- gfgtdf [~chatzilla@f054144237.adsl.alicedsl.de] has joined #wesnoth-dev
20150602 13:01:17< gfgtdf> vultraz: ?
20150602 13:01:48< vultraz> gfgtdf: ok so I'm investigating the bug where shroud is applied incorrectly to scenarios with none
20150602 13:03:12< vultraz> gfgtdf: this seems to fix it but im not sure if it's the proper way http://pastebin.com/whiCSARC
20150602 13:03:55< vultraz> bc configure_engine::set_default_values() is supposed to set that to false...
20150602 13:03:57< vultraz> but it doesn't
20150602 13:04:03< gfgtdf> vultraz: i wouldnt say this is teh propery way
20150602 13:04:20< vultraz> if I read parent_.params_.shroud_game the value is 1
20150602 13:04:22< vultraz> not bool
20150602 13:04:53< gfgtdf> vultraz: with the Fog is always set the the params value and shroud never is
20150602 13:05:03< gfgtdf> vultraz: maybe you debugger prints bool as 1/0
20150602 13:05:16< gfgtdf> vultraz: or your debugger is confused by buidl opmisations
20150602 13:05:29< vultraz> no i used a log operation
20150602 13:05:32< vultraz> to print it to stderr
20150602 13:05:57< gfgtdf> vultraz: stderr by default prints bool as 1/0
20150602 13:06:26< gfgtdf> vultraz: my try woudol be tpo replace teh chack "!parent_.params_.use_map_settings || res["fog"].empty() ||  (res["fog"].to_bool(true) == true && res["fog"].to_bool(false) == false)" by simply "!parent_.params_.use_map_settings"
20150602 13:06:41< gfgtdf> vultraz: i actually dont know why we check for teh other things
20150602 13:06:49< gfgtdf> vultraz: same for fog of yourse
20150602 13:07:01< vultraz> ok ill try that
20150602 13:07:01< gfgtdf> course*
20150602 13:09:15< gfgtdf> vultraz: that is for both fog abd shrodu replace that check
20150602 13:14:11-!- ancientcc [~ancientcc@118.187.21.47] has joined #wesnoth-dev
20150602 13:14:12-!- ancientcc [~ancientcc@118.187.21.47] has quit [Remote host closed the connection]
20150602 13:30:31-!- ancientcc [~ancientcc@118.187.21.47] has joined #wesnoth-dev
20150602 13:35:13-!- ancientcc [~ancientcc@118.187.21.47] has quit [Remote host closed the connection]
20150602 13:36:19-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 13:37:51< gfgtdf> vultraz: did it work ?
20150602 13:40:08-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 13:40:10< vultraz> hang on had to do something else
20150602 13:42:00-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 13:43:16< vultraz> gfgtdf: seems to work
20150602 13:43:32-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150602 13:45:00-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 13:45:03< vultraz> gfgtdf: should I commit it?
20150602 13:47:56-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 13:53:15-!- ancientcc [~ancientcc@118.187.21.47] has joined #wesnoth-dev
20150602 13:54:36-!- ancientcc [~ancientcc@118.187.21.47] has quit [Client Quit]
20150602 13:55:00< vultraz> gfgtdf: BTW, i found another bug. using :n mid-event causes a crash
20150602 13:58:25< gfgtdf> vultraz: hm yes :n shoudl be forbidden mid event
20150602 13:59:05< gfgtdf> vultraz: but since it is  a debug defature i dont think its that important
20150602 13:59:12< gfgtdf> vultraz: commit it if you want
20150602 13:59:38< gfgtdf> vultraz: I dont think it can hurt althought we might revert the spmp patch anyway.
20150602 14:05:29< vultraz> I don't think that will be simple
20150602 14:05:36< vultraz> A lot of refactoring has gone on on top of it
20150602 14:05:37-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 14:05:50< irker803> wesnoth: Charles Dang wesnoth:master 83eb7d37a4c4 / src/game_initialization/connect_engine.cpp: Drop superfluous conditions for setting side starting shroud/fog. Fixes bug #234 http://git.io/vkHIp
20150602 14:06:34-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 14:09:51< gfgtdf> vultraz: i actualy think is less refactoring code and more fixes/features
20150602 14:10:31< gfgtdf> vultraz: but what migth be easier is not changing the mp connect code and just restore the old sp path.
20150602 14:11:02-!- ancientcc [~ancientcc@118.187.21.47] has joined #wesnoth-dev
20150602 14:12:05-!- ancientcc [~ancientcc@118.187.21.47] has quit [Client Quit]
20150602 14:13:02-!- kex [~kex@31.11.67.182] has quit [Remote host closed the connection]
20150602 14:14:43-!- ancientcc [~ancientcc@118.187.21.47] has joined #wesnoth-dev
20150602 14:15:24-!- ancientcc [~ancientcc@118.187.21.47] has quit [Client Quit]
20150602 14:15:53-!- ancientcc [~ancientcc@118.187.21.47] has joined #wesnoth-dev
20150602 14:19:53-!- ancientcc [~ancientcc@118.187.21.47] has quit [Remote host closed the connection]
20150602 14:23:11-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 14:23:47-!- ancientcc_ [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 14:24:34-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 14:26:51-!- ancientcc_ [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 14:26:51-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20150602 14:28:06-!- ancientcc [~ancientcc@183.131.105.166] has quit [Ping timeout: 272 seconds]
20150602 14:29:24-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 245 seconds]
20150602 14:29:28-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 14:30:38-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150602 14:34:30-!- ancientcc_ [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 14:35:47-!- ancientcc_ [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 14:37:04-!- ancientcc_ [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 14:39:24-!- ancientcc_ [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 14:40:43-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 14:41:22-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 14:41:28-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 14:41:50-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 14:50:23-!- ancientcc [~ancientcc@183.131.105.166] has quit [Quit: Leaving]
20150602 14:50:50-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 14:53:05-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 14:55:13-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 14:58:59-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 15:01:59-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 15:10:47-!- ancientcc [~ancientcc@114.111.166.43] has quit [Quit: Leaving]
20150602 15:11:33-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 15:11:59-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 15:13:13-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 15:15:14-!- ancientcc [~ancientcc@183.131.105.166] has quit [Client Quit]
20150602 15:17:41-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 15:18:42-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150602 15:29:00-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 246 seconds]
20150602 15:29:25-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 15:31:03-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150602 15:31:45-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 15:34:00-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150602 15:36:15-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 15:36:33-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 15:37:17-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 15:37:30-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 15:38:27-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 15:38:35-!- ancientcc [~ancientcc@114.111.166.43] has quit [Remote host closed the connection]
20150602 15:39:11-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 15:39:23-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 15:40:46-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 15:40:59-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 15:41:38-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 15:43:24-!- ancientcc [~ancientcc@61.164.211.210] has quit [Remote host closed the connection]
20150602 15:43:57-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 15:45:09-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150602 15:45:49-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 15:46:27-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150602 15:51:24-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth-dev
20150602 15:58:12-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 15:58:57-!- ancientcc [~ancientcc@114.111.166.43] has quit [Client Quit]
20150602 16:02:06-!- ancientcc [~ancientcc@114.111.166.43] has joined #wesnoth-dev
20150602 16:02:10-!- ancientcc [~ancientcc@114.111.166.43] has quit [Read error: Connection reset by peer]
20150602 16:04:08-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 16:06:54-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150602 16:07:16-!- ancientcc [~ancientcc@183.131.105.166] has joined #wesnoth-dev
20150602 16:10:30-!- ancientcc [~ancientcc@183.131.105.166] has quit [Remote host closed the connection]
20150602 16:13:06-!- hay207 [~haythamme@41.34.13.94] has quit [Ping timeout: 272 seconds]
20150602 16:14:30-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 16:14:59-!- ancientcc [~ancientcc@61.164.211.210] has quit [Client Quit]
20150602 16:15:35-!- hay207 [~haythamme@41.34.13.94] has joined #wesnoth-dev
20150602 16:16:46-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 16:17:06-!- ancientcc [~ancientcc@61.164.211.210] has quit [Remote host closed the connection]
20150602 16:19:23-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 16:20:40-!- ancientcc [~ancientcc@61.164.211.210] has quit [Remote host closed the connection]
20150602 16:21:19-!- ancientcc [~ancientcc@61.164.211.210] has joined #wesnoth-dev
20150602 16:22:30-!- ancientcc [~ancientcc@61.164.211.210] has quit [Remote host closed the connection]
20150602 16:22:56-!- ancientcc [~ancientcc@118.187.21.47] has joined #wesnoth-dev
20150602 16:25:49-!- ancientcc [~ancientcc@118.187.21.47] has quit [Client Quit]
20150602 16:27:13-!- hay207 [~haythamme@41.34.13.94] has quit [Quit: Leaving]
20150602 16:27:27< vultraz> hmmmm
20150602 16:28:25< vultraz> So share_view overrides share_maps
20150602 16:28:27< vultraz> why
20150602 16:29:29< vultraz> IMO wouldn't it make more sense for share_maps to override share_view?
20150602 16:30:04< vultraz> since share_view = yes and share_maps = no is basically...useless
20150602 16:30:39< vultraz> the expected behavior of that would be, don't share should, share fog
20150602 16:30:42< vultraz> which makes no sense
20150602 16:31:26< vultraz> share shroud but not fog, I can see
20150602 16:32:08< vultraz> "// Share_view and share_maps can't both be enabled,"
20150602 16:32:10< vultraz> why not?
20150602 16:34:24-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20150602 16:36:16< vultraz> so share_maps defaults to... true
20150602 16:36:18< vultraz> ok that's expected
20150602 16:36:30< vultraz> so does view
20150602 16:36:54< vultraz> so yeah, I think the thing is that maps should override view
20150602 16:37:17-!- [Relic] [~Relic]@2602:306:33a3:6d30:9dcc:7533:8364:8c75] has joined #wesnoth-dev
20150602 16:42:49< gfgtdf> vultraz: why do you think that sahre_naps shoud oiverride share view ?
20150602 16:43:41< gfgtdf> vultraz: actually i dont know of an situation where you'd want to use shre_maps, so mybe we shoudl remove it
20150602 16:44:49< vultraz> Doesn't view just control fog and maps control shroud?
20150602 16:45:05< gfgtdf> vultraz: i'd say yes but i didnt tet it
20150602 16:45:17-!- Haudegen [~quassel@85.124.51.57] has quit [Ping timeout: 246 seconds]
20150602 16:45:54< gfgtdf> vultraz: I just dont know of a situation where youd want the shoud updates to be shared but not fog updates
20150602 16:47:17< gfgtdf> vultraz: "// Share_view and share_maps can't both be enabled," this is wirrten becasue share_view impled share_maps
20150602 16:47:41< gfgtdf> vultraz: that is share_view means sharing shourd anf gof and share_maps only shares fog iirc
20150602 16:48:04< vultraz> hm... you have a point
20150602 16:48:14< vultraz> sharing shroud but not fog is kinda pointless
20150602 16:48:37< vultraz> so you think we should replace both with one share_view key which handles both?
20150602 16:49:18-!- kex [~kex@31.11.67.182] has quit [Remote host closed the connection]
20150602 16:49:40< gfgtdf> vultraz: thats what i'd say, but there is also this comment: https://github.com/wesnoth/wesnoth/blob/master/src/play_controller.cpp#L513 which i dont understand
20150602 16:50:53< vultraz> hm..
20150602 16:50:55< vultraz> no idea
20150602 16:52:23< vultraz> lemme see if I can merge them together anyway
20150602 16:55:52< gfgtdf> vultraz: acorgind to changelog delayed map sharing was a feature for mp
20150602 16:56:08< gfgtdf> vultraz: but in mp we currently always use shared vision
20150602 16:56:20< gfgtdf> vultraz: so i think we can maybe remove it
20150602 16:58:39< gfgtdf> vultraz: also it looks like delayed map sharing was implemented after share_view so i now really think we now dont need it anymore
20150602 17:00:03< gfgtdf> vultraz: this commit seems to implement delayed map sharing: https://github.com/wesnoth/wesnoth/commit/0b09efaefa5ea76622de71a0e2e10a9e9dfc35c4
20150602 17:00:24< gfgtdf> vultraz: and this commit seems ti implement shared_vision: https://github.com/wesnoth/wesnoth/commit/283370720d1ab76b358835e538dd9199d4c9a68f
20150602 17:06:14-!- irker803 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20150602 17:09:56-!- irker604 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20150602 17:09:56< irker604> wesnoth: gfgtdf wesnoth:master cabbede63a8d / src/ (hotkey/hotkey_command.cpp replay_controller.cpp replay_controller.hpp): replace "Team1" option with "First human team" in replay viewer. http://git.io/vkQz6
20150602 17:10:10< vultraz> gfgtdf: ok getting rid of share_maps gets rid of all the problems
20150602 17:10:25< gfgtdf> vultraz: which problems ?
20150602 17:11:52< vultraz> http://gna.org/bugs/?23458 used to be the issue, but then I tested today and it seems an explicit share_view = no was needed to make share_maps = no work at all. So now that I've gotten rid of maps, it's convenient 
20150602 17:12:46< gfgtdf> vultraz: maybe you shoudl make a pr o i can llook at code
20150602 17:12:56< vultraz> pl
20150602 17:12:58< vultraz> ok*
20150602 17:13:13< gfgtdf> vultraz: actualy i'm surprised that share_view = no  has even any effect
20150602 17:13:36< vultraz> well it seems share_maps relied on share_view being false
20150602 17:13:37< gfgtdf> vultraz: ah no
20150602 17:13:41< vultraz> and it defaulted to true
20150602 17:13:46< vultraz> so it prevented maps from working
20150602 17:13:50< gfgtdf> vultraz: yes becasue of thos code: res["share_view"] =  res["share_view"].to_bool(true);
20150602 17:13:59< gfgtdf> vultraz: which is part of spmp patch
20150602 17:14:13< gfgtdf> vultraz: https://github.com/wesnoth/wesnoth/blob/83eb7d37a4c472c2805ea9c84876ff644803f078/src/game_initialization/connect_engine.cpp#L1078
20150602 17:14:33< vultraz> yeah
20150602 17:14:43< gfgtdf> vultraz: usually share_view does not default to true (in sp)
20150602 17:15:29< vultraz> If we make it one key it kinda makes sense to do so
20150602 17:15:39< vultraz> Er wait
20150602 17:15:47< vultraz> no
20150602 17:15:49< vultraz> hm
20150602 17:16:29< vultraz> idk we should really keep the default the same in sp and mp
20150602 17:16:49< gfgtdf> vultraz: it say we make it default true then
20150602 17:17:01< gfgtdf> vultraz: in mp you usualy never want it to be false.
20150602 17:17:05< vultraz> ok
20150602 17:17:31< vultraz> lemme make sure stuff works fine with fog and ill make a PR
20150602 17:17:31< gfgtdf> vultraz: and in sp i'd also say it isnt that bads to have it by default on.
20150602 17:18:31-!- heirecka [~heirecka@exherbo/developer/heirecka] has quit [Excess Flood]
20150602 17:20:25-!- heirecka [~heirecka@j61898.servers.jiffybox.net] has joined #wesnoth-dev
20150602 17:20:25-!- heirecka [~heirecka@j61898.servers.jiffybox.net] has quit [Changing host]
20150602 17:20:25-!- heirecka [~heirecka@exherbo/developer/heirecka] has joined #wesnoth-dev
20150602 17:23:49-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20150602 17:24:56< vultraz> gfgtdf: https://github.com/wesnoth/wesnoth/pull/407
20150602 17:31:47-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20150602 17:33:13< gfgtdf> vultraz: ok but i dont think this will fix http://gna.org/bugs/?23460
20150602 17:33:46< vultraz> im not sure since that bug happens erratically 
20150602 17:34:42< gfgtdf> vultraz: hmm anyway i currently see no reasons agaonst merging
20150602 17:34:45< vultraz> but i just tested in a case with shroud and fog on for two allied sides with share_view on and the bars didn't draw over the shroud 
20150602 17:35:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150602 17:35:25< gfgtdf> vultraz: that bug only happens when teh ally side has share_view active but not fog.
20150602 17:35:43< gfgtdf> vultraz: maybe shadowm know usecases of share_maps=yes but share_view=no
20150602 17:35:49-!- Haudegen [~quassel@85.124.51.57] has joined #wesnoth-dev
20150602 17:36:18< gfgtdf> vultraz: so i suggest to ask him before merging.
20150602 17:39:27< vultraz> yeah the bars bug still happens 
20150602 17:40:44< vultraz> the main potential change for umc is that now any allied shrouded side must have share_view=no in order to place shroud over their visible hexes, even manually
20150602 17:41:22< vultraz> well, actually, not this change, the change just makes it simpler
20150602 17:41:38< vultraz> bc of the sp/mp thing, you would have needed both share_view and share_maps = no
20150602 17:41:46< vultraz> so this simplifies
20150602 17:41:59< vultraz> I guess it's another thing to decide if that's the behavior we want
20150602 17:44:49< vultraz> shadowm: could you comment on #407
20150602 17:44:52 * vultraz out
20150602 17:46:32< irker604> wesnoth: Charles Dang wesnoth:master de7f89bc1b0e / src/game_initialization/multiplayer.cpp: Removed an unused variable http://git.io/vkQS6
20150602 17:46:46< gfgtdf> vultraz: also note that share_view shoudl onl have an effect if the team used shroud or fog which default ot false. So im most cases sp devs dont neeed to do anything
20150602 17:47:06< gfgtdf> vultraz: why you think that variable was unused ?
20150602 17:47:49-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20150602 17:48:32< gfgtdf> vultraz: i would assume that shadowm didnt put that variable there if it didnt do anything.
20150602 17:57:54-!- yann_ is now known as yann
20150602 18:04:40-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 18:09:46-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 264 seconds]
20150602 18:16:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20150602 18:19:42-!- gfgtdf [~chatzilla@f054144237.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
20150602 18:21:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150602 18:40:18-!- Kwandulin [~Miranda@p5B009CB1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20150602 19:24:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20150602 19:33:54-!- ancestral [~ancestral@52.sub-70-197-225.myvzw.com] has joined #wesnoth-dev
20150602 19:48:59-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 19:51:04-!- kex [~kex@31.11.67.182] has quit [Read error: Connection reset by peer]
20150602 19:51:26-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 19:56:50-!- Kwandulin [~Miranda@p5B009CB1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20150602 19:57:30-!- ancestral [~ancestral@52.sub-70-197-225.myvzw.com] has quit [Quit: i go nstuf kthxbai]
20150602 20:08:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20150602 20:15:20-!- horrowin1 [~Icedove@2a02:810a:8b00:5298:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20150602 20:29:49< shadowm> vultraz: Look at preferences::admin_authentication_reset's definition and tell me what you see.
20150602 20:31:22< shadowm> vultraz, gfgtdf: I'm afraid I've never really understood how share_view and share_maps work.
20150602 20:33:13< irker604> wesnoth: Ignacio R. Morelle wesnoth:master f09b875b2ce1 / src/game_initialization/multiplayer.cpp: Revert "Removed an unused variable" http://git.io/vk5e3
20150602 20:33:33-!- shadowm_desktop [~ignacio@186.10.6.32] has joined #wesnoth-dev
20150602 20:33:39-!- gfgtdf [~chatzilla@f054144237.adsl.alicedsl.de] has joined #wesnoth-dev
20150602 20:33:42-!- shadowm_desktop [~ignacio@186.10.6.32] has quit [Changing host]
20150602 20:33:42-!- shadowm_desktop [~ignacio@wesnoth/developer/shadowm] has joined #wesnoth-dev
20150602 20:39:05< shadowm> Maybe ask zookeeper?
20150602 20:39:20< zookeeper> hmh?
20150602 20:39:50< zookeeper> concise summary needed
20150602 20:41:02 * shadowm doesn't know what they are trying to do either.
20150602 20:41:33< gfgtdf> zookeeper: we want to remove share_maps memeber from [side]
20150602 20:42:53< zookeeper> so there'd be no longer a way to make only one of fog or shroud be shared? it'd always be both?
20150602 20:43:09< gfgtdf> zookeeper: yes
20150602 20:43:36< gfgtdf> zookeeper: actualyl iirc teh current options are 'share both' 'share shroud' 'share nothing'
20150602 20:44:09< zookeeper> okay... but why?
20150602 20:45:18< zookeeper> the current options rather make sense; sharing shroud but not fog is a sensible choice in some situations, whereas sharing fog but not shroud would be very weird
20150602 20:45:46< gfgtdf> zookeeper: vultraz says it fixes http://gna.org/bugs/?23458 and i dont really understand te current code espacialy the code about "delayed map sharing"
20150602 20:46:01< gfgtdf> zookeeper: you can tell my any such situation ?
20150602 20:47:34< zookeeper> where sharing shroud but not fog makes sense?
20150602 20:47:53< gfgtdf> zookeeper: yes
20150602 20:48:43< gfgtdf> zookeeper: also you know somethign about tis "delayed map sharing" as commented here: https://github.com/wesnoth/wesnoth/blob/master/src/play_controller.cpp#L513 `?
20150602 20:48:47< zookeeper> well, i don't know if there are any such uses in mainline
20150602 20:49:30< gfgtdf> zookeeper: umc is ok too :)
20150602 20:50:17-!- lucebac [~lucebac@unaffiliated/lucebac] has joined #wesnoth-dev
20150602 20:50:26-!- lucebac [~lucebac@unaffiliated/lucebac] has left #wesnoth-dev ["Part"]
20150602 20:50:34< zookeeper> well any situation where you want an ally (maybe AI) to be able to scout the map for you but not provide fog-piercing vision
20150602 20:51:09< zookeeper> sure it's probably a pretty rare case, since you likely wouldn't use that in co-op scenarios
20150602 20:51:24< zookeeper> unless it was a co-op with some kind of competitive twist to it so you might want to hide information
20150602 20:52:46< gfgtdf> zookeeper: you think that there is currently an addon on 1.10,1.12 or 1.13 server that used shared_maps?
20150602 20:52:54< gfgtdf> uses*
20150602 20:53:25< zookeeper> no idea, i'm not very knowledgeable about UMC, especially the kind which might use that
20150602 20:54:59< gfgtdf> zookeeper: you know somethign about this "delayed map sharing" as commented here: https://github.com/wesnoth/wesnoth/blob/master/src/play_controller.cpp#L513 `?
20150602 20:57:12< zookeeper> not really
20150602 20:59:32< gfgtdf> zookeeper: hm ok
20150602 21:00:07< gfgtdf> zookeeper: share_maps works just liek share_view right ? you get teh shroud updates at teh same time as th original player?
20150602 21:00:10< zookeeper> i take it that copy_ally_shroud doesn't lead to an explanation?
20150602 21:01:17< gfgtdf> zookeeper: no not really. IT seems liek it updates shoud at the beginning of teh turn, but i always thought that share_map updates your shrodu at teh same time as teh original players shroud
20150602 21:01:24< zookeeper> yes, i'd believe that's how they're supposed to work... unless you have DSU on
20150602 21:01:27< gfgtdf> zookeeper: so taht call sees to be useless to me
20150602 21:02:26< zookeeper> "delayed map sharing" considering the context obviously seems like something intended to update map sharing only at turn start/end instead of when moves etc happen
20150602 21:02:43< zookeeper> but i don't really know what sense such a mode would make
20150602 21:03:16< zookeeper> unless it's somehow related to DSU or whiteboard, i don't know
20150602 21:03:42< gfgtdf> zookeeper: yes but it also controlled by share_maps and since share maps already update your shroud then teh enemy moves i dont see the point of that function.
20150602 21:04:48< zookeeper> well, if it's some really ancient code then you could ask sirp
20150602 21:04:56< zookeeper> seems like a possibility
20150602 21:05:16< zookeeper> i mean, the functionality, not necessarily the exact code itself
20150602 21:05:37< gfgtdf> zookeeper: https://github.com/wesnoth/wesnoth/commit/0b09efaefa5ea76622de71a0e2e10a9e9dfc35c4
20150602 21:06:20< gfgtdf> zookeeper: you have an opinion on http://gna.org/bugs/?23600 ? Curretnyl it is possible to undo moves that happened before teh last shroud update even if they did not clear any shroud  but it still can cause OOS sometimes you see a reason against removing that possibility ?
20150602 21:07:16-!- hay207 [~haythamme@41.34.13.94] has joined #wesnoth-dev
20150602 21:07:41< zookeeper> uh, will have to stare at that description for a while...
20150602 21:07:47< irker604> wesnoth: gfgtdf wesnoth:master a3d1b17d1a07 / src/unit.cpp: maybe fix allied bars drawn over shroud http://git.io/vk53W
20150602 21:08:59< gfgtdf> zookeeper: that commit mesage or ym text ?
20150602 21:09:15< zookeeper> bug report
20150602 21:09:21< zookeeper> i get it now
20150602 21:09:43< zookeeper> well i've always assumed that if undo gets invalidated, your whole undo stack is gone
20150602 21:11:12< gfgtdf> zookeeper: ok
20150602 21:11:29< zookeeper> so based on that i'd be inclined to say that i don't have any objections against removing that possibility
20150602 21:11:51< zookeeper> is the ability to do that a new addition?
20150602 21:12:02< gfgtdf> zookeeper: to whcih addition ?
20150602 21:12:31< gfgtdf> vultraz: please test if this commit ^ fixes http://gna.org/bugs/?23460
20150602 21:12:39< zookeeper> the ability to undo U2's move
20150602 21:13:41< gfgtdf> zookeeper: hm i am not sure, jamit refactore teh undo code in ~1.11.2 idk whether it was possible in 1.10
20150602 21:13:58< zookeeper> i'd find it odd if it was always possible and i just never noticed
20150602 21:14:29< zookeeper> so i was wondering whether the undo-related work that has happened in past years would have introduced it either accidentally or deliberately
20150602 21:15:07< zookeeper> i wouldn't be surprised if there was a feature request to allow U2's move to be undoable (because it didn't reveal any information) and it was implemented and no one thought of this consequence 
20150602 21:19:20< gfgtdf> hm ok
20150602 21:19:51< shadowm> gfgtdf: Will team.fogged(loc) return false for a location that's not fogged due to sharing maps/views?
20150602 21:20:35< gfgtdf> shadowm: i think yes
20150602 21:24:36< gfgtdf> shadowm: why you ask ?
20150602 21:24:50< shadowm> Because of a3d1b17d1a07 above, of course.
20150602 21:31:55< gfgtdf> shikadibot: seen Elvish_Hunter
20150602 21:31:55< shikadibot> gfgtdf: The person with the nick Elvish_Hunter last spoke 12h 4m ago.  11h 19m ago they left with the message: Quit: Ciao!
20150602 21:40:51-!- horrowin1 [~Icedove@2a02:810a:8b00:5298:21b:fcff:fee3:c3ff] has quit [Quit: horrowin1]
20150602 21:44:59< gfgtdf> shadowm: iirc the reason why that code previousls did those checks is related to whiboard units of allies in mp.
20150602 21:45:49-!- travis-ci [~travis-ci@ec2-54-159-109-129.compute-1.amazonaws.com] has joined #wesnoth-dev
20150602 21:45:50< travis-ci> gfgtdf/wesnoth-old#467 (AI-SDL_RWops_2 - 3de087b : Alexander van Gessel): The build has errored.
20150602 21:45:50< travis-ci> Build details : http://travis-ci.org/gfgtdf/wesnoth-old/builds/65155028
20150602 21:45:50-!- travis-ci [~travis-ci@ec2-54-159-109-129.compute-1.amazonaws.com] has left #wesnoth-dev []
20150602 21:48:48< shadowm> Will it still work with those?
20150602 21:50:03< irker604> wesnoth: Ignacio R. Morelle wesnoth:master f735f7f28344 / src/game_initialization/create_engine.cpp: mp: Add missing fields in constructor initializer list http://git.io/vk5zh
20150602 21:50:57< gfgtdf> shadowm: i didnt test but i assumed that if you have shared vision=yes then fogged will return 'false' anyway.
20150602 21:51:22< gfgtdf> shadowm: maybe it was related to some cases where someone planned to move a unit to a fiend teh is currently fogged
20150602 21:51:27< gfgtdf> shadowm: i dodn ttest taht case
20150602 21:52:18< gfgtdf> shadowm: but i thought that bug http://gna.org/bugs/?23460 is more important than that rather rare case.
20150602 21:53:27< shadowm> Sure, this just reaffirms the general perception that nobody cares about the whiteboard. :p
20150602 21:55:45< gfgtdf> shadowm: well I didnt say the whiteboard is bad. I just say that you usualy wouldnt plan to move your units under shroud since you have really no information whether there are enmies
20150602 21:57:28< gfgtdf> shadowm: actualyl i just got an idea how that can be fixed
20150602 21:58:14< irker604> wesnoth: gfgtdf wesnoth:master aab8c0003909 / src/unit.cpp: allied planned unit are always visible under fog http://git.io/vk5ay
20150602 21:58:19< gfgtdf> shadowm: ^
20150602 21:59:08< shadowm> Hm, on-map fake units aren't related to [move_unit_fake], right?
20150602 21:59:17-!- travis-ci [~travis-ci@ec2-23-22-177-24.compute-1.amazonaws.com] has joined #wesnoth-dev
20150602 21:59:18< travis-ci> wesnoth/wesnoth#6555 (hide_all_overlays - f1bca97 : Charles Dang): The build has errored.
20150602 21:59:18< travis-ci> Build details : http://travis-ci.org/wesnoth/wesnoth/builds/65156019
20150602 21:59:18-!- travis-ci [~travis-ci@ec2-23-22-177-24.compute-1.amazonaws.com] has left #wesnoth-dev []
20150602 22:01:16< shadowm> matthiaskrgr: I was a bit too hasty in my original assessment. 1.12 doesn't have the faulty code.
20150602 22:01:41< shadowm> So it's not *that* bad, it's just 1.13.0.
20150602 22:01:51< matthiaskrgr> ok 
20150602 22:02:39< gfgtdf> shadowm: which bug you talk about ?
20150602 22:02:50< matthiaskrgr> 23606 
20150602 22:03:22< shadowm> I was going to blame a GSoC student but it turns out it's iceiceice's code.
20150602 22:04:13< shadowm> I don't blame him for not realizing that the pointer returned by util::md5 doesn't refer to a null-terminated string, the interface we have for MD5 by all means doesn't belong in Wesnoth.
20150602 22:05:44< shadowm> So I guess I'll just request the actual text form for the affected code and decide how to replace our MD5 implementation at a later time.
20150602 22:07:50-!- mjs-de [~mjs-de@f048199213.adsl.alicedsl.de] has quit [Remote host closed the connection]
20150602 22:08:31< shadowm> Not to mention that it's possible to do really bad things with MD5::raw_digest()'s return value if it's called early.
20150602 22:11:18-!- gfgtdf_ [~chatzilla@f054175140.adsl.alicedsl.de] has joined #wesnoth-dev
20150602 22:11:21-!- gfgtdf_ [~chatzilla@f054175140.adsl.alicedsl.de] has quit [Client Quit]
20150602 22:12:18< shadowm> ld using 2 GiB of RAM.
20150602 22:12:31< matthiaskrgr> yeah, it's a lot with ASAN 
20150602 22:12:31< shadowm> Debug builds.
20150602 22:12:40< matthiaskrgr> the binary will be around one GB :) 
20150602 22:12:49< matthiaskrgr> (if you use -g3 with asan ) 
20150602 22:12:53< shadowm> shadowm@nanacore:~/src/wesnoth/build-gcc5% du -h wesnoth
20150602 22:12:58< shadowm> 436M    wesnoth
20150602 22:13:19< shadowm> It's only around 3 times larger than a regular debug build.
20150602 22:13:23-!- gfgtdf [~chatzilla@f054144237.adsl.alicedsl.de] has quit [Ping timeout: 264 seconds]
20150602 22:13:24< matthiaskrgr> 979M here 
20150602 22:13:49< shadowm> Hm, weird.
20150602 22:13:56< matthiaskrgr> oh wait
20150602 22:14:01< matthiaskrgr> I also build UBsan into it 
20150602 22:14:08< matthiaskrgr> so it is ASAN + UBSAN + g3 
20150602 22:14:40< shadowm>  CXX_FLAGS_USER                   -fsanitize=address,undefined -g3 -fno-omit-frame-pointer
20150602 22:14:47< shadowm> That, right?
20150602 22:14:56< matthiaskrgr> yeah, looks good
20150602 22:15:10< shadowm> THat's what yields a 436M executable here.
20150602 22:15:24< shadowm> Using CMAKE_BUILD_TYPE=Debug, which selects -O0.
20150602 22:17:24-!- Greg-Boggs [~quassel@173.240.247.62] has quit [Remote host closed the connection]
20150602 22:24:12< irker604> wesnoth: Ignacio R. Morelle wesnoth:master 7b9292355547 / / (4 files in 3 dirs): Fix unbound memory read (bug #23606) http://git.io/vk5XG
20150602 22:25:54< shadowm> The performance impact of this address sanitizer thing isn't much (here?) compared to e.g. valgrind's memcheck.
20150602 22:26:38< matthiaskrgr> yeah, the official docs say it's only 2-3 times slower while valgrind is 10 times slower
20150602 22:26:43< matthiaskrgr> or something like that 
20150602 22:27:01< matthiaskrgr> and you can also combine it with -O2 etc, if you want 
20150602 22:27:17< matthiaskrgr> but it may not find everything that valgrind does
20150602 22:28:28< shadowm> Yeah, I imagine not.
20150602 22:36:59< irker604> wesnoth: Ignacio R. Morelle wesnoth:master 81efa398c113 / src/md5.cpp: md5: Return a NULL pointer if MD5::raw_digest() is called early http://git.io/vk5yR
20150602 22:45:44-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Quit: tomreyn]
20150602 22:51:15-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20150602 22:55:06< vultraz> shadowm: sorry about that... shouldn't have just randomly followed the compiler warning
20150602 22:57:05< shadowm> Your compiler complained?
20150602 22:59:04< vultraz> Yes
20150602 22:59:13< shadowm> tdm gcc 4.5.something, right?
20150602 23:00:07< vultraz> .2, yes
20150602 23:01:11< shadowm> You understand what the variable does, right?
20150602 23:03:13< vultraz> Um.....
20150602 23:04:30< shadowm> Consider this part of your C++ training.
20150602 23:07:40< vultraz> set authenticated to false?
20150602 23:07:53< shadowm> Yes, but when and why?
20150602 23:08:39< vultraz> when you start a client so you start unauthenticated?
20150602 23:08:45< shadowm> No.
20150602 23:08:49-!- kex [~kex@31.11.67.182] has quit [Remote host closed the connection]
20150602 23:09:08< shadowm> Given a class foo, the method foo::~foo() is the class destructor.
20150602 23:09:45< shadowm> ~foo() gets called when an object of type foo goes out of scope or operator delete is invoked on it, just prior to foo's memory being released.
20150602 23:09:50-!- kex [~kex@31.11.67.182] has joined #wesnoth-dev
20150602 23:10:31< shadowm> When an exception is thrown, stack unwinding takes place and class destructors are called in LIFO order.
20150602 23:11:38< shadowm> Using a class destructor to ensure a cleanup operation takes place (resetting that flag, in this case) is an important part of the RAII idiom.
20150602 23:12:04< shadowm> That is, both in the event of a function returning normally, and an exception being thrown within that function or one of its callees.
20150602 23:13:48< irker604> wesnoth: Ignacio R. Morelle wesnoth:master d7734d8b02bc / src/ (game_preferences.cpp game_preferences.hpp): Explicitly define admin_authentication_reset's ctor out of line http://git.io/vk5br
20150602 23:13:49< shadowm> Anyway, this commit should fix your warning.
20150602 23:14:35-!- hay207 [~haythamme@41.34.13.94] has quit [Ping timeout: 264 seconds]
20150602 23:14:49-!- kex [~kex@31.11.67.182] has quit [Ping timeout: 264 seconds]
20150602 23:17:35< vultraz> I see
20150602 23:20:52< vultraz> gfgtdf: yes, that seems to fix it
20150602 23:27:02< vultraz> gfgtdf: not sure why my commit fails filter_vision :/
20150602 23:33:15-!- gfgtdf [~chatzilla@f054155064.adsl.alicedsl.de] has joined #wesnoth-dev
20150602 23:40:26< vultraz> gfgtdf: is there a way to see which specific test section failed?
20150602 23:41:31< gfgtdf> vultraz: i posted which test failed
20150602 23:41:38< gfgtdf> vultraz: i even gavew a link to the file
20150602 23:42:17< vultraz> no i mean
20150602 23:42:22< gfgtdf> vultraz: do you know why teh patch fixes your bug?
20150602 23:42:31< vultraz> that test has abunch of things it tests
20150602 23:43:31< gfgtdf> vultraz: y it is not clear which exactly fails
20150602 23:44:26< shadowm> Link?
20150602 23:44:59< gfgtdf> shadowm: ?
20150602 23:45:25< vultraz> gfgtdf: technically it doesn't "fix" it, since as I said the original bug (that being that hexes visible by allied sides withOUT shroud could not be shrouded) seemed to have been randomly fixed somewhere.  The issue then became that allied sides with shroud could not be shrouded without BOTH share_view AND share_maps = no. So this patch merges those two and makes it simpler
20150602 23:45:48< shadowm> You are trying to determine which test of a bunch failed in some context.
20150602 23:46:19< vultraz> The behavior we have now is that "any allied shroud without shroud can be shrouded", and "any allied side WITH shroud may not be shrouded unless share_view=no"
20150602 23:46:20< shadowm> So I'm curious about the context from which you concluded that a test is failing.
20150602 23:46:26< vultraz> now after my patch*
20150602 23:46:35< gfgtdf> shadowm: the travis build said test failed
20150602 23:46:41< vultraz> shadowm: travis said so
20150602 23:46:53< shadowm> This build? http://travis-ci.org/gfgtdf/wesnoth-old/builds/65155028
20150602 23:47:16< gfgtdf> shadowm: no tha is a completeley unrelated build
20150602 23:47:18< shadowm> Or this build I just noticed? http://travis-ci.org/wesnoth/wesnoth/builds/65156019
20150602 23:47:35< gfgtdf> shadowm: thats also a unrelated bild
20150602 23:47:40< gfgtdf> build*
20150602 23:48:00< gfgtdf> shadowm: i think its this: https://travis-ci.org/wesnoth/wesnoth/builds/65119875
20150602 23:48:11< vultraz> https://travis-ci.org/wesnoth/wesnoth/builds/65119875
20150602 23:49:46< shadowm> timeout --kill-after=21 20 ./wesnoth -u filter_vision --validcache --log-strict=warning --noaddons 
20150602 23:49:50< shadowm> This WML test?
20150602 23:50:11< shadowm> The C++ test suite and all other WML tests pass AFAICT.
20150602 23:50:20< gfgtdf> shadowm: yes teh wml test
20150602 23:51:16< shadowm> Do you want me to check out the PR and try running the test?
20150602 23:51:34< shadowm> vultraz: 
20150602 23:51:46< vultraz> sure
20150602 23:52:15< vultraz> Since I'm really not sure why it would cause it to fail
20150602 23:52:21< gfgtdf> vultraz: since you changes teh default value for share_view to true, you could try to add share_view=no in all sides of the test
20150602 23:52:59< vultraz> oh
20150602 23:53:01< vultraz> hm
20150602 23:53:11< vultraz> we did agree true was a good default
20150602 23:53:47< gfgtdf> vultraz: yes sure, but stil teh test needs to be adjusted
20150602 23:54:20< gfgtdf> vultraz: you are sure teh you couldnt previous sidable taht by just using "share_view=no" ?
20150602 23:54:38< vultraz> ?
20150602 23:55:01< gfgtdf> vultraz: you said that you previously needed share_view=no and share_maps =no
20150602 23:55:31< vultraz> yeah. in 1.12 just share_maps worked
20150602 23:55:39< vultraz> share_maps=no*
20150602 23:55:40< gfgtdf> vultraz: ah right share_maps previously defaulted to tue.
20150602 23:56:05< vultraz> yeah but bc of the sp/mp thing share_maps gets overridden by share_view, meaning you needed both
20150602 23:56:08< vultraz> set to no
20150602 23:56:14< gfgtdf> vultraz: y
20150602 23:57:24< shadowm> http://pastebin.com/tgcXwMWs
20150602 23:58:09< vultraz> hm I just noticed I set share_view to cfg["share_view"].to_bool(true) in both team.cpp and connect_engine.cpp now
20150602 23:58:34< shadowm> The patch I used to obtain this info: https://dl.dropboxusercontent.com/u/21371130/poop/wassert.patch
20150602 23:59:02< gfgtdf> vultraz: yes you can removeteh one in connecT_engin if you want
20150602 23:59:13< gfgtdf> vultraz: but its not that important
20150602 23:59:19< vultraz> ok
20150602 23:59:52< vultraz> I can do that later
--- Log closed Wed Jun 03 00:00:01 2015