--- Log opened Mon Oct 05 00:00:19 2009
20091005 00:01:59< Ivanovic> might be that by now passing --dummy-locales is already enough
20091005 00:02:56< loonycyborg> It was once true, but not anymore :P
20091005 00:03:09-!- Bellerophon_true [n=chatzill@BSN-142-95-32.dial-up.dsl.siol.net] has quit [Read error: 110 (Connection timed out)]
20091005 00:04:02 * loonycyborg wonders whether there is a way to avoid dummy locales altogether
20091005 00:05:19-!- Crab_ [i=crab@wesnoth/developer/crab] has quit ["Leaving."]
20091005 00:12:33-!- Appleman1234 [n=Appleman@131.181.102.205] has joined #wesnoth-dev
20091005 00:21:01-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has quit [Remote closed the connection]
20091005 00:32:26-!- Nayela [n=Nayela@cpc3-lich6-0-0-cust673.brhm.cable.ntl.com] has quit ["Leaving"]
20091005 00:36:01-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 00:36:05< Zarel> Hey, guys!
20091005 00:36:08< Zarel> Quick survey!
20091005 00:37:24< Zarel> Are bugfix releases of Wesnoth intercompatible? i.e. Can 1.6.5 play a networked game for 1.6.4?
20091005 00:37:28< Zarel> s/for/with/
20091005 00:48:42-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 00:53:41-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 01:04:23< Ivanovic> Zarel: all mentioned in the release notes, have a look at http://www.wesnoth.org/forum/viewtopic.php?f=5&t=27026
20091005 01:05:13< Zarel> Okay.
20091005 01:05:35< Zarel> So do you always remain fully compatible between bugfix releases?
20091005 01:05:45< Ivanovic> in a stable stream: yeah
20091005 01:06:59< Zarel> Okay, thanks.
20091005 01:07:25< Zarel> Oh, by the way, you forgot to update the changelog before tagging 1.6.5: http://svn.gna.org/viewcvs/wesnoth/tags/1.6.5/changelog?rev=38453&view=download
20091005 01:07:27< Zarel> "Version 1.6.4+svn:"
20091005 01:07:43< Ivanovic> yeah, and?
20091005 01:07:49< Ivanovic> this is just a number that was not changed
20091005 01:08:05< Ivanovic> and because of this i will definitely not get another one out
20091005 01:08:06< Ivanovic> ;)
20091005 01:09:17< Ivanovic> anyway, time for me to head off to bed, n8#
20091005 01:09:32< Zarel> I know; that was just a "How many times has this been pointed out?" kinda thing.
20091005 01:09:49< Zarel> Lotsa Germans on OSS game development.
20091005 01:30:29-!- gtsteel [n=gtsteel@CPE001346a3fd7f-CM00e06fb8be94.cpe.net.cable.rogers.com] has joined #wesnoth-dev
20091005 01:53:50-!- PK5 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has joined #wesnoth-dev
20091005 02:13:48-!- esr [n=chatzill@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Remote closed the connection]
20091005 02:17:43-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"]
20091005 02:18:11-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20091005 02:25:18-!- Sirp [n=user@wesnoth/developer/dave] has joined #wesnoth-dev
20091005 02:25:28< Sirp> Hello.
20091005 02:25:48< Espreon> Hello Sirp.
20091005 02:26:56< Aethaeryn> hi Sirp 
20091005 02:35:50-!- esr [n=chatzill@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20091005 02:38:57-!- PK5 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has quit ["Java user signed off"]
20091005 02:50:25< shadowmaster> Espreon, mordante: I'd honestly appreciate not to hear complaints about an unfinished product. I haven't released any version of IftU from the SVN trunk, which means it's not bug-report-ready
20091005 02:51:05< shadowmaster> of course I'm worried about things that are way more important than the menu entry.
20091005 02:51:27< Espreon> I wasn't complaining.
20091005 02:52:28-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit [Read error: 110 (Connection timed out)]
20091005 02:53:27-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20091005 02:54:22-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20091005 02:57:40< CIA-62> jetryl * r39111 /trunk/data/core/images/units/drakes/warrior-melee-6.png: Minor tweak to the shadow opacity on one drake frame.
20091005 03:11:51-!- shikadibot [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has quit ["manual override"]
20091005 03:12:12-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20091005 03:12:14-!- shikadibot [n=shikadi@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev
20091005 03:19:47< shadowmaster> "The map cannot be <insert garbage character> here"  O O  uh oh, sounds like it's gonna die.
20091005 03:31:28-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 03:33:39< Aethaeryn> Zarel: hey
20091005 03:33:48< Zarel> Ello.
20091005 03:34:58< meowreka> hello everyone in the world
20091005 03:36:40< shadowmaster> esr: around?
20091005 03:39:02< meowreka> what
20091005 03:39:22< shadowmaster> meowreka: um, I am asking whether esr is around?
20091005 03:40:02-!- DDR [n=chatzill@66.183.125.196] has quit ["Time flies like an arrow. Fruit files like a bannana."]
20091005 03:40:22-!- DDR [n=chatzill@66.183.125.196] has joined #wesnoth-dev
20091005 03:42:37< Zarel> I don't think I've ever seen esr around.
20091005 03:42:53< Zarel> Which is a shame, since I remember there was something I'm supposed to ask him the next time he is.
20091005 03:43:03< shadowmaster> Zarel: grep the logs for esr
20091005 03:43:08-!- DDR is now known as I
20091005 03:43:12< shadowmaster> you will notice that he has been around. sometimes ;)
20091005 03:43:37-!- I is now known as Guest92844
20091005 03:43:52-!- Guest92844 is now known as DDR
20091005 03:44:30< esr> shadowmaster: Yes, but not very available.  gpsd had a hosting-site disaster; I'm preoccupied with recovering.
20091005 03:44:42< shadowmaster> I read about that.
20091005 03:45:12< shadowmaster> esr: when you get some time, you may want to check http://www.wesnoth.org/forum/viewtopic.php?p=388101#p388101 . The artist redoing the portraits for THoT is back.
20091005 03:45:31< esr> I shall.
20091005 03:45:53< esr> At the moment, the need for the last few portaits in THoT is greater.
20091005 03:46:14< esr> Er, I mean it's greater in DM.
20091005 03:46:34< crimson_penguin> shadowmaster: you should ask Jetrel for an ssh account for testing
20091005 03:47:13< shadowmaster> I'm not sure how that'll be very productive, crimson_penguin . MacOS X smells like an alien platform to me.
20091005 03:47:25< shadowmaster> even with the Unixish kernel and all that.
20091005 03:47:40< crimson_penguin> I really think it would be very very similar
20091005 03:47:46< crimson_penguin> I mean, what're you gonna do?
20091005 03:47:59< shadowmaster> I'm thinking :P
20091005 03:48:13< crimson_penguin> sure, your home folder would be in /Users/username/, but other than that...
20091005 03:48:39< shadowmaster> I don't think it's as easy as ./configure && make  to build software there ?
20091005 03:50:26-!- Kenpachi [n=chatzill@121.214.223.209] has quit ["ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]"]
20091005 03:51:08< crimson_penguin> shadowmaster: well, I THINK it is, I may be relying on some fink stuff for that... but I don't think I am
20091005 04:00:31< gtsteel> CMake can work out of the box on OSX
20091005 04:02:15< shadowmaster> I don't use CMake.
20091005 04:02:27< shadowmaster> I feel more comfortable with autotools (don't look at me like that)
20091005 04:09:32< noy> Umm we might need a discussion about our current server situation
20091005 04:09:45< meowreka> it's dead
20091005 04:10:05< meowreka> oh hi noy
20091005 04:10:16< noy> meowreka: really?
20091005 04:10:21< noy> OMG
20091005 04:10:30< meowreka> lol
20091005 04:10:40< meowreka> I have to fix my multiplayer name
20091005 04:11:07< shadowmaster> noy: um, as in?
20091005 04:11:19< meowreka> the official server is dead
20091005 04:11:30< meowreka> everyone's in the alternate server
20091005 04:11:35 * shadowmaster checks
20091005 04:11:54< noy> as its been crashing quite a bit
20091005 04:12:12< shadowmaster> um, I'm in the SVN server.
20091005 04:13:24< shadowmaster> the 1.6 server seems to be running
20091005 04:14:32< shadowmaster> I guess I came too late for the party.
20091005 04:20:13-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 98 bugs, 237 feature requests, 10 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20091005 04:27:44-!- gtsteel [n=gtsteel@CPE001346a3fd7f-CM00e06fb8be94.cpe.net.cable.rogers.com] has quit ["leaving"]
20091005 04:28:43-!- Kleptomane [n=Kleptoma@S01060019e3d6aaa1.cg.shawcable.net] has joined #wesnoth-dev
20091005 04:33:38< shadowmaster> why do the posting guidelines not mention anything about posting meaningless posts?
20091005 04:34:01< shadowmaster> ah wait, it is because it's too... obvious... :P
20091005 04:35:49-!- PK3 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has joined #wesnoth-dev
20091005 04:36:42-!- Appleman1234 [n=Appleman@131.181.102.205] has quit [Read error: 110 (Connection timed out)]
20091005 04:37:48< meowreka> shadowmaster you are quite the multitasker
20091005 04:45:27< PK3> its because he's actually more than one person
20091005 04:45:34< PK3> that's my secret to getting so much done
20091005 04:45:51< PK3> crap, its not a secret anymore.
20091005 04:58:17< meowreka> yes it is
20091005 04:58:33-!- Ivanovic_ [n=ivanovic@dtmd-4db22ace.pool.mediaWays.net] has joined #wesnoth-dev
20091005 05:04:18< crimson_penguin> no, he's only one person, but he's master of the shadows; gets them to do his work for him ;)
20091005 05:04:53< shadowmaster> last time I checked I still had just one shadow following me.
20091005 05:05:10< crimson_penguin> well can you at least get that one to do your bidding?
20091005 05:08:08-!- meowreka [n=Administ@c-69-242-154-116.hsd1.mo.comcast.net] has left #wesnoth-dev []
20091005 05:08:49< shadowmaster> nope.
20091005 05:09:09-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 05:09:49< shadowmaster> the "master" part is misleading. It was supposed to be "shadowm" first.
20091005 05:11:13< crimson_penguin> well what's the m for then? I've heard of name truncating, but expanding...?
20091005 05:12:55< shadowmaster> the 'm' wasn't supposed to mean anything.
20091005 05:13:36< shadowmaster> we'll just say that the 'aster' addition was a bad idea
20091005 05:14:06-!- Ivanovic [n=ivanovic@wesnoth/developer/ivanovic] has quit [Read error: 113 (No route to host)]
20091005 05:14:31-!- Ivanovic_ is now known as Ivanovic
20091005 05:14:39-!- Appleman1234 [n=Appleman@131.181.102.205] has joined #wesnoth-dev
20091005 05:23:01-!- ardesh [n=ardesh@port-92-206-40-93.dynamic.qsc.de] has joined #wesnoth-dev
20091005 05:40:11< crimson_penguin> heh, ok
20091005 05:59:04-!- Appleman1234 [n=Appleman@131.181.102.205] has quit [Read error: 104 (Connection reset by peer)]
20091005 05:59:22-!- Appleman1234 [n=Appleman@131.181.102.205] has joined #wesnoth-dev
20091005 06:30:20-!- PK3 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has quit [Read error: 110 (Connection timed out)]
20091005 06:41:19< CIA-62> silene * r39112 /trunk/src/display.cpp: Reverted part of 39019. As pointed by alink, tooltips do actually care about the area size.
20091005 06:53:20-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has quit ["meh"]
20091005 07:00:12-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 07:20:55-!- Sirp [n=user@wesnoth/developer/dave] has quit ["leaving"]
20091005 07:26:46-!- ilor [n=user@wesnoth/developer/ilor] has quit []
20091005 07:30:29-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20091005 08:12:48-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20091005 09:08:54-!- DDR_ [n=chatzill@66.183.125.196] has quit [Read error: 60 (Operation timed out)]
20091005 09:15:00-!- Kleptomane [n=Kleptoma@S01060019e3d6aaa1.cg.shawcable.net] has quit ["brb, im in ur mapz, stealing ur villages..."]
20091005 09:19:03-!- DDR [n=chatzill@66.183.125.196] has quit [Read error: 110 (Connection timed out)]
20091005 09:40:11-!- Blueblaze [n=nick@adsl-99-171-161-30.dsl.hstntx.sbcglobal.net] has quit [Remote closed the connection]
20091005 09:46:54-!- stikonas [n=and@bcm-131-111-216-119.girton.cam.ac.uk] has joined #wesnoth-dev
20091005 09:50:55-!- fendrin [n=fabi@wesnoth/developer/fendrin] has quit [Remote closed the connection]
20091005 10:03:24-!- loonybot [n=loonybot@79.139.139.50] has joined #wesnoth-dev
20091005 10:04:11-!- loonycyborg [n=sergey@79.139.139.50] has joined #wesnoth-dev
20091005 10:14:17-!- SonIcco [n=SonIcco@217.81.40.132] has joined #wesnoth-dev
20091005 10:25:59-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 10:26:58-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 10:29:25-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit [Client Quit]
20091005 10:30:20-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20091005 10:31:15-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20091005 10:44:58-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20091005 11:03:39< Ivanovic> moin
20091005 11:04:41-!- isaac_ [n=isaac@14.Red-88-26-177.staticIP.rima-tde.net] has quit [Remote closed the connection]
20091005 11:13:01< Ivanovic> Soliton: i commented updating the wescamp repo out from the g.w.o update script
20091005 11:13:28< Ivanovic> since berlios is dead (atm only?) so that there won't be updates anyway
20091005 11:13:35< Ivanovic> no idea if/when berlios will be back
20091005 11:14:52 * Soliton nods.
20091005 11:33:12-!- isaac [n=isaac@debian/developer/isaac] has joined #wesnoth-dev
20091005 11:44:39< loonycyborg> http://wesnoth.pastebin.com/m2c84ba39 <- so why does wesnoth use dummy locales? LANGUAGE env variable seems to work as well :P
20091005 11:53:33< Soliton> what about latin?
20091005 11:54:02< Soliton> or just languages you don't have the locale installed in your system.
20091005 11:57:59< loonycyborg> I don't have french and german locales installed.
20091005 11:58:27< loonycyborg> gettext is directly affected by LANGUAGE, not through locale.
20091005 11:59:14< loonycyborg> Just setting LANGUAGE can be used as fallback if setting locale fails,
20091005 11:59:29< Rhonda> loonycyborg: my wesnoth doesn't use dummy locales.
20091005 12:00:02< loonycyborg> Rhonda: Can you set language to latin? :P
20091005 12:00:29< Rhonda> What should that do?
20091005 12:01:29< loonycyborg> Make text in wesnoth appear in latin obviously..
20091005 12:01:42< Rhonda> I don't speak latin, why would I do that?
20091005 12:02:14< loonycyborg> Why NOT? :P
20091005 12:02:26< Rhonda> Besides, your python snippet, what's that got to do with wesnoth and dummy locales? I don't get it.
20091005 12:03:52< loonycyborg> Dummy locales is a workaround to allow one to set language to one that is belongs to a non-installed locale, or a language without official locale such as latin.
20091005 12:04:25< Rhonda> Yes. But you do that within python, not within wesnoth.
20091005 12:04:41< Rhonda> And wesnoth just has a compile-time option to enable that, IIRC it's even switched *off* by default.
20091005 12:04:42< loonycyborg> That's just a demonstation.
20091005 12:05:16< Rhonda> Anyway, that was a request by some people that didn't know (or care) to create the system locales they wanted to use in wesnoth.
20091005 12:05:28< loonycyborg> It hopes to demonstrate that it's possible to avoid having to have a compile option.
20091005 12:06:13< Rhonda> I think the compile option is what the hack within python does.
20091005 12:06:27< Rhonda> You either want to have that hack enabled or not.
20091005 12:06:29-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 12:06:34< loonycyborg> No it isn't.
20091005 12:06:53< loonycyborg> Dummy locales have entire locales created with localedef.
20091005 12:07:15< loonycyborg> And the above snippet solution avoids that.
20091005 12:08:19< Rhonda> Which above snippet solution?
20091005 12:08:35< Rhonda> I just see python tweaks
20091005 12:09:22< loonycyborg> The solution is basically to set LANGUAGE env variable instead of creating dummy locales with localedef.
20091005 12:09:33< Rhonda> oh
20091005 12:09:35< Rhonda> right
20091005 12:09:41< Rhonda> :~$ LANGUAGE=fr gettext -d mutt "Login failed."; echo
20091005 12:09:42< Rhonda> La connexion a échoué.
20091005 12:09:48< Rhonda> Now I see what you aim for.
20091005 12:10:08< Rhonda> LC_ALL=fr doesn't work because the locale isn't created.
20091005 12:10:49< Soliton> latin works as well for me.
20091005 12:11:43< Rhonda> :~$ LANGUAGE=zh_CN gettext -d mutt "Login failed."; echo
20091005 12:11:43< Rhonda> 登入失败。
20091005 12:11:50-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 12:11:51< Rhonda> sweet :D
20091005 12:13:37< Soliton> so does gettext has the locale definitions built-in or how would it know about its rules?
20091005 12:18:57< loonycyborg> http://www.gnu.org/software/gettext/manual/gettext.html#gettext-grok <- anyway, that's where did I found out about LANGUAGE var.
20091005 12:20:07< Rhonda> The question is wether that LANGUAGE approach would work crossplatform.
20091005 12:21:28< loonycyborg> It would probably work for GNU gettext and mac and windows already don't use dummy locales in favour of similar environment tweaks.
20091005 12:22:07< Rhonda> loonycyborg: But from reading that I don't really understand why changing LANGUAGE behaves so much differently to changing LC_ALL
20091005 12:24:15< loonycyborg> Neither do I. Probably source-code reading is in order :P
20091005 12:25:22< loonycyborg> It also says that ' This documentation section is outdated and needs to be revised'
20091005 12:29:06< Ivanovic> probably because LC_ALL also effects dates and whatever
20091005 12:29:16< Ivanovic> and those don't have defitions eg for latin
20091005 12:29:48< Ivanovic> so just "enforcing" the language without setting anything else gives the result loonycyborg observed
20091005 12:29:50< Ivanovic> good find!
20091005 12:35:49< Rhonda> hmm
20091005 12:35:53< Rhonda> just seting LC_MESSAGES is enough, too
20091005 12:36:40< Rhonda> :~$ LC_MESSAGES=eo gettext -d mutt "Login failed."; echo
20091005 12:36:40< Rhonda> Saluto malsukcesis.
20091005 12:47:02-!- fendrin [n=fabi@88-134-102-207-dynip.superkabel.de] has joined #wesnoth-dev
20091005 12:55:26< Ivanovic> Soliton: berlios seems to be up again, so i reactivated the wescamp update part in the g.w.o update script
20091005 13:09:15-!- SonIcco [n=SonIcco@217.81.40.132] has quit [Remote closed the connection]
20091005 13:11:40-!- Crab_ [i=crab@wesnoth/developer/crab] has joined #wesnoth-dev
20091005 13:19:27-!- Appleman1234 [n=Appleman@131.181.102.205] has quit [Read error: 110 (Connection timed out)]
20091005 13:20:38-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev
20091005 14:50:03-!- Bellerophon_true [n=chatzill@89.142.95.32] has joined #wesnoth-dev
20091005 14:58:21-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"]
20091005 15:59:17< Soliton> weird, i get segfaults when trying to load a saves/replays in trunk. when not running inside gdb it just looks like an ordinary quit though, no errors.
20091005 16:27:15< CIA-62> soliton * r39113 /branches/1.6/src/server/server.cpp: send a server message when clients report oos
20091005 16:35:47-!- ardesh_ [n=ardesh@port-92-206-52-117.dynamic.qsc.de] has joined #wesnoth-dev
20091005 16:40:22-!- ardesh [n=ardesh@port-92-206-40-93.dynamic.qsc.de] has quit [Read error: 145 (Connection timed out)]
20091005 16:45:43-!- fendrin [n=fabi@wesnoth/developer/fendrin] has quit [Remote closed the connection]
20091005 16:54:52-!- Crab_ [i=crab@wesnoth/developer/crab] has quit ["Leaving."]
20091005 16:56:55-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20091005 17:01:32-!- stikonas [n=and@131.111.216.119] has joined #wesnoth-dev
20091005 17:13:57-!- alink [n=alink@wesnoth/developer/alink] has joined #wesnoth-dev
20091005 17:14:23< alink> wesbot: seen Crab_
20091005 17:14:24< wesbot> alink: The person with the nick Crab_ last spoke 2d 19h ago.  19m 32s ago they left with the message: "Leaving."
20091005 17:15:04< alink> wesbot: seen suokko
20091005 17:15:05< wesbot> alink: Sorry, I don't know of suokko.
20091005 17:22:39-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20091005 17:24:31-!- stikonas [n=and@bcm-131-111-216-119.girton.cam.ac.uk] has joined #wesnoth-dev
20091005 17:38:34-!- Sirp [n=user@wesnoth/developer/dave] has joined #wesnoth-dev
20091005 17:54:27< CIA-62> alink * r39114 /trunk/src/ai/default/ (ai.hpp move.cpp): 
20091005 17:54:27< CIA-62> Optimize default AI targeting (prune most of targets)
20091005 17:54:27< CIA-62> No change in the AI behavior and with its current state, it seems that we usually
20091005 17:54:27< CIA-62> only need to consider the most promising target (sometimes few more, but not the majority of them)
20091005 17:56:38< alink> actually, this optimization^ is maybe less important in maze map. But even the (improbable) worst case scenario "the least interesting target is the only one reachable" should have around the same perf than before
20091005 17:56:39-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20091005 17:56:47< silene> hi
20091005 17:56:52< alink> hello silene
20091005 17:58:15< silene> alink: thanks for spotting the issue with the tooltip; not sure why i didn't notice it (the worst part is that i think i already did that mistake once before, there must be something about this piece of code that annoys me)
20091005 17:58:21-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20091005 17:59:39< alink> silene: or maybe because tooltip are not a "visible" bug, so it often bite people.
20091005 18:00:54-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 18:00:59 * alink considers having a debug-mode making tooltip area visible
20091005 18:01:44 * alink likes debug-features visually showing how the code works :)
20091005 18:04:56-!- ilor [n=user@aun232.neoplus.adsl.tpnet.pl] has joined #wesnoth-dev
20091005 18:07:28< alink> Crab_ I finally did the AI target sorting/pruning ^. The current AI flaws make it very useful (it skip a lot of A*), but I realized that it could also help even with future smarter rating system
20091005 18:11:05< alink> Crab_ btw in ai/contexts.cpp there is a wml_filter running on a lot of hexes and I believe it's a bottleneck (wml_filter are slow)
20091005 18:12:22< alink> my current main problem is that, from my test, it seems to run even when the scenario doesn't have an AI "avoid" parameter, but all that code is not clear to me yet
20091005 18:14:07< alink> if needed (and I suppose that it the case when "avoid" is defined), it could maybe use some caching. I think we often test the same hex several times
20091005 18:18:16< alink> the other possible ways are optimizing WML filter (do we still parse WML there? or they are already stored in a c++ efficient format?) or provide a global caching system, at least for simpler case (eg terrain filter, cache result in map, and flush them when map change)
20091005 18:20:33< alink> no we seems to still parse WML terrain filter for each match, which is of course stupid when we test a lot of hexes against the same filter
20091005 18:22:21-!- Sirp [n=user@wesnoth/developer/dave] has quit [Read error: 60 (Operation timed out)]
20091005 18:24:00< alink> mmh we seem to have  already a function to filter the whole map, but that could often be overkill too
20091005 18:25:55< alink> I really like the idea of storing filter in a more efficient format than raw WML, it should allow all kind of optimization for this slow feature
20091005 18:37:41-!- Nayela [n=Nayela@cpc3-lich6-0-0-cust673.brhm.cable.ntl.com] has joined #wesnoth-dev
20091005 18:46:23< silene> alink: no, this is not parsing; at last not in the usual sense (as in done by serialization/parser.cpp), wml is already stored in a config object at that time
20091005 18:51:04-!- __rtfb [n=read-the@78-56-0-35.static.zebra.lt] has joined #wesnoth-dev
20091005 18:51:55-!- _rtfb [n=read-the@78-56-0-35.static.zebra.lt] has quit [Read error: 60 (Operation timed out)]
20091005 18:52:38-!- Bellerophon_true [n=chatzill@89.142.95.32] has quit ["ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]"]
20091005 18:56:26-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 19:01:26< alink> yes sorry, by "parsing" i mean, working with the config object and all its key/tag searches etc
20091005 19:01:40< alink> not really "parsing" indeed
20091005 19:02:06< alink> well we still compare strings token
20091005 19:03:52< alink> an efficient object would be to store all the usual filter parameters in specialized c++ structure
20091005 19:06:22< silene> internalizing key/tag strings in config objects would be a big boost in performance; i'm not sure having a specialized structure would be much of an improvement upon that
20091005 19:08:51< alink> well, if we use the same filter on a lot of objects, each time we search in the config object if it has such attribute or child, unless config are really fast, a simple bool flag will be lot faster
20091005 19:10:03< silene> yes, that's point of internalizing strings; it makes string comparison as fast as integer comparison
20091005 19:10:24< silene> (or boolean comparison)
20091005 19:10:43< alink> ah ok, i see now what you mean by "internalizing strings", indeed this part would be solved
20091005 19:11:22-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20091005 19:12:43< alink> i still see in filter code a lot of object construction and stl operation on the content of the filter only, but i need to check more what can be done the first time only
20091005 19:16:24< alink> plus, having a filter object, we would have a simple logical place to cache stuff. { create filter, do a bunch of matches(using its cache), auto-destroy the filter and its cache}
20091005 19:16:59-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20091005 19:18:06< alink> well, TBH the caller code should avoid test-match the same stuff, but that often means that it must use its own caching system each time
20091005 19:20:23-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 19:21:27< silene> alink: you can hardly do otherwise: only the caller code knows when the cache would become invalid
20091005 19:22:58< alink> indeed that's why i used "{create filter} ", the caller code should not use obsolete filter object
20091005 19:23:42< alink> alternatively the filter object could have a flush_cache() function
20091005 19:24:19< alink> I guess it depends how often we need the same filter and how often we test the same stuff with the same filter
20091005 19:28:52< alink> in short, only use filter object locally, as we do for a temporary STL structure used by the caller code
20091005 19:32:38< alink> anyway, caching filter result is a second step, if filter "parsing" is optimized enough, then it may be fast enough compared to a cache search in most (simple) filter case
20091005 19:39:52-!- boucman [n=rosen@wesnoth/developer/boucman] has left #wesnoth-dev []
20091005 19:39:56-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 19:40:00-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20091005 19:40:04< boucman> oops
20091005 19:41:26-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 19:42:49-!- __rtfb is now known as rtfb
20091005 19:43:49< alink> to illustrate my point, an example of filter "parsing" easily optimized in a specialized structure:
20091005 19:44:00< alink> std::string adj_dirs = (*i).has_attribute("adjacent") ? (*i)["adjacent"] : "n,ne,se,s,sw,nw";
20091005 19:44:59< alink> just parse this once and store these directions in a vector, maybe even in a 6-bit object (a char)
20091005 19:46:04< alink> mmh, maybe it's a bad example, this code seems *very* inefficient
20091005 19:46:12-!- kitty [n=kitty@e180202210.adsl.alicedsl.de] has joined #wesnoth-dev
20091005 19:48:32< alink> lol there is even a line doing nothing :   std::string adj_dirs = (*i).has_attribute("adjacent") ? (*i)["adjacent"] : "n,ne,se,s,sw,nw"; and it doesn't use adj_dirs after that
20091005 19:49:50< CIA-62> alink * r39115 /trunk/src/terrain_filter.cpp: remove dead code
20091005 19:52:35< alink> <alink> to illustrate my point, an example of filter "parsing" easily optimized.  <-- so, in fact, the "easy opimization" was to simply remove that line :-)
20091005 20:00:51-!- Bellerophon_true [n=chatzill@89.142.149.252] has joined #wesnoth-dev
20091005 20:04:32-!- mordante [n=mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20091005 20:04:44< mordante> servus
20091005 20:05:12-!- kitty__ [n=kitty@e180197226.adsl.alicedsl.de] has joined #wesnoth-dev
20091005 20:05:47< mordante> AI0867, r39108 the second translation is not finished
20091005 20:08:46-!- kitty [n=kitty@e180202210.adsl.alicedsl.de] has quit [Read error: 60 (Operation timed out)]
20091005 20:08:46-!- kitty__ is now known as kitty
20091005 20:16:12-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 20:17:36< silene> mordante: it may have been on purpose, since it was explicitly disabled
20091005 20:17:52-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has quit [Read error: 113 (No route to host)]
20091005 20:19:23< mordante> silene, I noticed that as well but it looks horrible now, so I wonder whether went accidentally wrong
20091005 20:23:40-!- mjs-de [n=mjs-de@wh.uni-dortmund.de] has joined #wesnoth-dev
20091005 20:27:16< mordante> grzywacz, can you test whether bug #13764 has been resolved?
20091005 20:41:00-!- fendrin [n=fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20091005 20:46:17-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20091005 20:46:27-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20091005 20:51:50-!- DDR [n=chatzill@jabba.tru.ca] has joined #wesnoth-dev
20091005 20:54:25-!- SonIcco [n=SonIcco@pD951071C.dip0.t-ipconnect.de] has joined #wesnoth-dev
20091005 20:58:57-!- YogiHH [n=chatzill@d155175.adsl.hansenet.de] has joined #wesnoth-dev
20091005 21:00:58< grzywacz> wesbot, bug #13764
20091005 21:00:59< wesbot> Bug #13764  Assigned to: Mark de Wever <mordante>  Status: Ready For Test  Priority: 5 - Normal
20091005 21:01:02< wesbot> Summary: A "The file you have tried to load is corrupt" dialog that's impossible to close
20091005 21:01:05< wesbot> Original submission: After I failed a TSG scenario a dialog with the message m
20091005 21:01:08< wesbot> entioned in summary appeared but it's impossible to close (i.e. reappears just a
20091005 21:01:11< wesbot> URL: https://gna.org/bugs/?13764
20091005 21:12:35-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20091005 21:19:13< mordante> Zarel, FYI we had some incompatibilities between 1.4.x stable versions due to some bugs, but in general stable releases are and should be compatible
20091005 21:20:31< Zarel> Can you point to any rationale on that? One of my developers is trying to break MP compatibility for Warzone 2.2.4, and I need backup as to why that's a bad idea. :/
20091005 21:21:35< mordante> Zarel, the name generator pulled X random numbers from the random generator, depending on the translation the number X could be different
20091005 21:22:05< mordante> this caused the random generators to get out of sync and caused an OOS later on
20091005 21:22:08< Zarel> Oh, I mean, rationale for why stable branches shouldn't break MP compatibility.
20091005 21:23:01< mordante> the simple rationale is, it's called stable for a reason ;-)
20091005 21:23:07< mordante> but that's a bit simple
20091005 21:23:19< Zarel> If only that were enough. :(
20091005 21:23:27 * mordante types
20091005 21:23:44-!- PK6 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has joined #wesnoth-dev
20091005 21:24:20< mordante> IMO an MP protocol is an API and in general when you start to modify an API you should bump the minor or major version number
20091005 21:24:49-!- PK4 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has joined #wesnoth-dev
20091005 21:25:10< mordante> in general when updating to a new minor or major version number a user expects problems, when updating to a new patch they don't expect problems only bug fixes
20091005 21:25:15-!- PK6 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has quit [Client Quit]
20091005 21:25:39-!- PK4 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has quit [Read error: 104 (Connection reset by peer)]
20091005 21:26:08< mordante> (at least for OOS projects I expect that, commercial software often uses version numbers as marketing tool so no predictions there ;-) )
20091005 21:26:24< mordante> but why does your developer think it's a good idea?
20091005 21:28:45-!- Bellerophon_true [n=chatzill@89.142.149.252] has quit ["ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]"]
20091005 21:29:41< Zarel> "It's only a few lines of code!"
20091005 21:31:18< Zarel> https://mail.gna.org/public/warzone-dev/2009-10/msg00021.html
20091005 21:34:11< Zarel> :( The other developers don't even see that much of a problem with it.
20091005 21:35:07< mordante> :-(
20091005 21:35:46< mordante> it's not only net compatibility but compatibility in general 
20091005 21:36:01< mordante> stable is bugfix only 
20091005 21:36:08< mordante> as it should be (tm)
20091005 21:36:34-!- PK8 [n=pk@r74-192-44-206.vctrcmta01.vctatx.tl.dh.suddenlink.net] has joined #wesnoth-dev
20091005 21:37:21< mordante> or you need to state your policy that every patch release is incompatible, how often do you release patch versions
20091005 21:37:50< Zarel> Not that often. Once every few weeks?
20091005 21:37:55< Zarel> This is the first time we've had an incompatible patch release in ages.
20091005 21:38:11< Zarel> Heck, I thought it was policy.
20091005 21:38:59< CIA-62> silene * r39116 /trunk/src/map_label.cpp: Simplified map_labels::add_label.
20091005 21:39:00< mordante> I consider every few weeks quite often (not a bad thing)
20091005 21:39:03< CIA-62> silene * r39117 /trunk/src/ (map_label.cpp map_label.hpp): Removed unused field map_labels::label_cache_.
20091005 21:39:06< CIA-62> silene * r39118 /trunk/src/ (map_label.cpp map_label.hpp): Fixed constness in map_labels.
20091005 21:39:47-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #Wesnoth-dev
20091005 21:41:00< Zarel> Oh, Aethaeryn, you and your capitalization.
20091005 21:41:15< mordante> Zarel, maybe make it a policy and go for version 2.3.0 (or 2.4.0 if you want to use the odd/stable numbers)
20091005 21:41:47< Zarel> That's what I've been trying for.
20091005 21:41:59< Aethaeryn> Zarel: I type /wesnoth to join all 6 related channels I'm in
20091005 21:42:09< Aethaeryn> Might as well have the "proper" names. :P
20091005 21:42:14< Aethaeryn> It's just a script
20091005 21:42:40< Zarel> I wonder why the capitalization is even sent over the IRC protocol.
20091005 21:42:56< Zarel> I could troll people just by joining #WeSnOtH-dEv
20091005 21:45:00< Aethaeryn> Yes.
20091005 21:45:13< Aethaeryn> even better, join #weSNOTh-dev
20091005 21:45:20< Zarel> lol
20091005 21:45:57< Zarel> brb trolling
20091005 21:45:59-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has left #wesnoth-dev ["Leaving"]
20091005 21:46:05-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #weSNOTh-dev
20091005 21:46:13< Aethaeryn> XFD
20091005 21:46:24< Aethaeryn> I might have to do that now for all my #weSNOTh-* channels.
20091005 21:46:27< Aethaeryn> Change that in my script and all.
20091005 21:46:32< Zarel> * Topic for #weSNOTh-dev set by wesbot at Sun Oct  4 21:20:12 2009
20091005 21:46:39< Zarel> I find this far more amusing than I should.
20091005 21:47:12< Aethaeryn> I'm actually laughing out loud. I don't know what to do. "lol" is not sincere since its meaning has been run into the ground and is more like "I found that mildly amusing and might be smiling right now" instead of "laughing out loud"
20091005 21:47:49< Zarel> Well, I use "lol" for "That's amusing" and "rofl" for "That's _really_ amusing"
20091005 21:48:06< Zarel> It's like vowel shift, except with acronyms.
20091005 21:48:15< Zarel> "rofl" means "lol", and "lol" means "heh"
20091005 21:48:59< mordante> Zarel, still don't understand why your fellow developers think it's a good idea to release incompatible patches but good luck getting 2.3.0 out
20091005 21:49:02< Zarel> (I actually do say "lol" out loud, but only while making internet-related jokes)
20091005 21:49:24< Aethaeryn> I think I should do zomfgxfdroflolmao for genuinely laughing.
20091005 21:50:03< Aethaeryn> z-oh my f-ing god X f-ing D rolling on the floor while laughing out loud my a-- off.
20091005 21:50:26-!- DDR [n=chatzill@jabba.tru.ca] has quit [Read error: 110 (Connection timed out)]
20091005 21:51:32< crimson_penguin> my client doesn't show any of that capitalization
20091005 21:51:56< Zarel> My client is specialer. :D
20091005 21:52:24< crimson_penguin> Apparently IRC is like HFS+ :P
20091005 21:52:43< crimson_penguin> Wait, no, it's like FAT-32 :-/
20091005 21:53:10< crimson_penguin> HFS+ does care about capitalization, but you can't have "X" and "x" at the same time
20091005 21:53:58< Ivanovic> crimson_penguin: hfs+ is (in *some* cases!) case shizoprenic
20091005 21:54:13< crimson_penguin> How so?
20091005 21:54:15< Ivanovic> crimson_penguin: though you can reformat and make it really case sensitive (not! the default)
20091005 21:54:30< crimson_penguin> Yeah, that would probably kill OS X
20091005 21:54:33< Ivanovic> that is at least what i remember from my old times back in the osx 10.4 days with my ibook
20091005 21:54:54< Ivanovic> after reformating the default formatted drive you of course have to reinstall osx
20091005 21:55:03< crimson_penguin> don't think HFS+ has changed much since
20091005 21:55:43< Ivanovic> in that time it was just that apples default setup for the file system really s*****
20091005 22:00:53-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 104 (Connection reset by peer)]
20091005 22:01:06< grzywacz> mordante, I corrupted the save manually, the dialog is still impossible to close with the latest trunk
20091005 22:01:22< grzywacz> mordante, just echo asd > savefile.gz and try loading it from the game
20091005 22:01:41< Zarel> Actually, HFS+ has that as an option.
20091005 22:01:49< Zarel> HFS+ can be either case-sensitive or case-insensitive.
20091005 22:02:00< Zarel> (By default, it's case insensitive)
20091005 22:03:33-!- happygrue_ [n=George@c-98-223-235-36.hsd1.in.comcast.net] has joined #wesnoth-dev
20091005 22:08:47< mordante> grzywacz, works perfectly in the title screen, not when loading in game ;-) this https://gna.org/bugs/index.php?14438 triggered that thought
20091005 22:10:39-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."]
20091005 22:17:05< Ivanovic> esr: at least i got an idea why the script barfs when nothing before or after the part that is to be removed is included (talking about utils/pofix.py)
20091005 22:17:18< Ivanovic> esr: before running the script you check if the string already does exist
20091005 22:17:42< Ivanovic> esr: there you probably just grab for the "new string" if it is found in the file before the replacement is done
20091005 22:17:59< Ivanovic> esr: in this case you should also check if this is *exactly* the one that is also meant to be changed
20091005 22:18:09< Ivanovic> (as in "false duplicate found")
20091005 22:19:43< mordante> I'm off night
20091005 22:20:02< Ivanovic> in the case that just some chars at the beginning or end are removed a plain "check if this term already exists in the string" is bound to fail since of course it does exist (being the part that is mean to be *left* from the old one)
20091005 22:20:06< Ivanovic> n8 mordante
20091005 22:20:13-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 101 bugs, 237 feature requests, 10 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20091005 22:20:15-!- mordante [n=mordante@wesnoth/developer/mordante] has quit ["Leaving"]
20091005 22:23:57< CIA-62> ivanovic * r39119 /trunk/ (4 files in 3 dirs): updated Hungarian translation
20091005 22:28:23-!- happygrue__ [n=George@c-98-223-235-36.hsd1.in.comcast.net] has joined #wesnoth-dev
20091005 22:29:30-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20091005 22:32:03-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20091005 22:43:43< alink> hum, with the feature freeze and the balancing stuff, what is our position about fixing AI bugs (things possibly broken in 1.6) ?
20091005 22:44:14< alink> i mean trying fix it now instead of wait 1.9
20091005 22:44:32-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit []
20091005 22:45:05< alink> i am just optimizing for the moment, but i now see a lot of broken stuff
20091005 22:46:31-!- happygrue__ [n=George@c-98-223-235-36.hsd1.in.comcast.net] has quit [Connection timed out]
20091005 22:46:35-!- Crab_ [i=crab@wesnoth/developer/crab] has joined #wesnoth-dev
20091005 22:46:39-!- kitty [n=kitty@e180197226.adsl.alicedsl.de] has quit [Nick collision from services.]
20091005 22:46:52< Crab_> hi alink.
20091005 22:46:53< alink> and optimizing broken/useless code feel a bit futile
20091005 22:46:57< alink> 'lo Crab_
20091005 22:47:16-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 22:47:29< Crab_> wesbot tells that you were looking for me...
20091005 22:47:34-!- happygrue_ [n=George@c-98-223-235-36.hsd1.in.comcast.net] has quit [No buffer space available]
20091005 22:47:36< alink> Crab_: got my irc note about terrain_filter in AI contexts code ?
20091005 22:47:49< Ivanovic> alink: i'd say that broken stuff should be fixed
20091005 22:48:01-!- happygrue_ [n=George@c-98-223-235-36.hsd1.in.comcast.net] has joined #wesnoth-dev
20091005 22:48:10< Ivanovic> regarding ai stuff you should talk to Crab_ though about what is really broken and what is already broken enough to be called "feature"
20091005 22:48:30< Crab_> alink: reading...
20091005 22:49:04< alink> Crab_: contexts.cpp:347 this filter is costy and seems always used
20091005 22:50:07< Crab_> alink: yes. this is [avoid] aspect of the ai. it designates hexes which should be ignored by ai movement code (except in special, not currently present, cases). most of the time, it's empty, ( [not][/not] )
20091005 22:50:08< alink> Ivanovic: ok, i will start to check what was working in 1.4 and 1.6, fix it and try to see how it affect AI, and i report back
20091005 22:50:50< Crab_> alink: there's a *giant* possible optimization in 'ai targeting phase', wrt that aspect and wrt movement map.
20091005 22:50:59-!- kitty_ [n=kitty@e180197226.adsl.alicedsl.de] has joined #wesnoth-dev
20091005 22:51:08< Crab_> alink: i.e., imagine that there's no WML events, ambushes, etc
20091005 22:51:23< Crab_> imagine that we have N friendly units and we only want to do moves, not attacks
20091005 22:51:32< Crab_> we have computed srcdst and dstsrc maps, once.
20091005 22:51:43< Crab_> after each move, we do not have to recompute them
20091005 22:51:49< YogiHH> hi kitty_ 
20091005 22:51:59< Crab_> alink: we can just do a 'limited amendment' to them
20091005 22:52:07< kitty_> hey YogiHH 
20091005 22:53:07< alink> yeah that's a possibility, but need to check how much trouble is to track all the possible events causing the need to refresh them
20091005 22:53:09< Crab_> alink: this way, ai 'strategic movement' phase will need exactly 1 call of 'compute that SLF in avoid aspect', regardless of the units involved
20091005 22:53:30< Crab_> alink: to do this safely, some generic checks are needed.
20091005 22:53:45< Ivanovic> YogiHH: have you filled out the form that leslie asked for?
20091005 22:53:48< Ivanovic> you and Sapient that is
20091005 22:53:57< alink> Crab_: unless you play a scenario firing often WML events
20091005 22:53:58< Crab_> i.e.,it's easy enough to check for ambush during the move (currentai movement code explicitly checks for it using src/actions.cpp move code)
20091005 22:53:59< Ivanovic> anyway, i got to head off to bed now, n8
20091005 22:54:06< YogiHH> Ivanovic: not yet, i will do it tomorrow
20091005 22:54:30< YogiHH> Ivanovic: From what i have seen, i can do it for sapient as well
20091005 22:54:36< Crab_> and, we need a flag like 'something is strangely invalidated by something like WML'
20091005 22:54:40< Ivanovic> YogiHH: and since you said that you will get yourself a car it is probably easiest to go to the other hotel (cheapest that is)
20091005 22:54:51< YogiHH> Ivanovic: He is out of internet more or less atm
20091005 22:54:52< Ivanovic> since for the extra con you will have to pay some 70$ IIRC
20091005 22:54:59< YogiHH> 40
20091005 22:55:06< alink> Crab_: yes seems simple enough
20091005 22:55:43< Ivanovic> ah, i see where i have the 70 from
20091005 22:56:00< Ivanovic> about 70 cots are available
20091005 22:56:06< YogiHH> mhm
20091005 22:56:23< Crab_> alink: simple, but not so easy to implement (there's a ton of places where teams\units\time_of_day\etc modifications take place, we need to recheck the architecture of wesnoth to maybe pass all gamestate modifications through some kind of gateway\filter )
20091005 22:57:47< Ivanovic> time for my lovely warm bed, n8
20091005 22:57:47< Crab_> alink: btw, 'slow targeting phase' is the main reason of NR: Showdown being sometimes called NR:Slowdown :)
20091005 22:57:56< alink> Crab_: yeah that was i fear a bit about such system
20091005 22:58:18< Crab_> ai code is already self-aware on such modifications.
20091005 22:58:27< Ivanovic> alink, Crab_: a change like this sounds like a major redesign to me and should probably be done in a branch and not commited to trunk before 1.8 is ready
20091005 22:59:05< alink> Ivanovic: for this, yes, obviously
20091005 22:59:06< Crab_> i.e. if one place of ai moves something, srcdst maps in another place (even in formula code) will be properly invalidated
20091005 23:00:00< Crab_> Ivanovic: well, it's more important to find out 'what should be done', than to find out 'when it should be done'. I agree about this being a major internal redesign and post-1.8 way of doing things.
20091005 23:00:13< alink> Crab_: btw the last time i checked my last patch with NR, the number of targets(and their A*) came from >60 to 1 or 2 :-)
20091005 23:00:36< alink> * targets considered
20091005 23:01:58< alink> so AI do a lot less stuff but the time gain was not impressive, at least on my test-cases/system :-(
20091005 23:03:15< Crab_> alink: well, the number of units is still big. remember we were talking about a 'strategic movement' phase which will be able to use cached results of getting to target of nearby units with same movement type ?
20091005 23:05:27< alink> yes but now with the current AI, i don't see many A* calls, and the fact that a big reduction of the number of A* doesn't give good result make me wonder about the importance of this bottleneck
20091005 23:05:51-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [No buffer space available]
20091005 23:05:59< alink> but i need to check more the numbers
20091005 23:06:29< alink> Crab_: anyway for that filter, for the default case, could you use NULL instead of a dummy filter, to avoid entering filter code each time ?
20091005 23:07:08< alink> (for nothing, but filter code doesn't know that it's just [not][/not] and so retest all stuff each times)
20091005 23:08:51< Crab_> checking...
20091005 23:08:55-!- ShikadiLord [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20091005 23:09:25< Crab_> note that the filter itself is recalculated only once per turn
20091005 23:09:43-!- ShikadiLord [n=ignacio@wesnoth/developer/shadowmaster] has quit [Client Quit]
20091005 23:09:59< alink> yeah, but its content it "config-parsed" for each hexes in that nested loop
20091005 23:10:11< alink> s/it/is
20091005 23:12:28-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #weSNOTh-dev
20091005 23:12:29< alink> as i mentioned in logs, there is various ways to optimize this, but with the empty default case, the easiest way is to just detect NULL
20091005 23:12:52< Crab_> alink: what do you mean by 'each times' ?
20091005 23:13:25< Crab_> alink: ah, I see...
20091005 23:13:27< alink> we call "remove_destinations->match(dst)" for each dst locations
20091005 23:13:48< Crab_> it results in multiple filter calls ?
20091005 23:13:59< alink> and i think there is a lot of these dst, and often several time the same ones
20091005 23:14:10< Crab_> I was under the impression that it computed on 1st access and cached the results... am I wrong ?
20091005 23:14:28< alink> yes no cache in filter yet AFAIK
20091005 23:14:45< alink> check terrain_filter match() and see all the code runned
20091005 23:15:09< Crab_> alink: ok, thanks. I'll take this into account and use the set<location>
20091005 23:15:21< Crab_> as the value which is used
20091005 23:15:43< Crab_> (i.e. I'll do that 1-per-turn cache in ai code)
20091005 23:16:02< alink> set<location> ?
20091005 23:16:20< alink> filtering the whole map in a set each turn ?
20091005 23:17:28< alink> well, i don't really care about how "avoid" is optimized, just keep the empty default case fast ;-)
20091005 23:17:39< Crab_> alink: yes, that what I'm thinking about.
20091005 23:18:04< alink> check against NULL is the fastest, but find() in an empty set is already better
20091005 23:18:10-!- happygrue_ [n=George@c-98-223-235-36.hsd1.in.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
20091005 23:18:13< Crab_> alink: i.e. , is 'calling terrain_filter::get_locations once' more advantageous than calling ->match(dst) for each dst ?
20091005 23:18:20-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20091005 23:18:39-!- fendrin [n=fabi@wesnoth/developer/fendrin] has quit [Read error: 104 (Connection reset by peer)]
20091005 23:18:40< Crab_> alink: well, I can check against empty smart pointer, too.
20091005 23:18:43-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has quit ["ZOMGXFDROFLOLMAO"]
20091005 23:19:34< alink> i don't know well terrain_filter::get_locations, but i bet it depends of the size of map, the number of loc passing the filter-match, and the number of dst you need to test
20091005 23:20:41< Crab_> alink: most of the time we want to get 'hexes that we can reach'
20091005 23:21:16-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 23:21:39< Crab_> alink: is it possible to modify SLF to allow for 'is_not()' method ?
20091005 23:22:02< alink> not sure that follow
20091005 23:22:44< Crab_> alink: a method in the SLF with semantics: "return true if this filter doesn't match anything, return false if this is not known"
20091005 23:24:06< alink> "if this is not known" ?
20091005 23:24:35< Crab_> alink: yes. 'return true if we can optimize' thing
20091005 23:24:51< Crab_> (so, if this approach is used, [not][/not] filter will return 'true' on slf.is_not(), and it'll be possible to skip the checks 'does dst match filter' fully)
20091005 23:25:24< Crab_> I can even add a new [nothing] tag to SLF to allow easier checking of is_not
20091005 23:25:49< Crab_> this solution is better because it's more generic, yet simple.
20091005 23:25:52< Crab_> 'compiling
20091005 23:26:11< Crab_> of course, 'compiling' the slf into something faster, is a better approach, yes
20091005 23:26:31-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #weSNOTh-dev
20091005 23:26:52< alink> i still don't see why you don't want just using NULL there instead of wml stuff for the "nothing" case
20091005 23:28:17< Crab_> alink: when AI is saved, it's persisted into WML. so, WML representation of that NULL is required.
20091005 23:30:00< alink> ah ok
20091005 23:30:21-!- YogiHH [n=chatzill@d155175.adsl.hansenet.de] has left #wesnoth-dev []
20091005 23:30:22< Crab_> alink: I can either make the 'avoid' aspect to be a "boost::shared_ptr<terrain_filter>" and write a serialization/deserialization of it from config, or add a hack to check for that [not][/not] case, or modify a SLF to contain a flag 'hey, I KNOW that I match nothing'
20091005 23:30:29< alink> well, anyway, then maybe just check before the loop to see if it's equal to the dummy case and assign a bool flag for this
20091005 23:30:49< Crab_> alink: yes, that's exactly "or add a hack to check for that [not][/not] case" solution :)
20091005 23:31:07< Crab_> alink: but, I was thinking about actually pushing that flag to SLF.
20091005 23:31:47< Crab_> alink: that's why I talked about is_not() method to check for this.
20091005 23:32:26< alink> :)  then i recommend the hack, and wait to have more use of such flag before introducing new stuff in SLF
20091005 23:32:37-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20091005 23:32:41< Crab_> ok
20091005 23:32:45< Crab_> will do.
20091005 23:32:45< alink> after all, i assume that most SLF are not empty
20091005 23:33:04< Crab_> but, it's the 'empty' case that is most ripe for optimizations :)
20091005 23:35:45< alink> earlier today i talked about implementing filter object, if/when we use something like this, then a empty flag would be logical to add there
20091005 23:36:17-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20091005 23:36:45< Crab_> an object to store the state of a 'filtering session', sort of ?
20091005 23:37:37< Crab_> alink: and, about 'hum, with the feature freeze and the balancing stuff, what is our position about fixing AI bugs (things possibly broken in 1.6) ? '...
20091005 23:39:41< alink> no, for filter object, my idea was: first step, store the filter parameters in a efficient specialized c++ structure, not just a raw config object. Possible second step, add a cache in there for caching filter results
20091005 23:40:26< Crab_> alink: something similar to 'compiling WML of the filter into c++ data structures' ?
20091005 23:40:48< alink> yes
20091005 23:40:56< Crab_> sounds like a good idea
20091005 23:42:24< Crab_> alink: my position on 'fixing ai bugs' is : those bugs\features which are not visible to scenario creators should not be reworked (except where it's possible to fix them quickly), those bugs/features which affect the interface which is used by the scenario creators (i.e. WML AI syntax or formula ai syntax) should be changed/reworked to achieve a 'consistent, stable enough, with all required features' ai modification syntax.
20091005 23:45:03< alink> mmmh, the current bugs that i spotted was "this AI code receive incorrect input and thus do a bit of cpu work, but always fails, possibly causing dumb decision"
20091005 23:46:06< Crab_> what's "incorrect input" ?
20091005 23:47:35-!- Appleman1234 [n=Appleman@131.181.102.205] has joined #wesnoth-dev
20091005 23:47:59< Crab_> and note that 'dump decision' is better that 'no decision' or 'endless loop trying to decide'
20091005 23:48:04< Crab_> s/dump/dumb
20091005 23:48:15< alink> some code sending value like target rating or move_cost inconsistent with other code
20091005 23:48:43< Crab_> alink: well, I'd say "we can/should fix this if we will have 1.7.7 before 1.8"
20091005 23:48:52< alink> for example, i suspect "complex targeting" to never work, meaning that the "simple_targeting" WML flag is useless
20091005 23:48:57< AI0867> mordante: there's a reason it's fuzzy
20091005 23:49:51< Crab_> alink: since we need to test a changes which might lead to glitches like endless loops or ai not moving for entire minor revision
20091005 23:50:26< Crab_> alink: e.g., remember the reason for 1.6a ?
20091005 23:51:25< alink> yes, but some of these flaws that i understand now are maybe the source of some 1.6 AI bugs
20091005 23:51:58< shadowmaster> wow, really doing wesnoth-optipng with 6 threads can send my CPU from 62°C to  82°C in ten seconds now? :/
20091005 23:52:17< shadowmaster> I think I'll miss the winter.
20091005 23:52:37< Crab_> shadowmaster: so, now you're found a way to use your computer as a heating device while still helping wesnoth :)
20091005 23:52:51< Crab_> alink: so, I think that we need to ask Ivanovic about 1.7.7 - if we have the opportunity to test those fixes, we should do them
20091005 23:53:32< alink> Crab_: but as I said to Ivanovic, i will investigate more on the history of the broken code, and quickly check how the AI is affected by the change
20091005 23:53:40-!- SonIcco [n=SonIcco@pD951071C.dip0.t-ipconnect.de] has quit [Remote closed the connection]
20091005 23:53:59< shadowmaster> Crab: yes, it was nice to get my legs warm on those cold winter nights by running scons -j 6 :P
20091005 23:54:21< alink> plus there is also the small problem that a smarter/fixed AI is often less fast than a dumb/broken AI
20091005 23:54:36< shadowmaster> unfortunately now it's spring, which means I won't be able to do that trick without risking a burn
20091005 23:54:48< Crab_> alink: of course we will check. but, many more bugs are found by the users than by us :)
20091005 23:55:12< Crab_> shadowmaster: temporarily relocate to north hemisphere ;)
20091005 23:55:57< alink> Crab_: yeah and one may say that waving 0 and empty container is not a really bug, just a waste of code and cpu
20091005 23:57:27< Crab_> alink: well, I think that bugs need fixing. but, we need 1.7.7 to do proper tests of all non-subtle fixes.
20091005 23:58:00-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #Wesnoth-dev
20091005 23:58:34-!- boucman [n=rosen@wesnoth/developer/boucman] has quit ["Leaving."]
20091005 23:58:52< Crab_> alink: I'm, personally, in favor of doing another dev release before hitting 1.8, to allow a week or two of testing the changes of pre-1.8-cleanup.
20091005 23:59:52< Crab_> alink: so, we need to ask Ivanovic about that.
--- Log closed Tue Oct 06 00:00:31 2009