--- Log opened Fri Apr 18 00:00:08 2014
20140418 00:06:26< irker233> wesnoth: gfgtdf wesnoth:1.12 bc7892385ca1 / src/scripting/lua.cpp: fix a segfault in lua_function in SUF http://git.io/rdq6MA
20140418 00:06:28< irker233> wesnoth: gfgtdf wesnoth:1.12 723139d093e2 / src/synced_commands.cpp: fix wml menu events http://git.io/bLAc9g
20140418 00:06:29< irker233> wesnoth: gfgtdf wesnoth:1.12 5f955447ba5c / changelog: update changelog http://git.io/lJlSLg
20140418 00:17:48-!- ancestral [~ancestral@17.114.44.242] has quit [Quit: ancestral]
20140418 00:24:00-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140418 00:24:26< iceiceice> gfgtdf: 
20140418 00:24:35< iceiceice> maybe just output a warning on some channel?
20140418 00:24:40< iceiceice> it sounds like you only want it for debugging
20140418 00:25:34< iceiceice> i guess you could make an assert that happens only if debug mode is on? but idk if that is such a good idea, i'm actually not sure if i've heard of someone doing that in a serious project
20140418 00:26:25< gfgtdf> iceiceice: you mean wesnoths debug mode ?
20140418 00:27:32< iceiceice> yeah i mean, its at least a possibility you could do "assert(!game_config::debug)", 
20140418 00:27:46< iceiceice> since presumably you are doing testing with debug mode on?
20140418 00:28:03< iceiceice> probly not a good idea for the release though, i only mention as a possibility
20140418 00:28:36< iceiceice> if you arent sure if its a good or bad thing then it sounds like you just need to test more to be sure, or make precautions to handle it later
20140418 00:28:42< gfgtdf> iceiceice: no in nromal testign i don't compile in debug mode an i dont use wesnoths debug mode neigher
20140418 00:28:43< gfgtdf> normal
20140418 00:28:51< iceiceice> oh ok
20140418 00:31:35-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140418 00:38:11-!- aquileia [6dc00d61@gateway/web/freenode/ip.109.192.13.97] has quit [Quit: Page closed]
20140418 01:11:15-!- Gallaecio [~quassel@84.120.115.132.dyn.user.ono.com] has quit [Ping timeout: 240 seconds]
20140418 01:11:51-!- Gallaecio [~quassel@84.120.115.132.dyn.user.ono.com] has joined #wesnoth-dev
20140418 01:12:30-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140418 01:21:33-!- sachith500 [~kvirc@112.134.81.230] has joined #wesnoth-dev
20140418 01:22:54-!- sachith500 [~kvirc@112.134.81.230] has quit [Read error: Connection reset by peer]
20140418 01:23:10-!- sachith500 [~kvirc@112.134.81.230] has joined #wesnoth-dev
20140418 01:27:01-!- gfgtdf [~chatzilla@e177166210.adsl.alicedsl.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517]]
20140418 01:27:44-!- Gallaecio [~quassel@84.120.115.132.dyn.user.ono.com] has quit [Ping timeout: 258 seconds]
20140418 01:29:19-!- sachith500 [~kvirc@112.134.81.230] has quit [Read error: Connection reset by peer]
20140418 01:29:35-!- sachith500 [~kvirc@112.134.81.230] has joined #wesnoth-dev
20140418 01:36:34-!- Gallaecio [~quassel@84.120.115.132.dyn.user.ono.com] has joined #wesnoth-dev
20140418 01:48:58-!- sachith500 [~kvirc@112.134.81.230] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140418 01:49:58-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 258 seconds]
20140418 01:53:02-!- happygrue [~happygrue@2601:6:4380:7df:cc36:5a9:db92:78cb] has joined #wesnoth-dev
20140418 01:53:02-!- happygrue [~happygrue@2601:6:4380:7df:cc36:5a9:db92:78cb] has quit [Changing host]
20140418 01:53:02-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140418 01:53:13-!- ancestral [~ancestral@12.23.74.29] has joined #wesnoth-dev
20140418 02:15:37-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20140418 02:17:58-!- Ivanovic_ [~ivanovic@frnk-5f74d323.pool.mediaWays.net] has joined #wesnoth-dev
20140418 02:20:43-!- Ivanovic_ [~ivanovic@frnk-5f74d323.pool.mediaWays.net] has quit [Changing host]
20140418 02:20:43-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20140418 02:20:58-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 276 seconds]
20140418 02:22:07-!- Ivanovic_ is now known as Ivanovic
20140418 02:24:05-!- happygrue [~happygrue@wesnoth/developer/wintermute] has quit [Ping timeout: 258 seconds]
20140418 02:25:14-!- Aishiko_laptop [~unknown@2606:a000:bcc1:2b00:226:5eff:fe65:125c] has quit [Ping timeout: 258 seconds]
20140418 02:43:13-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Ping timeout: 245 seconds]
20140418 02:55:22-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140418 03:05:09-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 265 seconds]
20140418 03:11:48-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140418 03:32:39< Aishiko> mordante the reason that I didn't get an error was I wasn't checking png0 but bmp which was successfully imported
20140418 03:43:20-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Ping timeout: 265 seconds]
20140418 03:45:41-!- _8680_ [~8680@2002:4404:712c:0:1854:850c:54be:ca99] has quit [Ping timeout: 246 seconds]
20140418 03:46:44-!- _8680_ [~8680@2002:4404:712c:0:1d95:e434:7377:cff6] has joined #wesnoth-dev
20140418 03:57:07-!- irker233 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140418 04:03:51-!- irker136 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140418 04:03:51< irker136> wesnoth: mattsc wesnoth:master f6cdd851820e / data/ai/lua/ (ai_helper.lua battle_calcs.lua): AI helper functions: code cleanup, first pass http://git.io/Gbrj5g
20140418 04:03:51< irker136> wesnoth: mattsc wesnoth:master 19eff08fd760 / data/ai/lua/ai_helper.lua: Fix a typo http://git.io/Wx5Irg
20140418 04:03:52< irker136> wesnoth: mattsc wesnoth:master e87240c67f84 / data/ai/lua/battle_calcs.lua: battle_calcs.lua: avoid using formula= in SUFs http://git.io/Qnu67g
20140418 04:03:53< irker136> wesnoth: mattsc wesnoth:master 9701a724a861 / data/ai/lua/ai_helper.lua: ai_helper.lua: avoid using table.remove http://git.io/4bYk9A
20140418 04:03:54< irker136> wesnoth: mattsc wesnoth:master 9d440fac8e81 / data/ai/micro_ais/scenarios/protect_unit.cfg: Protect Unit MAI test scenario: use fight_on_without_leader=yes http://git.io/F4JpJQ
20140418 04:05:36< irker136> wesnoth: mattsc wesnoth:1.12 fe49356eba1a / data/ai/lua/ (ai_helper.lua battle_calcs.lua): AI helper functions: code cleanup, first pass http://git.io/RwLGmQ
20140418 04:05:38< irker136> wesnoth: mattsc wesnoth:1.12 7d88f9211a29 / data/ai/lua/ai_helper.lua: Fix a typo http://git.io/gNnBKA
20140418 04:05:40< irker136> wesnoth: mattsc wesnoth:1.12 f7049e114002 / data/ai/lua/battle_calcs.lua: battle_calcs.lua: avoid using formula= in SUFs http://git.io/x27ogA
20140418 04:05:42< irker136> wesnoth: mattsc wesnoth:1.12 cff3b5a35d93 / data/ai/lua/ai_helper.lua: ai_helper.lua: avoid using table.remove http://git.io/l6wluQ
20140418 04:05:44< irker136> wesnoth: mattsc wesnoth:1.12 14e55fc14c0f / data/ai/micro_ais/scenarios/protect_unit.cfg: Protect Unit MAI test scenario: use fight_on_without_leader=yes http://git.io/yltwcg
20140418 04:25:36-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140418 04:51:49-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140418 04:52:16-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140418 05:05:23-!- Gambit [~derek@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20140418 05:40:10-!- Sulfur [~Miranda@p5B327882.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140418 05:50:02-!- neXyon [~neXyon@178-191-221-44.adsl.highway.telekom.at] has joined #wesnoth-dev
20140418 05:56:28-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140418 05:56:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20140418 05:59:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20140418 06:40:18-!- neXyon [~neXyon@178-191-221-44.adsl.highway.telekom.at] has quit [Quit: bye]
20140418 08:10:39-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140418 08:50:27-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140418 08:53:10-!- Jetrel_ [~Jetrel@c-75-73-180-126.hsd1.mn.comcast.net] has joined #wesnoth-dev
20140418 08:55:43-!- Jetrel [~Jetrel@c-75-73-180-126.hsd1.mn.comcast.net] has quit [Ping timeout: 245 seconds]
20140418 09:05:51-!- Bodhi-Baum [~Bodhi@dslb-084-063-063-211.pools.arcor-ip.net] has joined #wesnoth-dev
20140418 09:28:09-!- molgrum [~molgrum@212.85.89.43] has quit [Quit: Lämnar]
20140418 09:31:56-!- Bodhi-Baum [~Bodhi@dslb-084-063-063-211.pools.arcor-ip.net] has quit [Quit: Verlassend]
20140418 09:42:19-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Ping timeout: 276 seconds]
20140418 09:46:41-!- Sulfur [~Miranda@p5B327882.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20140418 10:04:41-!- trademark_ [~trademark@nsg93-8-88-175-59-164.fbx.proxad.net] has quit [Ping timeout: 265 seconds]
20140418 10:06:20< stikonas> tried to go to https://wiki.wesnoth.org/Project, it didn't work. Now firefox remembered this https and refuses to open http...
20140418 10:14:49-!- ancestral [~ancestral@12.23.74.29] has quit [Quit: i go nstuf kthxbai]
20140418 10:18:12-!- bagzie [~bag@85-76-138-124-nat.elisa-mobile.fi] has joined #wesnoth-dev
20140418 10:29:22-!- ykanarev [~ykanarev@78.81.70.234] has joined #wesnoth-dev
20140418 10:29:22-!- ykanarev [~ykanarev@78.81.70.234] has quit [Client Quit]
20140418 10:30:52-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20140418 10:36:57-!- EdB [~edb@37.160.105.93] has joined #wesnoth-dev
20140418 10:39:23-!- Sulfur [~Miranda@p5B327882.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140418 10:46:38< cib0> Wow, I've invested hours debugging and bisecting to narrow this bug down to a commit range as much as possible, and it still got marked invalid without nearly so much investigation, because "your WML must be doing something wrong, so if it worked before and now it doesn't, it's not my problem". I feel tempted to quote Linus..
20140418 10:57:19-!- irker136 [~irker@fehu.ai0867.net] has quit [Quit: transmission timeout]
20140418 11:03:03-!- Gambit [~derek@wesnoth/developer/grickit] has joined #wesnoth-dev
20140418 11:06:42< AI0867> cib0: bug #?
20140418 11:08:33< zookeeper> newest
20140418 11:42:58-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140418 11:44:31< cib0> Oh connection broke without my noticing..
20140418 11:44:36< cib0> LOG_NG << "Added unit " << un->id() << ", " << un->name() << "\n";
20140418 11:44:41< cib0> Where can I view these logs?
20140418 11:45:15< cib0> There seems to be a --log-level parameter, but it expects a log domain, and LOG_NG doesn't seem to be specific to any domain..
20140418 11:46:04< cib0> Wait nevermind, log_engine is the domain.
20140418 11:47:33< cib0> That's pretty cool, lots of debug info that'll be helpful in tracking down this problem.
20140418 11:52:52-!- unitraxx [~Thunderbi@unaffiliated/unitraxx] has joined #wesnoth-dev
20140418 11:55:11< cib0> This is.. pretty curious.
20140418 11:55:48< cib0> It's triggering the scenario end code to store the unit in the recall list. Then, start of next scenario, the unit has disappeared from the save entirely.
20140418 11:55:58< cib0> If this isn't a bug I don't know what is.
20140418 11:56:52-!- unitraxx [~Thunderbi@unaffiliated/unitraxx] has left #wesnoth-dev []
20140418 12:02:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140418 12:13:11-!- kex [~kex@89.205.75.19] has quit [Remote host closed the connection]
20140418 12:13:28-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140418 12:13:46-!- kex [~kex@89.205.75.19] has joined #wesnoth-dev
20140418 12:15:19< AI0867> cib0: could you strip down the add-on a bit more? gfgtdf makes a valid point that there are far too many things happening to easily debug this
20140418 12:15:25< cib0> Does anyone happen to know how unit carryover from one scenario to the next works?
20140418 12:15:54< AI0867> someone refactored that last year or something?
20140418 12:16:35< AI0867> gamestatus.hpp provides a carryover class
20140418 12:18:15-!- kex [~kex@89.205.75.19] has quit [Ping timeout: 258 seconds]
20140418 12:19:59< cib0> AI0867, I wouldn't have any easier time breaking the problem down to the smallest possible example than anyone else would.
20140418 12:20:28< cib0> So, if I'm forced to do the hard work anyway, I'll just do the sensible thing and debug it from within the game.
20140418 12:21:18< cib0> After all, it's already very clear what's going wrong, I'm just not yet sure why.
20140418 12:28:46-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140418 12:29:57< cib0> And thanks, that carryover class was what I was looking for.
20140418 12:32:15-!- juanmi91 [51250737@gateway/web/freenode/ip.81.37.7.55] has joined #wesnoth-dev
20140418 12:34:24< juanmi91> mordante, can you give me SoC membership in your forum?
20140418 12:34:37< cib0> Well, this narrows it down.
20140418 12:35:12< cib0> Apparently carryover::update_carryover is never called on side 2, even though it's persistent.
20140418 12:35:28< cib0> But only if I use the right-click menu action, if I don't use it, then stuff is stored to side 2.
20140418 12:35:37< cib0> I'm expecting the cause to be hiarious.
20140418 12:40:31-!- juanmi91 [51250737@gateway/web/freenode/ip.81.37.7.55] has quit [Quit: Page closed]
20140418 12:43:51-!- EdB [~edb@37.160.105.93] has quit [Quit: Konversation terminated!]
20140418 12:55:15-!- Sulfur [~Miranda@p5B327882.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20140418 12:57:29< cib0> Hm, seems in the "bugged" case, it actually thinks the side has lost.. what..
20140418 13:00:36< cib0> Why on earth does using a menu action influence the team.info._lost flag..
20140418 13:03:25< Necrosporus> Which options are better for saving portraits in png? Interlacing adam7, bg color, gamma?
20140418 13:06:06-!- happygrue [~happygrue@2601:6:4380:7df:14e8:fa41:e76a:2728] has joined #wesnoth-dev
20140418 13:06:06-!- happygrue [~happygrue@2601:6:4380:7df:14e8:fa41:e76a:2728] has quit [Changing host]
20140418 13:06:06-!- happygrue [~happygrue@wesnoth/developer/wintermute] has joined #wesnoth-dev
20140418 13:07:37< AI0867> Necrosporus: no idea
20140418 13:08:03< AI0867> cib0: well, you're doing some dubious things regarding preload events and saving.
20140418 13:08:42-!- DCW1 [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has joined #wesnoth-dev
20140418 13:08:53< AI0867> the aim here is to provide a small slice of your add-on that still produces the bug
20140418 13:09:53-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 245 seconds]
20140418 13:15:06< cib0> AI0867: The bug was the opposite of what I thought. =P
20140418 13:15:33< cib0> My code is wrong, because units aren't supposed to carry over if there's no leader, unless fight_on_without_leader is set.
20140418 13:16:23< cib0> But there's a bug where check_victory isn't called if you end the scenario on turn 1, and so the team._info.lost flag isn't set, which makes the game think the side has a leader.
20140418 13:20:53-!- mjs-de [~mjs-de@p508CAD4E.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140418 13:22:33-!- Sulfur [~Miranda@p5B327882.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140418 13:28:30-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has joined #wesnoth-dev
20140418 13:31:18-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140418 13:45:08< cib0> It's really weird when you start a battle and some of your units are facing away from the enemy and your group.
20140418 13:45:26< AI0867> I think there's a pull request about that
20140418 13:47:44< AI0867> aquileia: I found the issue: http://forums.libsdl.org/viewtopic.php?t=8216&sid=fb58131c1bb6f4e14b1129e946d8f8bb
20140418 14:00:49< cib0> http://i.imgur.com/HWwAPXr.jpg
20140418 14:09:47-!- aquileia [6dc00d61@gateway/web/freenode/ip.109.192.13.97] has joined #wesnoth-dev
20140418 14:10:04< AI0867> aquileia: what's worse, I can't easily fix this, as the behaviour changed between 1.2.11 and 1.2.12
20140418 14:10:05-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20140418 14:10:18< AI0867> that is, in 1.2.11, SDL_mixer auto-freed everything
20140418 14:10:28< AI0867> in 1.2.12, it leaves the object alone by default
20140418 14:10:53< AI0867> maybe I should just bump our minimum SDL_mixer version
20140418 14:12:18< aquileia> AI0867: Is there any option to make it conditional?
20140418 14:16:46< aquileia> https://www.libsdl.org/projects/SDL_mixer/docs/SDL_mixer_8.html
20140418 14:16:49< AI0867> SDL_mixer's music loader? In 1.2.12, but not 1.2.11
20140418 14:17:05< AI0867> so I'll have to use version-based ifdef's anyway
20140418 14:17:54< AI0867> http://ai.ai0867.net/tmp/flip_free.diff
20140418 14:18:08< AI0867> that switches the behaviour, and should work with your 1.2.11
20140418 14:18:18< AI0867> in my 1.2.12, it'll cause memory leaks
20140418 14:18:26< AI0867> fairly minor ones, but still
20140418 14:18:50< Necrosporus> I guess, it's quite natural units are facing toward the last movement direction
20140418 14:19:01< AI0867> if you can confirm that that works, maybe you can then clear that and then upgrade to 1.2.12?
20140418 14:19:24< AI0867> and confirm that it's still gone?
20140418 14:19:25< aquileia> I'll do that
20140418 14:21:42< cib0> Yeah, the screenshot is from when the scenario started. Facing in the last moving direction is sensible.
20140418 14:21:58< cib0> I think on recruit/scenario start, all units should just face downward.
20140418 14:24:21-!- neXyon [~neXyon@178-191-221-44.adsl.highway.telekom.at] has joined #wesnoth-dev
20140418 14:30:08-!- gfgtdf [~chatzilla@e177166210.adsl.alicedsl.de] has joined #wesnoth-dev
20140418 14:33:26-!- zookeeper2 [~lmsnie@37.35.27.57] has joined #wesnoth-dev
20140418 14:33:35< zookeeper2> cib0, yeah, i think that'd be a good idea until the unlikely day when most units have north-facing frames as well, when it presumably wouldn't look so weird anymore.
20140418 14:33:37< zookeeper2> if someone needs the directions to be fully randomized, then it's trivial enough to do.
20140418 14:33:56-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Disconnected by services]
20140418 14:33:59-!- zookeeper2 is now known as zookeeper
20140418 14:34:01-!- zookeeper [~lmsnie@37.35.27.57] has quit [Changing host]
20140418 14:34:01-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20140418 14:35:13< gfgtdf> does any1 know ehy we have different functions check_victory and check_end_level ? 
20140418 14:39:13< gfgtdf> why*
20140418 14:39:40< AI0867> maybe check_end_level also checks for defeats?
20140418 14:39:41< AI0867> I don't know
20140418 14:42:04< cib0> check_victory calls check_end_level for one.
20140418 14:42:16< gfgtdf> AI0867: check_victory  checks for victory_when_enemies_defeated and calls check_end_level, which only chacks for endlevel i think
20140418 14:42:35< gfgtdf> but in which situation should we only do the later
20140418 14:42:40< gfgtdf> i cannot imagine
20140418 14:42:52-!- DCW1 [~Thunderbi@cpc66863-finc15-2-0-cust393.4-2.cable.virginm.net] has quit [Remote host closed the connection]
20140418 14:44:41< cib0> Apparently the checks aren't supposed to run when the scenario has already ended..
20140418 14:44:52-!- wesbot changed the topic of #wesnoth-dev to: string+feature freeze active on 1.12 | 233 bugs, 347 feature requests, 28 patches | Logs: http://irclogs.wesnoth.org | Alternate logs: http://wesnoth.debian.net | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20140418 14:45:08< cib0> But, at least the check for which sides have "lost", needs to run when the scenario ends either way. There's a logic/design error here somewhere.
20140418 14:46:16< cib0> (If you call check_victory on an ended scenario, it'll just call check_end_level which throws an exception and thus the rest of the function isn't called)
20140418 14:47:39< cib0> Probably factor out the function that updates the "lost" status and call that separately, both in the end_level WML trigger and in check_victory.
20140418 14:48:00< cib0> Want me to try that?
20140418 14:49:02-!- DHost [~Pcy@vps.plok.fr] has quit [Remote host closed the connection]
20140418 14:50:22< gfgtdf> cib0: hm maybe we can just move it to check_end_level, when check_victory calls that anyway.
20140418 14:51:55< cib0> Well, we could. The issue is we'd be collecting the same data twice, since check_victory re-uses the data that the lost check gathered.
20140418 14:55:15< cib0> I'll create a PR in a bit, you can suggest improvements then. =)
20140418 14:55:26-!- irker812 [~irker@fehu.ai0867.net] has joined #wesnoth-dev
20140418 14:55:26< irker812> wesnoth: mattsc wesnoth:master 5fc48b3e8887 / data/ai/micro_ais/cas/ (12 files): Micro AIs: don't check for specific value of move rating http://git.io/0JMd2g
20140418 14:56:13< irker812> wesnoth: mattsc wesnoth:1.12 1d2b3b8ffbcb / data/ai/micro_ais/cas/ (12 files): Micro AIs: don't check for specific value of move rating http://git.io/_7tf5Q
20140418 14:57:06< cib0> Actually, nevermind what I said earlier, the lost info is just for carryover, it's not used at all for checking victory.. So yeah, I'll move that.
20140418 14:57:08< gfgtdf> cib0: i also thingk that we should have the same behaviour in at turns and in human turnas and we currently call check_victory in ai turns and check_end_turn in human turns, another rason why i tihngk we can remove heck_end_turn
20140418 14:57:49< cib0> Well, one important difference is that check_end_turn is overloaded in single and multiplayer.
20140418 14:58:22< cib0> But yeah the same should be called.
20140418 14:58:42-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has quit [Ping timeout: 240 seconds]
20140418 14:59:50< gfgtdf> we dont have ifferent check_end_turn in playmp and playsingle controller, we just have different in playsingle and replaycontroller
20140418 15:00:26< gfgtdf> whcih maked me wonder if there is any reason why [endlevel] doudn't work in replays ?
20140418 15:00:26< cib0> Ah, yeah.
20140418 15:00:30< gfgtdf> make*
20140418 15:00:35< gfgtdf> shoudn't
20140418 15:00:41-!- sachith500 [~kvirc@112.135.209.163] has joined #wesnoth-dev
20140418 15:00:51< cib0> Maybe the information when the game ends is stored in the replay steps?
20140418 15:01:11< gfgtdf> cib0: no it isnt, it just that the replay end at some pint
20140418 15:01:16< gfgtdf> ends*
20140418 15:02:16< cib0> Okay.
20140418 15:03:27< cib0> Also inhering the mp controller from the sp controller is one weird application of inheritance.
20140418 15:04:27< iceiceice> why is it weird?
20140418 15:06:07< gfgtdf> i mean endlevel when enemies defeated works the same in mp and sp. why shoudn't [endlevel] ?
20140418 15:06:21< gfgtdf> in replay and in game i mean
20140418 15:06:53-!- sachith500 [~kvirc@112.135.209.163] has quit [Read error: Connection reset by peer]
20140418 15:07:12< cib0> iceiceice: Only way it couldn't be weird, is if the mp controller does everything the sp controller does, and only adds new behavior. Which I guess is possible, but then why call it "single_controller" when its functionality applies just as well to multiplayer?
20140418 15:07:54-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140418 15:08:49< iceiceice> cib0: that is largely accurate, the main thing that the mp controller has to do is add support for networking
20140418 15:09:23< cib0> Odd naming then.
20140418 15:28:42-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20140418 15:33:28< aquileia> AI0867: I had already updated to 1.2.12 before - but I forgot that the .dll is in a different directory than the .lib
20140418 15:34:04< aquileia> In this case it was good as I wouldn't have found the issue with 1.2.12
20140418 15:35:44< aquileia> The results are as you thought: 1.2.11 only works after the patch, 1.2.12 works in both cases
20140418 15:39:35< gfgtdf> cib0: my currently proposed fix looks liek this: https://github.com/gfgtdf/wesnoth-old/commit/3bbbaa55b9905b850500fbdc3c792188e9683414
20140418 15:41:17-!- _8680_ [~8680@2002:4404:712c:0:1d95:e434:7377:cff6] has quit [Ping timeout: 252 seconds]
20140418 15:42:20-!- _8680_ [~8680@2002:4404:712c:0:6988:24e3:fb5:ff0e] has joined #wesnoth-dev
20140418 15:48:24< cib0> There's typos in that.
20140418 15:48:49< cib0> If that doesn't break anything else, fine. I don't know enough about the workings of it to judge.
20140418 15:50:44< gfgtdf> ye i didn't compile to test. because i wanted to oush fast
20140418 15:50:57< gfgtdf> ll rmeove typs before i push to master/1.12
20140418 15:51:01< gfgtdf> remove
20140418 15:51:31-!- mjs-de [~mjs-de@p508CAD4E.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds]
20140418 15:52:04< cib0> Before you do that, send me the fixed version so I can test whether it actually fixes my particular issue. =P
20140418 15:52:24< gfgtdf> cib0: ok
20140418 15:52:55< cib0> Also please rebase/amend it, as we've discussed yesterday, commits that don't compile are a problem.
20140418 15:54:21< gfgtdf> gfgtdf: the previous comilation error were caused because i rebaed :), but ye i planned to do soi
20140418 15:54:27< gfgtdf> rebased*
20140418 16:01:22-!- sachith500 [~kvirc@112.135.209.163] has joined #wesnoth-dev
20140418 16:03:53< zookeeper> mattsc, you know anything about this orcish slayer leader thing? http://forums.wesnoth.org/viewtopic.php?f=53&t=20379&start=15#p569542 sounds bizarre
20140418 16:03:57-!- mjs-de [~mjs-de@p508C99DF.dip0.t-ipconnect.de] has joined #wesnoth-dev
20140418 16:05:20< mattsc> zookeeper: no, I don’t.  I just saw that post myself.  I was planning to look into it later today (gotta be off right now for a few hours), but feel free to beat me to it…
20140418 16:06:35< zookeeper> okay
20140418 16:07:03< AI0867> aquileia: okay then. I'll start preparing a patch that's tinier than your series ;)
20140418 16:07:18< AI0867> that is, I think I can ditch the whole filesystem::RWops wrapper
20140418 16:07:49< aquileia> AI0867: nice
20140418 16:09:00< aquileia> Do you want me to push my rebased sdl_fix so that you have a working base?
20140418 16:10:34< cib0> Is there actually an event that triggers before saving? That'd be cool.
20140418 16:11:47< AI0867> mail to dev-list sent
20140418 16:12:25< AI0867> aquileia: I think it would be less work to start from scratch, but taking a look can't hurt
20140418 16:12:45< aquileia> done, https://github.com/aquileia/wesnoth/tree/sdl_fix
20140418 16:12:53< gfgtdf> cib0: here: https://github.com/gfgtdf/wesnoth-old/commit/4447fdcae77424d6c851b0311d48d99aa3becb9b note that the branch is a 1.12 branch
20140418 16:13:08< gfgtdf> cib0: wesnoth.game_events.on_save fires onsaving
20140418 16:13:15< aquileia> AI0867: In any case, I learned a bit of git with it ;)
20140418 16:14:24< cib0> gfgtdf: Thanks.
20140418 16:14:25< AI0867> I've never actually used rebase with the -i switch
20140418 16:15:14< cib0> What's the branch name? ~_~
20140418 16:15:25< cib0> AI0867: Wow =p
20140418 16:15:55< cib0> So basically you've never manually edited commit history?
20140418 16:16:52< AI0867> I have, a bit, in limited ways
20140418 16:17:05< AI0867> I do have stacked git installed, but I have similarly never used it
20140418 16:17:55< gfgtdf> cib0: https://github.com/gfgtdf/wesnoth-old/commits/syncin12
20140418 16:18:35< cib0> ty
20140418 16:20:21< zookeeper> mattsc, well, i can't reproduce, but i asked for details in a PM which i also addressed to you
20140418 16:20:49< cib0> That on_save and on_load stuff seems better than using preload to load saves, and it's even compatible with my way of doings things(have all save stuff stored in one huge savegame WML table)
20140418 16:21:08< zookeeper> mattsc, i hope it's just him being mistaken or it somehow being his fault, since it'd be too odd otherwise
20140418 16:22:25< cib0> Wait no, one huge serialized lua table.. Heh. Who needs readability anyway..
20140418 16:23:07-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20140418 16:23:14< aquileia> shadowm, vultraz: Is it ok if I move some entries around to use a template? http://wiki.wesnoth.org/Download/es
20140418 16:24:23< gfgtdf> cib0: but there are currently problmes with on_load in mp
20140418 16:24:28< aquileia> This would reduce the maintenance of the translated pages (I had the idea after manually updating the German one)
20140418 16:30:44< cib0> I don't plan to make my overworld RPG campaign multiplayer anytime soon, but thanks.
20140418 16:32:13< cib0> gfgtdf: Works as expected.
20140418 16:32:24< gfgtdf> :)
20140418 16:32:57< cib0> It's weird when "this breaks my campaign" is a sign of bugs having been fixed.
20140418 16:34:03< cib0> But "it breaks all the time" is preferable to "it breaks sometimes" at any rate.
20140418 16:35:46-!- spoffy [~spoffy@host86-168-246-14.range86-168.btcentralplus.com] has joined #wesnoth-dev
20140418 16:40:31-!- EdB [~edb@85.69.242.6] has joined #wesnoth-dev
20140418 16:41:11-!- Bodhi-Baum [~Bodhi@dslb-084-063-063-211.pools.arcor-ip.net] has joined #wesnoth-dev
20140418 16:41:56< cib0> Is on_save also called on scenario end?
20140418 16:43:05< cib0> "The on_save and on_load hooks can be used to manipulate data that are neither meant to be forwarded to the next level nor substituted on the fly." Sounds like "no"..
20140418 16:44:27-!- sachith500 [~kvirc@112.135.209.163] has quit [Read error: Connection reset by peer]
20140418 16:45:05-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 252 seconds]
20140418 16:45:09< gfgtdf> cib0: i'd also say no, but im note sure
20140418 16:45:13< gfgtdf> not*
20140418 16:45:55-!- anonymissimus [~chatzilla@HSI-KBW-37-49-94-9.hsi14.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20140418 16:46:39< aquileia> Hi anonymissimus
20140418 16:46:44< anonymissimus> hey
20140418 16:46:54< anonymissimus> thanks for updating project file
20140418 16:47:05< aquileia> No problem
20140418 16:47:05< anonymissimus> *but* pls dont reamove some of those things
20140418 16:47:23< anonymissimus> especially the part about how to compile the prerequisites
20140418 16:47:29< anonymissimus> in that old guide
20140418 16:47:54< aquileia> you mean in the readme file?
20140418 16:48:17< aquileia> I'll move it to the wiki in that case
20140418 16:49:25< anonymissimus> yes, but wiki is less controllable than file under version control
20140418 16:49:49< anonymissimus> and once your GSOC is over there will probably no one maintaining it
20140418 16:50:09< aquileia> So you want to reinstate a section for the prerequisites, right?
20140418 16:50:23< anonymissimus> (hard to say sorry - usually people disappear)
20140418 16:50:27< aquileia> anonymissimus: I'm not even applying for GSoC
20140418 16:51:08< anonymissimus> well, I just would like to keep it there as it'S the only discription of it which I know of
20140418 16:51:16-!- timotei_ [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140418 16:51:21< aquileia> ok
20140418 16:51:41< anonymissimus> so you're not gsoc student ?
20140418 16:52:20< anonymissimus> what does your motivation for the project come from ? (for me I'm basically bound through my addons)
20140418 16:52:33< aquileia> no, I just wanted to get a feature in before the freeze and therefore implemented it myself, then got addicted
20140418 16:52:58< vultraz> aquileia: sure. what exactly do you intend to do?
20140418 16:53:14< anonymissimus> ah, and did you also add the sld2 files ? I added some of them, though I'm not sure whether it's a good idea
20140418 16:53:40< anonymissimus> as the build system isnt yet updated, so there wouldnt be errors anyway
20140418 16:53:48< aquileia> vultraz: I templated the section with the download links so that we only have to update 1 place and not 4
20140418 16:54:04< cib0> Not a fan of SDL2, personally. We switched to SDL2 in this other game, and it made rendering very slow on old laptops with no dedicated GPU.
20140418 16:54:39< cib0> But then, that's specific to actually using SDL_Texture, which is optional.
20140418 16:54:48< vultraz> aquileia: good idea
20140418 16:56:04< irker812> wesnoth: gfgtdf wesnoth:1.12 bcf28527618d / src/play_controller.cpp: always allow SAVE_REPLAY http://git.io/lIUi3w
20140418 16:56:06< irker812> wesnoth: gfgtdf wesnoth:1.12 e454252f218b / src/ (play_controller.cpp playmp_controller.cpp playsingle_controller.cpp): fix 21933 http://git.io/3PrBcQ
20140418 16:56:08< aquileia> Should I add optional parameters for the OS translations which are needed in Chinese?
20140418 16:56:08< irker812> wesnoth: gfgtdf wesnoth:1.12 ac2e8ae2aac9 / src/actions/move.cpp: add a check_victory after moves. http://git.io/ufZzZA
20140418 16:57:24< vultraz> uh...
20140418 16:57:29< vultraz> I...guess
20140418 16:58:15< cib0> Is it a new thing that you can't any longer move and attack in the same click, or did I mess something up?
20140418 17:00:45< anonymissimus> vultraz: why adding things like tools\exploder_composer.cpp to codeblocks ? and are you even using it ?
20140418 17:01:09< anonymissimus> the exploder is even unused on Linux i thinks
20140418 17:01:23< anonymissimus> msame for a few of the other targets (cutter)
20140418 17:01:55< aquileia> anonymissimus: They were excluded again
20140418 17:02:47 * aquileia intruduced a bug during that, though
20140418 17:03:42-!- sachith500 [~kvirc@112.135.209.163] has joined #wesnoth-dev
20140418 17:05:04-!- sachith500 [~kvirc@112.135.209.163] has quit [Read error: Connection reset by peer]
20140418 17:05:48-!- sachith500 [~kvirc@112.135.209.163] has joined #wesnoth-dev
20140418 17:06:25< anonymissimus> aquileia: so you are using codeblocks too ? (compliling parallely to MSVC is recommended)
20140418 17:06:46< anonymissimus> for a cross-platform c++ project developped on windows
20140418 17:07:06< aquileia> anonymissimus: No, that's also the reason I introduced that bug in CB-scons
20140418 17:07:28< gfgtdf> cib0: you still can move+attack in the same click, 
20140418 17:07:49< aquileia> I only brought the CB and CB-scons projects in line
20140418 17:08:10< gfgtdf> cib0: but i think not when an event interferes idk why 
20140418 17:08:55< cib0> Weird thing is I don't have a moveto event. =/
20140418 17:09:12< cib0> preload, start, side turn, victory
20140418 17:09:27-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20140418 17:09:45< anonymissimus> aquileia: cb-scons is only used by loonycyborg afaik, and only for "intellisense", that is, adding or removing files has no impact on compilation
20140418 17:10:17< anonymissimus> thus not very important
20140418 17:10:29< gfgtdf> cib0: on which branch are you testing ?
20140418 17:11:00< anonymissimus> you should just have reverted that commit by kevin-xi or what the nick is
20140418 17:11:02< aquileia> anonymissimus: I was told it influences the debugging behavior
20140418 17:11:13< anonymissimus> that may be
20140418 17:12:31< cib0> gfgtdf: master
20140418 17:12:44-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140418 17:14:39< vultraz> I use codeblocks
20140418 17:14:57< vultraz> But all I did was merge the PR. aquileia edited it after
20140418 17:15:54< cib0> Pfhfhfh, coding more "dynamic" content with lua can be hilarious. I have a system where I can just plug in any .map file for a location and it'll generate the scenario for it.
20140418 17:16:12< cib0> Forgot to place leader markers on the map, instant lose upon entering the place.
20140418 17:17:18< gfgtdf> cib0: maybe there were sighed things during te move  or imilar ?
20140418 17:17:22< aquileia> vultraz: All translations are in sync now
20140418 17:17:32-!- bumbadadabum [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20140418 17:18:27< cib0> gfgtdf: All enemies were in sight already so nope. I'll see if it persists.
20140418 17:22:35< cib0> What would be so cool: A thing for the map editor where you click on locations and it puts a list of <x, y> coordinates in your clipboard.
20140418 17:23:39-!- kex [~kex@79.126.245.90] has joined #wesnoth-dev
20140418 17:28:16< vultraz> I removed the section on older stable downloads from the Downloads page
20140418 17:28:48< vultraz> Nothing later than 1.8 was listed there
20140418 17:29:07< vultraz> (the furthest back was a 1.2 version)
20140418 17:31:15< aquileia> vultraz: But isn't it better to have an old version than none at all?
20140418 17:32:35< vultraz> Not that old
20140418 17:34:10< cib0> Each version is stable and a good game in and of itself.
20140418 17:34:34< cib0> But we do have svn and git so nothing will be lost.
20140418 17:34:54< vultraz> Only git
20140418 17:35:04< vultraz> We abandoned SVN last year
20140418 17:35:17< cib0> Took the server down, too?
20140418 17:35:28< vultraz> hm?
20140418 17:36:08< cib0> http://svn.gna.org/viewcvs/wesnoth/ Still there. =P
20140418 17:36:39< cib0> Could be useful if you want to try your hand at really, really old wesnoth lol
20140418 17:36:55< vultraz> All the history was moved to git anyway
20140418 17:37:15< vultraz> SF is only used for hosting the release binaries now, and gna for the bugtracker
20140418 17:37:50< cib0> ... oh
20140418 17:37:55< cib0> That explains why the download is so large.
20140418 17:38:24< vultraz> What, you think we just only took a snapshop and uploaded it to git? :P
20140418 17:38:28< vultraz> s/git/github
20140418 17:40:31< cib0> It would have been the best opportunity to do so, yes.
20140418 17:41:08< cib0> There's no reason really to have every developer keep a copy of the complete history since 2003, even if it's useful to have that history stored somewhere.
20140418 17:42:08< cib0> But then I'm talking as someone who can't afford either fast internet or a lot of disk space, I may be an exception there.
20140418 17:42:50-!- mordante [~mordante@roadie.xs4all.nl] has joined #wesnoth-dev
20140418 17:42:50-!- mordante [~mordante@roadie.xs4all.nl] has quit [Changing host]
20140418 17:42:50-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20140418 17:43:04< mordante> servus
20140418 17:43:36< cib0> yoh mordante
20140418 17:43:44< mordante> hi cib0 
20140418 17:44:31< mordante> Aishiko, good to see you found the error
20140418 17:44:49< mordante> Aishiko, found it with the debugger?
20140418 17:45:44< mordante> juanmi91 if I would know your forum name, also it is rather late in the game
20140418 17:46:50< vultraz> cib0: I have less than 1 MB/s internet
20140418 17:46:55< vultraz> more like 0.3 mb/s
20140418 17:47:16< vultraz> I'm good on disk space tho. Have 1 TB here
20140418 17:47:36< aquileia> anonymissimus: Oh, I just saw that you already restored these instructions once... sorry, I probably should have looked at that.
20140418 17:53:13-!- sachith500 [~kvirc@112.135.209.163] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
20140418 17:55:36< cib0> ... pick 3 unit types randomly from a list, get 3 times horseman.
20140418 17:55:48< cib0> "That's the problem with randomness, you can never know"
20140418 17:59:03-!- SigurdFD [~SigurdFD@24.154.98.89] has joined #wesnoth-dev
20140418 18:09:01< anonymissimus> aquileia: yes I did
20140418 18:09:39< anonymissimus> aquileia: when you "fixed" the projectfile, did it compile for you ?
20140418 18:09:52< anonymissimus> or was that a remote fix attempt
20140418 18:10:17< anonymissimus> it doesnt right now...looks like i at best start with shadowm's last commit
20140418 18:10:18< aquileia> If you mean the VC one, yes - on CB, no
20140418 18:10:24< anonymissimus> ok
20140418 18:10:42< aquileia> do you mean CB-scons?
20140418 18:10:50< anonymissimus> no, only cb
20140418 18:11:11< anonymissimus> for cb-scons I don't care, the one using it has to maintain it
20140418 18:14:22-!- kex [~kex@79.126.245.90] has quit [Remote host closed the connection]
20140418 18:14:53-!- kex [~kex@79.126.245.90] has joined #wesnoth-dev
20140418 18:19:19-!- kex [~kex@79.126.245.90] has quit [Ping timeout: 252 seconds]
20140418 18:35:37< aquileia> anonymissimus: I restored the prerequisites manual in my fork, could you add the commit to master, please?
20140418 18:36:19< aquileia> https://github.com/aquileia/wesnoth
20140418 18:49:14-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has joined #wesnoth-dev
20140418 18:49:45< anonymissimus> don't you have write access ? just do it
20140418 18:50:22< aquileia> No, I declined
20140418 18:50:24< anonymissimus> ah well seems you don :/
20140418 18:50:37< anonymissimus> make pull request
20140418 18:50:46< anonymissimus> i merge
20140418 18:50:50< aquileia> ok
20140418 18:51:37< anonymissimus> ah, and pls also add the sdl2 files to msvc, as we are doing that for codeblocks too
20140418 18:52:15< anonymissimus> even though they are not needed for now...but at some point someone will try to compile with sdl2 and at that point that person will be thankful
20140418 18:52:56< anonymissimus> i hope i got the codeblocks file fixed now
20140418 18:53:25-!- mordante is now known as wesnoth|mordante
20140418 18:53:30-!- _8680_ [~8680@2002:4404:712c:0:6988:24e3:fb5:ff0e] has quit [Ping timeout: 240 seconds]
20140418 18:54:13-!- _8680_ [~8680@2002:4404:712c:0:6151:c1c9:5c0b:2802] has joined #wesnoth-dev
20140418 18:59:53-!- noy is now known as noy-wesnoth
20140418 19:02:35-!- molgrum [~molgrum@212.85.89.43] has joined #wesnoth-dev
20140418 19:05:55< aquileia> wesnoth|mordante: I know you're occupied with #gsoc, but... is tracer.cpp correctly filed under libwesnoth_sdl_sources?
20140418 19:09:10< aquileia> It's currently only used in a unit test
20140418 19:15:26< aquileia> anonymissimus: The sdl subfolder is currently part of wesnoth.vcproj, Scons has it listed under libwesnoth... should I change it in VC?
20140418 19:15:41< cib0> Isn't the leader from my recall list supposed to overwrite the leader from my side tag..
20140418 19:17:07< wesnoth|mordante> aquileia, I'll look after the gsoc meeting
20140418 19:17:13< aquileia> ok
20140418 19:17:32< cib0> Oh, curious.
20140418 19:17:44< cib0> If you manually put the leader in the recall list, it won't work. Has to be on the map at scenario end.
20140418 19:21:26-!- wesnoth|mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20140418 19:21:49< irker812> wesnoth: anonymissimus wesnoth:master 4de900f9437f / projectfiles/CodeBlocks/wesnoth.cbp: fix cb project file http://git.io/G1wGRw
20140418 19:21:52< gfgtdf> cib0: i would think if you manual put the leader in the recall list the side gets defeated because it has no leader on the map?
20140418 19:22:35< anonymissimus> aquileia: what do you mean ?
20140418 19:23:04< anonymissimus> putting it into wesnothlib ?
20140418 19:23:14< aquileia> Yes, should I?
20140418 19:23:33< anonymissimus> well no idea; as I said, the sdl2 files aren't used for as long as MSVC doesn't build with sdl2
20140418 19:24:11< anonymissimus> the point of adding them only is that there doesn't so much work accumulate which needs to be done once we compile with sdl2
20140418 19:24:28< anonymissimus> because that is always very hard then
20140418 19:24:55< aquileia> I just thought that paralleling the sorting in Scons may be better
20140418 19:27:25< anonymissimus> no, dont imitate it
20140418 19:27:29< aquileia> ok
20140418 19:27:34< anonymissimus> makes no sense
20140418 19:28:39< anonymissimus> the point of wesnothlib afaik is that it puts files which are supposedly less frequently changed together
20140418 19:28:57< anonymissimus> so that it compiles somewhat quicker
20140418 19:29:10< anonymissimus> at least thats what Ilor wrote when he created it
20140418 19:29:34< anonymissimus> but those files are almost as often changed as the ones in the main project
20140418 19:31:40< cib0> gfgtdf: Well I'm calling endlevel right after, there's no check_victory inbetween.
20140418 19:34:09< iceiceice> gfgtdf: i have a quick question
20140418 19:34:15< iceiceice> when you changed around the RNG stuff,
20140418 19:34:19< iceiceice> what happened to random start time?
20140418 19:36:29-!- justinzane [~justinzan@host-12-172-184-180.nctv.com] has joined #wesnoth-dev
20140418 19:36:48< cib0> Hm, isn't there a way to undo [object] on a unit?
20140418 19:37:34< mattsc> zookeeper: thanks.  I can confirm that the side 2 leader in the replay is an Assassin for me as well.
20140418 19:39:36< cib0> Fun times ahead?
20140418 19:41:48< aquileia> anonymissimus: https://github.com/wesnoth/wesnoth/pull/154
20140418 19:43:17< zookeeper> cib0, no direct way
20140418 19:44:03< zookeeper> you have to either apply an object with opposite effects, or to manually clear the variables affected by the object and the object itself and then unstore
20140418 19:44:35< cib0> Ah, thanks.
20140418 19:44:50< cib0> So it's possible just a bit of effort to do from lua. =)
20140418 19:45:12-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20140418 19:47:54-!- timotei_ [~timotei@wesnoth/developer/timotei] has quit [Ping timeout: 258 seconds]
20140418 19:50:50< anonymissimus> aquileia: sld_utils is already present, isn't it ?
20140418 19:51:08< anonymissimus> and thats no sdl2 file
20140418 19:51:24< anonymissimus> nothing mordante did add during his sdl2 compatibility changes
20140418 19:52:26< aquileia> But why shouldn't I group it under SDL?
20140418 19:52:39< aquileia> I'll delete one of the inclusions, you are right
20140418 19:53:46< aquileia> anonymissimus: Is it ok if I leave it under SDL?
20140418 19:56:58< gfgtdf> iceiceice: is there a bug with random start time ? random start time should normaly use the unsynced rand() i think
20140418 19:57:20< anonymissimus> teh file is not in the sld folder
20140418 19:57:34< anonymissimus> sld is a folder mordante added for the sdl2 files
20140418 19:57:43< aquileia> ok
20140418 19:57:48< anonymissimus> so it better should stay where it was
20140418 19:58:10< iceiceice> gfgtdf: yeah i guess theres some longstanding issue with random start time when playing an MP campaign
20140418 19:58:23< iceiceice> if you transition to a scenario with random start time, everyone gets out of sync about the time of day
20140418 19:58:30< iceiceice> that is current in 1.10.6 anyways
20140418 19:58:37< iceiceice> heres an old bug report: https://gna.org/bugs/?15948
20140418 19:58:51< gfgtdf> iceiceice: i thought the host sets the random start time to a value leike he does for random_leader
20140418 19:59:42< iceiceice> hmm well i wouldnt know about it, but i can tell you that i had to debug one of my add-ons once and ran into this
20140418 19:59:44< aquileia> anonymissimus: PR updated
20140418 19:59:58< iceiceice> i guess Coffee also had to work around it in his TGQ add-on
20140418 20:00:01< iceiceice> iirc
20140418 20:00:15< gfgtdf> iceiceice: here is teh code that calcuklated random start time, i didnt chnage that https://github.com/wesnoth/wesnoth/blob/eb48917ce56f7cd5453131124f3dc3cea792b2c7/src/tod_manager.cpp#L351
20140418 20:00:23< mattsc> cib0: you can do pretty much anything you want to a unit from Lua.  Just take the .__cfg table dump, manipulate it, and then put the unit back out there.
20140418 20:00:58< iceiceice> is rand() unsynced?
20140418 20:01:36< gfgtdf> iceiceice: yes
20140418 20:01:44-!- justinzane [~justinzan@host-12-172-184-180.nctv.com] has quit [Remote host closed the connection]
20140418 20:01:45< iceiceice> hmm ok
20140418 20:01:52< iceiceice> it looks like there are even comments in the code that it causes a bug
20140418 20:02:14< iceiceice> idk i never tried to look at this seriouly, i thought i would just ask if you did anything with it / thought about it
20140418 20:02:19-!- justinzane [~justinzan@12.172.184.180] has joined #wesnoth-dev
20140418 20:02:30< gfgtdf> iceiceice: i think tod_manager is initiliased before gamedate/gamestatus, and the sycned rng wonto work be fore that
20140418 20:02:40< iceiceice> i mean
20140418 20:02:45< iceiceice> my thought would be that,
20140418 20:02:50< gfgtdf> iceiceice: if we change the initilisation order we could maybe use teh synced rand
20140418 20:02:54< iceiceice> the random start time should work like shuffle sides
20140418 20:03:05< gfgtdf> iceiceice: generated by the host then ?
20140418 20:03:10< iceiceice> it could be randomized in the cfg at that time i think
20140418 20:03:10< iceiceice> idk
20140418 20:03:23-!- kex [~kex@79.126.245.90] has joined #wesnoth-dev
20140418 20:03:24< gfgtdf> i think both options are possible
20140418 20:03:25< iceiceice> i dont really know what i am talking about here
20140418 20:03:51< gfgtdf> we could eigher sync it durign teh game with the synced rng or before the start making teh host takng that decision
20140418 20:04:32< iceiceice> hmm
20140418 20:04:42< iceiceice> is there anyway in WML to check the time of day?
20140418 20:04:56< gfgtdf> iceiceice: idk why do you ask ?
20140418 20:05:00< iceiceice> just thinking,
20140418 20:05:09< iceiceice> if we are going to randomize it before the start
20140418 20:05:14< gfgtdf> if there is no direct way, then there is sure some hacy way
20140418 20:05:24< iceiceice> probably better if that happens before prestart or whatever
20140418 20:05:35< iceiceice> *after the start
20140418 20:05:45< gfgtdf> iceiceice: why that ?
20140418 20:05:52< gfgtdf> then they would be unsyned during start
20140418 20:06:18< iceiceice> hm i guess i just think it would be confusing for add-on makers if like,
20140418 20:06:40< iceiceice> "when using random start time, the time of day during prestart is some default value, then is only set to its value during start"
20140418 20:07:05< gfgtdf> iceiceice: yes so why do you want it after the start
20140418 20:07:10< iceiceice> i dont 
20140418 20:07:14< gfgtdf> "	iceiceice	*after the start"
20140418 20:07:25< iceiceice> i guess its confusing because there are two "start"'s right?
20140418 20:07:26< iceiceice> lol
20140418 20:07:34< iceiceice> theres the [start] signal sent to server
20140418 20:07:38< gfgtdf> ah
20140418 20:07:41< iceiceice> and theres the "start" events 
20140418 20:07:42-!- mjs-de [~mjs-de@p508C99DF.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20140418 20:07:59< iceiceice> what happens in between those things is largely a mystery to me tbh
20140418 20:08:00< gfgtdf> i think after the start would be harder to implement
20140418 20:08:13-!- kex [~kex@79.126.245.90] has quit [Ping timeout: 258 seconds]
20140418 20:08:32< gfgtdf> better before prestart event or similar 
20140418 20:08:33< iceiceice> how is it currently set up though?
20140418 20:08:42< gfgtdf> in playcontrollers contructor
20140418 20:08:56< iceiceice> really?
20140418 20:09:11< iceiceice> do we construct a new playcontroller everytime you transition to a new scenario?
20140418 20:09:26< gfgtdf> iceiceice: what do wo do here ?? https://github.com/wesnoth/wesnoth/blob/eb48917ce56f7cd5453131124f3dc3cea792b2c7/src/tod_manager.cpp#L50
20140418 20:09:35< gfgtdf> iceiceice: i think yes
20140418 20:09:47< gfgtdf> but im nt sure
20140418 20:09:48< gfgtdf> not
20140418 20:10:29< gfgtdf> https://github.com/wesnoth/wesnoth/blob/master/src/playcampaign.cpp#L323
20140418 20:11:32< iceiceice> hmm
20140418 20:12:29< iceiceice> well it sounds like someone just willfully broke this :/
20140418 20:12:36< iceiceice> that line you sent here: https://github.com/wesnoth/wesnoth/blob/eb48917ce56f7cd5453131124f3dc3cea792b2c7/src/tod_manager.cpp#L50
20140418 20:12:52< iceiceice> where they just cast a const config & to non-const so they can change the TOD, knowing that it will cause OOS
20140418 20:13:41< iceiceice> idk
20140418 20:14:09< iceiceice> i guess the thing that makes it hard is that
20140418 20:14:22< iceiceice> if you move the code to work where the shuffle_sides code is,
20140418 20:14:27< iceiceice> that code isn't fired in SP
20140418 20:14:53< iceiceice> i'm not sure if theres any reason to change the way it works in SP right now,
20140418 20:15:09< gfgtdf> iceiceice: we want the same code in mp an in sp :)
20140418 20:15:19< iceiceice> yeah but idk how we can easily do that right now :/
20140418 20:15:28< iceiceice> to me it seems the most direct fix would be
20140418 20:15:34< iceiceice> go to the part where we shuffle the sides
20140418 20:15:42< iceiceice> check if "random_start_time = yes"
20140418 20:15:51< iceiceice> then mark it no and randomize the initial time
20140418 20:15:56< iceiceice> and dont change any other code
20140418 20:16:12< iceiceice> its just a workaround but it seems like its the least invasive thing that would fix the bug
20140418 20:17:20< iceiceice> also i guess i'm not sure how annyoing it would be to randomize the initial time, idk if you can just change some attribute value or if you have to like shuffle the TOD tags in the scenario?? that sounds slightly painful
20140418 20:17:21< gfgtdf> iceiceice: hmm maybe true idk how hard it is to chnage the in the ml code
20140418 20:18:04< anonymissimus> that random start time thing is a pain in the ass; someone should have decided to not implement it if he only can using const_cast
20140418 20:18:32< anonymissimus> if it's causing probs I'm all for removing the feature
20140418 20:18:46< iceiceice> is it used in mainline anywhere?
20140418 20:19:10< anonymissimus> it's the random start time check button in the mp create screen IIRC
20140418 20:19:21< gfgtdf> but it it used anywhere in sp ?
20140418 20:19:23< zookeeper> how can it be so problematic to make work right?
20140418 20:19:25< iceiceice> isn't it also a key in the scenario?
20140418 20:19:32< anonymissimus> in sp...probably not
20140418 20:19:54< gfgtdf> then we can remove it and reimplement it only in the mp connect code ?
20140418 20:20:11< gfgtdf> like host making the decision like for random faction/leader
20140418 20:22:14< iceiceice> hmm well i grepped for "random_start_time" in data/ 
20140418 20:22:18< iceiceice> it looks like it is always no
20140418 20:23:17-!- EdB [~edb@85.69.242.6] has quit [Quit: Konversation terminated!]
20140418 20:26:43< gfgtdf> iceiceice: i think in in any case you can do the fix proposed in the mp connect code.
20140418 20:26:59< gfgtdf> if you want
20140418 20:27:11< iceiceice> yeah i might do it
20140418 20:27:21< iceiceice> i think i have bigger fish to fry atm though 
20140418 20:27:42< gfgtdf> iceiceice: also with mp transition ?
20140418 20:27:47< iceiceice> yeah
20140418 20:28:22< gfgtdf> iceiceice: do you think you cn fix before 1.11.13?
20140418 20:29:00< iceiceice> i think so
20140418 20:29:09< iceiceice> i have been thinking about it
20140418 20:29:31< iceiceice> there are still some other bugs that need to be solved anyways,
20140418 20:29:44< iceiceice> we'll see where we are at the end of the weekend
20140418 20:32:13-!- noy-wesnoth [~Noy@wesnoth/developer/noy] has quit [Quit: noy-wesnoth]
20140418 20:32:30< SigurdFD> iceiceice: about next_scenario_settings, I was mistaken, there was no bug, just my own confusion. sorry about that.
20140418 20:33:03< iceiceice> hmm ok
20140418 20:33:16< iceiceice> do you know if the save_replay key is persistent?
20140418 20:33:26< iceiceice> or if that is also not actually persistent?
20140418 20:33:58< SigurdFD> let me check...
20140418 20:34:03-!- ancestral [~ancestral@17.114.45.117] has joined #wesnoth-dev
20140418 20:34:09< iceiceice> ok
20140418 20:34:15< iceiceice> if the next_scenario_settings stuff is being correctly cleared then perhaps a very simple fix for the save_replay thing is to also clear that at the same time
20140418 20:35:37< SigurdFD> the manually set value of replay_save= key is not persistent.
20140418 20:35:53< iceiceice> ok very well, thanks for reporting :)
20140418 20:35:58< SigurdFD> if it's absent in a [endlevel], it defaults to replay_save=yes
20140418 20:38:43< SigurdFD> np
20140418 20:40:44-!- SigurdFD [~SigurdFD@24.154.98.89] has quit []
20140418 20:42:27-!- Bodhi-Baum [~Bodhi@dslb-084-063-063-211.pools.arcor-ip.net] has quit [Quit: Verlassend]
20140418 20:43:21-!- justinzane [~justinzan@12.172.184.180] has quit [Remote host closed the connection]
20140418 20:44:03-!- justinzane [~justinzan@12.172.184.180] has joined #wesnoth-dev
20140418 20:44:52-!- wesbot changed the topic of #wesnoth-dev to: string+feature freeze active on 1.12 | 232 bugs, 347 feature requests, 28 patches | Logs: http://irclogs.wesnoth.org | Alternate logs: http://wesnoth.debian.net | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20140418 20:48:15< gfgtdf> iceiceice: why do you use set_attr instead or set_attr_dub in https://github.com/wesnoth/wesnoth/blob/master/src/server/game.cpp#L542 ? 
20140418 20:50:27< iceiceice> i didn't think about it
20140418 20:50:48< iceiceice> i wonder if that explains a bug i may have observed...
20140418 20:51:16< iceiceice> i mean just above they were using "set_attr" for this purpose
20140418 20:51:38< iceiceice> let me read through and think about this carefully
20140418 20:52:07< gfgtdf> iceiceice: but the 'change' above is a local object, recchg is created with new
20140418 20:54:01< iceiceice> you're right it looks like set_attr_dup is what i want
20140418 20:57:58< zookeeper> mattsc, and luckily it was as i hoped :P
20140418 20:58:57< irker812> wesnoth: aquileia wesnoth:master 0bbcec537f01 / projectfiles/VC9/README.txt: Restore instructions for VC dependencies http://git.io/6y08MA
20140418 20:58:59< irker812> wesnoth: aquileia wesnoth:master a92e37490727 / projectfiles/CodeBlocks-SCons/wesnoth.cbp: Fix CB-Scons target names http://git.io/GcWtKg
20140418 20:59:01< irker812> wesnoth: aquileia wesnoth:master f63358af1fe0 / projectfiles/VC9/wesnoth.vcproj: Add SDL2 specific files to VC project http://git.io/I20OQA
20140418 20:59:03< irker812> wesnoth: anonymissimus wesnoth:master 58cdba4adfbd / projectfiles/ (CodeBlocks-SCons/wesnoth.cbp VC9/README.txt VC9/wesnoth.vcproj): Merge branch 'master' of https://github.com/aquileia/wesnoth into aquileia-maste http://git.io/6JvznA
20140418 20:59:57< iceiceice> gfgtdf: i went back to this strange thing you pointed out in my code:
20140418 21:00:04< iceiceice> 20140417 19:12:10< gfgtdf> iceiceice: is there a reason for what you do with LOG_MP in  43603e0568d436b3e6351a733a9a304194525006 ? 
20140418 21:00:14< iceiceice> so i think that did not actually get pushed to master or 1.12
20140418 21:00:19< iceiceice> it was rebased away eventually
20140418 21:01:07< iceiceice> i'm not sure why it appears when i write url: https://github.com/wesnoth/wesnoth/commits/43603e0568d436b3e6351a733a9a304194525006
20140418 21:01:14< iceiceice> i think its just because it was part of a pull request
20140418 21:01:29< iceiceice> but that pull request didnt get pulled, i redid the commits later
20140418 21:05:25< aquileia> iceiceice: Maybe the commit SHA was different after you rebased, so the old one is still specific to the deleted version?
20140418 21:05:49< iceiceice> i think i never actually rebased those particular commits,
20140418 21:05:56-!- noy-wesnoth [~Noy@S01067cb21b205894.vs.shawcable.net] has joined #wesnoth-dev
20140418 21:06:02< iceiceice> i kept them as a back up and cherry-picked onto a testing branch which i tested and rebased
20140418 21:13:45-!- noy-wesnoth [~Noy@S01067cb21b205894.vs.shawcable.net] has quit [Quit: noy-wesnoth]
20140418 21:20:40< mattsc> zookeeper: yeah, agreed.
20140418 21:22:18-!- justinzane [~justinzan@12.172.184.180] has quit [Ping timeout: 240 seconds]
20140418 21:23:32< gfgtdf> does anyone else think the label "Each Team" in the replaycontroller is confusing ?
20140418 21:24:50< gfgtdf> i think the geman translator also got confused by this, because it's translated with "Jedes Team" while i am not sure whether "Each Team" is correct im sure that "Jedes Team" is not correct.
20140418 21:27:55-!- gfgtdf_ [~chatzilla@f054153120.adsl.alicedsl.de] has joined #wesnoth-dev
20140418 21:28:30-!- Sulfur [~Miranda@p5B327882.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20140418 21:28:35< anonymissimus> what should it be called ?
20140418 21:28:42< anonymissimus> team specific ?
20140418 21:30:03-!- gfgtdf [~chatzilla@e177166210.adsl.alicedsl.de] has quit [Ping timeout: 265 seconds]
20140418 21:30:05-!- gfgtdf_ is now known as gfgtdf
20140418 21:31:04< anonymissimus> hm..just got a crash when trying to load replay from 1.11/12
20140418 21:31:35< anonymissimus> not really worth a bug report
20140418 21:33:52< iceiceice> hmm gfgtdf: i am getting a bunch of these on std::cerr: 
20140418 21:33:53< iceiceice> 20140418 17:29:22 error network: found unknown command:
20140418 21:33:54< iceiceice> [record_change_controller]
20140418 21:33:54< iceiceice> 	controller = network_ai
20140418 21:33:54< iceiceice> 	player = iceiceice
20140418 21:33:55< iceiceice> 	side = 1
20140418 21:33:56< iceiceice> [/record_change_controller]
20140418 21:34:41< gfgtdf> anonymissimus: ye it shows from the pointof wie of teh curently active team
20140418 21:34:56< iceiceice> that is from the client
20140418 21:34:57< gfgtdf> view of the currently active team
20140418 21:34:58< iceiceice> but strangely enough,
20140418 21:35:12< iceiceice> i dont find any of them in the outputted server replay
20140418 21:35:25< gfgtdf> iceiceice: on whcih branch ?
20140418 21:35:37< iceiceice> 1.12 + change set_attr to set_attr_dup where you suggested
20140418 21:36:14< iceiceice> hmm i wonder if i need to wrap them in "command" or something for some reason?
20140418 21:36:49< gfgtdf> iceiceice: i tihnk record_change_controller is a replac command so it has to be inside a [turn][command][/command][/turn]
20140418 21:36:55< gfgtdf> replay*
20140418 21:37:26< iceiceice> hmm ok
20140418 21:37:37< iceiceice> its a bit funny to me
20140418 21:37:52< gfgtdf> why?
20140418 21:38:02< iceiceice> in the server code history is a vector of simple_wml documents
20140418 21:38:31< iceiceice> when i tell it to record some data,
20140418 21:38:39< iceiceice> it just puts it in a document and pushes it there
20140418 21:38:59< iceiceice> at the end in game::save_replay it looks like it should just concatenate them to become my list of "replay commands"
20140418 21:39:02< iceiceice> that goes into [replay]
20140418 21:39:18< iceiceice> so i dont udnerstand why my [record_change_controller]'s aren't showing up in the server replay sve
20140418 21:39:22< iceiceice> if the client is seeing them
20140418 21:39:29< iceiceice> when it joins as an observer
20140418 21:39:33< gfgtdf> becasue they need to be in a[turn][command]
20140418 21:39:37< gfgtdf> hm
20140418 21:39:55< iceiceice> oh hmm
20140418 21:40:03< iceiceice> i see what you mean it is checking for [turn]
20140418 21:40:07< gfgtdf> becaus everythign thean [turn][command] is removed here https://github.com/wesnoth/wesnoth/blob/master/src/server/game.cpp#L1402
20140418 21:40:48< gfgtdf> the game handles replay data here: https://github.com/wesnoth/wesnoth/blob/master/src/playturn.cpp#L165
20140418 21:41:03-!- TC01 [~quassel@128.220.109.252] has quit [Remote host closed the connection]
20140418 21:41:18< iceiceice> hmm ok but when the server records server messages
20140418 21:41:25< iceiceice> it doesnt do anything fancy like look for [turn]
20140418 21:41:40< iceiceice> here's the "send_and_record_server_message" function: https://github.com/wesnoth/wesnoth/blob/master/src/server/game.cpp#L1552
20140418 21:43:28< gfgtdf> iceiceice: did you test thet they are present in serversided replays ?
20140418 21:43:46< iceiceice> hmm
20140418 21:43:46< iceiceice> no
20140418 21:44:07< iceiceice> hmm it looks like they are:
20140418 21:44:10< iceiceice> i am seeing this in my replay:
20140418 21:44:11< iceiceice> [speak]
20140418 21:44:11< iceiceice> id="server"
20140418 21:44:11< iceiceice> message="iceiceice droids side 1."
20140418 21:44:11< iceiceice> [/speak]
20140418 21:44:25< iceiceice> outside of a command tag
20140418 21:44:28< gfgtdf> send_server_message uses turn
20140418 21:44:50< gfgtdf> iceiceice: the replaycontroller should inore thing ouside aocmmand tag
20140418 21:44:53< gfgtdf> ingore
20140418 21:45:17< iceiceice> i see
20140418 21:45:21< gfgtdf> are you sure it's outside a comand tag ?
20140418 21:47:00< gfgtdf> iceiceice: how is your record_change_controller in replac.cpp supposed to work ?
20140418 21:47:19< gfgtdf> replay*
20140418 21:47:25< iceiceice> so heres the idea
20140418 21:47:31< iceiceice> prior to the patch that i made,
20140418 21:47:41< iceiceice> the server would do some pretty bizarre stuff with controllers
20140418 21:47:59< iceiceice> the server normally holds the initial level config of the game, sent by the host
20140418 21:48:10< iceiceice> it relays this to allt he clients when the game starts
20140418 21:48:31< iceiceice> then it just acts as a relay, and command messages sent to all generally get recorded in the history
20140418 21:48:40< iceiceice> at the end the history becomes [replay]
20140418 21:48:45< iceiceice> and the level config becomes [replay_start]
20140418 21:48:54< iceiceice> so obviously it doesnt work if the game is reloaded and other such things
20140418 21:49:04< iceiceice> but even then there was bizarre stuff happening whenc ontrollers change
20140418 21:49:16< iceiceice> when the host gives a side away or droids it,
20140418 21:49:21< iceiceice> he requests a change to the server
20140418 21:49:28< iceiceice> if the server grants it he sends everyone a change_controller message
20140418 21:49:34< iceiceice> but he doesnt record that in the replay
20140418 21:49:39< iceiceice> instead he goes back in time to the replay start
20140418 21:49:42< iceiceice> and updates the side tag
20140418 21:49:54< iceiceice> thats how it currently works in 1.10 anyways
20140418 21:50:09< iceiceice> so if you want to make any controller stuff replay safe at all
20140418 21:50:21< iceiceice> or give the observer any chance to correctly save games and replays of something that he joins,
20140418 21:50:30< iceiceice> you need to change it so that you dont rewrite history on the server
20140418 21:50:33< iceiceice> and record controller changes
20140418 21:50:59< iceiceice> so the first thing i tried was, why not just write the controller change messages to the history, duh?
20140418 21:51:06< gfgtdf> iceiceice: so record_change_controller is only pushed in teh hitory not sended to the players ?
20140418 21:51:11< iceiceice> thats right
20140418 21:51:14< iceiceice> only observers see it
20140418 21:51:22< iceiceice> basically only replay.cpp will ever see it
20140418 21:51:27< iceiceice> so its interesting,
20140418 21:51:34< iceiceice> it might be that instead of "record_change_controller"
20140418 21:51:39< iceiceice> i should just make it "change_controller"
20140418 21:51:46< iceiceice> but have the replay.cpp handle differently than the regular game
20140418 21:51:54< iceiceice> because what i initially tried was to just store change_controller,
20140418 21:51:57< iceiceice> but what happens is,
20140418 21:52:01< iceiceice> sometimes when the current side is changed,
20140418 21:52:09< iceiceice> the play_controller will automatically reset the turn counter back
20140418 21:52:13-!- kex [~kex@79.126.245.90] has joined #wesnoth-dev
20140418 21:52:17< iceiceice> e.g. if it was a human you might have to reinit the sides or something...
20140418 21:52:21< iceiceice> and you cant do any of that in a replay
20140418 21:52:47< iceiceice> it might be that you could make the replay code smart, and handle "change_controller" the way that i want to in the case "is_replay = true" or something
20140418 21:52:49< gfgtdf> playturns restart shoudnt change teh turn count.
20140418 21:53:03< iceiceice> i will show you:
20140418 21:54:41< iceiceice> https://github.com/wesnoth/wesnoth/blob/master/src/playturn.cpp#L227
20140418 21:54:46< iceiceice> this stuff about turn restart
20140418 21:54:52< iceiceice> i think its totally unsafe in replay
20140418 21:54:58< iceiceice> at least htat was based on testing i did before PR 121
20140418 21:55:08< iceiceice> keep in mind i developed this on the master before 121 was merged
20140418 21:56:03< gfgtdf> iceiceice: playturn.cpp isnt used in watich replays at all
20140418 21:56:18< gfgtdf> playturn.cpp is only used durign networked games
20140418 21:56:30< iceiceice> i think it may be used when an observer joins a game
20140418 21:56:34< iceiceice> and is going through the replay
20140418 21:56:36< gfgtdf> yes in this case it is
20140418 21:56:40< iceiceice> yes so that is the problem
20140418 21:56:47< gfgtdf> but not in the replay controller i mean
20140418 21:56:50< iceiceice> oh ok
20140418 21:56:51-!- kex [~kex@79.126.245.90] has quit [Ping timeout: 240 seconds]
20140418 21:57:40< iceiceice> it is unfortunate that we have two code paths for htat
20140418 21:58:13< gfgtdf> ye but the eplacontroller is mainly used for ui think ,showing teh "splay side" "Srop replay" buttons and such
20140418 21:58:19< gfgtdf> things
20140418 21:59:01< gfgtdf> iceiceice: hm ok but i think i agree with you that the old syten was very unsafe
20140418 21:59:55< iceiceice> it was actually somewhat worse than that,
20140418 21:59:58< iceiceice> before i started changing things,
20140418 22:00:07< iceiceice> in fact the server would rewrite history at the start so that all controller types were human
20140418 22:00:09-!- neXyon [~neXyon@178-191-221-44.adsl.highway.telekom.at] has quit [Quit: bye]
20140418 22:00:20< iceiceice> i never really understood the rationale for this
20140418 22:00:34< iceiceice> i think it was a workaround for some ancient bug
20140418 22:00:44< iceiceice> but the consequence was,
20140418 22:01:05< iceiceice> if you were playing a mp campaign or scenario which had ai sides with allow player = no,
20140418 22:01:13< iceiceice> then whenever an observer joined, those sides would become human
20140418 22:01:21< iceiceice> just for that obsrever
20140418 22:01:31< iceiceice> if i understand correctly
20140418 22:01:53< iceiceice> anyways i think it is basically the cause of some of the advice they give about safely reloading mp campaigns,
20140418 22:02:01< iceiceice> if you ever dc from such a game, you cannot just rejoin and take control,
20140418 22:02:16< iceiceice> because your controllers will be fubar and if you try to save and reload later, you'll get oos because of these ai sides
20140418 22:03:06< iceiceice> so anyways the point of record_change_controller is to try to fix this
20140418 22:03:19< iceiceice> i'm wondering now if i did it worng though,
20140418 22:03:32< iceiceice> maybe the client handler needs to be in replay.cpp and also playturn.cpp
20140418 22:03:55< iceiceice> it was a while ago that i was developing this, i cant remember why i did it the way i did
20140418 22:03:56< gfgtdf> iceiceice: but when you now receive a normal [change_colroller] that still doesnt get into the replay and the the cientsided created replays will might still cause OOS ?
20140418 22:04:54< iceiceice> i'm not sure what exactly now means,
20140418 22:05:02< iceiceice> in 1.10 it is ok for clients that dont rejoin,
20140418 22:05:02< gfgtdf> on curretn master
20140418 22:05:19< iceiceice> on current mastera and in 1.10 clients that dont rejoin are fine
20140418 22:05:24< iceiceice> because they take change_controller when it is relayed
20140418 22:05:28< iceiceice> and handle it properly afaik
20140418 22:05:43< gfgtdf> but they dont store it on the replay i think
20140418 22:05:45< gfgtdf> store*
20140418 22:05:50< gfgtdf> in*
20140418 22:06:17< iceiceice> thats true
20140418 22:06:20< iceiceice> but their snapshot will at least be good
20140418 22:06:24< gfgtdf> ye
20140418 22:06:34< iceiceice> so it is definitely in all versions very unsafe to read side.controller
20140418 22:06:43< gfgtdf> ye
20140418 22:07:04< gfgtdf> but we still have mp sync  for 'probalby unsafe' things :)
20140418 22:07:08< iceiceice> yeah
20140418 22:07:21< iceiceice> the issue i'm concerned about is, how does the mp player that rejoins a game get a good snap shot eventually
20140418 22:07:40< iceiceice> hmm so in this sense maybe it is fine to rewrite history
20140418 22:07:47< gfgtdf> i thought yiu do that wurth cchange_record_controller ?
20140418 22:07:49< iceiceice> since reading controller types is a bad idea anyways
20140418 22:08:04< gfgtdf> with*
20140418 22:08:11< iceiceice> it might be that just getting rid of the "set all to human" thing will do what i want
20140418 22:08:55< iceiceice> which i already did a month ago
20140418 22:09:09< iceiceice> hmm...
20140418 22:09:23< iceiceice> i am thinking i might just get rid of the record change controller
20140418 22:09:30< iceiceice> and go back to the old rewriting history system
20140418 22:09:34< iceiceice> tell users not to read controllers
20140418 22:09:36< iceiceice> in wml
20140418 22:09:48< iceiceice> or at least, only check if things are ai vs human
20140418 22:10:19< iceiceice> the thing i need to fix is to make sure the "controller tweaks" are happening properly in scenario transitions
20140418 22:10:34< gfgtdf> ye
20140418 22:11:06< iceiceice> ok very good
20140418 22:11:17< iceiceice> i think i will plan to get rid of record change controller and go back to the old system
20140418 22:11:29< gfgtdf> i still wonder how scenario transitions work, especily if for example scenario 2 had more human playable sides than scenario 1, th there an opporinity to add new player beteween scenaros ?
20140418 22:11:47< gfgtdf> is there*
20140418 22:12:04< iceiceice> i think that the key point is whether the scenario transition to has "allow_new_game = yes"
20140418 22:12:11< iceiceice> if so then you will go to the mp connect dialog
20140418 22:12:23< iceiceice> and get a chance to reconfigure, swap people in and out, maybe assign a new side?
20140418 22:12:28< iceiceice> idk if it is advertized in the mp server
20140418 22:12:34< gfgtdf> hm ok
20140418 22:12:41< iceiceice> if you dont have allow_new_game = yes then you are supposed to transition right away
20140418 22:12:48< iceiceice> although you might also go to linger mode
20140418 22:12:58< iceiceice> and any one of these things seems fairly precarious tbh :/
20140418 22:14:06< iceiceice> hmm although here is a problem
20140418 22:14:26< iceiceice> what happens if an observer joins a game, but while he replays there is a change controller event?
20140418 22:14:49< iceiceice> i guess it goes on the backlog and presumably he handles it correctly?
20140418 22:14:57< gfgtdf> which backlog ?
20140418 22:15:02-!- kex [~kex@79.126.245.90] has joined #wesnoth-dev
20140418 22:15:21< iceiceice> while he is replaying there is a big queue of [replay] to process, right?
20140418 22:15:40< gfgtdf> iceiceice: yes, there is a lot of replay
20140418 22:15:50-!- anonymissimus [~chatzilla@HSI-KBW-37-49-94-9.hsi14.kabel-badenwuerttemberg.de] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 11.0/20120312181643]]
20140418 22:15:55< iceiceice> so he is consuming [command]'s at one end
20140418 22:15:59< gfgtdf> yes
20140418 22:16:01< iceiceice> and any news from the server is going in at the other
20140418 22:16:05< gfgtdf> yes
20140418 22:16:26< iceiceice> so i guess i dont understand why its not okay just to save the [change_controller]'s to the replay
20140418 22:16:36< gfgtdf> did i say it's not okay?
20140418 22:16:38< iceiceice> all of them
20140418 22:16:45< iceiceice> idk i tested it once and it seemed to cause problems
20140418 22:17:00< iceiceice> i wonder why we currently aren't doing that
20140418 22:17:03< gfgtdf> on which replay ?
20140418 22:17:11< gfgtdf> servers history_ ?
20140418 22:17:13< iceiceice> yes
20140418 22:17:41< iceiceice> my tests were a while ago, i dont remember exactly what went wrong
20140418 22:17:56< gfgtdf> iceiceice: i did some changes in that with the playturn_network_adaptar.
20140418 22:17:58< iceiceice> but htere are several TODO: comments in the server code "why dont we save these to history"
20140418 22:18:12< gfgtdf> adapter*
20140418 22:18:19< iceiceice> hmm so what's the news?
20140418 22:18:27< gfgtdf> idk in whcih order the server would send them to teh clienz
20140418 22:19:17< iceiceice> what things are you concerned would be out of order?
20140418 22:19:21< gfgtdf> prviously there was no 'queue'
20140418 22:19:42-!- kex [~kex@79.126.245.90] has quit [Ping timeout: 258 seconds]
20140418 22:19:48< iceiceice> there was some kind of backlog thoguh, right?
20140418 22:20:13< gfgtdf> yes but not for things like "change_controller" only for [turn][command]
20140418 22:20:32< iceiceice> hmmm
20140418 22:21:41-!- spoffy [~spoffy@host86-168-246-14.range86-168.btcentralplus.com] has quit [Ping timeout: 250 seconds]
20140418 22:22:47< iceiceice> so why do we need to have change_controller bypass the backlog?
20140418 22:23:08< iceiceice> i mean the server will always handle change_controller simultaneously on all clients and finish those before sending some other command
20140418 22:23:18< iceiceice> is the point that sometimes there is a blocking client or something?
20140418 22:23:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20140418 22:23:55< iceiceice> idk what is the advantage of having it bypass the backlog, i dont see it
20140418 22:24:17< gfgtdf> you mean teh old backlog before 121 ?
20140418 22:24:56< gfgtdf> or the servres history_ ?
20140418 22:25:01< iceiceice> sure, but also tell me what has changed becuase i dont htink i udnerstand
20140418 22:25:12< iceiceice> so the network_adapter has replaced the backog,
20140418 22:25:16< gfgtdf> yes
20140418 22:25:30< iceiceice> and now some of these commands are also placed in queue?
20140418 22:25:30< iceiceice> or all of them?
20140418 22:25:45< gfgtdf> everything we recieve from the server
20140418 22:25:56< iceiceice> i see
20140418 22:26:04< iceiceice> so maybe it is safe now to save change_controller to history
20140418 22:26:16< gfgtdf> i think it's worth a try.
20140418 22:26:21< iceiceice> ok
20140418 22:26:28< iceiceice> i will try it and let you know
20140418 22:27:07< gfgtdf> do you test on 1.12 or master?
20140418 22:27:51< iceiceice> will it make a difference?
20140418 22:29:09< iceiceice> i'll test on both
20140418 22:29:14< gfgtdf> i think now
20140418 22:29:30< gfgtdf> i id some fixed on 1.12 that ar not on master yes but they affect different things
20140418 22:29:34< gfgtdf> fixes
20140418 22:29:41< gfgtdf> now/not
20140418 22:29:48< gfgtdf> id(did
20140418 22:30:10< iceiceice> ok
20140418 22:30:14< iceiceice> be back later
20140418 22:33:27< gfgtdf> iceiceice: wait what happend if you see that a side gets assigned to teh observing observer while the observer seed teh replay? wil the client think he in now in charge of that sidee and can do commands ?
20140418 22:33:37< gfgtdf> sees
20140418 22:33:55< gfgtdf> even if there are still ings on the replay?
20140418 22:33:58< gfgtdf> things*
20140418 22:34:01< iceiceice> that was apparently a bug in old versions of wesnoth :p
20140418 22:35:06< iceiceice> i think that in 1.10 it is basically avoided by not having the controller changes recorded
20140418 22:35:57< gfgtdf> iceiceice: hm ok we can still test it i think.
20140418 22:36:15< iceiceice> i think that what will happen if i do it the way i am thinking is
20140418 22:36:26< iceiceice> when a side is set to human for osme player,
20140418 22:36:33< iceiceice> the server will tell them it is human on their side
20140418 22:36:38< iceiceice> and network on everyone else
20140418 22:36:39< iceiceice> and in the replay
20140418 22:36:42< iceiceice> for observers
20140418 22:36:45< iceiceice> and if it is AI
20140418 22:36:52< iceiceice> it will be ai for that player, and network_ai for everyone else,
20140418 22:36:56< iceiceice> and the history for observers
20140418 22:37:19< iceiceice> my guess is that if a client is told "this side is controlled by network but it is the same name as you" they wont just grab control
20140418 22:37:23< iceiceice> only if it is human
20140418 22:37:48< iceiceice> i will investigate thouh
20140418 22:38:30< iceiceice> ok really be back later this time :p
20140418 22:38:35-!- iceiceice [~chris@cpe-66-108-20-80.nyc.res.rr.com] has quit [Quit: Leaving]
20140418 22:38:52< gfgtdf> iceiceice: yes i think that could work
20140418 23:02:42< cib0> Is there a way to get the width/height of a map from WML/lua?
20140418 23:06:43< cib0> Ah, store_map_dimensions. Silly me, was looking in direct action WML.
20140418 23:07:03-!- Necrosporus_ [~Necrospor@unaffiliated/necrosporus] has joined #wesnoth-dev
20140418 23:10:05-!- Necrosporus [~Necrospor@unaffiliated/necrosporus] has quit [Ping timeout: 252 seconds]
20140418 23:18:01< gfgtdf> fendin_: s there a reason why in https://github.com/wesnoth/wesnoth/commit/95ecd0c70114138d395cc975472151a8844b9f1c, we place the units in the turn 1 side 1 event and not in teh start event ?
20140418 23:18:12< gfgtdf> a
20140418 23:24:53-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds]
20140418 23:25:19-!- Duthlet [~Duthlet@wesnoth/mp-mod/Duthlet] has quit [Quit: leaving]
20140418 23:31:17< aquileia> fendrin_: ^
20140418 23:35:14-!- molgrum [~molgrum@212.85.89.43] has quit [Quit: Lämnar]
20140418 23:36:44< gfgtdf> cib0: note that you can disable teh behaviour we tlked byout earlier with remove_from_carryover_on_leaders_loss
20140418 23:36:53< gfgtdf> in scenariowml
20140418 23:41:02-!- bumbadadabum_ [~bumbadada@d155109.upc-d.chello.nl] has joined #wesnoth-dev
20140418 23:41:10-!- bumbadadabum_ [~bumbadada@d155109.upc-d.chello.nl] has quit [Client Quit]
20140418 23:48:20-!- justinzane [~justinzan@host-12-172-184-180.nctv.com] has joined #wesnoth-dev
--- Log closed Sat Apr 19 00:00:12 2014