--- Log opened Fri May 01 00:00:47 2009
20090501 00:11:19-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzz"]
20090501 00:11:58-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20090501 00:13:07-!- Lord_Aether [n=castle@206.170.190.49] has quit []
20090501 00:23:13-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has quit ["On the road again"]
20090501 00:23:22-!- giusef [n=giusef@unaffiliated/giusef] has joined #wesnoth-dev
20090501 00:28:21-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20090501 00:36:36-!- ilor [n=user@wesnoth/developer/ilor] has quit []
20090501 00:37:35-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Read error: 104 (Connection reset by peer)]
20090501 00:52:17-!- Gnutoo [n=gnutoo@host70-36-dynamic.117-80-r.retail.telecomitalia.it] has joined #wesnoth-dev
20090501 01:01:02-!- Zen_Clark [n=user@99-136-80-191.lightspeed.rcsntx.sbcglobal.net] has joined #wesnoth-dev
20090501 01:08:10-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"]
20090501 01:19:47< Crab_> lol, after my recent work, ai.cpp is *exactly* 2000 lines long, by chance :)
20090501 01:23:03-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has quit ["ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]"]
20090501 01:34:10< CIA-30> crab * r35364 /trunk/ (19 files in 3 dirs): 
20090501 01:34:10< CIA-30> AI refactoring: split ai_interface into three parts: 1) ai_interface - interface
20090501 01:34:10< CIA-30> between the ai and the game 2) ai_game_info - information about the game for the
20090501 01:34:10< CIA-30> AI (former ai_interface::info) 3) ai_readwrite_context - interface between the
20090501 01:34:10< CIA-30> ai and ai components. Removed ai_interface code from ai/ai.cpp (this removed
20090501 01:34:13< CIA-30> ~20% from ai/ai.cpp, and, accidentally, left ai/ai.cpp exactly 2000 lines long)
20090501 01:36:14< Polarina> Who cares that it's exactly 2000 lines long?
20090501 01:36:28< crimson_penguin> Polarina: I thought it was amusing
20090501 01:36:34< Crab_> Polarina: no one ) but it's simply amusing.
20090501 01:36:46 * crimson_penguin likes big round numbers
20090501 01:36:54< crimson_penguin> you know really they should be called square numbers
20090501 01:37:04< Polarina> "Oh no! Only 1999 lines of code, let me just add a comment over there."
20090501 01:37:08< crimson_penguin> since when is the action of "rounding" anything like a circle, or roundness?
20090501 01:37:19< crimson_penguin> Polarina: yes, but it was by chance!
20090501 01:37:22< Crab_> Polarina: the main point that I haven't done anything with it :)
20090501 01:37:43< Crab_> Polarina: just done a wc -l before commit to see how much I've moved to other files :)
20090501 01:38:14< Polarina> wc -w is more interesting.
20090501 01:39:04-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit []
20090501 01:47:05-!- cjhopman [n=chris@wesnoth/developer/cjhopman] has joined #wesnoth-dev
20090501 01:51:24< Crab_> night )
20090501 01:51:24-!- Crab_ [n=Crab_@wesnoth/developer/crab] has quit ["Leaving."]
20090501 01:53:41-!- Netsplit bartol.freenode.net <-> irc.freenode.net quits: ABCD_, wesbot, Gnutoo, yann, dfranke
20090501 01:54:25-!- Netsplit over, joins: wesbot, dfranke, Gnutoo, ABCD_, yann
20090501 01:54:25-!- Elvish_Pillager [n=eli@24-183-181-144.dhcp.oxfr.ma.charter.com] has quit [Read error: 110 (Connection timed out)]
20090501 01:54:51-!- Elvish_Pillager [n=eli@24-183-181-144.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20090501 02:08:12-!- Gnutoo [n=gnutoo@host70-36-dynamic.117-80-r.retail.telecomitalia.it] has quit [Read error: 60 (Operation timed out)]
20090501 02:11:31-!- Gnutoo [n=gnutoo@host70-36-dynamic.117-80-r.retail.telecomitalia.it] has joined #wesnoth-dev
20090501 02:17:20-!- noy [n=Noy@d75-157-39-176.bchsia.telus.net] has joined #wesnoth-dev
20090501 02:21:13-!- Elvish_Pillager [n=eli@24-183-181-144.dhcp.oxfr.ma.charter.com] has quit ["Hi! I'm a quit message virus vaccine. If you see a quit message virus, don't replace your quit message with it!"]
20090501 02:23:39-!- giusef [n=giusef@unaffiliated/giusef] has quit ["exit (-1);"]
20090501 02:24:17-!- coldeq [n=coldeq@ppp121-44-155-124.lns10.syd7.internode.on.net] has quit ["Leaving"]
20090501 02:27:26< ancestral> Just a question, as we're playing a game right now and want to unmute
20090501 02:27:38< ancestral> Is this still a feature request? https://gna.org/bugs/?7547
20090501 02:42:13 * Polarina writes a music.
20090501 02:43:24-!- Gnutoo [n=gnutoo@host70-36-dynamic.117-80-r.retail.telecomitalia.it] has quit [Read error: 113 (No route to host)]
20090501 03:03:14-!- Polarina [n=polarina@wesnoth/translator/Polarina] has quit ["Leaving."]
20090501 03:05:20-!- Polarina [n=polarina@wesnoth/translator/Polarina] has joined #wesnoth-dev
20090501 03:09:59< Polarina> http://simnet.is/gabrielp/something.ogg
20090501 03:14:15< Polarina> Anyone likes that? :)
20090501 03:17:34-!- Appleman1234 [n=Appleman@131.181.47.1] has joined #wesnoth-dev
20090501 03:30:26< Zen_Clark> Polarina: Pretty good. Little short, with simple tones, but pretty good.
20090501 03:30:46< Polarina> Zen_Clark: :)
20090501 03:34:48-!- fabi [n=fabi@e176232076.adsl.alicedsl.de] has joined #wesnoth-dev
20090501 03:48:33-!- fendrin [n=fabi@wesnoth/developer/fendrin] has quit [Read error: 110 (Connection timed out)]
20090501 03:49:34 * Shadow_Master redirects Polarina to /dev/bed
20090501 03:49:57< Polarina> Shadow_Master: You didn't like it?
20090501 03:50:46< ancestral> Polarina: Mainline it! :P
20090501 03:51:07< Shadow_Master> no, I haven't listened to it because I cannot use speakers here, and my headphones are too far away
20090501 03:51:16< Shadow_Master> but you should be in bed AFAICT ;)
20090501 03:53:38-!- Zen_Clark [n=user@99-136-80-191.lightspeed.rcsntx.sbcglobal.net] has quit ["Dexter's Lab is on now."]
20090501 04:02:46-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20090501 04:27:18-!- happygrue_ [n=George@c-67-176-145-41.hsd1.in.comcast.net] has joined #wesnoth-dev
20090501 04:27:35-!- [Relic] [n=[Relic]@adsl-76-229-202-137.dsl.milwwi.sbcglobal.net] has joined #wesnoth-dev
20090501 04:28:32< [Relic]> Hello :)
20090501 04:43:43-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 113 (No route to host)]
20090501 05:02:07-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit [Remote closed the connection]
20090501 05:10:34-!- crimson_p [n=irchon@64.201.60.216] has joined #wesnoth-dev
20090501 05:12:33-!- crimson_p [n=irchon@64.201.60.216] has quit [Remote closed the connection]
20090501 05:22:16-!- tsr_ [n=tsr@c213-89-114-91.bredband.comhem.se] has joined #wesnoth-dev
20090501 05:23:33-!- tsr__ [n=tsr@c213-89-114-91.bredband.comhem.se] has quit [Read error: 110 (Connection timed out)]
20090501 05:25:38-!- crimson_penguin [n=ben@64.201.60.216] has joined #wesnoth-dev
20090501 05:26:45-!- ABCD_ [n=abcd@wikipedia/ABCD] has quit ["leaving"]
20090501 05:39:26-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20090501 05:42:47-!- tsr_ [n=tsr@c213-89-114-91.bredband.comhem.se] has quit ["Ex-Chat"]
20090501 05:43:26-!- xonev [n=chatzill@59.92.6.75] has joined #wesnoth-dev
20090501 05:48:38-!- ancestral [n=ancestra@97-116-120-23.mpls.qwest.net] has quit []
20090501 05:55:11-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20090501 06:47:44-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20090501 07:04:58-!- ancestral [n=ancestra@97-116-120-23.mpls.qwest.net] has joined #wesnoth-dev
20090501 07:05:56-!- happygrue_ [n=George@c-67-176-145-41.hsd1.in.comcast.net] has quit [Read error: 110 (Connection timed out)]
20090501 07:22:44-!- [Relic] [n=[Relic]@adsl-76-229-202-137.dsl.milwwi.sbcglobal.net] has quit ["Leaving"]
20090501 08:02:19-!- Sirp [n=me@wesnoth/developer/dave] has quit ["leaving"]
20090501 08:27:39-!- xonev [n=chatzill@59.92.6.75] has quit [Read error: 110 (Connection timed out)]
20090501 08:40:46-!- xonev [n=chatzill@59.92.6.75] has joined #wesnoth-dev
20090501 08:50:27-!- EdB [n=edb@207.117.88-79.rev.gaoland.net] has joined #wesnoth-dev
20090501 08:51:29-!- mordante [n=mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20090501 08:51:52< mordante> hi
20090501 08:52:28< EdB> hello mordante
20090501 08:52:37< mordante> hi EdB 
20090501 09:16:32-!- Appleman1234 [n=Appleman@131.181.47.1] has quit [Read error: 110 (Connection timed out)]
20090501 09:21:37-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev
20090501 09:24:16-!- turin [n=turin@168.215.250.18] has quit [Read error: 110 (Connection timed out)]
20090501 09:34:54-!- Reisiger [n=Reisiger@adsl-84-226-65-137.adslplus.ch] has joined #wesnoth-dev
20090501 09:36:10< Reisiger> Good morning :)
20090501 09:42:48-!- Netsplit bartol.freenode.net <-> irc.freenode.net quits: erl
20090501 09:43:36-!- Netsplit over, joins: erl
20090501 09:44:33< mordante> hi Reisiger 
20090501 09:55:19-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20090501 09:55:51< boucman> hey all
20090501 09:58:11< mordante> hi boucman 
20090501 09:58:22< boucman> hey mordante how is it going ?
20090501 09:59:02< mordante> good :-) I finally managed to get some things done yesterday
20090501 09:59:08< mordante> and with you?
20090501 10:00:25-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20090501 10:00:36< silene> hi
20090501 10:00:39< mordante> hi silene 
20090501 10:00:46< boucman> I had a busy week, and I4m going to have a busy WE
20090501 10:00:47< Reisiger> Good morning silene
20090501 10:01:03< boucman> I'll stick around, but won't code much this WE
20090501 10:02:36< mordante> I had that a few weeks ago and it feels good to finally have time for Wesnoth hacking again
20090501 10:12:07< Reisiger> Q: Anyone here who could look at the VC9 wesnoth.vcproj maintenance patch? http://www.wesnoth.org/forum/viewtopic.php?p=354943#p354943 MSVC chokes on a removed cpp file otherwise :o)
20090501 10:12:50-!- Crab_ [n=Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20090501 10:12:54< Crab_> hi
20090501 10:13:38< Reisiger> morning Crab_ :)
20090501 10:13:52< boucman> morning Crab_
20090501 10:13:56< boucman> how is it going ?
20090501 10:14:21-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"]
20090501 10:15:16< Reisiger> Crab_: Do you have MSVC?
20090501 10:15:43< mordante> hi Crab_ 
20090501 10:15:58< Crab_> Reisiger: can install it, but I don't have it at the moment
20090501 10:16:03< Crab_> hi mordante
20090501 10:17:42< boucman> Crab_: your stat site is online (just mentionning in case it's a bug and not you turning it off)
20090501 10:17:53< Reisiger> Crab_: I made a patch ( http://www.wesnoth.org/forum/viewtopic.php?p=354943#p354943 ) to solve a compile error due to missing/moved/deleted resource files in wesnoth.vcproj. Could you please have a look at it?
20090501 10:18:59< Crab_> boucman: yes, my stat web interface should/will be always online. It is located on a colocated server.
20090501 10:19:16< boucman> ok, so it is a bug :P
20090501 10:19:56< Crab_> boucman: 'boucman: Crab_: your stat site is online'. so, what's the bug ?
20090501 10:20:14< boucman> Crab_: I mean offline :P
20090501 10:20:18< boucman> I get connection faile
20090501 10:20:23< Crab_> hehe ) online for me - http://aitest.wesnoth.org/
20090501 10:20:28< boucman> http://crab.terraninfo.net/data/misc/wesnoth_ai_test2.php
20090501 10:20:34< boucman> ok, changing my bookmark
20090501 10:22:26< Crab_> boucman: at the moment, I'm preparing to make a modular copy of default ai
20090501 10:22:39< boucman> sounds good
20090501 10:22:51< boucman> I see you have splited the ai in multiple files some more
20090501 10:22:54< boucman> that's good
20090501 10:23:22< Crab_> boucman: yes, I've split ai interface into several parts
20090501 10:25:05-!- Chusslove [n=caslav@brsg-d9bee9d0.pool.mediaWays.net] has joined #wesnoth-dev
20090501 10:27:58< Crab_> boucman: 1) ai_interface -  first part is the 'contract' for the ai from the point-of-view of the game  2) ai_readonly_context and ai_readwrite_context - second part is the 'contact' for the ai from the point-of-view of 'ai part', note that 'readonly/readwrite - in regards to the game state, not in regards to ai, so just using 'const' was not an option)  
20090501 10:27:59< Crab_>  3) ai_game_info - old ai_interface::info, but it will be expanded later to deal with subjective state.
20090501 10:29:26< boucman> so ai_interface is how AI pass info to the game, and AI context is the game as seen by the AI (readonly being the real one, readwrite being the tweaked one)
20090501 10:29:30< boucman> that 's  it .
20090501 10:29:36< boucman> ?
20090501 10:29:47< Crab_> no
20090501 10:30:28-!- ancestral [n=ancestra@97-116-120-23.mpls.qwest.net] has quit ["And that’s the end of THAT chapter."]
20090501 10:30:28< Crab_> so ai_interface is methods that are called by the game when it needs something from the ai. namely - play_turn and new_turn.
20090501 10:30:57< Crab_> and ai context is the convenience methods which are available when we work in a 'context' of a specific ai
20090501 10:32:05< Crab_> for example, if you know the side, you may get the team for that side with ai_manager::get_info().teams[side-1]; 
20090501 10:32:08< Crab_> but this is ugly
20090501 10:32:34< Crab_> so, you should have a 'helper object' which knows that 'side', and can provide a current_team() method
20090501 10:33:19< boucman> ok, make sense
20090501 10:33:21< Crab_> this helper object is needed 1) in the ai   2) in the parts of the ai    3) in formula ai functions
20090501 10:33:43< Crab_> so, for now, the ai "extends" that object.
20090501 10:34:15< Crab_> so, ai has access to that helpers as in the days of old ( .current_team()  )
20090501 10:34:43-!- loonybot [n=loonybot@79.139.247.143] has joined #wesnoth-dev
20090501 10:34:43< Crab_> and parts of the ai / formula_ai functions will get a reference to the ai and use ai_.current_team()
20090501 10:35:05< Crab_> for now, formula_ai functions get a reference to formula_ai in that cases
20090501 10:35:32< Crab_> this is 'overkill' and makes it harder to 'include' formula functions to evaluate things from default_ai.
20090501 10:35:45-!- loonycyborg [n=sergey@79.139.247.143] has joined #wesnoth-dev
20090501 10:36:27< Crab_> and the old system also leads to code duplication in formula_ai functions (see nearest_keep_function , for example)
20090501 10:36:39< boucman> ok, make sense
20090501 10:37:35< Crab_> the helper functions in ai_read[only|write]context should be ai-independent, to allow us to keep only one copy of contexts.[ch]pp around.
20090501 10:37:59< boucman> ok
20090501 10:40:39< Crab_> the next step for me is to search through the default ai and group all functions used there into two categories: ai-independent (so, they will be moved to ai_contexts or to ai_interface) and ai-dependent.
20090501 10:40:53< Crab_> ('ai-dependent' is those which make *decisions*)
20090501 10:40:57-!- YogiHH [n=chatzill@d028081.adsl.hansenet.de] has joined #wesnoth-dev
20090501 10:41:17< boucman> Crab_: you should also upgrade the AI you test on your server to make sure you didn't break anything
20090501 10:41:38< boucman> (I can't see how you would have with this change, but... we have nasty suprises with AI)
20090501 10:42:17< Crab_> boucman: yes, I will, but this will only be a partial test (since I've got only 1 ai to test)
20090501 10:42:38< Crab_> boucman: but this is basically a 'pull up' refactoring.
20090501 10:42:55< boucman> kk
20090501 10:43:03< Crab_> boucman: since ai_*_context are superclasses of default ai
20090501 10:44:05< Crab_> then comes the fun part - I will need to make a 'copy' of all default_ai files into separate files (maybe, a separate subdir), and split that copy into pieces.
20090501 10:44:06< Ivanovic> moin
20090501 10:44:16-!- giusef [n=giusef@unaffiliated/giusef] has joined #wesnoth-dev
20090501 10:44:18< Crab_> morning, Ivanovic
20090501 10:44:24< boucman> hehe
20090501 10:44:47< Crab_> boucman: then, I'll code a 'composite ai whose turn sequence is a vector of stages' (this is simple)
20090501 10:44:48< YogiHH> helllo everyone
20090501 10:45:10< YogiHH> mordante: have you seen my commit yesterday about the minimap?
20090501 10:45:37< Crab_> boucman: then, I'll make an ai with an 'RCA phase', and plug those pieces of default_ai's copy into it.
20090501 10:45:56< Crab_> boucman: then there will be a good place to test. default_ai vs rca_default_ai
20090501 10:45:58< mordante> hi Ivanovic 
20090501 10:46:15< mordante> YogiHH, yes, but haven't had a closer look, will do so later
20090501 10:46:39< mordante> first want to get some unit tests for the dialogs in
20090501 10:47:07< Crab_> boucman: and it will be no problem if something is broken then - since default_ai will sit there untouched.
20090501 10:47:15< YogiHH> mordante: np. I just feel better then, as i don't pretend i knew what i was doing there, especially not considering draw_background, which i only copied from the panel :-)
20090501 10:47:19< boucman> sounds good
20090501 10:47:43< Crab_> so, that default_ai will sit there as a 'benchmark ai', for a long while.
20090501 10:47:57< mordante> :-)
20090501 10:48:28< Crab_> then, I'll extract rca_default_ai's stage configuration to a separate C++ or WML file.
20090501 10:49:23< Crab_> boucman: this will allow us to test different variants of the RCA ai. - we can, for example, add formula candidate actions and see if they make things better or worse
20090501 10:49:42< boucman> yes, that sounds good
20090501 10:51:22< Crab_> boucman: that ai will have many different kinds of pieces, not only 'candidate actions'
20090501 10:53:58< Crab_> boucman: when adding those files, I'll also do a few renames to drop the ai_ prefix from ai_manager, ai_configuration, ai_actions, ai_interface
20090501 10:55:42< boucman> ok, makes sense now that they have their own directory
20090501 10:55:51< Crab_> boucman: what is the best way to organize files from different ai's ? 
20090501 10:57:24< boucman> I'd say a subdirectory per AI with identical filenames
20090501 10:57:39< boucman> ai/default/
20090501 10:57:42< boucman> ai/testing/
20090501 10:58:54< boucman> bbiam
20090501 11:03:49< Crab_> boucman: so, it will look like this - http://wesnoth.pastebin.com/m79b1d362
20090501 11:06:21-!- noy [n=Noy@d75-157-39-176.bchsia.telus.net] has joined #wesnoth-dev
20090501 11:09:53-!- euschn [n=chatzill@wesnoth/developer/euschn] has joined #wesnoth-dev
20090501 11:09:58< euschn> hi
20090501 11:10:13< boucman> Crab_: that's what I had more or less in mind
20090501 11:10:27< boucman> what exactly do you mean by "good" in your list ?
20090501 11:10:48< Crab_> Reisiger: about your patch - it's better to ask someone who already has MSVC about it )
20090501 11:11:58< Crab_> boucman: it is basically a note about the ai - is it 'competetive and good' or is it 'stub' (as idle_ai, ai2, dfool_ai, simple_ai)
20090501 11:12:23< boucman> ok
20090501 11:12:25< Reisiger> Crab_: True. I'll need to have a look on other files not in the vcproj which MSVC doesn't seem to care about anyway o_O
20090501 11:13:51< Crab_> boucman: ok. I'm afk for 10 min, then present for ~15 min, then afk till evening. 
20090501 11:14:19< boucman> k
20090501 11:15:31< mordante> hi euschn 
20090501 11:19:17-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 11:22:34< silene> Crab_: note that there was a time where dfool ai was working well (better than the default ai, i mean); i don't think the game concepts have changed much since then, so it may still be good, if it still works
20090501 11:24:58-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20090501 11:25:49< Crab_> silene: interesting
20090501 11:26:06< Crab_> silene: i'll test it )
20090501 11:26:15< boucman> Crab_: could you test that with your current framework ?
20090501 11:26:21< Crab_> boucman: yes
20090501 11:26:51< boucman> cool
20090501 11:27:56< silene> unfortunately, since it hasn't been actively tested/maintained, it may just as well have bitrotten and segfault as soon as you launch it ;-)
20090501 11:28:24< Crab_> silene: we'll see :)
20090501 11:29:01-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20090501 11:29:14< boucman> silene: don't worry, Crab_'s test framework handles crashes properly ;)
20090501 11:30:02< Ivanovic> you mean the ai crashing is a clear win for the opponent?
20090501 11:30:04< Ivanovic> ^^
20090501 11:36:45< Crab_> silene, boucman: unfortunately, dfool_ai is unusable at the moment (it doesn't grab any villages or recruit any units)
20090501 11:37:11< boucman> k
20090501 11:37:21< Crab_> Ivanovic: ai crashing is a 'failed matchup', although it is possible to figure out which side crashed (since recent version logs per-turn-per-side info)
20090501 11:39:07-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Read error: 60 (Operation timed out)]
20090501 11:43:49-!- Crab_ [n=Crab_@wesnoth/developer/crab] has quit ["Leaving."]
20090501 11:47:12-!- giusef [n=giusef@unaffiliated/giusef] has quit ["exit (-1);"]
20090501 11:55:40< silene> YogiHH: did you change the loadgame dialog? the minimap preview is now stuck to the right
20090501 11:56:10< YogiHH> silene: no, i only reactivated drawing for the minimap
20090501 11:56:28< YogiHH> silene: for the new minimap widget, that is
20090501 12:04:34< CIA-30> jhinrichs * r35365 /trunk/src/ (menu_events.cpp playcampaign.cpp savegame.cpp savegame.hpp): 
20090501 12:04:34< CIA-30> Savegame reorganization Step 1: Providing a simpler interface to saving and loading.
20090501 12:04:34< CIA-30> Makes the interface more consistent by clearly separating between automatic and interactive saves.
20090501 12:09:12-!- wesbot changed the topic of #wesnoth-dev to: accepted students for SoC: http://socghop.appspot.com/org/home/google/gsoc2009/wesnoth | 63 bugs, 236 feature requests, 11 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20090501 12:13:41-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 12:14:37< YogiHH> Soliton: i refactored the savegame code such that automatic saves can be done with or without overwriting. So the mailing list question is kind of obsolete now.
20090501 12:15:16< YogiHH> Soliton: at least from a coding point of view
20090501 12:16:23< Soliton> ok. saves are not such a problem anyway rather replays but i guess that's the same.
20090501 12:16:43< YogiHH> yes
20090501 12:32:16-!- Gnutoo [n=gnutoo@host70-36-dynamic.117-80-r.retail.telecomitalia.it] has joined #wesnoth-dev
20090501 12:32:27-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090501 12:36:42-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 12:42:31-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Read error: 54 (Connection reset by peer)]
20090501 12:46:36-!- Reisiger [n=Reisiger@adsl-84-226-65-137.adslplus.ch] has quit ["Verlassend"]
20090501 12:49:10-!- euschn [n=chatzill@wesnoth/developer/euschn] has quit [Read error: 104 (Connection reset by peer)]
20090501 12:49:27-!- euschn [n=chatzill@wesnoth/developer/euschn] has joined #wesnoth-dev
20090501 12:51:08-!- fabi [n=fabi@wesnoth/developer/fendrin] has quit [Remote closed the connection]
20090501 12:56:02-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 12:58:43-!- EdB [n=edb@207.117.88-79.rev.gaoland.net] has quit [Remote closed the connection]
20090501 13:09:41-!- coldeq [n=coldeq@ppp121-44-155-124.lns10.syd7.internode.on.net] has joined #wesnoth-dev
20090501 13:26:44-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Read error: 104 (Connection reset by peer)]
20090501 13:26:57< YogiHH> euschn: off for a while, will be back in the evening hours
20090501 13:27:33-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 13:45:49< CIA-30> esr * r35366 /trunk/data/campaigns/Eastern_Invasion/scenarios/01.The_Outpost.cfg: Address bug #13462.
20090501 13:50:55-!- coldeq [n=coldeq@ppp121-44-155-124.lns10.syd7.internode.on.net] has quit ["leaving"]
20090501 13:53:25-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 110 (Connection timed out)]
20090501 13:54:49-!- YogiHH [n=chatzill@d028081.adsl.hansenet.de] has left #wesnoth-dev []
20090501 14:38:48-!- Reisiger [n=Reisiger@adsl-84-226-65-137.adslplus.ch] has joined #wesnoth-dev
20090501 14:53:39-!- Reisiger [n=Reisiger@adsl-84-226-65-137.adslplus.ch] has quit [Read error: 104 (Connection reset by peer)]
20090501 14:59:12-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090501 15:06:56-!- Reisiger [n=Reisiger@adsl-89-217-1-86.adslplus.ch] has joined #wesnoth-dev
20090501 15:12:23-!- crimson_p [n=irchon@64.201.60.216] has joined #wesnoth-dev
20090501 15:13:57-!- crimson_p [n=irchon@64.201.60.216] has quit [Remote closed the connection]
20090501 15:44:03-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20090501 15:44:31-!- crimson_penguin [n=ben@64.201.60.216] has joined #wesnoth-dev
20090501 15:44:42-!- xonev [n=chatzill@59.92.6.75] has quit ["ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]"]
20090501 16:04:15< CIA-30> silene * r35367 /trunk/src/language.cpp: Made the code readable.
20090501 16:04:26-!- Reisiger [n=Reisiger@adsl-89-217-1-86.adslplus.ch] has quit [Read error: 104 (Connection reset by peer)]
20090501 16:05:02-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 16:14:30-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit [Read error: 60 (Operation timed out)]
20090501 16:16:12-!- maxy [n=maxy@80-219-0-199.dclient.hispeed.ch] has joined #wesnoth-dev
20090501 16:21:03-!- crimson_penguin [n=ben@64.201.60.216] has joined #wesnoth-dev
20090501 16:22:03-!- EdB [n=edb@241.12.95-79.rev.gaoland.net] has joined #wesnoth-dev
20090501 16:24:50-!- Dragonking [n=dk@wesnoth/developer/dragonking] has joined #wesnoth-dev
20090501 16:25:01< Dragonking> hello everyone
20090501 16:26:55< mordante> hi Dragonking 
20090501 16:28:50< euschn> hi Dragonking
20090501 16:43:25-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090501 16:51:06-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 16:59:29-!- stikonas_ [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 17:02:16< CIA-30> mordante * r35368 /trunk/src/CMakeLists.txt: 
20090501 17:02:16< CIA-30> Change the way the editor files are added in cmake.
20090501 17:02:16< CIA-30> The new way is the same as scons and automake. This will fix some issues
20090501 17:02:16< CIA-30> I had with the not yet committed new unittests.
20090501 17:05:29-!- stikonas__ [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 17:10:19< CIA-30> mordante * r35369 /trunk/src/ai/ai_actions.cpp: Initialize all members.
20090501 17:10:30< CIA-30> mordante * r35370 /trunk/src/astarsearch.cpp: Initialize all members.
20090501 17:10:36< CIA-30> mordante * r35371 /trunk/src/game_events.cpp: Initialize all members.
20090501 17:10:39< CIA-30> mordante * r35372 /trunk/src/loadscreen.cpp: Initialize all members.
20090501 17:10:43< CIA-30> mordante * r35373 /trunk/src/log.cpp: Initialize all members.
20090501 17:10:44-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)]
20090501 17:10:49< CIA-30> mordante * r35374 /trunk/src/pathfind.cpp: Initialize all members.
20090501 17:10:52< CIA-30> mordante * r35375 /trunk/src/savegame.cpp: Initialize all members.
20090501 17:10:57< CIA-30> mordante * r35376 /trunk/src/scripting/lua.cpp: Initialize all members.
20090501 17:11:01< CIA-30> mordante * r35377 /trunk/src/server/server.cpp: Initialize all members.
20090501 17:11:06< CIA-30> mordante * r35378 /trunk/src/terrain.cpp: Initialize all members.
20090501 17:11:15< CIA-30> mordante * r35379 /trunk/src/unit_types.cpp: Initialize all members.
20090501 17:11:19-!- turin [n=turin@168.215.250.18] has joined #wesnoth-dev
20090501 17:14:14-!- stikonas__ is now known as stikonas
20090501 17:19:37< CIA-30> silene * r35380 /trunk/src/pathfind.cpp: Improved the pathfinder by making it touch only the visited nodes. Should noticeably speed up the AI.
20090501 17:20:40-!- stikonas_ [n=quassel@ctv-213-164-108-14.vinita.lt] has quit [Read error: 110 (Connection timed out)]
20090501 17:26:07< CIA-30> mordante * r35381 /trunk/po/wesnoth-lib/POTFILES.in: Fix the POTFILES.in with a recent movement.
20090501 17:27:37< CIA-30> mordante * r35382 /trunk/ (5 files in 3 dirs): 
20090501 17:27:37< CIA-30> Add a new unit test for gui2.
20090501 17:27:37< CIA-30> Not all dialogs have been implemented yet, but they'll follow later.
20090501 17:49:38-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev
20090501 17:53:30-!- fendrin [n=fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20090501 18:09:12-!- wesbot changed the topic of #wesnoth-dev to: accepted students for SoC: http://socghop.appspot.com/org/home/google/gsoc2009/wesnoth | 64 bugs, 236 feature requests, 11 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20090501 18:14:49< CIA-30> silene * r35383 /trunk/src/ (29 files in 3 dirs): The dependency graph of Wesnoth is plain idiotic. As if pathfind.cpp needed to depend on font.hpp...
20090501 18:14:55-!- euschn [n=chatzill@wesnoth/developer/euschn] has quit ["ChatZilla 0.9.84 [Firefox 3.0.7/2009030423]"]
20090501 18:15:45-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["KVIrc 3.4.2 Shiny http://www.kvirc.net/"]
20090501 18:16:21-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20090501 18:16:55-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090501 18:22:44-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 18:35:03-!- stikonas_ [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 18:45:07-!- stikonas__ [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 18:52:46-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)]
20090501 18:55:20-!- stikonas__ [n=quassel@ctv-213-164-108-14.vinita.lt] has quit [Remote closed the connection]
20090501 18:58:25< CIA-30> silene * r35384 /trunk/po/wesnoth/fr.po: Typo.
20090501 18:58:54-!- Crab_ [n=Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20090501 19:00:10< CIA-30> silene * r35385 /branches/1.6/po/wesnoth/fr.po: Typo.
20090501 19:00:16< Crab_> silene: regarding "Improved the pathfinder by making it touch only the visited nodes. Should noticeably speed up the AI.", how large speedup is expected ?
20090501 19:00:23-!- stikonas_ [n=quassel@ctv-213-164-108-14.vinita.lt] has quit [Read error: 110 (Connection timed out)]
20090501 19:02:27< silene> Crab_: it depends, i tried on a large map with lots of units; the AI started to move units almost immediately instead of computing for about 10s; but i didn't measure it precisely
20090501 19:03:02< Crab_> silene: ok ) I will try to measure (I log game duration, too, in my ai tester)
20090501 19:05:05< silene> Crab_: to give you an idea, on a 100x100 map, the time needed for computing the srcdst map should (theoretically) be divided by 100
20090501 19:05:22< Crab_> silene: great )
20090501 19:06:17< mordante> nice silene :-)
20090501 19:07:56< cjhopman> silene: no way.
20090501 19:08:29< silene> cjhopman: why not? you were scanning the 100x100 nodes, while my patch scans only 10x10 nodes (for a unit with movement 5)
20090501 19:16:15< cjhopman> the "no way" is that there is no way that it would be divided by 100
20090501 19:16:41< cjhopman> but, it should be faster
20090501 19:17:26-!- noy [n=Noy@70.70.224.183] has joined #wesnoth-dev
20090501 19:21:58< silene> cjhopman: i wouldn't be so sure it can't be divided by 100; think about it: modifying 100x100 nodes, that's 320K of memory, that's the L1 cache of your processor being evicted 20 times; modifying 10x10 nodes only, the L1 cache is preserved at 70%
20090501 19:24:36< silene> in fact, i should have said 40 times, since your algorithm was touching the 100x100 nodes twice per run
20090501 19:25:39< silene> knowing that accessing outside the L1 cache is at least 10 times slower, the pathfinder may in fact be 400x faster now
20090501 19:25:56< CIA-30> mordante * r35386 /trunk/src/gui/widgets/grid.cpp: 
20090501 19:25:58< CIA-30> Disable an assert which gets triggered.
20090501 19:26:00< CIA-30> This assert shouldn't be triggered, but adding a workaround fixes the
20090501 19:26:02< CIA-30> issue. (The problem was discovered by YogiHH).
20090501 19:26:04< CIA-30> mordante * r35387 /trunk/src/gui/widgets/ (minimap.cpp minimap.hpp): 
20090501 19:26:06< CIA-30> Some minimap improvements.
20090501 19:26:08< CIA-30> Draw on the background again and integrate the drawing with the helper
20090501 19:26:12< CIA-30> routine.
20090501 19:26:14< CIA-30> mordante * r35388 /trunk/src/gui/ (auxiliary/layout_exception.hpp widgets/window.cpp): 
20090501 19:26:16< CIA-30> Change the new layout algorithm to use exceptions.
20090501 19:26:18< CIA-30> Like the current algorithm it now throws an WML exception if the dialog
20090501 19:26:20< CIA-30> doesn't fit on the screen.
20090501 19:29:48< cjhopman> silene: don't worry, i'll profile it quick
20090501 19:29:58-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20090501 19:34:31-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 19:36:30< cjhopman> on a 60x60 board it is about 12% faster
20090501 19:38:24-!- EdB [n=edb@241.12.95-79.rev.gaoland.net] has quit [Remote closed the connection]
20090501 19:39:40-!- Einherjer [n=Einherje@c-98-220-192-27.hsd1.il.comcast.net] has quit ["Leaving"]
20090501 19:42:42< cjhopman> which I would agree is noticeably faster, but it's no 400 times or even 4 times
20090501 19:52:30< CIA-30> mordante * r35389 /trunk/src/gui/widgets/ (window.cpp window.hpp window_private.hpp): 
20090501 19:52:30< CIA-30> Window code cleanups.
20090501 19:52:30< CIA-30> Since the last commit the return value of NEW_layout was no longer used. Moved
20090501 19:52:30< CIA-30> the file to a new separate header so it's easier to add new private functions
20090501 19:52:30< CIA-30> without the need to recompile the universe.
20090501 19:54:58< Crab_> silene: after 66 tries of new svn release, it takes 1.24 seconds per ai turn, and old one takes 1.31 seconds per ai turn (2 sides)
20090501 20:00:28< Ivanovic> sounds like a nice improvement anyway
20090501 20:00:42< cjhopman> Crab_: i feel that a lot of that difference is not because of that change... on a map like you are using, profiling shows no difference between the two
20090501 20:00:48< Ivanovic> what about "bad case" situations like really many units on a really big map?
20090501 20:01:17< cjhopman> Ivanovic: my 12% improvement is 9 ai each with 1000 gold on a 60x60 map
20090501 20:01:50< cjhopman> for 6 turns
20090501 20:02:02< Crab_> cjhopman: well, no other changes were done to the ai, and the logging level has even increased to log per-turn info
20090501 20:02:18< silene> cjhopman: just to be sure, the 12% improvement was what? the time needed to finish the 6 turns?
20090501 20:02:19< cjhopman> Crab_: yeah, i think its probably just a matter of them not being the same games
20090501 20:02:39< cjhopman> silene: its comparison between the two find_routes methods
20090501 20:03:16< cjhopman> so, not just that final loop includes the pathfinding part too
20090501 20:03:20< mordante> ilor, can you have a look at this patch later? http://www.wesnoth.org/forum/viewtopic.php?p=354943#p354943
20090501 20:04:09< cjhopman> silene: I run them both in the same game.... basically each find_routes call actually calls them each once
20090501 20:04:28< cjhopman> so then I know they both have to calculate the same thing
20090501 20:04:41< ilor> mordante: why later when I can do it now ;)
20090501 20:05:09< silene> cjhopman: you mean that you run one after the other?
20090501 20:05:13< mordante> ilor, also good, just that it has no hurry ;-)
20090501 20:06:29< cjhopman> silene: i do
20090501 20:07:01< cjhopman> do you expect that to bias it? if so, for which the first or the second?
20090501 20:07:22< mordante> ilor, YogiHH and I fixed the minimap and I want to look at the tabsheet this weekend (not sure whether I can finish it then)
20090501 20:07:42< mordante> and I'm also busy with the 4 button generic message dialog
20090501 20:08:11< silene> cjhopman: yes, it biases it, since the cache will be trashed
20090501 20:08:38< Ivanovic> boucman: this patch is assigned to you and marked "in progress" for a while already, what is the current status? https://gna.org/patch/?1148
20090501 20:09:20< cjhopman> I can test them separately too... won't take more than a couple minutes
20090501 20:11:41< Crab_> after 100 tries, I have even 1.20 seconds per turn (vs 1.31)
20090501 20:11:58< ilor> mordante: nice, hopfully I'll do something project-related this weekend
20090501 20:12:23< mordante> ilor, school project or wesnoth project?
20090501 20:12:40-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 113 (No route to host)]
20090501 20:13:24< ilor> mordante: wesnoth, obviously ;)
20090501 20:13:38< mordante> cool :-)
20090501 20:18:25< CIA-30> zookeeper * r35390 /branches/1.6/data/campaigns/Eastern_Invasion/scenarios/05.Northern_Outpost.cfg: Fixed Owaec's portrait not appearing for about the tenth time.
20090501 20:19:13< ilor> mordante: I'll commit as soon as I can confirm it links okay
20090501 20:19:29< mordante> ok
20090501 20:19:47< CIA-30> zookeeper * r35391 /trunk/data/campaigns/Eastern_Invasion/scenarios/05.Northern_Outpost.cfg: Ported r35390 to trunk.
20090501 20:19:53< cjhopman> Crab_: that would equate to about a 30-40% speedup of that pathfinding... which I would now believe
20090501 20:20:02< ilor> mordante: also, anyone thought about giving commit access to the guys that somehwat regularly update project files?
20090501 20:20:20< Crab_> cjhopman: 100 tries is too low. there's a lot of random noise there.
20090501 20:20:56< mordante> ilor, I'm not against that as long as they know they're only supposed to commit project file updates and know how to handle svn
20090501 20:21:03< cjhopman> Crab_: true... you could do test them with the same rng seeds
20090501 20:21:06< mordante> Ivanovic, what do you think? ^^
20090501 20:21:26< Crab_> cjhopman: this would not be representative )
20090501 20:21:38< cjhopman> i mean, like 100 different seeds
20090501 20:21:51< cjhopman> but the same ones between the two
20090501 20:22:08< mordante> especially regarding Reisiger, since he's around here quite often
20090501 20:22:59< cjhopman> silene: separating them shows the new one at about 19% faster
20090501 20:23:15< zookeeper> mordante, i'll leave the gold carryover bug report to you now? looks like it's an engine bug, would you agree?
20090501 20:25:02< mordante> I haven't looked further at it yet but if it's an engine bug somebody should fix it
20090501 20:25:35< mordante> but at the moment I want to focus on the gui stuff since I've a lot of bugs regarding them assigned to me
20090501 20:25:52< mordante> so I'm a bit reluctant to look at more bugs
20090501 20:26:07-!- stikonas [n=quassel@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20090501 20:26:54< zookeeper> sure, no problem
20090501 20:27:36< cjhopman> silene: I feel that that optimization is something that I should have noticed... but oh well, I'm still new at this
20090501 20:27:37< Ivanovic> mordante: hmm, good question
20090501 20:27:54< zookeeper> should i just reassign to none or assing to you and mark as postponed and tell him to handle the gold/side change manually in WML?
20090501 20:28:30< mordante> rather to none, somebody else with more time might want to look at it
20090501 20:29:14-!- noy [n=Noy@wesnoth/developer/noy] has quit [Connection timed out]
20090501 20:29:52< Ivanovic> zookeeper: could you have a look at completing this one? https://gna.org/bugs/index.php?13462
20090501 20:30:05< Ivanovic> and also at handling this one? https://gna.org/bugs/index.php?13464
20090501 20:32:27< zookeeper> i already did the latter one a moment ago
20090501 20:32:39< zookeeper> and yeah, i could do the first one too..
20090501 20:33:48-!- Elvish_Pillager [n=eli@24-183-181-144.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20090501 20:40:43< CIA-30> ilor * r35392 /trunk/projectfiles/VC9/wesnoth.vcproj: vc9 project file update from Reisiger
20090501 20:40:58< ilor> mordante:^ 
20090501 20:41:01< mordante> thanks
20090501 20:41:09< mordante> Chusslove, around?
20090501 20:41:19< CIA-30> zookeeper * r35393 /trunk/data/campaigns/Eastern_Invasion/scenarios/01.The_Outpost.cfg: Re-fix bug #13462 simply by putting him on side 2 instead.
20090501 20:44:13< CIA-30> zookeeper * r35394 /branches/1.6/data/campaigns/Eastern_Invasion/scenarios/01.The_Outpost.cfg: Ported r35393 to 1.6.
20090501 20:45:38< Chusslove> mordante: Yep.
20090501 20:46:22< mordante> Chusslove, I asked esr for a pofix feature request, but I think it fits more with your po validation script
20090501 20:47:22< mordante> there are strings that have a space as last character eg "unit: " and these spaces are sometimes omitted in the translation
20090501 20:47:57< mordante> so it would be nice if there was test to see whether the original string ends in a space and give a warning if the translation doesn't
20090501 20:48:20< Chusslove> mordante: One needs to thread carefully there, as there are sometimes also superfluous spaces at the end, which (at least I) do not carry over into translation.
20090501 20:48:36< Chusslove> How about checking for space just after colon?
20090501 20:48:57< Chusslove> I.e. is there another valid case of trailing space?
20090501 20:49:52-!- Netsplit bartol.freenode.net <-> irc.freenode.net quits: Gnutoo, Rhonda, turin, fendrin, johani, silene, crimson_penguin, ikarius
20090501 20:49:59< Polarina> http://simnet.is/gabrielp/planxty-carolan.ogg  :)
20090501 20:50:08< zookeeper> Ivanovic, done
20090501 20:50:47< Ivanovic> zookeeper: for the first one esr already commited some fix to trunk only
20090501 20:51:11-!- Rhonda [n=alfie@wesnoth/developer/rhonda] has joined #wesnoth-dev
20090501 20:51:20< mordante> Chusslove, there's also a combined string in the tutorial that ends with ", "
20090501 20:51:25-!- Netsplit over, joins: turin, crimson_penguin, silene
20090501 20:51:30< Chusslove> Ok, comma too.
20090501 20:51:42-!- Netsplit over, joins: fendrin, Gnutoo, ikarius, johani
20090501 20:51:42< Chusslove> Space after dot is the one I wouldn't force.
20090501 20:51:58< mordante> depends sometimes two strings are combined
20090501 20:52:01< Soliton> Chusslove: if there are superfluous trailing spaces then you should report them and not silently fix them in your translation.
20090501 20:52:11< Ivanovic> jupp
20090501 20:52:20< mordante> seems Soliton stole my next sentence ;-)
20090501 20:52:38< Chusslove> That's a point :)
20090501 20:53:56< zookeeper> Ivanovic, yeah, i overwrote that one
20090501 20:54:04< Ivanovic> zookeeper: ah, oka
20090501 20:54:05< Ivanovic> y
20090501 20:55:05< silene> mordante: what is the string that ends with ", " in the tutorial?
20090501 20:58:52< mordante> silene, I remembered wrong it was a dot instead of comma; For this tutorial, you are playing Konrad. "
20090501 20:59:45< silene> mordante: okay, the comma would have make it hard to translate, that's why i was a bit surprised
20090501 21:00:47-!- cjhopman [n=chris@wesnoth/developer/cjhopman] has quit [Success]
20090501 21:06:34-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"]
20090501 21:24:21-!- YogiHH [n=chatzill@d081127.adsl.hansenet.de] has joined #wesnoth-dev
20090501 21:24:31< YogiHH> hello everyone
20090501 21:25:22< mordante> hi YogiHH 
20090501 21:25:53< mordante> YogiHH, I made some modification to the minimap and fixed the assertion failure you ran into yesterday
20090501 21:26:07< YogiHH> ok
20090501 21:30:36-!- noy [n=noy@wesnoth/developer/noy] has joined #wesnoth-dev
20090501 21:32:13-!- stikonas [n=quassel@ctv-213-164-108-14.vinita.lt] has joined #wesnoth-dev
20090501 21:33:46-!- cjhopman [n=chris@wesnoth/developer/cjhopman] has joined #wesnoth-dev
20090501 21:41:57-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev
20090501 21:42:02< Chusslove> mordante: Nevertheless I think we have to limit the trailing space check; I'm counting 2600 matching trailing whitespace, and 1800 nonmatching. By language: http://rafb.net/p/FnDtcD82.html
20090501 21:42:25< CIA-30> mordante * r35395 /trunk/src/gui/widgets/ (window.cpp window.hpp): Add linked widgets in the new layout algorithm.
20090501 21:42:36< CIA-30> mordante * r35396 /trunk/src/gui/widgets/window.cpp: 
20090501 21:42:36< CIA-30> Replace the layout algorithm.
20090501 21:42:36< CIA-30> The new algorithm seems to be at par with the old algorithm so make the
20090501 21:42:36< CIA-30> new one the algorithm used. The algorithm still needs some polishing but
20090501 21:42:36< CIA-30> the big problem is the old algorithm which doesn't know about the new
20090501 21:42:38< CIA-30> scrollbar mode. So once this algorithm gets a bit more testing in trunk
20090501 21:42:40< CIA-30> the old algorithm can be removed and this one can get polished.
20090501 21:44:09< mordante> Chusslove, I'm afk will be back in 90 minutes, can you send me the results of the German translation
20090501 21:44:33< mordante> and I still think most are valid in default mode in po edit you don't see the trailing spaces
20090501 21:44:47< mordante> afk
20090501 21:44:55< Chusslove> mordante: In my language, out of 48 hits, only one is really wrong.
20090501 21:46:41-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20090501 21:49:36-!- maxy [n=maxy@80-219-0-199.dclient.hispeed.ch] has quit []
20090501 21:50:49< CIA-30> jhinrichs * r35397 /trunk/src/savegame.cpp: Remove an unnecessary assignment.
20090501 21:51:01< Crab_> zookeeper: can you tell me something about WML events interaction with shroud updates ?  Example situation: http://wesnoth.pastebin.com/m5ce40672
20090501 21:51:27< Crab_> zookeeper: how it *should* work ?
20090501 21:51:51-!- loonybot [n=loonybot@79.139.247.143] has joined #wesnoth-dev
20090501 21:53:00< Crab_> ( silene: it's related to that bug 13256 you've commented on recently )
20090501 21:53:35-!- loonycyborg [n=sergey@79.139.247.143] has joined #wesnoth-dev
20090501 21:54:42< YogiHH> hmm, is it me or does the wiki miss a nice central navigation? There seem to be a lot of pages you will never find unless you know they exist.
20090501 21:54:44< silene> Crab_: yes; note that the sighted event is fundamentally incompatible with the way we handle delayed updates, so we may just as well get rid of it
20090501 21:55:27< silene> (you don't even have to kill units in order to have issues with this event)
20090501 21:56:38< Crab_> silene: yes, and so I'm not really sure how to fix that bug - one of the solutions is to fire additional apply_shroud_changes_without_firing_sighted_events+clear_undo_stack *at start* of [kill] and other such events
20090501 21:56:57< Crab_> but this may lead to 'oh, my sighted event hasn't fired!' bugs
20090501 21:57:00< silene> Crab_: that's how i would fix it too
20090501 21:57:46< silene> Crab_: i seem to remember Sapient wanted to deprecate the sighted event, but i'm not sure
20090501 21:58:24< Crab_> another solution is to rework delayed_shroud_changes to fire 'moveto' events only on applying shroud changes
20090501 21:59:21< Crab_> it all starts even better if we want to make certain events undoable :)
20090501 22:00:01< silene> Crab_: that's not good, since you may have moved other units since then, so by the time moveto is raised, the situation may be completely different
20090501 22:00:13< YogiHH> silene: that's correct, the sighted event is still considered to be buggy and experienced WML creators work around it atm
20090501 22:00:53< silene> Crab_: just imagine a trap that's supposed to spring once a unit enters a room, so that it gets isolated; if the moveto event is delayed, the player will have time to move its whole army inside the room
20090501 22:02:07< Crab_> silene: yes. just imagine a trap that's supposed to spring once a unit sights a specific enemy (which requires moving into a room), so that it gets isolated; if the sighted event is delayed, the player will have time to move its whole army inside the room
20090501 22:02:53< Crab_> note that there's around 54 'sighted' events in mainline campaigns
20090501 22:04:31< silene> great
20090501 22:04:45< Crab_> another type of 'fix' is to make delayed_shroud_updates less powerful: we can 'check for sighted' events  and apply_shroud_changes immediately if a sighted event should be fired from unit on this location.
20090501 22:05:30< Crab_> basically, if 'moveto' events trigger immediately while using delayed_shroud_updates, why should 'sighted' events be delayed ?
20090501 22:05:51< silene> agreed
20090501 22:06:38< Crab_> this will trigger those events in the same wat both with delayed_shroud_updates, and without it.
20090501 22:06:42< Crab_> s/wat/way
20090501 22:07:26< Crab_> note that 'delayed_shroud_updates less powerful' will only matter if sighted events related to that unit are actually present in the scenario
20090501 22:07:39-!- cjhopman_ [n=chris@dyn-0-158.uwnet.wisc.edu] has joined #wesnoth-dev
20090501 22:09:51-!- cjhopman [n=chris@wesnoth/developer/cjhopman] has quit [Read error: 110 (Connection timed out)]
20090501 22:15:00< zookeeper> Crab_, urgh, that's pretty complicated.
20090501 22:16:13< zookeeper> (i mean the thing you asked me)
20090501 22:16:37< Crab_> zookeeper: yes. that's why opinions are needed. the current idea is ' make delayed_shroud_updates less powerful: check for sighted events  and apply_shroud_changes immediately if a sighted event should be fired from unit on this location.'. So, 'sighted' events will "interrupt a move, and apply shroud updates" at start of actually executing that 'sighted' event.
20090501 22:16:43< zookeeper> franky, i don't know how sighted events "should" work
20090501 22:17:28< Crab_> in my example question, this will be ( A->B-> 'sighted' event, at start of which we apply shroud changes->teleport to Z )
20090501 22:17:45< zookeeper> Crab_, i think it'd be really good to have that sort of behaviour. however, i think we still need the old behaviour for some things.
20090501 22:17:52< Crab_> zookeeper: why ?
20090501 22:18:05< Crab_> imagine a player without delayed_shroud_updates moving units 1 hex a time.
20090501 22:18:15< Crab_> nothing will change for him )
20090501 22:18:30< zookeeper> because sometimes it really makes sense to trigger something only when the player will actually sees something, not when he would see them if he had delay shroud updates off.
20090501 22:18:42< zookeeper> for example for tutorialish purposes
20090501 22:19:01< Crab_> zookeeper: well, this trigger will apply_shroud_changes at start of event - so, the player *will* see )
20090501 22:19:05< zookeeper> or when the player needs to actually find some unit
20090501 22:19:16< zookeeper> yes, i know, but that's not the same thing
20090501 22:19:47< Crab_> zookeeper: note the same can be said about 'moveto' event, which triggers immediately.
20090501 22:20:15< zookeeper> i think it's a mistake to have just one kind of a sighted event, regardless of which way it works...there's always some cases where the other behaviour would be better
20090501 22:20:40< zookeeper> one size just can't fit all in this case, IMO
20090501 22:21:28< CIA-30> ivanovic * r35398 /trunk/po/ (wesnoth-units/sk.po wesnoth-utbs/sk.po): updated Slovak translation
20090501 22:21:32< CIA-30> ivanovic * r35399 /branches/1.6/po/ (wesnoth-units/sk.po wesnoth-utbs/sk.po): updated Slovak translation
20090501 22:21:42< zookeeper> oh, wait. now i see what you actually suggested with your "make delayed_shroud_updates less powerful". no please no :)
20090501 22:21:56< Crab_> zookeeper: why ?
20090501 22:22:08< Crab_> zookeeper: note that 'moveto' event already works this way.
20090501 22:22:29< zookeeper> did you mean that you'd change how the delay shroud updates option works even when there's no sighted or moveto events?
20090501 22:22:33-!- noy [n=noy@wesnoth/developer/noy] has quit ["Get Colloquy for iPhone! http://mobile.colloquy.info/"]
20090501 22:22:40< Crab_> zookeeper: no
20090501 22:22:48< zookeeper> ok, great. it sounded a bit like that ;)
20090501 22:22:49-!- noy [n=noy@wesnoth/developer/noy] has joined #wesnoth-dev
20090501 22:22:53< Crab_> zookeeper: see the current situation with moveto event: 
20090501 22:23:14< Crab_> delayed_shroud_updates is ON, we move to hex C, and moveto event fires immediately.
20090501 22:23:48< Crab_> 'moveto' event is not delayed until 'applying of shroud updates'
20090501 22:23:52< zookeeper> yep
20090501 22:24:23< Crab_> but 'sighted' event works differently, not consistently with 'moveto'. 'sighted' events are only fired when shroud updates are applied.
20090501 22:24:49< Crab_> this leads to chaos in situations like aforementioned example, which has both 'sighted' and 'moveto'
20090501 22:25:39< zookeeper> Crab_, this is kinda off-topic, but somewhat related: i think ideally the delay shroud updates option would be replaced with some kind of an option for a general "planning mode", in which moveto or any other events wouldn't trigger.
20090501 22:25:52< Crab_> zookeeper: this is on-topic.
20090501 22:25:58< zookeeper> or rather, you couldn't make anything actually "happen"
20090501 22:26:13< Crab_> zookeeper: this is another valid solution. note silene's objection to it
20090501 22:26:32< Crab_> "10:58:38 PM) silene: Crab_: just imagine a trap that's supposed to spring once a unit enters a room, so that it gets isolated; if the moveto event is delayed, the player will have time to move its whole army inside the room"
20090501 22:27:06< zookeeper> well, that's not exactly related to what i'm trying to describe
20090501 22:27:29< Crab_> zookeeper: ok ) then describe it more :)
20090501 22:27:37< zookeeper> sure, give me a minute...
20090501 22:29:05< zookeeper> you see, in my "planning mode" you wouldn't actually be making any moves. when you'd exit the mode, your units would just be where they were when you entered it. it'd just be a tool for checking out defense values, how leadership affects your damage and stuff. you wouldn't even reveal hidden enemy woses while in it.
20090501 22:29:11< Crab_> zookeeper: As I understand your proposal, you're talking about 'virtual planning mode' where player is able to move units to specified positions, but no events will fire (the moves won't be actually 'made') until some magic button is pressed...
20090501 22:29:27< zookeeper> yes
20090501 22:29:36-!- cjhopman [n=chris@wesnoth/developer/cjhopman] has joined #wesnoth-dev
20090501 22:29:43< zookeeper> i'm not sure if it should involve a magic button which would execute your planned moves
20090501 22:30:18< Crab_> zookeeper: magic button = as 'apply_shroud_updates' of today
20090501 22:30:30< zookeeper> since then we run into problems when those planned moves can't be executed, for example because a unit is unexpectedly ambushed (which didn't happen in the planning mode)
20090501 22:31:10< Crab_> zookeeper: this can be dealt by executing orders one-by-one, and stopping the execution (reverting to planning mode with the remaining units in the new situation)
20090501 22:32:11< Crab_> (stopping the execution in case of unexpected situation)
20090501 22:33:43< zookeeper> yeah
20090501 22:33:52< zookeeper> but it's still pretty complicated to the player, i suppose
20090501 22:34:42< Crab_> yes, it is harder to say 'which units have moved and which are just planned to move'
20090501 22:35:09< Crab_> but this will fix the moveto-sighted-undo inconsistency, as well
20090501 22:35:30< zookeeper> yes
20090501 22:35:45< zookeeper> which is a pretty big good aspect ;)
20090501 22:36:09< Crab_> so the question is: what to do ? current behavior is buggy, and should be changed, but in what direction ?
20090501 22:36:13-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["KVIrc 3.4.2 Shiny http://www.kvirc.net/"]
20090501 22:36:49-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20090501 22:36:52< Crab_> A) drop sighted events sometimes  B) make sighted events fire immediately, even in 'delayed' mode  C) make moveto events delayed in delayed mode.
20090501 22:38:17< zookeeper> D) two separate event types for both moveto and sighted events, one which won't fire in delayed mode and one which will?
20090501 22:38:39< zookeeper> so the author can decide which behaviour fits his particular event best
20090501 22:38:57< Crab_> so D = let the author deside between (A) and (B) ?
20090501 22:39:36< zookeeper> yeah. i think that'd be better than forcing either of them...unless we could really make a perfect planning mode.
20090501 22:40:03< Crab_> note that there's less problems with 'immediate firing events'. they're just less buggy :)
20090501 22:40:16< Crab_> compare the amount of bugs with 'sighted' and 'moveto'
20090501 22:40:25< zookeeper> oh, definitely.
20090501 22:40:37-!- cjhopman_ [n=chris@wesnoth/developer/cjhopman] has quit [Connection timed out]
20090501 22:41:05< Crab_> silene: what do you think about all this ?
20090501 22:42:38-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has joined #wesnoth-dev
20090501 22:42:54< silene> i would favor B
20090501 22:43:55< Crab_> I too. I don't like 'events that are not guaranteed to fire' in prescribed circumstances.
20090501 22:44:46< zookeeper> well, is there a problem with also guaranteeing that sighted events will fire?
20090501 22:45:35< zookeeper> (IIRC the problem with them now is that a sighted event for A sighting B won't trigger if it's B's turn and B moves into A's vision)
20090501 22:45:54< Crab_> zookeeper: well, see that example again. if we don't fire sighted event immediately, it won't take effect if unit is killed in 'moveto' event
20090501 22:46:19< Crab_> 'sighted event for A sighting B won't trigger if it's B's turn and B moves into A's vision' is a different problem, and it is easier, imo
20090501 22:47:21< zookeeper> ok, is there a particular reason why you're worried about events which involve teleporting or killing units?
20090501 22:48:19< zookeeper> it sounds so complicated that i don't think anyone should try to write WML like that anyway and expect foolproof behaviour ;)
20090501 22:48:31< Crab_> https://gna.org/bugs/?13256, 
20090501 22:49:01< Crab_> for example. all it requires is a single 'moveto' kill event and fog enabled
20090501 22:49:51< Crab_> but fixing it requires dealing with apply_shroud_changes, and apply_shroud_changes throws 'sighted' events, and so they should be dealt with. so the question arises.
20090501 22:51:23 * zookeeper nods to make it look like he understands it all
20090501 22:51:35< Crab_> and note https://gna.org/bugs/?13440
20090501 22:52:00< Chusslove> mordante: When you're back: http://caslav.gmxhome.de/misc/msgs-nomatch-trws-de.out
20090501 22:53:24< Crab_> zookeeper:  1) "killing a unit should unvalidate all undo moves, including those which are not related to this unit"   2) invalidating undo moves requires applying shroud changes   3) applying shroud changes triggers 'sighted' events  4) the question was: "what to do with them?"
20090501 22:53:54< silene> Chusslove: frightening, how come there are so many strings with a trailing space...
20090501 22:54:16< Chusslove> Well... whadda I know :)
20090501 22:56:14< zookeeper> Crab_, them == the sighted events? well, trigger them? :p sorry if i'm a bit slow tonight
20090501 22:57:04< Crab_> zookeeper: ok. and what to do if that 'sighted' event was related to that unit that was just killed (in step 1) :) ?
20090501 22:57:44< zookeeper> i'd say it shouldn't trigger, since the undo invalidation and shroud updates happen _after_ the unit has been killed.
20090501 22:58:24< Crab_> zookeeper: that is variant "A) drop sighted events sometimes" :)
20090501 22:58:37< zookeeper> right
20090501 22:58:41< Crab_> zookeeper: and that is also a valid solution to the assertion failures
20090501 22:58:42< silene> zookeeper: but what about sighted events for other units? should they be dropped too? since they can also affect the dead unit
20090501 22:58:56< zookeeper> silene, how could they affect the dead unit?
20090501 22:59:12< Crab_> zookeeper: they can teleport it to a safe place
20090501 23:00:03< Crab_> basically, if we just drop sighted events, we will (sometimes) have situations which are impossible from a logical point of view.
20090501 23:00:30< zookeeper> i mean, if the sighted event filters on the dead unit, then obviously it won't match and therefore trigger at all, because the unit ain't there
20090501 23:00:48< silene> zookeeper: unit A moves, unit B moves, unit B triggers a moveto event that will kill it, shroud updates causing unit A to trigger a sighted event
20090501 23:02:09< silene> so event for B has started, while event for A was delayed and is then executed after while it happened before
20090501 23:03:24-!- noy [n=noy@wesnoth/developer/noy] has quit ["Get Colloquy for iPhone! http://mobile.colloquy.info/"]
20090501 23:04:17< zookeeper> i'm not sure i see the problem or why it'd be illogical. i mean, sighted events are from the player's POV clearly tied to what he sees. i don't think it's illogical that in that case A's sighted event fires after B's moveto event.
20090501 23:05:08< Crab_> zookeeper: for example, the unit may move to a location without seeing it.
20090501 23:05:08< silene> zookeeper: it's illogical because it should have happened before B moved
20090501 23:05:11< zookeeper> even though the move which brought A into the place where he gets to sight whatever he sights happens before the move which actually clears the shroud and allows A to see
20090501 23:05:15< zookeeper> silene, why?
20090501 23:05:55< ilor> has anyone here tried using git on windows?
20090501 23:07:24< zookeeper> i think we just have different ideas of what a sighted event should be.
20090501 23:08:01< Crab_> zookeeper: define a triggering condition for a 'sighted' event, then
20090501 23:10:28< silene> zookeeper: my idea of what a sighted event can be is what the engine allows it to be ;-) in particular, it is a plain event; any actions available to other events are available to it
20090501 23:11:01< zookeeper> well, as i said i'd rather have multiple different event types than just one
20090501 23:11:34< zookeeper> i'll try to describe some possibilities..
20090501 23:12:19< silene> zookeeper: adding an additional event type won't solve the issue for the existing one; that's orthogonal
20090501 23:12:44-!- Elvish_Pillage2 [n=eli@24-183-181-144.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20090501 23:12:44-!- Elvish_Pillager [n=eli@24-183-181-144.dhcp.oxfr.ma.charter.com] has quit [Read error: 110 (Connection timed out)]
20090501 23:12:54< zookeeper> silene, i'd also change the existing one
20090501 23:13:21< zookeeper> two clearly different types for clearly different situations
20090501 23:14:44< silene> will there be a delayed event in your two types? if so, the bug will reappear
20090501 23:15:41-!- chains [n=Rylar@adsl-69-209-64-30.dsl.chcgil.sbcglobal.net] has joined #wesnoth-dev
20090501 23:17:41< mordante> Chusslove, I think we should still look at your warnings, but run it after we ran pofix on trunk to get rid of those extra spaces
20090501 23:18:52< ilor> mordante: do you know how long should a git svn rebase take for a week-full of commits?
20090501 23:19:10< mordante> mainly depends on your internet speed
20090501 23:19:13< YogiHH> http://www.wesnoth.org/wiki/DevelopersHome
20090501 23:19:18< Crab_> ilor: extrapolate using commit numbers
20090501 23:19:30< mordante> rebase itself seems fast only disable automatic gc operations
20090501 23:19:31< silene> ilor: the rebase itself is instant, it's the fetch that may take time
20090501 23:19:41< ilor> I did fetch then rebase
20090501 23:20:04< mordante> git svn is not efficient and it often triggers a gc operation
20090501 23:20:10< ilor> fetch took some time grabbing commits in turn, rebase is working for 5 minutes now without any sign of life
20090501 23:20:11< mordante> which is slow
20090501 23:20:48< zookeeper> silene, i don't understand the underlying mechanisms so i really have no idea why the high-level event behaviour has anything to do with assert crashes
20090501 23:20:48< silene> ilor: that's bad, it really should take only a few seconds
20090501 23:21:15< ilor> I can see perl processes spawning and dying frequently so it's doing something
20090501 23:21:25< mordante> that sounds bad
20090501 23:21:28< YogiHH> night everyone
20090501 23:21:33< mordante> night YogiHH 
20090501 23:21:43-!- YogiHH [n=chatzill@d081127.adsl.hansenet.de] has left #wesnoth-dev []
20090501 23:21:47< mordante> not sure how stable git under Windows is 
20090501 23:21:56< zookeeper> "sighted" event: triggers when primary unit is actually visually revealed to the client controlling secondary unit's side. Maybe only trigger only on that client, a bit like select events. Used for "There they are!" dialogue and such. "move-in-range" event: triggers when secondary unit moves so that primary unit ends up in its vision range. Doesn't care whether delay shroud updates is on or not, just about the underlying vision ranges. Used 
20090501 23:22:00< ilor> not very, it seems
20090501 23:22:02< Chusslove> mordante: Mismatch in trailing space would presently outnumber other problems by factor 10. Unless somehow that gets considerably reduced, I'd rather warn only on missing space after colon, or perhaps indeed mass-append those missing spaces to all translations.
20090501 23:22:18< zookeeper> that's basically how i think this stuff should be divided, in some way.
20090501 23:22:28< silene> zookeeper: you have it the irc line limit
20090501 23:22:32< silene> hit*
20090501 23:22:46< mordante> Chusslove, yes that's why I said enable the warning _after_ fixing the english with pofix
20090501 23:23:01< Chusslove> Ook.
20090501 23:23:25< mordante> but the colon is indeed the most common case where it goes wrong
20090501 23:23:30-!- ancestral [n=ancestra@32.151.11.163] has joined #wesnoth-dev
20090501 23:23:31< silene> ilor: you can kill it, it should be safe, and then just restart it by "git rebase trunk"
20090501 23:23:43< zookeeper> silene, "move-in-range" event: triggers when secondary unit moves so that primary unit ends up in its vision range. Doesn't care whether delay shroud updates is on or not, just about the underlying vision ranges. Used for ambush and trap events in which stuff like unit placement or killing actually happens.
20090501 23:24:06< ilor> silene: git svn rebase trunk you mean?
20090501 23:24:17< silene> ilor: no, i don't -)
20090501 23:24:42< zookeeper> silene, of course people could just put their [kill]s in the former event type, but so what? can't we still fix the crashes by more precisely defining the order in which stuff happens?
20090501 23:25:01< silene> ilor: if you have already done a git svn fetch; you don't have to do a svn rebase, you can do a plain rebase
20090501 23:25:12< mordante> Chusslove, and we can add a po comment when the space is required after a dot, esr's new wml-po-extrator can place it in the pot-file
20090501 23:25:22< ilor> silene: I see
20090501 23:25:30< Crab_> zookeeper: your "move-in-range" event is just a 'precisely defining the order in which stuff happens' :)
20090501 23:25:39< zookeeper> i think all this reveals a very subtle fundamental design flaw in wesnoth ;)
20090501 23:25:54-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has quit ["On the road again"]
20090501 23:25:58< Chusslove> mordante: That would be excellent. E.g. if it's not space-after-colon, then needs a keyword in extracted comment.
20090501 23:26:06< ilor> silene: thanks, that was it ;)
20090501 23:26:28< Chusslove> say "trailing-space-significant"
20090501 23:26:52< Crab_> zookeeper: and that 'move-in-range' event is ok
20090501 23:27:25< Crab_> zookeeper: and current 'sighted event' is buggy-by-design in case delay shroud updates is on.
20090501 23:29:32-!- ancestral [n=ancestra@32.151.11.163] has quit ["Get Colloquy for iPhone! http://mobile.colloquy.info/"]
20090501 23:29:36< mordante> Chusslove, that keyword sounds good to me
20090501 23:30:03< zookeeper> Crab_, well, as i said, i think it's more a question of specification. it's not buggy if we specify that this is how it should work...unless you're referring to the actual crashes.
20090501 23:30:19< mordante> and I'm shocked by the number of trailing spaces in the original
20090501 23:32:37< Crab_> zookeeper: i'm referring to the fact that it's behavior and it's 'triggering/not triggering at all' is dependent on delay shroud updates.
20090501 23:34:02< zookeeper> ah
20090501 23:34:33< Crab_> the assertion failures and weird behavior when multiple events interact are just consequences
20090501 23:34:53< zookeeper> i think i finally get what you mean. you're worried about the fact that the same moves (in the same order) lead to the sighted event triggering if delay shroud updates is off, and not triggering if it's on?
20090501 23:35:08< mordante> Ivanovic, do you know how pofix works?
20090501 23:35:13< Crab_> yes, this is another problem.
20090501 23:35:15< silene> zookeeper: yes, that's one of the consequences
20090501 23:36:50< Chusslove> mordante: I've studied it :) It's rather simple-minded. You'd like to append missing spaces?
20090501 23:36:52< zookeeper> that could be solved by always updating shroud and firing sighted events just before firing a moveto event, no?
20090501 23:37:28< zookeeper> i mean, if a move fires a moveto event, then before firing it, update shroud and fire sighted events
20090501 23:37:35< mordante> Chusslove, no rather remove the extra spaces in the original
20090501 23:37:36< zookeeper> that way you couldn't screw up the order, i think
20090501 23:37:58< Crab_> zookeeper: note that we need to fire 'sighted' event exactly on the hex where 'sighted' condition manifests.
20090501 23:38:57< Ivanovic> mordante: no, i don't
20090501 23:38:58< zookeeper> yeah, that's true, and pretty much invalidates what i just said :p
20090501 23:39:20< Ivanovic> mordante: i only know that it is far from perfect since it does *not* support plural forms and thus is unusable on the mainfile
20090501 23:39:26< Chusslove> mordante: It works by just looking for pairs in the file as array of characters:
20090501 23:39:37< Chusslove> ("foo", "bar")
20090501 23:39:52< Crab_> zookeeper: well, what you're just said is very close to option "B"
20090501 23:40:39< Ivanovic> mordante: sounds more like a task fro wmllint to me
20090501 23:40:44-!- loonybot [n=loonybot@79.139.247.143] has joined #wesnoth-dev
20090501 23:40:50< Chusslove> So to replace ending spaces, you'd need to add a long-enough portion (such that it's reasonably unique) of the string before it.
20090501 23:41:15< Chusslove> ("foo bar baz bam \"", "foo bar baz bam\"")
20090501 23:41:32< Crab_> zookeeper: that is 'if there's a sighted event which will fire during a unit movement (ignoring delay_shroud_updates), update shroud and clean undo stack at start of firing that event'
20090501 23:41:32< mordante> Ivanovic, in that case I can do it manually, I just don't want to fuzzy the translation
20090501 23:42:12< Ivanovic> argh, sorry, thought you were talking about po2po
20090501 23:42:28< Ivanovic> pofix does not support any "regular expression" stuff IIRC
20090501 23:42:42< Crab_> zookeeper: and this is "move-in-range" you're described)
20090501 23:43:05< Ivanovic> so you will a) have to add all pairs of strings and b) have to change the date stuff
20090501 23:44:09< Crab_> note that current sighted event is equal to "move-in-range" event in case that we play with NO delayed_shroud_updates and move units 1-hex-a-time
20090501 23:44:25< mordante> and then it changes it in the wml and in the po file?
20090501 23:44:28< Chusslove> If PO files were merged with --previous, I could write a script to unfuzzy on removed trailing space only, in c. 5 mins.
20090501 23:44:57< Ivanovic> mordante: no, it only change the po files
20090501 23:45:03< Ivanovic> you have to change it in the wml files yourself
20090501 23:45:04< Crab_> so, if we want "the same moves (in the same order) should trigger the same events", we will come to the conclusion that 'sighted=move-in-range'
20090501 23:45:08-!- loonycyborg [n=sergey@79.139.247.143] has joined #wesnoth-dev
20090501 23:46:14< Ivanovic> mordante: i'd say collect a list of strings that should be changed and wait for esr being back in some days
20090501 23:46:49< mordante> sounds like the safest plan ;-)
20090501 23:46:51< Ivanovic> then he can add it to the script, the stuff can be removed and such
20090501 23:48:00< mordante> Chusslove, is it easy for you to make a list of all strings with a trailing space in the original?
20090501 23:48:22< Crab_> zookeeper: for example, lets say a WML editor wants to make "when you see the necromancer, he surrounds himself with skeletons" event
20090501 23:48:31< mordante> you're output looks nicer as grep ;-)
20090501 23:48:35< mordante> your*
20090501 23:48:45< Chusslove> mordante: Yep, one-liner.
20090501 23:49:05< Chusslove> mordante: In trunk?
20090501 23:49:12< Ivanovic> trunk only
20090501 23:50:09< Crab_> zookeeper: if we play with delayed_shroud_updates, we can move a unit right next to the necromancer without revealing shroud, and only after we apply shroud changes and the shroud will update - but the skeletons will not be able to shield the necromancer from us - since we will be already next to it.
20090501 23:50:46< Crab_> with  'sighted=move-in-range', everything will work in a consistent way, no matter what 'delayed_shroud_update' is.
20090501 23:50:46< Chusslove> mordante: Perhaps leave out those messages ending in colon and space?
20090501 23:51:40< Crab_> zookeeper: also note https://gna.org/bugs/index.php?13323 - it is connected to this 
20090501 23:52:05< CIA-30> mordante * r35400 /trunk/src/ (4 files in 2 dirs): 
20090501 23:52:05< CIA-30> Initial commit of the lexical_cast test.
20090501 23:52:05< CIA-30> Copied from the svn version.
20090501 23:52:13< CIA-30> mordante * r35401 /trunk/src/unit_frame.cpp: Fix a compiler warning.
20090501 23:54:11< mordante> Chusslove, yes please
20090501 23:54:15< Chusslove> mordante: http://caslav.gmxhome.de/misc/msgs-w-trspc.out 
20090501 23:55:08< CIA-30> mordante * r35402 /trunk/src/ (CMakeLists.txt lexical_cast/): Revert accidental commit.
20090501 23:57:22< mordante> Chusslove, thanks, that page will remain for a while?
20090501 23:57:30< Chusslove> Sure.
20090501 23:57:37< zookeeper> Crab_, vision range is max moves + 1, so you couldn't get next to the necro, only 1 hex away
20090501 23:58:08< zookeeper> in order to be able to move next to it, you'd have to have already seen him at your turn start
20090501 23:58:13< zookeeper> but anyway..
20090501 23:58:34< Chusslove> mordante: Well... there's not much magic in it; if you'd
20090501 23:58:35< Chusslove> svn co svn://anonsvn.kde.org/home/kde/trunk/l10n-support/pology; export PATH=$PWD/pology/scripts:$PATH
20090501 23:58:42< Chusslove> then the command line to get the list
20090501 23:58:51< mordante> good then I'll discuss it with esr when he's around again
20090501 23:58:55< Chusslove> posieve find-messages -snmsgid:': +$' -smsgid:' $' po/*/*.pot
20090501 23:59:09< Crab_> zookeeper: Silver mage teleport ?
20090501 23:59:46< Crab_> zookeeper: but anyway :)
--- Log closed Sat May 02 00:00:18 2009