--- Log opened Fri Jan 01 00:00:44 2010
20100101 00:04:02-!- Blueblaze [n=nick@adsl-76-202-22-180.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100101 00:22:16-!- new_shadowmaster [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100101 00:27:13-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)]
20100101 00:35:53-!- new_shadowmaster is now known as NewShadowm
20100101 00:42:57-!- ettin [n=jorda@wesnoth/developer/ettin] has quit [Read error: 54 (Connection reset by peer)]
20100101 00:43:28-!- ettin [n=jorda@wesnoth/developer/ettin] has joined #wesnoth-dev
20100101 00:51:28-!- Espreon is now known as ZaWarudo
20100101 00:51:33-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has joined #wesnoth-dev
20100101 00:52:09-!- ZaWarudo is now known as Espreon
20100101 00:53:31-!- yann [n=dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has quit [Remote closed the connection]
20100101 01:04:01-!- zookeeper [n=l@88-148-251-223.bb.dnainternet.fi] has quit []
20100101 01:10:59< Noyga> happy new year
20100101 01:11:05< Noyga> and gnit
20100101 01:11:08-!- Noyga [n=noyga@wesnoth/developer/noyga] has quit ["Quitte"]
20100101 01:32:33-!- elynia_ [n=shyde@wesnoth/umc-dev/misc/elynia] has joined #wesnoth-dev
20100101 01:32:47-!- shadowmaster_ [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100101 01:32:55-!- NewShadowm [n=ignacio@wesnoth/developer/shadowmaster] has quit [Nick collision from services.]
20100101 01:33:06-!- elynia_ [n=shyde@wesnoth/umc-dev/misc/elynia] has quit [Nick collision from services.]
20100101 01:33:11-!- elynia_ [n=shyde@wesnoth/umc-dev/misc/elynia] has joined #wesnoth-dev
20100101 01:33:19-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has quit [Nick collision from services.]
20100101 01:36:04-!- elynia_ is now known as elynia
20100101 01:36:52-!- shadowmaster_ is now known as NewShadowm
20100101 01:39:15-!- elynia is now known as PinkUnicorn
20100101 01:56:20-!- PinkUnicorn is now known as FaerieWhoSaysFoo
20100101 02:02:31-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20100101 02:03:33-!- FaerieWhoSaysFoo [n=shyde@wesnoth/umc-dev/misc/elynia] has quit ["nyu"]
20100101 02:17:50-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has joined #wesnoth-dev
20100101 02:19:30-!- shikadibot_home [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20100101 02:31:11-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100101 02:50:46-!- ardesh [n=ardesh@port-92-195-52-152.dynamic.qsc.de] has quit [Read error: 110 (Connection timed out)]
20100101 02:51:24-!- ardesh [n=ardesh@port-92-195-210-217.dynamic.qsc.de] has joined #wesnoth-dev
20100101 02:59:44 * Espreon wishes that boucman was around.
20100101 02:59:56< shadowmaster> for what?
20100101 03:00:29< Espreon> So that I can remind him to fix something.
20100101 03:16:47-!- Chusslove [n=Chusslov@brsg-d9bef670.pool.mediaWays.net] has quit [Read error: 110 (Connection timed out)]
20100101 03:23:48-!- Chusslove [n=Chusslov@brsg-d9befa8e.pool.mediaWays.net] has joined #wesnoth-dev
20100101 03:26:54-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"]
20100101 03:27:34-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20100101 03:53:37< shadowmaster> happy new year in advance
20100101 03:58:42-!- Espreon is now known as ZaWarudo
20100101 04:00:46-!- ZaWarudo is now known as Espreon
20100101 04:18:30-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20100101 04:23:49-!- NewShadowm [n=ignacio@wesnoth/developer/shadowmaster] has quit [Connection timed out]
20100101 04:24:07-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100101 04:26:12-!- Ivanovic_ [n=ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100101 04:28:25-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has quit [Read error: 110 (Connection timed out)]
20100101 04:29:00-!- shikadibot_home [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has quit [Read error: 110 (Connection timed out)]
20100101 04:42:20-!- Ivanovic [n=ivanovic@wesnoth/developer/ivanovic] has quit [Read error: 110 (Connection timed out)]
20100101 04:44:14-!- Ivanovic_ is now known as Ivanovic
20100101 05:18:35-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["Leaving"]
20100101 05:42:59-!- Jetrel [n=Jetrel@wesnoth/artist/jetrel] has joined #wesnoth-dev
20100101 05:44:11< Jetrel> shadow_master, esr, anyone-who-cares:  I'm upgrading the wolf+rider graphics as I speak, and one side effect of this is I'm doing the wolves as a separate layer, so they can easily be split into separate units.  I would like to make a full 3 levels of wolves.
20100101 05:44:42< Jetrel> I propose the names:   "Wolf"  "Great Wolf" and "Dire Wolf", respectively.  Anyone have any problems with that, or suggestions for something better?
20100101 05:45:12< Jetrel> We're speaking of rider-LESS wolves here, mind you - monsters as campaign fodder.
20100101 05:46:08< Jetrel> Also, there will only be a straight line of 3;  the ruddy-toned pillager wolves will have no counterpart in the stock monsters.
20100101 05:46:48< Jetrel> I might make a graphical variant of the level-2 if people want it for riderless mounts or something.
20100101 05:47:50< Jetrel> ¬_¬  in fact I probably -should-, just because of that.
20100101 05:55:13< CIA-28> jetryl * r40487 /trunk/data/core/ (13 files in 2 dirs): Updated the goblin wolf rider with new graphics, and a two-frame defense animation.
20100101 06:02:38< Espreon> Excellent. :)
20100101 06:03:40< CIA-28> jetryl * r40488 /trunk/data/core/ (9 files in 2 dirs): Updated the riderless wolf with new graphics and a two-frame defense animation.
20100101 06:05:05-!- boucman [n=rosen@wesnoth/developer/boucman] has quit ["Leaving."]
20100101 06:12:06-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has joined #wesnoth-dev
20100101 06:12:22-!- shikadibot_home [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20100101 06:12:23-!- NewShadowm [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100101 06:14:43< shadowmaster> Jetrel: good
20100101 06:23:15< esr> Jetrel: Cool.  I would have suggested Dire Wolf for L3 if you hadn't thought of it.
20100101 06:25:00< esr> Jetrel: I think fendrin and I are going to need an earth-elemental unit for the "Wings of Victory" campaign...are you up for spriting something like that?
20100101 06:25:20< Espreon> Jetrel: Superb.
20100101 06:31:22-!- shikadibot_ [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20100101 06:31:23-!- shadowmaster_ [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100101 06:31:23-!- shikadibot_home [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has quit [Read error: 104 (Connection reset by peer)]
20100101 06:31:43< shadowmaster> Espreon: you have seen 55eee
20100101 06:31:54< Espreon> Eh?
20100101 06:32:23< shadowmaster> esr: have you seen the animated rock unit and its L2 and L3 from the Era of Myths (originally taken from the Path of Summoners era by fmunoz IIRC)?
20100101 06:32:53< Espreon> shadowmaster: I believe that melon created the L3.
20100101 06:33:07< Espreon> The L3 unit is EoM/TSL-only.
20100101 06:33:08< shadowmaster> that's probably right.
20100101 06:33:38-!- NewShadowm [n=ignacio@wesnoth/developer/shadowmaster] has quit [Read error: 104 (Connection reset by peer)]
20100101 06:47:29-!- shikadibot_ is now known as shikadibot_home
20100101 06:48:08-!- shadowmaster_ is now known as nickshadowm_lapt
20100101 06:48:15-!- nickshadowm_lapt is now known as shadowm_laptop
20100101 06:51:47< Jetrel> esr:  actually, fmuñoz has made a whole set of elemental units for his "path of summoners" era.  Some are not very good, but some of them, like the plant-elemental, are quite nice
20100101 06:52:06 * Jetrel goes afk for new years celebrations.
20100101 06:52:45< Espreon> esr: Just look in /trunk/The_Silver_Lands and see what you like
20100101 06:52:56 * Espreon is talking in the context of UMC-Dev's svn repository of course.
20100101 06:53:34< Jetrel> Later when I am done with some other mainline stuff, I would like to mainline many of the elemental units from "path of summoners" after beautifying them.
20100101 06:53:43< Jetrel> that's quite a ways off.
20100101 06:53:55< shadowmaster> Jetrel: Sylph. :3
20100101 06:54:24< shadowmaster> I hope that's included in the "other mainline stuff" list
20100101 06:54:33< Jetrel> shadowmaster:   yeah, I'm planning to do a whole pass over the elves quasi-soon wherein I'll do major animation upgrades to the whole race.
20100101 06:55:25< Espreon> Jetrel: Sounds like a grand plan.
20100101 06:56:29< Jetrel> these are where my current cleanups stand; to forestall complaints from esr, it's not iron, it's mithril, if we're gonna complain about that.  :P
20100101 06:57:10< Jetrel> part of why I gave it that sort of blue-silver tinge/lustre.
20100101 06:57:22< Jetrel> and I really need to go.
20100101 06:57:38< esr> Jetrel: Thanks for the pointer.
20100101 07:09:10-!- shikadibot_home [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has quit ["leaving"]
20100101 07:09:13-!- elynia [n=shyde@wesnoth/umc-dev/misc/elynia] has quit ["nyu"]
20100101 07:09:45-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit ["shadowmaster, stop making people hilight me! :("]
20100101 07:43:20-!- Sirp [n=user@wesnoth/developer/dave] has quit [Read error: 113 (No route to host)]
20100101 08:40:36-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20100101 08:55:37-!- Kenpachi_ [n=chatzill@CPE-58-166-240-240.lns3.way.bigpond.net.au] has quit [Read error: 110 (Connection timed out)]
20100101 09:24:14-!- PeterFA [n=quassel@unaffiliated/peterfa] has joined #wesnoth-dev
20100101 09:24:36< PeterFA> I meant to be online on esr's available times but I got caught up in life.
20100101 09:45:02-!- ardesh [n=ardesh@port-92-195-210-217.dynamic.qsc.de] has quit [Read error: 60 (Operation timed out)]
20100101 09:46:46-!- ardesh [n=ardesh@port-92-195-162-228.dynamic.qsc.de] has joined #wesnoth-dev
20100101 10:17:42-!- PeterFA [n=quassel@unaffiliated/peterfa] has quit [Remote closed the connection]
20100101 10:38:40-!- Noyga [n=noyga@wesnoth/developer/noyga] has joined #wesnoth-dev
20100101 10:55:50< Ivanovic> moin
20100101 10:55:57< Ivanovic> and a happy new year
20100101 11:19:25-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100101 11:46:41-!- yann [n=dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has joined #wesnoth-dev
20100101 11:48:58-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100101 11:53:08-!- Noyga [n=noyga@wesnoth/developer/noyga] has quit [Remote closed the connection]
20100101 11:54:18-!- Crab_ [n=Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100101 12:08:30-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100101 12:38:44-!- Blueblaze [n=nick@adsl-76-202-22-180.dsl.hstntx.sbcglobal.net] has quit [Remote closed the connection]
20100101 12:43:30< Ivanovic> hi Crab_
20100101 12:43:37< Crab_> hi Ivanovic
20100101 12:43:38< Ivanovic> Crab_: have you seen this bug? https://gna.org/bugs/index.php?15013
20100101 12:44:05< Crab_> yes. In fact, I assigned it to myself :)
20100101 12:44:10< boucman> happy new year to all of you
20100101 12:44:21< Crab_> happy new 2010, yes :)
20100101 12:44:27< Ivanovic> ah, right
20100101 12:44:54< Ivanovic> you mentioned that you might have a look at updating (okay, upgrading) the wiki, any news on this?
20100101 12:45:09< Crab_> boucman: just don't forget to delete it once it ends, otherwise you'll get a memory leak :)
20100101 12:45:22< Crab_> Ivanovic: no, not yet
20100101 12:45:39< boucman> Crab_: ??
20100101 12:46:14< Crab_> boucman: just joking that 'new' in 'happy new year' is similar to c++ operator new()
20100101 12:46:24< boucman> hehe
20100101 12:46:30< boucman> sorry, not totally awake yet
20100101 12:46:43< Crab_> boucman: so, after year ends, all bad memories from it have to be deleted :)
20100101 12:47:44< Espreon> boucman: Remember to fix those problems... ;)
20100101 12:47:51-!- Kenpachi [n=chatzill@CPE-58-166-240-240.lns3.way.bigpond.net.au] has joined #wesnoth-dev
20100101 12:48:42< boucman> Espreon: I can do it now, but I don't remember the problem itself :P
20100101 12:50:06< Espreon> The problems: The wing flapping of the drakes overlays the cave wall; the ellipse looks funny; the shadows are casted on the cave wall.
20100101 12:50:29< Espreon> Just spawn a Hurricane Drake on a hex that has cave wall south of it.
20100101 12:51:47< boucman> mkay
20100101 12:52:30< boucman> Espreon: no promise on that one, the thing is that the engine doesn't know the difference between a cave wall, a castle wall or a giant tree (same code
20100101 12:52:44< boucman> however for the two others, that's how they are supposed to work
20100101 12:53:01< Espreon> I see...
20100101 12:53:28< Espreon> Even the funny appearence of the ellipse?
20100101 12:53:59< boucman> i have to check that one, but I think a non-flying unit would have the same ellipse, i.e partly covered by the wall
20100101 12:54:16< Espreon> Well, in this case, it looks glitchy...
20100101 12:54:39< Espreon> It looks like it is merged with the upper part with the cave wall...
20100101 12:54:50< Espreon> Rather than being blocked...
20100101 12:55:47< boucman> Espreon: i think it looks good, not sure what you don't like...
20100101 12:57:25< Espreon> Lemme create a screenshot...
20100101 12:57:31< boucman> ok
20100101 13:02:46< Espreon> boucman: http://imagebin.org/77800
20100101 13:03:09< boucman> ok, hmm
20100101 13:04:20< boucman> it's hard to tell if it's a bug in the terrain engine or if it's a bug in the overlays that don't join properly (my guess is the later since a bug in the former would cause glitches in many more places)
20100101 13:04:28< boucman> but it's not an animation bug :P
20100101 13:05:23< boucman> as for the shadow on the wall thing, that one is almost impossible to fix since shadows are not separated from the main image
20100101 13:06:54< Espreon> Meh, oh well...
20100101 13:13:34< fendrin> Espreon has raised a good point here. The drakes shouldn't fly in caves at all, that leads to strange movemont consequences. The drakes are slow on most underground terrains but if the cave terrain is mixed with some overground terrain (water for example) which is often needed in cave scenarios for some reason the drakes are fast there because of their flying ability. I thought about making underground water tiles that deny the flying to 
20100101 13:13:35< fendrin> solve this problem.
20100101 13:15:15< boucman> iirc the terrain mixing code allows a best/worse choice for the value used for defense/offense
20100101 13:15:40< boucman> as for animations, better see this with tsi, he's the one that handled the artistic part of changing the drakes
20100101 13:17:43< fendrin> boucman: That won't work, the underground water terrain can't be a mixed terrain type because there is no equivalent terrain on which the flying drakes are forced to swim. I don't even have an idea how fast flying drakes can swim.
20100101 13:19:37< boucman> ok, I see your point
20100101 13:23:02< fendrin> boucman: Esr and I, we are planning to do an overground scenario on which all drakes are forced to walk/swim because of a storm. I first thougt, ease just give every drake the movement type of the clashers. But that isn't true because the clasher's movement is also affected by their heavy armour. It needs some serious thinking to get this right.
20100101 13:24:13< boucman> fendrin: interesting idea...
20100101 13:24:31< boucman> otoh other drakes are probably not used to walking, so it would make sense
20100101 13:24:47< boucman> would the glider line still be able to fly (maybe with reduced mp)
20100101 13:25:28< fendrin> That was not planned but it is an option.
20100101 13:27:45-!- loonybot [n=loonybot@ppp79-139-137-151.pppoe.spdop.ru] has joined #wesnoth-dev
20100101 13:28:31-!- loonycyborg [n=sergey@ppp79-139-137-151.pppoe.spdop.ru] has joined #wesnoth-dev
20100101 13:29:51-!- boucman [n=rosen@wesnoth/developer/boucman] has quit [Remote closed the connection]
20100101 13:30:14-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100101 13:36:26-!- Amu [i=smar@smar.fi] has joined #wesnoth-dev
20100101 13:37:36-!- Smar is now known as Amuchan
20100101 13:37:39-!- Amu is now known as Smar
20100101 13:43:09< Espreon> wesbot: seen thespaceinvader ?
20100101 13:43:09< wesbot> Espreon: The person with the nick thespaceinvader 2d 14h ago they left with the message: "ChatZilla 0.9.86 [Firefox 3.5.6/20091201220228]"
20100101 14:01:00-!- mordante [n=mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20100101 14:01:15< mordante> servus
20100101 14:01:23< mordante> best wishes 
20100101 14:01:51< Crab_> hi mordante
20100101 14:02:01< mordante> hi Crab_ 
20100101 14:02:11< mordante> AI0867, if the load bug is gui1 I'm not really interested, have enough gui2 stuff to do
20100101 14:02:50< Espreon> Hello mordante.
20100101 14:02:55< mordante> hi Espreon 
20100101 14:03:14< boucman> Crab_: when do you plan to switch trunk to use the new AI by default ?
20100101 14:03:56< Crab_> boucman: before next release. I need to fix a few relatively easy things (mostly copypaste needed) before I do that.
20100101 14:04:31< boucman> ok
20100101 14:06:55< Crab_> (when loading a save/starting a level, old parameters such as protect_leader and protect_location are to be replaced by new types of ai goals (those need to be created by copying their old code)
20100101 14:09:25< loonycyborg> mordante: Is it planned to add drive letters to gui2 version of file chooser dialog on windows? :P
20100101 14:09:44< mordante> loonycyborg, of course 
20100101 14:10:09< loonycyborg> I expected as much..
20100101 14:10:13< mordante> and I also think using boost::filesystem can make some things easier
20100101 14:11:17< boucman> mordante: i'm not sure adding a new dependency at this point is a good idea, 1.9 ?
20100101 14:11:31< loonycyborg> There seem to be AMIGAOS conditionals everywhere. I don't think that boost::filesystem has support for it.
20100101 14:13:31< Ivanovic> loonycyborg: personally i don't think that it is this important to support amigaos
20100101 14:13:44< Ivanovic> the last version available for that one is 1.4.7 anyway...
20100101 14:13:58< boucman> hmm
20100101 14:14:17< Ivanovic> beside this, at least in os4depot.net the latst version of boost available is 1.33.1 anyway
20100101 14:14:32< boucman> Ivanovic: it might be a good idea to make a call in the 1.8 announcement, and plan (official) removal for 1.9
20100101 14:15:27< Ivanovic> boucman: even right now it can not work anyway
20100101 14:16:00< Ivanovic> since the boost version we require is newer than the latest available in amigaos
20100101 14:16:02< Ivanovic> ;)
20100101 14:16:07< boucman> :P
20100101 14:16:22< boucman> let's still do it cleanly, even if it's not working
20100101 14:16:24< mordante> boucman, obviously not 1.8 material
20100101 14:16:38< loonycyborg> If someone will want to port wesnoth to amigaos we'll tell them to go patch boost. That'll make porting all other boost.filesystem using programs to amigaos easier :P
20100101 14:17:24< CIA-28> mordante * r40489 /trunk/src/ (680 files in 23 dirs): New year copyright update.
20100101 14:19:48< Crab_> 2009.01.01 11:28 <CIA-52> mordante * r31858 /trunk/ (480 files in 19 dirs): New year copyright update.
20100101 14:20:29< mordante> Crab_, ? 
20100101 14:20:46< mordante> and why does CIA-28 report it for me ?
20100101 14:20:53< Crab_> mordante: that was the one from the previous year :)
20100101 14:21:15< mordante> ah ok
20100101 14:21:30< mordante> still use the same script ;-)
20100101 14:21:31< Crab_> mordante: it is interesting to compare the number of files :)
20100101 14:21:51< mordante> 200 more.. we've been quite busy
20100101 14:23:02< Ivanovic> regarding ports not really "supported" anymore: opensolaris was not updated for ages, too
20100101 14:23:45< Ivanovic> latest solaris version is 1.4.5 and 1.5.1, so ages old, too
20100101 14:35:17-!- Appleman1234 [n=Appleman@CPE-124-191-178-150.oxqn1.cha.bigpond.net.au] has joined #wesnoth-dev
20100101 14:37:34-!- Appleman1234 [n=Appleman@CPE-124-191-178-150.oxqn1.cha.bigpond.net.au] has quit [Client Quit]
20100101 14:42:51< mordante> wesbot seen ilor
20100101 14:42:52< wesbot> mordante: The person with the nick ilor last spoke 3d 18h ago.  3d 14h ago was here and on the channel #wesnoth with the message:
20100101 14:44:15< Ivanovic> okay, updated the downloads page to refelect the latest known state of versions (known according to repositories of those packages)
20100101 14:44:20< Ivanovic> http://wiki.wesnoth.org/Download
20100101 14:52:11-!- rosso [n=rosso@dslb-088-070-049-153.pools.arcor-ip.net] has joined #wesnoth-dev
20100101 15:06:11< fendrin> Anyone around who has some tima and can confirm my thoughts about c++ code I wrote?
20100101 15:07:38< boucman> fendrin: ok
20100101 15:08:03< fendrin> boucman: Thanks. Let me commit the code first. 
20100101 15:08:08< boucman> :P
20100101 15:09:05< CIA-28> fendrin * r40490 /branches/fendrin_pathfind/src/ (12 files in 5 dirs): Made the new pathfinder compile.
20100101 15:09:51< fendrin> boucman: I have brought the new pathfinder in a state where it is compilable but I get segmentation faults when the heuristic is iterating over the teleport locations.
20100101 15:10:21< boucman> ok
20100101 15:10:44< boucman> fendrin: i don't have your branch checked out btw, do I need it ?
20100101 15:11:09< fendrin> boucman: No, I will provide links to the svn repository.
20100101 15:11:13< boucman> k
20100101 15:12:23< fendrin> http://svn.gna.org/viewcvs/wesnoth/branches/fendrin_pathfind/src/pathfind.cpp?rev=40490&dir_pagestart=150&view=markup
20100101 15:12:43< fendrin> Please have a look at the method "get_teleport_locations".
20100101 15:13:53< fendrin> Am I assuming right that the contents of the returned "res" variable are invalid because the inserted villages pointer point to a local variable that looses it's validity after the execution leaves the scope?
20100101 15:14:00< Crab_> fendrin: yes
20100101 15:14:18< boucman> that would be my guess, yes
20100101 15:14:33< Crab_> fendrin: std::set<map_location> villages; goes out of scope, so any pointers to it are not valid anymore
20100101 15:14:37< fendrin> I need to redesign the whole mather or is there an easy way to fix things?
20100101 15:15:04< Crab_> fendrin: easy fix - make std::set<map_location*> villages
20100101 15:15:23< boucman> fendrin: i guess you should return real set of map locations instead of pointers in that case
20100101 15:15:26< Crab_> fendrin: and store the pointers to the map_locations in in current_team.villages()
20100101 15:15:46< boucman> since they are not data structures that you share with anybody else
20100101 15:16:27< Crab_> fendrin: ah no, you don't need all villages...
20100101 15:16:45< stikonas> accordint to the last comment https://gna.org/bugs/index.php?14957 is fixes, but it is marked as postponed instead of fixes
20100101 15:17:17< stikonas> s/accordint/according, s/fixes/fixed/
20100101 15:17:19< fendrin> boucman: I would do that under normal circumstances. But the data structure gets incredible huge. Assume you have 20 villages. Every village is connected with every other in case of mage teleportation.
20100101 15:17:32< boucman> hmm
20100101 15:17:46< Crab_> fendrin: so what ? is map_location that large ?
20100101 15:18:23< fendrin> Crab_: No, it isn't but remember that the pathfinder is called often, espacially by the ai.
20100101 15:18:45< Crab_> fendrin: often is not a problem - since there aren't multiple calls 'at the same time'
20100101 15:19:09< Crab_> fendrin: so, it looks like map_location only contains 'int x, y;'
20100101 15:19:16< boucman> fendrin: is a map_location that much larger than a pointer ?
20100101 15:19:37< boucman> hmm
20100101 15:19:52< fendrin> boucman: No, it isn't but I don't use pointer to map_location but pointer to sets of map_location.
20100101 15:20:32< boucman> yes, but the target of the pointer should still be in memory somewhere, so unless the target is shared, you don't gain any space...
20100101 15:20:50< boucman> you do right now because of the bug, but if you correct the bug, the gain will be nil
20100101 15:23:54< fendrin> Sure? Like it is now I have only one village set that is pointed to n times where n is the size of villages. Otherwise I have villages * villages memory usage.
20100101 15:24:41< boucman> fendrin: well, i'm not sure i understand your design, but it works only for the particular case of village teleport, in the generic case you can't assume there will be any reuse
20100101 15:26:45< fendrin> The generic case will have a similar problem. I filter for sources of the teleport and for destinations. Every source will be linked to every destionation. So in this case it makes also sense to have an indirect data structure.
20100101 15:27:39< boucman> fendrin: I really don't understand, what makes you think that there will be any sharing ?
20100101 15:28:07< boucman> you can share thevillage destination structure only because you know that every village is connected to every village 
20100101 15:28:22< boucman> whe you move to a 100% WML structure, that assumption doesn't work
20100101 15:29:24< fendrin> The filter case I described obove is a 100% WML structure.
20100101 15:29:28-!- Kenpachi [n=chatzill@CPE-58-166-240-240.lns3.way.bigpond.net.au] has quit [Remote closed the connection]
20100101 15:30:39< boucman> fendrin: that's where i don't understand, every source won't be linked to every destination, only to a subset depending on the filter
20100101 15:31:12< Crab_> fendrin: even, if you have villages A,B,C,D, then A->{B,C,D},   B->{A,C,D},   C->{A,B,D},      D->{A,B,C} -  where's the 'equal sets' ?
20100101 15:31:46< fendrin> Yes, but this subset is for every location that matches the filter the same. Linking with oneself is no problem the pathfinder will handle that.
20100101 15:32:28< Crab_> fendrin: maybe then just precache the set that you'll get from  'foreach (const map_location &l, current_team.villages())' ?
20100101 15:34:01< boucman> fendrin: ok, i think I understand how you want it to work
20100101 15:34:01< Crab_> fendrin: but, after each move, this set can change
20100101 15:34:36< boucman> my advice is to make yourself a smart class with a smart destructor and some structures that wraps all that propperly using new and delete to handle the shared refs
20100101 15:34:59< fendrin> boucman: A class teleport_locations?
20100101 15:35:15< boucman> something like that
20100101 15:35:28< boucman> you could just replace 
20100101 15:35:34< boucman> std::set<map_location> villages; 
20100101 15:35:37< boucman> with 
20100101 15:35:51< boucman> std::set<map_location>* villages = new...
20100101 15:36:00< boucman> but you need to take care of proper destruction
20100101 15:37:32< fendrin> The new keyword causes c++ to alocate the memory only if the execution reaches the new. If new is not used the memory will be allocated at programm start, right? 
20100101 15:38:50< Crab_> fendrin: no, 'allocation at program start' is for static data
20100101 15:39:40< boucman> fendrin: new is just like malloc except that it calls the constructor if it's a class
20100101 15:41:59-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20100101 15:42:08-!- rosso [n=rosso@dslb-088-070-049-153.pools.arcor-ip.net] has quit [Remote closed the connection]
20100101 15:42:23-!- rosso [n=rosso@dslb-088-070-049-153.pools.arcor-ip.net] has joined #wesnoth-dev
20100101 15:44:18< fendrin> sorry, afk for a moment.
20100101 15:49:44 * fendrin reads about malloc in wikipedia
20100101 15:50:55< fendrin> Isn't a set or map always a dynamic data structure? What do I gain by the usage of "new"?
20100101 15:51:07< Crab_> fendrin: I suggest that, before playing with allocating/deallocating data, it will be a good thing to figure out the right 'scope' for the data you need
20100101 15:53:03< Crab_> fendrin: note that for, 100x100 map, the full theoretical map of possible teleports (if it's possible to teleport from any to any) for unit X stored as "map_location->map_location" will take 8x(100^4)=800 mb in memory
20100101 15:53:20< boucman> fendrin: here is an idea, buil a std::set<std::pair<std::set<map_location>,std::set<map_location>>>
20100101 15:53:50< boucman> containing a description of all teleports as pairs of set(source),set(destination)
20100101 15:54:07< boucman> and use the second half of the pairs to build your final data structure
20100101 15:56:48< fendrin> Wouldn't that set be hugher that the current solution?
20100101 15:57:35< boucman> no, it would be about the same
20100101 15:58:16< boucman> fendrin: you need to have the targets of your pointer somewhere, either create them via malloc, or store them in a data structure somewhere, but they need to exist at some point
20100101 15:58:17< fendrin> boucman: But the same is too much, as Crab_ calculated.
20100101 15:58:46< boucman> the same as your current solution
20100101 15:59:57< Crab_> fendrin: also note that the worst case where we'll need all that data to be calculated, is reachable (if we need to travel the biggest 'distance' possible on the map, we'll need to check if it's possible to make shortcut via any available teleports)
20100101 16:00:25< fendrin> Okay, thank you for the help Crab_ and boucman. I have to head home to see my grandparents from bavaria now. I will consider your tips carefully.
20100101 16:00:40< boucman> np
20100101 16:00:45< Crab_> fendrin: I suggest that you limit the teleports somehow
20100101 16:01:13< Crab_> i.e. make them, while still useful and more powerful than now, a bit easier to deal with
20100101 16:02:03< Crab_> say, limit them to groups of 'locations which are all full-mesh interconnected'
20100101 16:03:32< Crab_> this will take, for 100x100 map,  <8mb per full mesh group (each group being a std::set<map_location>, calculated once per turn )
20100101 16:04:33< boucman> Crab_: iiuc that's what fendrin planned to do with his original idea, the structure shared by the pointer was what you call the mesh
20100101 16:04:51< boucman> except it was multi-keyed in a std::map to easily map source=>destination
20100101 16:04:59< Crab_> then they should not be calculated in get_allowed_teleports
20100101 16:05:13< boucman> :)
20100101 16:05:18< Crab_> s/calculated/stored
20100101 16:08:54< fendrin> One last word: They should be calculated and stored in gamemap.
20100101 16:09:29< boucman> fendrin: true
20100101 16:10:02< Crab_> fendrin:see http://pastebin.mozilla.org/694311
20100101 16:10:55< Crab_> where pointers in easy_access_cache_  point to sets in locations_, thus they have the same scope and are always valid.
20100101 16:11:38< Crab_> (and teleportation_map can be part of gamemap )
20100101 16:12:16< fendrin> Crab_: That looks good. I will try it when I return.
20100101 16:12:25< fendrin> Have a nice first january.
20100101 16:12:27< fendrin> bye
20100101 16:12:29< Crab_> and current 'teleport' ability is not a special case - it can be represented as a ordinary teleport_group which is usable by units with "teleport" ability
20100101 16:12:30< Crab_> bye
20100101 16:12:42< fendrin> right
20100101 16:15:05< Crab_> and get_teleport_locations can be a one-liner in this case :)
20100101 16:15:55< Crab_> which'll join all easy_access_cache_'s in all allowed teleport groups together and return a single map.
20100101 17:34:24-!- stikonas_ [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100101 17:51:02-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)]
20100101 17:51:45-!- dtiger [n=dtiger@dynamic-vpdn-93-125-62-48.telecom.by] has joined #wesnoth-dev
20100101 17:53:48-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100101 17:54:32< CIA-28> esr * r40491 /trunk/ (54 files in 3 dirs): 
20100101 17:54:32< CIA-28> Address bug #15027: UtBS scenario 7: ally name is not translatable.
20100101 17:54:32< CIA-28> Required a pofix run.
20100101 17:54:54< CIA-28> esr * r40492 /trunk/utils/pofix.py: Comment fix.
20100101 17:59:49< Ivanovic> esr: ehm, the commit sounds suspicious to me!
20100101 18:00:01-!- stikonas__ [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100101 18:00:11< Ivanovic> and there is a mistake in the commit
20100101 18:00:16< Ivanovic> 07a_Dealing_with_Dwarves.cfg
20100101 18:00:20< Ivanovic>  0                [set_variable]
20100101 18:00:30< Ivanovic> the '0' at the beginning should definitely not be there
20100101 18:00:42-!- stikonas_ [n=and@wesnoth/translator/stikonas] has quit [Read error: 54 (Connection reset by peer)]
20100101 18:01:10< esr> Ivanovic: Looking...
20100101 18:01:42< Ivanovic> and pofix has not covered all cases
20100101 18:01:48< Ivanovic> cf http://svn.gna.org/viewcvs/wesnoth/trunk/po/wesnoth-utbs/de.po?rev=40491&r1=40490&r2=40491&view=diff
20100101 18:02:07< Ivanovic> just one string of several with the *two* vars was adjusted
20100101 18:02:41< esr> Looking...
20100101 18:02:56< Ivanovic> and regarding the logics we use better change the replace string to not replace the |
20100101 18:03:10< Ivanovic> since the pipe at the end of the string might be left out in a translated version
20100101 18:03:46< Ivanovic> that is the reason why the replace instruction only finds one case
20100101 18:04:14< esr> I don't see what's wrong with that diff.
20100101 18:04:38< Ivanovic> you changeds the vars in 4 strings in the cfg files
20100101 18:04:51< Ivanovic> in the po file only one string is changed, the other three will lead to fuzzys
20100101 18:05:02< Ivanovic> because the replace expression is not as generic as it should be
20100101 18:05:28< Ivanovic> it should be  ("$dwarf_name", "$intl_dwarf_name"),       ("$troll_name", "$intl_troll_name"),
20100101 18:05:33< esr> Oh, your's saying there are cases I can't see because they're not in the diff :-/
20100101 18:05:36< Ivanovic> (as in "remove the pipes")
20100101 18:05:47< esr> OK, hold on...
20100101 18:06:35< Ivanovic> beside this there is an error in 07a_Dealing_with_Dwarves.cfg (the one with the '0' at the start of line outside of any tags), cf http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Under_the_Burning_Suns/scenarios/07a_Dealing_with_Dwarves.cfg?rev=40491&r1=40490&r2=40491&view=diff
20100101 18:07:24< esr> Got that already.  Fat-finger error...
20100101 18:07:37< esr> Running pofix now.
20100101 18:09:39< CIA-28> esr * r40493 /trunk/ (50 files in 3 dirs): Previous substitution wasn't quite general enough, and fix a finger error.
20100101 18:10:12< esr> When we ship 1.8 all the string lists in pofix should be cleared, so we're not carrying around obsolete fixes forever.
20100101 18:11:44< CIA-28> mordante * r40494 /trunk/src/ai/composite/component.hpp: Initialize all members.
20100101 18:11:45< CIA-28> mordante * r40495 /trunk/src/font.cpp: Added constructor to initialize all members.
20100101 18:11:50< CIA-28> mordante * r40496 /trunk/src/gamestatus.cpp: Initialize all members.
20100101 18:11:52< CIA-28> mordante * r40497 /trunk/src/actions.cpp: 
20100101 18:11:52< CIA-28> Pre instead of post increment a variable.
20100101 18:11:52< CIA-28> Issue found by cppcheck.
20100101 18:11:57< CIA-28> mordante * r40498 /trunk/src/ai/contexts.cpp: 
20100101 18:11:57< CIA-28> Pre instead of post increment a variable.
20100101 18:11:57< CIA-28> Issue found by cppcheck.
20100101 18:12:02< CIA-28> mordante * r40499 /trunk/src/ai/default/ai.cpp: 
20100101 18:12:02< CIA-28> Pre instead of post increment a variable.
20100101 18:12:03< CIA-28> Issue found by cppcheck.
20100101 18:12:06< CIA-28> mordante * r40500 /trunk/src/attack_prediction.cpp: 
20100101 18:12:07< CIA-28> Pre instead of post increment a variable.
20100101 18:12:09< CIA-28> Issue found by cppcheck.
20100101 18:12:11< CIA-28> mordante * r40501 /trunk/src/color_range.cpp: 
20100101 18:12:13< CIA-28> Pre instead of post increment a variable.
20100101 18:12:17< CIA-28> Issue found by cppcheck.
20100101 18:12:19< CIA-28> mordante * r40502 /trunk/src/display.cpp: 
20100101 18:12:21< CIA-28> Pre instead of post increment a variable.
20100101 18:12:23< CIA-28> Issue found by cppcheck.
20100101 18:12:25< CIA-28> mordante * r40503 /trunk/src/formula_function.cpp: 
20100101 18:12:27< CIA-28> Pre instead of post increment a variable.
20100101 18:12:29< CIA-28> Issue found by cppcheck.
20100101 18:12:31< CIA-28> mordante * r40504 /trunk/src/game_display.cpp: 
20100101 18:12:35< CIA-28> Pre instead of post increment a variable.
20100101 18:12:37< CIA-28> Issue found by cppcheck.
20100101 18:12:41< CIA-28> mordante * r40505 /trunk/src/game_events.cpp: 
20100101 18:12:43< CIA-28> Pre instead of post increment a variable.
20100101 18:12:45< CIA-28> Issue found by cppcheck.
20100101 18:12:47< CIA-28> mordante * r40506 /trunk/src/generate_report.cpp: 
20100101 18:12:49< CIA-28> Pre instead of post increment a variable.
20100101 18:12:51< CIA-28> Issue found by cppcheck.
20100101 18:12:55< CIA-28> mordante * r40507 /trunk/src/play_controller.cpp: 
20100101 18:12:57< CIA-28> Pre instead of post increment a variable.
20100101 18:12:59< CIA-28> Issue found by cppcheck.
20100101 18:13:01< CIA-28> mordante * r40508 /trunk/src/sound.cpp: 
20100101 18:13:03< CIA-28> Pre instead of post increment a variable.
20100101 18:13:05< CIA-28> Issue found by cppcheck.
20100101 18:13:09< CIA-28> mordante * r40509 /trunk/src/unit_display.cpp: 
20100101 18:13:11< CIA-28> Pre instead of post increment a variable.
20100101 18:13:15< CIA-28> Issue found by cppcheck.
20100101 18:13:17< CIA-28> mordante * r40510 /trunk/src/unit_frame.cpp: 
20100101 18:13:19< CIA-28> Pre instead of post increment a variable.
20100101 18:13:19< boucman> mordante: spaming my inbox again, I see :)
20100101 18:13:21< CIA-28> Issue found by cppcheck.
20100101 18:13:34< mordante> indeed ;-)
20100101 18:14:24< mordante> just bored while waiting for some tests...
20100101 18:14:49< mordante> but my new lobby seems to use 1/6 less cpu time
20100101 18:15:09< Ivanovic> nice improvement already
20100101 18:15:25< esr> mordante: How many GUI bugs are yoyu expecting to fix pre-1.8, roughly?
20100101 18:15:33< mordante> not only is speed but also in appearance :-)
20100101 18:17:19< mordante> esr, only the lobby speed is planned to be fixed (unless more new bugs are discovered)
20100101 18:17:54< mordante> most other items are simply waiting to be converted to gui2
20100101 18:19:39-!- deekay [n=dk@wesnoth/developer/dragonking] has joined #wesnoth-dev
20100101 18:21:16-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 54 bugs, 245 feature requests, 9 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100101 18:33:56-!- stikonas__ [n=and@ctv-79-132-179-139.vinita.lt] has quit [Read error: 54 (Connection reset by peer)]
20100101 18:33:59-!- stikonas__ [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100101 19:40:14-!- kitty_ [n=kitty@e180202025.adsl.alicedsl.de] has joined #wesnoth-dev
20100101 19:46:19-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100101 19:51:31< CIA-28> mordante * r40511 /trunk/ (4 files in 3 dirs): 
20100101 19:51:31< CIA-28> Switched back to the tiled background for gui2.
20100101 19:51:31< CIA-28> The tile background looks better and renders faster. The latter is
20100101 19:51:31< CIA-28> noticable in the new lobby, which becomes faster with this change.
20100101 19:52:34< mordante> Ivanovic, ilor, shadowmaster, espreon^
20100101 19:55:26< boucman> mordante: is it enough for 1.8 ? or is it still wip ?
20100101 19:57:21< mordante> boucman, still WIP ilor wants to diff the game and user lists instead off fully recreating them
20100101 19:58:33< mordante> the main goal was to make dialogs looking better again
20100101 19:58:43< mordante> but since profiling indicated quite a bit time in the scale routine I wanted to test the speedup as well
20100101 19:58:59< mordante> and the lobby uses 1/6 to 1/5 less CPU time in top
20100101 20:01:20-!- stikonas__ [n=and@ctv-79-132-179-139.vinita.lt] has quit [Read error: 110 (Connection timed out)]
20100101 20:26:52-!- dtiger [n=dtiger@dynamic-vpdn-93-125-62-48.telecom.by] has quit [Remote closed the connection]
20100101 20:31:14-!- wajimba [n=Andrew_A@24-158-30-63.dhcp.dlth.mn.charter.com] has joined #wesnoth-dev
20100101 20:38:09-!- dtiger [n=dtiger@dynamic-vpdn-93-125-62-48.telecom.by] has joined #wesnoth-dev
20100101 20:41:17< boucman> Crab_: around ?
20100101 20:41:35< boucman> you're probably the best to answer http://www.wesnoth.org/forum/viewtopic.php?f=10&t=28321
20100101 20:43:25-!- dtiger [n=dtiger@dynamic-vpdn-93-125-62-48.telecom.by] has quit [Read error: 104 (Connection reset by peer)]
20100101 20:53:11-!- Blueblaze [n=nick@adsl-76-202-22-180.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100101 20:58:44-!- stikonas [n=and@wesnoth/translator/stikonas] has quit ["Konversation terminated!"]
20100101 20:58:48-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100101 21:00:44< mordante> I'm off bye
20100101 21:02:51-!- stikonas_ [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100101 21:03:28-!- YogiHH [n=chatzill@d097117.adsl.hansenet.de] has joined #wesnoth-dev
20100101 21:03:39-!- mordante [n=mordante@wesnoth/developer/mordante] has quit ["Leaving"]
20100101 21:03:46< YogiHH> hello
20100101 21:04:40< boucman> hey yogi
20100101 21:04:52< Ivanovic> hi YogiHH, nice to see you around
20100101 21:08:38-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 60 (Operation timed out)]
20100101 21:10:34< Crab_> boucman: thanks
20100101 21:31:43< CIA-28> esr * r40512 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/09_Blood_is_Thicker_Than_Water.cfg: 
20100101 21:31:43< CIA-28> Address bug #15029: UtBS, scenario 9: golem Kromph doesn't die after
20100101 21:31:43< CIA-28> Eloh's death.
20100101 21:34:30-!- stikonas_ is now known as stikonas
20100101 21:37:00< CIA-28> esr * r40513 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/09_Blood_is_Thicker_Than_Water.cfg: 
20100101 21:37:01< CIA-28> However, we only want to kill off Kromph if he is under Eloh's
20100101 21:37:01< CIA-28> control. If not, he's still on side 1 and the following surrender
20100101 21:37:01< CIA-28> speech is no problem.
20100101 21:37:03-!- boucman [n=rosen@wesnoth/developer/boucman] has quit [Remote closed the connection]
20100101 21:37:17-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100101 21:52:35-!- wajimba [n=Andrew_A@24-158-30-63.dhcp.dlth.mn.charter.com] has quit ["Leaving."]
20100101 21:59:55< esr> YogiHH: Are you back to work on code again, or just looking around?
20100101 22:03:52< YogiHH> esr: looking around for the moment, but coding is on the plan :)
20100101 22:05:36< esr> YogiHH: That's good, because crab has some savefile-replated bugs assigned that whould probably be better handled by you.  Like the top one, #15013. 
20100101 22:06:01< esr> It would be good idf you could take those so he could concentrate on the AI.
20100101 22:07:20< Crab_> esr: hey, don't encourage people to steal #15013 from me :) I stole it from alink in the first place because there are ai-goto-related things that I need to check :)
20100101 22:09:17< esr> Well, I don't really care who fixes it.  But you haven't yet.  Just trying to distribute the load a little.
20100101 22:09:39< Crab_> ok, point taken :)
20100101 22:12:50< Crab_> esr: (and IMO that bug is not savegame-related)
20100101 22:15:37< Crab_> YogiHH: but, fendrin recently wanted to ask you something about persisting additional information in the savegames (he is working on expanding 'teleport' functionality)
20100101 22:19:40< Crab_> YogiHH: the question was similar to this: "if we have 1 config object, and we need to persist it in the savegame, what source file(s) we need to touch to implement the save/load ?"
20100101 22:33:37< esr> loonycyborg: ping?
20100101 22:33:50< loonycyborg> Yes?
20100101 22:35:13< esr> loonycyborg: You were diagnosing bug #14011 yesterday.  Do you plan to fix it?
20100101 22:35:32-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20100101 22:35:49-!- stikonas_ [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100101 22:36:56< loonycyborg> esr: I will try to unravel what adds that prefix to c: but I'm supposed to celebrate the New Year now :P
20100101 22:36:58-!- stikonas [n=and@wesnoth/translator/stikonas] has quit ["Konversation terminated!"]
20100101 22:37:20< esr> loonycyborg: Ah.
20100101 22:39:50< loonycyborg> I can also help with the upgrade to boost.filesystem eventually since I have some experience with it.
20100101 22:44:34-!- kitty_ [n=kitty@e180202025.adsl.alicedsl.de] has quit [Read error: 110 (Connection timed out)]
20100101 22:50:01-!- stikonas__ [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100101 22:50:25-!- stikonas_ [n=and@wesnoth/translator/stikonas] has quit [Read error: 54 (Connection reset by peer)]
20100101 22:54:00< Crab_> boucman: http://www.wesnoth.org/forum/viewtopic.php?f=10&t=28321&p=401198#p401198
20100101 22:54:57-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100101 23:13:54< boucman> Crab_: checking...
20100101 23:14:52-!- yann [n=dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has quit [Remote closed the connection]
20100101 23:17:10< boucman> Crab_: nice post, very pedagogical
20100101 23:18:06-!- Blarumyrran [n=Blarumyr@81-20-159-197.levira.ee] has joined #wesnoth-dev
20100101 23:18:29< Crab_> still, fai is not very easy to use in this case.. note that I needed to evaluate next_hop(me.loc,loc(1,1) two times (plus one extra time to deal with unit_at(null) bug)
20100101 23:19:25< Crab_> boucman: and having a helper function like move_closer_to(A,B) would clean things up a lot...
20100101 23:20:05< boucman> Crab_: EasyCoding ?
20100101 23:20:27< Crab_> boucman: yes, the 'helper function' stuff can be handled there
20100101 23:21:10< Crab_> but the first one (reevaluation problem) is more a fai design issue. note that c++ code avoids the reevaluation by using " move_ = find_the_move(); " - caching the optimal move_ locally in the candidate action
20100101 23:21:55< Crab_> and, note that c++ code can do stuff like "move_ = check_move_action(from,to,false);" to check if the movement is possible
20100101 23:22:28< Crab_> and, in fai, I had to write a buggy&incomplete&duplicate function to check if the move is possible
20100101 23:22:37< Crab_> [ if(unit_at(next_hop(me.loc,loc(1,1)))=null    ]
20100101 23:25:06-!- stikonas__ is now known as stikonas
20100101 23:25:36< boucman> Crab_: http://www.wesnoth.org/forum/viewtopic.php?p=401206#p401206
20100101 23:33:19-!- boucman [n=rosen@wesnoth/developer/boucman] has quit [Remote closed the connection]
20100101 23:34:03-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100101 23:40:41< Crab_> boucman: yes, answered. I expected to tell those things later, when actual 1.9 development starts (I'll expand EasyCoding tasks and for-future-gsocers ideas then), but it's ok to tell it now, as well )
20100101 23:40:56< boucman> ok
20100101 23:47:34-!- Nobun [n=Admin@95.75.155.66] has joined #wesnoth-dev
20100101 23:48:07-!- Nobun [n=Admin@95.75.155.66] has left #wesnoth-dev []
20100101 23:55:52-!- boucman [n=rosen@wesnoth/developer/boucman] has quit ["Leaving."]
--- Log closed Sat Jan 02 00:00:53 2010