--- Log opened Fri Jul 31 00:00:06 2009 --- Day changed Fri Jul 31 2009 20090731 00:00:06-!- shadowmaster [n=ignacio@wesnoth/developer/shadowmaster] has quit [Client Quit] 20090731 00:00:36-!- shadowmaster [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev 20090731 00:01:02-!- shadowmaster [n=ignacio@wesnoth/developer/shadowmaster] has quit [Client Quit] 20090731 00:01:26-!- shadowmaster [n=ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev 20090731 00:01:53-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Client Quit] 20090731 00:02:13-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 00:03:34-!- shadowm_webchat [i=be166d74@wesnoth/developer/shadowmaster] has joined #wesnoth-dev 20090731 00:05:06-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev 20090731 00:11:04-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."] 20090731 00:13:02-!- loonycyborg [n=sergey@wesnoth/developer/loonycyborg] has quit ["Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"] 20090731 00:13:35-!- loonybot [n=loonybot@wesnoth/bot/loonybot] has quit [Remote closed the connection] 20090731 00:14:38-!- Sirp [n=user@wesnoth/developer/dave] has joined #wesnoth-dev 20090731 00:20:12-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 00:24:31-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 00:27:49-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 00:30:06-!- melinath [n=melinath@pool-71-162-41-64.altnpa.east.verizon.net] has quit [Read error: 110 (Connection timed out)] 20090731 00:34:31< corn> Ivanovic: I think LH forgot about my survey problem... 20090731 00:34:47-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has quit [Read error: 104 (Connection reset by peer)] 20090731 00:35:41-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 00:40:25-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev 20090731 00:44:15-!- allefant [n=allefant@allegro/developer/allefant] has quit [Read error: 110 (Connection timed out)] 20090731 00:46:36-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 00:52:36-!- ABCD_away [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 00:52:54-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 00:53:29-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has quit [Connection reset by peer] 20090731 00:53:53-!- ABCD_away is now known as ABCD 20090731 00:55:30-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has quit [Remote closed the connection] 20090731 01:01:40-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has quit ["night all"] 20090731 01:03:18-!- Jetrel [n=Jetrel@wesnoth/artist/jetrel] has left #wesnoth-dev [] 20090731 01:18:58-!- shadowm_webchat [i=be166d74@wesnoth/developer/shadowmaster] has quit ["Page closed"] 20090731 01:43:04-!- Elvish_Pillager [n=eli@71-10-231-36.dhcp.oxfr.ma.charter.com] has quit [Read error: 110 (Connection timed out)] 20090731 01:45:16-!- Baufo [n=quassel@wesnoth/developer/baufo] has quit [Remote closed the connection] 20090731 01:47:05-!- Chusslove [n=Chusslov@brsg-d9bef391.pool.mediaWays.net] has quit [Read error: 110 (Connection timed out)] 20090731 01:53:27-!- Chusslove [n=Chusslov@brsg-d9bef4ab.pool.mediaWays.net] has joined #wesnoth-dev 20090731 02:00:38-!- ilor [n=ilor@wesnoth/developer/ilor] has joined #wesnoth-dev 20090731 02:22:08-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"] 20090731 02:25:57-!- Kenpachi_ [n=chatzill@CPE-58-166-241-41.sa.bigpond.net.au] has joined #wesnoth-dev 20090731 02:25:57-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev 20090731 02:35:34-!- Kenpachi__ [n=chatzill@CPE-124-182-243-32.sa.bigpond.net.au] has joined #wesnoth-dev 20090731 02:45:43-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 110 (Connection timed out)] 20090731 02:46:12-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"] 20090731 02:46:41-!- Kenpachi [n=chatzill@CPE-139-168-194-150.sa.bigpond.net.au] has quit [Read error: 110 (Connection timed out)] 20090731 02:47:41-!- noy [n=Noy@wesnoth/developer/noy] has quit [] 20090731 02:53:09< CIA-62> cornmander * r37346 /trunk/src/ (game.cpp upload_log.cpp upload_log.hpp): 20090731 02:53:09< CIA-62> Added new --new-uploader flag for testing uploader code changes in development. 20090731 02:53:09< CIA-62> Added uploader_settings namespace to support the new flag. Added information on 20090731 02:53:09< CIA-62> --new-uploader to --help. Added "unknown" platform to wesnoth log uploads in 20090731 02:53:10< CIA-62> case the platform is not detected instead of leaving the parameter undefined as 20090731 02:53:12< CIA-62> it is now. Fixed incorrect linewrap for --help documentation on --screenshot 20090731 02:53:14< CIA-62> flag. 20090731 02:53:54-!- Kenpachi_ [n=chatzill@CPE-58-166-241-41.sa.bigpond.net.au] has quit [Read error: 110 (Connection timed out)] 20090731 03:01:16-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 03:01:35-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 03:04:56-!- ilor [n=ilor@wesnoth/developer/ilor] has quit [Read error: 110 (Connection timed out)] 20090731 03:10:20-!- BenUrban [n=benurban@c-68-50-54-86.hsd1.md.comcast.net] has joined #wesnoth-dev 20090731 03:10:23-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 03:11:07-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 03:19:12-!- Crab_ [i=crab@wesnoth/developer/crab] has left #wesnoth-dev [] 20090731 03:19:43-!- ancestral [n=ancestra@97-116-106-75.mpls.qwest.net] has joined #wesnoth-dev 20090731 03:21:46< CIA-62> cornmander * r37347 /trunk/src/upload_log.cpp: 20090731 03:21:46< CIA-62> Added connection information for temporary development upload server. Added code 20090731 03:21:46< CIA-62> that chooses between new uploader and old uploader. Duplicated existing upload 20090731 03:21:46< CIA-62> code as the basis of the new upload code - the upload_logs_dev() function 20090731 03:21:46< CIA-62> doesn't implement any new functionality yet. 20090731 03:27:28-!- iBlueblaz [n=irchon@166.205.5.52] has joined #wesnoth-dev 20090731 03:34:14-!- iBlueblaz [n=irchon@166.205.5.52] has quit [Remote closed the connection] 20090731 03:55:45 * shadowmaster concentrates all his willpower on summoning boucman out of his regular schedule.. 20090731 04:02:29-!- Ivanovic_ [n=ivanovic@dtmd-4db2a8a0.pool.einsundeins.de] has joined #wesnoth-dev 20090731 04:03:07-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev 20090731 04:05:26-!- melinath [n=melinath@pool-71-162-41-64.altnpa.east.verizon.net] has joined #wesnoth-dev 20090731 04:09:39-!- Appleman1234 [n=Appleman@131.181.100.31] has joined #wesnoth-dev 20090731 04:19:27-!- Ivanovic [n=ivanovic@wesnoth/developer/ivanovic] has quit [Read error: 110 (Connection timed out)] 20090731 04:20:10-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has quit [Connection reset by peer] 20090731 04:20:24-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has joined #wesnoth-dev 20090731 04:20:27-!- Ivanovic_ is now known as Ivanovic 20090731 04:37:35-!- iBlueblaz [n=irchon@166.205.5.52] has joined #wesnoth-dev 20090731 04:42:57-!- iBlueblaz [n=irchon@166.205.5.52] has quit [Remote closed the connection] 20090731 04:45:57< corn> hey, I am compressing upload logs with boost's gzip filter and writing them to a file, but the contents get truncated when I am trying to send the file because there is a conversion to c-style strings going on 20090731 04:46:48< corn> I wanted to encode in base64 but unfortunately boost does not have a filter for that. what are my alternatives? 20090731 04:50:12< corn> hm... I will just remove the std::string -> c_str conversion, since it seems to be arbitrary 20090731 04:57:26-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit ["WRYYYYYYYYYYYYYYYYYYYY!"] 20090731 05:29:40-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20090731 05:41:08< shadowmaster> well, as I've done my work here, I guess I'll finally have some time to mess with writing networking apps. 20090731 05:41:11< shadowmaster> off now. 20090731 05:44:00-!- melinath [n=melinath@pool-71-162-41-64.altnpa.east.verizon.net] has quit [Read error: 113 (No route to host)] 20090731 06:06:06-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev 20090731 06:08:20-!- ancestral [n=ancestra@97-116-106-75.mpls.qwest.net] has quit ["And that’s the end of THAT chapter."] 20090731 06:17:28-!- iBlueblaz [n=irchon@166.205.5.52] has joined #wesnoth-dev 20090731 06:24:02-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 113 (No route to host)] 20090731 06:27:39-!- iBlueblaz [n=irchon@166.205.5.52] has quit [Remote closed the connection] 20090731 06:43:47-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 06:45:44-!- yann [n=dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has quit [Read error: 110 (Connection timed out)] 20090731 06:57:07-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has quit ["quit"] 20090731 07:11:59< esr> The coders here might find this interesting: http://gpsd.berlios.de/protocol-evolution.html 20090731 07:19:53-!- ancestral [n=ancestra@97-116-106-75.mpls.qwest.net] has joined #wesnoth-dev 20090731 07:21:42-!- iBlueblaz [n=irchon@166.205.5.52] has joined #wesnoth-dev 20090731 07:30:24-!- iBlueblaz [n=irchon@166.205.5.52] has quit [Remote closed the connection] 20090731 07:53:19< CIA-62> cornmander * r37348 /website/stats.wesnoth.org/wesstats/controllers/root.py: Added support for compressed logfiles on the server-side upload script. 20090731 07:54:28< CIA-62> cornmander * r37349 /trunk/src/ (upload_log.cpp upload_log.hpp): Added support for upload log compression client-side. 20090731 08:13:42-!- Sirp [n=user@wesnoth/developer/dave] has quit ["leaving"] 20090731 08:14:54-!- zookeeper [n=l@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20090731 08:35:29-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has joined #wesnoth-dev 20090731 08:41:35-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."] 20090731 08:51:02-!- Turuk_ [n=Turuk@wesnoth/forumsith/turuk] has joined #wesnoth-dev 20090731 08:53:41-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev 20090731 08:58:52-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has quit [Read error: 110 (Connection timed out)] 20090731 09:07:19-!- YogiHH [i=d4ca9d15@wesnoth/developer/yogihh] has joined #wesnoth-dev 20090731 09:07:32< YogiHH> hello 20090731 09:30:16-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 09:31:06-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 113 (No route to host)] 20090731 09:41:04-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 09:41:25-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 09:54:23-!- Kenpachi [n=chatzill@121.215.190.168] has joined #wesnoth-dev 20090731 09:58:10-!- Turuk_ [n=Turuk@wesnoth/forumsith/turuk] has quit [Read error: 60 (Operation timed out)] 20090731 09:59:14-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has joined #wesnoth-dev 20090731 10:00:06-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has joined #wesnoth-dev 20090731 10:02:56-!- ancestral [n=ancestra@97-116-106-75.mpls.qwest.net] has quit [] 20090731 10:06:08-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 10:06:34-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 10:12:40-!- Kenpachi__ [n=chatzill@CPE-124-182-243-32.sa.bigpond.net.au] has quit [Read error: 110 (Connection timed out)] 20090731 10:26:13-!- loonybot [n=loonybot@79.139.138.234] has joined #wesnoth-dev 20090731 10:27:00-!- loonycyborg [n=sergey@79.139.138.234] has joined #wesnoth-dev 20090731 10:27:33-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 10:27:47-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Connection reset by peer] 20090731 10:30:12-!- elias [n=allefant@allegro/developer/allefant] has joined #wesnoth-dev 20090731 10:33:42-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit [Remote closed the connection] 20090731 10:40:40-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 10:41:33-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 10:51:41-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 10:52:04-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 10:52:33-!- Crab_ [i=crab@wesnoth/developer/crab] has joined #wesnoth-dev 20090731 10:52:44< Crab_> hi 20090731 10:54:20-!- noy [n=Noy@wesnoth/developer/noy] has quit [] 20090731 11:10:23-!- Netsplit brown.freenode.net <-> irc.freenode.net quits: nital 20090731 11:15:52< Ivanovic> moin 20090731 11:16:10< Ivanovic> corn: she wrote ellen to restore your entry 20090731 11:21:42< Ivanovic> corn: that was less than two days ago 20090731 11:21:45< Ivanovic> so have some faith 20090731 11:29:42-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 11:30:05-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 11:31:52-!- Netsplit over, joins: nital 20090731 11:37:42-!- Elvish_Pillager [n=eli@71-10-231-36.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev 20090731 11:40:46-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has quit [Connection reset by peer] 20090731 11:41:01-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has joined #wesnoth-dev 20090731 11:43:57-!- AnMaster [n=AnMaster@unaffiliated/anmaster] has joined #wesnoth-dev 20090731 12:02:42-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev 20090731 12:04:42-!- Amu [n=smar@a88-113-60-192.elisa-laajakaista.fi] has quit [Read error: 110 (Connection timed out)] 20090731 12:06:32-!- Espreon [n=espreon@wesnoth/developer/espreon] has quit [Client Quit] 20090731 12:16:04-!- ilor [n=ilor@wesnoth/developer/ilor] has joined #wesnoth-dev 20090731 12:20:11< Ivanovic> ilor: i added some permissions for the three chans yesterday 20090731 12:20:18< Ivanovic> please change/update as needed 20090731 12:20:32< Ivanovic> (soliton was already complaining about not having access ;) ) 20090731 12:25:09-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has quit [Remote closed the connection] 20090731 12:26:49< ilor> Ivanovic: noticed that in the logs ;) 20090731 12:37:15-!- Appleman1234 [n=Appleman@131.181.100.31] has quit [Read error: 110 (Connection timed out)] 20090731 12:39:31< Ivanovic> okay 20090731 13:05:48< ilor> Soliton: can you change the irssi triggers on the lobby bot? 20090731 13:12:30-!- BenUrban_ [n=benurban@unaffiliated/benurban] has joined #wesnoth-dev 20090731 13:16:17< AI0867> esr: your fixme states that upon removal of [stoned], min_savgame should be bumped, but I really doubt that's needed. (min_savegame is still at 1.3.10) 20090731 13:16:24< Soliton> ilor: yes, sorry. will do now. 20090731 13:23:36< Elvish_Pillager> huh, I'm not a moderator anymore on the forum? 20090731 13:25:26< Soliton> ilor: should work now. 20090731 13:29:22< loonycyborg> Elvish_Pillager: What makes you think so? 20090731 13:29:23-!- BenUrban [n=benurban@unaffiliated/benurban] has quit [Read error: 110 (Connection timed out)] 20090731 13:29:23-!- ancestral [n=ancestra@97-116-106-75.mpls.qwest.net] has joined #wesnoth-dev 20090731 13:31:09< loonycyborg> Indeed, it seems you aren't. 20090731 13:31:36< loonycyborg> And Moderators group contains only Turuk :/ 20090731 13:32:43-!- blarumyrran [n=minaise@81-20-159-197.levira.ee] has joined #wesnoth-dev 20090731 13:44:03-!- Baufo [n=quassel@93-82-10-3.adsl.highway.telekom.at] has joined #wesnoth-dev 20090731 13:51:30-!- Amu [n=smar@a88-113-60-192.elisa-laajakaista.fi] has joined #wesnoth-dev 20090731 13:57:17-!- ancestral [n=ancestra@97-116-106-75.mpls.qwest.net] has quit [] 20090731 14:08:53-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has joined #wesnoth-dev 20090731 14:23:15-!- BenUrban_ is now known as BenUrban 20090731 14:25:43-!- Crab_ [i=crab@wesnoth/developer/crab] has quit ["Leaving."] 20090731 14:47:20-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20090731 14:47:36< boucman> hey all 20090731 14:48:30< YogiHH> hi boucman 20090731 14:57:51< Soliton> YogiHH: do you happen to know if this is something euschn has already fixed (or is in his area)? http://www.wesnoth.org/forum/viewtopic.php?p=372414#p372414 20090731 15:02:08-!- melinath [n=melinath@pool-71-162-41-64.altnpa.east.verizon.net] has joined #wesnoth-dev 20090731 15:06:11-!- blarumyrran [n=minaise@81-20-159-197.levira.ee] has quit [Read error: 113 (No route to host)] 20090731 15:06:40-!- yuid [n=n08eriaa@merry.midgard.liu.se] has joined #wesnoth-dev 20090731 15:11:16-!- yuid [n=n08eriaa@merry.midgard.liu.se] has quit ["leaving"] 20090731 15:12:16< YogiHH> Soliton: yes, that's very likely him. He was doing some stuff with the side.persistent attribute to enable keeping unused sides over several scenarios. I don't know if it is fixed, though. 20090731 15:19:40-!- Crab_ [n=Crab_@wesnoth/developer/crab] has joined #wesnoth-dev 20090731 15:19:47< Crab_> hi 20090731 15:25:51< boucman> hey Crab_ 20090731 15:26:10-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev 20090731 15:26:17< silene> hi 20090731 15:26:35< Crab_> boucman: I'll show you a new version of that patch, in ~1h 20090731 15:26:40< boucman> ok, cool 20090731 15:26:47< boucman> commit ready ? 20090731 15:27:53< Crab_> boucman: yes, it should be in 'does-not-break-anything' state (although with some rough edges left, but those can be fixed in separate commits) 20090731 15:28:04< boucman> ok, good 20090731 15:28:15< boucman> did you test with your automated scripts ? 20090731 15:29:13-!- ancestral [n=ancestra@97-116-106-75.mpls.qwest.net] has joined #wesnoth-dev 20090731 15:29:19< Crab_> boucman: no, I haven't yet. 20090731 15:30:59< Soliton> melinath: there are some data/campaigns paths left in your 1.7 brent version, btw. 20090731 15:31:31-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Connection reset by peer] 20090731 15:31:41< CIA-62> ai0867 * r37350 /trunk/src/unit.cpp: Remove [stoned]->[petrified] compatibility hack. Do not bump min_savegame. 20090731 15:32:17-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 15:35:53-!- ancestral [n=ancestra@97-116-106-75.mpls.qwest.net] has quit ["And that’s the end of THAT chapter."] 20090731 15:37:09< melinath> soliton: whoops. Thanks. I have some other bugs I've been meaning to fix there... 20090731 15:37:20< melinath> will get on it. 20090731 15:37:27-!- Sirp [n=user@wesnoth/developer/dave] has joined #wesnoth-dev 20090731 15:42:13-!- n08eriaa [n=n08eriaa@merry.midgard.liu.se] has joined #wesnoth-dev 20090731 15:43:00< n08eriaa> is it possible to write and test ai:s for wesnoth without having to build it all from source? 20090731 15:43:05-!- n08eriaa is now known as yuid 20090731 15:43:46< Soliton> Crab_: ^ 20090731 15:44:20< Crab_> yuid: it is very hard to do without touching c++. but it is possible to use FormulaAI to script some ai actions, or pre-determine AI behavior in specific situations. 20090731 15:44:37-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #Wesnoth-dev 20090731 15:44:43< melinath> soliton: I can't find the ~/campaigns references you mentioned. Could you give an example file? 20090731 15:46:14< Soliton> melinath: in your _main.cfg. 20090731 15:46:55< Crab_> yuid: for example, in one of mainline scenarios, wolf rider patrol routes and behavior is scripted using FormulaAI. 20090731 15:47:00< yuid> Crab_: i should have said '... for wesnoth in C++ without ...' 20090731 15:47:23< yuid> Crab_: i know of formula, but i would like to try it in 'pure' c++ 20090731 15:48:30< melinath> Soliton: Hmm... I must have fixed it and then not uploaded a new version. In any case, I'll upload a version that works in a bit. 20090731 15:48:41< Crab_> yuid: no, there's no way to do it without compiling wesnoth. of course, you don't have to recompile everything each time - 'the rest of wesnoth' does not directly depend on individual ai implementations. 20090731 15:49:28< yuid> ok 20090731 15:49:35 * Soliton . o O (how to write source code in C++ without compiling?) 20090731 15:50:56< Crab_> Soliton: by using a dll, you don't have to compile 'main' program with uses said dll. 20090731 15:51:09< Crab_> Soliton: that dll stil has to be compiled, of course :) 20090731 15:51:09< yuid> Soliton: i was figuring whether it was possible to just compile my ai code and say link it to wesnoth in some simple manner 20090731 15:52:07-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 15:52:08< Crab_> yuid: it's possible that you can hack up a solution for your platform / build-system combo. 20090731 15:52:16-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 15:52:47< yuid> Crab_: what i'm searching for really is the least effort-demanding method :) 20090731 15:53:15< Soliton> well, if you don't change anything but ai code only that will be recompiled? 20090731 15:53:52< yuid> right, but i still have to download the source package and compile it 20090731 15:53:53< Crab_> Soliton: yes (if you don't touch one of a few 'exposed' headers) 20090731 15:54:26< Soliton> well, you'd want to test your AI anyway so you need the whole game? 20090731 15:55:45< yuid> my initital hopes came from the output of 'man wesnoth', under the --parm option 20090731 15:56:02< Crab_> yuid: least effort-demanding method is to just 'get linux (in virtual machine, if needed), get the source, compile/change/test' 20090731 15:58:34< yuid> ok 20090731 15:58:44< Crab_> yuid: there was a way for writing ai's in python, but it was removed 20090731 15:59:53< yuid> ah, that makes the choice simpler 20090731 16:00:21< yuid> (my strong preference for c++ over python already made quite simple, though) 20090731 16:05:20-!- Baufo [n=quassel@wesnoth/developer/baufo] has quit [Remote closed the connection] 20090731 16:09:22< Soliton> ilor: btw, any difficulties in setting up the server and irssi, anything i had forgot to mention? 20090731 16:14:27-!- BenUrban [n=benurban@unaffiliated/benurban] has quit ["Power failu"] 20090731 16:15:14< boucman> YogiHH: around ? 20090731 16:15:33< YogiHH> boucman: yes 20090731 16:15:51< boucman> YogiHH: you wrote most of the replay code IIRC... 20090731 16:16:08< YogiHH> boucman: yes 20090731 16:17:06< YogiHH> to be precise, most of what has to do with the specific replay controls, the replay functionality itself was already there when i joined the project 20090731 16:17:48< boucman> is there an easy way if you are in a replay (rather than real game) from c++ ? 20090731 16:17:49< boucman> the point is to skip sounds and messages when replaying 20090731 16:18:08< boucman> ok 20090731 16:18:29< YogiHH> boucman: you mean to detect if you are in a replay? 20090731 16:18:33< boucman> so far I've tested with if(!disp || disp->video().update_locked() || disp->video().faked() ) { 20090731 16:18:36< boucman> yes 20090731 16:19:10< boucman> "catching up" when loading an mp game is what i'm most interested in, more than replays 20090731 16:19:35< YogiHH> boucman: well, the standard way is to check the recorder variable, i think at_end() was the name of the method (don't have the code in front of me atm) 20090731 16:20:49< YogiHH> boucman: it's a global variable you can access anywhere 20090731 16:20:52< boucman> ok, i'll dig into it... 20090731 16:21:18< boucman> but iirc that tells me if i'm in a real replay, not when i'm catching up on a game 20090731 16:21:49< YogiHH> boucman: I think it applies to both 20090731 16:22:17< boucman> ok 20090731 16:22:44< YogiHH> boucman: The mechanisms are no different. Real replays are controlled by replay_controller, whereas catching up is forced by playmp_controller, but the should work the same 20090731 16:23:02< YogiHH> s/the/they 20090731 16:26:31< boucman> get_replay_source().at_end() <== would that be it ? 20090731 16:29:11< YogiHH> boucman: yes 20090731 16:29:22< boucman> ok, testing 20090731 16:30:03< silene> boucman: i'm not sure it matters, but please keep in mind that during a mp game, everything except for the current player is a replay, so testing this variable may not be a good idea 20090731 16:30:22< boucman> hmm 20090731 16:30:25< boucman> good point 20090731 16:30:56-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Read error: 60 (Operation timed out)] 20090731 16:31:10< YogiHH> boucman, silene: well, if you want to exclude sounds, it doesn't matter if it is for your own turns or for other sides, i guess 20090731 16:31:31< boucman> i only want to remove them in "fast replay" mode 20090731 16:31:34< silene> YogiHH: my point was that you don't want to exclude them in this case 20090731 16:31:42< boucman> because they are annoying and cpu/time consuming 20090731 16:31:50< boucman> normal replays and opposite turn should be kept 20090731 16:32:35< silene> boucman: i understand about skipping sound, but why not keep updating the playlist whether it is a fast replay or not? 20090731 16:33:57< boucman> silene: i didn't intend to, i'm reviewing the patch as we speak 20090731 16:34:29< YogiHH> boucman: hmm, i just remember i made a skip_replay variable, that is passed around quite a bit. Not sure, though, if its scope is sufficient for you. 20090731 16:34:50< YogiHH> boucman: maybe that's better suited for your purposes 20090731 16:35:32< boucman> i'll have a look at it 20090731 16:35:55< YogiHH> boucman: iirc, that's a member of one of the controller classes, too 20090731 16:36:33< YogiHH> could even be static... 20090731 16:36:46< boucman> most of them seems to use it, i'll check 20090731 16:37:18< boucman> it's a memeber of play_controller 20090731 16:37:44-!- Vlack [i=vlk@unaffiliated/vlack] has joined #wesnoth-dev 20090731 16:37:45< YogiHH> boucman: that is exclusively to cover the "fast replay" functionality 20090731 16:37:48< Vlack> hello 20090731 16:38:01< YogiHH> hi Vlack 20090731 16:38:04< boucman> YogiHH: wonderfull 20090731 16:38:07< boucman> that's what I want 20090731 16:38:13< Vlack> Is it tru YogiHH 20090731 16:38:37< Vlack> Is this true 20090731 16:38:40< Vlack> Get a free shell account. Its a slightly involved signup process for this .... at the forum or visit us in the IRC channel #wesnoth-dev 20090731 16:39:37< YogiHH> Vlack: So, what's up? 20090731 16:39:40< Vlack> I 20090731 16:39:53< Vlack> ? 20090731 16:40:11< Soliton> where is that from? 20090731 16:40:45< Vlack> is that true? 20090731 16:40:48< Vlack> http://www.nerdgeekhero.com/ 20090731 16:40:54< Soliton> no.. 20090731 16:41:16< Vlack> good 20090731 16:41:37< ilor> Soliton: I edited the paths in the scripts because it was faster than setting up everything in the exact locations, but generally no problems 20090731 16:41:37< wesbot> ilor: Sometimes we are fast 20090731 16:42:19< ilor> Soliton: maybe if there is / will be a guide it can point people to mkfifo because not everyone will know you need to use that 20090731 16:42:36< Soliton> Vlack: it doesn't say anything like that there. 20090731 16:42:59< Vlack> Soliton, mixed up 20090731 16:43:07< Vlack> Didn't read the whole story 20090731 16:43:10-!- Aethaeryn [n=Michael@69.251.9.23] has joined #Wesnoth-dev 20090731 16:43:12< Vlack> It was in google 20090731 16:43:15< Vlack> NerdGeekHero 20090731 16:43:15< Soliton> you don't need to make a fifo, ilor. the server will do that for you. 20090731 16:43:15< Vlack> Get a free shell account. Its a slightly involved signup process for this .... at the forum or visit us in the IRC channel #wesnoth-dev on irc.freenode.net. ... 20090731 16:43:15< Vlack> www.nerdgeekhero.com/ - Cached - Similar 20090731 16:44:01< loonycyborg> Yep. You can get rather confusing out-of-context quotes from google :P 20090731 16:44:02< Vlack> thanks 20090731 16:44:34-!- Vlack [i=vlk@unaffiliated/vlack] has left #wesnoth-dev ["Bye"] 20090731 16:45:13< ilor> Soliton: ah, true, but then you need to have the server have write perms in the dir which I didn't have ;) 20090731 16:46:16-!- YogiHH [i=d4ca9d15@wesnoth/developer/yogihh] has left #wesnoth-dev [] 20090731 16:52:47-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has joined #wesnoth-dev 20090731 16:53:15< Crab_> boucman: ftp://ftp.terraninfo.net/wesnoth/2009july31.aicfg.diff.zip 20090731 16:56:02< Crab_> boucman: known broken things: 'avoided locations' ([avoid] tag), removal of recruitment pattern entries if they are invalid 20090731 17:01:28< AI0867> YogiHH: is there a reason recruits are recorded before being executed? as error checking was already possible before I split up recruit_unit(), I didn't touch this code. 20090731 17:06:02-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Client Quit] 20090731 17:06:24-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 17:07:40-!- yuid [n=n08eriaa@merry.midgard.liu.se] has quit ["leaving"] 20090731 17:08:30< ilor> Soliton: this new lobby /command feature will need an upgrade though 20090731 17:09:06< ilor> iirc now every use of a lobby: /ban someone will be recorded as *socket* banning someone, the info about the actual issuer of the command is lost 20090731 17:10:00< boucman> Crab_: rereading something else atm, will switch to that afterward 20090731 17:10:09< Crab_> ok 20090731 17:10:18< Soliton> ilor: sure, but there are irc logs. 20090731 17:10:42< ilor> Soliton: we log wesnoth-mp-lobby-*? 20090731 17:10:51< ilor> if so then it's not a big deal 20090731 17:11:48< Soliton> www.wesnoth.org/irclogs 20090731 17:12:35< ilor> certainly not a big deal then :) 20090731 17:13:27< Soliton> so now you can check who kicked/banned you! ;-) 20090731 17:19:14< ilor> hm, lobby chat logging into the lobby bot is broken in trunk 20090731 17:20:01< ilor> most likely becuase I output stuff differently to the log 20090731 17:20:31-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 17:20:33< Soliton> please don't change logging output unless really necessary. 20090731 17:21:00< Soliton> it makes any kind of stats gathering a pain. 20090731 17:21:05< ilor> well, too late, it got changed some time ago when I was doing the room system on the server 20090731 17:21:10-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 17:21:11< ilor> I will now go and fix it I guess 20090731 17:21:41< Soliton> what changed? 20090731 17:21:52< ilor> lobby messages don't end up in the log at al 20090731 17:23:52< Soliton> a because it's not a game anymore, i guess. 20090731 17:24:06< ilor> I just forgot about it during the refactor 20090731 17:25:22< Soliton> the "if (owner_ == 0)" checks are obsolete now, no? 20090731 17:26:45< corn> Ivanovic: I must not have gotten that corrospondence, the last message in my inbox was her reply to the melange team 20090731 17:28:06< ilor> Soliton: well, there aren;t ny sve for an assert and maybe a if owner = 0 output error 20090731 17:28:10< ilor> *save for a 20090731 17:34:14< Ivanovic> corn: forwarded it to you 20090731 17:38:41< corn> Ivanovic: thanks 20090731 17:42:53-!- silene [n=plouf@wesnoth/developer/silene] has quit ["Leaving."] 20090731 17:47:49-!- EdB [n=edb@213.12.95-79.rev.gaoland.net] has joined #wesnoth-dev 20090731 17:54:55-!- silene [n=plouf@wesnoth/developer/silene] has joined #wesnoth-dev 20090731 17:55:39-!- ABCD [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 17:55:56-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 17:57:37-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev 20090731 18:00:50-!- boucman [n=rosen@wesnoth/developer/boucman] has quit [Read error: 104 (Connection reset by peer)] 20090731 18:02:05-!- boucman [n=rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20090731 18:18:40< CIA-62> thespaceinvader * r37351 /trunk/data/core/ (9 files in 2 dirs): Add and wire new Thunderer melee animation 20090731 18:22:03-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has quit ["Saurian Augur - I'll heal you by 4 hp if you leave next to me"] 20090731 18:25:21-!- Noyga [n=lame-z@wesnoth/developer/noyga] has joined #wesnoth-dev 20090731 18:27:43< CIA-62> turuk * r37352 /trunk/data/core/units/drakes/Enforcer.cfg: Updated description. 20090731 18:28:29-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20090731 18:29:01< boucman> shadowmaster: around ? 20090731 18:29:54< AI0867> Noyga: how are the plans to maintain EE? 20090731 18:30:46< Noyga> AI0867, err no plan, i'm currently inactive 20090731 18:31:07< Noyga> too much life :/ 20090731 18:32:45< noy> who is? 20090731 18:34:43< AI0867> noy: noyga is EE's maintainer. The collection of everything and then some called BEEM is maintained by voodoo 20090731 18:35:06< noy> BEEM is basically what everybody yses 20090731 18:35:07< noy> uses 20090731 18:36:34< AI0867> it took over completely in 1.6? 20090731 18:37:09-!- elias [n=allefant@allegro/developer/allefant] has quit [Read error: 110 (Connection timed out)] 20090731 18:37:09< AI0867> because last time I checked, their calling it balanced is like the old warsaw pact countries calling themselves democratic 20090731 18:37:43-!- elias [n=allefant@allegro/developer/allefant] has joined #wesnoth-dev 20090731 18:37:45< noy> yes 20090731 18:37:51< noy> I completely agree 20090731 18:38:44< AI0867> voodoo was also nice enough to spot some errors in EoS, fix it in BEEM and forego telling me about it 20090731 18:39:59< CIA-62> cornmander * r37353 /website/stats.wesnoth.org/wesstats/controllers/root.py: 20090731 18:39:59< CIA-62> Added backwards compatibility with uncompressed log files (v1). Added another default value to 20090731 18:39:59< CIA-62> the log dictionary to work with slightly incomplete logs (not sure why the game produces 20090731 18:39:59< CIA-62> these...) 20090731 18:41:08-!- Turuk_ [n=Turuk@wesnoth/forumsith/turuk] has joined #wesnoth-dev 20090731 18:42:44-!- EdB [n=edb@213.12.95-79.rev.gaoland.net] has quit [Remote closed the connection] 20090731 18:43:06< corn> I haven't gotten any commit mails in the past two days, is there a problem with GNA? 20090731 18:45:02< AI0867> gna is bugged slightly more than usual 20090731 18:45:12< corn> ok 20090731 18:45:25< AI0867> interestingly enough, CIA works again, so they fixed about half the issue 20090731 18:45:51< AI0867> I do wonder what's so hard about commit hooks 20090731 18:46:57< corn> is there any way to browse the WML tree in-game? 20090731 18:49:27< corn> right now I am adding the map_data key to the stuff sent in upload_logs 20090731 18:49:30-!- Turuk [n=Turuk@wesnoth/forumsith/turuk] has quit [Read error: 110 (Connection timed out)] 20090731 18:53:11-!- blarumyrran [n=minaise@81-20-159-197.levira.ee] has joined #wesnoth-dev 20090731 18:58:52-!- mjs-de [n=mjs-de@vpw.wh.uni-dortmund.de] has quit ["On the road again"] 20090731 19:02:56-!- grzywacz [n=grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev 20090731 19:03:02-!- giusef [n=giusef@unaffiliated/giusef] has joined #wesnoth-dev 20090731 19:04:52< AI0867> in-game? I don't believe so, though you could add a command to dump the tree to stdout or something like that, not sure if that's what you want though 20090731 19:06:57< corn> nope 20090731 19:07:15< corn> really I just need to figure out how to get the map_data key passed to the upload_log struct 20090731 19:09:28-!- Elvish_Pillage2 [n=eli@71-10-231-36.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev 20090731 19:09:42< Crab_> corn: get game_map from resources::, then get map_data from game_map 20090731 19:13:30< shadowmaster> boucman: here 20090731 19:13:45< corn> Crab_: ok, thanks 20090731 19:13:59< boucman> shadowmaster: I have a clean fix for bug 14039, but i'm not sure how to test your case... 20090731 19:14:13< shadowmaster> wesbot: bug 14039 20090731 19:14:14< wesbot> Bug #14039 Assigned to: Jérémy Rosen Status: None Priority: 5 - Normal 20090731 19:14:17< wesbot> Summary: All initial music playlists broken since r36270, more potential side-effects 20090731 19:14:21< wesbot> Original submission: SVN revision #36270 introduces some changes in game_event 20090731 19:14:23< wesbot> s.cpp which prevent music playlists from being modified in any temporary or perm 20090731 19:14:27< wesbot> URL: https://gna.org/bugs/?14039 20090731 19:15:04< shadowmaster> boucman: well, the "test" is just turning music on and ensuring HttT 1 starts with anything but revelation.ogg which was the story music for that scenario 20090731 19:15:15< shadowmaster> or UtBS 1 and elf-land.ogg, which is shorter and more annoying 20090731 19:15:27< boucman> ok, thx 20090731 19:15:51< shadowmaster> whtever fixes the [music] case should be used for the [sound], [sound_source], [label] etc cases 20090731 19:18:14< corn> Crab_: ok, I need to get a hold of gamemap::tiles_, which is a 2d t_terrain vector 20090731 19:19:02-!- ardesh [n=ardesh@port-92-206-108-65.dynamic.qsc.de] has joined #wesnoth-dev 20090731 19:19:18< corn> ah, there is a nice write_game_map function that already returns a std::string 20090731 19:19:22< corn> thanks 20090731 19:22:16< shadowmaster> away now. 20090731 19:25:37-!- Elvish_Pillager [n=eli@71-10-231-36.dhcp.oxfr.ma.charter.com] has quit [Read error: 110 (Connection timed out)] 20090731 19:31:45-!- Turuk [n=Turuk@74.83.20.222] has joined #wesnoth-dev 20090731 19:33:20-!- Netsplit brown.freenode.net <-> irc.freenode.net quits: nital 20090731 19:39:41-!- Turuk_ [n=Turuk@wesnoth/forumsith/turuk] has quit [Read error: 110 (Connection timed out)] 20090731 19:39:59-!- busfahrer [n=busfahre@unixboard/user/busfahrer] has quit ["leaving"] 20090731 19:51:15-!- ABCD_ [n=ABCD@gentoo/contributor/abcd] has joined #wesnoth-dev 20090731 19:53:12-!- ABCD [n=ABCD@gentoo/contributor/abcd] has quit [Read error: 104 (Connection reset by peer)] 20090731 19:54:00-!- Netsplit over, joins: nital 20090731 19:56:56-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has joined #wesnoth-dev 20090731 19:57:51< ilor> hi noy 20090731 19:58:04< noy> hey 20090731 19:58:10< noy> I'm just heading out 20090731 19:58:19< noy> is there something I can quickly help you with? 20090731 19:58:22< ilor> noy: there's a new feature in the lobby bot that you might like :) 20090731 19:58:41< noy> oh does it use commands? 20090731 19:58:48< ilor> noy: you can get voice/op in one of the mp-lobby chans, and then say lobby: /kick foo 20090731 19:59:27< ilor> basically all the /query commands like ban kick etc are there 20090731 20:00:20-!- noy [n=Noy@wesnoth/developer/noy] has quit [] 20090731 20:00:51< ilor> noy: I hope you'll have the time to have a look when you're back ;) 20090731 20:04:30-!- ilor [n=ilor@wesnoth/developer/ilor] has quit [Read error: 104 (Connection reset by peer)] 20090731 20:13:26< CIA-62> cornmander * r37354 /trunk/src/ (playsingle_controller.cpp upload_log.cpp upload_log.hpp): Added map data to the upload log. 20090731 20:17:01< Crab_> boucman: I've added some documentation, http://www.wesnoth.org/wiki/Ai_Module#AI_Config_Format 20090731 20:17:56-!- Netsplit brown.freenode.net <-> irc.freenode.net quits: nital 20090731 20:18:37-!- Netsplit over, joins: nital 20090731 20:18:40< boucman> Crab_: yes, already read it :) 20090731 20:18:48< Crab_> hehe ) 20090731 20:25:58< CIA-62> thespaceinvader * r37355 /trunk/data/core/units/dwarves/Explorer.cfg: Fix Explorer description. 20090731 20:26:12< Crab_> boucman: it seems that gna has eaten my today's email to dev-ml about boost 1.3.5 20090731 20:26:39< Crab_> s/1.3.5/1.35 20090731 20:34:04-!- noy [n=Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20090731 20:47:42< boucman> Crab_: repost :P 20090731 20:47:49< boucman> once gna is full it'll stop eating 20090731 20:49:34< CIA-62> turuk * r37356 /trunk/data/core/units/drakes/ (Arbiter.cfg Clasher.cfg Enforcer.cfg Warden.cfg): Capitalization adjustment in the descriptions per decided standard. 20090731 20:50:07< CIA-62> boucman * r37357 /trunk/src/ (game_events.cpp play_controller.hpp): rework sound skiping, fix bug 14039 20090731 20:50:47< Crab_> boucman: yes, I'll repost later. meanwhile, I'll fix some @todo's in my WIP, and comment it more. it's, imo, ready for commit (those things that are broken there can be fixed afterwards). What's your opinion about that patch ? 20090731 20:50:50< corn> Crab_, boucman: I put in map data as a wml variable, but it creates difficulty for my braindead parser because the map data is multiline and the parser can only read single line variables. do you think it would be better to reencode the map data somehow server-side or to make the parser smarter 20090731 20:51:24< Crab_> corn: what do you use for parser ? 20090731 20:51:38< corn> it's just a python script I wrote, I will pastebin in a second 20090731 20:51:45< boucman> Crab_: havn't really started reviewing yet, i was on a bug, starting right away 20090731 20:52:10< Crab_> boucman: ok 20090731 20:52:13< corn> http://pastebin.com/m527c2232 20090731 20:53:12< corn> it would probably be better to encode it client-side because more complicated parsing would be slower 20090731 20:53:41< corn> and the server needs to handle as many upload logs as possible pers econd 20090731 20:54:16< boucman> +config aspect::to_config() const 20090731 20:54:17< boucman> +{ 20090731 20:54:17< boucman> + config cfg; 20090731 20:54:17< boucman> + cfg["invalidate_on_turn_start"] = invalidate_on_turn_start_ ? "yes" : "no"; 20090731 20:54:17< boucman> + cfg["invalidate_on_tod_change"] = invalidate_on_tod_change_ ? "yes" : "no"; 20090731 20:54:17< boucman> + cfg["invalidate_on_gamestate_change"] = invalidate_on_gamestate_change_ ? "yes" : "no"; 20090731 20:54:19< boucman> + cfg["invalidate_on_minor_gamestate_change"] = invalidate_on_minor_gamestate_change_ ? "yes" : "no"; 20090731 20:54:21< boucman> + 20090731 20:54:34< boucman> Crab_: why did you stop using lxical_cast as you did in your previous patch ? 20090731 20:55:10< Crab_> boucman: it gave "0" for false, and "1" for true, and that is not consistent with standard way of writing booleans as config values 20090731 20:55:26< boucman> ok 20090731 20:55:41< boucman> don't we have a standard function to do that yes/no stuff ? 20090731 20:56:44< boucman> +template 20090731 20:56:44< boucman> +class config_value_translator { 20090731 20:57:05< boucman> couldn't all these be moved into a generic config file instead of AI specific place at some point ? 20090731 20:57:43< Crab_> "boucman: don't we have a standard function to do that yes/no stuff ?" for example, in src/team.cpp, this way is used, too - cfg["hidden"] = hidden ? "yes" : "no"; 20090731 20:57:56< boucman> ok, so we probably don't ;) 20090731 20:58:30< Crab_> about 'config_value_translator' -yes, there's even a '// @todo: move to some other place' there :) 20090731 20:58:49< boucman> hehe 20090731 21:03:41< Crab_> corn: imo, it's better to make the parser smarter. because having different representations of the same WML will cause more long-term problems that will be fixed by reencoding. 20090731 21:05:00< Crab_> corn: or, if you are going for 'max speed', drop WML completely from here - reencode as something totally different, something for which good python parser is already available. 20090731 21:05:45-!- giusef [n=giusef@unaffiliated/giusef] has quit ["exit (-1);"] 20090731 21:05:51< corn> that is a good point 20090731 21:06:14< corn> is there any chance in the future that wml will be converted into xml 20090731 21:06:49< boucman> corn: very unlikely 20090731 21:06:55< corn> it would move a lot of code out of wesnoth and into upstream packages like expat 20090731 21:07:19< Crab_> corn: no, WML has certain advantages (which do not apply in your case) 20090731 21:07:40< corn> what are they? 20090731 21:08:05< corn> I don't have much experience with coding mark up languages, so I didn't realize there was a difference 20090731 21:09:09< Crab_> corn: afaik, it is the availability of gettext internationalization, and control over internal representation 20090731 21:09:56< corn> ah 20090731 21:10:08< corn> ok 20090731 21:10:17< corn> in any case, it would be an extremely significant recode 20090731 21:10:37< Crab_> corn: http://www.wesnoth.org/forum/viewtopic.php?p=295012#p295012 20090731 21:12:10< Crab_> corn: btw, the 'least' recode is, probably, coding the stats collection server in C++ and reusing wesnoth wml implementation 20090731 21:12:44< corn> Crab_: there is already a WML parser coded in python as well, it is used by wmllint 20090731 21:13:19-!- melinath [n=melinath@pool-71-162-41-64.altnpa.east.verizon.net] has quit [Remote closed the connection] 20090731 21:13:33< Crab_> corn: then why you've made another ? 20090731 21:13:50-!- melinath [n=melinath@pool-71-162-41-64.altnpa.east.verizon.net] has joined #wesnoth-dev 20090731 21:13:53< corn> and sirp has very good points about why wml is better thin this case 20090731 21:14:04< corn> Crab_: wmllint implementation is much more complex 20090731 21:14:10< Crab_> ok 20090731 21:15:23< corn> I think I am going to go with reencoding the particular datatype, the problem of incompatibility with the regular map data should not be a problem as long as no one tries to use the upload logs for other purposes 20090731 21:15:45< corn> I think I can make my parser even fewer lines, the current implementation is very unpythonic 20090731 21:15:52< corn> fewer lines + faster 20090731 21:17:05< Soliton> utils::string_bool() is the function to convert WML values to boolean. 20090731 21:17:25< Soliton> if the use is just internal it's not important to use it though. 20090731 21:17:58< Crab_> Soliton: known. the question is about the reverse function, boolean -> string (-> wml attribute ) 20090731 21:18:47< Soliton> ok, you can use whatever of the valid values you want then. 20090731 21:19:33-!- olik_ [n=olik@85-220-66-214.dsl.dynamic.simnet.is] has quit [Read error: 104 (Connection reset by peer)] 20090731 21:19:40< Crab_> Soliton: btw, it will be changed if/when new config functions will be added, such as set_attribute 20090731 21:21:17-!- melinath [n=melinath@pool-71-162-41-64.altnpa.east.verizon.net] has left #wesnoth-dev [] 20090731 21:21:24-!- melinath [n=melinath@pool-71-162-41-64.altnpa.east.verizon.net] has joined #wesnoth-dev 20090731 21:21:49< Soliton> also i'm pretty sure wmllint does not use a wml parser. 20090731 21:22:03< Soliton> it's just regex based. 20090731 21:23:28< corn> wesnoth/data/tools/wesnoth/wmlparser.py 20090731 21:23:47-!- olik [n=olik@85-220-78-118.dsl.dynamic.simnet.is] has joined #wesnoth-dev 20090731 21:24:10< Soliton> yes, we have a wml parser. 20090731 21:24:51< corn> ok, I was wrong about wmllint using it 20090731 21:25:53-!- Aethaeryn [n=Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Read error: 113 (No route to host)] 20090731 21:42:26< melinath> is DM only a mainline campaign as of 1.7? 20090731 21:42:34< Soliton> yes. 20090731 21:43:17< melinath> kk. What's the status of the bug that makes wesnoth crash when haloes should be displayed? 20090731 21:43:35< Soliton> boucman: ^ 20090731 21:43:59< Soliton> i don't think there is any such bug filed so far. 20090731 21:44:06< melinath> I'd like to debug through DM looking at text context, but I can't start a game due to it crashing. :-p 20090731 21:44:25< melinath> I filed a bug today in tech support 20090731 21:44:32< melinath> if there wasn't one before 20090731 21:45:25< boucman> melinath: never heard about it, please open a bug, with a way to reproduce (savegame would be great) and ping me here once you're done :) 20090731 21:45:35< melinath> http://www.wesnoth.org/forum/viewtopic.php?f=4&t=26477 20090731 21:45:56< melinath> I supplied the console error etc. No savegame because it happens in the first turn. 20090731 21:46:07< melinath> Just try loading Delfador's Memoirs, for example. 20090731 21:46:20< boucman> simply creating a shyde ? 20090731 21:46:22< boucman> testing 20090731 21:46:46 * Soliton plays trunk with a shyde and several other units with halos. 20090731 21:47:19< Soliton> so if there was a bug with that in 1.7.2 it's already fixed. 20090731 21:47:23< boucman> works here... 20090731 21:47:33< melinath> hmm... 20090731 21:47:45< melinath> okay. Must just be me. erg. 20090731 21:48:03< Soliton> well, boucman probably also tried trunk. 20090731 21:48:13< boucman> indeed 20090731 21:48:17< melinath> I'm running off the repository 20090731 21:48:47< melinath> Good to know it's fixed, though. 20090731 21:49:15< corn> just because they can't replicate doesn't necessarily mean it is fixed 20090731 21:49:17< corn> unfortunately 20090731 21:50:41< melinath> *good to know there's a pretty decent chance that it'll work with the next repository update. 20090731 21:54:02-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev 20090731 21:54:45< Sirp> hi happygrue 20090731 21:54:55< happygrue> hello 20090731 21:56:20-!- YogiHH [n=chatzill@c211151.adsl.hansenet.de] has joined #wesnoth-dev 20090731 22:00:25-!- Crab_1 [n=Crab_@pedlarness.consul.volia.net] has joined #wesnoth-dev 20090731 22:00:26-!- Crab_ [n=Crab_@wesnoth/developer/crab] has quit [Read error: 104 (Connection reset by peer)] 20090731 22:00:45-!- kitty__ [n=kitty@e180197245.adsl.alicedsl.de] has joined #wesnoth-dev 20090731 22:01:04-!- Crab_1 [n=Crab_@pedlarness.consul.volia.net] has quit [Client Quit] 20090731 22:01:23-!- Crab_ [n=Crab_@wesnoth/developer/crab] has joined #wesnoth-dev 20090731 22:16:14< CIA-62> cornmander * r37358 /website/stats.wesnoth.org/ (configuration.py.example wesstats/controllers/root.py): Upload script now saves incoming maps to a path in the filesystem. 20090731 22:16:53-!- ilor [n=user@wesnoth/developer/ilor] has joined #wesnoth-dev 20090731 22:30:08< Soliton> ilor: a command to message a specific user would be nice for irc so that you can answer adminmsg users. 20090731 22:30:23< ilor> true 20090731 22:31:18< boucman> Crab_: good for commit afaict 20090731 22:31:56< ilor> Soliton: suggestions for the name? ;) 20090731 22:32:04-!- noy [n=Noy@wesnoth/developer/noy] has quit ["GO, GET TO THE CHOPPAH!!!"] 20090731 22:33:02< Soliton> ilor: that is the question indeed. :-) 20090731 22:33:30-!- Jetrel [n=Jetrel@wesnoth/artist/jetrel] has joined #wesnoth-dev 20090731 22:34:03< Jetrel> thespaceinvader: you've pinged me, but you appear to my machine to be offline 20090731 22:34:09< Soliton> m or message, maybe. 20090731 22:34:15< thespaceinvader> ah 20090731 22:34:18< thespaceinvader> i forgto to do this 20090731 22:34:24< Crab_> boucman: good. I'll complete/test some stuff with 'avoid' aspect (I'm making it use a SLF), then I'm ready to commit. should I commit without waiting for the gna dev-ml to work again ? if yes, then, should I make changes to buildsystem files to account for boost 1.35 dependency ? 20090731 22:34:26< thespaceinvader> better? 20090731 22:34:37< Jetrel> thespaceinvader: nope 20090731 22:34:39< ilor> Soliton: actually adminmsg would be good if it wasn't used for the opposite :P 20090731 22:34:43< thespaceinvader> oh 20090731 22:34:45< thespaceinvader> how odd 20090731 22:34:54< thespaceinvader> brb 20090731 22:34:57-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has quit ["ChatZilla 0.9.85 [Firefox 3.0.12/2009070611]"] 20090731 22:35:04< Soliton> ilor: best would be if msg would be servermsg. 20090731 22:35:04< Jetrel> Likewise. 20090731 22:35:12-!- Jetrel [n=Jetrel@wesnoth/artist/jetrel] has quit ["Remember also the arabian proverb, which tells us that on the tree of silence, there hangs its fruit, which is peace."] 20090731 22:35:15< ilor> adminresp? 20090731 22:35:17-!- thespaceinvader [n=chatzill@wesnoth/artist/thespaceinvader] has joined #wesnoth-dev 20090731 22:35:29-!- Jetrel [n=Jetrel@wesnoth/artist/jetrel] has joined #wesnoth-dev 20090731 22:35:44< boucman> Crab_: i think you shouldn't wait for gna, this commit has been around for way too long 20090731 22:35:50< thespaceinvader> Jetrel: better? 20090731 22:36:10< Crab_> boucman: ok, then I'll commit it later today. and, what about the second question ? 20090731 22:36:10< Soliton> well, it's not really specific to responding to adminmsgs but yeah, maybe. 20090731 22:36:14< Jetrel> Yes. :) 20090731 22:36:15< boucman> my guess is that boost will be a non-issue, but put in the commit log message since gna is down 20090731 22:36:23< Crab_> ok 20090731 22:36:30< ilor> or maybe 'intimidate' :P 20090731 22:38:03< Soliton> though if it would appear to come from the server adminsomething would make sense. 20090731 22:39:07< Crab_> boucman: ok. I see how to patch scons/cmake/automake files to properly check for 1.35, but I don't know about MSVC/CodeBlocks. 20090731 22:39:12< ilor> Soliton: from the players POV it will appear as an "Message from server admin: $msg" or sth 20090731 22:39:35< boucman> ok 20090731 22:39:58< ilor> Crab_: MSVC is manual labor with regards to dependecy checking anyway so I guess don't bother 20090731 22:40:12< loonycyborg> Crab_: MSVC/CodeBlocks don't check boost version :) 20090731 22:40:23< ilor> Crab_: unless you have code that builds but breaks at runktime with some old boost 20090731 22:40:38< corn> Crab_: how big is the patch? 20090731 22:41:15< corn> loc 20090731 22:41:29< Soliton> ilor: well, there is a hack currently to make adminmsgs appear from the irc nick. 20090731 22:42:00< Crab_> ilor: no, it will break on compilation (missing boost::dynamic_pointer_cast ) 20090731 22:42:05< Crab_> loonycyborg: ok :) 20090731 22:43:01< Crab_> corn: 6453 (with context) 20090731 22:43:12< corn> that is fearsome :) 20090731 22:43:22< corn> you are probably adding 5% to the total wesnoth codebase 20090731 22:43:39< Crab_> corn: no, without context, it's smaller :) 20090731 22:43:51-!- Espreon [n=espreon@wesnoth/developer/espreon] has joined #wesnoth-dev 20090731 22:44:11< corn> if it is a bunch of large changes then context will be small compared to your changes 20090731 22:44:14< corn> but you're right :) 20090731 22:45:01< boucman> corn: lots of code moved around => big patch 20090731 22:46:12< Crab_> corn: wesnoth's ./src (including comments and blank lines) is 200 kloc. 20090731 22:48:17-!- silene1 [n=plouf@AMarseille-251-1-73-132.w83-205.abo.wanadoo.fr] has joined #wesnoth-dev 20090731 22:48:57< corn> ok 20090731 22:49:42< corn> I am wondering, in terms of database structure, how should I store information on what location a unit was killed at, what kind of unit, and what kind of unit it was killed by 20090731 22:50:27< corn> right now I am planning a 3 column table with the map file checksum as an identified, the game id, and a large column that will store that data as a CSV list 20090731 22:50:38< corn> and each row will be a seperate game upload 20090731 22:51:13-!- Jetrel [n=Jetrel@wesnoth/artist/jetrel] has left #wesnoth-dev [] 20090731 22:51:31< CIA-62> ivanovic * r37359 /trunk/ (5 files in 4 dirs): updated Czech translation 20090731 22:51:36< CIA-62> ivanovic * r37360 /branches/1.6/po/ (wesnoth/cs.po wesnoth-editor/cs.po): updated Czech translation 20090731 22:52:27< YogiHH> corn: wouldn't that be a pain to do aggregating reports if the data is hidden in a string csv list? 20090731 22:52:48< Crab_> corn: unit_types: {unit_type_id,unit_type_name_string} kill_map {map_id, turn_of_kill, killed_unit_type_id, killer_unit_type_id } ? 20090731 22:52:51< ilor> corn: cvs or anything of the like is a big no-no in DB design 20090731 22:53:01< ilor> *csv 20090731 22:53:36< Crab_> plus the location x,y, of course :) 20090731 22:53:58< corn> YogiHH, Crab_: the flipside is I blow up the data into a bunch of seperate tables then I will have to JOIN it and there will be big performance hits 20090731 22:54:26< ilor> corn: that's less of a performance hit than what you'd end up doing: massive string concat 20090731 22:54:38< YogiHH> corn: with proper indexing, that shouldn't be a problem 20090731 22:54:45< ilor> RDBS is designed for joins 20090731 22:54:58< corn> ok 20090731 22:55:55< Crab_> corn: note that you don't have to join 20090731 22:56:14-!- silene1 [n=plouf@AMarseille-251-1-73-132.w83-205.abo.wanadoo.fr] has quit ["Leaving."] 20090731 22:56:49< Crab_> corn: just do a select on kill_map, without joining 20090731 22:57:44< Soliton> ilor: we also need a way for the response of admin commands to make it back to irc. 20090731 22:58:02< Crab_> corn: and, then, cache those page fragments which depend on unit type stats, in something like memcached, with key= unit_type_id 20090731 22:58:18< corn> Crab_: ok, that is a good idea 20090731 22:58:21< Crab_> then, for regular queries, you will only need to hit the db for kill maps 20090731 22:58:42< ilor> Soliton: well, we can just log admin commands in stderr and make them go through to irssi 20090731 22:59:11< corn> Crab_: in your structure, don't I need to JOIN to recover the unit type? 20090731 22:59:21< Soliton> ilor: probably simply add some id string to the logging of process_command(). 20090731 22:59:44< Soliton> ilor: clearly we'll not invent a new way of communication, yes. ;-) 20090731 23:00:09< Soliton> ilor: but we don't want the response of all admin commands to show up. 20090731 23:00:23< ilor> Soliton: we can make it do only for the socket commands 20090731 23:00:34< Soliton> which is why i meant to add.. only add.. indeed. 20090731 23:01:11< Soliton> but not all responses are logged that way some (mostly errors) return directly. 20090731 23:01:18< Crab_> corn: no, you only need the id 20090731 23:01:35< Crab_> corn: and you have them in kill_map - killed_unit_type_id and killer_unit_type_id 20090731 23:02:08< corn> Crab_: I will put everything into a table like this {map_id,game_id,turn,killed_type,killed_level,killer_type,killer_level,position} 20090731 23:02:24< corn> for a generic unit, is type == id? 20090731 23:02:54< corn> and then for leader units, id != type 20090731 23:03:01< corn> because that is how I am thinking about it 20090731 23:03:02< ilor> Soliton: regarding the admin response, it can be made to have the irc nick like adminmsg do, so it'd be a special case 20090731 23:03:30< Crab_> by 'id' i mean 'surrogate id' of the db table which holds info about unit type name, description (maybe, later, internationalized), picture, etc 20090731 23:04:07< ilor> Soliton: I'd prefer to make it so all socket communication get the irc name, but that means either having to edit server code in all the versions we're running or having the irc handling depend on the server version 20090731 23:04:46< corn> Crab_: ok, I understand 20090731 23:05:05-!- silene [n=plouf@wesnoth/developer/silene] has quit [Read error: 110 (Connection timed out)] 20090731 23:05:09< Soliton> ilor: sounds good to me. 20090731 23:05:19< Crab_> corn: and you can just make leaders 'a dummy type' 20090731 23:05:22< ilor> Soliton: which alternative? :P 20090731 23:05:31< corn> Crab_: this is my proposed structure then: {map_id,game_id,turn,killed_id,killed_type,killed_level,killer_id,killer_type,killer_level,position} 20090731 23:06:01< corn> where killed_id and killer_id would be keys in a seperate table 20090731 23:06:13< Soliton> ilor: 1.6 is actively maintained still if that's what you mean? 20090731 23:06:18< corn> and stats regarding those units would be cached 20090731 23:06:27< Crab_> corn: why do you need killed_type / killer_type ? 20090731 23:06:49< Crab_> corn: and note that level is not necessary 20090731 23:06:51< Soliton> really i'm not sure what problem you see. 20090731 23:06:56< corn> so that you can filter right on the killmap for saying ex. "where zombies die most often" 20090731 23:07:51< Crab_> corn: well, you can get the 'db id' of the zombie type from a (cached) unit_types table, and filter using it. 20090731 23:08:24< boucman> wesbot: help 20090731 23:08:24< wesbot> boucman: I could tell you about bug(s), feature(s), task(s), patch(es), a log revision, update the topic, last seen of people... you name it. 20090731 23:08:36< boucman> wesbot log 34920 20090731 23:08:39< wesbot> esr * r34920 : Change the terrain definition tag from [terrain] to [terrain_type]. 20090731 23:08:43< wesbot> URL: http://svn.gna.org/viewcvs/wesnoth?view=rev&rev=34920 20090731 23:09:04< ilor> Soliton: nvm, I'll just make it work : 20090731 23:09:05< ilor> :) 20090731 23:09:06< corn> Crab_: that is true. however, why is not level not necessary? 20090731 23:09:15< YogiHH> afk 20090731 23:09:19< Crab_> corn: for example, open data/core/units/drakes/Flameheart.cfg 20090731 23:09:32< Crab_> corn: look for 'level=3' definition 20090731 23:09:33-!- Kenpachi_ [n=chatzill@CPE-58-170-90-28.sa.bigpond.net.au] has joined #wesnoth-dev 20090731 23:10:02< Soliton> ilor: the only point where the name is important is for adminmsg so far. 20090731 23:10:02< esr> boucman: Did that change break something? It was quite a while ago now. 20090731 23:10:06< corn> however, the unit could level up in-game 20090731 23:10:31< boucman> esr: yes, see bug 13967 20090731 23:10:38< Soliton> ilor: i suggest using the same protocol as adminmsg does atm but do it for everything. 20090731 23:10:48< boucman> fixing the wolfrider is trivial, but it's probably a job for wmllint... 20090731 23:11:02< boucman> was going to call yoou once I had finished assessing the situation 20090731 23:11:06< ilor> Soliton: I'll be changing the fifo "line-protocol" from "foo bar == /query foo bar" to "foo bar == /query foo (issued by bar from irc)" 20090731 23:11:12< Soliton> ilor: the nice side effect then is that you can't do shut_down from irc again. 20090731 23:11:12< Crab_> corn: level up a drake flameheart, L3 unit. what will be the level of resulting unit ? 20090731 23:11:13< esr> Looking... 20090731 23:11:29-!- happygrue [n=George@wesnoth/developer/wintermute] has quit [Read error: 104 (Connection reset by peer)] 20090731 23:11:32< ilor> Soliton: ah, reverse the foobar order in the last bit :) 20090731 23:11:57< esr> boucman: You are right. This appears to be a job for wmllint. 20090731 23:12:17< Crab_> corn: it will stay a L3 drake flameheart 20090731 23:12:18< Soliton> ilor: i don't get it. can you give an example? 20090731 23:12:30< boucman> esr: ok, i'll reassing to you so it doesn't get lost 20090731 23:12:31< Soliton> ilor: did you mean /foo bar? 20090731 23:12:39< esr> Assign it to me, please. with a not explaining that the tag change seems to be at the root. 20090731 23:12:43< boucman> (btw, we forgot to document that name change, doing it atm) 20090731 23:13:02< corn> Crab_: what about an L1 unit advancing to L2? 20090731 23:13:05< ilor> Soliton: foo bar in the fifo will be interpreted as bar coming from user foo 20090731 23:13:07< Crab_> corn: and, if, for example, Drake Fighter (L1) levels up, it will become a Drake Warrior (L2) 20090731 23:13:15< ilor> i.e. /query bar (by foo) 20090731 23:13:16< esr> I'll probably get this done in the next two hours. 20090731 23:13:37< Crab_> corn: so, if unit type changes, level is just a consequence. 20090731 23:14:04< Crab_> corn: of course, you can put the level value there (after all, it's a small number and can aid in making some queries run faster) 20090731 23:14:05< Soliton> ilor: please don't change the usual protocol. i'm using it from the command line and several scripts depend on it. 20090731 23:14:07< corn> I wasn't aware that that was *always* the case 20090731 23:14:25< Soliton> ilor: as i said please do it as in the adminmsg command. 20090731 23:14:27< Crab_> corn: we can always ask zookeeper, just to be sure :) 20090731 23:14:54< Crab_> zookeeper: is the unit level fully determined by its unit type ? 20090731 23:15:12< Soliton> ilor: infact let me do it since i've just changed that version a bit. 20090731 23:15:19< ilor> Soliton: okay 20090731 23:15:37< ilor> Soliton: BTW, how do you 'usually' reboot the server? 20090731 23:15:44-!- Blueblaze [n=nick@c-98-199-143-139.hsd1.tx.comcast.net] has joined #wesnoth-dev 20090731 23:16:26< AI0867> esr: 13:16 < AI0867> esr: your fixme states that upon removal of [stoned], min_savgame should be bumped, but I really doubt that's needed. (min_savegame is still at 1.3.10) 20090731 23:16:47< Soliton> ilor: send_server_command restart 20090731 23:16:53< AI0867> I've since removed the workaround, without bumping min_savegame 20090731 23:17:13< esr> AI0867: OK. You lnow that part of the code better than I do. 20090731 23:17:39< ilor> Soliton: okay. I added an "allow_remote_shutdown" config param because otherwise I couldn;t cleanly shutdown the server on windows :) 20090731 23:17:40< corn> Crab_: I will omit the type column, however level is still useful because it is a unit-type independent way of filtering units based on their strength 20090731 23:17:49< Crab_> corn: ok 20090731 23:18:27< Soliton> ilor: killing with a signal is fine, too. 20090731 23:18:27-!- Kenpachi__ [n=chatzill@CPE-58-170-90-28.sa.bigpond.net.au] has joined #wesnoth-dev 20090731 23:18:46< Soliton> ilor: if i want to really shut it down i kill the run_server script usually. 20090731 23:18:59< deekay> corn: How will this "logging" work with regard to different eras than default one? And with custom units, where between 2 custom eras we can have 2 units with same ID but completely different stats? 20090731 23:19:12< ilor> Soliton: when I tried taskkill on windows it ended up killing teh server rather abruptly, so it didn't write data 20090731 23:19:27< Soliton> write what data? 20090731 23:19:38< Soliton> ilor: also can you join #wesnoth-mp? 20090731 23:21:37< corn> deekay: not sure yet. The unit data will be read from the config file about that unit type and hopefully uniquely identified based on scenario+campaign 20090731 23:21:54< esr> boucman: Still There? I'm looking at the Wolf Rider, and wondering if this is my problem after all. I see no [terrain] tag in there? 20090731 23:22:21< deekay> corn: In MP games info about era may be useful 20090731 23:22:50< boucman> esr: line 17 20090731 23:23:02< boucman> you've renamed that one to terrain_type too 20090731 23:23:03< deekay> corn: But also you may want to limit this database to store only info about "default" eras (eras shipped with wesnoth) 20090731 23:23:17-!- Sapient [n=patrickp@wesnoth/developer/sapient] has joined #wesnoth-dev 20090731 23:23:25< esr> Oh, the attribute as well? OK, I can fix that. 20090731 23:23:32< corn> deekay: right now there are no plans to add logging to MP games with players, and I still haven't switched on logging for MP games at all 20090731 23:23:43< deekay> corn: Ok 20090731 23:23:44< corn> only AI vs AI games will be supported 20090731 23:26:12-!- Kenpachi [n=chatzill@121.215.190.168] has quit [Read error: 110 (Connection timed out)] 20090731 23:26:12< zookeeper> Crab_, at least i've never seen an exception to that rule 20090731 23:26:38< Crab_> zookeeper: thanks 20090731 23:27:41< zookeeper> Crab_, i'm not 100% sure if you could manually change an existing unit's level to something else, but i doubt that. 20090731 23:29:07< corn> zookeeper: thanks 20090731 23:30:50-!- Noyga [n=lame-z@wesnoth/developer/noyga] has left #wesnoth-dev ["Quitte"] 20090731 23:31:02< boucman> esr: well, i don't really mind, but that's what your commit did 20090731 23:31:04< corn> ok, table created 20090731 23:31:16< boucman> if you consider it a mistake, we can also revert the C++ side of things 20090731 23:31:24< esr> boucman: I'll fix things up. 20090731 23:31:30< boucman> ok 20090731 23:32:11< corn> Crab_: how should I store this inside of the wesnoth client? create a new struct with turn,killed_id,killer_id,position and store a vector of this struct? 20090731 23:33:44< corn> this is before I encode it into WML for transmission in the logs 20090731 23:33:52< Crab_> corn: sounds good. note that you'll store strings for ids there, not DB id's. 20090731 23:33:54< Soliton> deekay, corn: unit ids should be pretty unique or people will notice that eras modify each others content and hopefully complain to the add-on author(s). but making sure they really can't hurt of course. 20090731 23:34:01< corn> Crab_: yes 20090731 23:34:26-!- Kenpachi [n=chatzill@CPE-58-170-85-76.sa.bigpond.net.au] has joined #wesnoth-dev 20090731 23:34:43< Crab_> corn: you will also need to design/ reuse some kind of 'grab a list of unit types and corresponding pictures from wesnoth' script 20090731 23:34:55-!- Kenpachi_ [n=chatzill@CPE-58-170-90-28.sa.bigpond.net.au] has quit [Read error: 110 (Connection timed out)] 20090731 23:34:59< corn> Crab_: yep 20090731 23:35:05< Crab_> taking into account the fact that pictures tend to update from time to time :) 20090731 23:37:53< Crab_> boucman: a philosophical question: imagine that AI is instructed to avoid a location near a specific unit. What if that unit is invisible to the AI? Should AI avoid that location ? 20090731 23:38:12< boucman> hehe 20090731 23:38:18< boucman> yes, definitely 20090731 23:38:42< Crab_> ok ) this simplifies things, btw :) 20090731 23:38:44< corn> Crab_: it depends if you want your AI to replicate human behavior 20090731 23:38:55< corn> I would say no, it should _not_ try to avoid that location 20090731 23:39:05< boucman> the point the secnario designer is trying to make is that we should avoid that unit... the fact that it's invisible is irreleant 20090731 23:39:26< Sapient> Crab_: yes, it should... there is a mechanism in SUF to add visibility checks 20090731 23:39:54< corn> maybe I am misunderstanding 20090731 23:40:12< Sapient> so if they don't want the avoidance to apply given invisible units, that should be possible by filtering visibility 20090731 23:40:46< Crab_> Sapient: yes, I'm using SLF there. thanks. 20090731 23:40:49< boucman> corn: avoiding a location (here) is not about having a better AI, it's about instructing an AI to follow a scenario designer's special instructions 20090731 23:41:09< boucman> so it's ok to take into account "unavailable info" 20090731 23:41:12< Sapient> e.g. [filter_vision] [/filter_vision] 20090731 23:41:16< corn> ah 20090731 23:41:56< boucman> corn: basically from the AI PoV there is instructions to avoid a given set of locations, but the AI can't know there is a unit here... 20090731 23:42:45< corn> ok, I understand 20090731 23:43:31-!- lizard_r [n=Miranda@wesnoth/umc-dev/developer/lizard] has quit ["Saurian Augur - I'll heal you by 4 hp if you leave next to me"] 20090731 23:44:11-!- kitty__ [n=kitty@e180197245.adsl.alicedsl.de] has quit [] 20090731 23:44:28< CIA-62> noyga * r37361 /branches/1.6/po/wesnoth-trow/fr.po: French translation update 20090731 23:50:04< CIA-62> cornmander * r37362 /trunk/src/upload_log.cpp: Encoded map data so it is easier for server-side parser to read 20090731 23:50:31-!- ABCD_ is now known as ABCD 20090731 23:51:06< Crab_> how can I create a SLF that matches no locations ? 20090731 23:51:52< zookeeper> [not][/not] 20090731 23:51:59< Crab_> thanks 20090731 23:53:02-!- Kenpachi__ [n=chatzill@CPE-58-170-90-28.sa.bigpond.net.au] has quit [Read error: 110 (Connection timed out)] 20090731 23:54:25< esr> zookeeper: Since you''re here, somethging for you to look at after my next commit. The WML for the Drake Glider is poorly matched to the set of sprite frames now available. I''m doing a nminimal cleanup so wmllint won't complain about unreferenced images, but someone ho knows AnimationWML better needs to integrate the new ones better. 20090731 23:56:10< CIA-62> esr * r37363 /trunk/data/core/ (6 files in 3 dirs): wmllint cleanup. The Drake Gider WML needs a tuneup for the new sprites. 20090731 23:59:04-!- happygrue [n=George@wesnoth/developer/wintermute] has joined #wesnoth-dev 20090731 23:59:34< CIA-62> noyga * r37364 /trunk/po/wesnoth-trow/fr.po: French translation update --- Log closed Sat Aug 01 00:00:09 2009