--- Log opened Wed Jun 02 00:00:29 2010
20100602 00:03:52< CIA-87> esr * r43108 /trunk/data/tools/ (wesnoth/wmltools.py wmllint): Fix bug #16098: wmllint enters infinite loop during spellcheck
20100602 00:06:02-!- PK [~pk@r74-192-30-57.bcstcmta01.clsttx.tl.dh.suddenlink.net] has joined #wesnoth-dev
20100602 00:13:29-!- ancestral [~ancestral@12.145.225.25] has quit [Quit: ancestral]
20100602 00:13:51-!- norbert_ [~norbert@82-171-70-54.ip.telfort.nl] has joined #wesnoth-dev
20100602 00:16:22< alink> esr: I have a wmlint request : it seems that a lot of addons still use the name key as id key in [race] but we deprecated this
20100602 00:16:39< alink> assuming that wmlint can fix this
20100602 00:17:01< alink> and this confuse the help system
20100602 00:17:10< esr> Si you want name= -> id= within a [race] declaration?
20100602 00:17:44-!- zookeeper [~l@wesnoth/developer/zookeeper] has quit []
20100602 00:17:53< alink> no, name must stay
20100602 00:18:15< alink> id is now needed, so copy name to id when id is missing
20100602 00:18:51< esr> alink: Please file an FR with a detailed specifiucation, so I won't forget it.
20100602 00:18:52< alink> see http://wiki.wesnoth.org/UnitsWML where it still claims that the engine do this, but we don't 
20100602 00:19:04< alink> esr ok
20100602 00:19:20< esr> Al;so note in the FR how the wiki should change, please.
20100602 00:19:30< esr> I'll do both at the same time.
20100602 00:19:35< alink> ok good
20100602 00:20:15< alink> bugs where noticed here http://www.wesnoth.org/forum/viewtopic.php?p=431745#p431745
20100602 00:20:24< alink> s/where/were
20100602 00:22:17< esr> OK, please include that link too.
20100602 00:25:45< CIA-87> esr * r43109 /trunk/data/core/terrain-graphics/village.cfg: Comment fixes.
20100602 00:30:02< alink> esr, all done
20100602 00:30:15< esr> alink: Thanks.
20100602 00:30:50< alink> So i may assume that UMC will now fix this? no need to add new safeguard in trunk or 1.8.3 
20100602 00:31:35< esr> I should get to it pretty shortly.  Probably later tonight.
20100602 00:32:28< alink> ah there is already a  lg::wml_error about missing id, I think I will consider that enough for the c++ side
20100602 00:34:30< alink> esr: Thanks
20100602 00:36:18-!- k23z__ [k23z__@188.27.127.239] has joined #wesnoth-dev
20100602 00:36:50-!- thespaceinvader [~chatzilla@wesnoth/artist/thespaceinvader] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]]
20100602 00:40:53< AI0867> fendrin: which packages do you have installed? I have texlive-latex-extra (which pulls in a lot of others) and it compiles fine here
20100602 01:02:49-!- PK [~pk@r74-192-30-57.bcstcmta01.clsttx.tl.dh.suddenlink.net] has quit [Quit: Java user signed off]
20100602 01:03:12-!- billynux [~billy@wesnoth/developer/billynux] has quit [Quit: Leaving]
20100602 01:18:05-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Read error: Operation timed out]
20100602 01:18:59-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100602 01:45:16-!- mjs-de [~mjs-de@vpw.wh.uni-dortmund.de] has quit [Remote host closed the connection]
20100602 01:45:59-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100602 01:51:51-!- Bocom__ [~Bocom@c-b7cfe255.013-31-6b736412.cust.bredbandsbolaget.se] has quit [Ping timeout: 260 seconds]
20100602 01:56:56-!- Bocom [~Bocom@c-b7cfe255.013-31-6b736412.cust.bredbandsbolaget.se] has joined #wesnoth-dev
20100602 02:05:23< CIA-87> esr * r43110 /trunk/data/core/terrain-graphics/ (internal-generic.cfg overlay.cfg walls.cfg): Partial terrain-macro argument type cleanup.
20100602 02:09:09-!- ancestral [~ancestral@12.145.225.25] has joined #wesnoth-dev
20100602 02:11:17-!- Blueblaze [~nick@adsl-76-202-16-2.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 240 seconds]
20100602 02:23:52-!- ancestral [~ancestral@12.145.225.25] has quit [Quit: ancestral]
20100602 02:34:29-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has quit [Quit: Leaving]
20100602 02:55:23< shadowmaster> 20100601 20:46:16 error config: illegal map: Illegal character in map: (Dc) 'Dc'
20100602 02:55:26< shadowmaster> The map cannot be lo�
20100602 02:55:31< shadowmaster> weird stuff happens.
20100602 02:56:13< shadowmaster> these messages in the MP lobby tend to appear in stderr truncated and ending with garbage
20100602 02:56:54-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz]
20100602 02:57:13< shadowmaster> ohcrap
20100602 02:57:25-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20100602 02:58:06< shadowmaster> I believe that it's because there's code referring to a C string obtained from a basic_string that runs out of scope
20100602 02:58:52< shadowmaster> src/map.cpp lines 220 and 244 in the 1.8 branch
20100602 02:59:12< shadowmaster> not completely sure here though
20100602 03:04:37< shadowmaster> I can't remember the interface for ostringstream but I know that it's not safe to dereference from a C string obtained via basic_string<>::c_str() after the object has died
20100602 03:05:45< shadowmaster> hm
20100602 03:07:05< shadowmaster> well, given how incorrect_format_exception works and the fact that objects must have been destroyed and execution returned to the throw handler by the point that C string gets dereferenced...
20100602 03:07:25< shadowmaster> yeah, this sounds like a SIGSEGV attractor
20100602 03:08:32< shadowmaster> I guess it won't be a huge problem if I sacrifice performance by constructing a std::string member in the exception object to keep the string alive for long enough instead
20100602 03:09:20< shadowmaster> this class doesn't even inherit from std::exception so I don't see the point in using a C string directly
20100602 03:14:43< shadowmaster> hm.
20100602 03:17:00< shadowmaster> interesting mess that I've got in my hands
20100602 03:22:07< shadowmaster> gods, does this take long to compile
20100602 03:22:18< shadowmaster> at least I don't have to worry about RAM and swapping
20100602 03:23:57-!- norbert_ [~norbert@82-171-70-54.ip.telfort.nl] has quit [Quit: Leaving]
20100602 03:32:20< CIA-87> alink * r43111 /trunk/src/ (font.cpp font.hpp tooltips.cpp): 
20100602 03:32:20< CIA-87> Use pango word wrapping in tooltip instead of our homemade function.
20100602 03:32:20< CIA-87> This fix inaccuracies when using pango markups.
20100602 03:32:22< CIA-87> alink * r43112 /trunk/src/generate_report.cpp: 
20100602 03:32:22< CIA-87> In terrain def% tooltip, replace the incorrect "chance to be hit" by "defense"
20100602 03:32:22< CIA-87> But need something better shortly saying "chance to avoid being hit"
20100602 03:32:48 * shadowmaster scratches head
20100602 03:33:03< shadowmaster> the AI knows too much about the gamemap for my taste
20100602 03:33:41< alink> ^btw the help could also use a similar change
20100602 03:33:59< alink> it says "Every unit has a chance of being hit, based on the Terrain it is in. This is shown in the status pane, and may also be found by right-clicking a unit, selecting Unit Description, and then looking at Terrain Modifiers"
20100602 03:34:38< alink> these numbers are not "chance of being hit", but chance to avoid being hit
20100602 03:37:21< alink> I don't how it's supposed to work in wesnoth world. Does the unit block or avoid the attack ?
20100602 03:37:30< alink> +know
20100602 03:38:09< shadowmaster> Shydes seem to block with their magic shields
20100602 03:38:14< shadowmaster> no idea about other units
20100602 03:38:33< alink> but avoid make more sense when looking at terrain effect
20100602 03:39:08< alink> they use the terrain "defense" to avoid being hit
20100602 03:39:34< alink> but when you see the sprite it doesn't look like that
20100602 03:41:21< alink> defense is maybe good enough, but I wish something showing better the probability aspect
20100602 03:41:53< alink> as in: 70% defense  doesn't means blocking 70% of damage
20100602 03:44:20< CIA-87> shadowmaster * r43113 /trunk/src/map.hpp: Remove an unused exception class and update a comment
20100602 03:44:44< CIA-87> shadowmaster * r43114 /trunk/ (changelog src/map_exception.hpp): 
20100602 03:44:44< CIA-87> incorrect_map_format_exception now holds a basic_string instead of a
20100602 03:44:44< CIA-87> C-string pointer, so exception handlers won't dereference freed memory
20100602 03:44:44< CIA-87> which could cause a SIGSEGV under certain conditions.
20100602 03:44:45< CIA-87> This fixes corrupted and/or truncated messages regarding invalid terrain
20100602 03:44:45< CIA-87> types caused by maps in the MP server lobby.
20100602 03:45:10< alink> esr: maybe I can interest you to precise that help stuff:
20100602 03:45:14< alink> [03:32:50] <alink> it says "Every unit has a chance of being hit, based on the Terrain it is in. This is shown in the status pane, and may also be found by right-clicking a unit, selecting Unit Description, and then looking at Terrain Modifiers"
20100602 03:45:15< alink> [03:33:28] <alink> these numbers are not "chance of being hit", but chance to avoid being hit
20100602 03:46:47< alink> but i need to go, bye
20100602 03:46:51-!- alink [~alink@wesnoth/developer/alink] has quit [Remote host closed the connection]
20100602 03:49:31-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100602 03:52:38-!- Blueblaze [~nick@adsl-76-202-16-2.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100602 03:57:51-!- Blueblaze [~nick@adsl-76-202-16-2.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 260 seconds]
20100602 03:58:32< CIA-87> shadowmaster * r43115 /branches/1.8/src/map.hpp: 
20100602 03:58:32< CIA-87> Remove an unused exception class and update a comment
20100602 03:58:32< CIA-87> (Backported from trunk, r43113.)
20100602 03:59:01< CIA-87> shadowmaster * r43116 /branches/1.8/ (changelog src/map_exception.hpp): 
20100602 03:59:01< CIA-87> incorrect_map_format_exception now holds a basic_string instead of a
20100602 03:59:01< CIA-87> C-string pointer, so exception handlers won't dereference freed memory
20100602 03:59:01< CIA-87> which could cause a SIGSEGV under certain conditions.
20100602 03:59:02< CIA-87> This fixes corrupted and/or truncated messages regarding invalid terrain
20100602 03:59:02< CIA-87> types caused by maps in the MP server lobby.
20100602 03:59:03< CIA-87> (Backported from trunk, r43114.)
20100602 04:10:27< shadowmaster> ALSA lib pcm.c:7236:(snd_pcm_recover) underrun occured
20100602 04:10:35< shadowmaster> this is getting irritating to watch
20100602 04:24:57-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100602 04:54:23-!- Blueblaze [~nick@76.202.16.2] has joined #wesnoth-dev
20100602 05:03:34-!- Daltx [~Daltx@CPE001e5840eaf6-CM00195ee19c52.cpe.net.cable.rogers.com] has quit []
20100602 05:10:10< CIA-87> eleazar * r43117 /trunk/data/campaigns/The_Hammer_of_Thursagan/maps/ (high_pass.map mages_and_drakes.map): a couple more map enhancements for tHoT.
20100602 05:12:16< CIA-87> eleazar * r43118 /trunk/ (12 files in 3 dirs): Switching the ford to something that works with the animated water. It currently has various problems, but it's moving in the right direction.
20100602 05:16:21-!- ancestral [~ancestral@97-116-112-18.mpls.qwest.net] has joined #wesnoth-dev
20100602 05:29:05-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Read error: Connection reset by peer]
20100602 05:37:52-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100602 05:49:04-!- silene [~plouf@bau91-1-82-239-244-109.fbx.proxad.net] has joined #wesnoth-dev
20100602 05:54:29-!- silene [~plouf@bau91-1-82-239-244-109.fbx.proxad.net] has quit [Changing host]
20100602 05:54:29-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100602 05:55:53-!- Jetrel [~Jetrel@wesnoth/artist/jetrel] has joined #wesnoth-dev
20100602 05:56:08< Jetrel> ancestral:  yo
20100602 05:57:17< ancestral> Oh hi
20100602 05:58:08< Jetrel> ancestral:  you had a bugfix for me?
20100602 05:58:12< Jetrel> I'm gonna update my svn.
20100602 05:59:37< ancestral> Okay
20100602 05:59:58< ancestral> Yeah, basically I just put a black layer below a couple of the photos
20100602 06:00:52< ancestral> Some of these pictures are really old, but I figure if someone wanted to use them in game, then there we go :)
20100602 06:05:31< Jetrel> ancestral:  so, looking over your bug report, it looks like you're only providing missing instances of the "205x205, black-bg" versions, right?  You're not messing with any of the transparent versions?
20100602 06:07:10< ancestral> I think all the transparent ones are there, except some of them are hiding where the black background ones should be… unless I'm wrong about that
20100602 06:07:35< ancestral> All the transparent ones should only be in the transparent folder, right?
20100602 06:07:47< shadowmaster> what bug report is this?
20100602 06:07:54< ancestral> https://gna.org/bugs/index.php?15724
20100602 06:08:04< ancestral> I hope this doesn't break any scenarios
20100602 06:08:23< shadowmaster> artists generally don't proivide the black background version for hero units who don't need a unit_type portrait
20100602 06:08:27< shadowmaster> by the way
20100602 06:08:40< Jetrel> ancestral:  yeah, go ahead and commit the fix.
20100602 06:09:05< shadowmaster> the alternate portraits were intended for heroes rather than unit_types, hence the lack of black background versions
20100602 06:09:16< Jetrel> Well, honestly, we should really get rid of all the black-background versions, and have the engine generate them programmatically.
20100602 06:09:40< ancestral> Is there a size difference though? Between the black background ones and the transparent ones?
20100602 06:09:47< shadowmaster> wasn't one (or more) of our portrait artists against the idea of runtime rescaling?
20100602 06:09:47< ancestral> Whether that may be intentional or not
20100602 06:10:18< Jetrel> ugh. fuck it.  I want nothing to do with this sort of bureaucratic bullshit.
20100602 06:10:26< Jetrel> ancestral:  just commit the fix.
20100602 06:10:32< shadowmaster> I recall that kitty told me off for rescalling Kalenz' portrait at runtime
20100602 06:10:37< shadowmaster> :P
20100602 06:10:42< Jetrel> Yeah, it's just so dumb.
20100602 06:11:01< ancestral> Okay thanks.
20100602 06:11:10< shadowmaster> (that was for the campaign menu images before one of the people who are speaking right now changed the standard)
20100602 06:15:09< Jetrel> IMO, it should use downscaled big versions, because with a more intelligent gui layout, the images wouldn't be getting downscaled.
20100602 06:20:44-!- silene1 [~plouf@bau91-1-82-239-244-109.fbx.proxad.net] has joined #wesnoth-dev
20100602 06:20:44-!- silene [~plouf@wesnoth/developer/silene] has quit [Read error: Connection reset by peer]
20100602 06:20:58-!- silene1 is now known as silene
20100602 06:21:07-!- silene [~plouf@bau91-1-82-239-244-109.fbx.proxad.net] has quit [Changing host]
20100602 06:21:07-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100602 07:07:26-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Quit: You are doing it right!]
20100602 07:11:56< fendrin> AI0867: texlive-latex-extra was missing and that did the trick. Thank you :-)
20100602 07:17:04-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Ping timeout: 240 seconds]
20100602 07:17:38-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100602 07:30:19< Jetrel> Sorry, amendment:  "the images would be getting downscaled MUCH"
20100602 07:43:29-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Read error: Connection reset by peer]
20100602 07:47:06-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100602 07:49:36< noy> Jetrel: can you come into mentor?
20100602 07:51:33-!- Jetrel [~Jetrel@wesnoth/artist/jetrel] has left #wesnoth-dev []
20100602 07:59:42-!- Crab_ [~Crab_@wesnoth/developer/crab] has quit [Quit: Leaving.]
20100602 08:19:37-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Ping timeout: 240 seconds]
20100602 08:21:42-!- Blueblaze [~nick@76.202.16.2] has quit [Ping timeout: 258 seconds]
20100602 08:38:51-!- silene [~plouf@wesnoth/developer/silene] has quit [Quit: Leaving.]
20100602 08:50:11-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100602 08:56:25-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: crimson_penguin]
20100602 09:04:35-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has quit [Quit: Hi! I'm a quit message virus vaccine. If you see a quit message virus, don't replace your quit message with it!]
20100602 09:11:46-!- gabba [~gabba@wesnoth/developer/gabba] has quit [Ping timeout: 245 seconds]
20100602 09:17:47-!- Crab_ [~Crab@wesnoth/developer/crab] has joined #wesnoth-dev
20100602 09:26:39-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100602 09:32:29-!- Upthorn [ogmar@adsl-75-26-174-104.dsl.scrm01.sbcglobal.net] has quit [Ping timeout: 240 seconds]
20100602 09:32:51-!- Netsplit *.net <-> *.split quits: esr, shikadibot, ABCD
20100602 09:34:24-!- Upthorn [~ogmar@adsl-75-26-174-104.dsl.scrm01.sbcglobal.net] has joined #wesnoth-dev
20100602 09:39:03-!- Netsplit over, joins: esr, shikadibot, ABCD
20100602 09:47:13-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100602 10:46:31-!- ancestral [~ancestral@97-116-112-18.mpls.qwest.net] has quit [Quit: And that’s the end of THAT chapter.]
20100602 10:47:52-!- wesbot changed the topic of #wesnoth-dev to: released 1.8.2, announcing "soon"| 114 bugs, 280 feature requests, 16 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100602 10:57:59-!- stikonas [~and@bcm-131-111-247-104.girton.cam.ac.uk] has joined #wesnoth-dev
20100602 10:57:59-!- stikonas [~and@bcm-131-111-247-104.girton.cam.ac.uk] has quit [Changing host]
20100602 10:57:59-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100602 11:05:54< Ivanovic> moin
20100602 11:06:09< Ivanovic> time to work on the announcement of 1.8.2
20100602 11:08:55< Rhonda> https://buildd.debian.org/status/package.php?p=wesnoth-1.8&suite=unstable
20100602 11:09:20< Ivanovic> wow, tarball size increased by 10MB...
20100602 11:09:37< Rhonda> Yes, noticed that.
20100602 11:09:47< Ivanovic> Rhonda: cool, some builds are already done
20100602 11:10:16< Rhonda> amd64 already uploaded and i386 just waiting for the buildd admin to sign, yes.
20100602 11:13:31-!- Valkier [~IceChat7@c-174-55-104-2.hsd1.pa.comcast.net] has joined #wesnoth-dev
20100602 11:17:38-!- Valkier [~IceChat7@c-174-55-104-2.hsd1.pa.comcast.net] has left #wesnoth-dev []
20100602 11:22:06< Ivanovic> 1.8.2 announcement: http://forums.wesnoth.org/viewtopic.php?f=5&t=30205
20100602 11:22:18< Ivanovic> yeah, it is really small and tiny, there is not too much to mention...
20100602 11:25:51< Ivanovic> updated the frontpage, too
20100602 11:28:12-!- Ivanovic changed the topic of #wesnoth-dev to: 114 bugs, 280 feature requests, 16 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100602 11:33:53-!- loonybot [~loonybot@ppp79-139-137-245.pppoe.spdop.ru] has joined #wesnoth-dev
20100602 11:33:59-!- loonybot [~loonybot@ppp79-139-137-245.pppoe.spdop.ru] has quit [Changing host]
20100602 11:33:59-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100602 11:34:52-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100602 11:51:53-!- zookeeper [~l@wesnoth/developer/zookeeper] has quit []
20100602 11:57:55-!- mjs-de [~mjs-de@stud3.physik.uni-dortmund.de] has joined #wesnoth-dev
20100602 12:21:31-!- euschn [~eugen@wesnoth/developer/euschn] has joined #wesnoth-dev
20100602 12:42:03-!- k23z__ [k23z__@188.27.127.239] has quit [Quit: Leaving]
20100602 12:46:33-!- k23z__ [k23z__@188.27.127.239] has joined #wesnoth-dev
20100602 12:46:37-!- euschn [~eugen@wesnoth/developer/euschn] has quit [Quit: Leaving.]
20100602 12:51:49-!- thespaceinvader [~chatzilla@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev
20100602 13:18:01-!- k23z__ [k23z__@188.27.127.239] has quit [Ping timeout: 264 seconds]
20100602 13:24:17-!- mjs-de [~mjs-de@stud3.physik.uni-dortmund.de] has quit [Remote host closed the connection]
20100602 13:31:16-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has joined #wesnoth-dev
20100602 13:33:28< CIA-87> eleazar * r43119 /trunk/data/core/ (3 files in 2 dirs): two more green grass tiles, and some tweaks to grass probability.
20100602 13:59:57-!- Johannes13 [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100602 14:12:40-!- Tesafilmchen [~quassel@p4FDE753F.dip.t-dialin.net] has joined #wesnoth-dev
20100602 14:29:04-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has joined #wesnoth-dev
20100602 14:29:04-!- fendrin [~fabi@88-134-103-91-dynip.superkabel.de] has quit [Changing host]
20100602 14:29:04-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100602 14:36:46-!- Crab_ [~Crab@wesnoth/developer/crab] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
20100602 15:02:54-!- Nalf-Eshnee [~bcc1bb6b@gateway/web/freenode/x-pluifpyvhrvtlkuy] has joined #wesnoth-dev
20100602 15:06:56-!- King_Elendil [~King_Elen@75.143.233.138] has joined #wesnoth-dev
20100602 15:09:01-!- meric [~Eric@124-168-175-127.dyn.iinet.net.au] has joined #wesnoth-dev
20100602 15:12:39-!- qemqemqem__ [~quassel@ip70-177-181-137.dc.dc.cox.net] has quit [Ping timeout: 260 seconds]
20100602 15:22:40-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100602 15:23:11-!- Nalf-Eshnee [~bcc1bb6b@gateway/web/freenode/x-pluifpyvhrvtlkuy] has quit [Quit: Page closed]
20100602 15:25:57-!- Johannes13 [~Johannes@unaffiliated/johannes13] has quit [Disconnected by services]
20100602 15:26:04-!- Johannes13_ is now known as Johannes13
20100602 15:26:54-!- meric [~Eric@124-168-175-127.dyn.iinet.net.au] has quit [Read error: Connection reset by peer]
20100602 15:27:14-!- meric [~Eric@124-168-168-69.dyn.iinet.net.au] has joined #wesnoth-dev
20100602 15:30:12-!- King_Elendil [~King_Elen@75.143.233.138] has quit [Quit: I hope y'all have a nice day ;)]
20100602 15:53:17-!- billynux [~billy@wesnoth/developer/billynux] has joined #wesnoth-dev
20100602 15:54:56< CIA-87> billynux * r43120 /trunk/src/ana/ (19 files in 4 dirs): Added subdirectory ana to src to work on the network rewrite GSoC project.
20100602 15:55:10-!- Ken_Oh [~briang@static-71-178-174-220.washdc.fios.verizon.net] has joined #wesnoth-dev
20100602 15:57:10-!- Gambit|Bugged [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100602 15:59:44-!- Gambit|Bugged is now known as Gambit
20100602 16:01:53-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Client Quit]
20100602 16:02:25-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100602 16:43:05< CIA-87> upthorn * r43121 /trunk/src/ (persist_context.cpp persist_context.hpp): encapsulated functions related to namespace parsing, namespace parsing now basically accurate to spec (inaccuracies reflect pending changes to spec).
20100602 16:47:52-!- wesbot changed the topic of #wesnoth-dev to: 115 bugs, 280 feature requests, 16 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100602 16:48:09-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100602 16:48:15< CIA-87> eleazar * r43122 /trunk/data/core/terrain-graphics.cfg: some fixes for ford layering.
20100602 16:55:07-!- Greywhind [~Greywhind@138.16.58.24] has joined #wesnoth-dev
20100602 16:58:08-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100602 16:59:49-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20100602 17:08:58-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100602 17:33:45-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Quit: Leaving.]
20100602 17:34:50-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100602 17:34:57-!- Mythological [Mythologic@77.28.88.41] has joined #wesnoth-dev
20100602 17:41:26-!- allefant [~elias@allegro/developer/allefant] has joined #wesnoth-dev
20100602 17:47:51-!- Tesafilmchen_ [~quassel@p4FDE656B.dip.t-dialin.net] has joined #wesnoth-dev
20100602 17:49:16-!- Tesafilmchen [~quassel@p4FDE753F.dip.t-dialin.net] has quit [Ping timeout: 245 seconds]
20100602 17:55:38-!- billynux [~billy@wesnoth/developer/billynux] has quit [Ping timeout: 260 seconds]
20100602 17:58:53-!- Tesafilmchen_ [~quassel@p4FDE656B.dip.t-dialin.net] has quit [Ping timeout: 240 seconds]
20100602 18:25:15-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100602 18:34:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100602 18:36:12-!- cjhopman_ [~chris@wesnoth/developer/cjhopman] has joined #wesnoth-dev
20100602 18:41:57-!- alink [~alink@wesnoth/developer/alink] has joined #wesnoth-dev
20100602 18:51:16-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100602 18:53:11-!- Lastmerlin [~Lastmerli@kalypso.csn.tu-chemnitz.de] has joined #wesnoth-dev
20100602 18:53:53-!- boucman [~rosen@84.102.83.240] has joined #wesnoth-dev
20100602 18:54:00-!- boucman [~rosen@84.102.83.240] has quit [Changing host]
20100602 18:54:00-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100602 18:55:13-!- Johannes13 [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 264 seconds]
20100602 19:19:18-!- billynux [~c8078d05@wesnoth/developer/billynux] has joined #wesnoth-dev
20100602 19:28:43-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 248 seconds]
20100602 19:31:49-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100602 19:31:49-!- meric [~Eric@124-168-168-69.dyn.iinet.net.au] has quit [Quit: meric]
20100602 19:39:20-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Read error: Connection reset by peer]
20100602 19:59:08-!- gabba [~gabba@wesnoth/developer/gabba] has joined #wesnoth-dev
20100602 19:59:26< gabba> bonjour
20100602 19:59:40< shadowmaster> hi there
20100602 19:59:46< gabba> hi shadowmaster
20100602 20:00:36< boucman> hey gabba
20100602 20:00:59< boucman> i've read all your diagrams, i'm not completely clear with the visitor pattern yet, but overall this looks good
20100602 20:01:19< gabba> hello boucman
20100602 20:01:58< billynux> hi the 3 of you :P
20100602 20:02:08< gabba> boucman: ok. I expected to code more and design less, but the old design was just too detached from reality
20100602 20:02:17< gabba> billynux: hi
20100602 20:02:42< boucman> yes, taht's always the case :)
20100602 20:02:54< billynux> gabba: my UML diagram looks messy :(
20100602 20:03:13< gabba> billynux: which one?
20100602 20:03:31-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20100602 20:03:35< boucman> the idea of the dead() action is really good, though I'm not sure when to handle it... my guess is that it should com after any attack with ctk > 0
20100602 20:03:43< mordante> servus
20100602 20:03:51< billynux> I uploaded an .xmi to trunk/src/ana with the Umbrello file
20100602 20:03:53< gabba> hi mordante
20100602 20:03:54< billynux> hi mordante 
20100602 20:04:02< mordante> hi gabba 
20100602 20:04:04< mordante> hi billynux 
20100602 20:04:25< gabba> boucman: I see the dead() action more as a thing the player would manually set
20100602 20:04:45< boucman> an (related idea is to have each attack move keep a ctk for the involved unit, and display the cumulated ctk on the screen (just a small improvement to keep in the back of the head if it's not complicated)
20100602 20:04:46< gabba> boucman: any automatic calculations might get annoying
20100602 20:05:08< billynux> "I see the dead()" ... people :D -> sorry, Sixth Sense reference
20100602 20:05:24< boucman> gabba: I can't imagine how to make it from a UI point of view...
20100602 20:05:36-!- phlaem [~a@e178108242.adsl.alicedsl.de] has joined #wesnoth-dev
20100602 20:06:03-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has quit [Ping timeout: 260 seconds]
20100602 20:06:10-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100602 20:06:19< shadowmaster> billynux: I believe the original line is "I see dead people"
20100602 20:06:34< gabba> boucman: something like right-click on the unit, "consider as dead", and then a nice skull and crossbones appears over it
20100602 20:06:35< billynux> affirmative
20100602 20:06:58< boucman> maybe...
20100602 20:07:18< gabba> alink and cjhopman_ liked it too, so it can't be that bad an idea :P
20100602 20:07:32< boucman> ok, let's forget UI for the moment... I think it's a bit early for that... ATM
20100602 20:07:56< gabba> but displaying cumulative CTK is a good idea, actually it's there in my "optional developments" wiki page
20100602 20:08:06< boucman> ok, cool
20100602 20:08:22< boucman> i'm looking at your first sequence diagram (moving unit wo previous arrow)
20100602 20:08:30-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100602 20:09:11-!- stikonas [~and@bcm-131-111-247-104.girton.cam.ac.uk] has joined #wesnoth-dev
20100602 20:09:11-!- stikonas [~and@bcm-131-111-247-104.girton.cam.ac.uk] has quit [Changing host]
20100602 20:09:11-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100602 20:09:13< boucman> a guess is that it would make things simpler everywhere (but especially for the "mouse move" case) to keep a copy of the "cumulated" unit map in the manager
20100602 20:09:22< boucman> only that one...
20100602 20:09:38< boucman> it will be used very often and might simplify things a lot...
20100602 20:10:50< billynux> gabba: I meant this diagram: http://imagebin.org/99257
20100602 20:11:22< gabba> boucman: makes sense, but it would have to be replaced with a fresh copy of the original everytime we execute an action, and significantly modified whenever an action is deleted or moved somewhere in the sequence
20100602 20:11:31< mordante> Ivanovic, the German calendar is interesting... _Tuesday_, June 2 2010 (at the frontpage)
20100602 20:12:40< gabba> billynux: lots of arrows going all over the place, but not what I would call messy though
20100602 20:12:55< boucman> gabba: how would that compare to the build temp unit_map on every mouse move ?
20100602 20:13:10< billynux> thanks, I can't stand non-orthogonal arrows 
20100602 20:13:44< gabba> billynux: maybe if you manage to group things by theme/package it would help readability, but I'm saying that after a superficial quick look
20100602 20:14:22< gabba> boucman: actually, I don't know
20100602 20:14:28< boucman> hehe
20100602 20:14:44< billynux> gabba: true... but this is just the API part, the implementation part is a little complex, if I add the classes that use the API: its worse
20100602 20:15:24< gabba> billynux: I bet
20100602 20:16:35< boucman> gabba: ok, i'll ask another related question... do we need to build the temp unit_map on every mouse move ? afaik until the mouse click, this should be very similar to the current footstep code, except with a temp unit_map... which shouldn't change until there is a click
20100602 20:16:51< boucman> (or maybe I don't understand what you mean by the mouse_move in input)
20100602 20:18:21< gabba> boucman: you're right, I kind of messed up in this diagram -- we only need to build the temp_unit_map once, along with creating the arrow
20100602 20:19:04< gabba> so, that brings it down to recreating it every time the unit selection changes
20100602 20:19:15< boucman> ok, makes more sense, though I think you only to build it whenever something changes in the manager, which is even less often...
20100602 20:19:56< gabba> boucman: ah, no, you know why I did it like this?
20100602 20:20:09< boucman> why ?
20100602 20:20:26< gabba> boucman: it's because these changes were supposed to be made on the REAL unit map, therefore they had to be erased before the next redraw
20100602 20:21:28< gabba> all that to avoid a copy that was supposedly expensive... I should've verified that fact myself before
20100602 20:22:20< gabba> I'm not really sure about the performance issues here... rebuilding the temp_unit map every time the mouse changes hexes probably takes less performance than the pathfinding itself, isn't it?
20100602 20:23:20< boucman> probably... but having the cumulated unit_map handy still sounds like a good idea to me... 
20100602 20:24:28< boucman> i mean few people will need the intermediate ones, but the top one might be used regularly... i'm not sure how you want to handle the basic unit_map+diff in pathfinding except by rebuilding a new unit map anyway
20100602 20:25:27< gabba> so, make a copy of the real unit_map, and update it with the sequence of planned actions, every time the planned actions collection changes, basically?
20100602 20:26:17< gabba> Ok I see what you mean by top/intermediate ones
20100602 20:26:58< boucman> yes, I can't see any real perf drawbacks (I can't think of any common case were the structure would change and we would not have to use that built unit_map anyway) and it makes a cleaner API since that's something it's logical for the manager to make available
20100602 20:27:32< gabba> ok, one problem solved
20100602 20:27:38< boucman> if you are worried about perf, you could keep a need_rebuild attribute, set it on stack change and build the temp_unit_map on first access
20100602 20:29:27< gabba> billynux: last time I used Umbrello, I seem to remember it trying to take my sanity away... I strongly recommend Bouml as a tool you can rely on (but well, you already have invested a lot in Umbrello for this project)
20100602 20:29:53< billynux> gabba: true... I use both, they seem to have fixed major bugs in umbrello
20100602 20:30:20< billynux> gabba: bouml is the craziest tool I've ever seen, you brake everything if you change a project from one path to another
20100602 20:30:27< boucman> ok, moving on the second diagram (move with existing arrow)
20100602 20:30:29< gabba> boucman: yes. Or maybe I can just test first and see if perf is acceptable
20100602 20:30:54< boucman> gabba: of course, "early optimisation is the root of all evil"
20100602 20:30:54< gabba> billynux: bah, just rename the project file to match the directory name and you're ok
20100602 20:31:27< gabba> he he
20100602 20:32:00< billynux> gabba: maybe, but it is still ridiculous to be forced to do that. Also... It saves a gazillion files for ONE project... whats up with that?  if I want revision control on it I have to save ~100 files
20100602 20:32:33< billynux> umbrello project -> 1 .xmi file. And it is not too buggy ATM, just...  workable
20100602 20:33:50< gabba> billynux: I'm not saying it doesn't have idiosyncracies, but it's definitely the most reliable I encountered... no crashes, no glaring missing features, good sequence diagrams, and you can even do tracability from use cases all the way to source artefacts if you want
20100602 20:34:12< boucman> you're use case doesn't seem to handle the case where the selected unit has a move in the midle of the action stack...
20100602 20:34:17< gabba> billynux: good to hear Umbrello improved, but I'm still skeptical
20100602 20:34:25< boucman> oh wait
20100602 20:34:28< boucman> get it now
20100602 20:34:49< billynux> mordante: I have squid working, but just the default settings, I'm not sure how to configure basic/digest properly
20100602 20:35:08< boucman> hmm no
20100602 20:35:20< mordante> ok nice, I've no idea either about it, but maybe Rhonda knows
20100602 20:35:22< boucman> it seems to be handled but i'm not clear what you're trying to do
20100602 20:35:32< billynux> gabba: And if bouml is not crashing, its good to hear that too. It was the last time I used it.
20100602 20:35:46< boucman> should the new move replace the old one (i.e same place in the stack) or the old one be deleted and the new one added at the top
20100602 20:36:02< boucman> add_move has an end parameter, which seems to suggest the latter
20100602 20:36:21< gabba> boucman: yeah, I guess it's easier to understand with an explanation of how I imagine the UI for this case
20100602 20:36:22< Rhonda> mordante: ?
20100602 20:36:25< boucman> but your update&pathfind action mentions "following moves" suggesting there are such moves
20100602 20:36:35< boucman> gabba: probably :)
20100602 20:36:42< mordante> Rhonda, configuring squid, do you have experience with it?
20100602 20:36:50< Rhonda> not really
20100602 20:36:54< billynux> :(
20100602 20:37:08-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100602 20:37:17< kevg> hello
20100602 20:37:18< billynux> I think Crab_ knew something about it. Anyway, I have lots of manuals to consult, and some friends
20100602 20:37:34< billynux> So I'll be RTFM I guess
20100602 20:37:56< gabba> boucman: so, the idea is that you select the unit, it highlights its current arrow, and starts drawing a new one (more transparent I guess);
20100602 20:38:06< mordante> Rhonda, regarding the s390 build it ends with "collect2: ld terminated with signal 9 [Killed]" can it be due to a build timeout?
20100602 20:39:27< gabba> you move the new arrow around (the old one is still there as a reference), and when you click to confirm, the old arrow is replaced by the new one. In backend terms, action #6 is replaced by a new action at the same position in the action deque
20100602 20:39:41< gabba> boucman: does it make more sense that way?
20100602 20:39:42< billynux> I'm off people, class! later
20100602 20:39:48< mordante> see you later
20100602 20:39:52< gabba> see you billynux
20100602 20:40:01< billynux> mordante: I assume you saw I uploaded ana to wesnoth's trunk (under src)
20100602 20:40:07-!- billynux [~c8078d05@wesnoth/developer/billynux] has quit [Quit: Page closed]
20100602 20:40:18< boucman> yes, tough to follow the current ergonomy the arrow should be "less transparent" (i.e brighter, highlighted)
20100602 20:41:13< boucman> ok the whole thing makes sense now, though the add_move call in your diagram probably shouldn't have "end" as the positional parameter
20100602 20:41:49< gabba> boucman: "end" is the end of the arrow, where you clicked the mouse
20100602 20:43:40< boucman> ok, you need a way to "insert_move" in that case, but that's a detail, I agree on the principles
20100602 20:43:51< gabba> boucman: ^ hmm, if we do that the visual effect will be: select unit, its arrow highlights, then as soon as you move cursor on neighbouring hex, arrow gets toned down and a new highlighted arrow appears that follows the cursor
20100602 20:44:40< gabba> boucman: I see what you mean, add_move is not the proper call here... I took some shortcuts
20100602 20:44:41< boucman> gabba: yes, sounds good, the old one could be made transparent, but the arrow following the mouse should be highlighted
20100602 20:45:26< gabba> boucman: ok, and if you don't want to replace the existing move, just right-click to deselect the unit. Seems like a working concept.
20100602 20:45:56< boucman> yes, right clicking (or esc) has always be a deselecting action...
20100602 20:47:00< kevg> boucman: is writing candidate for healer control from EasyCoding is actual task?
20100602 20:47:05< gabba> boucman: sure, it's just reusing that behavior
20100602 20:49:34< boucman> kevg: crab would know better than me, but it's probably not to hard
20100602 20:50:24< boucman> i'm suprised it's marked as fai or c++ or lua... I would understand for FAI and lua, but one of the aim of the new AI is to have the AI code not be hard coded...
20100602 20:51:23< gabba> boucman: so about the visitor... all it does is it gets called from the manager in a foreach loop:
20100602 20:52:28< boucman> ok, I got it...
20100602 20:52:35< gabba> foreach(action a, actions) { action.accept(visitor); }
20100602 20:55:08< kevg> boucman: ok. I'll discuss it with Crab some time
20100602 20:55:08< boucman> what's the point of the accept() check, though ?
20100602 20:56:42< gabba> boucman: standard visitor pattern stuff... you need the back-and-forth action.accept(visitor), which itself calls visitor.visit_move(this), to get proper treatment for each subclass
20100602 20:56:50< kevg> zookeeper: are you around?
20100602 20:57:02< boucman> m'kay
20100602 20:57:06< gabba> it's double-dispatch, to use the fancy term
20100602 20:57:18< boucman> I can understand the back and forth thing
20100602 21:00:05< gabba> boucman: it's either that or have code of the style: if (action.type() == move) //do stuff; else if (action.type() == attack) //do stuff; etc, etc 
20100602 21:00:42< boucman> yes, I got that, studying the last sequence diagram now
20100602 21:01:39< boucman> design question, about the check_validity...
20100602 21:02:16< boucman> who should decide what to do when an action is invalid...
20100602 21:02:51< boucman> right now, you put it in the pathfind_visitor class, but the action could also either return something describing what to do or do it itself...
20100602 21:03:43< boucman> in particular if we can be invalid for multiple reasons, we need a way to report to pathfind_visitor the reason so it can take that into account in it's decision
20100602 21:04:12< gabba> boucman: yes, I wasn't sure about this one... an action removing itself from the manager seems difficult and not OO, but it can ask for its own deletion
20100602 21:05:30< boucman> indeed, I think there are two questions to ask...
20100602 21:06:02< boucman> 1) can pathfind_visitor be called in different circumstances causing different actions to be taken on the same invalidity
20100602 21:06:06< gabba> boucman: we could have bunch of codes from an enum as a possible return value, but I'm not sure I like the idea
20100602 21:06:16< boucman> 2) can different invalidity cause create different action
20100602 21:06:51< boucman> i'm not sure about it either, we need to brainstorm more on the problem
20100602 21:07:24< boucman> (other idea to write down, you might want an "add an invisible unit here" action, in case the player want to suppose there is a wose somewhere
20100602 21:08:24-!- PK [~pk@r74-192-30-57.bcstcmta01.clsttx.tl.dh.suddenlink.net] has joined #wesnoth-dev
20100602 21:08:30< gabba> ^ we can also add more visitors as needed, even subclass pathfind_visitor if slightly different needs arise
20100602 21:08:59< boucman> indeed
20100602 21:09:06< boucman> so that solves question one
20100602 21:09:27< gabba> good idea the invisible unit
20100602 21:09:27< boucman> if the answer to question two is "no there is no such case" then we're good :)
20100602 21:10:43< boucman> gabba: hmm shouldn't the "assume dead" event be an attribute of the attack action ? I'm asking because they have a place in the stack, but lots of places don't make sense...
20100602 21:11:15-!- kevg [~kevg@94.232.5.102] has left #wesnoth-dev []
20100602 21:12:02< gabba> No, I think it should be independent: the player can perfectly assign three units as dead from the start and then define a few moves, without yet defining attacks
20100602 21:12:22-!- Lastmerlin [~Lastmerli@kalypso.csn.tu-chemnitz.de] has left #wesnoth-dev ["Kopete 0.12.7 : http://kopete.kde.org"]
20100602 21:14:01-!- YogiHH [YogiHH@d096248.adsl.hansenet.de] has joined #wesnoth-dev
20100602 21:14:24-!- YogiHH [YogiHH@d096248.adsl.hansenet.de] has quit [Changing host]
20100602 21:14:24-!- YogiHH [YogiHH@wesnoth/developer/yogihh] has joined #wesnoth-dev
20100602 21:14:45< boucman> gabba: ok
20100602 21:15:00< gabba> about question #2, it's really hard to answer without actually coding the thing, I think. But up to now I'm under the impression that move/attack/recruit will just mark themselves as conflicted and then get ignored by pathfind_visitor when building the temp_unit_map; "dead" gets deleted instead because it just doesn't convey any more useful info if its target unit doesn't exist
20100602 21:15:30-!- Gambit [~Gambit@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100602 21:15:59< boucman> ok, I can't find any trivial counter example, so we'll assume it works and see if problems arise
20100602 21:17:28< gabba> alright
20100602 21:19:11< gabba> btw I found a good solution to a nagging UI problem
20100602 21:19:41< boucman> yes ?
20100602 21:19:52< gabba> such as, what happens if you assume a unit dead and then move one of your own on top of it
20100602 21:20:30< boucman> gabba: btw, since you don't keep intermediate unit maps, you have to rebuild it from start whenever something moves in the stack... am I right, or is there a trick that I missed ?
20100602 21:20:41< CIA-87> silene * r43123 /trunk/src/savegame.cpp: Avoided costly roundtrip through strings.
20100602 21:20:47< mordante> I'm off night
20100602 21:20:47< CIA-87> silene * r43124 /trunk/src/gui/auxiliary/window_builder/helper.cpp: Avoided costly roundtrip through strings.
20100602 21:20:50< gabba> player confusion is the first obvious answer :P , if he wants to check the stats of the then-hidden unit
20100602 21:20:51< CIA-87> silene * r43125 /trunk/src/gui/dialogs/campaign_selection.cpp: Avoided costly roundtrip through strings.
20100602 21:20:52< CIA-87> silene * r43126 /trunk/src/multiplayer_create.cpp: Avoided costly roundtrip through strings.
20100602 21:20:55< CIA-87> silene * r43127 /trunk/src/controller_base.cpp: Avoided costly roundtrip through strings.
20100602 21:20:58< CIA-87> silene * r43128 /trunk/src/map.cpp: Avoided costly roundtrip through strings.
20100602 21:21:02< CIA-87> silene * r43129 /trunk/src/mapgen.cpp: Avoided costly roundtrip through strings.
20100602 21:21:04< CIA-87> silene * r43130 /trunk/src/gui/auxiliary/window_builder/slider.cpp: Avoided costly roundtrip through strings.
20100602 21:21:08< CIA-87> silene * r43131 /trunk/src/gui/auxiliary/widget_definition/toggle_panel.cpp: Avoided costly roundtrip through strings.
20100602 21:21:12< CIA-87> silene * r43132 /trunk/src/persist_context.cpp: Fixed compilation of persistent WML code.
20100602 21:21:13< gabba> boucman: ^you're right
20100602 21:21:18-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20100602 21:21:38< boucman> ok, makes sense...
20100602 21:22:05-!- Johannes13__ [~Johannes@pD95030A4.dip0.t-ipconnect.de] has joined #wesnoth-dev
20100602 21:22:21< boucman> note that at the end of pathfind_visitor (which to me seems more or less mandatory to run whenever something changes in the stack) you have built the top unit_map, so saving it at this point makes sense
20100602 21:22:57< boucman> the only case where you don't need pathfind_visit is when you add at the top of the stack, but having the built unit_map at that point makes even more sense
20100602 21:23:30< gabba> boucman: anyways, the solution is to have replay-like controls so you can go back and forward in your list of planned moves. Basically if you're at move #6 you hit back three times, and moves #4-#6 get hidden or dimmed
20100602 21:25:00< gabba> boucman: yes, keeping a copy of the "bottom" (i.e. original) and "top" unit map makes sense; for anything in-between, just rebuild it as needed from the "bottom" one
20100602 21:25:12< boucman> ok (I think hidden would be less confusing then dimmed, but that's a detail)
20100602 21:25:51-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 260 seconds]
20100602 21:26:43-!- ancestral [~ancestral@12.145.225.25] has joined #wesnoth-dev
20100602 21:26:48< gabba> It's yet more UI work, but such a system would alleviate my fear of the player being lost in a huge mess of arrows
20100602 21:27:56< boucman> hmm
20100602 21:28:21-!- Daltx [~Daltx@CPE001e5840eaf6-CM00195ee19c52.cpe.net.cable.rogers.com] has joined #wesnoth-dev
20100602 21:28:51< boucman> though adding an undo/redo UI paradigm on top of the action stack would make sense, i'm not sure how much it reduces the confusion in the "click on dead unit" case you've originally mentionned
20100602 21:29:28< boucman> it allows to access that unit, yes, but I'm not sure it's less confusing
20100602 21:29:55< gabba> boucman: it's not really undo/redo, but rather "review", i.e. you can go back to see earlier moves without the clutter of the later ones
20100602 21:31:07< boucman> hmm, i'm not convinced, but since most of the input side of the UI is more "concept" and "vision" than things we can test at this point, it's sort of an empty discussion at this point
20100602 21:31:07< gabba> boucman: I don't know if the player would be confused (let's grant him some level of intelligence), but he would certainly be annoyed at not being able to access the hidden unit
20100602 21:31:36< boucman> we can easily add it if we think it's needed, and we don't need it for early testing... it's an idea to keep in mind
20100602 21:32:18< boucman> gabba: I always assumed that clicking on a real unit selects it and clicking on a ghost did nothing, so I originally didn't see that problem
20100602 21:32:24< boucman> did you have something different in mind ?
20100602 21:33:09< gabba> I don't agree it's an empty discussion: if you notice, the UI already affects directly the underlying framework coding; and it's not use coding a backend for features like "assume dead" if we can already detect interface nightmares
20100602 21:33:41< boucman> that's a good point too...
20100602 21:33:42< gabba> ^no, we're on the same page regarding clicking on units vs ghosts
20100602 21:33:44< ancestral> So… if I'm submitting a patch with binary files (i.e. images) should I use bsdiff or maybe I don't need to produce a diff file?
20100602 21:34:41< boucman> ancestral: attach the files (as a zip if there are a lot of them) + a "svn diff" which tells me where they should be, allows me to make sure you didn't forget any, and easily give me any text diff needed
20100602 21:34:56< boucman> ok
20100602 21:34:58< ancestral> Cool
20100602 21:35:04< gabba> I think we're knee-deep in the dead... uh in interface coding already
20100602 21:35:10< boucman> hehe
20100602 21:35:54< boucman> gabba: here is an idea for a "next coding target" 
20100602 21:36:07< gabba> I'm all ears
20100602 21:37:06< boucman> put in place all the structure for the actions assuming only moves (i.e no attack/deads etc...) and assuming no action execution
20100602 21:38:01< boucman> with a hackish UI (maybe even no editing of actions if that's complicated) so we can start to "see stuff" play with the UI etc...
20100602 21:38:19< boucman> do you think it's a fenced enough problem to solved ?
20100602 21:39:46< gabba> I'm trying to see which parts of the framework I need to code for that...
20100602 21:40:17< boucman> k
20100602 21:41:34< gabba> At least: the external input, the manager, move, path_find_visitor, maybe unit_find_visitor
20100602 21:41:57< boucman> yes, it's quite a big chunk... 
20100602 21:42:22< alink> gabba: btw, about using the real unit_map, you seems to have missed my main point, which was easy use of engine functions.
20100602 21:42:40< gabba> alink: did I? dammit
20100602 21:43:09< gabba> alink: but I can use them on a copy of the unit map, can't I (maybe with minor refactoring) ?
20100602 21:43:38< alink> if you use fake unit_map, you must pass it to all engine function and they must repass it to all sub fuctions
20100602 21:43:44< alink> *functions
20100602 21:43:59< alink> also need to track all use of ressources::unit_map
20100602 21:44:15< alink> and all objects storing a reference to unit_map
20100602 21:45:02< boucman> allefant: hmm good point, pathfinding is our main one, though, so if we could limit it to that, we should be good
20100602 21:45:11< boucman> allefant: sry, I meant alink
20100602 21:45:28< alink> boucman: i think there is also plan to see/use attack dialog
20100602 21:45:34< boucman> an the only other idea I have is swapping ressources::unit_map which wouldn't be good either
20100602 21:45:57-!- ancestral [~ancestral@12.145.225.25] has quit [Quit: ancestral]
20100602 21:46:11< alink> swapping unit_map is possible but similar to my "play/rewind move" on it
20100602 21:46:37< alink> which btw should be fairly cheap, just moving few pointers
20100602 21:47:02< boucman> your play/rewind ? 
20100602 21:47:30< gabba> temp_unit_mover and temp_unit_placer
20100602 21:47:35-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has joined #wesnoth-dev
20100602 21:47:39< alink> you play a move, do a pathfind request, undo the move  
20100602 21:48:56< gabba> alink: so let's say I have 30 moves defined, I'll need to temporarily apply those and then undo them, each time the mouse changes hexes (which can happen very fast depending on player). Does that sound ok perf.-wise?
20100602 21:49:15< alink> as i see it, you will move 
20100602 21:49:29< alink> 30 pointers in a std::map
20100602 21:50:33< alink> while copying an unit_map currently means copy all its units data (ctor etc). and units are heavy objects
20100602 21:51:15< alink> temporary death should be cheap too, just store the dead unit, or move it off-map
20100602 21:51:50< gabba> the pathfind itself is probably more heavy than moving n pointers which is an O(n) operation, right?
20100602 21:51:51< alink> i am not sure yet about recruit. depend how you plan to handle it
20100602 21:52:10< boucman> hmm
20100602 21:52:13< alink> gabba, yes clearly 
20100602 21:52:59< gabba> alink: recruit would amount to a temp_unit_placer for pathfinding purposes, but it's still an optional feature
20100602 21:53:04< boucman> alink: ok, I understand your idea, which is that basically each action knows what it needs to do/undo on the unit map, and we build/act/unbuild every time...
20100602 21:53:18< boucman> because we can't leave the unit_map in an uncontrolled state....
20100602 21:54:11< alink> boucman yes , but as gabba said, we already use similar trick for checking "future" state, but only for 1 unit
20100602 21:54:31-!- Blueblaze [~nick@adsl-76-202-16-2.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100602 21:54:45< boucman> m'kay...
20100602 21:54:56< alink> but it's very cheap, so O(N) such thing is really not a problem
20100602 21:56:36< boucman> ok, I understand the idea, i'm only mildly comfortable with it, but I see why you want to do that...
20100602 21:56:37< alink> as an similar concept, I think that when we clear delayed shroud, we replay all moves from the undo stack and make them clear shroud
20100602 21:56:42< boucman> gabba: your opinion ?
20100602 21:57:01< boucman> ok, so it's sort of a proven concept...
20100602 21:57:10-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100602 21:57:58< gabba> Right now I'm completely reliant on you guys for accurate info on how unit_map and related code works. But in my limited view of things, I think what alink proposes will work.
20100602 21:59:00< alink> the only limitation that i could see is that you can't hand code flow to engine before you have finished cleaning. But many heavy parts already assume that
20100602 21:59:18< boucman> gabba: ok, let's try to do it alink's way, in that case
20100602 21:59:24-!- Johannes13__ [~Johannes@pD95030A4.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20100602 21:59:25< gabba> I do find it "weird", but if it's the only way to take advantage of some engine functions...
20100602 22:00:40< boucman> personally, i'm reassured by the fact that it's already done somewhere else, it proves the concept works
20100602 22:01:56< alink> boucman: well, the scale and complexity will change but the basis seems simple
20100602 22:02:00< gabba> just one thing alink, are you sure that copying a unit_map involves copying every unit? The "typedef std::map<size_t, unit *> umap;" line at the top of unit_map.hpp suggests otherwise
20100602 22:02:19< gabba> seems to me like unit_map holds unit pointers, not the units themselves
20100602 22:02:45< alink> as I said, with current implementation, unit_map copy ctor copy all units
20100602 22:03:22< gabba> ok, I trust you on that
20100602 22:03:31< alink> and, besides, unit must be stored somewhere, and currently it's into the unit_map (using new and delete, if you want)
20100602 22:04:07< boucman> gabba: it makes sense, there is no reason that two images of a unit at different time have the same HP and stuff like that
20100602 22:04:31< alink> gabba:just check unit_map(const unit_map &that); which call add() which call "new unit"
20100602 22:04:39-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100602 22:04:59< alink> gabba: btw there is other coders knowing unit_map far better than me
20100602 22:05:43< gabba> yeah looking at the code now
20100602 22:05:54< alink> for the little story, in the past, some perf killers were simply people forgetting to use reference when using unit_map
20100602 22:06:50< gabba> history is always a good teacher :)
20100602 22:08:48< silene> gabba, boucman, et al: just a thought, you are aware of wml "select" event, right?
20100602 22:09:19< gabba> silene: not really
20100602 22:09:27< gabba> (as far as I'm concerned)
20100602 22:09:30< alink> grmbml "select" event :-/
20100602 22:09:32< silene> gabba: whenever you select a unit, wml code is executed
20100602 22:09:35< boucman> is that the one for doing multiple choice menus ?
20100602 22:09:45< boucman> ah, that one :(
20100602 22:09:47< silene> boucman: among other things
20100602 22:10:16< alink> not sure how whiteboard UI will works, but when switching to observer mode, select event are disabled
20100602 22:10:53< gabba> judging by boucman's and alink's reactions, that event has caused trouble in the past :P
20100602 22:11:21< silene> gabba: a bit, but you have to know that it is heavily used in some umc
20100602 22:11:31< alink> depending how you trigger whiteboard actions, we could just temporary use observer mode (or a new similar flag)
20100602 22:11:55-!- Blueblaze [~nick@adsl-76-202-16-2.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 248 seconds]
20100602 22:12:00-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100602 22:12:23< gabba> silene: so, I either have to assume that anything can happen when a unit is selected (such as all units disappearing), or disable that event?
20100602 22:12:28-!- cjhopman_ [~chris@wesnoth/developer/cjhopman] has quit [Ping timeout: 276 seconds]
20100602 22:12:39< silene> gabba: yes
20100602 22:12:40< boucman> it's an event that is triggered whenever you click on a unit, basically
20100602 22:12:48< boucman> and allow to do right click menus
20100602 22:13:21< alink> when you click a unit and where the engine is idling, for example during anim, it's disabled
20100602 22:13:30< alink> s/where/when
20100602 22:13:47-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100602 22:14:26< gabba> if it only allowed right-click menus it wouldn't be a problem
20100602 22:14:40< alink> mmh i think there is code for triggering delayed select event, but it was not perfect
20100602 22:14:45< silene> gabba: no it's more than that; try the tutorial
20100602 22:15:39< gabba> And there's no way to detect what was affected by the wml code triggered by the "select" event?
20100602 22:15:40< alink> gabba: doesn't matter, you can't have any assumption about WML event effect
20100602 22:16:45< alink> silene: btw how is it a problem for this? whiteboard mode will ignore all WML events
20100602 22:17:01< alink> it will be all fake move, fake deaths etc...
20100602 22:17:29-!- yann [~dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has quit [Ping timeout: 260 seconds]
20100602 22:17:32< alink> and we will always restore unit_map before letting the player click around
20100602 22:18:03< gabba> alink: not so sure, one of the goals was to eventually have whiteboard mode by default, maybe even as a replacement to undo, if it's deemed a good replacement
20100602 22:18:05< silene> alink: i'm not saying it's a problem; i just wanted to point out the issue; as long as there aren't random or missing select events, it's fine
20100602 22:19:25< alink> silene: ok, but thanks for the warning, it's true that it's a tricky thing when working on UI/mouse parts
20100602 22:20:31< alink> gabba: undo are often all flushed when an event is triggered (move, select)
20100602 22:20:50< alink> but i think there is WML flag for that
20100602 22:21:06< silene> not a flag, a tag, [allow_undo]
20100602 22:21:17< alink> ok, that one :-)
20100602 22:21:33< gabba> I suppose I can do something like player selects -> wml stuff happens -> validate all planned actions -> proceed with drawing arrow etc if all's fine
20100602 22:22:19< silene> which planned actions?
20100602 22:22:30< gabba> the whiteboard planned actions
20100602 22:22:47< alink> anyway as i see, select event is not a special case here, each time any WML code is triggered, you will need to recheck consistency of all planned actions
20100602 22:23:30< gabba> alink: yes, it's just a bit more annoying if it happens in the middle of UI interaction, but I think I can manage
20100602 22:23:57< alink> ah but if an UMC use crazy select event, it could make the whiteboard less usefull
20100602 22:24:12< alink> but that will be the fault of the UMC
20100602 22:24:25< silene> gabba: you can't have planned actions after having executed wml code; all of them should have been executed before it
20100602 22:24:41< gabba> yeah, with great wml power comes great responsibility, and stuff ;)
20100602 22:24:55< gabba> silene: huh?
20100602 22:25:08< gabba> silene: I smell misunderstanding
20100602 22:26:08< gabba> silene: let's say I planned 30 moves with the whiteboard, and then I select a unit which triggers a "select" event, it's a valid use case isn't it?
20100602 22:26:33< alink> silene: planned action is "I plan to move unit from (5,4) to (10,4)", if WML change things enough to make this impossible, the whiteboard UI is supposed to warn you
20100602 22:27:15< gabba> planned moves persist even from turn to turn, they just get marked as conflicted if they become impossible for some reason, so the player can adjust or delete them manually
20100602 22:27:40< gabba>  + what alink said
20100602 22:29:01< gabba> boucman, alink, silene: is there a generic way to tell if a wml event was just triggered? I'm not sure how the code flow works in that area.
20100602 22:29:22< silene> alink: that's not the issue; a "select" event is not a "moveto" event, it doesn't happen as a consequence of a move, it happens as soon as you click a unit, even if you don't do anything with it; so if there some moves not yet committed, it's breaking causality from a user point of view
20100602 22:29:36< alink> one of the WML event function (fire?) return a bool or something
20100602 22:31:31< gabba> alink: a more specific pointer would be appreciated :)
20100602 22:32:14< gabba> silene: I'm not really following you there... how does it "break causality"?
20100602 22:32:25< alink> gabba: search what trigger shroud update and undo clear , WML events do such thinsg
20100602 22:32:30-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100602 22:33:09-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100602 22:33:26< alink> silene: to be clear, are you talking about the select triggered when the user really click, or the select needed when auto-executing the planned move ?
20100602 22:33:31-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100602 22:33:44< alink> (I just thought about the later now)
20100602 22:34:10< alink> which is indeed a possible problem
20100602 22:34:56< silene> alink: no i'm just talking about the first case; what happens when a user selects a unit while there is an uncommitted move?
20100602 22:35:03< alink> gabba: is there even an auto-execution of planned moves, or whiteboard is just planning/drawing stuff
20100602 22:35:45< alink> silene: their validity is rechecked 
20100602 22:35:57< boucman> alink: there will be, but we recheck everything before executing
20100602 22:36:04< CIA-87> silene * r43133 /trunk/src/gui/auxiliary/widget_definition/slider.cpp: Avoided costly roundtrip through strings.
20100602 22:36:07< CIA-87> silene * r43134 /trunk/src/gui/auxiliary/canvas.cpp: Avoided costly roundtrip through strings.
20100602 22:36:10< CIA-87> silene * r43135 /trunk/src/builder.cpp: Avoided costly roundtrip through strings.
20100602 22:36:12< alink> and a 'impossible' warning  may be displayed
20100602 22:36:14< CIA-87> silene * r43136 /trunk/src/multiplayer_connect.cpp: Avoided costly roundtrip through strings.
20100602 22:36:21< CIA-87> silene * r43137 /trunk/src/game_config.cpp: Avoided costly roundtrip through strings.
20100602 22:36:22< CIA-87> silene * r43138 /trunk/src/playturn.cpp: Avoided costly roundtrip through strings.
20100602 22:36:36< silene> alink: so the planned move, while prepared before, is executed after the select event; that's what i call breaking causality
20100602 22:36:47< gabba> alink: the player can either select a unit and execute it's planned move using context menu or hotkey; you can as well ask for "execute all", which executes orders in sequence until some blocking event happens
20100602 22:38:39< gabba> silene: did you read my wiki project page? I kind of feel you're missing some info on how the whole thing is supposed to work...
20100602 22:39:14< alink> silene: well, the user expect change. For example you can plan move during oppenent's turn (I think)
20100602 22:39:36< gabba> alink: yes, you can
20100602 22:40:07< alink> silene: it's the job of the UI to warn the user: 'such move is now impossible or the path is differrent that you wanted'
20100602 22:40:20< alink> s/that/than
20100602 22:40:46-!- Daltx [~Daltx@CPE001e5840eaf6-CM00195ee19c52.cpe.net.cable.rogers.com] has left #wesnoth-dev []
20100602 22:41:16< alink> silene: as an example, old goto move have the similar problem
20100602 22:41:59-!- Johannes13__ [~Johannes@pD9502B53.dip0.t-ipconnect.de] has joined #wesnoth-dev
20100602 22:42:11< gabba> silene: the worse that can happen is that the unit has a planned move, the player selects is for whatever reason (maybe just to highlight it's planned move arrow, not to execute the move yet), and then wml does something and planned move arrow changes to a dotted one, indicating the move just became invalid for some reason. To me, that's acceptable.
20100602 22:42:12< silene> alink: that's not my point; let's take an example, suppose you have planned a move, and then you select another unit to invoke a direct spell like a heal (e.g. wesband, era of magic, and so on); where does the heal land?
20100602 22:42:56< gabba> silene: it lands as usual I guess, no interaction with the whiteboard there
20100602 22:43:56< gabba> silene: but I see what you're getting at... one thing to remember is that planned moves don't hide the unit's original location
20100602 22:45:22< silene> gabba: so we are back to the point that prompted my talking about the "select" event; be careful what the unit_map contains before wml happens
20100602 22:45:35< gabba> silene: the graphics are: real unit --> arrow --> non-selectable ghost (future location of unit); so, the unit is still there for whatever immediate effects you want to apply
20100602 22:45:39-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 260 seconds]
20100602 22:46:03< alink> silene: planning move don't change unit's location before executing them. If you heal before execute planned move, you will move an healed unit. If you execute first, the unit move away and you can't heal him
20100602 22:47:23< alink> silene: if this is about temporary modification of unit_map, then all is fine, unit_map will always be restored before returning to mouse code
20100602 22:48:20< alink> such temporary modification will only be used to check planned move validity, not to store any intermediate states
20100602 22:48:48< gabba> silene: Rather, after the wml event happens, first thing I'll do is go through planned actions and see if they still make sense, and either delete them or change their visuals if they don't, depending on the type of action
20100602 22:49:41< gabba> silene: and about the unit map, alink is right: the unit map will always be restored before code leaves my control
20100602 22:50:26< gabba> hopefully this is sorted out and I can get to coding, now :P
20100602 22:54:14-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20100602 22:54:14-!- stikonas_ [~and@bcm-131-111-247-104.girton.cam.ac.uk] has joined #wesnoth-dev
20100602 22:54:14-!- stikonas_ [~and@bcm-131-111-247-104.girton.cam.ac.uk] has quit [Changing host]
20100602 22:54:14-!- stikonas_ [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100602 22:56:19< alink> To answer your previous question (when a WML event was really executed?) see actions.cpp:2448
20100602 22:56:24< alink> gabba^
20100602 22:56:48< gabba> thanks alink, bookmarking it
20100602 22:57:33< alink> well, this is just one example of a way to do it. There is maybe other ones
20100602 22:58:08< alink> but it's the typical case, unit moves and triggers moveto and sighted event
20100602 22:59:05-!- Tesafilmchen [~quassel@p4FDE7B0A.dip.t-dialin.net] has joined #wesnoth-dev
20100602 23:21:44-!- ancestral [~ancestral@12.145.225.25] has joined #wesnoth-dev
20100602 23:23:34-!- Johannes13__ [~Johannes@pD9502B53.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
20100602 23:23:51< boucman> gabba: i'm going to bed, thx for the questions, but you design was good from the start, so let's go for it and see in what walls we bump :)
20100602 23:24:46< gabba> boucman: ok, I'm starting on this and let's see what happens
20100602 23:25:03< boucman> night all
20100602 23:25:04< gabba> 'night
20100602 23:25:07-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100602 23:27:16-!- Greywhind [~Greywhind@138.16.58.24] has quit [Quit: leaving]
20100602 23:27:18< gabba> alink: ok I see, game_events::raise adds to the event queue, and game_events::pump executes them and returns true if any event was executed
20100602 23:28:50< ancestral> Does svn diff work recursively by default?
20100602 23:29:43< gabba> alink: executing a move and figuring out whether a wml event happened during the execution might be tricky though
20100602 23:29:43< Espreon> Yeah.
20100602 23:29:51< Espreon> ancestral: ^
20100602 23:30:07< ancestral> Oh what am I doing wrong now…
20100602 23:31:23< ancestral> So I'm attempting to make a patch which changes binary files, and boucman suggested running diff anyway
20100602 23:31:30< ancestral> binary files == images
20100602 23:32:02< ancestral> Maybe it's working fine, that svn diff doesn't compare differences in binary files
20100602 23:32:03 * Espreon rolls his eyes
20100602 23:32:18< ancestral> (my diff on my computer does)
20100602 23:32:42< ancestral> Espreon: Care to add something?
20100602 23:33:02< Espreon> No, not really.
20100602 23:33:28 * Espreon just finds the idea of making a patch for binary files to be absurd.
20100602 23:33:28< ancestral> I'm sorry. It's hard to interpret emotes sometimes.
20100602 23:33:53-!- thespaceinvader [~chatzilla@wesnoth/artist/thespaceinvader] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]]
20100602 23:33:54< alink> gabba: I don't see why, you will call the engine function ::move() which must already know if an event was triggered, just need to tell you about it somehow
20100602 23:34:04< ancestral> Well, on my computer, for example, diff will tell you which directory files are only in and which files are different
20100602 23:34:24< ancestral> And that actually would be helpful, but it looks like svn diff is pretty primitive (at least, in comparison)
20100602 23:34:26< alink> gabba: just a question of how to pass/store the information
20100602 23:34:38< ancestral> Anyway, I guess I answered my own question
20100602 23:35:19< gabba> alink: thing is, I'm reluctant to modify move() and other core functions
20100602 23:35:25< Espreon> ancestral: I don't think that SVN has its own thing; it probably uses an external tool.
20100602 23:35:40< Espreon> So, just make it use something else.
20100602 23:35:55< ancestral> Then where is diff being run from I wonder
20100602 23:36:08< ancestral> I might try -x
20100602 23:36:36< alink> gabba: i see (wise decision). Well, in this case you can add your own code just reading/saving info and don't touch anything of the code flow
20100602 23:36:38< ABCD> the only scm that I know of that really does binary diffs is git :)
20100602 23:36:41< ancestral> Yeah svn does have an internal diff
20100602 23:37:14< Espreon> I believe that one can make it use something else.
20100602 23:37:29< Espreon> Look at your configuration files for clues.
20100602 23:37:47< alink> gabba: or have a global wb::mark_arrows_dirty() and call it after the pump() 
20100602 23:38:39< gabba> alink: I like that better than modifying the ::move() method signature, at least
20100602 23:38:59< alink> gabba: btw if you code is fast enough, you may even recheck things after each engine actions regardless of WML events 
20100602 23:39:18< alink> i even suggest starting doing this for start ^
20100602 23:39:27< silene> and after each debug command too
20100602 23:39:29-!- stikonas_ [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100602 23:40:21< gabba> alink: interesting. Is there a central place like pump() from which I can detect engine actions? (I assume pump() is only for wml.) 
20100602 23:42:12-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100602 23:42:21< gabba> alink: or you're suggesting that I pepper the code with wb::mark_arrows_dirty() calls?
20100602 23:42:50< alink> gabba: not sure, but there is not many possible actions (move,attack,select...) , debug commands are a problem though
20100602 23:42:55< ancestral> Blecch wrapper scripts. Not worth it.
20100602 23:42:58-!- silene [~plouf@wesnoth/developer/silene] has quit [Quit: Leaving.]
20100602 23:43:33< alink> gabba: i have no better idea for now
20100602 23:43:56< gabba> alink: thanks, that's already a good start
20100602 23:45:14< alink> gabba: note that a lot of such code is already peppered with update shroud, minimap, side panel,  etc..
20100602 23:49:13< gabba> alink: I wonder why nobody ever felt the need for an observer pattern for this stuff, or at least for wml events... something  like a "notify_observers(string event)" in game_events::raise()
20100602 23:51:31< alink> yeah, not sure why. Maybe because WML events may change so many things, you may end notify half of the code :-/
20100602 23:51:52< alink> and the notified will have no idea of what changed
20100602 23:52:29< alink> but that's a pessimistic view, your idea seems good and may be very usefull 
20100602 23:52:53< alink> it's just that WML events are so annoying :-/
20100602 23:53:24< alink> they change stuff behind your back (and only when playing rare UMC)
20100602 23:57:19-!- Tesafilmchen [~quassel@p4FDE7B0A.dip.t-dialin.net] has quit [Remote host closed the connection]
--- Log closed Thu Jun 03 00:00:36 2010