--- Log opened Wed Jan 06 00:00:56 2010
20100106 00:02:49-!- shadowm_bluecore [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100106 00:03:05-!- shadowmaster [n=ignacio@wesnoth/developer/shadowmaster] has quit [Read error: 60 (Operation timed out)]
20100106 00:03:09-!- shadowmaster [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100106 00:03:30-!- _jbx_ [n=jbailey@12.190.80.225] has quit ["Split open and melt."]
20100106 00:07:28-!- giusef [n=giusef@unaffiliated/giusef] has joined #wesnoth-dev
20100106 00:07:54-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has quit [Remote closed the connection]
20100106 00:09:19< AI0867> zookeeper: true, but one event is cleaner than two nested events (or an event that fires every turn and depends on a variable or other test)
20100106 00:20:04-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100106 00:21:16-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 53 bugs, 245 feature requests, 9 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100106 00:24:04-!- fmunoz [n=chatzill@138.Red-83-49-148.dynamicIP.rima-tde.net] has quit ["ChatZilla 0.9.86 [Firefox 3.5.6/20091201220228]"]
20100106 00:29:29< zookeeper> AI0867, sure
20100106 00:33:44-!- [Relic] [n=[Relic]@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit ["Leaving"]
20100106 00:40:47-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit []
20100106 00:45:36-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20100106 00:48:35-!- Chusslove [n=Chusslov@brsg-d9bef13c.pool.mediaWays.net] has quit [Remote closed the connection]
20100106 00:50:26-!- boucman [n=rosen@wesnoth/developer/boucman] has quit ["Leaving."]
20100106 00:51:34-!- Chusslove [n=Chusslov@brsg-d9bef13c.pool.mediaWays.net] has joined #wesnoth-dev
20100106 00:52:14-!- shadowm_bluecore is now known as shadowm_laptop
20100106 00:55:27-!- Crab_ [n=Crab_@wesnoth/developer/crab] has quit ["Leaving."]
20100106 01:02:40-!- Sapient [n=patrickp@wesnoth/developer/sapient] has joined #wesnoth-dev
20100106 01:03:02-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit ["restarting to regain control of the USB interface..."]
20100106 01:11:14-!- mjs-de [n=mjs-de@p3EE257F2.dip.t-dialin.net] has quit [Remote closed the connection]
20100106 01:12:01-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100106 01:14:42-!- YogiHH [n=chatzill@d098055.adsl.hansenet.de] has left #wesnoth-dev []
20100106 01:20:34-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit [Remote closed the connection]
20100106 01:23:02-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100106 01:28:47-!- giusef [n=giusef@unaffiliated/giusef] has quit ["exit (-1);"]
20100106 01:29:07-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)]
20100106 01:30:00-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit [Connection reset by peer]
20100106 02:00:20-!- deekay [n=dk@wesnoth/developer/dragonking] has quit []
20100106 02:07:25-!- Sapient [n=patrickp@wesnoth/developer/sapient] has left #wesnoth-dev []
20100106 02:11:34-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100106 02:18:40-!- Tallken [n=f2f93bf5@93.102.76.38.rev.optimus.pt] has joined #wesnoth-dev
20100106 02:27:55-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100106 02:37:58-!- Chusslove [n=Chusslov@brsg-d9bef13c.pool.mediaWays.net] has quit [Read error: 110 (Connection timed out)]
20100106 02:42:53-!- Chusslove [n=Chusslov@brsg-d9beefb9.pool.mediaWays.net] has joined #wesnoth-dev
20100106 02:46:21-!- shadowmaster_ [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100106 02:47:22-!- shadowmaster_ is now known as shadowm_laptop_
20100106 02:55:51-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit [Read error: 110 (Connection timed out)]
20100106 02:58:15-!- shadowm_laptop_ is now known as shadowm_laptop
20100106 03:27:43-!- Tallken [n=f2f93bf5@93.102.76.38.rev.optimus.pt] has quit ["Leaving"]
20100106 03:34:43-!- shadowm_laptop is now known as _Wall
20100106 03:35:40-!- _Wall is now known as shadowm_laptop
20100106 03:45:42-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20100106 03:50:16-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"]
20100106 03:50:57-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection]
20100106 04:08:38-!- shadowm_laptop [n=ignacio@wesnoth/developer/shadowmaster] has quit ["this is no quit message"]
20100106 04:20:27-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"]
20100106 04:20:38-!- Ivanovic_ [n=ivanovic@dtmd-4db2fefd.pool.mediaWays.net] has joined #wesnoth-dev
20100106 04:36:51-!- Ivanovic [n=ivanovic@wesnoth/developer/ivanovic] has quit [Read error: 110 (Connection timed out)]
20100106 04:38:36-!- Ivanovic_ is now known as Ivanovic
20100106 05:29:57-!- Blueblaze [n=nick@adsl-99-171-163-57.dsl.hstntx.sbcglobal.net] has quit [Read error: 110 (Connection timed out)]
20100106 06:01:15-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100106 06:13:47-!- Blueblaze [n=nick@adsl-99-171-163-57.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100106 06:21:16-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 54 bugs, 245 feature requests, 9 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100106 06:45:40-!- noy_ [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100106 06:45:50-!- noy [n=Noy@wesnoth/developer/noy] has quit [Read error: 104 (Connection reset by peer)]
20100106 06:46:20-!- noy_ is now known as noy
20100106 07:10:41-!- Blueblaze2 [n=nick@adsl-76-202-21-66.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100106 07:12:18-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100106 07:13:57-!- Blueblaze [n=nick@adsl-99-171-163-57.dsl.hstntx.sbcglobal.net] has quit [Read error: 60 (Operation timed out)]
20100106 07:31:50-!- ilor_ [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20100106 07:32:13-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has quit []
20100106 07:32:24-!- ilor [n=user@wesnoth/developer/ilor] has quit [Read error: 104 (Connection reset by peer)]
20100106 07:49:12-!- silene [n=plouf@wesnoth/developer/silene] has quit [Read error: 110 (Connection timed out)]
20100106 07:50:22-!- silene [n=plouf@ASte-Genev-Bois-152-1-104-79.w86-203.abo.wanadoo.fr] has joined #wesnoth-dev
20100106 08:35:03-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100106 08:43:18-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20100106 08:55:20-!- ilor_ [n=user@wesnoth/developer/ilor] has quit [Read error: 110 (Connection timed out)]
20100106 08:55:36-!- noy [n=Noy@wesnoth/developer/noy] has quit [Read error: 104 (Connection reset by peer)]
20100106 08:56:49-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100106 09:03:58-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20100106 09:11:37-!- Chusslove [n=Chusslov@brsg-d9beefb9.pool.mediaWays.net] has quit [Read error: 110 (Connection timed out)]
20100106 09:18:52-!- Chusslove [n=Chusslov@brsg-d9bee8e5.pool.mediaWays.net] has joined #wesnoth-dev
20100106 09:20:51-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."]
20100106 09:21:58-!- ilor [n=user@wesnoth/developer/ilor] has quit [Read error: 110 (Connection timed out)]
20100106 09:47:37-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 110 (Connection timed out)]
20100106 09:59:32-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100106 10:03:11-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100106 10:20:51-!- tsr_ [n=tsr@h-37-106.A254.priv.bahnhof.se] has quit [Read error: 110 (Connection timed out)]
20100106 10:49:23-!- mjs-de [n=mjs-de@vpw.wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20100106 10:51:29-!- knotwork [n=markm@142.177.234.40] has quit [Remote closed the connection]
20100106 10:54:59-!- Blueblaze2 [n=nick@adsl-76-202-21-66.dsl.hstntx.sbcglobal.net] has quit [Read error: 110 (Connection timed out)]
20100106 11:01:39< Ivanovic> moin
20100106 11:04:04-!- knotwork [n=markm@142.177.234.40] has joined #wesnoth-dev
20100106 11:07:33-!- loonybot [n=loonybot@ppp79-139-137-151.pppoe.spdop.ru] has joined #wesnoth-dev
20100106 11:08:19-!- loonycyborg [n=sergey@ppp79-139-137-151.pppoe.spdop.ru] has joined #wesnoth-dev
20100106 11:49:54-!- deekay [n=dk@wesnoth/developer/dragonking] has joined #wesnoth-dev
20100106 12:07:41< CIA-61> jetryl * r40586 /trunk/data/core/ (7 files in 2 dirs): New images for the goblin knight.
20100106 12:52:04-!- stikonas [n=and@wesnoth/translator/stikonas] has quit ["Konversation terminated!"]
20100106 12:52:19-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100106 13:09:50-!- Appleman1234 [n=Appleman@CPE-124-191-178-150.oxqn1.cha.bigpond.net.au] has joined #wesnoth-dev
20100106 13:10:38-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20100106 13:32:48-!- SonIcco [n=SonIcco@pD9511593.dip0.t-ipconnect.de] has joined #wesnoth-dev
20100106 13:54:08-!- fendrin [n=fabi@wesnoth/developer/fendrin] has quit [Remote closed the connection]
20100106 13:54:29-!- fendrin [n=fabi@88-134-75-97-dynip.superkabel.de] has joined #wesnoth-dev
20100106 14:04:27-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20100106 14:14:37< Ivanovic> hi ilor
20100106 14:15:06< ilor> hi Ivanovic
20100106 14:15:21< Ivanovic> since you are atm waiting for mordante to do something regarding the gui (and having a look at your work) maybe you can have a look at this bug report, though personally i doN't really understand it... https://gna.org/bugs/index.php?15058
20100106 14:15:26< Ivanovic> that is: i see several things:
20100106 14:15:31< ilor> Ivanovic: I'm on my way to uni now, leaving in ~15 minutes
20100106 14:15:38< Ivanovic> 1) joining as observer should work by double click, it does not atm
20100106 14:16:17< Ivanovic> 2) observers joining a password protected game do get a password box, but the password seems to not be required to get in since just pressing "ok" does the job
20100106 14:17:03< ilor> 2) is my misunderstaning of how things should be working, fix will be trivial
20100106 14:17:17< ilor> 2) looks is a bug but also should be eady to fix
20100106 14:17:23< ilor> s/2/1
20100106 14:17:26< Ivanovic> personally i don't know how it should work (regarding 2)
20100106 14:17:57< Ivanovic> that is: do observers in a password protected game need a password or not?
20100106 14:17:57< ilor> Ivanovic: whatever it was in the old lobby, for now
20100106 14:18:25< ilor> I'll have to check that
20100106 14:18:59< Ivanovic> mkay
20100106 14:19:17< zookeeper> Ivanovic, you have any idea what new strings jetrel's new riderless wolf is supposed to require..?
20100106 14:19:42< Ivanovic> zookeeper: no idea
20100106 14:20:13< Ivanovic> he is allowed to use anything available in po/wesnoth-units/wesnoth-units.pot
20100106 14:20:15< Ivanovic> ;)
20100106 14:22:41-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100106 14:25:02< ilor> off now, will be back in ~6-7hrs
20100106 14:25:04-!- ilor [n=user@wesnoth/developer/ilor] has quit []
20100106 14:25:46< zookeeper> i'm gonna lock the avatar battle thread
20100106 14:26:10< zookeeper> frankly i think we should be more lock-happy with all sorts of pointless forum game threads anyway
20100106 14:31:20< Ivanovic> locking sounds sane to me
20100106 14:31:26< zookeeper> feel free to unlock if you think it's anything but a waste of time...i don't have much patience for forum members who never contribute anything useful but just create noise
20100106 14:31:29< Ivanovic> locking of stuff that is not productive (anymore) that is
20100106 14:31:50< zookeeper> if someone useful makes noise then that's more tolerable than someone like zigg just making noise but nothing else
20100106 14:32:05< Ivanovic> jupp
20100106 14:38:55< Ivanovic> stikonas: i got the same build error
20100106 14:41:25< Ivanovic> mordante: logs with verbose output: http://pastebin.com/ma261f66
20100106 14:42:54< stikonas> Ivanovic: maybe this is cmake specific
20100106 14:43:02< Ivanovic> could be
20100106 14:44:30< Ivanovic> lets see if removing the build dir does help
20100106 14:45:02< Ivanovic> nope, same error
20100106 14:45:22< Ivanovic> using ldd 2.11 and gcc 4.4.2
20100106 14:45:41< Ivanovic> as well as cmake 2.8.0
20100106 15:03:00 * stikonas tried compiling with gcc 4.2.4 but compilation aborted even earlier
20100106 15:05:44< stikonas> Ivanovic: this is the error with gcc 4.2.4: http://pastebin.ca/1740150 Should Wesnoth still support this gcc version?
20100106 15:05:52-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has quit ["This computer has gone to sleep"]
20100106 15:09:09-!- giusef [n=giusef@unaffiliated/giusef] has joined #wesnoth-dev
20100106 15:16:32< Ivanovic> yes, wesnoth should support that version IIRC
20100106 15:16:59< Ivanovic> though the editor is most likely ilors area of work (and in fact it is only a warning...)
20100106 15:17:00< Ivanovic> ;)
20100106 15:39:51-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 60 (Operation timed out)]
20100106 15:39:58-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100106 15:58:21< AI0867> zookeeper: another thing, for engine (and consistency, as in, the default would be 'no', rather than 'yes') purposes, it would be a good idea to rename the 'healable' status to 'unhealable' or the like
20100106 15:59:06< AI0867> the previous thing being the "side X turn refresh" and "side X turn Y refresh"
20100106 16:00:01< AI0867> which has the same problem as the "side X turn Y", "side X turn" patch had ;)
20100106 16:06:29-!- Appleman1234 [n=Appleman@CPE-124-191-178-150.oxqn1.cha.bigpond.net.au] has quit ["Leaving"]
20100106 16:06:49-!- Appleman1234 [n=Appleman@CPE-124-191-178-150.oxqn1.cha.bigpond.net.au] has joined #wesnoth-dev
20100106 16:07:05-!- stikonas_ [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100106 16:08:21-!- Appleman1234 [n=Appleman@CPE-124-191-178-150.oxqn1.cha.bigpond.net.au] has quit [Client Quit]
20100106 16:19:07-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Nick collision from services.]
20100106 16:19:09-!- stikonas_ is now known as stikonas
20100106 16:49:24-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100106 17:20:38-!- mordante [n=mordante@87.215.201.26] has joined #wesnoth-dev
20100106 17:20:41< mordante> servus
20100106 17:21:29< mordante> Ivanovic, please look for thorizontal_scrollbar_definition::tresolution::tresolution in gui/widgets/settings.cpp and remove it
20100106 17:21:50< mordante> no idea why it compiled for me however :-/
20100106 17:22:16< mordante> (can't commit here and won't be around tonight)
20100106 17:22:53< mordante> stikonas, you can do it^^^ locally to get it linking there 
20100106 17:23:14< stikonas> I'm already doing it
20100106 17:24:02< stikonas> but I do not see such line
20100106 17:24:14< stikonas> mordante: in that file
20100106 17:25:46< stikonas> mordante: are you sure that this line was commited
20100106 17:26:51< mordante> stikonas, can't really check here, can you try to revert r40584 locally?
20100106 17:27:06< stikonas> it works then
20100106 17:27:13< stikonas> I did that yesterday
20100106 17:27:51< mordante> ok good
20100106 17:28:11< mordante> can somebody revert r40584 for me
20100106 17:28:57< mordante> I'll look at the proper fix later
20100106 17:29:56< mordante> stikonas, and for older compilers best turn off the strict-warnings
20100106 17:29:58< stikonas> mordante: that line was indeed removed in that commit: http://stikonas.homelinux.org/cgi-bin/gitweb.cgi?p=wesnoth;a=commit;h=5e0307c2587b3d3c8cf15d355268b17da289d016
20100106 17:30:31< stikonas> I'm using 4.4.1, I just wanted to try older compiler, because loonycybirg said that 4.3 worked for him
20100106 17:30:40< stikonas> I'm not usually using 4.2.4
20100106 17:30:53< mordante> I also thought I yanked pasted the lines, but sometimes I hit undo by accident
20100106 17:31:34< stikonas> no problem, I do not have time for gaming anyway :)
20100106 17:31:41< mordante> (or add a random :w in my code ;-) )
20100106 17:32:32< mordante> no but I have to leave trunk in a broken state :-(
20100106 17:33:45< mordante> got to go, bye
20100106 17:34:32-!- mordante [n=mordante@87.215.201.26] has quit ["Leaving"]
20100106 17:37:51-!- noy [n=Noy@wesnoth/developer/noy] has quit []
20100106 17:49:38-!- SonIcco [n=SonIcco@pD9511593.dip0.t-ipconnect.de] has quit [Remote closed the connection]
20100106 17:53:34-!- Noyga [n=noyga@wesnoth/developer/noyga] has joined #wesnoth-dev
20100106 18:01:23-!- daxion_ [n=jochen@dslb-094-219-187-165.pools.arcor-ip.net] has joined #wesnoth-dev
20100106 18:02:03-!- giusef [n=giusef@unaffiliated/giusef] has quit ["exit (-1);"]
20100106 18:02:41-!- daxion_ [n=jochen@dslb-094-219-187-165.pools.arcor-ip.net] has quit [Client Quit]
20100106 18:21:16-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 53 bugs, 245 feature requests, 9 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100106 18:49:52-!- crimson_penguin [n=ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100106 19:06:05-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100106 19:06:11< silene> hi
20100106 19:13:45< stikonas> silene: hi, can you revert r40584?
20100106 19:14:01< stikonas> mordante asked for that
20100106 19:14:34< stikonas> well, he asked for somebody to revert that commit :), but nobody reverted it so far
20100106 19:15:46-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100106 19:31:13-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100106 19:32:52< boucman> http://www.wesnoth.org/forum/viewtopic.php?p=402008#p402008
20100106 19:33:14< boucman> ^^ anybody knows the protocol to commit music ? (wrt to tags etc...)
20100106 19:36:09< loonycyborg> boucman: shadowmaster should know afaik.
20100106 19:36:14< boucman> k
20100106 19:36:37< CIA-61> silene * r40587 /trunk/ (9 files in 4 dirs): Reverted r40584: "Move thorizontal_scrollbar_definition to a new file."
20100106 19:49:22-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 54 (Connection reset by peer)]
20100106 19:50:03-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100106 20:01:38-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev
20100106 20:44:15-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 104 (Connection reset by peer)]
20100106 20:44:27-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100106 20:53:13-!- stikonas [n=and@wesnoth/translator/stikonas] has quit ["Konversation terminated!"]
20100106 20:53:23-!- stikonas [n=and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100106 21:18:43-!- Crab_ [n=Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100106 21:23:26-!- fabi [n=fabi@88-134-75-97-dynip.superkabel.de] has joined #wesnoth-dev
20100106 21:23:27-!- fendrin [n=fabi@wesnoth/developer/fendrin] has quit [Read error: 104 (Connection reset by peer)]
20100106 21:24:46-!- fabi [n=fabi@wesnoth/developer/fendrin] has quit [Remote closed the connection]
20100106 21:25:48-!- fendrin [n=fabi@88-134-75-97-dynip.superkabel.de] has joined #wesnoth-dev
20100106 21:26:22< Crab_> deekay: around ?
20100106 21:27:13< boucman> Crab_: i had an idea today...
20100106 21:27:20< Crab_> yes?
20100106 21:27:26< boucman> would it be possible to simulate a multiple hex unit using the new AI
20100106 21:27:45< boucman> by having a "master unite that moves normally
20100106 21:27:54-!- Noyga [n=noyga@wesnoth/developer/noyga] has quit [Remote closed the connection]
20100106 21:28:05< boucman> with the extra constraint of having to have a free walkable hex on a given edge
20100106 21:28:19< boucman> and a slave unit with infinite mvt that would immediately follow it
20100106 21:28:32-!- Noyga [n=noyga@wesnoth/developer/noyga] has joined #wesnoth-dev
20100106 21:28:39< boucman> (of course simulating combat would be a bit tricky, but with a little wml we might be able to do it
20100106 21:29:21< Crab_> boucman: does pathfinding support that ?
20100106 21:29:56< boucman> Crab_: you mean for animations during mvt ?
20100106 21:30:11< Crab_> I mean: "give me routes for unit X to location Z"
20100106 21:30:31< Crab_> does it support 'need a free walkable hex on a given edge' ?
20100106 21:31:01< boucman> Crab_: no, but by having a special AI for the master unit, it could refuse such moves
20100106 21:31:25< Crab_> boucman: those 'multiple hexes' are behind a unit ?
20100106 21:31:54< boucman> what do you mean by "behind"
20100106 21:32:00< Crab_> big unit moves from A to B
20100106 21:32:25< Crab_> let's pretend that a small unit moving from A to B will not be ambushed.
20100106 21:32:59< Crab_> is it possible for a big unit to be ambushed where a small unit won't be ?
20100106 21:33:30< Crab_> the answer is "no" if those extra hexes are 'behind' a unit (thus, they move in already scouted path)
20100106 21:33:32< boucman> hmm
20100106 21:33:39< Crab_> the answer is "yes" if they're on sides of our unit
20100106 21:33:40< boucman> i hadn't thought of ambushes...
20100106 21:33:56< Crab_> e.g. you can make an ambush-safe snake
20100106 21:34:08< Crab_> since the tail moves where head already was
20100106 21:34:41< Crab_> but, you can't make ambush-safe 3-hex-wide unit (say, "wing, head, wing")
20100106 21:34:44< boucman> so we have to guarentee that the tail takes the same path then the head...
20100106 21:35:00< Crab_> yes, but this is ok if the tail can 'bend'
20100106 21:35:37< boucman> Crab_: do we really care about how the tail moves during mvt ?
20100106 21:36:12< Crab_> yes, if we do care about 'why my ambusher wasn't able to ambush the tail? it moved right before him!'
20100106 21:36:36< boucman> Crab_: ok, this brings us to my second idea
20100106 21:36:58< Crab_> this issue settled, it's certanly possible to calculate allowed movements and attacks for this unit 'by hand'.
20100106 21:36:59< boucman> the master unit would have an image that would be multiple hex wide, and the slaves would be invisible
20100106 21:37:06< boucman> afk one sec
20100106 21:37:40< Crab_> slaves would be unambushable ?
20100106 21:38:01< Crab_> and, how will the enemy retaliate against this unit ?
20100106 21:38:28< boucman> slaves would be invisible
20100106 21:38:43< boucman> and would not attack (to simulate a single unit)
20100106 21:38:49< boucman> and not ambushable I guess
20100106 21:39:06< Crab_> ok, if we deal with ambush issue with 'slaves are not ambushable' ...
20100106 21:39:33< Crab_> then, it is certainly possible to calculate allowed movements and attacks for this unit 'by hand'.
20100106 21:39:54< Crab_> so, AI would be able to use it
20100106 21:40:12< boucman> Crab_: this is purely theoreticall, but it's cool to see the sort of stuff we'll be able to do with the new AI
20100106 21:40:26< Soliton> if the slave is not ambushable it is possible to move onto an ambushing unit with it.
20100106 21:40:39< boucman> hmm
20100106 21:41:14< boucman> good point, i assumed my "check for no neighbours" would check that, but if the AI can't see the ambusher....
20100106 21:41:22-!- Noyga [n=noyga@wesnoth/developer/noyga] has left #wesnoth-dev ["Quitte"]
20100106 21:41:25 * fendrin filled a bug report about his non working sound. https://gna.org/bugs/?15065
20100106 21:41:27< Crab_> ai *can* cheat, don't forget that :)
20100106 21:41:47< boucman> Crab_: you've thought of everything :)
20100106 21:42:08< Soliton> well, then you can deduce ambushing units be where you can't go.
20100106 21:42:27< Soliton> not an issue if it is an ai controlled unit though.
20100106 21:42:51< Crab_> Soliton: well, in that case we'll have to duplicate some c++ pathfinding code using formula_ai
20100106 21:43:05< loonycyborg> fendrin: It looks like SDL failed to initialize sound in your case.
20100106 21:43:17< Crab_> Soliton: e.g. find out our allowed routes, pick a route, then make sure that we don't move further than we need in order to be ambushed
20100106 21:43:27< loonycyborg> Does sound in other SDL apps still work?
20100106 21:43:46< fendrin> loonycyborg: Good question, have you any sdl app in mind?
20100106 21:44:05< Crab_> can be made easier if the code for controlling that big unit will be dumb enough
20100106 21:44:06< boucman> Crab_: we only need to check ambush at destination
20100106 21:44:18< loonycyborg> fendrin: Nope :(
20100106 21:44:30< Crab_> boucman: no
20100106 21:44:37< Crab_> boucman: imagine the issue with 2 ambushers
20100106 21:44:37< boucman> Crab_: never might, we need to check that we are not ambushed at a place where we can't stop
20100106 21:44:47< Crab_> and this, too
20100106 21:45:04< Crab_> actually, we can move hex-by-hex :)
20100106 21:45:23< Crab_> e.g. doing a serie of small 1-hex moves and checks
20100106 21:45:24< boucman> Crab_: it means we can't go through friendly units
20100106 21:45:50< Crab_> ah, yes
20100106 21:45:53< loonycyborg> fendrin: You'll probably need to specially test apps using SDL_mixer, not just SDL.
20100106 21:46:20< boucman> Crab_: ok, it's a bit more complicated than I thought 
20100106 21:46:28< boucman> nice idea but can't be dealt with in 5'
20100106 21:46:39< boucman> or just make the giant unit unambushable :)
20100106 21:46:52< Crab_> well, it can be made easier by making the giant unit 'special'
20100106 21:47:05< Crab_> e.g. if we design a scenario-specific AI 'around' that unit
20100106 21:47:38< Crab_> e.g we need to move our units out of his way
20100106 21:48:04< boucman> i like my unambushable idea better ;)
20100106 21:48:22< Crab_> that's different things...
20100106 21:48:36< Crab_> we need to teach AI to not block paths for this big unit
20100106 21:48:51< boucman> why ?
20100106 21:49:05< boucman> if it's unambushable, we don't need to move it step by step
20100106 21:49:15< Crab_> but where we want to move our big unit ?
20100106 21:49:25< Crab_> somewhere where it can deal big damage,isn't it ?
20100106 21:49:36< boucman> oh, you mean from a "startegy" point of view
20100106 21:49:37< Crab_> but what if *that* place is blocked by our units ?
20100106 21:49:38< Crab_> yes
20100106 21:49:51< boucman> i was still considering "gameplay simulation"
20100106 21:50:06< Crab_> ai attack optimization assumes that we can interchange units which can reach certain hexes
20100106 21:50:16< boucman> hmm
20100106 21:50:31< Crab_> so, we need to design our AI around that big unit
20100106 21:51:13< Crab_> note that we can modify the 'check for ambush' code
20100106 21:51:37< Crab_> since it is relatively inexpensive - we rarely move units
20100106 21:51:54< Crab_> ( in comparison with the number of times we check 'what moves are possible?' )
20100106 22:01:27< stikonas> Ivanovic: some translator posted translations to the mailing list, instead of sending them to maintainer of Hebrew language
20100106 22:01:41< fendrin> loonycyborg: alien-arena hangs at startup during the sound initialization. It's an sdl game.
20100106 22:01:48< Ivanovic> stikonas: i already notified torangan about this, asking him to take care of it
20100106 22:01:57< stikonas> ok
20100106 22:02:09< loonycyborg> fendrin: Did you build frogatto? It uses sdl-mixer too.
20100106 22:02:25< loonycyborg> And its sound code is probably taken from wesnoth :P
20100106 22:02:57< fendrin> loonycyborg: No, I have no build of frogatto around.
20100106 22:03:20< fendrin> I have the source checked out but it's not easy to compile.
20100106 22:12:37-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."]
20100106 22:21:57-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20100106 22:25:23-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100106 22:33:16-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20100106 22:35:53-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100106 22:49:29-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20100106 22:50:06-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100106 22:51:03< Crab_> hmm.. what status of the bug should I use if it is fixed in new version of the ai and won't be fixed in old default ai ? 'fixed' or 'won't fix' or something else ?
20100106 22:52:19< boucman> i'd say fixed, with an appropriate comment, 
20100106 22:52:28< boucman> we won't release anymore 1.6 I guess
20100106 22:52:38< Crab_> the bug is against 1.7.11
20100106 22:52:54< boucman> more reason
20100106 22:53:15< Crab_> it is against a well-known problem in default_ai design, which will be fixed when  RCA ai will be made default.
20100106 22:53:16-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 104 (Connection reset by peer)]
20100106 22:53:23-!- stikonas [n=and@ctv-79-132-179-139.vinita.lt] has joined #wesnoth-dev
20100106 22:55:15< Crab_> ( https://gna.org/bugs/index.php?15035 - I'll change it to fixed when I'll make RCA default)
20100106 22:57:24-!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
20100106 23:06:37< Crab_> boucman: there's many issues with formula_ai which should be fixed before 1.8, and the biggest one is the necessity of easing the process of writing formula_ai based candidate actions. the problem is that we need to enable the usual c++-based candidate action paradigm http://pastebin.mozilla.org/695185
20100106 23:07:44< boucman> i read your pastebin, but i'm not sure what you mean
20100106 23:08:34< Crab_> note the important points: 1) in evaluate(), we find the action that we want to do,  then use the corresponding check_FOO function to see if our action is allowed, and return BAD_SCORE if it's not allowed  2) we store our action, to be reused in evaluate.
20100106 23:08:43< Crab_> now if we code this in fai..
20100106 23:08:52< Crab_> 'find the action we want to do' is more-or-less, easy
20100106 23:09:24< Crab_> 'checking if our action is allowed' is impossible (this can be solved by introducing formula_ai wrappers for check_FOO functions
20100106 23:10:05< Crab_> as it's impossible to check 'in the right way', I was forced to check indirectly. say 'is the dst occupied?'
20100106 23:10:21< Crab_> or, 'is dst in my allowed moves?'
20100106 23:11:05< boucman> Crab_: are you still thinking of the multi-unit stuff or is this generic considerations
20100106 23:11:24< Crab_> I am thinking of generic cases, like fai stuff I wrote a few days ago
20100106 23:12:12< Crab_> then, it's impossible to store stuff between execute and evaluate (except by abusing fai variables, which is not the easiest thing to do correctly)
20100106 23:13:05< Crab_> that leads to duplication of code - I am forced to search out in execute() for the 'best move'   I've might had already determined in evaluate().
20100106 23:13:48< boucman> Crab_: can we safely assume that 99% of moves are OK ?
20100106 23:13:54< Crab_> no
20100106 23:13:59< boucman> no ?
20100106 23:14:31< Crab_> if a formula contains a glitch...
20100106 23:14:54< Crab_> and, even if it's 99% correct
20100106 23:15:03< Crab_> let's say there are 100 units we can move
20100106 23:15:13< Crab_> if we're 99% correct, then we fail for 1 unit
20100106 23:15:31< Crab_> then, on average, such candidate action will be able to move 50 units before ending turn
20100106 23:15:53< Crab_> since 1 failure is 'blacklist until end of turn' - there's strict infinite loop protection :)
20100106 23:16:10< boucman> Crab_: ok, my assumption of 99% is still correct, let me continue
20100106 23:16:15< Crab_> ok
20100106 23:16:47< Crab_> (my goal here is to find a way to make writing working fai candidate actions easier)
20100106 23:16:48< boucman> my assumption is that the remaining 1% is a bug, not a normal use-case, and as such can be both logged and can cause some perf loss
20100106 23:17:21< Crab_> I don't agree. but, continue...
20100106 23:18:08< boucman> in that case, I would move the is_ok part in in execute() and reevaluate after blacklisting... i.e only do is_ok on the selected action, we gain by calling is_ok less often but loose by reevaluating on buggy formulas
20100106 23:18:57< boucman> which means that local variables are not a problem anymore (if I understand your problem correctly) since in the problematic case of is_ok==false we reevaluate anyway
20100106 23:19:31< deekay> Crab_: Looking for me?
20100106 23:19:54< Crab_> deekay: yes. please have a say at the ongoing discussion about formula_ai candidate actions
20100106 23:20:08< Crab_> deekay: I'll repeat, briefly:
20100106 23:20:40< Crab_> 1) "writing formula_ai based candidate actions is possible, the result is cool,  but it is dawn hard to get right."
20100106 23:20:51< Crab_> 2) the problems include:
20100106 23:21:27< Crab_> 2a) we need a way in fai to check if a action is valid without actually executing it
20100106 23:21:29< boucman> Crab_: i'll be afk for now and probably leave soon, so we'll continue another day...
20100106 23:21:35< Crab_> boucman: ok
20100106 23:22:35< Crab_> 2b) if we have found a suitable action(s) during evaluation, we need to store them until execution - otherwise, we're forced to duplicate stuff (re-find the best action during in execution)
20100106 23:23:06< Crab_> deekay: so, how we should fix fai-based candidate actions ?
20100106 23:23:33-!- zookeeper [n=l@wesnoth/developer/zookeeper] has quit []
20100106 23:24:06< Crab_> 2a) can be fixed, say, by introducing stuff like "is_possible(FOO)". we can't use on_fail here since we're not actually executing anything.
20100106 23:24:12< Crab_> but what to do with 2b?
20100106 23:26:08< Crab_> e.g., it can look like: evaluate: "if is_possible(find_best_healing_move()) return GOOD else return BAD;"          execute: do "find_best_healing_move()"
20100106 23:26:21< Crab_> and we want to avoid from calling find_best_healing_move twice
20100106 23:28:33-!- Zarel [n=Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100106 23:31:14< boucman> Crab_: what do you think of my idea ?
20100106 23:31:53< Crab_> ( i.e now it looks like 'top' and I want it to be like bottom one here http://pastebin.mozilla.org/695198 )
20100106 23:33:07< Crab_> boucman: the problem is that if a formula is both high-scorer and buggy, we have to blacklist it, otherwise (as the game situation stays the same) it will come up high-scorer and buggy again.
20100106 23:33:27< deekay> Crab_: I'm not sure if I follow...  1) we rate AND check wheter action is valid (here we store evaluated thing) 2) we rate CA 3) exectute what is evaluated    yes?
20100106 23:33:46< boucman> yes, i still have the blacklisting feature...
20100106 23:33:55< Crab_> deekay: yes we need both to 'rate' and store our list to be executed if we score highest
20100106 23:34:02< Crab_> boucman: then explain your idea in more detail
20100106 23:34:22< Crab_> deekay: and we need to make sure that we don't return >0 if we have invalid actions
20100106 23:34:57< Crab_> deekay: e.g. if we can pick one of 10 actions, and 7 are valid and 3 are not, it makes sense to pick 'the best' of valid ones.
20100106 23:36:23< Crab_> deekay: c++ code does it quite easily - like: sort(proposed actions by quality desc); foreach(action in actions) {if action is valid -> store action and return GOOD}; return BAD;
20100106 23:36:35< boucman> Crab_: basic idea http://pastebin.mozilla.org/695201
20100106 23:37:48< Crab_> looking...
20100106 23:38:00< deekay> Crab_: We would need to store result of formula evaluation (variant)
20100106 23:38:17< Crab_> deekay: but aren't moves autoevaluated ?
20100106 23:38:43< boucman> deekay: we could, but if is_ok is a rare occurence, it might not be worth the trouble
20100106 23:38:52< deekay> Crab_: aww ok I know what you mean
20100106 23:39:57< deekay> We would need parse each formula CA,  check is_ok and then remember it
20100106 23:40:04< deekay> But.. it's getting messy
20100106 23:40:14< deekay> Sadly
20100106 23:40:30< Crab_> deekay: remember a list of some new objects which have is_ok and each of them wraps a move ?
20100106 23:40:58< Crab_> e.g. define a new callable, candidate_action_result callable ...
20100106 23:41:06< Crab_> deekay: because we need to return a score, as well
20100106 23:42:14< deekay> To check wherter move "is_ok" we need to parse formula and evaluate it. Result is variant, that wraps some callable, we must "unwrap" this callable and check it it "is_ok"
20100106 23:42:26< Crab_> boucman: basically, your code 'works' but is equal to the code with 'yellow' lines removed. see http://pastebin.mozilla.org/695204
20100106 23:42:45< Crab_> boucman: oops,wrong one
20100106 23:42:52< deekay> But basically all of this could be probably rewritten.....
20100106 23:43:19< Crab_> boucman: this one 
20100106 23:43:21< Crab_> http://pastebin.mozilla.org/695205
20100106 23:43:56< Crab_> boucman: because this code (yellow lines) has no extra effect - execute does is_ok() internally, and if that CA returns false, it's blacklisted
20100106 23:44:05< boucman> Crab_: you sure ? i thought the point was testing is_ok before execute
20100106 23:44:18< Crab_> boucman: the point was testing is_ok before we return score>0
20100106 23:45:09< boucman> Crab_: ok, i'm confused, what's the problem we are trying to solve ?
20100106 23:45:33< Crab_>  2a) we need a way in fai to check if a action is valid without actually executing it.
20100106 23:45:33< Crab_> 2b) if we have found a suitable action(s) during evaluation, we need to store them until execution - otherwise, we're forced to duplicate stuff (re-find the best action during in execution).
20100106 23:45:46< Crab_> where 2a is easy
20100106 23:45:49< Crab_> and 2b is hard
20100106 23:46:16< Crab_> boucman: will you be available tomorrow ? I can prepare an extended description of the problem
20100106 23:46:27< Crab_> deekay: how it should be rewritten ?
20100106 23:46:39< boucman> Crab_: we have a separate evaluate and execute because we assumed these would be different 
20100106 23:47:09< Crab_> boucman: yes, they're different. but execute needs to have access to some data which we have found in evaluate
20100106 23:47:11< boucman> if we find out they are the same, maybe we could have a convention of returning a pair(score,move)
20100106 23:47:17< deekay> Crab_: Nah, nvm me, been thinking about wrong stuff
20100106 23:48:12< deekay> Crab_: If we can store score and callable, then it should work for formulas
20100106 23:48:13< Crab_> boucman: yes, returning pair <variant score, variant moves> is one of the ways to go..  but how the fai code will look ?
20100106 23:49:39< shadowmaster> boucman: okay
20100106 23:49:53< Crab_> boucman: it is easy in procedural language: like " find out good moves, sort by score, pick and store best valid one, return its score"
20100106 23:49:55< boucman> shadowmaster: thx
20100106 23:49:58< deekay> So we need to evaluate, extract callabe from variant, is_ok?  store callable... but currently checking is_ok would reqire dynamic_casts to distinguish between callables
20100106 23:50:02< boucman> Crab_: http://pastebin.mozilla.org/695210
20100106 23:50:11< boucman> note the new candidate_action engine
20100106 23:51:17< Crab_> nah, the engine should stay "fai", because it's still the same formula_ai ... but yes, we can mark the new syntax easily.
20100106 23:52:06-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev
20100106 23:53:01< Crab_> boucman: the question is like: write a snippet in functional language which returns a pair MOVE,SCORE      where MOVE is f(POSITION) and SCORE is g(POSITION, MOVE)
20100106 23:53:38< Crab_> I am wondering how the syntax for those fai snippets would be like
20100106 23:53:57< boucman> Crab_: going to bed now, and i won't be here tomorow (friday evening, i will be)
20100106 23:54:04< Crab_> boucman: ok, good night
20100106 23:54:09< boucman> best is to try to write a few i guss
20100106 23:54:13-!- boucman [n=rosen@wesnoth/developer/boucman] has quit ["Leaving."]
20100106 23:54:31< Crab_> deekay: well, I think that dynamic_cast issue will be fixed, in time.
20100106 23:59:08< Crab_> deekay: maybe we use some kind of local fai variable instead ? e.g. add operations for working with a list of currently considered moves ?
--- Log closed Thu Jan 07 00:00:06 2010