--- Log opened Wed Jun 16 00:00:46 2010
20100616 00:00:50< ABCD> -fno-strict-aliasing will turn off the warning by telling the compiler that you really might have non-strict aliasing happening, so don't optimize it away
20100616 00:01:33< ABCD> (-Wno-strict-aliasing just disables the warning, -fno-strict-aliasing changes compilation to ensure that the program still works the way you expected)
20100616 00:02:45-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20100616 00:10:43-!- _jbx_ [~jbailey@12.190.80.225] has quit [Quit: Dig that hole, forget the sun.]
20100616 00:12:03< Espreon> gabba: All is well.
20100616 00:12:12< gabba> good
20100616 00:20:17-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has quit [Quit: ancestral]
20100616 00:25:05-!- kevg [~kevg@94.232.5.102] has left #wesnoth-dev []
20100616 00:27:36-!- norbert_ [~norbert@82-171-70-54.ip.telfort.nl] has quit [Quit: Leaving]
20100616 00:28:34< Espreon> gabba: You probably already know this, but in the whiteboard, if one plans a move, replans the same unit's move, and then clicks on that unit, the game segfaults.
20100616 00:29:21< gabba> yeah, I was precisely pulling my hair out over this, and I just found the cause
20100616 00:29:39< gabba> now to find the solution :-/
20100616 00:29:49< Espreon> Yay...
20100616 00:30:03< gabba> Yay indeed
20100616 00:31:38-!- zookeeper [~l@wesnoth/developer/zookeeper] has quit []
20100616 00:33:53-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has joined #wesnoth-dev
20100616 00:46:48-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 265 seconds]
20100616 00:48:28< gabba> boucman: some (idle?) animation seems to kick in at some point on the whiteboard's unit ghosts, canceling the "ghosted" animation...
20100616 00:50:13< boucman> gabba: hmm, good point... I have a good idea why, i'll fix that tomorow (please remind me to)
20100616 00:50:17< boucman> going to bed now
20100616 00:50:27-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100616 00:58:18-!- Sangel [~sangel@adsl-99-140-187-157.dsl.chcgil.sbcglobal.net] has joined #wesnoth-dev
20100616 01:03:50-!- Sangel [~sangel@adsl-99-140-187-157.dsl.chcgil.sbcglobal.net] has quit [Quit: Sangel]
20100616 01:05:56-!- Shakey [HydraIRC@c-71-201-89-187.hsd1.il.comcast.net] has joined #wesnoth-dev
20100616 01:07:42< CIA-86> gabba * r43473 /trunk/src/whiteboard/ (8 files): Whiteboard: redefinition of moves doesn't crash anymore; a little problem with invalidation remains
20100616 01:07:46< CIA-86> gabba * r43474 /trunk/src/arrow.cpp: Arrows: fixed invalidation on delete.
20100616 01:11:39-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has quit [Quit: ancestral]
20100616 01:14:10-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has joined #wesnoth-dev
20100616 01:25:19-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has quit [Quit: ancestral]
20100616 01:26:16-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has joined #wesnoth-dev
20100616 01:43:42< Espreon> alink: http://imagebin.org/101485 — Please convert that fake dash into an em dash.
20100616 01:47:34-!- Appleman1234 [~Appleman1@CPE-60-226-180-71.qld.bigpond.net.au] has joined #wesnoth-dev
20100616 01:53:42-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Ping timeout: 265 seconds]
20100616 01:56:09< Espreon> boucman: Some swamp and swamp village tiles have hex outlines.
20100616 01:57:56-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Remote host closed the connection]
20100616 01:58:57-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has quit [Quit: ancestral]
20100616 02:26:00-!- Shakey [HydraIRC@c-71-201-89-187.hsd1.il.comcast.net] has quit [Quit:  HydraIRC -> http://www.hydrairc.com <- Would you like to know more?]
20100616 02:53:14< CIA-86> eleazar * r43475 /trunk/data/core/ (48 files in 2 dirs): much uploading of exparamental half-finished terrain especially grass and dirt shore.
20100616 03:03:18< CIA-86> gabba * r43476 /trunk/src/whiteboard/ (manager.cpp manager.hpp visitor.hpp): Whiteboard: minor refactoring, comments, cleanup
20100616 03:03:22< CIA-86> gabba * r43477 /trunk/src/ (9 files in 2 dirs): Whiteboard: highlight-on-hover for planned moves
20100616 03:10:13-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100616 03:17:50-!- Blueblazed [~nick@99.182.54.45] has joined #wesnoth-dev
20100616 03:18:54-!- Blueblazed [~nick@99.182.54.45] has quit [Client Quit]
20100616 03:19:07-!- Blueblazed [~nick@adsl-99-182-54-45.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100616 03:23:01-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz]
20100616 03:23:21-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100616 03:23:39-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20100616 03:28:24< Crab_> alink: multistep_move_possible can be removed from trunk, it's not used atm (it was used by old default ai to see if it needed to visit a keep while doing a move)
20100616 04:07:57-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has joined #wesnoth-dev
20100616 04:29:31< CIA-86> espreon * r43478 /trunk/ (54 files in 3 dirs): Converted straight apostrophes in the name macros to their curly forms; ran pofix.
20100616 04:31:16< CIA-86> espreon * r43479 /trunk/data/core/macros/deprecated-utils.cfg: Removed the deprecated macros, for they should have been removed a long time ago.
20100616 04:37:11-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 260 seconds]
20100616 04:41:33-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100616 04:49:18< Aethaeryn> Espreon: something broke in my build.
20100616 04:49:22< Aethaeryn> of the latest trunk
20100616 04:49:31< Aethaeryn> did you manage to get it to build?
20100616 04:49:40< Aethaeryn> need to know if it's local or more
20100616 04:49:51< Espreon> Hold on...
20100616 04:49:57< shadowmaster> what's the symptom?
20100616 04:53:01< Aethaeryn> http://wesnoth.pastebin.com/zH0Y7P1R
20100616 04:53:04< Aethaeryn> sorry for the delay, IM
20100616 04:53:59< Crab_> seems like someone forgot to add a file...
20100616 04:54:08< shadowmaster> wtf
20100616 04:54:11< shadowmaster> why is this thing recompiling the AI again?
20100616 04:54:23< Espreon> Crab_: Well, how dare he/she/it/they!
20100616 04:54:37< shadowmaster> I'm starting to suspect it's related to revision.hpp
20100616 04:54:52< shadowmaster> the gratuitous AI recompiles, that is
20100616 04:55:25< Crab_> shadowmaster: there was a commit to src/ai/actions.hpp recently (yesterday in the evening)
20100616 04:55:47< shadowmaster> yes, but I recompiled only a few hours ago
20100616 04:55:50< Espreon> gabba: We're missing a file...
20100616 04:55:56< shadowmaster> and now it's recompiling the AI again
20100616 04:56:15< shadowmaster> I'd like to know of a tool that can help me track header dependencies here
20100616 04:56:30< Crab_> shadowmaster: and there were buildfile changes, too
20100616 04:56:57< gabba> Espreon: let me see... 
20100616 04:57:05< shadowmaster> um, ccache should be helping me with that
20100616 04:57:21< shadowmaster> unless the command line to the compiler changed, which it doesn't look any different IIRC
20100616 04:57:46< gabba> Espreon: damn yes, I'm going too fast today, I forgot to git add the new file
20100616 04:58:06< Espreon> Ah, I see.
20100616 04:58:43< gabba> shadowmaster: I may be responsible for *some* of the recompiles: I had to change stuff in display.hpp, which is imported in a lot of places
20100616 04:59:03< shadowmaster> uh-huh.
20100616 04:59:04-!- Ivanovic_ [~ivanovic@dtmd-4db23b20.pool.mediaWays.net] has joined #wesnoth-dev
20100616 04:59:13< gabba> shadowmaster: but sometimes it does seem to recompile without reason: revision.hpp?
20100616 04:59:19< shadowmaster> commit something so I can try to prove my revision.hpp theory anyway :p
20100616 04:59:29< gabba> yeah, coming up
20100616 04:59:58< shadowmaster> I shouldn't be seeing ai/composite/engine_fai.o being regenerated the next time
20100616 05:00:41-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Quit: Leaves have fallen all around. It's time I was on my way. Thanks to you I'm much obliged for such a pleasant stay.]
20100616 05:02:03-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 258 seconds]
20100616 05:02:14< CIA-86> gabba * r43480 /trunk/src/whiteboard/ (highlight_visitor.cpp highlight_visitor.hpp): Missing files
20100616 05:02:27< gabba> Here are the missing files, sorry for the trouble guys
20100616 05:03:02-!- Ivanovic_ is now known as Ivanovic
20100616 05:03:23< Espreon> Aethaeryn: ^
20100616 05:03:34< Aethaeryn> k
20100616 05:06:29< Aethaeryn> running
20100616 05:06:47< Aethaeryn> might take a while, I don't know if an aborted compile will force scons to redo the whole thing now
20100616 05:09:04-!- King_Elendil [~King_Elen@75.143.233.138] has joined #wesnoth-dev
20100616 05:09:27< Aethaeryn> scons: done building targets.
20100616 05:09:29< Aethaeryn> worked :D
20100616 05:10:07< shadowmaster> okay, let's see what happens
20100616 05:12:37< shadowmaster> okay, it regenerated revision.hpp but it doesn't seem to be going to recompile the whole thing
20100616 05:13:07 * ABCD really, really, really doesn't like scons (speaking as a packager)
20100616 05:13:11< shadowmaster> so I guess I'm just unlucky and always get to compile after major changes
20100616 05:13:23< shadowmaster> Aethaeryn: hence we still support autotools
20100616 05:13:29< shadowmaster> er, ABCD 
20100616 05:13:59< ABCD> I just use cmake, which does the job just fine
20100616 05:14:02< shadowmaster> I prefer autotools to scons as software maintainer, but as software developer I prefer scons
20100616 05:14:23< shadowmaster> *the Wesnothian scons recipe
20100616 05:15:14 * ancestral prefers scones to scons
20100616 05:15:20< ABCD> as a packager, dealing with scons is horrible, as there is practically no standardization, unlike with autotools/cmake
20100616 05:15:48< gabba> Crab_: do you have a minute to help me with a rather hairy C++ problem?
20100616 05:16:16< Crab_> gabba: I can try
20100616 05:17:26< gabba> Crab_: ok, I want to remove the direct dependency of class team in team.hpp on my "whiteboard/side_actions.hpp" header, ...
20100616 05:18:23< gabba> but std::auto_ptr, boost::scoped_ptr and boost::shared_ptr all prove impossible to introduce: compilation fails with cryptic errors
20100616 05:18:43< gabba> Crab_: so, is there anything special I should know about this class?
20100616 05:19:11< Crab_> gabba: are you sure about whiteboard/side_actions.hpp ?
20100616 05:19:23< Crab_> gabba: I see no direct dependency to team.hpp there
20100616 05:19:48< gabba> team.hpp contains the line #include "whiteboard/side_actions.hpp"
20100616 05:20:04< Crab_> ah, sorry, I got it reverse ;)
20100616 05:20:11< gabba> yeah ;)
20100616 05:20:46< Crab_> boost::shared_ptr should work ok, how do you use it ?
20100616 05:21:04-!- King_Elendil [~King_Elen@75.143.233.138] has quit [Read error: Connection reset by peer]
20100616 05:21:35< Crab_> gabba: have you done a proper forward declaration of wb::side_actions ?        namespace wb { class side_actions; }
20100616 05:22:26< gabba> Crab_: indeed -- I got smart pointers to work this way in many other classes
20100616 05:22:50< Crab_> if there are compilation errors after trying that, show the code/the errors.
20100616 05:23:03< gabba> Crab_: I you want to see code, I can go back to one of my tries and show you the diff and compile errors
20100616 05:23:13< Crab_> yes
20100616 05:23:14< gabba> it'll take a few minutes
20100616 05:23:16< Crab_> ok
20100616 05:31:00< gabba> Crab_: here's the diff http://wesnoth.pastebin.com/ee5rWTT5
20100616 05:31:37< Crab_> gabba: the wb::side_actions& team::get_side_actions() is problematic
20100616 05:31:48< Crab_> you need to return a smart pointer in there
20100616 05:32:00< gabba> the reference?
20100616 05:32:39< Crab_> (show the compilation errors, please)
20100616 05:32:41< gabba> Crab_: actually I'm ok with the team having sole ownership
20100616 05:33:21< gabba> Crab_: here you go, compilation errors: http://wesnoth.pastebin.com/MDmftWvZ
20100616 05:34:03< gabba> above that, it all looks good
20100616 05:35:18< Crab_> ah, sorry again, then. the problem is that ca_testing_move_to_targets.cpp previously got your headers through team.hpp
20100616 05:36:19< Crab_> so, readd it in there (#include "../../whiteboard/side_actions.hpp"  in src/ai/testing/ca_testing_move_to_targets.cpp
20100616 05:37:27< gabba> Crab_: you mean you are already using my stuff :P ?
20100616 05:37:35< Crab_> no, it's not me
20100616 05:37:44< Crab_> git svn blame someone else :)
20100616 05:38:25< Crab_> #include <deque> might be enough..
20100616 05:39:01< Crab_> it looks like someone had 'optimized' header dependencies
20100616 05:39:20< gabba> I understand what happened, but that was weird :-/
20100616 05:39:33< gabba> Crab_: thanks for the diagnostic
20100616 05:40:29< Crab_> gabba: in general, if you see something like ' error: request for member ‘push_back’ in ‘preferred_moves’, which is of non-class type ‘int’' then check the type of  ‘preferred_moves’ and see how it comes that it's unknown at the mentioned line.
20100616 05:40:51< Crab_> in that case, preferred_moves is a std::deque<map_location>
20100616 05:41:44< gabba> I see... I don't know where's the "optimization" in removing the standard library includes, but meh. I'll know for next time.
20100616 05:42:29< ancestral> Is there a way I can have svn update without any .svn info?
20100616 05:42:49< ancestral> I guess it'd be a mass diff or something
20100616 05:43:39< Crab_> ancestral: recheckout or play games like "create a local repository, import everything to there, checkout from there, svn switch --relocate to using wesnoth's repo."
20100616 05:47:30< Crab_> gabba: most likely, it was a unintended side effect
20100616 05:48:25< ancestral> bah I'll just dump and grab
20100616 05:48:29< gabba> Crab_: yeah, judging from the history it was a piling up of changes which caused that
20100616 05:49:25< gabba> it had been a long, long time since I freaked out before a seemingly incomprehensible and totally unrelated error message :P
20100616 05:50:02< gabba> and indeed, with just #include <deque> it builds
20100616 05:51:47< Crab_> gabba: I think that it was like this: some time ago, ca_testing_move_to_targets.cpp got deque through the header file A. then, after your changes, ca_testing_move_to_targets.cpp has got deque through two header files, team.hpp and that header A. 
20100616 05:51:48< Crab_> Then, dependency on B was removed to simplify the dependencies in other parts of the code,   but ca_testing_move_to_targets.cpp compiled nevertheless thanks to team.hpp using your code which referenced deque.
20100616 05:52:14< Crab_> s/on B/on A
20100616 05:52:29< gabba> your explanation makes a lot of sense
20100616 05:53:14< Crab_> so, your code has become a cornerstone on which other, seemingly unrelated, pieces of wesnoth started to depend :)
20100616 05:54:21< gabba> lol, in this case I would've preferred my code to stay in its little corner for a while more
20100616 05:54:46< gabba> Crab_: just to have your opinion on the philosophical approach to pointers: if it doesn't make sense that the planned_actions outlive the team, isn't it better to have them managed by a boost::scoped_ptr and return references to interested parties that wanna use the object?
20100616 05:55:28< Crab_> (afair, there are tools which can produce a list of such dependencies for human to review - like 'file FOO uses BAR but doesn't include bar.h'  )
20100616 05:55:37< gabba> If I use a shared_ptr, other classes can keep the planned_actions alive after team is dead, and I don't think it's a good idea
20100616 05:56:33< gabba> ^interesting, I'll look up this kind of tool at some point
20100616 05:56:43-!- un214 [~quassel@adsl-75-45-4-19.dsl.scrm01.sbcglobal.net] has joined #wesnoth-dev
20100616 05:57:42< Crab_> I use shared_pointers in the ai, even for objects which can use scoped pointers. it's slightly easier to code that way, as I can deal only in smart pointers.
20100616 05:58:43< Crab_> but, I would prefer planned_actions to stay outside of team unless you plan to make them persistent
20100616 05:59:21< un214> or make them itempotent
20100616 05:59:29< Crab_> e.g., if you make them stay when we save/load, they do belong it team
20100616 05:59:35< un214> (but that requires test cases)
20100616 06:01:20< gabba> Crab_: I put them there because boucman suggested it as a proper place (they share the same lifecycle). But I don't think making them persistent is worth the effort, especially for this summer.
20100616 06:01:28< Crab_> ' other classes can keep the planned_actions alive after team is dead, and I don't think it's a good idea' - it doesn't matter much, as other classes can keep a (invalid) reference after team is dead, too :)
20100616 06:02:07< Crab_> gabba: 'especially for this summer' is not that important.. more important is your 'vision' of the whiteboard system
20100616 06:02:35< un214> so what exactly is unsafe_lua
20100616 06:02:41< Crab_> how it should be ? should they, someday, be stored in savegames ? or they are transient stuff that should disappear when we save/load ?
20100616 06:03:28-!- un214 [~quassel@adsl-75-45-4-19.dsl.scrm01.sbcglobal.net] has quit [Remote host closed the connection]
20100616 06:03:38< gabba> well, since they're gonna be serializable to configs (for the network), I guess saving them to savegames wouldn't be much of a step
20100616 06:04:05< gabba> but whether they're really useful to carry on from game to game...
20100616 06:04:07< Crab_> un214: unsafe_lua allows lua code to load arbitrary packages.
20100616 06:04:37< Crab_> gabba: yes, implementation is not that hard. but should they or not ?
20100616 06:05:28< gabba> Crab_: I think they're worth saving in the case of a large game (4+ players) where you have defined moves while it's not your turn. It would suck to lose them, and thus we'd lose part of the "pick up where you've left" aspect of a savegame.
20100616 06:05:41< Crab_> gabba: ok, good
20100616 06:05:53< Crab_> then yes, making the team their object makes sense
20100616 06:05:58< Crab_> s/object/owner
20100616 06:06:23< Crab_> especially if you can get away with only returning const references to them :)
20100616 06:08:01< Crab_> and, also, note that the code which gets references to planned moves should only live as far as team lives.
20100616 06:08:29< Crab_> so, if done right, the code which can access planned_moves after the team is destroyed should not exist at all.
20100616 06:08:50< gabba> Crab_: not really, I need to do *lots* of modification to the side_actions object; unless you mean deque of actions contained inside, in which case yes, I'm only returning const references to the deque
20100616 06:09:07< Crab_> yes, deque of actions contained inside
20100616 06:09:16< gabba> ok
20100616 06:09:36< Crab_> gabba: e.g., if a FOO_manager accesses planned actions, then the FOO_manager has to be constructed AFTER the team is constructed and has to be destroyed before the team is destroyed.
20100616 06:10:27< gabba> Crab_: member variables are destroyed in reverse order of initialization, isn't it?
20100616 06:10:57< Crab_> afair, yes
20100616 06:11:22< gabba> teams are initialized in play_controller.cpp as well, so I can easily adjust that stuff
20100616 06:11:38< gabba> (i.e. move my manager up/down the list)
20100616 06:11:42< Crab_> yes, it's all tied to play*controller's
20100616 06:12:55-!- Blarumyrran [~Blarumyrr@84-50-143-71-dsl.rkv.estpak.ee] has quit [Quit: Lahkun]
20100616 06:28:05< CIA-86> gabba * r43481 /trunk/src/whiteboard/ (7 files): Whiteboard: initial test of action execution, by defining the same move twice
20100616 06:28:17< CIA-86> gabba * r43482 /trunk/src/ai/testing/ca_testing_move_to_targets.cpp: Added missing include, which prevented the removing of the whiteboard/side_actions.hpp include from team.hpp
20100616 06:28:22< CIA-86> gabba * r43483 /trunk/src/ (team.cpp team.hpp whiteboard/manager.cpp): Removed dependency of team.hpp on whiteboard/side_actions.hpp. Should save some recompiles.
20100616 06:39:34-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20100616 06:40:15-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100616 07:12:21-!- noy_ [~Noy@70.70.255.54] has joined #wesnoth-dev
20100616 07:12:21-!- noy_ [~Noy@70.70.255.54] has quit [Changing host]
20100616 07:12:21-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100616 07:14:14-!- noy [~Noy@wesnoth/developer/noy] has quit [Read error: Connection reset by peer]
20100616 07:14:53-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100616 07:19:07-!- noy_ [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 276 seconds]
20100616 07:21:19-!- Upth [ogmar@adsl-75-26-202-12.dsl.scrm01.sbcglobal.net] has quit [Ping timeout: 260 seconds]
20100616 07:23:16-!- Upth [~ogmar@adsl-75-26-202-12.dsl.scrm01.sbcglobal.net] has joined #wesnoth-dev
20100616 07:23:16-!- Upth is now known as Upthorn
20100616 07:23:43-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100616 07:37:05-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100616 07:41:08-!- noy [~Noy@wesnoth/developer/noy] has quit [Ping timeout: 258 seconds]
20100616 07:41:08-!- noy_ is now known as noy
20100616 07:45:07< CIA-86> gabba * r43484 /trunk/src/ (3 files in 2 dirs): Whiteboard: arrow gets properly reset when selecting a new unit
20100616 07:45:13< CIA-86> gabba * r43485 /trunk/src/ (mouse_events.cpp whiteboard/manager.cpp): Whiteboard: experiment with allowing units to plan moves in spaces left by other units. The visuals don't work yet. Since move validation is not yet in, this can crash the whiteboard if you try weird move combinations
20100616 07:49:24-!- mjs-de [~mjs-de@vpw.wh.uni-dortmund.de] has quit [Remote host closed the connection]
20100616 07:53:40-!- gabba [~gabba@wesnoth/developer/gabba] has left #wesnoth-dev []
20100616 08:10:46-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100616 08:18:44 * zookeeper tries to summon sapient
20100616 08:23:28-!- Blueblazed [~nick@adsl-99-182-54-45.dsl.hstntx.sbcglobal.net] has quit [Remote host closed the connection]
20100616 08:26:34-!- Blueblaze [~nick@adsl-99-182-54-45.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100616 08:31:23-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: crimson_penguin]
20100616 08:49:41-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100616 08:49:55-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has quit [Quit: And that’s the end of THAT chapter.]
20100616 08:51:49-!- Blueblaze [~nick@adsl-99-182-54-45.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 252 seconds]
20100616 08:54:05-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100616 09:07:18-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit []
20100616 09:14:33-!- kevg [~kevg@94.232.5.102] has quit [Remote host closed the connection]
20100616 09:14:55-!- Crab_ [~Crab_@wesnoth/developer/crab] has quit [Quit: Leaving.]
20100616 09:24:47-!- Ivanovic [~ivanovic@dtmd-4db23b20.pool.mediaWays.net] has quit [Changing host]
20100616 09:24:47-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100616 09:25:56< Ivanovic> moin
20100616 09:27:38< Ivanovic> Espreon: you forgot to fix the .pot file
20100616 09:27:51< Ivanovic> Espreon: that is basically as important as all the po files (if not more important!)
20100616 09:28:01< Ivanovic> since it does provide the reference for the po files
20100616 09:30:33-!- euschn [~eugen@wesnoth/developer/euschn] has joined #wesnoth-dev
20100616 09:32:03< CIA-86> ivanovic * r43486 /trunk/po/wesnoth/wesnoth.pot: the update for the reference file (wesnoth.pot) was missing in r43478 by espreon
20100616 10:49:12-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100616 10:49:58-!- ABCD [~abcd@gentoo/developer/abcd] has quit [Quit: Leaving]
20100616 10:57:51-!- thespaceinvader [~chatzilla@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev
20100616 11:22:18-!- ABCD [~abcd@gentoo/developer/abcd] has joined #wesnoth-dev
20100616 11:27:43-!- stikonas_ [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100616 11:28:13-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds]
20100616 11:37:13-!- stikonas_ [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds]
20100616 11:43:21-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: ...]
20100616 11:44:12-!- stikonas_ [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100616 12:01:51-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100616 12:21:58-!- stikonas_ [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20100616 12:25:56< kevg> zookeeper: hi. I wrote candidate action for healers. It should replace current Healing Phase. Is it possible to change one CA for healers only via WML? I need it for testing. Now i can only replace ca in healing macros in ai_candidate_actions.cfg with my ca.
20100616 12:32:25-!- k23z__ [~k23z__@188.26.48.9] has joined #wesnoth-dev
20100616 12:32:50-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100616 12:33:05< CIA-86> thespaceinvader * r43487 /trunk/ (12 files in 3 dirs): Add and wire new Dwarf Lord ranged attack by Cloud. Remove an old unused frame from the Dwarf Lord. Update changelogs.
20100616 12:36:07-!- stikonas_ [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100616 12:39:03-!- Bob_The_Mighty [~chatzilla@cpc4-brig15-0-0-cust904.3-3.cable.virginmedia.com] has joined #wesnoth-dev
20100616 12:39:45< Ivanovic> kevg: regarding candidate action stuff you should probably talk to crab_
20100616 12:39:55< Ivanovic> i don't know how much zookeeper knows about the AI stuff
20100616 12:39:57< Ivanovic> ;)
20100616 12:40:37< kevg> Ivanovic: ok. Will try to ask Crab. 
20100616 12:43:29< AI0867> {MODIFY_AI_ADD_CANDIDATE_ACTION SIDE STAGE_ID CANDIDATE_ACTION}
20100616 12:43:40< AI0867> think that could help
20100616 12:44:17-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has joined #wesnoth-dev
20100616 12:49:39< kevg> i found simple solution: i added new ai stage ;)
20100616 12:50:31-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100616 12:51:29-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100616 13:04:56< Gallaecio> Hi, I found a reference to http://www.wesnoth.org/wiki/CommandMode in Wesnoth manpages. Besides the fact that it could be updated (now its "http://wiki.wesnoth.org/CommandMode"), I have some questions about translation.
20100616 13:05:28< Gallaecio> Is Wesnoth wiki translatable?
20100616 13:06:11< Gallaecio> Or would it be OK in case it's not if I write a translation in an external site (gl.wikibooks.org) and I reference it from the manpages translation?
20100616 13:09:09< loonycyborg> So you want to translate the wiki page too? That's goddamn dedicated :P
20100616 13:09:15-!- mjs-de [~mjs-de@vpw.wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20100616 13:09:52-!- Crab_ [~Crab@wesnoth/developer/crab] has joined #wesnoth-dev
20100616 13:10:53< Gallaecio> :)
20100616 13:11:43< Gallaecio> OK, I found a topic in the forums
20100616 13:11:54< Gallaecio> Looks like official wiki can be translated :)
20100616 13:13:04< Gallaecio> Does anyone know who is in charge of the wiki i18n?
20100616 13:16:34-!- kevg [~kevg@94.232.5.102] has quit [Remote host closed the connection]
20100616 13:21:20< Gallaecio> I guess I should use the wesnoth-i18n mailing list.
20100616 13:22:27< Crab_> Gallaecio: what do you want to do with the wiki ?
20100616 13:24:21< Gallaecio> I want to suggest wiki i18n. With an additional plugin for subpages support and a template (which I can do myself), it should be easy.
20100616 13:33:05< Crab_> the main problem is to keep the content in sync... even the english version can be outdated
20100616 13:33:14< Crab_> nevertheless, it can be tried.
20100616 13:33:47< Crab_> what plugins are to be installed ?
20100616 13:34:34< zookeeper> Gallaecio, IIRC there's no one in charge...you can just translate pages if you want, doesn't seem like there's a need for there to be anything else to it
20100616 13:36:07< Gallaecio> I'll send a propose to the i18n mailing list explaining what I think could be done.
20100616 13:36:16< Gallaecio> Just the way translations could be managed
20100616 13:37:24< Gallaecio> I recently worked with a Chakra GNU/Linux developer to get it's wiki internationalized, and it's easy if we do not try to do something too complicated.
20100616 13:40:21< Crab_> ok. I've got access to install plugins in the wiki and reconfigure it, should something like that be needed.
20100616 13:41:53< Gallaecio> Ok, I'll send the mail soon. If you agree with the i18n method, I'll tell you what plugins would be necesary (just the subpages one and one to autorecognize language codes with it's localized name).
20100616 13:42:27< Gallaecio> Then I would just need to modify the Chakra template so it fits Wesnoth in style.
20100616 13:42:44< Crab_> ok
20100616 13:43:17-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20100616 13:46:39< Gallaecio> Sent.
20100616 13:52:51< Crab_> ok, I see it. I personally think that adding such capability is a good idea, and, if there's agreement on that matter, I'll be able to add the necessary plugins to our wiki.
20100616 13:53:53-!- Ken_Oh [~briang@static-71-178-174-220.washdc.fios.verizon.net] has joined #wesnoth-dev
20100616 13:57:51< Gallaecio> OK, I'll see if I can find out which ones where necesary. Subpages looks like a configuration issue, not an extension. And the other thing looks like a built-in parser function, so maybe there's no need to install anything.
20100616 14:01:10< Gallaecio> Confirmed. To do this there would only be necesary to create the template once the subpages support is active.
20100616 14:04:52< Crab_> ok, I see. so, the only config option is to enable subpages for default namespace ?
20100616 14:06:07< Gallaecio> Yes
20100616 14:07:27< Crab_> ok, then I'll do so in a few days, provided there's no other opinions in the responses to your mail to i18n ml.
20100616 14:09:00< Gallaecio> Ok. :)
20100616 14:10:49-!- Appleman1234 [~Appleman1@CPE-60-226-180-71.qld.bigpond.net.au] has quit [Ping timeout: 264 seconds]
20100616 14:12:39-!- stikonas_ [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20100616 14:16:42< Gallaecio> Ivanovic: you there?
20100616 14:17:22< Ivanovic> huh?
20100616 14:17:36< Gallaecio> I think I found a typo
20100616 14:17:44< Gallaecio> wesnoth-manpages, 24
20100616 14:17:53< Ivanovic> add it to the spelling mistakes wiki page
20100616 14:17:59< Gallaecio> Ok
20100616 14:18:00< Ivanovic> http://wiki.wesnoth.org/SpellingMistakes
20100616 14:18:03< Gallaecio> Thanks
20100616 14:19:03< Ivanovic> you're welcome
20100616 14:20:06< Ivanovic> Gallaecio: regarding translated wiki stuff: it was rather intentional that it is not translated
20100616 14:20:30< Ivanovic> the reason being simple: if WML create stuff or history and whatever is translated it is basically impossible to keep it up to date
20100616 14:20:50< Ivanovic> and especially regarding WML stuff this is a *huge* problem since outdated syntax in some translated wiki page is hell
20100616 14:23:41< zookeeper> yeah, if you translate something then definitely _don't_ translate any technical information, references, tutorials and such.
20100616 14:24:04< Gallaecio> I think keeping wiki translations up to date would be as difficult as maintaining game translations. You just need to keep track of original pages changes (with RSS or Atom).
20100616 14:24:04< zookeeper> since no one will keep those up to date no matter how many people will say that they will
20100616 14:24:08< Ivanovic> and even if you translate some history/background stuff: this should not be outdated either
20100616 14:24:33< Ivanovic> and trust me, keeping this stuff up to date works as long as you got many people dedicated to things
20100616 14:24:54< Ivanovic> but once the amount of people drops, you will easily create hundreds of outdated pages
20100616 14:25:06< Gallaecio> :S
20100616 14:25:10< Ivanovic> (eg look how many translations basically don't progress)
20100616 14:25:26< Gallaecio> Yeah, if the English page is outdated that might be a real problem...
20100616 14:25:49< Gallaecio> (too)
20100616 14:26:32< Gallaecio> So you think it's better to keep the wiki English-only, or to do translations just for some articles?
20100616 14:28:47< Ivanovic> the articles that are specific to the translation should be in that lang
20100616 14:28:58< Ivanovic> but the howto stuff should be understood by translators if it is in english
20100616 14:29:06< Ivanovic> (otherwise how to translate?)
20100616 14:29:29< Ivanovic> if the howto stuff is not good enough to be understood in english: better improve the english version
20100616 14:30:54< Gallaecio> I understand there are some pages not meant to be translated.
20100616 14:31:41< Gallaecio> But I think every final user-oriented page could.
20100616 14:35:33< Gallaecio> And the reasons most translators translate is to feel confortable when reading. They (we) know English, just prefer own language. So I think the problem is not that translations might become outdated (that will always happen with any kind of translation). The problem would be if the original pages were outdated.
20100616 14:38:34< Upthorn> I learned something just now
20100616 14:38:48< Upthorn> from gabba's whiteboard code
20100616 14:41:03< Upthorn> apparently, according to the c++ specification, static const floating point values are not allowed to be defined inside a class declaration. However, static const integer values are. Furthermore, a static const floating point value can be declared in the class declaration and then defined outside using "const <type> <class>::<member> = <value>;" with no problem.
20100616 14:41:44< Upthorn> also MSVC 9 adheres to the (ridiculous) specification on this.
20100616 14:42:41< Crab_> Upthorn: yes. gcc allows to specify a value for static const double in the class declaration, MSVC9 does not (as the standard says).
20100616 14:44:54< AI0867> is there a reasoning for this?
20100616 14:45:03< AI0867> as in, why does the standard say this?
20100616 14:45:17< Upthorn> I do not see what reasoning there could be.
20100616 14:45:51< Upthorn> but I also didn't understand why initializer lists should have to be in member declaration order until someone here explained it to me
20100616 14:50:34-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100616 15:28:10-!- nagbot [~nagbot@wesnoth/bot/nagbot] has joined #wesnoth-dev
20100616 15:31:18-!- Greywhind [~Greywhind@pool-96-238-43-241.prvdri.fios.verizon.net] has quit [Ping timeout: 240 seconds]
20100616 15:33:33-!- Greywhind [~Greywhind@pool-96-238-43-241.prvdri.fios.verizon.net] has joined #wesnoth-dev
20100616 15:41:59-!- Gallaecio [~Gallaecio@232.158.60.213.dynamic.mundo-r.com] has quit [Remote host closed the connection]
20100616 15:48:05< CIA-86> upthorn * r43488 /trunk/src/ (persist_context.cpp persist_context.hpp): Minor changes to initialization order and better separation of member types (object/data/function) in persist_context class and member structs.
20100616 15:48:57< CIA-86> ivanovic * r43489 /trunk/po/ (4 files in 4 dirs): updated Vietnamese translation
20100616 15:49:05< CIA-86> ivanovic * r43490 /branches/1.8/po/ (4 files in 4 dirs): updated Vietnamese translation
20100616 15:49:15< CIA-86> upthorn * r43491 /trunk/src/resources.hpp: correctly marked move_action as a struct, instead of a class, to alleviate linker errors.
20100616 15:50:45< CIA-86> upthorn * r43492 /trunk/src/whiteboard/ (move.cpp move.hpp): Brought the initialization of move class' static const double members in line with C specification (code now compiles in VC9).
20100616 15:52:00-!- Bob_The_Mighty [~chatzilla@cpc4-brig15-0-0-cust904.3-3.cable.virginmedia.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]]
20100616 15:56:25< CIA-86> upthorn * r43493 /trunk/projectfiles/VC9/wesnoth.vcproj: All files that must be compiled are now included in manually maintained VC9 project.
20100616 15:58:25< Crab_> Upthorn: how it's going with the SP persistence ? I would like to start to test and review the code when it'll be ready.
20100616 16:01:17-!- _jbx_ [~jbailey@12.190.80.225] has joined #wesnoth-dev
20100616 16:01:21< CIA-86> ai0867 * r43494 /trunk/data/tools/wesnoth/wmlparser.py: Prettify old wmlparser's WML output,original patch by Hexane
20100616 16:01:24< CIA-86> ai0867 * r43495 /trunk/data/tools/wesnoth/wmlparser.py: Properly excape double-quotes in wmlparser, the only thing not done by python's repr()
20100616 16:01:28< CIA-86> ai0867 * r43496 /trunk/data/tools/wesnoth/wmlparser2.py: Rename wmlparser2's AttributeNode.key to AttributeNode.name, to coinicide with TagNode. Port --to-json from old wmlparser
20100616 16:03:09-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100616 16:08:20< kevg> Crab_: hi. About healers... Now wanna make 3 things with current AI. 1) change combat phase for healers (do not attack if we can make a lot of heal) 2) change healing ca to go to moved healers too (done) 3) write ca for healers (move to places with more healing rate) or insert that code in healing_ca (done with rough healing calculations which should be improved). That's all i have in my mind at the moment. What do you think about it?
20100616 16:08:23-!- alink [~alink@wesnoth/developer/alink] has joined #wesnoth-dev
20100616 16:08:34< Crab_> hi, kevg
20100616 16:09:04< Crab_> yes, looks ok
20100616 16:09:58< Crab_> (1) is tricky atm, you'd probably want to add a hack in the place where attacks are rated
20100616 16:11:14< kevg> btw, how attacks are rated? By expected damage?
20100616 16:19:36< CIA-86> alink * r43497 /trunk/src/ (4 files in 3 dirs): Remove display from ai::game_info, and uses resources::screen instead
20100616 16:19:38< CIA-86> alink * r43498 /trunk/src/ (7 files in 5 dirs): Remove tod_manager from ai::game_info, and uses resources::tod_manager instead
20100616 16:19:41< CIA-86> alink * r43499 /trunk/src/ (4 files in 4 dirs): Remove gamestate from ai::game_info, and uses resources::gamestate instead
20100616 16:22:28< alink> That's some nice T-shirts : http://t-shirts.cafepress.com.au/wesnoth  :-D
20100616 16:23:00< alink> esp. Konrad and Li'sar
20100616 16:24:51-!- kevg [~kevg@94.232.5.102] has quit [Remote host closed the connection]
20100616 16:26:17-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100616 16:27:41< alink> Crab_: I seem to see one use of multistep_move_possible in ai/testing/ca.cpp
20100616 16:29:18-!- k23z__ [~k23z__@188.26.48.9] has quit [Ping timeout: 265 seconds]
20100616 16:29:22-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100616 16:30:25< Crab_> alink: ah, yes. it can be safely removed.
20100616 16:31:11< alink> Crab_: you mean also remove the && multistep_move_possible(..) == false) ?
20100616 16:31:23< Crab_> the entire if () block.
20100616 16:31:35< Crab_> the code (roughtly) forbids the leader to take the village if he can go to keep instead
20100616 16:31:49< Crab_> with RCA ai, it's no longer necessary, as 'go to keep' is more high-priority action.
20100616 16:32:18< alink> Crab_: Ok I trust you and axe it then :)
20100616 16:32:22< Crab_> ok
20100616 16:32:34-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has joined #wesnoth-dev
20100616 16:32:34-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has quit [Changing host]
20100616 16:32:34-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100616 16:34:59< Crab_> kevg: yes, the chance-to-kill and chance-to-be-killed are most important
20100616 16:35:06< CIA-86> alink * r43500 /trunk/src/ai/ (default/contexts.cpp default/contexts.hpp testing/ca.cpp): 
20100616 16:35:06< CIA-86> Remove the now useless multistep_move_possible, as pointed by Crab_:
20100616 16:35:06< CIA-86> "with RCA ai, it's no longer necessary, as 'go to keep' is more high-priority action."
20100616 16:36:09< Crab_> kevg: see attack_analysis::rating in src/ai/default/attack.cpp
20100616 16:36:33< Crab_> kevg: for now, I suggest adding your code there as a hack.
20100616 16:36:37-!- Crab_ [~Crab@wesnoth/developer/crab] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
20100616 16:39:32< CIA-86> alink * r43501 /trunk/src/ai/testing/ (ca.cpp ca.hpp): remove now useless parameter possible_moves from get/find_villages
20100616 16:54:08-!- euschn [~eugen@wesnoth/developer/euschn] has quit [Quit: Leaving.]
20100616 17:18:22-!- knotwork [~markm@142.177.232.37] has quit [Ping timeout: 264 seconds]
20100616 17:30:32-!- k23z__ [~k23z__@188.27.126.157] has joined #wesnoth-dev
20100616 17:34:29-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100616 17:35:15-!- wesbot changed the topic of #wesnoth-dev to: 128 bugs, 283 feature requests, 13 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100616 17:51:06-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
--- Log opened Wed Jun 16 18:18:38 2010
20100616 18:18:46-!- lobby [~wesnoth@wesnoth/bot/lobby] has joined #wesnoth-dev
20100616 18:18:46-!- Topic for #wesnoth-dev: 128 bugs, 283 feature requests, 13 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100616 18:18:46-!- Topic set by wesbot [~wesbot@wesnoth/bot/wesbot] [Wed Jun 16 17:35:15 2010]
20100616 18:18:46[Users #wesnoth-dev]
20100616 18:18:46[ _jbx_          ] [ drusepth       ] [ isaac      ] [ Rhonda         ] 
20100616 18:18:46[ ABCD           ] [ elias          ] [ Ivanovic   ] [ shadowmaster   ] 
20100616 18:18:46[ Aethaeryn      ] [ Elvish_Pillager] [ k23z__     ] [ shikadibot     ] 
20100616 18:18:46[ AI0867         ] [ erl            ] [ Ken_Oh     ] [ Smar           ] 
20100616 18:18:46[ alink          ] [ Espreon        ] [ kevg       ] [ thespaceinvader] 
20100616 18:18:46[ ancestral      ] [ esr            ] [ linease    ] [ Tigge          ] 
20100616 18:18:46[ AnMaster       ] [ ettin          ] [ lobby      ] [ Upthorn        ] 
20100616 18:18:46[ apoi           ] [ fendrin        ] [ loonybot   ] [ Vetinari       ] 
20100616 18:18:46[ Bob_The_Mighty ] [ freim          ] [ loonycyborg] [ wesbot         ] 
20100616 18:18:46[ Bocom_         ] [ Gambit         ] [ mjs-de     ] [ yann           ] 
20100616 18:18:46[ chris|         ] [ Greywhind      ] [ nagbot     ] [ zookeeper      ] 
20100616 18:18:46[ CIA-86         ] [ grzywacz       ] [ nguyenatto ] 
20100616 18:18:46[ crimson_penguin] [ Ingmar         ] [ PK         ] 
20100616 18:18:46-!- Irssi: #wesnoth-dev: Total of 50 nicks [0 ops, 0 halfops, 0 voices, 50 normal]
20100616 18:18:56-!- Soliton [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev
20100616 18:19:03-!- Channel #wesnoth-dev created Tue Jan 27 06:28:41 2009
20100616 18:19:12-!- knotwork [~markm@142.177.232.37] has joined #wesnoth-dev
20100616 18:20:00-!- Irssi: Join to #wesnoth-dev was synced in 81 secs
20100616 18:25:23-!- linease [~linease@dslb-092-076-127-224.pools.arcor-ip.net] has quit [Quit: Lost terminal]
20100616 18:41:12< CIA-86> thespaceinvader * r43504 /trunk/ (10 files in 3 dirs): Add and wire new Dwarf Guard melee attack by Cloud, update changelogs.
20100616 18:57:51-!- ABCD [~abcd@gentoo/developer/abcd] has quit [Remote host closed the connection]
20100616 18:59:11-!- ABCD [~abcd@gentoo/developer/abcd] has joined #wesnoth-dev
20100616 19:02:08-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100616 19:02:44-!- Bob_The_Mighty [~chatzilla@cpc4-brig15-0-0-cust904.3-3.cable.virginmedia.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]]
20100616 19:06:56-!- YogiHH [YogiHH@d128188.adsl.hansenet.de] has joined #wesnoth-dev
20100616 19:07:10-!- YogiHH [YogiHH@d128188.adsl.hansenet.de] has quit [Changing host]
20100616 19:07:10-!- YogiHH [YogiHH@wesnoth/developer/yogihh] has joined #wesnoth-dev
20100616 19:12:10-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100616 19:12:48< boucman> hey all
20100616 19:13:00-!- billynux [c8078d05@wesnoth/developer/billynux] has joined #wesnoth-dev
20100616 19:42:13-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Ping timeout: 260 seconds]
20100616 19:50:00< boucman> AI0867: ping
20100616 19:56:27< CIA-86> alink * r43505 /trunk/src/ai/formula/ (callable_objects.hpp function_table.cpp): Comment off several full copies of the whole unit_map into an unused member
20100616 19:56:29< CIA-86> alink * r43506 /trunk/src/ai/testing/ca.cpp: Use reference to fix a useless full copy of the main unit_map.
20100616 20:04:44< alink> wesbot: log r43453
20100616 20:04:45< wesbot> alink * r43453 : Use top_srcdir instead of .. for ../data/tools copy.Seems needed to use make in another directory.
20100616 20:04:48< wesbot> URL: http://svn.gna.org/viewcvs/wesnoth?view=rev&rev=43453
20100616 20:05:31< alink> ^it seems that this change fixed something not working before, but is it really wanted?
20100616 20:05:57< alink> (copying wmlscope and the likes out of data/core)
20100616 20:06:16< alink> what does scons/CMake do btw?
20100616 20:10:29-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100616 20:12:19< loonycyborg> alink: Nothing relevant to that change
20100616 20:12:56< alink> I mean, does it also move/cp wml tools ?
20100616 20:14:00< alink> because i don't see the point, and I must now ignore them for git/svn
20100616 20:15:02< alink> so, if this copy never worked, maybe I should kill it instead of fix it
20100616 20:15:02< loonycyborg> Only as part of install..
20100616 20:15:36< alink> ah ok install does it but not simple build
20100616 20:16:05< alink> I should check how it changes things for make install
20100616 20:16:13< ABCD> alink: what it (apparently) fixed was out-of-source builds -- which are always nice to have working
20100616 20:17:01< alink> ABCD yeah that was my goal :)
20100616 20:21:15-!- YogiHH [YogiHH@wesnoth/developer/yogihh] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]]
20100616 20:21:31< CIA-86> alink * r43507 /branches/1.8/ (changelog src/mouse_events.cpp): 
20100616 20:21:31< CIA-86> Fixed crash if a sighted event killed a unit just before a fight.
20100616 20:21:31< CIA-86> Simplified back-port from r43430 and its correction r43435
20100616 20:21:49< boucman> AI0867: still not around ?
20100616 20:23:44-!- PK [~pk@r74-192-30-57.bcstcmta01.clsttx.tl.dh.suddenlink.net] has quit [Quit: Java user signed off]
20100616 20:31:04-!- phlaem [~a@e178099052.adsl.alicedsl.de] has joined #wesnoth-dev
20100616 20:38:24-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20100616 20:38:36< mordante> servus
20100616 20:44:27-!- Johannes13 [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100616 20:45:18-!- Johannes13 [~Johannes@unaffiliated/johannes13] has quit [Read error: Connection reset by peer]
20100616 20:45:24-!- Johannes13 [~Johannes@unaffiliated/johannes13] has joined #wesnoth-dev
20100616 20:45:56< CIA-86> boucman * r43508 /trunk/src/unit.cpp: prevent ghosted units from having idle animations
20100616 20:46:08< boucman> mordante: I discovered something weird wrt the SDL/ubuntu bug...
20100616 20:46:25< mordante> boucman, that is?
20100616 20:46:34< boucman> when i'm in the editor and i click on one of the "terrain category" button, the clicks always works...
20100616 20:46:35< billynux> hi mordante 
20100616 20:46:45< mordante> hi billynux 
20100616 20:46:50< boucman> whereas when I click on a terrain in that same editor, it never works...
20100616 20:47:15< boucman> so there is something in the way these two types of widget are handled that is a workaround for the bug
20100616 20:47:29< mordante> boucman, when you look in the code I expect you find the former acts on the mouse down the latter on the mouse up
20100616 20:47:37< boucman> oh
20100616 20:47:38< boucman> ok
20100616 20:47:49< boucman> so no discovery :(
20100616 20:47:57< mordante> the same for the enveloppe in the main menu
20100616 20:48:17< mordante> but IIRC Rhonda mentioned the fixed SDL is getting into the next Ubuntu
20100616 20:48:24< boucman> k
20100616 20:48:46< boucman> four more month to go :P
20100616 20:48:55< mordante> but thanks for the info 
20100616 20:49:17< mordante> the Ubuntu team is fast ;-P
20100616 20:49:43< boucman> well, it seems to work today, so maybe it has been backported
20100616 20:49:52< billynux> mordante: gotta go... any comments for me?
20100616 20:49:57< boucman> or it's the usual eisenbug problem
20100616 20:50:13< mordante> might be I don't follow Ubuntu too closely
20100616 20:50:34< mordante> billynux, no haven't caught up with the logs yet, will you be around tomorrow
20100616 20:50:35< mordante> ?
20100616 20:50:49< billynux> yes, all day
20100616 20:50:51< mordante> boucman, no the problem seems rather consistent
20100616 20:51:04< mordante> ok then I'll see you tomorrow
20100616 20:52:44-!- billynux [c8078d05@wesnoth/developer/billynux] has quit [Quit: Page closed]
20100616 20:56:21< mordante> Upthorn, regarding your static const float in class definition question, try asking silene when he's around
20100616 20:58:20< Upthorn> mordante: are you saying that silene might know the reason it's disallowed in the spec?
20100616 20:58:37< mordante> Upthorn, yes
20100616 20:58:52< Upthorn> Oh. Huh.
20100616 21:02:40< Upthorn> I assumed you had misunderstood and thought I had a programming question about how to work around it, but you are correct that I'm very curious about why that's how it works.
20100616 21:14:17< Rhonda> mordante: It is already in lucid-proposed.
20100616 21:14:45< mordante> Rhonda, that means in the current version?
20100616 21:15:12< Rhonda> erm, lucid-updates
20100616 21:15:26< Rhonda> boucman: Enable lucid-updates and upgrade your libsdl
20100616 21:15:43< boucman> Rhonda: i'll check, but I probably already did
20100616 21:15:45< Rhonda> lucid is 10.04, yes.
20100616 21:16:01-!- gabba [~gabba@wesnoth/developer/gabba] has joined #wesnoth-dev
20100616 21:16:07< gabba> bonjour
20100616 21:16:44< boucman> Rhonda: I have lucid-proposed, not lucid-update, but the bug was magically solved today, so my guess is that it's already there
20100616 21:16:49< boucman> gabba: salut
20100616 21:17:02< gabba> salut boucman
20100616 21:17:07< boucman> gabba: I have read all your sources and tested whiteboard a little
20100616 21:17:21< gabba> good, any comments?
20100616 21:17:22< boucman> I have all sorts of questions and remarks :D
20100616 21:17:27< gabba> he he
20100616 21:17:29< boucman> nothing serious, though
20100616 21:17:47< gabba> At least it doesn't crash as often now :P
20100616 21:17:52< boucman> first is a small remakr about arrows.cpp
20100616 21:18:11< boucman> you have hardwired footsteps/teleport-* independently of styles
20100616 21:18:18< Rhonda> boucman: If packages.ubuntu.com would work for those suits already (granted, we are only two months after the release, why should it) I would hand you a link to there
20100616 21:18:36< mordante> Rhonda, ah great so we might have hear the last of that bug (famous last words...)
20100616 21:18:38< boucman> it would be better to have a special named image (like the others) even if it means having two copies of the file lying around...
20100616 21:19:40< gabba> boucman: agreed, I should copy it/them under the arrows directory and rename them
20100616 21:20:00< boucman> gabba: just write this as a TODO, no emergency
20100616 21:20:27< boucman> I have some questions about arrow::clear_path
20100616 21:21:02< boucman> is there a reason why it's not directly calling arrow->set_path(empty) ?
20100616 21:21:13< gabba> let me see
20100616 21:22:50< gabba> boucman: the function would be better called "reset()" actually
20100616 21:23:06< boucman> ok
20100616 21:24:05< gabba> also I preferred symbols_map_.clear() to calling the huge update_symbols() to obtain the same result
20100616 21:24:34< boucman> mkay
20100616 21:25:04< boucman> I have still trouble understanding the arrow drawing logic in there (how are things invalidated, who keeps tracks of what) but if you are confident, then that's fine
20100616 21:25:38< Rhonda> wesbot: seen silene
20100616 21:25:38< wesbot> Rhonda: The person with the nick silene last spoke 3d 6h ago.  2d 12h ago they left with the message: Quit: Leaving.
20100616 21:25:49< boucman> moving to action.hpp
20100616 21:25:49< Rhonda> damn :)
20100616 21:26:38< gabba> to summarize, you set the path, then calculate which symbols go where and place them in the symbols_map_, and then notify the display that the arrow changed, at which point the display copies the symbols in its own, global map
20100616 21:26:56< boucman> the function move::apply_temp_midifier, shoudln't it be moved to the action class ? afaict all actions will have to have it
20100616 21:27:02< boucman> gabba: ok, makes sense
20100616 21:27:50< gabba> yes, good point for that function
20100616 21:29:06< boucman> maybe also a function to test if it's in soft/hard conflict
20100616 21:30:04< gabba> which I'm gonna add once I get to those conflicts... today would be a good time since move execution got in yesterday
20100616 21:30:36< boucman> gabba: ok, good
20100616 21:30:40< Upthorn> oh hey, I've been wanting to ask, is there anything special I need to do to try out the whiteboard, or should I just play normally and see different functionality?
20100616 21:30:43< boucman> moving to move
20100616 21:30:59< boucman> Upthorn: in debug mode type :whiteboard
20100616 21:31:08< gabba> or just :wb ;)
20100616 21:31:09< Upthorn> debug mode?
20100616 21:31:10< boucman> to execute a move, you need to "order twice"
20100616 21:31:15< boucman> :debug
20100616 21:31:20< boucman> only in SP
20100616 21:31:28< Upthorn> ok.
20100616 21:31:38< gabba> Upthorn: or start wesnoth with --debug (and I recommend --test as well)
20100616 21:31:57< Upthorn> does tutorial count as SP?
20100616 21:32:13< Upthorn> I've been testing all my stuff there
20100616 21:32:38< boucman> in move.cpp, you have a local "get_current_team" which is used only  once, you might want to fold it or add it to the controller class (no emergency, i'm just moving through my list of remarks)
20100616 21:32:41< gabba> it should
20100616 21:32:47< Espreon> alink: Did you get my message?
20100616 21:34:04< gabba> boucman:  noted
20100616 21:34:55< mordante> I'm off bye
20100616 21:35:08< Espreon> boucman: What about you? Did you get my message?
20100616 21:35:18< boucman> Espreon: nope, 
20100616 21:35:26< Espreon> Hold on...
20100616 21:35:39-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20100616 21:35:54< boucman> gabba: visitor.cpp is more or less empty, you should inline the constructor/destructor and remove the file (unless you expect to have more things in there, but I don't think so
20100616 21:36:12< boucman> if you don't remove the cpp, not that you have a useless include in there
20100616 21:36:30< boucman> (btw, that's true for action.cpp too)
20100616 21:36:56< gabba> Upthorn: you can get into the test (wesnoth -t) scenario faster than in the tutorial, since it skips the main menu. ("wesnoth --help" has other interesting options)
20100616 21:37:35< Espreon> 20100616 01:56:09< Espreon> boucman: Some swamp and swamp village tiles have hex outlines.
20100616 21:38:00< Upthorn> hrm.
20100616 21:38:16< Upthorn> I wish I knew that earlier.
20100616 21:38:19< gabba> boucman: I must have at least one non-abstract method body to allow inheritance, hence visitor.cpp (believe me, I tried to make it hpp-only
20100616 21:38:37< gabba> Upthorn: I said the same thing once I found out about it :P
20100616 21:39:01< boucman> gabba: i didn't know that... ok
20100616 21:39:49< Espreon> Ivanovic: Sorry about that.
20100616 21:39:58< boucman> mapbuilder_visitor::visit_move using find instead of "count" might be slightly faster here
20100616 21:40:10< gabba> Upthorn: there's also in-game help for commands, :help I think after you've done :debug... some great stuff in there
20100616 21:40:56< boucman> mapbuilder_visitor::~mapbuilder_visitor : I assume this is because we can't rely on the stack destructor to destroy in a LIFO order... (I didn't find it explicitely in the specs)
20100616 21:42:17< gabba> mapbuilder_visitor::visit_move: ok, its a set so I should be able to use find indeed
20100616 21:42:32< gabba> for the destructor, I couldn't find any info either
20100616 21:42:56< boucman> ok, makes sense
20100616 21:43:50< Upthorn> okay, the whiteboard is looking good so far, but I am glad that the current interface is temporary
20100616 21:44:20-!- Lastmerlin [~Lastmerli@kalypso.csn.tu-chemnitz.de] has joined #wesnoth-dev
20100616 21:44:33< boucman> gabba: that's it for the code side, i'll be afk 10' and the we'll discuss the UI itself
20100616 21:44:48< gabba> Upthorn: yeah, it's really early stuff, use at your own risk, might crash your computer and eat your dog, etc
20100616 21:44:57-!- knotwork [~markm@142.177.232.37] has quit [Remote host closed the connection]
20100616 21:45:00< gabba> boucman: ok
20100616 21:48:46< CIA-86> espreon * r43509 /trunk/data/core/images/units/dwarves/ (14 files): Ran umcpropfix.
20100616 21:49:01< Lastmerlin> question: for my game, several art/content creators ask for some space to share their work with other contributors.
20100616 21:49:08< Lastmerlin> they proposed some special folder in svn
20100616 21:49:24< Lastmerlin> I hesitate to do this, because versioning wont work well for big binary files
20100616 21:49:54< Lastmerlin> and as each version is saved in svn, it will increase the svn repo quickly
20100616 21:50:01< Lastmerlin> how does wesnoth handle this ?
20100616 21:51:52< grzywacz> Do they really need versioning?
20100616 21:52:01< Lastmerlin> no i dont think so
20100616 21:52:12< grzywacz> Lastmerlin, I think in wesnoth the "share with contributors" role is played by forums
20100616 21:52:12< Lastmerlin> only easy sharing
20100616 21:52:25< Lastmerlin> hmm thats what we do too atm
20100616 21:52:40< Lastmerlin> and they complain about it
20100616 21:54:21< boucman> back
20100616 21:54:46< boucman> Espreon: not sure what you mean... they don't have transitions
20100616 21:54:49< boucman> ?
20100616 21:55:05< Espreon> I don't recall seeing this before...
20100616 21:56:00< boucman> hmm I can't reproduce
20100616 21:56:26< boucman> gabba: so, gameplay aspects...
20100616 21:56:32< gabba> yes
20100616 21:57:08< boucman> 1) clicking on a ghost seems to "pseudo select" it, without using the select animation nor updating the selected unit on the right...
20100616 21:57:19< Espreon> boucman: Look at the Cave of the Basilisk (or whatever it is called).
20100616 21:57:32-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has joined #wesnoth-dev
20100616 21:57:32-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has quit [Changing host]
20100616 21:57:32-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100616 21:57:53< gabba> pseudo-select is kind of weird... I thought maybe it was the hex highlighting
20100616 21:58:29< boucman> gabba: yes, that's it, nothing to worry about, then
20100616 21:59:08< boucman> we might want to be able to pseudo select ghosts at some point, though...
20100616 21:59:18< boucman> in particular for unit swapping
20100616 21:59:46< gabba> boucman: it could be interesting, maybe to drag them around. Swapping you say?
20100616 22:00:29< boucman> when you want to exchange two units position, usually in a crowded front, you move the first away, move the second at the first's position then move the first in the second's position
20100616 22:01:22< boucman> Espreon: ok, I see what you mean, that's probably du to eleazar's work in progress on recoloring
20100616 22:01:31< gabba> yeah I see
20100616 22:01:31< boucman> that's not one of my recent changes, that's for sure
20100616 22:01:50-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100616 22:03:33< boucman> gabba appart for that not much to say, it's true that i tend to click on the ghost to try and move it "again", 
20100616 22:03:39< boucman> what's your next step ?
20100616 22:03:43-!- knotwork [~markm@142.177.232.37] has joined #wesnoth-dev
20100616 22:04:16< gabba> boucman: action validation, I can't really progress on proper move execution without it
20100616 22:04:52< boucman> k, 
20100616 22:07:35< gabba> visually there are various things to solve: highlight the ghost together with the path, don't draw a ghost over another unit
20100616 22:08:07< gabba> boucman: also, please take a look at the idle animation kicking in and removing the ghosted one
20100616 22:08:54< boucman> gabba: solved, I comitted about an hour before you joined
20100616 22:09:04< gabba> ah, thanks
20100616 22:10:05< boucman> how can you draw a ghost over another unit ? it seems handled properly...
20100616 22:10:34< boucman> gabba: ok, I just crashed the game while trying
20100616 22:10:37< boucman> lemme reproduce
20100616 22:10:49< boucman> wesnoth-debug: src/unit_abilities.cpp:129: bool unit::get_ability_bool(const std::string&, const map_location&) const: Assertion `units_' failed.
20100616 22:11:27< gabba> If you make a "merry-go-round" it crashes, i.e. a circle where all units make one step clockwise for example
20100616 22:11:31< boucman> here is the method
20100616 22:11:47< boucman> 1) move_action unit A
20100616 22:11:56< boucman> 2) move_action unit B where unit 1 was
20100616 22:12:02< boucman> 3)select unit A
20100616 22:12:14< boucman> move cursor out of unit A's starting hex
20100616 22:12:17< boucman> crash
20100616 22:12:47< gabba> really, that crashes too? darn
20100616 22:13:16< Espreon> boucman: Hmmmm... I see...
20100616 22:13:25< gabba> it's the temporary map modifiers moving the unit in places the game engine doesn't expect them, I think
20100616 22:13:29< alink> fyi i plan to remove units_ from unit, which will solve this bug
20100616 22:14:17< boucman> alink: sounds good, when do you intend to do it ? (for our own planning)
20100616 22:14:22< alink> but checking ability of fake_unit shouldn't happen
20100616 22:14:48< boucman> alink: we need it for pathfinding, I guess
20100616 22:14:57< alink> boucman: it's already done here, but I needed to check something, don't remember what
20100616 22:15:08< boucman> k
20100616 22:15:23< CIA-86> espreon * r43510 /trunk/data/core/images/units/dwarves/ (15 files): 
20100616 22:15:23< CIA-86> Ran wesnoth-optipng:
20100616 22:15:23< CIA-86> Overall statistics (only for files with a smaller recompressed size):
20100616 22:15:23< CIA-86> Original size: 31 KiB on 15 files
20100616 22:15:23< CIA-86> Optimized size: 18 KiB
20100616 22:15:26< gabba> so... what's the bug exactly and what causes it?
20100616 22:15:30-!- Ken_Oh [~briang@static-71-178-174-220.washdc.fios.verizon.net] has quit [Read error: Connection reset by peer]
20100616 22:15:54< Espreon> alink: You did recieve my message, jeß?
20100616 22:15:57< alink> you are not supposed to do pathfinding with fake units, I think
20100616 22:16:15< alink> Espreon: yeah, but didn't checked the code yet
20100616 22:16:27< Espreon> Ah, I see.
20100616 22:16:39< boucman> gabba: it would be so much better if we were able to leave the ghost behind :(
20100616 22:16:48< gabba> hmm, I'm not aware of doing pathfinding with fake units, though...
20100616 22:17:06< gabba> boucman: what do you mean?
20100616 22:17:50< alink> gabba: each unit has a pointer to the main unit_map (that's why I recommended not using several unit_map), but it's NULL for fake unit (not in the main unit_map)
20100616 22:19:11-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 260 seconds]
20100616 22:19:21< boucman> gabba: I mean the idea we discussed and both liked but brought other problems, moving the unit, and setting a fake unit at the original location...
20100616 22:19:34< gabba> boucman: ah, yes
20100616 22:22:51< gabba> boucman: well, if you genuinely think it would make the interface better, I'll think about it again. But I discovered more bothersome stuff about it, such as: move unit A, move unit B where unit A was: 1- it hides the ghost (bad?) 2- now try canceling A's planned move....
20100616 22:23:42< boucman> 1 is actually good I think, since the ghost of A is less important then B's future position
20100616 22:23:59< boucman> we are more interested in the described situation than the original position if you see what I mean
20100616 22:24:53< boucman> 2 is more of an issue, but whatever we do we will always have multiple "clickable units" on hexes, so either popup a menu to select (clunky) or select the top unit of the stack (cluncky too)
20100616 22:26:05< gabba> well, let's stick to the reality at hand...
20100616 22:27:28-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100616 22:27:47-!- drusepth [~drusepth@dhcp-077-249-151-209.chello.nl] has quit [Ping timeout: 258 seconds]
20100616 22:27:56< gabba> boucman: unless you have more comments I'm gonna go debug the crashed you notice. I don't think it has anything to do with fake units, I just use them as visual fluff
20100616 22:28:11< boucman> nope, that's it atm
20100616 22:28:43< gabba> ok, thanks for the code review
20100616 22:31:30-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has joined #wesnoth-dev
20100616 22:31:30-!- stikonas [~and@ctv-79-132-162-160.vinita.lt] has quit [Changing host]
20100616 22:31:30-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100616 22:31:32-!- zookeeper [~l@wesnoth/developer/zookeeper] has quit []
20100616 22:33:12< alink> gabba: the ability causing the crash is "hides". so maybe it's just a visibility thing
20100616 22:35:51< gabba> alink, boucman: what happens is, when I temporary move units to their destination, I don't move the selected unit. I did that because... err... there was a good reason at the moment. So one unit is moved where your selected unit is, and swaps the selected unit out, with the crash as a result once something tries to access it
20100616 22:37:14< CIA-86> upthorn * r43511 /trunk/src/terrain_filter.cpp: One line fix for compilation that I somehow forgot to commit until now.
20100616 22:38:49< alink> gabba: note that my units_ change really seems to fix it. I can commit it now if you want
20100616 22:38:53< gabba> alink, boucman: now I remember, the reason for leaving the selected unit where it is was that when you tried to change paths for a unit that already had one, it got moved at its destination, and so the new path started where the ghost was. So I end up with two conflicting systems to reconcile.
20100616 22:39:11< gabba> alink: ok, lemme try that
20100616 22:40:12< boucman> ok, the explanation makes sense...
20100616 22:42:07< CIA-86> alink * r43512 /trunk/src/ (unit.cpp unit.hpp unit_abilities.cpp): 
20100616 22:42:07< CIA-86> Remove units_ from unit class, and always use resources::units instead.
20100616 22:42:07< CIA-86> (some polishing are still needed)
20100616 22:43:04< alink> gabba: AFAIK the only thing making units_ = NULL was unit_map::extract, which is called by unit_map::erase and unit_map::move
20100616 22:43:40< gabba> alink: it's called by temporary_unit_mover
20100616 22:43:44< alink> and, I was wrong, these days fake units used units_=resources::unit_map not NULL
20100616 22:45:59< alink> mmmh but unit_map::move only use unit_=NULL for a very short time and internally 
20100616 22:46:08< alink> anyway units_ is gone now
20100616 22:46:38< gabba> compiling, if it stops the crash I'm happy :)
20100616 22:47:08< alink> it sopped the crash that i had, here
20100616 22:47:20< gabba> the swapped-out (and therefore temporarily fake) unit was attempting pathfinding I guess, that's what must have happened
20100616 22:47:52< boucman> gabba: the more I think the more i'm convinced we are doing it backward... UI wise, the dest of the move is more important than the source, and it will be the only way to keep things in check when we will have all sorts of moves sharing source/destination
20100616 22:49:21< alink> btw, it's for later (because bug prone) but it could be cool to drag&drop ghosts to modify destination
20100616 22:49:37< boucman> alink: much later :P
20100616 22:49:58< alink> yeah, yeah, drag&drop is a hell to debug
20100616 22:50:02< boucman> gabba: just updated, trying to reproduce
20100616 22:50:57< boucman> gabba: it's fixed
20100616 22:51:16< gabba> alink: yup, crash solved. You were here right on time, I would've spent a lot of time trying to do things another way.
20100616 22:51:34< alink> note that because of how i implemented drag&drop, you can already use it with whiteboard :-)
20100616 22:51:52< alink> gabba: good, but that was pure luck that I worked on units_ at this moment
20100616 22:52:16 * boucman tests right away
20100616 22:53:06< boucman> indeed
20100616 22:53:21< gabba> drag and drop interests me a lot, of course
20100616 22:54:11< gabba> ah, so now you *can* make a merry-go-round :P
20100616 22:54:27< alink> gabba: but currently it's just calls left_click twice when pressing /releasing the mouse . Plus few details about cursors etc..
20100616 22:54:50< gabba> problem is, without numbering, try to remember which one you defined first, heh
20100616 22:55:17< boucman> gabba: use drawing layers for that, so you see which one is on top...
20100616 22:56:03< alink> alternatively: drawing order
20100616 22:56:34< alink> (drawing on the same layer uses draw order)
20100616 22:57:13-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Remote host closed the connection]
20100616 22:57:34< boucman> gabba, alink: whatever we do, we will need to intercept the "click on ghost" logical event at some point...
20100616 22:58:03< gabba> boucman: layers are no use in this case :P http://imagebin.org/101563
20100616 22:58:40< boucman> hehe
20100616 22:58:50< boucman> in that case, all ghosts should be on top, I guess
20100616 22:58:57-!- Lastmerlin [~Lastmerli@kalypso.csn.tu-chemnitz.de] has left #wesnoth-dev ["Kopete 0.12.7 : http://kopete.kde.org"]
20100616 22:59:04< alink> oh ghost units have ghost halo too :-o
20100616 22:59:58< gabba> yeah :P also if you look at the elvish druid, it looks like she's clinging to the wolf rider ghost, heh
20100616 23:00:28-!- stikonas_ [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100616 23:00:56< gabba> that's with zoom btw
20100616 23:01:16< alink> btw about mouse event on ghost, also need to update sidebar at some point
20100616 23:01:20< gabba> boucman: I'm not sure ghosts should be on top
20100616 23:02:07< boucman> gabba: when we plan a move, we are more interested on the resulting situation than on the original situation
20100616 23:02:37< gabba> boucman: actually I was gonna not have ghosts when units are superposed like that, I find it messy
20100616 23:02:45< boucman> esp when there will be lots of planned moves... thus arrows should be unobtrusive (probably highly transparent) and source position should be barely visible (set_ghosted) 
20100616 23:02:58< kevg> boucman: hi. Maybe you know, move_map srcdst variables in ai code contains one key(current position) and several keys(possible positions to move)?
20100616 23:02:58< boucman> this is independant of which one is the fake, it''s a pure UI consideration
20100616 23:03:32< boucman> kevg: IIRC yes, that's it... Crab_ would know, of course
20100616 23:04:02< Crab_> kevg: it's a multimap, for each source location, all possible pairs <source, destination > are there.
20100616 23:04:14< Crab_> kevg: you can use formula ai to see it
20100616 23:04:25< kevg> Crab_: for each unit or for one?
20100616 23:04:36-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 276 seconds]
20100616 23:04:38< Crab_> for all units
20100616 23:05:16< kevg> Crab_: and why we need dstsrc?
20100616 23:05:41< Crab_> to see 'what our units can move to location Z' , fast.
20100616 23:06:09< gabba> boucman: source position barely visible is not so good, again for "select" event menus (yes, I know you love those)
20100616 23:06:24< Crab_> kevg: formula ai function 'my_moves' can show you all the possible moves
20100616 23:06:29< boucman> :(
20100616 23:06:30< gabba> unless we disable "select" when a unit has a planned move?
20100616 23:06:38< Crab_> kevg: try it, be sure to do it when there's only a few units on the map
20100616 23:06:41-!- Lastmerlin [~Lastmerli@kalypso.csn.tu-chemnitz.de] has joined #wesnoth-dev
20100616 23:07:02< kevg> Crab_: thanks
20100616 23:07:10< boucman> that would make sense, they can't be planned, only done at execute time
20100616 23:07:30< boucman> at least as a first go, until we have played enough with WB to see how usable it is
20100616 23:08:10< gabba> I'd have to test with a scenario with custom menus to measure the implications
20100616 23:08:37< boucman> isn't there a special menu to create unit in test scenario
20100616 23:09:27< alink> note that we may change the drawing order only when the mouse is on the hex. For example, show ghost on top, unless you move the mouse there, which will then show the real (source) unit
20100616 23:09:43< alink> on top
20100616 23:10:02< gabba> boucman: ah yes, there's calculate unit worth and other stuff
20100616 23:10:38< gabba> alink: that's a pretty good idea, not sure if it's easy
20100616 23:11:36-!- Bocom_ [~Bocom@c-b7cfe255.013-31-6b736412.cust.bredbandsbolaget.se] has quit [Ping timeout: 241 seconds]
20100616 23:12:02< alink> there is already various mousehover effect: slight highlight, show reachable area(for enemy), sidebar update 
20100616 23:12:54< alink> the sidebar could also use some convention like always show real unit when both are under the mouse
20100616 23:13:23-!- Blueblaze [~nick@adsl-99-182-54-45.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100616 23:13:44< alink> there is already such rules regarding selected unit and mousehover unit
20100616 23:14:18-!- Bocom [~Bocom@c-b7cfe255.013-31-6b736412.cust.bredbandsbolaget.se] has joined #wesnoth-dev
20100616 23:14:29< gabba> I wonder how we'll handle cycle units: cycle to real position I guess?
20100616 23:15:27< alink> seems to make sense
20100616 23:15:50-!- billynux [~billy@wesnoth/developer/billynux] has joined #wesnoth-dev
20100616 23:16:18< alink> I need to go, bbl
20100616 23:16:31< gabba> bye alink
20100616 23:17:30< boucman> gabba: let's use "src" and "dst" rather than ghost and real, so we understand ourselves better
20100616 23:17:39< gabba> sure
20100616 23:17:46< boucman> we have a philosophical difference in our UI conception, 
20100616 23:18:38< boucman> you think in terms of "planning ahead" I think in term of "doing a move, analyzing what it looks back, changing the move i did, eventually validate all my moves"
20100616 23:19:25< boucman> from a purely visual point of view (no menu/click) this makes a huge difference, because you show the current situation with some markers for a future possible position
20100616 23:19:39< boucman> I draw the future position with some reminders of where we are coming from
20100616 23:19:52< gabba> "doing a move, analyzing what it looks back, changing the move i did, eventually validate all my moves" is my goal as well
20100616 23:20:51< boucman> yes, my description might not be the best, but i'm trying to explain our difference in UI philosophy, not in term of capabilities, if you get what i'm saying
20100616 23:21:47< gabba> I understand you want to put the emphasis on the result situation, but it has a lot of issues I'm not sure how to solve
20100616 23:22:08< boucman> well, my gut feeling is that it has less issues than the oposite :P
20100616 23:22:14< boucman> but it's a gut feeling...
20100616 23:22:43< boucman> yours makes easier to do what the UI is already able of doing, i.e changing a planned move
20100616 23:23:04< gabba> also, the mockups that gathered pretty wide approval presented my original solution, so if we change concept now, will the support stay the same?
20100616 23:24:05< boucman> mine make it easy to do more than one action on a unit
20100616 23:24:23-!- thespaceinvader [~chatzilla@wesnoth/artist/thespaceinvader] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]]
20100616 23:24:31< boucman> i'm not too much worried about aproval... or rather, i'm pretty worried in both cases equally
20100616 23:24:38< gabba> boucman: it may be a clunky solution, but there was also the idea of having a key to temporarily view the future situation without the clutter of arrows, real vs ghosts units, etc
20100616 23:25:11< boucman> k
20100616 23:25:52< boucman> well, keep the idea in mind when we will have a playable state and some real testers, but let's move on with the ghost problem
20100616 23:26:25-!- stikonas_ [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 265 seconds]
20100616 23:26:26< boucman> the "problem" is that with whiteboard we are representing multiple "points in time" simultaneously
20100616 23:26:48< boucman> so when a user clicks somewhere, what PIT is he pointing to...
20100616 23:27:11< gabba> (^the idea would be to for instance hold spacebar, and while you hold, you get the "future" display. From a technical point of view it's much easier than having a permanent emphasis on dst, since you keep control over the UI and display for that short time)
20100616 23:27:31< boucman> when the hex is only one src or one dst it's easy, but these things can stack (well, not src, but dst can)
20100616 23:27:41< boucman> hmm, interesting idea... 
20100616 23:28:56< boucman> the idea I was going to offer as an alternative was to say is that the ghost is only a ghost, and if you want to add a second action to a unit, you have to act on the src, you never act on a dst (using a modifier, a right click entry or another ui trick to append instead of replace)
20100616 23:29:54< boucman> ok, pushing a bit forward, a proposed UI
20100616 23:30:10< gabba> tbh, I never had the idea of adding a sequence of actions to a unit; one at a time seems enough
20100616 23:30:17-!- Upthorn [~ogmar@adsl-75-26-202-12.dsl.scrm01.sbcglobal.net] has quit [Ping timeout: 265 seconds]
20100616 23:30:20< boucman> to have a unit A move to hex 1 then 2 then 3 the ergonomy would be
20100616 23:30:39< boucman> click A, click 1, click A, click 2, click A, click 3
20100616 23:30:54< boucman> if you want to cancel the moves on A, you double-click on A...
20100616 23:31:15< boucman> you can't partialy remove A's moves, but we get a coherent UI, which is an important thing to have...
20100616 23:32:20< gabba> all that's assuming A stays at its src position?
20100616 23:32:43< gabba> if so I don't like the back-and-forth movement it requires, it could get annoying very fast
20100616 23:33:18< gabba> but maybe we should first discuss whether we need to queue moves for a single unit... I wasn't working in that mindset at all
20100616 23:33:23< boucman> then, click A click1 click2 click2, right-click to stop acting on A
20100616 23:33:58-!- Johannes13 [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 240 seconds]
20100616 23:33:59< boucman> i'm not the game expert like Soliton or noy, but i'm afraid we will...
20100616 23:34:11< boucman> move/recruit/move is also a very common pattern for leaders
20100616 23:34:46< gabba> "you can't partialy remove A's moves": well, double-click could just remove the most recent move of that unit
20100616 23:35:05< boucman> good point
20100616 23:35:15-!- wesbot changed the topic of #wesnoth-dev to: 127 bugs, 283 feature requests, 13 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100616 23:35:22< Crab_> ask alink about ' queue moves for a single unit' - he once coded this feature, but disabled it, afair.
20100616 23:35:33< boucman> the idea i'm trying to keep (and which was opposite to my original idea) is that you should never interact with ghosts
20100616 23:35:51< boucman> Crab_: i'm not sure it was the same thing...
20100616 23:36:36< boucman> the underlying question we have is is it common enough that a unit "acts" more than once per turn for us to have to code it into wb, and i'm afraid the answer is yes
20100616 23:36:43< boucman> leadership is another example
20100616 23:37:25< gabba> the question is more: "does a unit move a lot in quick succession without other units moving in-between"
20100616 23:37:32< boucman> gabba: the good news is that it changes nothing in arrows, and very little in the action code, it's purely UI
20100616 23:38:17< gabba> true, the underlying mechanic seems to support
20100616 23:38:23< gabba> to support it
20100616 23:38:24< boucman> gabba: it can happen too, leaders recruiting, fog exploration (tthough i'm not sure this can be really planned, since the decision of moving again depends on what the fog revealed
20100616 23:38:56< boucman> gabba: there might be a place where you wouldhave to change a find_first into a find_all, (from memory) but the changes should be minimal
20100616 23:39:06< gabba> yes, the secondary question is "do we want planning for this kind of situation"
20100616 23:40:00< boucman> I am not sure, but here my guess is that we should plan a UI that allows it...
20100616 23:40:57< boucman> gabba: note that in the modified unit_map, you can see if a unit can still move and avoid the user having to unselect the unit if the unit has no MP left and no possible fight
20100616 23:41:36< gabba> Assuming we do, a reasonable UI would be: if you select a unit with defined moves, each left-click appends a new move; double-click on the unit clears most recent move of that unit; and the ghost can be draggable so you can easily change intermediate waypoints
20100616 23:41:39< boucman> gabba: ok, I have to leave for today, I'll try to pop in briefly tomorow, but no promisses
20100616 23:41:41< gabba> ^hmm true
20100616 23:41:51-!- Crab_ [~Crab_@wesnoth/developer/crab] has quit [Quit: Leaving.]
20100616 23:42:14< boucman> well, if you allow dragging ghosts you have the problem of multile ghosts on the same hex popping
20100616 23:42:16-!- Blueblaze [~nick@adsl-99-182-54-45.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 252 seconds]
20100616 23:42:45< boucman> i'd drop ghost dragging in the first playable prototype, 
20100616 23:43:17< gabba> makes sense. but note that right now, multiple ghosts on the same hex are impossible
20100616 23:43:23< boucman> I wouldn't even bet that removing the last move vs removing all moves on double click is the best way to do it... that's the sort of stuff only a hardened player could tell, and only after trying it
20100616 23:43:41< boucman> true, but they will be at some point
20100616 23:44:11< gabba> that's a UI choice we can choose not to make
20100616 23:44:27< boucman> ok, I really ahve to go now, see you tomorow
20100616 23:44:41< gabba> see you, I'm gonna think about all that
20100616 23:46:14< boucman> yes, it definitely needs some deep thinking, it would be nice if you could synthetize the "mouse UI" in a mail, either to me or the ML, but if you do post to the ML add a huge lot of warnings about it being work in progress and us trying to get a minimal working UI for early testing, or else we might have a UI flamewar at a point where we are too floating on our ideas for that to be productive in any way
20100616 23:46:24< boucman> night
20100616 23:46:30-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100616 23:51:35-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100616 23:51:44< boucman> gabba: I think I know
20100616 23:52:05-!- _jbx_ [~jbailey@12.190.80.225] has quit [Quit: Dig that hole, forget the sun.]
20100616 23:52:08< gabba> boucman: a flash of light :D ?
20100616 23:52:08< boucman> keep your current UI, except that holding shift will add a second action instead of replacing
20100616 23:52:42< boucman> that the usual meaning of shift-click in all mouse based programs, it's so obvious I don't know how I could have missed it :P
20100616 23:53:05< gabba> classic, it's a good idea (but keep in mind I'd like a key to plan when not in full planning mode, and shift was a good candidate)
20100616 23:53:39< gabba> aaaaalso, someone asked if wesnoth was still gonna be playable only with the mouse... hmmm
20100616 23:54:33< boucman> gabba: i'd tend to disagree on that, a key to "toggle" but shift is a key you need to hold, and I can't imagine someone holding shift during the whole planning, esp since you use planning when it's complicated
20100616 23:54:45< boucman> gabba: aargh, yeah, that too :(
20100616 23:54:56< boucman> well these people might have a limited planning at first
20100616 23:55:01< boucman> ok, back to bed nos :P
20100616 23:55:04< boucman> now
20100616 23:55:16-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Client Quit]
20100616 23:55:18< gabba> 'night :)
--- Log closed Thu Jun 17 00:00:35 2010