--- Log opened Sat Jun 27 00:00:20 2009 --- Day changed Sat Jun 27 2009 20090627 00:00:20< boucman> night all 20090627 00:00:26< Sapient> gn, boucman 20090627 00:00:27-!- boucman [n=rosen@wesnoth/developer/boucman] has quit ["Leaving."] 20090627 00:09:14-!- wesbot changed the topic of #wesnoth-dev to: 1.7.1 planned for June 28 | 68 bugs, 234 feature requests, 12 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org 20090627 00:10:20-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit [] 20090627 00:13:09-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20090627 00:20:47-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Remote closed the connection] 20090627 00:21:40-!- cib0 [n=cib@p5DD3482B.dip.t-dialin.net] has quit [Remote closed the connection] 20090627 00:25:16< Rrenys> It would be really great if there were a button for sorting all the mp lobby name categories by name (or even better if it was done automatically) 20090627 00:30:36-!- giusef [n=giusef@unaffiliated/giusef] has quit ["exit (-1);"] 20090627 00:35:39-!- Alesis-Novik [n=alesis@78.60.249.133] has joined #wesnoth-dev 20090627 00:42:03-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has quit [Remote closed the connection] 20090627 00:56:52-!- BenUrban [n=benurban@96.231.170.217] has joined #wesnoth-dev 20090627 01:06:07-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit [] 20090627 01:08:47-!- Sirp_ [n=me@pool-173-74-23-130.dllstx.fios.verizon.net] has joined #wesnoth-dev 20090627 01:26:59-!- Sirp [n=me@wesnoth/developer/dave] has quit [Read error: 110 (Connection timed out)] 20090627 01:27:28-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has quit ["ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]"] 20090627 01:38:01-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["Tengo que ir... Yeahzorz..."] 20090627 01:41:23-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev 20090627 01:44:01-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20090627 01:51:51< noy> so does anybody know when we added the programming for idle animations? 20090627 01:51:56< noy> offhand? 20090627 01:57:17-!- ilor [n=user@wesnoth/developer/ilor] has quit [Read error: 60 (Operation timed out)] 20090627 02:00:57< Sapient> I don't know... but I think the jumping dwarf was the first one, IIRC 20090627 02:10:32-!- ancestral [n=ancestra@97-116-110-107.mpls.qwest.net] has quit [] 20090627 02:11:30-!- ancestral [n=ancestra@97-116-110-107.mpls.qwest.net] has joined #wesnoth-dev 20090627 02:38:36< Sapient> that Pozzie scheme seems to be generating a lot of noise on the dev-ml 20090627 02:39:13< Sapient> fantasy wesball leages, lol 20090627 02:47:31-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"] 20090627 02:48:01-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection] 20090627 02:55:43-!- Sapient [n=patrickp@wesnoth/developer/sapient] has left #wesnoth-dev [] 20090627 02:56:26-!- ABCD_ [n=ABCD@wikipedia/ABCD] has joined #wesnoth-dev 20090627 02:57:00-!- ABCD [n=ABCD@wikipedia/ABCD] has quit [Read error: 104 (Connection reset by peer)] 20090627 02:57:34-!- ABCD_ is now known as ABCD 20090627 03:25:01-!- Mythological [i=Mytholog@77.28.119.119] has joined #wesnoth-dev 20090627 03:29:53< CIA-53> cornmander * r36414 /website/stats.wesnoth.org/ (3 files in 3 dirs): Added date filtering support to backend (servlet) 20090627 03:35:50< CIA-53> cornmander * r36415 /website/stats.wesnoth.org/ (6 files in 3 dirs): 20090627 03:35:50< CIA-53> Changed URL from a noun to a verb (newview->addview) and stubbed a deleteview page. Removed completed timestamp support from 20090627 03:35:50< CIA-53> TODO. 20090627 03:37:32-!- noy [n=Noy@wesnoth/developer/noy] has quit [] 20090627 03:37:52-!- Sirp_ [n=me@pool-173-74-23-130.dllstx.fios.verizon.net] has quit ["brb"] 20090627 03:46:44-!- Sirp [n=me@wesnoth/developer/dave] has joined #wesnoth-dev 20090627 04:20:51-!- BenUrban [n=benurban@unaffiliated/benurban] has quit ["Power failu"] 20090627 04:37:39-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["Tengo que ir... Yeahzorz..."] 20090627 04:46:53-!- ABCD [n=ABCD@wikipedia/ABCD] has quit [Read error: 104 (Connection reset by peer)] 20090627 04:55:47-!- BenUrban [n=benurban@68.55.19.224] has joined #wesnoth-dev 20090627 04:57:35-!- Ivanovic_ [n=ivanovic@dtmd-4db2ae68.pool.einsundeins.de] has joined #wesnoth-dev 20090627 05:01:50-!- ABCD [n=ABCD@wikipedia/ABCD] has joined #wesnoth-dev 20090627 05:02:40-!- ABCD_ [n=abcd@wikipedia/ABCD] has joined #wesnoth-dev 20090627 05:03:06-!- Rrenys [n=rrenys@81-20-159-197.levira.ee] has quit [Success] 20090627 05:12:36-!- Ivanovic [n=ivanovic@wesnoth/developer/ivanovic] has quit [Read error: 110 (Connection timed out)] 20090627 05:13:34-!- Ivanovic_ is now known as Ivanovic 20090627 05:16:11-!- Mythological [i=Mytholog@77.28.119.119] has quit [] 20090627 05:33:27-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev 20090627 05:48:58< Aethaeryn> roughly how long does it take to go from development until stable? 20090627 05:49:21< Aethaeryn> in other words, how long would a content maker reasonably expect to wait for 1.8? 20090627 05:49:38< Aethaeryn> in the most roughest of guestimations? 20090627 06:01:20-!- Aethaeryn is now known as MikeJB 20090627 06:13:49-!- MikeJB is now known as Aethaerny 20090627 06:13:51-!- Aethaerny is now known as Aethaeryn 20090627 06:33:27-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit [] 20090627 07:50:02-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev 20090627 07:55:48-!- BenUrban_ [n=benurban@unaffiliated/benurban] has joined #wesnoth-dev 20090627 08:03:03< CIA-53> esr * r36416 /trunk/data/campaigns/The_Hammer_of_Thursagan/maps/strange_allies.map: Edge correction, an tweaks to use forested hills. 20090627 08:04:17< CIA-53> esr * r36417 /trunk/data/core/units/ (6 files in 3 dirs): Beginning of usage-polishing pass on unit descriptions. 20090627 08:12:10-!- ancestral [n=ancestra@97-116-110-107.mpls.qwest.net] has quit ["And that’s the end of THAT chapter."] 20090627 08:12:43-!- BenUrban [n=benurban@unaffiliated/benurban] has quit [Read error: 110 (Connection timed out)] 20090627 08:13:40< Aethaeryn> anyone a sprite artist? 20090627 08:26:06-!- EdB [n=edb@125.117.88-79.rev.gaoland.net] has joined #wesnoth-dev 20090627 08:48:31-!- maxy [n=maxy@84-74-83-103.dclient.hispeed.ch] has joined #wesnoth-dev 20090627 09:13:40-!- EdB [n=edb@125.117.88-79.rev.gaoland.net] has quit [Remote closed the connection] 20090627 09:16:12-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20090627 09:30:22< Ivanovic> moin 20090627 09:30:44-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20090627 09:43:15-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev 20090627 09:49:48< CIA-53> ivanovic * r36418 /trunk/po/ (7 files in 7 dirs): updated Lithuanian translation 20090627 09:49:51< CIA-53> ivanovic * r36419 /branches/1.6/ (9 files in 8 dirs): updated Lithuanian translation 20090627 10:21:45-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev 20090627 10:21:55< silene> hi 20090627 10:22:06< stikonas> silene: hi 20090627 10:22:27< stikonas> silene: I was able to test Wesnoth 1.6.3 on Windows on another computer 20090627 10:23:19< stikonas> the strings on the right (https://gna.org/file/wesnoth-date.jpg?file_id=6048) behaves exactly as on GNU/Linux 20090627 10:23:31< stikonas> so backporting your patch should help there 20090627 10:23:47< silene> you mean: it is broken only once? 20090627 10:23:53< stikonas> silene: yes 20090627 10:24:01< silene> okay, will do, then 20090627 10:24:07< stikonas> but the date on the left was translated for me, and I suspect that it uses default system language 20090627 10:24:09< silene> thanks 20090627 10:25:15< silene> stikonas: no, this is dumber than that, the date on the left is computed, after the locale is initialized the first time, while the date on the left is before 20090627 10:26:05< silene> (so, for the date on the left, it is as if it was already the second time you are opening the load box) 20090627 10:27:58-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20090627 10:35:06< CIA-53> silene * r36420 /trunk/changelog: Updated changelog. 20090627 10:36:55-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev 20090627 10:40:12< CIA-53> silene * r36421 /branches/1.6/ (changelog src/dialogs.cpp src/language.cpp): Set LC_TIME locale at the same place as other locales. (Fixes bug #13782.) 20090627 10:58:33-!- Noyga [n=lame-z@wesnoth/developer/noyga] has joined #wesnoth-dev 20090627 11:18:17-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)] 20090627 11:20:42-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"] 20090627 11:24:00-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev 20090627 11:25:12< grzywacz> moin 20090627 11:26:57< Soliton> AI0867: http://www.wesnoth.org/forum/viewtopic.php?p=364010#p364010 20090627 11:43:47-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has quit [Remote closed the connection] 20090627 11:48:50-!- Aethaeryn [n=Michael@c-98-204-170-162.hsd1.md.comcast.net] has left #Wesnoth-dev [] 20090627 11:50:48-!- loonybot [n=loonybot@79.139.136.167] has joined #wesnoth-dev 20090627 11:51:40-!- loonycyborg [n=sergey@79.139.136.167] has joined #wesnoth-dev 20090627 12:08:09-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["Tengo que ir... Yeahzorz..."] 20090627 12:08:47-!- noy [n=Noy@wesnoth/developer/noy] has quit [] 20090627 12:09:14-!- wesbot changed the topic of #wesnoth-dev to: 1.7.1 planned for June 28 | 67 bugs, 234 feature requests, 12 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org 20090627 12:23:00-!- cib0 [n=cib@p5DD34E2A.dip.t-dialin.net] has joined #wesnoth-dev 20090627 12:23:47-!- EdB [n=edb@94.12.95-79.rev.gaoland.net] has joined #wesnoth-dev 20090627 12:33:33-!- Alesis-Novik [n=alesis@78.60.249.133] has quit [Remote closed the connection] 20090627 12:36:19-!- Alesis-Novik [n=alesis@78.60.249.133] has joined #wesnoth-dev 20090627 12:46:33-!- Alesis-Novik [n=alesis@78.60.249.133] has quit [Remote closed the connection] 20090627 12:48:11-!- Alesis-Novik [n=alesis@78.60.249.133] has joined #wesnoth-dev 20090627 13:00:40-!- Chusslove [n=Chusslov@brsg-d9befcfb.pool.mediaWays.net] has joined #wesnoth-dev 20090627 13:08:07-!- EdB [n=edb@94.12.95-79.rev.gaoland.net] has quit [Remote closed the connection] 20090627 13:23:37-!- silene1 [n=plouf@ASte-Genev-Bois-152-1-18-115.w83-114.abo.wanadoo.fr] has joined #wesnoth-dev 20090627 13:24:08-!- silene [n=plouf@wesnoth/developer/silene] has quit [Read error: 110 (Connection timed out)] 20090627 13:29:43-!- silene1 is now known as silene 20090627 13:30:03-!- Crab_ [n=Crab_@wesnoth/developer/crab] has joined #wesnoth-dev 20090627 13:30:06< Crab_> hi 20090627 13:30:27< boucman> hey Crab_ 20090627 13:30:31< boucman> how's everything ? 20090627 13:30:39< Crab_> good :) 20090627 13:30:40< Dragonking> hi everyeone 20090627 13:30:46< Crab_> hi Dragonking 20090627 13:31:09< boucman> so how did your last discussion turn out ? 20090627 13:31:58< Dragonking> boucman: I fixed some formula bugs, started working on this RCA thing just since thursday I have been working on one project for my uni... let me not comment about performance of my "team" there......... 20090627 13:32:06< Dragonking> I'll be back to wesnoth after monday apparently 20090627 13:33:00< boucman> k 20090627 13:33:06< Dragonking> I'm actually codin in java all the tamie, from time ot time playing wesnoth parrarerly to not go crazy about how I have Eclipse API 20090627 13:33:46< Dragonking> s/have/hate/ 20090627 13:35:00< Dragonking> Just due to it I lost another 5 days before midterm evaluation.. ech :/ 20090627 13:36:30-!- ilor [n=user@wesnoth/developer/ilor] has quit [] 20090627 13:36:46< Dragonking> boucman: I have locally some changes, I made generic function that takes variant and runs formula over it, treating variant as an 'input' parameter 20090627 13:37:06< Dragonking> I think that's what you wanted to have in RCM filters to make it more generic? 20090627 13:37:28< boucman> yes, that was the idea 20090627 13:37:38< boucman> to gain a level of complexity 20090627 13:40:56< Dragonking> I stopped at point where I'm supposed to check if enemy unit is in range of my unit, before performing attack evaluation, but I realized I need object of unit class there... and all I have are variant, so I would have to do dynamic_cast(variant.asCallable()).getUnit() and then realized that it may get slow there.. was looking for ways to somehow replace casting but I'm afraid there's none 20090627 13:42:55< Dragonking> Hmm... maybe for this just write formula that would do it automatically and run it instead.. 20090627 13:43:21< boucman> yes, i thing that it should be done on the formula side (at least as a first implementation) 20090627 13:44:36< Dragonking> I want to make sure that we understand each other - this formula ot selec units would be invisible for user and always the same 20090627 13:45:48< boucman> hmm 20090627 13:46:07 * boucman rereads the whole conversation 20090627 13:46:20< Dragonking> That is sole purpose of 'attack' RCM, to not take into account impossible attack - due to units distance 20090627 13:47:10< boucman> hmm no :P 20090627 13:47:27< boucman> it's also to have a generic filtering mechanism for other cases of "pair matching" 20090627 13:47:34< boucman> think of healers+units 20090627 13:47:56< boucman> we start with all units, and we first filter on healers 20090627 13:47:59< Dragonking> I'm talking about 'attack' RCA 20090627 13:48:34< boucman> hmm ok, i'll take another example 20090627 13:48:40< Dragonking> We have 'move' 'attack' 'support' and to be implemented 'something' that you proposed some time ago 20090627 13:48:49< Crab_> Dragonking: why do you need "variants/dynamic casts" to do this ? you can get a list of possible attacks/pair moves without variants/casts, convert them into vector of 'pair matches' objects and run formulas on them 20090627 13:48:52< boucman> yes, i think we can hardcode the removal of "impossible attack pairs" 20090627 13:49:44< boucman> however we should still allow the user to have its own filter, suppose I want to do a special RCA for units that are about to level, being able to reduce complexity by filtering out units that are not about to levell would be a huge gain 20090627 13:50:16< Dragonking> boucman: but that is also point of RCA 20090627 13:50:59-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has quit [Remote closed the connection] 20090627 13:51:00< Dragonking> Crab_: But then we get many pairs and for each we would need to check if my_unit and enemy_unit matches addicional filters 20090627 13:51:03< boucman> Dragonking: yes, but the "filters" on the attack type are here to simplify formula/reduce computational complexity 20090627 13:51:44< boucman> Dragonking: to avoid this conversation being to confusing, let's discuss the cast thing with Crab_, we'll get back to filtering and if/why it needs to be accessible after that 20090627 13:52:57< Dragonking> boucman: if we have filter_me = filter( input, max_xp - current_xp < 8 ) then we first filter units about to level 20090627 13:53:05< Crab_> Dragonking: yes, but, see how it's done with attacks -> 1) get a vector of attack_analysis 2) filter them 20090627 13:53:09< Dragonking> boucman: Then game internally looks what those units can attack 20090627 13:53:39< Crab_> so, the question is: can't the same thing be done with 'paired moves', not necessary attacks ? 1) get a vector of paired_move_analysis 2) filter them 20090627 13:54:07< Crab_> (where (1) can be pure c++) 20090627 13:55:52< Crab_> and, where (1) can be cached (as srcdst and dstsrc move_maps) 20090627 13:56:45< Crab_> s/ (as srcdst and dstsrc move_maps)/ (exactly as srcdst and dstsrc move_maps are cached) 20090627 13:58:36< Dragonking> Well, idea was to filter first unit that are useless, then look where they may reach 20090627 13:58:42< boucman> Crab_: I guess caching a list of all possible attacks (separate from the map of all moves) might be a good idea 20090627 13:59:07< boucman> Dragonking: good point... 20090627 13:59:48< Dragonking> With looking first where unit can reach, we end up with many "moves" that are just useless for us. 20090627 14:00:08< Crab_> Dragonking: yes, but they can be not useless for some other candidate action 20090627 14:01:19< Dragonking> Crab_: We would still need to rebuild it after last action 20090627 14:01:36< Crab_> Dragonking: yes. note that srcdst and dstsrc are already rebuilt 20090627 14:01:56< Dragonking> So I though about using it inside formula 20090627 14:02:03< Dragonking> Internal formula call to check what can we reach 20090627 14:02:58< boucman> Crab_: in our case, we are trying to optimize by reducing the number of formula calls 20090627 14:03:20< Dragonking> Each pair would need up to 2 formula calls 20090627 14:03:24< boucman> the problem is not building the move-map, the problem is to avoid running a formula on each possible move 20090627 14:03:45< boucman> and we doing that by filtering on attacker first, then on target, and then only on the remaining pairs 20090627 14:03:53< boucman> (at least that's the plan) 20090627 14:04:01< boucman> it's not related to srcdst building 20090627 14:04:51< Dragonking> boucman: But Crab_ is right that we may use that, and I think running formula for each already filtered my unit, that would return units in his range may bo good idea 20090627 14:05:01< Dragonking> Formula already uses srcdst 20090627 14:05:04< Crab_> boucman: so, what's the problem with multi-step approach ? 1) get move map 2) filter on unit1, 3) stop or filter on unit2 4) stop or execute formula 20090627 14:05:22< boucman> Crab_: yes that's fine 20090627 14:05:33< boucman> i'm not sure what our problem is anymores, I guess :P 20090627 14:06:17-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev 20090627 14:07:01< Crab_> Dragonking: note that there are 'get_srcdst(), get_dstsrc(), get_enemy_srcdst(), get_enemy_dstsrc(), get_possible_moves(), get_enemy_possible_moves()' in ai::readonly_context 20090627 14:08:08< Crab_> that return the 'cached value' 20090627 14:08:33< Dragonking> Crab_: 2) how would you filter out unit1 ? 20090627 14:11:15< Crab_> Current approach in some places, with 'normal moves' - loop on srcdst, checking unit on src and filtering on it\ 20090627 14:11:38< Dragonking> So you would run filter n times for n our units? 20090627 14:12:00< Dragonking> Current approach is to run filter once per all my_units and getting vector of matching ines 20090627 14:12:02< Dragonking> ones' 20090627 14:12:03< boucman> Crab_: would looping on srcdst loop on all src/dst pairs ? because that's what we want to avoid... 20090627 14:12:13< Crab_> Dragonking: yes, n runs of the filter on N units. 20090627 14:13:43< Crab_> boucman: to avoid looping on all src/dst pairs, we need to replace our move_map implementation. 20090627 14:14:19< Dragonking> I think it could be: filter out my_units using formula, filter out enemy_moves using formula, for each my_unit_filtered run formula filtering enemies (using srcdst used by formula), and run eval for each matching pair. 20090627 14:14:25< boucman> Crab_: how much work would that be ? 20090627 14:15:09< Crab_> boucman: most of the work is 'figuring out the best data structure to use'. actual implementation is not that difficult. 20090627 14:15:17< Crab_> it is now std::map 20090627 14:16:09< boucman> well, seems easy enough to loop on all keys, then, we just need to expose the API, I guess 20090627 14:23:52< Crab_> boucman: for example, what do you think about using an additional cache with something like std::map > unit_moves ? 20090627 14:24:04< Dragonking> hmm.. if we would treat filter_me like function it could be reduced to one call: tomap(my_filtered, map( my_filtered, 'my_unit', filter( enemy_filtered, 'enemy', unt_can_reach(my_unit, enemy) ) ) where my_filterd = filter_me(my_units), enemy_filtered = filter_me(enemy_units) 20090627 14:24:27< Crab_> ( a map from units to ranges on srcdst map) 20090627 14:24:45< boucman> Crab_: taht could be usefull, yes 20090627 14:24:54< Dragonking> Filteding is done once, for each filtered pair there is call directly to srcdst, formula itself is run once 20090627 14:25:35-!- giusef [n=giusef@unaffiliated/giusef] has joined #wesnoth-dev 20090627 14:25:47< Dragonking> Result would be [ my_unit1 -> [enemy1, enemy2...], my_unit2->[enemy4, enemy7,.. ] .. ] 20090627 14:26:55< Crab_> Dragonking: then it's not 'call to srcdst' :) 20090627 14:27:20< Dragonking> unt_can_reach() is based on that I think 20090627 14:27:41< Dragonking> Anyway accessing srcdst in formula is already easy AFAIR 20090627 14:28:27< Dragonking> I don't recall exact names, it's just abstract that it is possible like that 20090627 14:28:44< Crab_> it's no reason to use unit_can_reach here... 20090627 14:28:58< Crab_> let's see from other direction: 20090627 14:29:32< Crab_> 1) it is highly probable that any implementation of ai, in the near future, will include ai default combat phase 20090627 14:29:55< Crab_> 2) that ai default combat phase calculates the attack to do by picking 'best' attack of all 20090627 14:30:10< Crab_> 3) so, to do this, it constructs a list of all possible attacks. 20090627 14:30:48< Crab_> 4) so, for each rca 'tick', a list of all possible attack is evaluated 20090627 14:32:29< Crab_> 5) so, it is, in my opinion, better to modify that 'construction of a list of possible attacks' to include any additional info we need [such as A) modify it to calculate a list of possible friendly pairs, as well B) construct some kind of "unit -> vector" cache ] 20090627 14:32:30< Crab_> . 20090627 14:32:54< Crab_> what do you think ? 20090627 14:34:18< Crab_> see std::vector default_ai_context_impl::analyze_targets - we already do a 'full loop' here 20090627 14:34:30< Dragonking> In case of RCA it comes to how many time we have to call formula 20090627 14:34:36< Dragonking> We would like ot minimalize that 20090627 14:34:59< Crab_> we can run a formula 1 time 20090627 14:35:12< Crab_> run it on full list of [ my_unit1 -> [enemy1, enemy2...], my_unit2->[enemy4, enemy7,.. ] .. ] 20090627 14:35:40< Crab_> (this list is, sort of, *already* constructed and then thrown away in ai default combat phase ) 20090627 14:35:50< boucman> Crab_: that's the same complexity... 20090627 14:36:16< boucman> suppose we have M units, and N ennemies thant can attatck each other 20090627 14:36:30< boucman> that makes M*N complexity 20090627 14:36:39< Crab_> boucman: so, we already have it :) 20090627 14:36:51< boucman> huh ? 20090627 14:37:12< boucman> again, the complexity is not building the list, as you say we already have the list 20090627 14:38:13< boucman> the long part is actually evaluating each moves, and the point of the filtering is to filter out most useless moves before calling the long and complicated "evaluate the move" formula 20090627 14:38:35< boucman> I don't think data-caching can avoid that 20090627 14:38:37< Crab_> boucman: yes. but it can be done in steps 20090627 14:39:53< Crab_> boucman: 1) get the full move list 2) for all units, filter on unit1 3) intersect [1] with [2] 4) for all units, filter on unit2 5) intersect [3] with [4] 6) do a filter on (unit1,unit2) on remaining moves. 20090627 14:40:06< Crab_> 1,3,5 are c++ 20090627 14:40:12< Crab_> 2,4,6 are fai 20090627 14:40:24< boucman> Crab_: yes, that's the plan 20090627 14:40:26< Crab_> c++ complexity is N*M 20090627 14:40:32< boucman> apparently we agree but can't understand each other 20090627 14:40:45< Crab_> fai complexity is N+M+'whatever left of N*M after two previous filters' 20090627 14:40:45< Dragonking> Crab_: If 2 is fai we get variants of callable -> hence casting 20090627 14:41:03< Crab_> Dragonking: no 20090627 14:42:01< Crab_> Dragonking: (2) is 'unit_map &units_ = get_info().units, convert unit_map to fai data structure, run a fai filter on it 20090627 14:42:31< Dragonking> And as result you get variant 20090627 14:42:37< Dragonking> Full of callable things 20090627 14:42:39< Crab_> Dragonking: you have a list of units, and you want to return a list of units. in fai, this requires casting ? 20090627 14:43:24< Dragonking> Crab_: Define 'return' in fai 20090627 14:43:39< Dragonking> All fai can do and all it can operate on are variants 20090627 14:44:06< Crab_> ok, understood. so, let is be 'casting'. 20090627 14:44:35< boucman> iiuc, Dragonking, what worries you is the cpp_unit<=>fai_unit casting 20090627 14:45:29< Dragonking> Crab_: If you want to get 3 done in C++ you will get form fai step 2 variant of type list, full of variants of type callable 20090627 14:45:38< boucman> cpp=>fai can't be avoided (it can be cached, thoug) fai=>cpp could maybe be avoided, or the cost heavily reduced in multiple ways 20090627 14:46:01< Dragonking> boucman: That's my point, once moving to fai, stay there 20090627 14:46:34< Crab_> Dragonking, well, we can also do it as 'call fai N times on specific units, get bool from fai' 20090627 14:46:49< Dragonking> And that's what we want aviod form the start. 20090627 14:47:02< boucman> or 'keep a pointer to cpp unit in the fai object' 20090627 14:47:13< Dragonking> boucman: It is kept 20090627 14:47:22< Dragonking> boucman: But we need to cast to get it 20090627 14:47:33< boucman> well, then the cast fai=>cpp is almost free, I guess 20090627 14:47:47< Dragonking> I don't know how free it is 20090627 14:48:12< Dragonking> dynamic_cast(variant.as_callable() ) 20090627 14:48:26< Dragonking> unit_callable stories unit and location it stands on 20090627 14:48:54< boucman> Dragonking: is dynamic_cast that costy ? 20090627 14:49:10< Dragonking> And (hopefully) noone messes up filter formula to return other type than unit_callable - if so, either we check for null value after casting, or have segfault 20090627 14:49:14< boucman> it's not a rewrite of the object, it's only a check of the underlying type IIUC 20090627 14:50:21< Dragonking> I'm not an expert, hence I started discussion :) 20090627 14:50:43< boucman> neither am I... that would be a question for our C++ experts :P 20090627 14:50:56< Crab_> Dragonking: have you seen our ai profiling graphs ? 20090627 14:51:04< Dragonking> Crab_: Not really 20090627 14:51:07< Crab_> such as ftp://ftp.terraninfo.net/wesnoth/ai_2009may16_r35649_bs600.jpg 20090627 14:51:16< Dragonking> And seriously, I should work on project now.. :(((((( 20090627 14:51:45< Dragonking> Crab_: wow nice graph 20090627 14:51:46< Crab_> then, imo, it's better to 'write a simple implementation then profile it and see how it turns out' 20090627 14:52:20< Crab_> the biggest time killer so far (especially in large maps), is default_ai::move_to_targets 20090627 14:52:24< Dragonking> Ok, I'll just write it with casting ans see how it turns out 20090627 14:52:35< Crab_> s/default_ai::move_to_targets/ai::ai_default::move_to_targets 20090627 14:55:26-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev 20090627 15:09:11-!- mjs-de [n=mjs-de@vpw.wh.Uni-Dortmund.DE] has quit [Read error: 60 (Operation timed out)] 20090627 15:30:08< maxy> what program creates those graphs? 20090627 15:35:21< Crab_> maxy: google performance tools gives the data. see http://ironalbatross.net/wiki/index.php5?title=Google_Performance_Tools 20090627 15:36:07-!- viktor [n=chatzill@193.86.150.33] has joined #wesnoth-dev 20090627 15:38:25-!- ardesh__ [n=ardesh@port-92-206-21-87.dynamic.qsc.de] has quit [Read error: 60 (Operation timed out)] 20090627 15:38:43< maxy> thanks 20090627 15:40:14-!- ardesh__ [n=ardesh@port-92-206-106-126.dynamic.qsc.de] has joined #wesnoth-dev 20090627 15:52:30-!- crimson_penguin [n=ben@64.201.60.211] has joined #wesnoth-dev 20090627 15:58:23-!- BenUrban_ is now known as BenUrban 20090627 16:00:05-!- viktor [n=chatzill@193.86.150.33] has quit ["ChatZilla 0.9.85 [Firefox 3.0.11/2009060308]"] 20090627 16:32:26< silene> Dragonking, boucman: dynamic_cast is slow; more precisely it is O(n) with n the number of ancestors of the current object; depending on the system and on how templated your code is, each check may require scanning several KB of memory 20090627 16:32:55< boucman> ok, thx 20090627 16:33:33< boucman> in our case I guess N=1 so it should be ok, but we'll have to check that with perf measures 20090627 16:40:50< Dragonking> boucman: Number of ancestors of formula_callable is more than one. 20090627 16:40:59< Dragonking> silene: thanks 20090627 16:41:30< boucman> Dragonking: oh, I thought the structure was simpler than that 20090627 16:42:03< Dragonking> boucman: hmm... depends if I understood silene correctly 20090627 16:42:43< Dragonking> "number of ancestors" as number of classes derived form it, or as "levels" of classes derivedfrom it? 20090627 16:43:10< boucman> number of class it is derived from, I guess 20090627 16:43:10< silene> when doing dynamic_cast(new B()); the complexity is the number of classes C between A and B 20090627 16:43:12-!- giusef [n=giusef@unaffiliated/giusef] has quit [Read error: 113 (No route to host)] 20090627 16:44:02< Dragonking> boucman: Then terrain_callable, location_callable, unit_callable, unit_type_callable, attack_.., map_.. move_map...., and some more 20090627 16:44:57< boucman> no, these are "brothers" of B, not class between A and B IIUC 20090627 16:45:03< Dragonking> boucman: True 20090627 16:45:43< Dragonking> So actually not number of classes derived but these "levels" of inheritance 20090627 16:46:25< boucman> that's what I understand, silene, are we correct ? 20090627 16:47:02< silene> Dragonking: no, not levels, because if you have multiple inheritance, you may get lost when visiting the ancestors, so you have to visit all the ancestors, not just the one that are in a straightline from A to B 20090627 16:48:16< silene> boucman: yes, if they are just brothers, they don't matter 20090627 16:48:28< Dragonking> silene: Ok, good to know. 20090627 16:48:55< boucman> Dragonking: well, let's stay with our current plan (test and measure the impact) we'll see if it's a problem 20090627 16:49:12-!- Tigge [n=tigge@bacchus.olf.sgsnet.se] has quit [Read error: 104 (Connection reset by peer)] 20090627 16:49:35< Dragonking> boucman: ok 20090627 16:49:48< Dragonking> boucman: I'll doe it after monday most likely 20090627 16:50:07< boucman> ok 20090627 16:51:17< Dragonking> I want to finish coding part of my SoC (and fix bugs that I am aware about) before 1st July, and after this only focus on formula-part of my SoC 20090627 16:52:31< boucman> ok, make sense 20090627 17:07:00-!- Tigge [n=tigge@bacchus.olf.sgsnet.se] has joined #wesnoth-dev 20090627 17:09:39-!- EdB [n=edb@194.12.95-79.rev.gaoland.net] has joined #wesnoth-dev 20090627 17:23:01< CIA-53> crab * r36422 /trunk/src/ai/ (6 files in 3 dirs): ai_composite: new candidate action: testing_ai_default::get_villages_phase 20090627 17:28:38-!- EdB [n=edb@194.12.95-79.rev.gaoland.net] has quit [Remote closed the connection] 20090627 17:32:01< boucman> Crab_: prooreading 20090627 17:32:06< boucman> what will be your next commit ? 20090627 17:32:30< Crab_> ai_default::move_leader_to_keep as ai::candidate_action 20090627 17:32:54< boucman> ok, should not be very long, most of the pieces are in place now 20090627 17:32:57< Crab_> then ai_default::do_recruitment as ai::candidate_action 20090627 17:32:59-!- Tigge [n=tigge@bacchus.olf.sgsnet.se] has quit [Read error: 104 (Connection reset by peer)] 20090627 17:33:13< Crab_> today 20090627 17:33:20< boucman> cool 20090627 17:35:23< Crab_> note the way I now handle is_gamestate_changed() in candidate_action::execute 20090627 17:37:17< Crab_> s/candidate_action::execute/get_villages_phase::execute 20090627 17:37:33< boucman> i'm looking at it right now 20090627 17:37:47-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has quit [Remote closed the connection] 20090627 17:40:15< boucman> ok, Crab_ a couple of questions 20090627 17:40:18< Crab_> ok 20090627 17:40:36< boucman> why do you refresh the leader variable in the for loop 20090627 17:40:47< boucman> (btw, we try to use "foreach" as much as possible) 20090627 17:41:04< Crab_> boucman: mostly copypasting from old code now. 20090627 17:41:09< boucman> ok 20090627 17:41:15< boucman> that's a good enough answer for me 20090627 17:41:46< Crab_> boucman: after I copypaste everything needed for a 'complete ai', it'll be time to get rid of some evil code and improve it 20090627 17:42:08< boucman> yes, that's why I said copy/paste was a good answer at that point... 20090627 17:42:30< boucman> the primary goal of your SoC is that the AI code is clean and manageable 20090627 17:42:49< boucman> improving the AI is the obvious goal, but let's not do step 2 until step 1 is done :) 20090627 17:45:27< Crab_> :) 20090627 18:03:35-!- ardesh_ [n=ardesh@port-92-206-113-70.dynamic.qsc.de] has joined #wesnoth-dev 20090627 18:15:42-!- ardesh__ [n=ardesh@port-92-206-106-126.dynamic.qsc.de] has quit [Read error: 60 (Operation timed out)] 20090627 18:28:42-!- Doppp|EeePC [n=aasdasd@c-67-171-96-240.hsd1.pa.comcast.net] has quit [Read error: 110 (Connection timed out)] 20090627 18:34:46< CIA-53> crab * r36423 /trunk/ (5 files in 4 dirs): ai_composite: new candidate action: testing_ai_default::move_leader_to_keep_phase 20090627 18:35:35< Crab_> boucman: note the way I'm using move_result_ptr field in that candidate action 20090627 18:35:45< boucman> checking right away 20090627 18:36:21< boucman> Crab_: you've accidentally added a file : Added: trunk/src/ai/default/.ai.cpp.swp 20090627 18:37:02< Crab_> boucman: yes 20090627 18:37:23< CIA-53> crab * r36424 /trunk/src/ai/default/.ai.cpp.swp: remove accidentially added file 20090627 18:40:02< boucman> interesting indeed 20090627 18:40:21-!- ABCD [n=ABCD@wikipedia/ABCD] has quit [Read error: 104 (Connection reset by peer)] 20090627 18:40:57< Crab_> the main advantage is the 'reuse' of all checks which determine 'is the move allowed ?' 20090627 18:41:10< boucman> ok 20090627 18:41:22-!- ABCD [n=ABCD@wikipedia/ABCD] has joined #wesnoth-dev 20090627 18:44:54-!- Sapient [n=sapien-x@66.56.60.141] has joined #wesnoth-dev 20090627 18:45:31< Sapient> esr: looks like a missed type in the Drake Fighter description... 20090627 18:45:45< esr> ? 20090627 18:45:48-!- ilor [n=ilor@wesnoth/developer/ilor] has joined #wesnoth-dev 20090627 18:45:55< Sapient> "to swordsman" -> "to swordsmen" 20090627 18:46:15< esr> Oh. You can fix if you like. 20090627 18:46:41< Sapient> my checkout is pretty ancient 20090627 18:46:44< ilor> Soliton: is there a solid way of reproducing the networking issue on trunk server? 20090627 18:46:47< Sapient> moving day here 20090627 18:47:04< Soliton> ilor: worked for me when i tried. 20090627 18:47:11< Soliton> ilor: what did you try? 20090627 18:47:47< ilor> Soliton: created a 3p world conquest game on trunk server and joined it with 3 clients 20090627 18:48:17< Soliton> ok, the creation should not work iirc. let me try again. 20090627 18:49:16< Soliton> yep, i get client disconnected right away. 20090627 18:49:48< Soliton> ilor: loading a savegame works for you as well then? 20090627 18:50:35< Soliton> i've tried with latest trunk just now, btw. 20090627 18:50:52< Soliton> sounds like it is os dependent. 20090627 18:51:21< Soliton> i'll try reverting that commit i mentioned. unfortunately a simple revert produces a conflict... 20090627 18:51:25< ilor> Soliton: I'm trying with ubuntu 20090627 18:51:47< ilor> Soliton: wait a sec I'll give you id's of the 2 revs you need to revert 20090627 18:51:57< Soliton> ok, cool. 20090627 18:52:11< Soliton> ilor: you're trying right now and it works? 20090627 18:52:24< Soliton> with ubuntu i mean. 20090627 18:52:30< ilor> Soliton: yes 20090627 18:52:35< Soliton> ok, odd. 20090627 18:52:52< ilor> unless I messed up the two binaries which has a nonzero chance of happening :) 20090627 18:53:17< ilor> Soliton: revert 35738 and 35734 20090627 18:54:24 * Soliton recompiles. 20090627 18:56:17< ilor> Soliton: yep I mixed up the binaries and was testing on the one with these 2 reverted. WIthou them I get the error 20090627 18:56:33< Soliton> ilor: ah, great. 20090627 18:57:28< Soliton> well, less so for portability since i assume on windows it works fine. 20090627 18:58:17< ilor> Soliton: the actual problem was that on dirty client quits I had the windows version of wesnothd get into an infinite loop in some cases 20090627 18:58:32-!- Tigge [n=tigge@bacchus.olf.sgsnet.se] has joined #wesnoth-dev 20090627 18:58:35< Soliton> right. 20090627 18:58:57< Soliton> and according to SDL docs the current code should be correct afair. 20090627 19:00:22< Sapient> cya later, have fun. 20090627 19:00:22-!- Sapient [n=sapien-x@wesnoth/developer/sapient] has left #wesnoth-dev [] 20090627 19:03:38 * Soliton confirms that reverting those commits fixes the problem. 20090627 19:09:30< ilor> I guess reverting them and figuring out a different workaround for the windows wesnothd problem is the way to go 20090627 19:11:29< ilor> loonycyborg: is it possible to make scons use a different build directory than "build"? 20090627 19:12:21< Soliton> looks hardcoded. 20090627 19:13:29< ilor> I could use a system type -dependant dir name. Using the same git repo works fine when switching windows/linux, but using the same build dir does not ;) 20090627 19:16:58-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20090627 19:18:20< Crab_> ilor: mount something on top of build dir in linux ;) 20090627 19:19:08< Crab_> (using something simular to FreeBSD's mount_nullfs ) 20090627 19:19:55< loonycyborg> Actually, perhaps I could make that dir relocatable.. 20090627 19:27:42-!- Rrenys [n=rrenys@81-20-159-197.levira.ee] has joined #wesnoth-dev 20090627 19:28:01< CIA-53> ilor * r36425 /branches/1.6/src/network_worker.cpp: revert the networking changes from r35734 and r35738 20090627 19:31:23< CIA-53> ilor * r36426 /trunk/src/network_worker.cpp: revert the networking changes from r35734 and r35738 20090627 19:31:59< Soliton> ilor: you could put the code in #ifdef _WIN32. 20090627 19:32:32< ilor> Soliton: I'll reboot to windows in a bit and figure out something reasonable 20090627 19:33:45< Soliton> k 20090627 19:34:19-!- ilor [n=ilor@wesnoth/developer/ilor] has quit [Read error: 54 (Connection reset by peer)] 20090627 19:42:18-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev 20090627 19:44:41-!- Noyga is now known as Miamotte 20090627 20:02:13-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has joined #wesnoth-dev 20090627 20:05:43-!- ardesh__ [n=ardesh@port-92-206-117-194.dynamic.qsc.de] has joined #wesnoth-dev 20090627 20:07:56-!- ardesh_ [n=ardesh@port-92-206-113-70.dynamic.qsc.de] has quit [Read error: 60 (Operation timed out)] 20090627 20:10:01-!- Miamotte is now known as Noyga 20090627 21:03:54< Crab_> boucman: I wanted to discuss ai_default targets a bit. 20090627 21:04:32< boucman> sure 20090627 21:05:02< boucman> what's up with it ? 20090627 21:05:05< Crab_> ai_default has a struct target, which can be of different types ( enum TYPE { VILLAGE, LEADER, EXPLICIT, THREAT, BATTLE_AID, MASS, SUPPORT }; ) 20090627 21:05:19< Crab_> it is used for the following thing: 20090627 21:05:51< Crab_> 1) evaluating recruit movement ( 'recruits that can reach targets in less time are better') 20090627 21:06:08-!- YogiHH [n=chatzill@c156022.adsl.hansenet.de] has joined #wesnoth-dev 20090627 21:06:45< Crab_> 2) moving units towards targets, this giving ai 'purpose' and causing its units to move 'to the same places', thus achieving some grouping 20090627 21:07:31< boucman> this is an ai-wide data, it's not a goal attached to a single unit, is it ? 20090627 21:07:41< Crab_> ai-wide 20090627 21:07:58< Crab_> 3) communicating between different ai phases (for example, a wounded unit can be classified as 'target that needs support because it's in danger' in get_healing phase, and this info will be used for moving units in other phase 20090627 21:08:00< boucman> ok 20090627 21:08:08< nickbp> http://slickdeals.net/permadeal/21951 20090627 21:08:33< boucman> sounds like a design that was hacked over an existing AI afterward 20090627 21:09:13< Crab_> boucman: and the question is: how this fits in RCA ideology ? 20090627 21:09:47< boucman> not well ;) 20090627 21:09:51< Crab_> and the secondary question is: what should be done to move_to_targets to make it faster (it's a main time-killer on big maps atm) 20090627 21:10:22< boucman> ok, first question first... 20090627 21:10:44< boucman> is that target thing causing problems when porting to the phase system ? 20090627 21:11:55< Crab_> boucman: it's not that 'causing problems' so far (I hasn't got to move_to_targets phase so far), but 'just omitting it' will make the ai more stupid. 20090627 21:12:34< boucman> ok 20090627 21:13:29< CIA-53> loonycyborg * r36427 /trunk/SConstruct: Added a scons option to relocate build/ dir. 20090627 21:13:49< boucman> hmm this is a bad case of communitcation between steps... 20090627 21:13:50< Crab_> current move_to_targets it's a time killer because on big maps, and with many possible targets, it doesn't matter much how we move, as long as we move 'in general direction' of said targets, and cache the general 'best route' to a said targets. But, current implementation invokes A* a lot to calculate "really best" routes, which is slow on big maps (say BIG hello to Showdown and those animating bats) 20090627 21:14:24< nickbp> agree with crab_ 20090627 21:15:38< boucman> Crab_: ok, I agree too, but that's a completely different problem 20090627 21:15:44< nickbp> if you wanted, could have it use A* on small maps (or for small distances) then an approximation for large maps/dists 20090627 21:15:52< Crab_> but that slowdown is a secondary question atm (it has to be kept in mind, thought) 20090627 21:16:33< boucman> indeed 20090627 21:16:48< boucman> the problem is how to get rid of that target thing or redesign around it 20090627 21:17:06< Crab_> nickbp: somebody on forums suggested using clustering algorithms to figure out a general 'direction where to send forces', and then sending a suitable portion of units to that 'general direction'. 20090627 21:17:36< nickbp> disclaimer: im new here so im fuzzy on details 20090627 21:18:17< Crab_> boucman: yes. so, the question is more like "in RCA-based AI, how do individual candidate actions communicate among themselves and communicate the rest of the ai?" 20090627 21:18:30< Crab_> s/ the rest/to the rest 20090627 21:18:40< boucman> the rca philosophy is that they don't :) 20090627 21:19:04< boucman> they fight each other to have a chance to move the pawns their way ;) 20090627 21:19:43< Crab_> boucman: and, what about "in RCA-based AI, how do individual candidate actions communicate with their future (next turn) selves?" 20090627 21:20:35< Crab_> ( if a CA has moved a unit and has a specific plan for it on next turn ) 20090627 21:20:35-!- Doppp|EeePC [n=aasdasd@c-67-171-96-240.hsd1.pa.comcast.net] has joined #wesnoth-dev 20090627 21:21:00< Crab_> ( for example, if a CA tries to move leader to keep which is only reachable in 3 turns ) 20090627 21:21:40< boucman> Crab_: then it had the best score for the leader, this turn and probably will next turn 20090627 21:21:52< boucman> and if it doesn't, it means something else is more important 20090627 21:21:57< Crab_> boucman: unfortunately, this is tricky. see: 20090627 21:22:04< boucman> hysteresis ? 20090627 21:22:21< Crab_> imagine the "mountain--------forest---------plain--------keep" map, with leader on mountain 20090627 21:22:35< Crab_> imagine that while the leader is on mountain, CA 'move to keep' wins. 20090627 21:22:43< Crab_> it moves the leader closer to keep, on forest 20090627 21:23:03< Crab_> imagine that while the leader is on forest, CA 'move to best defended location' wins 20090627 21:23:13< Crab_> it moves the leader back to mountain 20090627 21:23:24-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has quit [Remote closed the connection] 20090627 21:23:26< Crab_> voila - the leader jumps around each turn :) 20090627 21:23:38< boucman> yes, hysteresis :) 20090627 21:24:00< boucman> well, i never said RCA was perfect 20090627 21:24:10< YogiHH> Crab_: why should 'move to best defended location' win all of a sudden if it did not before? 20090627 21:25:26< boucman> Crab_: RCA doesn't have an "overall plan" that's not the way it works... 20090627 21:25:37< Crab_> YogiHH: because each candidate action is not perfect, and most of them have certain 'locality' (they play with srcdst maps which give possible moves for this turn only, so they naturally consider the situation in an area of a map which is closer to the unit) 20090627 21:25:52< boucman> but it's true that there are some strategic vs tactical vs indiviual aspect that needs to be discussed 20090627 21:26:10< Crab_> boucman: it is an issue with recruiting - because leader can only recruit on keep 20090627 21:26:22< Crab_> and keeps can be separated by more than 1 turn of movement 20090627 21:26:55< Crab_> also, this is a issue with villages - because it is needed to plan 'village grabbing' ahead of time, to grab them quickly 20090627 21:28:52< boucman> hmm 20090627 21:29:00< Crab_> also, this is an issue with 'group attacks' - a concern raised by Aethaeryn on irc, two days ago. " a little disappointing to fight on the larger maps, then, even giving them all 800g "+ "the AI starts trickling and isn't as strong as if they fought in packs or "waves" " 20090627 21:29:39< boucman> Crab_: RCA had originally been thought as an easy way to provide plugable tactics to a more general AI 20090627 21:30:09< boucman> we might have a more generic (maybe C++) AI and use RCA more for special cases 20090627 21:30:38< Crab_> boucman: it is not a problem with rca in general. the problem is that our current rca provides 1-turn tactics only :) 20090627 21:31:11< boucman> hehe 20090627 21:31:23< boucman> Crab_: we need a way for a unit to "reserve" another unit 20090627 21:31:32< Crab_> and some things just need more than 1 turn to complete. and recalculating them each turn is sometimes prone to 1) slowness 2) hysteresis 20090627 21:32:08< boucman> Crab_: on the other hand, multi-turn techniques need to be interupted because something didn't work as expected 20090627 21:32:11< Crab_> boucman: yes 20090627 21:32:29-!- ABCD_away [n=ABCD@wikipedia/ABCD] has joined #wesnoth-dev 20090627 21:32:35< Crab_> boucman: so, the targets were seen as 'hints' to the ai. a hints to be considered, but not necessarily obeyed 20090627 21:32:43-!- ABCD [n=ABCD@wikipedia/ABCD] has quit [Read error: 104 (Connection reset by peer)] 20090627 21:33:11< Crab_> for example, after each attack, ai_default added the location of the attack to a cache, to favor attacking near that location on the same turn 20090627 21:33:13< boucman> you're talking of the current default_ai targets her e? 20090627 21:33:17< Crab_> yes 20090627 21:33:54< Crab_> and the primary question is 'what to do with those targets in rca?' 20090627 21:34:38< boucman> well, personally I don't thinkg that "ganging up" should be planned 20090627 21:34:50< boucman> each attack makes the target unit weaker => a better target 20090627 21:35:16< boucman> but let's still think of how to implement it, we might need the engine to support something similar at some point 20090627 21:35:44-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit [Remote closed the connection] 20090627 21:35:49< Crab_> and note that there's additional big thing which needs 'planning something for several turns in advance' 20090627 21:35:57< Crab_> this thing is 'time of day' 20090627 21:36:21< boucman> true 20090627 21:36:29< boucman> i'm not good enough a player to do AI design ;) 20090627 21:36:30< Crab_> a human player *knows* that if it's morning now, it'll be two turns of day afterwards 20090627 21:37:05-!- loonycyborg [n=sergey@79.139.136.167] has joined #wesnoth-dev 20090627 21:37:30< boucman> yeah "rediscovering" your plan every turn has its limit 20090627 21:37:33< Crab_> so, " each attack makes the target unit weaker => a better target" - not always the best option - sometimes it's better to wait for better time of day and THEN attack with all units. 20090627 21:38:03-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit [Remote closed the connection] 20090627 21:38:11< boucman> Crab_: don't we already have a way to attach some data/save global variable for FAI ? 20090627 21:38:22-!- loonycyborg [n=sergey@79.139.136.167] has joined #wesnoth-dev 20090627 21:38:32< boucman> a formula "talking to itself" is a problem that might be already solved 20090627 21:38:44< boucman> it's the "talking to other that's tricky 20090627 21:40:32< Crab_> boucman: note that traditionally, (as far as I see), that 'sometimes it's better to wait for better time of day and THEN attack' was emulated by setting lower aggression value in 'wrong' time of day 20090627 21:41:19< boucman> Crab_: the "best" way would probably to use your "ai perception" thing 20090627 21:41:37< boucman> adding stuff that's not striclty perception, like targets and stuff like that, 20090627 21:41:54< boucman> this extra step could be filled by other chunk of AI 20090627 21:42:03< Crab_> boucman: this doesn't solve that problem 20090627 21:42:49< Crab_> please see data/ai/formula/poisoner_eval.fai 20090627 21:43:15< boucman> ok, opened 20090627 21:43:54< Crab_> this formula ignores aggression and 'quality-like' perception 20090627 21:44:18< Crab_> so, it works the same in different time of days 20090627 21:44:39< Crab_> (and ignores 'target' hints, too) 20090627 21:44:57< boucman> Crab_: well, somehow, we'll have to have formula consider hints, 20090627 21:45:36< boucman> if we "reserve" units, other formula still need to consider the reserved units in their strategy, even if they don't move them 20090627 21:46:05< Crab_> boucman: what do you mean by "reserving" ? 20090627 21:46:38< boucman> if an ai can somehow tell the engine "unit A is mine for the next three turn" 20090627 21:46:43-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has joined #wesnoth-dev 20090627 21:46:53< boucman> the engine can refuse all moves except by the reserving ai 20090627 21:47:14< boucman> however other ais might need to consider that unit's impact when looking at their own strategy 20090627 21:48:17< Crab_> boucman: one way to do this is to take advantage of the fact that candidate actions are stateful, so they can hold a cache of 'reserved units and planned movements' and return higher scores when it's possible to do something with 'reserved unit' 20090627 21:49:06< boucman> hehe 20090627 21:49:09< boucman> yeah makes sense 20090627 21:50:47< Crab_> but, this doesn't solve a problem of ai-wide coordination of moves. 20090627 21:51:14< Crab_> c++ ai_default has sometimes-not-working 1) aggression+caution 2) targets 20090627 21:52:02< boucman> Crab_: if we want the different AI stages/RCA to communicate we have to invent and force on them a common language 20090627 21:52:14< Crab_> in c++ ai, ai perception will be a working method to 'coordinate and tune' behavior (since c++ ai tends to do things like 'evaluate all possible variants, assign a score and pick best score' ) 20090627 21:52:29< boucman> be it through objectives, through a way for ai to modify the way we score moves, or through bluntly refusing some moves 20090627 21:52:41-!- ancestral [n=ancestra@97-116-110-107.mpls.qwest.net] has joined #wesnoth-dev 20090627 21:57:10< Crab_> boucman: ok, lets look at that poisoning candidate move again 20090627 21:58:00< boucman> k 20090627 21:59:10< Crab_> what about doing that "a way for ai modify the way we score moves" by making that fai return not fixed value, such as 2, but "2+X, where X = evaluate_action_value(attack from A to B)" 20090627 21:59:34< Crab_> and that evaluate_action_value will be ai-wide aspect 20090627 22:00:16< Crab_> that can consistently assign score to a move 20090627 22:00:32< Crab_> (this was discussed some time ago, but then there was too early for that) 20090627 22:00:48< boucman> well, writing this "evaluate_action_value" would be the same as writing a whole AI 20090627 22:00:53< boucman> it's just pushing the problem around 20090627 22:01:12< Crab_> boucman: no, since we do not return just "evaluate_action_value(attack from A to B)" 20090627 22:01:23< Crab_> we return, in that case, 2+"evaluate_action_value(attack from A to B)" 20090627 22:01:54< Crab_> so, "evaluate_action_value", or "evaluate_attack_value", can be simpler - just an adjusting factor 20090627 22:02:18< Crab_> and that "2" will represent our human intervention 20090627 22:02:22< boucman> I don't like that... I can't put my finger on why, but I don't think it'll work 20090627 22:02:40< boucman> or we need a very precise frontier on what exactly would that evaluate_attack_value do 20090627 22:04:43-!- MikeJB [n=Michael@c-98-204-170-162.hsd1.md.comcast.net] has joined #Wesnoth-dev 20090627 22:05:50-!- ABCD_away [n=ABCD@wikipedia/ABCD] has quit [Client Quit] 20090627 22:06:03< Crab_> boucman: it is, in fact, already implemented once, in ai_default :) 20090627 22:06:33< boucman> yeah, and soon we'll want to make it plugable etc... 20090627 22:06:47< boucman> so we're jsut pushing the problem around but not solving anything 20090627 22:07:22< Crab_> boucman: it's already pluggable since it's pushed up to default_ai_context 20090627 22:08:02-!- ABCD [n=ABCD@wikipedia/ABCD] has joined #wesnoth-dev 20090627 22:08:27< boucman> in what way is it pluggable ? 20090627 22:09:05< Crab_> boucman: ai_default takes an object implementing default_ai_context as a constructor arg. 20090627 22:09:34< Crab_> the point is just making candidate actions 'consider' not only their opinion, but AI's opinion, too, when assigning a score to themselves. 20090627 22:10:27-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit [Remote closed the connection] 20090627 22:10:42< boucman> no, I get it 20090627 22:10:57< boucman> the point is to have other AI contexts than the default one, 20090627 22:11:04-!- Noyga [n=lame-z@wesnoth/developer/noyga] has left #wesnoth-dev ["Quitte"] 20090627 22:11:37< boucman> Crab_: what I fear with all that is that explaining to people how the pluggable AI works is becoming more and more complicated, and that in itself is a sign of bad design 20090627 22:12:20< Crab_> boucman: well, it was that complicated from the start, it's not becoming any more complicated. 20090627 22:12:36< Crab_> boucman: the question is "how do I assign a score to my candidate action?" 20090627 22:12:44< boucman> Crab_: yeah, but previously, the only advice for writing ai was 20090627 22:12:53< boucman> just implement class XXX that does everything 20090627 22:13:12< boucman> none of that complicated "colaborate with other ais thing ;) 20090627 22:14:03< Crab_> boucman: I think that 'write a piece which collaborates with other pieces via a well-defined interface' is simpler than 'reimplement the entire ai from scratch' :) 20090627 22:14:16< boucman> oh, so do I 20090627 22:14:29< boucman> :) 20090627 22:14:59< boucman> the problem is that our interface my get out of the "well defined" zone and into the "confusing and complicated" zone faster than you think 20090627 22:16:00< Crab_> it reminds me of a particular piece of postgresql documentation: "writing a procedural call handler is easy. Here's the template: (template is written). Only a few thousand lines of code have to be added instead of the dots to complete the call handler. " 20090627 22:16:19-!- Netsplit leguin.freenode.net <-> irc.freenode.net quits: Doppp 20090627 22:16:38< boucman> héhé 20090627 22:16:42-!- Netsplit over, joins: Doppp 20090627 22:17:31< Crab_> also note that current situation is not that good either. It is *very hard* to say in human language, what *exactly* aggression parameter does :) 20090627 22:18:15< boucman> Crab_: yes, 20090627 22:18:26< boucman> let's not discuss current situation, I know it awfull 20090627 22:18:36< boucman> lets just continue discussing how we want to change it 20090627 22:18:49< boucman> ok, let me start a different approch to AI 20090627 22:19:18< boucman> we have the "phase" which is temporal 20090627 22:19:31< boucman> and we have RCA which allows simple moves to be compared 20090627 22:19:37-!- Netsplit leguin.freenode.net <-> irc.freenode.net quits: Doppp 20090627 22:20:00< boucman> however, I think there is a "top down" approch that we are missing, and that communication we are discussing is just a way around that concept... 20090627 22:20:16< Crab_> also note that "allows simple moves to be compared" is not that true 20090627 22:20:30< boucman> yes, I know, I was simplifying 20090627 22:20:33< Crab_> we don't have any scoring system so far. 20090627 22:20:52< boucman> Crab_: RCA is a way of scoring... heach move scores itself, but that's not the point 20090627 22:21:04< Crab_> it scores, but it is not that suited for comparison :) 20090627 22:21:12< boucman> what we are missing is a "large to detail" layer 20090627 22:21:22-!- Netsplit over, joins: Doppp 20090627 22:21:22< Crab_> what will be in that layer ? 20090627 22:21:30< boucman> /layer/layering 20090627 22:21:55< boucman> a way to separate "strategy" (recruit, move units toward fight) 20090627 22:22:03< boucman> + ToD 20090627 22:22:13< boucman> from tactics (grouping of units) 20090627 22:22:32< boucman> and individual moves (heal, run away) 20090627 22:22:55< boucman> tactics and individual can be more or less merged, but we need a way to "plug strategies" and make sure the lower level respect the higher level strategies 20090627 22:23:00< Crab_> note that rca will be able to handle tactics just nice as individual units 20090627 22:23:26< Crab_> at least c++ ai is able to consider the effect of multiple attacks 20090627 22:23:38< boucman> yes, that's wha tI meant with merging these two, it's more the strategic side i'm interested in 20090627 22:23:39< Crab_> and fai will allow to make paired moves 20090627 22:24:03< Crab_> yes, I agree 20090627 22:24:33< boucman> (my typing is becoming awfull tonight :) ) 20090627 22:25:26< Crab_> and I'm saying that making a candidate action::score partly depend on some common criteria (=depend on higher level strategies) can be a solution. 20090627 22:25:29-!- MikeJB is now known as Aethaeryn 20090627 22:26:03< boucman> oh, so your evaluation would be "how much does that move match my strategy" 20090627 22:26:05< boucman> hmm 20090627 22:26:09< boucman> I didn't understand that 20090627 22:26:18< Crab_> "how much does that move match my strategy" is another, different, approach 20090627 22:26:49< Crab_> "how much does that move match my strategy" means that candidate action will return 1 score per strategy 20090627 22:26:50< boucman> well, I need to have a meaning to that scoring... "how good" doesn't make much sense to me... 20090627 22:27:49< boucman> imagine a formula about poison 20090627 22:27:58< Crab_> imagined 20090627 22:27:58< boucman> and consider "retreating weak units" 20090627 22:28:09< boucman> suppose we have a weak poisoner 20090627 22:28:14< Crab_> ok 20090627 22:28:32< boucman> should the poisoning formula's score be reduced because it doesn't retreat the weak unit, 20090627 22:28:53< boucman> or should the retreating be a separate formula ? 20090627 22:29:05< Crab_> 'retreating is a separate formula' 20090627 22:29:11< Crab_> but, we need to compare them 20090627 22:29:16< Crab_> the question is: how ? 20090627 22:29:47< boucman> Crab_: well, the current idea was "they compare themselves" 20090627 22:29:50< Crab_> how ? 20090627 22:30:00< boucman> we (the dev) tweak the score each formula return by hand 20090627 22:30:04-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Read error: 113 (No route to host)] 20090627 22:30:55< Crab_> we (the devs) are able to tweak the score each formula returns for each possible unit type, time of day, damage returned, aggression value, caution value, available gold, turns left in game, BY HAND ? 20090627 22:31:27< Crab_> that's why I want a formula to account at least for some parameters in the said tweaking. 20090627 22:31:50< boucman> Crab_: ok, i see your point 20090627 22:32:23< boucman> however, that tweaking needs to be heavily plugable, probably via formulas 20090627 22:32:38< Crab_> so, we can write : retreat candidate action will return 7.5+our_basic_tweaking_formula , and poisoning will return 12.2+our_basic_tweaking_formula 20090627 22:32:53< Crab_> yes. it'll be an 'aspect' in my terminology 20090627 22:33:10< nickbp> id picture that being a common formula where you just modify some multipliers depending on the conditions 20090627 22:33:23< Crab_> nickbp: yes, something like that 20090627 22:33:39< Crab_> that 7.5 and 12.2 represent our 'by hand' tweaking, and our_basic_tweaking_formula represents the 'formula part' of tweaking 20090627 22:33:54< nickbp> ie get the "caution value" multiplier for MASSIVE DAMAGE 20090627 22:34:01< boucman> i'm not sure if additive would be the way to go, wouldn't multiplicative be better ? 20090627 22:34:06< boucman> i'm not sure either way 20090627 22:34:19-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev 20090627 22:34:19-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit [Client Quit] 20090627 22:34:30< Crab_> boucman: this is for formula to decide :) since that "+" is in formula :)) 20090627 22:34:44-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev 20090627 22:35:02< boucman> oh, I thought it would be in the engine 20090627 22:35:04< Crab_> boucman: candidate action can return 2+our_basic_tweaking_formula*our_basic_tweaking_formula, if it so desires 20090627 22:35:08-!- maxy [n=maxy@84-74-83-103.dclient.hispeed.ch] has quit [] 20090627 22:35:10< boucman> and no, I'm afraid it can't be in the formula 20090627 22:35:13< Crab_> why ? 20090627 22:36:06< boucman> because the meaning of 'our_basic_tweaking' is an API, it has to have a guaranteed meaning, and probably a guraenteed range, and that influences heavily how the fomula uses it 20090627 22:36:26< boucman> moreover, the use has to be mandatory, so it makes more sense to apply it on the engine side 20090627 22:37:05< Crab_> boucman: but imagine that some candidate action might want to say: "hey, my score is 100, and I don't care :)" 20090627 22:37:17< Crab_> or "my score is 50 plus half of the standard bonus" 20090627 22:37:23< boucman> then that formula is wrong 20090627 22:37:51< Crab_> the meaning of 'our_basic_tweaking' is an API 20090627 22:38:01< boucman> we have to put a limit somewhere, you know we can't allow "everything" or the AI will be impossible to understand once it's heavily populated with interacting formulas 20090627 22:38:12< Crab_> boucman: ok. 20090627 22:38:22< Crab_> boucman: so, you think that multiplication will be better ? 20090627 22:39:20< boucman> Crab_: whe I write "i'm not sure" it means that i'm not sure ;) 20090627 22:39:29< boucman> i.e it's worth discussing 20090627 22:39:49< boucman> but once again, we need to decide of a scale 20090627 22:40:21< boucman> the question will also go with "can a formula handle non integers?" currently it can't IIRC 20090627 22:40:48< Crab_> boucman: "can a formula handle non integers?" should not affect our discussion :) 20090627 22:40:58< Crab_> boucman: because both me and DK promised to fix it :)) 20090627 22:41:29< boucman> ok :) 20090627 22:41:43< Crab_> note that + and * are the same for non-negative numbers 20090627 22:42:02< boucman> ?? 20090627 22:42:24-!- loonycyborg [n=kvirc@79.139.136.167] has joined #wesnoth-dev 20090627 22:42:42< Crab_> because ln(A*B)=ln(A)+ln(B), and ln is monotonic 20090627 22:43:37< Crab_> so, for positive A and B, it doesn't matter much what we pick - there exists such a rescaling of candidate action scores which will give us equal candidate action systems. 20090627 22:43:49< boucman> nobody can argue against math ;) 20090627 22:44:42< boucman> in that case, i'll follow you on additive, it might give us a better scale... and is easier to handle from an understanding point of view 20090627 22:46:36< Crab_> so, for us, the difference between + and * is mainly question like "how do we want to compare action with (own score=-1, helper score = 5) and action (own score=1, helper score = 1) 20090627 22:46:58< Crab_> A: -1+5=4, B: 1+1=2, A is picked and executed. 20090627 22:47:07< Crab_> A: -1*5=-5, B: 1*1=1, B is picked and executed. 20090627 22:48:21< boucman> hmm 20090627 22:48:34< Crab_> imagine an ai that is made very aggressive 20090627 22:48:38< Crab_> (by intent) 20090627 22:49:04< Crab_> it has a 'almost suicidal' attack possibility, which scores -1 by itself 20090627 22:49:37< Crab_> but it favors the 'style' the ai plays (aggressive), so it scores 5 by helper 20090627 22:50:05< Crab_> second action is turtle-style, which is not that bad and scores 1 by itself 20090627 22:50:39< Crab_> but it doesn't follow 'party line' - it's very cautions, so it gets 0.1 from helper 20090627 22:50:47< Crab_> what do we want the AI to pick ? 20090627 22:51:19< boucman> i don't know :) 20090627 22:51:37< Crab_> this is a general question (by picking other numbers the situation can change cardinally) 20090627 22:51:46< boucman> we are slowly moving our concept, let me describe a completely different way of writing AI 20090627 22:51:57< Crab_> the point I was trying to make than * cannot make <0 score to become >0 20090627 22:52:00< Crab_> but + can 20090627 22:52:04< boucman> which is related, but I mainly describe it to help the discussion 20090627 22:52:13< Crab_> I'm listening 20090627 22:52:23-!- Jazzy [n=Jazzy@sfDIAL-222.216-16-54.iw.net] has joined #wesnoth-dev 20090627 22:52:28< Jazzy> wowza 20090627 22:52:29< boucman> foreach possible move 20090627 22:52:41< boucman> foreach register formula 20090627 22:52:42< Jazzy> i use to play this game like a year ago and i never thought that there would be an irc for it on freenode 20090627 22:52:55< boucman> ask the formula to evaluate the move 20090627 22:53:00-!- Jazzy [n=Jazzy@sfDIAL-222.216-16-54.iw.net] has left #wesnoth-dev ["im.outta.here."] 20090627 22:53:01< boucman> endfor 20090627 22:53:06< boucman> sum all results 20090627 22:53:09< boucman> endfor 20090627 22:53:14< boucman> 20090627 22:53:49< boucman> this way, we have asked multiple formulas "what's the move worth for you" and we have ranked the move by adding the different formulas 20090627 22:54:03< boucman> (here, multipying can be used instead of addition) 20090627 22:54:28< Crab_> this is what we do in rca. but, we only search an interesting subset of possible moves to make it quicker. 20090627 22:54:29< boucman> with this type of AI, we can express both strategic and tactic consideration the same way 20090627 22:54:41< boucman> Crab_: yes and no 20090627 22:54:55< Crab_> and why 'sum all results' ? 20090627 22:55:10< boucman> with our current RCA, we don't sum the different evaluations of a given move 20090627 22:55:26< Crab_> ok 20090627 22:55:35< boucman> suppose that we have a move that is worth 5 for attacking, 0 for retrating and 0 for healing 20090627 22:55:46< Crab_> ok 20090627 22:55:57< boucman> and another that is worh 0 for attack, 3 for healing and 3 for retreating 20090627 22:56:13< boucman> current RCA would play the first move because it's worth 5 and has the top score 20090627 22:56:27< boucman> my approch would play the other move because it's worth 3+3 20090627 22:56:34< boucman> so the approches are not equivalent 20090627 22:57:06< boucman> philosophically very different if you see what i mean... 20090627 22:57:23< Crab_> well, nothing prevents our current rca to return the sum of '5+0+0' in the first case, and '3+3+0' in the second case 20090627 22:57:36< boucman> yes, there is 20090627 22:57:36< Crab_> so, technically, they are equivalent - only the order of the loops is changed 20090627 22:57:50< Crab_> philosophically, yes 20090627 22:57:56< boucman> currently each formula only evaluates the move it considers the best it doesn't evaluate all moves 20090627 22:59:26< Crab_> yes 20090627 22:59:53< boucman> Crab_: that would be probably easy to change considering the low number of formulas we have, but it's not equivalent 20090627 23:03:31< boucman> ok, you see what I mean, our "ask people to give us a move" philosophy seems to be reaching its limits, and I'm wondering if we should change... 20090627 23:03:49< Crab_> boucman: change to what ? 20090627 23:03:59< boucman> the philosophy 20090627 23:04:28< Crab_> how ? 20090627 23:04:30< boucman> hmm 20090627 23:04:35< boucman> let me think a little more 20090627 23:04:51< Crab_> and note that 'ask people to give us a move' is ok, the problem is with 'asking the people how good their proposed move is' 20090627 23:05:28< boucman> ok, i'm a bit lost now 20090627 23:06:00< Crab_> boucman: and see http://wesnoth.pastebin.com/m11bfb78e 20090627 23:06:12< Crab_> it is a certain variation of your example 20090627 23:07:27< boucman> ok, the change you did to the formula is the same needed for my idea (i.e each RCA returns a list of moves instead of a single move) 20090627 23:07:56< boucman> however my idea does not introduce a difference between "normal" candidate actions and "strategy" candidate actions 20090627 23:08:34< Crab_> boucman: my idea doesn't do it too :) since that foreach register formula can be 'inside' the candidate action. 20090627 23:08:45< Crab_> ( foreach strategy ) in my case 20090627 23:08:50< boucman> and I think it's better not to introduce that difference, because if a move is interesting from different "tactical" point of view they sum instead of ignoring each other 20090627 23:09:28< boucman> not sure what you mean here... 20090627 23:10:37< Crab_> http://wesnoth.pastebin.com/m419bfa28 20090627 23:11:39< boucman> Crab_: yes, but that way, when we add new strategies (or worth, when UMC add a new strategy) it's not taken into account 20090627 23:11:48< boucman> since the poisoner eval needs to be modified 20090627 23:12:05-!- Netsplit leguin.freenode.net <-> irc.freenode.net quits: nital 20090627 23:12:24-!- Netsplit over, joins: nital 20090627 23:13:39< Crab_> http://wesnoth.pastebin.com/m24b7d6d2 20090627 23:14:59< boucman> i still don't like the idea of having the formulas themselves take the formulas into account, 20090627 23:15:01< Crab_> that sum(map(..)) can be written as a separate engine-side function to simplify code 20090627 23:15:26< boucman> and you miss my point about different non-strategy formulas helping each others (though that point is open to discussion) 20090627 23:15:36< boucman> ok 20090627 23:15:45< Crab_> 'my point about different non-strategy formulas helping each others ' - can you reiterate ? 20090627 23:15:51< boucman> ok 20090627 23:16:48< boucman> suppose our AI has three RCA 20090627 23:16:56< boucman> 1) attack everything in range 20090627 23:17:02< boucman> 2) retreat for healing 20090627 23:17:07< boucman> 3) grab villages 20090627 23:17:15< Crab_> ok 20090627 23:17:43< boucman> we are wounded, there is a reachable unit, and an unowned reachable villagevillage 20090627 23:18:06< boucman> 1 returns 5 for attacking the unit, 2 and 3 return 0 20090627 23:18:24< boucman> 1 returns 0 for the village, 2 and 3 returns 3 20090627 23:18:36< Crab_> got it. you mean the situation where the same move is useful for multiple things at once? 20090627 23:18:40< boucman> yes 20090627 23:18:56< boucman> strategies are a good thing, but they don't cover that particular need 20090627 23:19:43-!- Netsplit leguin.freenode.net <-> irc.freenode.net quits: nital 20090627 23:19:50< Crab_> so, basically, in that approach, candidate actions are 'strategies', too ? 20090627 23:20:39< boucman> Crab_: well, at this point I see no reason to have two separate notions, but it doesn't mean I won't change my mind later 20090627 23:20:52< boucman> but as long as we can reduce the number of concepts, that's better 20090627 23:21:07< Crab_> the problem is more in 'the other direction' 20090627 23:21:17< Crab_> 'is strategy a candidate action' ? 20090627 23:22:03< Crab_> for example, strategy 'get more gold' - can it lead us to concrete actions ? 20090627 23:22:03< Crab_> for example, strategy 'get more unit worth' - can it lead us to concrete actions ? 20090627 23:22:03< Crab_> for example, strategy 'levelup faster' - can it lead us to concrete actions ? 20090627 23:22:12< boucman> well, a strategy or a tactical move is just scoring an action... on different criterias, so yes 20090627 23:22:26-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."] 20090627 23:22:49< Crab_> well, candidate actions are not just 'scoring an action'. see the src/ai/testing/ca.cpp 20090627 23:22:59-!- Netsplit over, joins: nital 20090627 23:23:38< boucman> in what way are they not ? 20090627 23:23:50< Crab_> they are more than that 20090627 23:24:11< Crab_> note that candidate actions there are 'constructive' - they all have a way to get a list of 'good possible moves', from which some moves can be picked 20090627 23:24:23< boucman> ok, I see your point 20090627 23:24:32< boucman> esp if an action returns multiple moves 20090627 23:24:46< Crab_> yes, esp if an action returns multiple moves. 20090627 23:25:01< Crab_> so, are the strategies constructive ? 20090627 23:25:18< Crab_> if they are, then they can be written as candidate actions 20090627 23:25:23< Crab_> and then your approach can work 20090627 23:25:49< boucman> i don't know, you tell me :) 20090627 23:25:54< Crab_> if they are not constructive, they are a different beast than candidate actions 20090627 23:26:04< Crab_> and then, they should be reduced to 'score helpers' 20090627 23:26:49< Crab_> I note that some poisoning .fai is an example of a constructive strategy 20090627 23:26:57< Crab_> and it lends itself well to your approach 20090627 23:27:31< Crab_> since it's weakness now (=ignoring all other stuff except poisoning) is a strength in your approach (were multiple stuff is added together ) 20090627 23:28:12< Crab_> I also note that it is hard to write difficult formulas in fai 20090627 23:28:52< boucman> yes, the complexity of programming RCA is reduced because if you don't want to handle a special case, it's somebody else's problem ;) 20090627 23:29:02< Crab_> and 'constructive strategies' are most often, concepts (such as 'poisoning is good, you should poison more'), which are not difficult to write. 20090627 23:29:37< Crab_> this approach means that fai becomes a language for writing 'constructive concepts' 20090627 23:30:52< Crab_> note than that, in general, makes it less powerful for specifying 'what exactly to do'. 20090627 23:31:08< boucman> yes 20090627 23:31:10< Crab_> but the complexity is reduced 20090627 23:32:02< boucman> I personally don't believe on the "what exactly to do" approch, except for some UMC needs 20090627 23:32:17< boucman> we'll never get it right and never get a wroking AI 20090627 23:32:34< boucman> my approch also make it easier to write a "bad AI that can be improved" 20090627 23:32:35< Crab_> boucman: c++ has many 'what exactly to do' parts :) 20090627 23:32:47< Crab_> and c++ is a good way to write them 20090627 23:32:53< boucman> Crab_: yes, the language lends itself much better to that approch 20090627 23:34:23< Crab_> and note that that 'register formula' should not be named candidate action :) 20090627 23:34:31< boucman> hehe 20090627 23:34:41< boucman> AI design sure is hard 20090627 23:35:20< Crab_> note that we can leave candidate actions 'as designed', and make that 'register formula' stuff to be something else. 20090627 23:35:44< boucman> yes, I was thinking of that too 20090627 23:36:03< boucman> with your new framework, we can try different concepts, which is pretty cool :) 20090627 23:36:47-!- ABCD_ [n=abcd@wikipedia/ABCD] has quit [Client Quit] 20090627 23:36:56< Crab_> boucman: what about http://wesnoth.pastebin.com/m49777ad8 ? 20090627 23:37:14< Crab_> (the first line is a name) 20090627 23:38:21< boucman> Crab_: yes, that's more or less my example, (or did I miss something? ) 20090627 23:38:33< Crab_> first line :) 20090627 23:39:11< boucman> ok, I don't get it 20090627 23:39:19< Crab_> this is not an alternative to 'candidate action evaluation loop', this is a single 'candidate action'. 20090627 23:40:24< Crab_> I can easily rework combat phase to use this approach 20090627 23:40:42< boucman> i don't like the idea of each formula "asking each other to evaluate" it would get messy pretty fast 20090627 23:40:50< boucman> gimme a sec to post a reply 20090627 23:42:22< boucman> http://wesnoth.pastebin.com/m5b9dae87 20090627 23:43:10< boucman> my approch is very close, but by doing it out of the action itself, we avoid nasty cases of moves being cross-evaluated by multiple moves (and we probably solve Dragonking's filter problem at the same time) 20090627 23:44:40< Crab_> boucman: how do you represent the list of good actions ? 20090627 23:45:12< Crab_> simple std::vector ? 20090627 23:45:30< boucman> std::set to guarentee unicity, but that was my idea 20090627 23:45:38< boucman> it might be a bit simplistic 20090627 23:46:05< boucman> the thing is that I am mainly thinking FAI and you are mainly thinking C++ (which is a good thing since we don't see the problem from the same pov) 20090627 23:46:45< boucman> Crab_: we will ndee a generic c++ representation of "a move" (whatever that means) for the engine at some point. I don't think we can escape that 20090627 23:47:10< Crab_> we have this already - action_ptr 20090627 23:47:15< Crab_> and std::set is not good. imagine move list A->B; B->A; A->C; C->A; A->B; A->D; 20090627 23:47:27< Crab_> (it actually makes sense if shroud is on) 20090627 23:47:49< Crab_> s/ A->B; A->D/A->B; B->D 20090627 23:48:06< boucman> ok, I see your point 20090627 23:48:14< Crab_> so, std::set< std::vector > :) 20090627 23:48:34< boucman> if an action_ptr is a single action, then the list of good moves would be 20090627 23:48:46< boucman> std::set > 20090627 23:48:53< Crab_> yes 20090627 23:51:09< Crab_> there's a catch here :) 20090627 23:51:37< boucman> yes ? 20090627 23:52:11< Crab_> imagine a course of actions A,B,C,D which leads to "victory" 20090627 23:53:02< Crab_> imagine that A is not that good by itself, but opens the possibility of B, which is also not good by itself but opens the possibility of C 20090627 23:53:46< Crab_> (for example, "moving friendly units out of the way", or "killing an 1-hp skeleton to open the way") 20090627 23:54:08< boucman> ok 20090627 23:54:09-!- ancestral [n=ancestra@97-116-110-107.mpls.qwest.net] has quit ["And that’s the end of THAT chapter."] 20090627 23:54:14< Crab_> then, to do action A, we need: 20090627 23:54:28< Crab_> 1) somehow include A in a list of good moves 20090627 23:55:05< Crab_> 2) figure out that A is a good move 20090627 23:55:09< Crab_> in yellow lines in http://wesnoth.pastebin.com/m57338c87 20090627 23:55:35< Crab_> to do this, some kind of depth-search is required. this is not a problem by itself 20090627 23:55:41< Crab_> the problem is that it is required twice. 20090627 23:57:10< boucman> we're never going to solve that... 20090627 23:58:59< Crab_> note the thing that ai_default does in regards to this 20090627 23:59:20< boucman> which is ? --- Log closed Sun Jun 28 00:00:01 2009