--- Log opened Tue Dec 22 00:00:11 2009
20091222 00:01:17< Sapient> anyone else here tried Alien Assault?
20091222 00:01:43< CIA-28> espreon * r40323 /trunk/data/campaigns/Heir_To_The_Throne/images/portraits/chantal-shyde.png: Added Chantal's missing portrait.
20091222 00:03:01< Sapient> I think people who complain about RNG in wesnoth should give that one a try
20091222 00:06:03-!- shikadibot [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has quit ["manual override"]
20091222 00:07:15< Ivanovic> stikonas: bugs.wesnoth.org
20091222 00:07:34< Espreon> Oh joy, the temporary diappearence happens outside of Windows.
20091222 00:07:37< Ivanovic> stikonas: no idea who is responsible for this one and why the *translateable* team name is not used
20091222 00:15:04-!- shikadibot [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20091222 00:15:40< CIA-28> ivanovic * r40324 /trunk/po/ (5 files in 5 dirs): updated Latvian translation
20091222 00:19:56< shadowmaster> I'm checking it
20091222 00:20:17-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20091222 00:20:27< shadowmaster> not good
20091222 00:20:56< shadowmaster> I own a broken trunk build :/
20091222 00:21:16-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 72 bugs, 247 feature requests, 9 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20091222 00:21:35< loonycyborg> shadowmaster: How broken?
20091222 00:22:05< shadowmaster> as in, clicking campaigns menu gives:
20091222 00:22:05< shadowmaster> wesnoth: src/gui/widgets/window.cpp:662: void gui2::twindow::draw(): Assertion `dirty_list_.empty()' failed.
20091222 00:22:09< shadowmaster> Aborted
20091222 00:22:12< shadowmaster> mordante: ^
20091222 00:22:31< shadowmaster> anyone else can reproduce?
20091222 00:22:35< loonycyborg> shadowmaster: That already should be fixed.
20091222 00:22:48< loonycyborg> I was getting that yesterday.
20091222 00:23:27< shadowmaster> okay, with these problems I forgot to rebase wesnoth
20091222 00:24:25< shadowmaster> I really, really want to throw the table through the window now :|
20091222 00:25:49< loonycyborg> With sql you can drop a table. I hope it's close enough :P
20091222 00:26:36< loonycyborg> Just run sqlite3 and drop some tables :P
20091222 00:26:58< shadowmaster> ha-ha. not funny.
20091222 00:32:48-!- shadowmaster_ [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20091222 00:32:57-!- shadowmaster_ is now known as shadowm_laptop
20091222 00:32:59-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091222 00:35:09-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit [Client Quit]
20091222 00:44:31-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"]
20091222 00:45:00-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20091222 01:01:53-!- deekay [n=dk@wesnoth/developer/dragonking] has quit []
20091222 01:05:58-!- noy [n=noy@wesnoth/developer/noy] has joined #wesnoth-dev
20091222 01:12:20-!- mjs-de [n=mjs-de@wh.uni-dortmund.de] has quit [Read error: 113 (No route to host)]
20091222 01:23:20-!- noy [n=noy@wesnoth/developer/noy] has quit []
20091222 01:23:29-!- esr [n=chatzill@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20091222 01:43:04-!- Ken_Oh [n=dick@c-68-48-6-159.hsd1.md.comcast.net] has joined #wesnoth-dev
20091222 01:57:04-!- Crab_ [n=Crab_@wesnoth/developer/crab] has left #wesnoth-dev []
20091222 02:05:15-!- Sapient [n=patrickp@wesnoth/developer/sapient] has left #wesnoth-dev []
20091222 02:13:21-!- Chusslove [n=Chusslov@brsg-d9bee886.pool.mediaWays.net] has quit [Read error: 110 (Connection timed out)]
20091222 02:16:25-!- Aethaeryn is now known as MikeJB
20091222 02:18:40-!- ardesh [n=ardesh@port-92-195-16-107.dynamic.qsc.de] has quit [Read error: 110 (Connection timed out)]
20091222 02:19:04-!- ardesh [n=ardesh@port-92-195-45-108.dynamic.qsc.de] has joined #wesnoth-dev
20091222 02:20:01-!- Chusslove [n=Chusslov@brsg-d9befe6f.pool.mediaWays.net] has joined #wesnoth-dev
20091222 02:35:09-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20091222 02:44:55-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit [Read error: 60 (Operation timed out)]
20091222 02:46:38-!- Ken_Oh [n=dick@c-68-48-6-159.hsd1.md.comcast.net] has quit ["Leaving."]
20091222 02:59:28-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20091222 03:26:36-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit [Read error: 110 (Connection timed out)]
20091222 03:38:52-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091222 03:40:06-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20091222 04:16:24-!- Velensk [n=benjamin@cpe-24-209-93-196.woh.res.rr.com] has joined #wesnoth-dev
20091222 04:16:34-!- Velensk [n=benjamin@cpe-24-209-93-196.woh.res.rr.com] has quit [Client Quit]
20091222 04:16:41-!- Velensk [n=benjamin@cpe-24-209-93-196.woh.res.rr.com] has joined #wesnoth-dev
20091222 04:17:13-!- Velensk [n=benjamin@cpe-24-209-93-196.woh.res.rr.com] has quit [Client Quit]
20091222 04:17:28-!- Velensk [n=benjamin@cpe-24-209-93-196.woh.res.rr.com] has joined #wesnoth-dev
20091222 04:25:03-!- Velensk [n=benjamin@cpe-24-209-93-196.woh.res.rr.com] has left #wesnoth-dev []
20091222 04:38:10-!- Ivanovic_ [n=ivanovic@dtmd-4db2c74f.pool.mediaWays.net] has joined #wesnoth-dev
20091222 04:44:08-!- SonIcco_ [n=SonIcco@pD951146F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20091222 04:47:29-!- MikeJB [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has quit ["..."]
20091222 04:50:37-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20091222 04:54:43-!- Ivanovic [n=ivanovic@wesnoth/developer/ivanovic] has quit [Read error: 110 (Connection timed out)]
20091222 04:56:08-!- Ivanovic_ is now known as Ivanovic
20091222 04:57:40-!- Paco__ [n=chatzill@c93483c1.virtua.com.br] has joined #wesnoth-dev
20091222 04:57:41-!- Paco__ is now known as fmunoz
20091222 05:01:39-!- SonIcco [n=SonIcco@pD9511743.dip0.t-ipconnect.de] has quit [Read error: 110 (Connection timed out)]
20091222 07:48:01-!- Jetrel [n=Jetrel@wesnoth/artist/jetrel] has quit [Remote closed the connection]
20091222 07:48:28-!- kiba [n=user@adsl-145-152-245.asm.bellsouth.net] has quit [Read error: 110 (Connection timed out)]
20091222 08:05:52-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20091222 08:13:47-!- fmunoz [n=chatzill@c93483c1.virtua.com.br] has quit ["ChatZilla 0.9.86 [Firefox 3.5.6/20091201220228]"]
20091222 08:22:00< CIA-28> zookeeper * r40325 /trunk/data/campaigns/The_Rise_Of_Wesnoth/ (3 files in 3 dirs): Used pixelmind's fire dragon portrait for Shek'kahan.
20091222 08:25:53-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20091222 08:48:48-!- Blueblaze [n=nick@adsl-76-202-22-180.dsl.hstntx.sbcglobal.net] has quit [Read error: 60 (Operation timed out)]
20091222 09:53:29-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has joined #wesnoth-dev
20091222 10:05:54-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20091222 10:11:56-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20091222 10:45:33-!- deekay [n=dk@wesnoth/developer/dragonking] has joined #wesnoth-dev
20091222 10:54:31-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091222 11:03:04< Ivanovic> moin
20091222 11:26:00-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20091222 11:26:49-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20091222 11:38:45-!- stikonas_ [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20091222 11:41:09-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 60 (Operation timed out)]
20091222 11:54:55-!- loonybot [n=loonybot@ppp79-139-139-192.pppoe.spdop.ru] has joined #wesnoth-dev
20091222 11:56:01-!- loonycyborg [n=sergey@ppp79-139-139-192.pppoe.spdop.ru] has joined #wesnoth-dev
20091222 12:07:57-!- alink [n=alink@wesnoth/developer/alink] has joined #wesnoth-dev
20091222 12:10:01-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20091222 12:16:34< ilor> hi, could someone verify that ssh://213.238.120.124:22 is connectable?
20091222 12:19:42< Soliton> works fine here.
20091222 12:20:21< Ivanovic> seems to work nicely here, too
20091222 12:21:06< ilor> thanks
20091222 12:21:27< ilor> normally I'd use my backup "at my friend's" shell to check it
20091222 12:21:35< ilor> but I am there fixing an issue :P
20091222 12:47:52-!- EdB [n=edb@195.12.95-79.rev.gaoland.net] has joined #wesnoth-dev
20091222 13:12:07< CIA-28> alink * r40326 /trunk/src/display.cpp: remove one unneeded include
20091222 13:13:06< CIA-28> alink * r40327 /trunk/src/save_blocker.hpp: remove one unneeded include
20091222 13:18:13< CIA-28> alink * r40328 /trunk/src/ (7 files): store waypoints in usual vector of locations instead of list (was not worth the trouble)
20091222 13:29:34-!- ilor_ [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20091222 13:30:49-!- ilor [n=user@wesnoth/developer/ilor] has quit [Read error: 110 (Connection timed out)]
20091222 13:32:13-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has quit [Remote closed the connection]
20091222 13:33:26-!- fmunoz [n=chatzill@201-0-203-222.dial-up.telesp.net.br] has joined #wesnoth-dev
20091222 13:51:26-!- SonIcco_ [n=SonIcco@pD951146F.dip0.t-ipconnect.de] has quit [Remote closed the connection]
20091222 13:56:12< alink> zookeeper: WML users prefers that a tag is always there, even if often empty, instead of just there only if not empty, right ?
20091222 14:00:55< zookeeper> alink, ummm...no, not really...assuming that i understood right. examples? :P
20091222 14:01:18< alink> like [status] or [variables] in unit info
20091222 14:02:26< zookeeper> you mean whether it's nicer that in a savefile units have empty [variables] rather than not having them if they're empty? 
20091222 14:03:02< alink> yes, because I wish to add a [waypoints] there, but most of the time, it will be empty
20091222 14:04:25< zookeeper> well, frankly i don't think it matters much...doesn't hurt to have them.
20091222 14:04:41< alink> mmh, in fact, i am mostly asking about the general policy, because this tag will not be very useful for WML users
20091222 14:04:58< alink> ok, thanks
20091222 14:05:38< zookeeper> not very useful? i immediately assumed that'd be some kind of a replacement for goto_x= and goto_y=
20091222 14:06:12< alink> yes, that's the plan for 1.9 but i can't kill goto_xy now :-(
20091222 14:06:39< zookeeper> sure, but that sounds like a useful thing regardless :P
20091222 14:08:37< zookeeper> anyways, i don't think there's a general policy. of course you don't want to have to write empty tags in unit/scenario/etc code, but it looks like pretty much every property that a unit can have is already written in savefiles.
20091222 14:08:40< alink> in fact, i didn't planned to save waypoints in 1.8, but since we save goto_xy, reloading currently cause goto to use different paths (because it lost waypoints). No big deal, but i want to fix that
20091222 14:09:55< alink> zookeeper: yeah the c++ code usualy write like that, but i was not sure if it was for c++ coding reasons or WML ones
20091222 14:15:23< alink> btw, glad that my future plan of making waypoints replace goto_x/y look so natural :-)
20091222 14:36:20-!- lukjad007 [n=lukjadOO@unaffiliated/lukjad007] has quit ["Backups are usually a good thing unless it's a sewer."]
20091222 14:39:18-!- lukjad007 [n=lukjadOO@unaffiliated/lukjad007] has joined #wesnoth-dev
20091222 14:43:09-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20091222 14:43:52< silene> hi
20091222 14:45:14< shadowmaster> hi there
20091222 14:47:22-!- lukjad007 [n=lukjadOO@unaffiliated/lukjad007] has quit ["Backups are usually a good thing unless it's a sewer."]
20091222 14:48:09< fendrin> Ivanovic: The deadwater campaign contains an overlay that is used to mark the loyal units. Since deadwater goes mainline, am I allowed to use this overlay in LOW as well? Or can we go further, include it to core and modify the {LOYAL} macro to give the overlay to every loyal unit in the game?
20091222 14:48:30< Ivanovic> fendrin: not sure yet
20091222 14:48:36< Ivanovic> i'd say: don't before 1.8 is out
20091222 14:48:59< shadowmaster> fendrin: uhhh, it's not the best option IMO
20091222 14:49:03-!- lukjad007 [n=lukjadOO@unaffiliated/lukjad007] has joined #wesnoth-dev
20091222 14:49:17< shadowmaster> not that there are any other options.
20091222 14:50:22< shadowmaster> (that makes it the best? :P)
20091222 14:50:50< fendrin> shadowmaster: What is the best option in your opinion?
20091222 14:51:43< Soliton> * Mainline now consistently uses the loyalty overlay from Dead Water.
20091222 14:51:49< shadowmaster> "not that there are any other options"
20091222 14:53:04< CIA-28> silene * r40329 /trunk/src/ (9 files in 3 dirs): 
20091222 14:53:04< CIA-28> Manipulated unit states as booleans for improved performances.
20091222 14:53:04< CIA-28> Flag 'healable' needs some special casing: it is the only state in the game with a reverted semantic (unset when present).
20091222 14:53:08< CIA-28> silene * r40330 /trunk/src/unit.cpp: Removed low-level conversions.
20091222 14:53:12< CIA-28> silene * r40331 /trunk/src/game_events.cpp: Removed low-level conversions.
20091222 14:53:19< CIA-28> silene * r40332 /trunk/src/mapgen_dialog.cpp: Removed low-level conversions.
20091222 14:53:19< fendrin> Soliton: ?
20091222 14:53:21< CIA-28> silene * r40333 /trunk/src/color_range.cpp: Removed useless initialization.
20091222 14:53:27< CIA-28> silene * r40334 /trunk/src/ (multiplayer_ui.cpp team.cpp): Removed low-level conversions.
20091222 14:53:30< CIA-28> silene * r40335 /trunk/src/play_controller.cpp: Removed low-level conversions.
20091222 14:53:43< shadowmaster> fendrin: r40264
20091222 14:54:03 * shadowmaster *grumble*
20091222 14:54:08< fendrin> wesbot: show r40264
20091222 14:54:28< shadowmaster> shikadibot: log r40264
20091222 14:54:29< shikadibot> Revision 40264 (esr, 2009-12-15 17:14:35 +0000 (Tue, 15 Dec 2009)):
20091222 14:54:29< shikadibot> By popular demand, make the loyal-unit generator macros give the units they 
20091222 14:54:33< shikadibot> make the loyalty-crown overlay from Dead Water.
20091222 14:54:35< shikadibot> Web interface URL: http://svn.gna.org/viewcvs/wesnoth?view=rev&rev=40264
20091222 14:54:47< fendrin> Okay, great.
20091222 14:55:53< shadowmaster> I wonder who are "popular demand" sources.
20091222 14:56:06< Soliton> is there a reason why the local trait doesn't just add that overlay?
20091222 14:56:11< Soliton> loyal*
20091222 14:56:55< esr> shadowmaster: I'd hear hear, on channel, that the loyalty-icon feature was veruy popular in the forums.  And adding it was very easy and non-intrusive.
20091222 14:58:09< esr> Soliton: I don't think the {TRAIT_LOYAL} macro would asdd the overlay at the right place.  And I did *not* want to make changes to C++, not this late in the cycle.
20091222 14:58:28< esr> s/hear hear/heard here/
20091222 14:58:58< shadowmaster> there is no effect to apply new overlays, actually.
20091222 14:59:29< Soliton> i see.
20091222 15:00:40< esr> I added the overlay to the loyal-unit macros, then hand-patched the exceptionakl cases in WML.
20091222 15:01:13< Soliton> sounds much more foolproof. :-P
20091222 15:01:47< esr> Well, the exceptional cases could have been a problem.  But grep is my friend. 
20091222 15:02:10< shadowmaster> esr: could you convert it into a separate macro included by those macros?
20091222 15:02:49< shadowmaster> e.g. as in the {IS_HERO} macro. So that I don't need to remember/copy some path since I tend not to use the {*UNIT} macros in general...
20091222 15:02:52< esr> I think I already did, at least halfway.  There's an {IS_LOYAL}.  
20091222 15:03:11< shadowmaster> ah. Fair enough.
20091222 15:03:36< esr> That's what I used for the cases the generator macros don't cover.
20091222 15:03:39-!- lukjad007 [n=lukjadOO@unaffiliated/lukjad007] has quit [Client Quit]
20091222 15:05:18-!- lukjad007 [n=lukjadOO@unaffiliated/lukjad007] has joined #wesnoth-dev
20091222 15:06:06-!- stikonas_ is now known as stikonas
20091222 15:09:40-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20091222 15:11:55< stikonas> Soliton: https://gna.org/bugs/index.php?14984
20091222 15:12:27< stikonas> do you know how can this be fixed?
20091222 15:13:34< stikonas> Ant furthermore, I see no reason at all, why this message box is being shown
20091222 15:14:18< stikonas> in single player campaigns, because player always starts the game, so there is no need to remind him, that it is his turn.
20091222 15:15:33< shadowmaster> stikonas: ugh, I was going to check the issue reported in that bug tracker entry last night
20091222 15:15:34-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 54 (Connection reset by peer)]
20091222 15:15:37< shadowmaster> then I got distra-
20091222 15:15:47-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20091222 15:15:55< shadowmaster> stikonas: ugh, I was going to check the issue reported in that bug tracker entry last night
20091222 15:16:09< shadowmaster> then I got distra- oh look, system upgrades! wee
20091222 15:19:11< Soliton> stikonas: if you don't like that dialog turn it off?
20091222 15:19:16-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20091222 15:19:32< Ivanovic> stikonas: the dialog is the normal "turn dialog"
20091222 15:20:12< Ivanovic> though it is a bug that either the team name is not translateable or that the translated team name is not used
20091222 15:20:32< shadowm_laptop> r/cmode +D 1,1
20091222 15:20:37< shadowm_laptop> er.
20091222 15:23:36< Soliton> in general that name is the name of the player so you can't really translate it.
20091222 15:24:23-!- Blarumyrran [n=Blarumyr@81-20-159-197.levira.ee] has joined #wesnoth-dev
20091222 15:24:36< Soliton> i agree that it probably makes even less sense in singleplayer but i don't use that dialog at all.
20091222 15:25:20< stikonas> I turned it of too...
20091222 15:25:49< shadowmaster> I found that dialog more annoying than useful ;)
20091222 15:26:02 * Ivanovic has it turned on
20091222 16:10:27< silene> stikonas, Ivanovic: i guess it is the same bug that causes the tooltip at the top of the screen to not be translated; and this is not fixable (due to mp)
20091222 16:10:51< Ivanovic> :(
20091222 16:19:07< shadowmaster> :)
20091222 16:20:34< shadowmaster> fendrin: http://forums.wesnoth.org/viewtopic.php?f=4&t=28232
20091222 16:40:40-!- dtiger [n=dtiger@dynamic-vpdn-93-125-15-71.telecom.by] has joined #wesnoth-dev
20091222 16:52:01-!- Ken_Oh [n=briang@static-71-178-174-220.washdc.fios.verizon.net] has joined #wesnoth-dev
20091222 16:59:52-!- ilor_ [n=user@wesnoth/developer/ilor] has quit [Read error: 113 (No route to host)]
20091222 17:02:43< fendrin> shadowmaster: http://forums.wesnoth.org/viewtopic.php?p=399605#p399605 Do you think that answer fits the question?
20091222 17:04:12< shadowmaster> I'd have replied with a "please elaborate. what version, what add-on, read the forum rules, etc." , but that should work too.
20091222 17:06:41-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20091222 17:08:08< shadowmaster> fendrin: never mind, HomerJ read my mind
20091222 17:25:04< CIA-28> silene * r40336 /trunk/src/unit_types.cpp: Removed useless conditional.
20091222 17:25:12< CIA-28> silene * r40337 /trunk/src/unit_types.cpp: Initialized with dummy race earlier.
20091222 17:25:12< CIA-28> silene * r40338 /trunk/src/ (unit_types.cpp unit_types.hpp): Removed useless conditional.
20091222 17:33:17-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit ["restarting system"]
20091222 17:33:27< CIA-28> silene * r40339 /trunk/src/log.cpp: Defaulted to warning level in order to catch some issues before 1.8.
20091222 17:36:08-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20091222 17:43:39-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20091222 17:46:04-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20091222 17:54:10< fendrin> alink: Finaly I managed to understand the current implementation of the A* algo :-)
20091222 17:54:36< alink> fendrin: good, it's true that it's not trivial
20091222 17:56:24< fendrin> alink: You fill in the child nodes for the villages before the algo starts and only use the extra childs if the current is a village. I will have to fill in the teleport childs in every iteration of the main while loop. I fear that will tear down the performance if not done correctly.
20091222 17:59:04 * fendrin can't wait to spoil trank with all the dirty hacks he has waiting on his hard disk.
20091222 17:59:09< alink> mmmh, you can just cache them
20091222 18:00:07< fendrin> I can cache them? Hmmm, how would a cache look like in c++?
20091222 18:00:51< fendrin> My idea was to make heavy use of pointers instead of copying the teleport child list like it is done now.
20091222 18:00:52< alink> i mean just keep them always in the same STL structure and reuse it
20091222 18:01:13 * alink check where we are "copying the teleport "
20091222 18:01:33< fendrin> 		std::copy(teleports->begin(), teleports->end(), locs.begin() + 6);
20091222 18:02:07< fendrin> can't give you the line, I have commented every single line of the algo in order to understand it well.
20091222 18:03:13< alink> ah ok currently this is done only once, not in every iteration of the main while loop
20091222 18:03:18< fendrin> right
20091222 18:03:28< silene> fendrin: pointers would in fact be slower than the current copying (pointers have about the same size than locations, but they incur an additional indirection)
20091222 18:03:35< alink> but indeed you may need to change that if teleport become more complex
20091222 18:03:47-!- Crab_ [n=Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20091222 18:03:58< shadowmaster> "spoil trank"?
20091222 18:04:19< fendrin> shadowmaster: s/trank/trunk
20091222 18:04:36< shadowmaster> you shall not pass :<
20091222 18:04:54< shadowmaster> "dirty hacks" has a very negative connotation here
20091222 18:06:55< alink> fendrin: if you use "static" teleports (which is the first step) then IMO upgrading A* should be relatively easy. The main part of the work will be to store them somewhere in gamestate and provide a WML interface to modify them.
20091222 18:07:30< fendrin> alink: hmmm, I found the wml interface to code easy. It's already in place. 
20091222 18:08:42< alink> fendrin: ok good
20091222 18:08:56< fendrin> shadowmaster: I know. The dirty hack statement was a try to troll and collect some fish.
20091222 18:09:19< alink> and they are saved, WML can modify them after creation, etc...
20091222 18:10:21< fendrin> alink: I haven't coded the recording of the wml to the savefiles right now. But I have done this before for the recall dialog thing, that should be handable.
20091222 18:11:26< alink> fendrin: ok good, but yes i said "main part of the work" not "complex part of the work"
20091222 18:11:58< alink> but maybe it's because i already knew the A* code :-)
20091222 18:15:04< fendrin> And I already knew howto handle new wml tags :-)
20091222 18:15:51-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20091222 18:16:35< fendrin> silene: Maybe I can avoid all performance issues by using iterators over the original data structure.
20091222 18:16:50< alink> yeah but I always find that deciding new good WML interface (easy to use for WML writers) is hard. 
20091222 18:18:09< fendrin> alink: That is right. I haven't finished the wml interface to my new features right now. I want to discuss the issues with the wml wizards first.
20091222 18:18:13-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20091222 18:19:01 * shadowmaster afk for a movie
20091222 18:19:18< alink> well, keep it in mind when creating your c++ structures, it can simplify code and improve performance
20091222 18:20:14-!- Sebastian_ [i=be2a5742@gateway/web/freenode/x-emnwhptcdbksfpvd] has joined #wesnoth-dev
20091222 18:21:12< fendrin> alink: My structure is a std::map<location (the source of the teleport) , vector<locations (the targets that can be reached from the teleport) > > in the game_map.
20091222 18:21:16-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 73 bugs, 247 feature requests, 9 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20091222 18:22:10-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit ["Lost terminal"]
20091222 18:23:00< alink> fendrin: and how WML can edit/remove them. You will provide remove functions?
20091222 18:23:31< alink> the other way is to associate an id key to each teleport group or something like that
20091222 18:23:57< alink> but not idea what is simpler
20091222 18:25:00< fendrin> alink: I will offer a method (and wml support) that can delete the source of a teleport with all destinations. I don't plan to offer a method that can delete destinations from an already defined teleport.
20091222 18:25:15< alink> but yeah for A* such simple structure is probably better
20091222 18:26:12< alink> btw, IIRC Crab_ already mentionned it but you may want to check multimap 
20091222 18:26:50< fendrin> Yes, I will keep the multimap in mind. 
20091222 18:27:26< alink> because it's some sort of map<..., vector<> >, even if there is difference, not sure if relevant
20091222 18:30:03-!- giusef [n=giusef@unaffiliated/giusef] has joined #wesnoth-dev
20091222 18:33:23< CIA-28> alink * r40340 /trunk/src/ (map_location.cpp map_location.hpp unit.cpp): 
20091222 18:33:23< CIA-28> Save unit's waypoints (because we save goto) in [waypoints] x=1,2,... y=1,2,..
20091222 18:33:23< CIA-28> Note that if a WML event changes the goto then waypoints are discarded.
20091222 18:33:23< CIA-28> This is done by adding an extra last waypoint equal to goto for consistency check
20091222 18:33:24< CIA-28> (removed when loading), so WML can still edit them if needed.
20091222 18:33:26< Crab_> alink: I mentioned for multimap, because it is used for ai movement maps
20091222 18:34:48< alink> ok
20091222 18:36:11< fendrin> alink, Crab_: The multimap offers a natural order to the items contained. I believe to not need that feature. Therefore the map with vector maybe faster.
20091222 18:36:56< alink> fendrin: i don't think that multimap does that, but checking
20091222 18:39:14< alink> yeah only key need an ordering, as in std::map, datas in the same key are not ordered
20091222 18:40:03< alink> anyway, it's probably the heuristic function which will put the more constraint on what is the best structure
20091222 18:40:41-!- Blueblaze [n=nick@76.202.22.180] has joined #wesnoth-dev
20091222 18:41:30< alink> mmh we should already use caching there
20091222 18:42:00< fendrin> alink: Right, I still don't understand your hack to correct the heuristic function in the constructor of node. Would you mind to comment or explain it in detail?
20091222 18:42:06< alink> distance between teleports and target never change
20091222 18:42:12< silene> it's worth than that, the heuristic function will become very complicated; currently, all the villages are linked, so the distance between any two points is easy to compute; but once there are tunnels, the minimal distance may involve several tunnels (while currently it involves at most one)
20091222 18:42:45< silene> in other words, the heuristic function itself will be an A* algorithm
20091222 18:43:14< alink> yeah, i though about that, i think i had an idea using a matrix filled only once, but i don't remember it now
20091222 18:46:48< alink> fendrin: about the current heuristic function (not my hack btw): first, you need to understand the importance of a correct heuristic when there is teleport
20091222 18:47:07-!- Noyga [n=lame-z@wesnoth/developer/noyga] has joined #wesnoth-dev
20091222 18:47:11 * fendrin is listening carefully.
20091222 18:47:25-!- _teddy [n=fedor76@ppp-78-24-27-29-bras0.istra.ru] has quit [Read error: 104 (Connection reset by peer)]
20091222 18:48:30< alink> because with teleports the A* heuristic (distance to target) is not good enough. Always aiming for target is a bad idea if there is teleport just near you going right to the far target
20091222 18:50:04< alink> currenlty it's very simple just check if there is village near source and near target and check if using teleport is shorter
20091222 18:50:20< silene> it's not that it is not good enough; if the heuristic function gives a result bigger than the minimal path, the path returned by A* is plain wrong
20091222 18:51:21< alink> silene: yeah i mean it will often gives a path ignoring the teleport. early 1.7 had this bug
20091222 18:51:50< alink> but yeah for a shortest path algo, it's "wrong"
20091222 18:53:03< silene> at a time (i would say 0.9), someone even multiplied the heuristic function by 1.1, saying that the algorithm was finding paths faster; that was true, but we also got several bug reports saying that units were getting stuck in mountains...
20091222 18:53:42< alink> hehe, the classic trap of the "faster" heuristic :)
20091222 18:54:16-!- _teddy [n=fedor76@ppp-78-24-27-29-bras0.istra.ru] has joined #wesnoth-dev
20091222 18:55:50-!- [Relic] [n=[Relic]@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20091222 18:56:33< fendrin> It seems that I need to go back to the planning phase to deceide the right data structure that fits the needs of the graph and the heuristic.
20091222 18:57:17< alink> anyway for the complex multi teleport heuristic, maybe do a breadth-first search (only using distance) from the target to various teleport and updating the distance to source for each teleport entry
20091222 18:57:36< [Relic]> Hello :)
20091222 18:58:39< alink> which indeed will need to use the teleport structure in the opposite direction of its intented use
20091222 19:00:32< alink> fendrin: i say, first figure a way to just do it right, and then find a way to do it fast :-)
20091222 19:01:07< alink> or at least not too slowly
20091222 19:02:39< silene> alink: i think i see what your matrix-based heuristic may be; it requires to compute a matrix for each movement type by using non-teleport A*; the matrix would give the cost of going between any two tunnel entries
20091222 19:03:01< silene> then the heuristic function would be almost the same as the current one
20091222 19:03:38< alink> no need to worry about movement type for the heuristic, we just use hex-distance there
20091222 19:04:35< silene> alink: why? since we have to compute the distance matrix anyway, we may as well compute the optimal one
20091222 19:05:34-!- Netsplit kubrick.freenode.net <-> irc.freenode.net quits: Noyga, AnMaster, Tigge, Blueblaze
20091222 19:05:39< alink> well we will end doing a lot of precise and costy pathfinding for bad paths
20091222 19:06:25< alink> the point of using simple heuristic it to quicly prune bad paths
20091222 19:07:37< silene> alink: as i said, the heuristic function itself does not change much; it won't be slower if the matrix is optimal, but the A* algorithm will definitely be faster
20091222 19:08:20< alink> yes A* will be much faster, but building the matrices will be much slower
20091222 19:09:01< silene> who cares? there are only a few movement types; once they all have been computed and cached, there won't be any additional cost
20091222 19:10:07< alink> Note that you can't cache optimal matrix, too much changing things affect pathfinding (ZoC, current MP etc)
20091222 19:10:23-!- Netsplit over, joins: Noyga, Blueblaze, Tigge
20091222 19:11:05< alink> but yeah maybe caching one optimist verision for each movement type is worth it
20091222 19:11:46< silene> alink: i was thinking optimal in the sense that there is at least a configuration of the map/units where the distances are correct
20091222 19:11:48< fendrin> It seems I should implement the thing in a way that allows to easily exchange the heuristic funktion. 
20091222 19:13:07< silene> fendrin: no, there is never a reason not to use the best heuristic function avalaible
20091222 19:13:53-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #Wesnoth-dev
20091222 19:14:44< alink> silene: mmh code simplicity maybe? If hex-distance is good enough, no need to write/maintain more complex caching system
20091222 19:16:00< silene> alink: if it is good enough, then it is the best one (i was only reacting to the point about having custom heuristic functions)
20091222 19:17:08< alink> I'd say start with hex-distance, it's simpler and should near optimal on non-mazy map. Then check if there is big problem in maze using teleport and then try a better heuristic
20091222 19:17:15< alink> +be 
20091222 19:18:11< fendrin> Okay, that sounds like a good midterm goal.
20091222 19:18:16-!- AnMaster_ [n=AnMaster@unaffiliated/anmaster] has joined #wesnoth-dev
20091222 19:19:17< Crab_> note that 'mp cost to target for specific movement type' doesn't always exactly translate into 'turns to get there' - as extra mp (e.g. with mp=5,cost=3) are wasted. for example, it is possible that the target with cost=40 will be reachable in 10 turns, and the target with cost=33 will be reachable in 11 turns
20091222 19:20:15< fendrin> Crab_: I see. But I can't see how the current code is aware of that.
20091222 19:20:23< silene> Crab_: the algorithm already handles it
20091222 19:20:31< silene> fendrin: it's taken into account by the cost function
20091222 19:20:32< Crab_> ok
20091222 19:20:56< Sebastian_> well I am new , but last semester I had a similar problem, mmm, I havent cheked the data structure behind game position, Where can i find the c++ file for that,, (I downloaded svn but there are alot of files)
20091222 19:21:09< silene> alink: note that you have to cache the matrix anyway, even if there is only one; it would be too costly to recompute it each time
20091222 19:21:53< fendrin> silene: Current heuristic is very simple. It only does some x-y stuff. I am not sure about to costly to recompute therefore.
20091222 19:22:26< alink> silene: well using hex-distance is a small O(1) thing, you need many different tunnels to become a problem
20091222 19:22:38< alink> fendrin: about midterm goal. If you want a easy task to familiarize yourself with the current heuristic and optimize 1.8 a bit, then you may try to implement the optimization that i mentionned earlier: "cache the distance from teleports to target"
20091222 19:23:05< alink> fendrin: this will be a much easier version of what you need for 1.9
20091222 19:23:18-!- Netsplit kubrick.freenode.net <-> irc.freenode.net quits: ettin, knotwork, Vetinari, [Relic], loonycyborg
20091222 19:23:27< silene> alink: no, it isn't; it's exponential in the number of tunnels; hence the interest of precomputing everything in a matrix, so that it is only quadratic
20091222 19:24:00< fendrin> alink: Do you want me to cache the heuristic from teleport to target? Or should I start an a starsearch run for that?
20091222 19:24:53< Crab_> Sebastian_: the actual pathfinding algorithm is in src/astarsearch.cpp
20091222 19:25:54< Sebastian_> I will check it, fink update is going to take long :)
20091222 19:26:31< alink> silene; i don't see it as very costy, the few tunnels will create a very simple graph, it should be simple enough, but i need to thing more about it
20091222 19:28:04-!- Netsplit over, joins: [Relic], loonycyborg, ettin, knotwork, Vetinari
20091222 19:28:14< alink> fendrin: yeah note that each time we check the heuristic (at each node), we recaculate the minimal distance from teleport to target, but this value never change
20091222 19:28:25< alink> this is simpler version of your complex problem
20091222 19:30:20< alink> silene: another point about not caching the matrix is that a next goal could be to have WML-conditional teleport, which will cause problems for cache, but not for generated matrix
20091222 19:30:49< alink> a simple example could be to check side of unit
20091222 19:32:17< alink> in fact any WML filter not depending of the location of unit or current MP should not be a problem
20091222 19:32:49< alink> just add a "usable" bool in each teleport and check it once
20091222 19:33:59< Crab_> alink: note that you'll need to duplicate/extract this 'is teleport usable?' check - e.g. a teleport might be usable when the unit will begin its move, but won't be usable when the unit actually reaches the teleport location
20091222 19:34:39-!- AnMaster_ is now known as AnMaster
20091222 19:34:43< alink> Crab_: that's why i specified WML filter not depending of the location of unit or current MP :-)
20091222 19:35:09< Crab_> alink: that's not all - imagine a 'sighted' event which triggers during the move and changes something
20091222 19:35:15< alink> otherwise it's much harder to stay efficient
20091222 19:35:48< alink> Crab_: pathfinding provide a solution before doing the move, it ignores what may happens when you actually move
20091222 19:35:54< Crab_> alink: that's not a problem for pathfinding per se, but it means that the actual movement code in src/actions.cpp will need to check for teleport useability, too
20091222 19:36:12< alink> ah yes, but that's the easy part :-)
20091222 19:36:33< alink> only need to check the hex where you actually pass
20091222 19:36:35< Crab_> alink: so, I'm talking about that only to point out that 'is teleport usable' is to be decoupled from pathfinding - as it is a part of the 'game rules'
20091222 19:37:09< alink> ah no, my bool "usable" was just to cache the result of the WML filter
20091222 19:37:16< alink> for pathfinding
20091222 19:37:37< alink> game rules will be a real filter or WML stuff
20091222 19:37:42< Crab_> ok
20091222 19:38:32< alink> the point is to avoid using WML filter in pathfinding because they are slow and can be tested on many many hexes
20091222 19:38:58< alink> this is why the current power of the skirmisher ability hurt performance a bit
20091222 19:39:06< Crab_> yes, they should limited to things that can be precalculated
20091222 19:40:31< alink> yes, this make  things simpler, but OTOH the skirmisher flexibility make a lot of sense
20091222 19:40:33< Espreon> Hmmmm... trunk complains about missing fonts now. It has never done so before... and the fonts are indeed missing.
20091222 19:40:53< Espreon> Missing fonts: sazanami-gothic.ttf and wqy-zenhei-gb2312.ttf.
20091222 19:42:39< fendrin> alink: node's fields: g h t and in are not commented. g = goal ; the distance from the node to the goal calculated by the heuristic?
20091222 19:43:09< alink> yeah that's always annoyed me too, but that's classic A* notation
20091222 19:43:41< alink> I suggest that you read some A* stuff to familiarize yourself with it
20091222 19:43:56< alink> and no IIRC g is actual cost to get there
20091222 19:44:16< alink> i have very nice pathfinding site for that, i'll get you the url
20091222 19:45:37< alink> http://theory.stanford.edu/~amitp/GameProgramming/index.html
20091222 19:46:18< fendrin> alink: I have already implemented a astarsearch in java for a software project. And I have implemented a Dijkstra. That was in java.
20091222 19:46:27< fendrin> as well
20091222 19:47:34< alink> yeah but there is various way to implement A* and there is various cases (grid or not, hex or square, teleport). each one affecting what it the best implementation
20091222 19:49:04< alink> in wesnoth the most special thing which break a bit A* theory is the turn based aspect
20091222 19:49:59< alink> because it can change the distance between nodes, and most A* implementation consider that constant
20091222 19:51:13-!- Netsplit kubrick.freenode.net <-> irc.freenode.net quits: ettin, knotwork, Vetinari, [Relic], loonycyborg
20091222 19:51:30< alink> and that's not so rare, since you just need terrain costing 2 MP
20091222 19:55:21< fendrin> alink: You are talking about a mp 5 unit that can only go 2 hexes with mp2 terrain?
20091222 19:56:31< silene> fendrin: yes, since it means that the next move will actually cost 3 if the terrain has a cost of 2
20091222 19:57:01< alink> yes, this cause the cost to get from one node to another node  to depends of the previous path used
20091222 19:57:50< alink> if all hexes cost 2 MP, we could anticipate that, but add some 1 MP there, and even if the unit has 6MP, you have the same problem
20091222 20:04:13< fendrin> I see.
20091222 20:05:26< alink> that's somehow related to teleport. for example, some people find it unfair that the silver mage can teleport several times by turns. But changing that and using a teleport counter will also make cost depend of the previous path used
20091222 20:05:52< silene> fendrin: thinking back about the previous discussion, there may have been a misunderstanding due to the naming of the functions: the real heuristic function is not in the "heuristic" function, it is in the "node" constructor
20091222 20:06:03-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091222 20:07:05< alink> silene: good point, i also assumed that we talked about that, not the just the "heuristic function"
20091222 20:07:17< fendrin> silene: Yes, I know. 
20091222 20:07:47-!- ardesh [n=ardesh@port-92-195-45-108.dynamic.qsc.de] has quit [Read error: 110 (Connection timed out)]
20091222 20:08:23-!- ardesh [n=ardesh@port-92-195-100-199.dynamic.qsc.de] has joined #wesnoth-dev
20091222 20:20:54-!- Netsplit over, joins: [Relic], loonycyborg, ettin, knotwork, Vetinari
20091222 20:21:39-!- Netsplit kubrick.freenode.net <-> irc.freenode.net quits: Noyga, Tigge, Blueblaze
20091222 20:28:41-!- giusef [n=giusef@unaffiliated/giusef] has quit ["exit (-1);"]
20091222 20:29:48-!- Netsplit over, joins: Noyga, Blueblaze, Tigge
20091222 20:49:16-!- TheJH [n=jann@wikipedia/TheJH] has joined #wesnoth-dev
20091222 20:51:40< CIA-28> silene * r40341 /trunk/src/actions.cpp: Fixed wild copy-pasting.
20091222 20:51:49-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."]
20091222 20:53:23-!- kitty_ [n=kitty@e180200104.adsl.alicedsl.de] has joined #wesnoth-dev
20091222 21:09:48-!- EdB [n=edb@195.12.95-79.rev.gaoland.net] has quit [Remote closed the connection]
20091222 21:21:18-!- fmunoz [n=chatzill@201-0-203-222.dial-up.telesp.net.br] has quit [Read error: 113 (No route to host)]
20091222 21:55:02< CIA-28> ivanovic * r40342 /trunk/ (8 files in 7 dirs): updated Slovak translation
20091222 22:10:06-!- Sebastian_ [i=be2a5742@gateway/web/freenode/x-emnwhptcdbksfpvd] has quit [Ping timeout: 180 seconds]
20091222 22:11:18< Crab_> fendrin: ok, I've mostly finished my change to team construction which will fix all those LoW duplication bugs and simplify a lot of other things. will need a lot of testing before I commit it (I got rid of some old hacks in the code, and removed some new hacks such as find_vacant as well)
20091222 22:13:06-!- fabi [n=fabi@88-134-119-197-dynip.superkabel.de] has joined #wesnoth-dev
20091222 22:17:21-!- Ken_Oh [n=briang@static-71-178-174-220.washdc.fios.verizon.net] has quit ["Leaving."]
20091222 22:22:29-!- Noyga [n=lame-z@wesnoth/developer/noyga] has left #wesnoth-dev ["Quitte"]
20091222 22:27:16< fabi> Crab_: That is good, but maybe you commit it after the release since I think to have fixed all issues by wml hacks.
20091222 22:27:45-!- Sebastian_ [i=be2a5742@gateway/web/freenode/x-tviyvxvvsxnarfvo] has joined #wesnoth-dev
20091222 22:29:04-!- fendrin [n=fabi@wesnoth/developer/fendrin] has quit [Read error: 110 (Connection timed out)]
20091222 22:30:55< Crab_> fabi: this one, too ? http://forum.wesnoth.org/viewtopic.php?f=4&t=28177
20091222 22:31:29< Crab_> (that is with 'I had totally restarted the campaign in 1.7.10, having deleted all the saves from previous attempts in 1.7.9 (having not reached this mission either).')
20091222 22:35:14< fabi> Crab_: No, that issue is new to me.
20091222 22:36:15-!- dtiger [n=dtiger@dynamic-vpdn-93-125-15-71.telecom.by] has quit [Remote closed the connection]
20091222 22:37:13< Crab_> fabi: so, more wml hacks are needed - or, I can patch it once at the c++ engine level
20091222 22:39:47< fabi> Crab_: Good point.
20091222 22:40:53< Crab_> fabi: I won't commit it if my playtests show any not-trivial-to-fix problems in mainline content
20091222 22:41:39< Crab_> fabi: but, if no problems are spotted, I think that it'll be better to patch the thing once and then have less maintenance problems 
20091222 22:43:02< Crab_> with the patch, I'm killing an old hack which says ' if this side tag describes the leader of the side, we may replace the leader with someone from recall list who can recruit, but take positioning from [side]'
20091222 22:44:10< Crab_> it is, however, replaced by create-or-recall semantics of all those [unit] and leader-in-[side] tags, so, for example HttT (which uses this hack to get the player's leader) just works without WML changes.
20091222 22:44:45< Crab_> but, this will break any levels which depended on the hack and which have leader different from leader in previous scenario
20091222 22:45:26< Crab_> (sooner or later, that hack is to be removed anyway because it prevents 'multiple leaders on same side' from working correctly)
20091222 22:47:33< fabi> Crab_: Hmm, I think I didn't understand what types of semantics work and which not. But you seem to have a pretty good idea of what you are doing, so it's not on me to deny that fix before the release.
20091222 22:48:31< Crab_> fabi: I also see that, in 1.9, it will be desirable to somehow add a new type of WML event which will be fired even before teams are fully constructed - to allow messing with recall lists before team construction takes place.
20091222 23:01:55< fabi> Crab_: Doesn't the preload event do that?
20091222 23:03:04< Crab_> fabi: no, it's too late
20091222 23:04:06< Crab_> fabi: you see, when teams are constructed, there's no 'environment' in which WML events can be run - e.g. teams vector is not complete
20091222 23:04:23-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit []
20091222 23:04:25< Crab_> fabi: but, when teams are constructed, starting units and leader are placed
20091222 23:06:07< Crab_> fabi: therefore, any attempts to change the side leader/starting units via WML events are 'workarounds'. for example, if it would be possible to reorganize recall lists and leaders before they're used in team construction, it would be trivial to do things 'put landar from side 1 to side 2, and put half of side 1 recall list there, too'
20091222 23:06:58< Crab_> fabi: workarounds such as 'do it at the end of previous scenario' are buggy wrt saves from different versions
20091222 23:07:30< fabi> Crab_: Yes, all end of scenario hacks are bad, at least for testing purposes and savegame compatability.
20091222 23:23:03-!- alink [n=alink@wesnoth/developer/alink] has quit [Remote closed the connection]
20091222 23:24:24-!- TheJH [n=jann@wikipedia/TheJH] has quit [Read error: 60 (Operation timed out)]
20091222 23:27:36-!- Sebastian_ [i=be2a5742@gateway/web/freenode/x-tviyvxvvsxnarfvo] has quit ["Page closed"]
20091222 23:46:25-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)]
--- Log closed Wed Dec 23 00:00:21 2009