--- Log opened Sat Jun 19 00:00:39 2010
--- Day changed Sat Jun 19 2010
20100619 00:00:39-!- kevg [~kevg@94.232.5.102] has left #wesnoth-dev []
20100619 00:04:27-!- Blueblaze [~nick@adsl-99-186-64-86.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 260 seconds]
20100619 00:07:06< boucman> night all
20100619 00:07:14-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100619 00:07:43-!- ancestral [~ancestral@12.145.225.25] has quit [Ping timeout: 260 seconds]
20100619 00:13:35-!- Bocom [~Bocom@c-b7cfe255.013-31-6b736412.cust.bredbandsbolaget.se] has joined #wesnoth-dev
20100619 00:15:22-!- Johannes13_ [~Johannes@unaffiliated/johannes13] has quit [Ping timeout: 264 seconds]
20100619 00:17:10-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Remote host closed the connection]
20100619 00:40:30< CIA-86> eleazar * r43577 /trunk/data/core/terrain-graphics.cfg: revised layering and transition exceptions for better appearance.
20100619 00:41:10-!- gabba [~gabba@wesnoth/developer/gabba] has left #wesnoth-dev []
20100619 00:50:19-!- ancestral [~ancestral@12.145.225.25] has joined #wesnoth-dev
20100619 00:51:23< zookeeper> so does anyone know what has happened to the loading times in trunk? starting the game with .cfg changes takes horribly long.
20100619 00:54:34-!- ancestral [~ancestral@12.145.225.25] has quit [Client Quit]
20100619 01:03:27< zookeeper> that is, about two minutes on my machine. certainly a heck of a lot longer than 1.8.
20100619 01:09:22-!- Upth [~ogmar@adsl-75-26-206-73.dsl.scrm01.sbcglobal.net] has quit [Quit: Never cook alone / I have no use for you now / To Beat All The Rest]
20100619 01:09:30< CIA-86> zookeeper * r43578 /trunk/data/campaigns/The_Rise_Of_Wesnoth/maps/Elf_Lords.map: Fixed the major silliness of the elf lords not having an elvish castle.
20100619 01:09:47-!- Upthorn [ogmar@adsl-75-26-206-73.dsl.scrm01.sbcglobal.net] has quit [Ping timeout: 265 seconds]
20100619 01:10:08< CIA-86> zookeeper * r43579 /branches/1.8/data/campaigns/The_Rise_Of_Wesnoth/maps/Elf_Lords.map: Ported r43578 to 1.8.
20100619 01:10:59-!- zookeeper [~l@wesnoth/developer/zookeeper] has quit []
20100619 01:17:56-!- happygrue [~George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20100619 01:42:58-!- norbert_ [~norbert@82-171-70-54.ip.telfort.nl] has joined #wesnoth-dev
20100619 02:12:41-!- mpiechotka [~mpiechotk@dyn1083-84.hor.ic.ac.uk] has left #wesnoth-dev []
20100619 02:13:34-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Read error: Operation timed out]
20100619 02:13:44< CIA-86> espreon * r43580 /trunk/data/core/images/halo/undead/ (21 files): Ran umcpropfix.
20100619 02:16:26< CIA-86> espreon * r43581 /trunk/data/core/images/halo/undead/ (22 files): 
20100619 02:16:26< CIA-86> Ran wesnoth-optipng:
20100619 02:16:26< CIA-86> Overall statistics (only for files with a smaller recompressed size):
20100619 02:16:26< CIA-86> Original size: 76 KiB on 22 files
20100619 02:16:26< CIA-86> Optimized size: 23 KiB
20100619 02:22:11-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100619 02:27:32< CIA-86> espreon * r43582 /trunk/data/core/terrain-graphics/ (internal-complex-tracks.cfg internal-tracks.cfg): Ran umcpropfix.
20100619 02:40:13-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz]
20100619 02:40:27-!- PK [~pk@r74-192-30-57.bcstcmta01.clsttx.tl.dh.suddenlink.net] has quit [Quit: Java user signed off]
20100619 02:41:00-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20100619 02:43:50-!- Appleman1234 [~Appleman1@CPE-60-226-180-71.qld.bigpond.net.au] has joined #wesnoth-dev
20100619 02:44:44< CIA-86> gabba * r43583 /trunk/ (8 files in 3 dirs): Whiteboard: Action execution with the 'y' key.
20100619 02:47:46-!- isaac [~isaac@debian/developer/isaac] has quit [Ping timeout: 264 seconds]
20100619 02:48:28-!- isaac [~isaac@debian/developer/isaac] has joined #wesnoth-dev
20100619 02:51:55-!- Blueblaze [~nick@adsl-99-186-64-86.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100619 04:07:36-!- norbert_ [~norbert@82-171-70-54.ip.telfort.nl] has quit [Quit: Leaving]
20100619 04:21:20< CIA-86> ai0867 * r43584 /trunk/src/builder.cpp: Add support for image path functions in terrain graphics
20100619 04:53:08< CIA-86> ai0867 * r43585 /trunk/src/builder.cpp: Revert all changes to rebuild_terrain(), the images used in there aren't actual terrain tiles. (this fixes the drawing-preview)
20100619 04:55:38-!- Ivanovic_ [~ivanovic@dtmd-4db2349f.pool.mediaWays.net] has joined #wesnoth-dev
20100619 04:59:10-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 258 seconds]
20100619 04:59:35-!- Ivanovic_ is now known as Ivanovic
20100619 05:10:38-!- ancestral_ [~ancestral@mobile-166-137-142-094.mycingular.net] has joined #wesnoth-dev
20100619 05:14:03< CIA-86> ai0867 * r43586 /trunk/data/core/terrain-graphics/builder.cfg: Reapply r43557, as there aren't any problems this time
20100619 05:28:49< AI0867> mordante: http://www.wesnoth.org/forum/viewtopic.php?p=436163#p436163
20100619 05:29:44-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Read error: Connection reset by peer]
20100619 05:37:20-!- PeterPorty [~Pete@pc-193-248-120-200.cm.vtr.net] has joined #wesnoth-dev
20100619 05:37:28< PeterPorty> shadowmaster, 
20100619 05:37:56< PeterPorty> can't you act like a grown up?
20100619 05:38:39< shadowmaster> I'm not the one who is annoying to people just fo rfun.
20100619 05:38:43< shadowmaster> *for fun
20100619 05:38:49< Espreon> Indeed.
20100619 05:38:53-!- mode/#wesnoth-dev [+o shadowmaster] by ChanServ
20100619 05:39:03< PeterPorty> you kiddin
20100619 05:39:09-!- mode/#wesnoth-dev [+b-o *!*@*.vtr.net$#wesnoth-unavailable shadowmaster] by shadowmaster
20100619 05:39:28< shadowmaster> if you want to demonstrate how grown up you are then avoid me.
20100619 05:39:50< shadowmaster> instead of evading bans *and* my ignore mask
20100619 05:56:07-!- PeterPorty [~Pete@pc-193-248-120-200.cm.vtr.net] has left #wesnoth-dev []
20100619 05:57:01-!- meric [~Eric@124-170-175-143.dyn.iinet.net.au] has joined #wesnoth-dev
20100619 05:58:09-!- mode/#wesnoth-dev [+o shadowmaster] by ChanServ
20100619 05:58:16-!- mode/#wesnoth-dev [-bo *!*@*.vtr.net$#wesnoth-unavailable shadowmaster] by shadowmaster
20100619 05:59:18-!- chains [~Rylar@adsl-75-37-46-32.dsl.pltn13.sbcglobal.net] has joined #wesnoth-dev
20100619 06:22:04-!- chains [~Rylar@adsl-75-37-46-32.dsl.pltn13.sbcglobal.net] has quit [Quit: Leaving]
20100619 06:25:01-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has quit [Quit: Hi! I'm a quit message virus vaccine. If you see a quit message virus, don't replace your quit message with it!]
20100619 06:38:32-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100619 06:39:13-!- meric [~Eric@124-170-175-143.dyn.iinet.net.au] has left #wesnoth-dev []
20100619 06:39:44-!- ancestral_ [~ancestral@mobile-166-137-142-094.mycingular.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi]
20100619 06:40:53-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has joined #wesnoth-dev
20100619 06:50:08-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: crimson_penguin]
20100619 07:16:13-!- Blarumyrram [~Blarumyrr@84-50-143-71-dsl.rkv.estpak.ee] has quit [Ping timeout: 264 seconds]
20100619 07:21:56-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Disconnected by services]
20100619 07:22:15-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100619 07:41:38< esr> Espreon: Is your feature request  #16019 fulfilled?  I had it marked Ready For Test.
20100619 07:42:11< CIA-86> alink * r43587 /trunk/src/font.hpp: Fix broken fade-out of floating damage.
20100619 07:44:00< Espreon> esr: Lemme test...
20100619 07:46:07< Espreon> esr: Success.
20100619 07:46:55< Espreon> So, what about my other FR?
20100619 07:47:45< esr> Which, the colour -> color thing?
20100619 07:48:05< Espreon> Uh, actually, this: https://gna.org/bugs/index.php?14852
20100619 07:48:29< esr> Looking...
20100619 07:48:42< esr> Oh, that.
20100619 07:49:15< esr> I'd really rather not complicate the code for an edge case that weird.  Why do you need it?
20100619 07:49:16 * Espreon wishes that the "#po" comment feature would be ported to the Perl version of wmlxgettext.
20100619 07:49:32< Espreon> Uh................
20100619 07:50:03< Espreon> ... because I have several files that are completely commented, for I don't use the contents yet.
20100619 07:52:22< ancestral> Perl!
20100619 07:52:35 * Espreon chuckles
20100619 07:53:16< esr> Change the file extension.
20100619 07:53:47< esr> WAit, that might not work.
20100619 07:54:20-!- mjs-de [~mjs-de@vpw.wh.uni-dortmund.de] has quit [Remote host closed the connection]
20100619 07:54:29-!- mjs-de [~mjs-de@vpw.wh.uni-dortmund.de] has joined #wesnoth-dev
20100619 07:56:56< Espreon> esr: You don't have to implement that FR if you don't want to do so.
20100619 07:57:02< shadowmaster>  /47
20100619 07:57:05< Espreon> It's not a big deal.
20100619 07:57:27< esr> I'd really prefer not to.  I looked at what it would take and it was kinda ugly.
20100619 07:57:58< Espreon> That's fine.
20100619 07:58:16-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit []
20100619 08:00:07< esr> As for colour -> color, you know wmllint's spellchecker will catch that, right?
20100619 08:00:37< shadowmaster> wmllint's?
20100619 08:00:44< shadowmaster> isn't it an external module?
20100619 08:01:07< esr> Yes, wmllint does a spell check on all strings using pyenchant.
20100619 08:01:12< Espreon> esr: Uh, this is about converting deprecated keys.
20100619 08:01:47< esr> Oh, a colour *key*. OK, I'll conver that.
20100619 08:02:09< Espreon> Also, all tags with "colour" in their names now have "color" in them.
20100619 08:02:20< Espreon> ... instead... yeahz...
20100619 08:07:45< esr> What's the set of tags and keys in question?
20100619 08:15:10< Espreon> Keys: "colour"
20100619 08:15:37< Espreon> Tags: [colour_adjust]
20100619 08:15:41< Espreon> esr: ^
20100619 08:18:47< esr> Noted.
20100619 08:23:25-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100619 08:27:18< CIA-86> esr * r43588 /trunk/data/tools/wmllint: Enforce "color" rather than "colour" in the WML.
20100619 08:31:41< esr> Espreon: Are the American spelling supported in the C++ engine already?
20100619 08:36:26< Espreon> Yes.
20100619 08:39:10< esr> Good, because I just converted mainline.  Will commit.
20100619 08:50:40< CIA-86> esr * r43589 /trunk/data/ (39 files in 16 dirs): 
20100619 08:50:41< CIA-86> [colour_adjust] -> [color_adjust]
20100619 08:50:41< CIA-86> colour= -> color
20100619 08:58:37< esr> Espreon: You should grep -R  the source tree for "colour".  There are a few remnant uses that may or may not be targets for conversion.
20100619 09:00:55< Espreon> esr: Uh, those may be hard to find, for "colour" is still supported.
20100619 09:01:51< esr> That's why I'm saying you should grep -R.  I see about 40 hits.
20100619 09:02:03< esr> But now I'm going to sleep.
20100619 09:02:19< Espreon> esr: Ask alink about this when he returns.
20100619 09:02:45< esr> OK. But I'll be gone all next week.  Off playing with swords.
20100619 09:03:39< Espreon> Cool.
20100619 09:13:38-!- dtiger [~dtiger@dynamic-vpdn-91-149-190-99.telecom.by] has joined #wesnoth-dev
20100619 09:34:52-!- Ivanovic [~ivanovic@dtmd-4db2349f.pool.mediaWays.net] has quit [Changing host]
20100619 09:34:52-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100619 09:36:24< Ivanovic> moin
20100619 09:42:40-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100619 09:53:21-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit []
20100619 10:22:55-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: ...]
20100619 10:26:39-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100619 10:37:32-!- Upth [~ogmar@69.62.144.108] has joined #wesnoth-dev
20100619 10:37:32-!- Upth is now known as Upthorn
20100619 10:53:44-!- Blueblaze [~nick@adsl-99-186-64-86.dsl.hstntx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20100619 10:54:02-!- Blueblaze [~nick@adsl-99-186-64-86.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100619 11:19:32-!- Blueblaze [~nick@adsl-99-186-64-86.dsl.hstntx.sbcglobal.net] has quit [Remote host closed the connection]
20100619 11:19:49< CIA-86> gabba * r43590 /trunk/src/hotkeys.cpp: Removed useless todo
20100619 11:19:57< CIA-86> gabba * r43591 /trunk/ (10 files in 3 dirs): Whiteboard: delete latest defined action with 'h' key. (Choice of hotkeys is temporary.) Also, renamed a method.
20100619 11:26:30-!- esr [~chatzilla@wesnoth/developer/esr] has quit [Ping timeout: 265 seconds]
20100619 11:35:15-!- wesbot changed the topic of #wesnoth-dev to: 128 bugs, 283 feature requests, 14 patches | logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100619 11:37:25-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100619 11:38:16-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100619 11:41:07-!- esr [~chatzilla@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-dev
20100619 11:56:58-!- ancestral [~ancestral@97-116-115-34.mpls.qwest.net] has quit [Quit: And that’s the end of THAT chapter.]
20100619 12:03:11-!- meric [~Eric@124-170-166-78.dyn.iinet.net.au] has joined #wesnoth-dev
20100619 12:09:41-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100619 12:24:28-!- Blarumyrran [~Blarumyrr@84-50-143-71-dsl.rkv.estpak.ee] has joined #wesnoth-dev
20100619 12:46:13-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100619 13:02:39-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100619 13:02:44< kevg> hello
20100619 13:31:12-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100619 13:35:26< AI0867> boucman: it seems that minimap_image_overlay_ is *always* initialized with "void" and never changed
20100619 13:35:33< AI0867> do you see a use for it?
20100619 13:35:43< boucman> I have no idea what this is
20100619 13:36:15< AI0867> a companion to minimap_image_, which is the editor tile/drawing preview/minimap image for the terrain
20100619 13:37:40< boucman> AI0867: hmm, waybe there was a plan to do something of it at some point, but I have no idea what it was
20100619 13:37:52< boucman> any way for WML to add something on the minimap ?
20100619 13:38:08< AI0867> not that I can see
20100619 13:40:57< AI0867> oh
20100619 13:41:15< AI0867> it can be initialized when two terrain_typeS are merged into one 
20100619 13:41:31< AI0867> mistook that for a copy constructor at first
20100619 13:45:14-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has quit [Read error: Connection reset by peer]
20100619 13:47:41-!- Gambit [~quassel@pa-67-234-73-7.dhcp.embarqhsd.net] has joined #wesnoth-dev
20100619 13:52:42-!- kevg [~kevg@94.232.5.102] has left #wesnoth-dev []
20100619 14:04:57-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100619 14:33:51-!- Appleman1234 [~Appleman1@CPE-60-226-180-71.qld.bigpond.net.au] has quit [Ping timeout: 260 seconds]
20100619 14:46:17-!- Appleman1234 [~Appleman1@CPE-60-226-180-71.qld.bigpond.net.au] has joined #wesnoth-dev
20100619 14:55:15< AI0867> 20100619 14:49:56 error general: Duplicate terrain code definition found for ^Vhha
20100619 14:55:19< AI0867> 20100619 14:49:56 error general: Trying to add terrain snow-mountain_village (Village) [village, frozen, rough]
20100619 14:55:22< AI0867> 20100619 14:49:56 error general: which conflicts with  snow-hill_village (Village) [village, frozen, rough]
20100619 14:57:50< AI0867> zookeeper: You removed the prefix of both Ms^Vhha and Ha^Vhha, leading to a conflict that was unnoticed until now
20100619 14:58:44< zookeeper> hmh
20100619 14:59:59< AI0867> they share the same terrain graphics, so that's not really a problem
20100619 15:00:06< AI0867> but they conflict in aliases and default base
20100619 15:00:10< zookeeper> i'll take a look
20100619 15:00:39< AI0867> I guess the alias should be of bas_ instead, and remove the hills/mountains from the editor icon
20100619 15:00:49< zookeeper> well, that's interesting, i have made the change locally but haven't committed it
20100619 15:01:02< AI0867> not sure what to do with the default base though
20100619 15:05:02< CIA-86> ai0867 * r43592 /trunk/src/ (terrain.cpp terrain.hpp): If two different definitions for the same [terrain_type] don't match, fail to merge them and complain loudly
20100619 15:11:42< zookeeper> AI0867, it looks like Ms^Vh* isn't used anywhere in mainline, so i'll just change the code from ^Vhha to ^Vhms
20100619 15:12:08< AI0867> k
20100619 15:13:48< CIA-86> zookeeper * r43593 /trunk/data/core/terrain.cfg: Changed the terrain code of snow mountain village from ^Vhha to ^Vhms because the former is also used by the snow hill village. Also made orcish snow village alias to village,snowhills instead of just village,hills.
20100619 15:14:44-!- Appleman1234 [~Appleman1@CPE-60-226-180-71.qld.bigpond.net.au] has quit [Read error: Operation timed out]
20100619 15:21:00-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100619 15:28:12-!- Appleman1234 [~Appleman1@CPE-60-226-180-71.qld.bigpond.net.au] has joined #wesnoth-dev
20100619 15:28:32-!- Elvish_Pillager [~eli@71-10-224-192.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20100619 15:29:21< CIA-86> ai0867 * r43594 /trunk/src/terrain.cpp: Replace lg::wml_error with ERR_G, as lg::wml_error doesn't work in the editor
20100619 15:29:37-!- ABCD [~abcd@gentoo/developer/abcd] has quit [Ping timeout: 265 seconds]
20100619 15:34:50-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100619 15:38:31-!- Appleman1234 [~Appleman1@CPE-60-226-180-71.qld.bigpond.net.au] has quit [Ping timeout: 252 seconds]
20100619 16:24:26-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 240 seconds]
20100619 16:38:53-!- CIA-86 [cia@208.69.182.149] has quit [Ping timeout: 276 seconds]
20100619 16:39:01-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Remote host closed the connection]
20100619 16:39:53-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100619 16:54:49-!- Blarumyrran [~Blarumyrr@84-50-143-71-dsl.rkv.estpak.ee] has quit [Changing host]
20100619 16:54:49-!- Blarumyrran [~Blarumyrr@unaffiliated/blarumyrran] has joined #wesnoth-dev
20100619 16:58:39-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100619 16:59:49< kevg> Crab_: hello. I've submitted patch. Have you seen it?
20100619 17:02:14< fendrin> Ivanovic: Do you remember the latest bug report to LoW you pointed me to?
20100619 17:02:25< Ivanovic> no
20100619 17:03:02< fendrin> Ivanovic: Okay, it involves removing an overlay from a unit. I have noticed that it is ugly to fix. 
20100619 17:03:06< Crab_> hi, kevg
20100619 17:03:13< Crab_> yes, I've looked through it
20100619 17:03:51< fendrin> Ivanovic: The [remove_unit_overlay] tag does only support simple unit filters, filtering for coordinates only. 
20100619 17:04:44< Ivanovic> hmmm
20100619 17:05:09< fendrin> Ivanovic: I think it is time to let full unit filters be implemented in every place where it makes sense.
20100619 17:05:37< Ivanovic> sounds reasonable to me
20100619 17:06:13< fendrin> Ivanovic: It's also a source of not working wml code since many coders just don't remember which tag supports which filtering options.
20100619 17:06:36< fendrin> And the engine doesn't warn about the not working filtering in any way.
20100619 17:06:47< Ivanovic> short term solution: improve documentation about filtering
20100619 17:06:56< kevg> Crab_: and what can you tell about it. Its terrible? :-P
20100619 17:07:15< Ivanovic> long term solution: add some engine warnings like "this filtering won't work" as well as switch things to the same filter format wherever possible
20100619 17:08:02< AI0867> Upthorn: http://cboard.cprogramming.com/cplusplus-programming/122425-why-not-static-const-double-d-%3D-1-5%3B-inside-class.html#post913589
20100619 17:08:11< AI0867> took me a while to find an explanation
20100619 17:08:15< fendrin> Ivanovic: Okay, I will see over the action wml tags and introduce better filtering whereever possible.
20100619 17:08:30< Ivanovic> great!
20100619 17:08:39< fendrin> Ivanovic: The warnings shouldn't be hard to code as well.
20100619 17:09:17-!- CIA-86 [cia@208.69.182.149] has joined #wesnoth-dev
20100619 17:09:52< Crab_> kevg: well , there's a number of small glitches and potential improvements  in there :)
20100619 17:10:53< Crab_> kevg: if you have time atm, we can talk about it
20100619 17:11:06< kevg> Crab_: i have time.
20100619 17:12:52< Crab_> ok, let's start from src/ai/default/attack.cpp change
20100619 17:14:04< Crab_> you want to determine if a unit is a healer. two simple issues in there (leaving the non-simple issues for now) : 1) after you found out that one of the units involved in the attack is a healer, you can break out of the loop, no reason to check further
20100619 17:14:46< kevg> Crab_: yes. Its my silly mistake.
20100619 17:14:48< Crab_> 2) see data/core/macros/abilities.cfg , you'll find out that the only valid ability type that you need to check is 'heals'
20100619 17:15:15< Crab_> so, u->has_ability_type("cure") or  u.has_ability_type("cures") won't give you anything important
20100619 17:16:48-!- Crab_ [~Crab_@wesnoth/developer/crab] has left #wesnoth-dev []
20100619 17:16:54-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100619 17:17:05< kevg> Crab_: yes. A didn't know about this file at all.
20100619 17:17:15< Crab_> you see, the abilities are defined in WML
20100619 17:17:34< Crab_> e.g. the value= in there gives the value of healing
20100619 17:17:48< Crab_> ok, continuing..  src/ai/registry.cpp seems ok
20100619 17:18:00< kevg> and ability name is in square brackets?
20100619 17:18:57< Crab_> kevg: the ability name is a wml tag. see unit::has_ability_type in src/unit_abilities.cpp
20100619 17:19:45< Crab_> when you do has_ability_type("heals"), the engine does a list.child_range("heals")  call to get a list of all [heals] blocks which this unit has.
20100619 17:21:23< Crab_> next, let's take a look at your change to get_healing phase
20100619 17:21:50< Crab_> you've wanted units to consider locations near 'moved healers' as 'potential villages', right ?
20100619 17:22:11< kevg> yes
20100619 17:22:51< kevg> find all positions near all moved healers and put them into vector
20100619 17:23:36< Crab_> it's better to do 'find all positions near all FRIENDLY healers with 0_MOVEMENT_LEFT and put them in a SET'
20100619 17:23:43< Crab_> especially the first part ;)
20100619 17:24:09< kevg> hmm
20100619 17:24:26< Crab_> it's not good to go near enemy healers, hence the need to check for them being FRIENDLY :)
20100619 17:24:54< Crab_> then, the AI can do partial moves, so it's better to find healers which have 0 movement points left.
20100619 17:25:15< kevg> why the set is better than vector?
20100619 17:25:16-!- Blarumyrran [~Blarumyrr@unaffiliated/blarumyrran] has quit [Quit: Lahkun]
20100619 17:25:38< Crab_> 'no duplicates'
20100619 17:25:50< Crab_>  it's better to put locations in a set, to avoid duplicates in the locations we need to change, since the power_projection check is much more expensive than the removal of duplicates.
20100619 17:26:00-!- Blarumyrran [~Blarumyrr@unaffiliated/blarumyrran] has joined #wesnoth-dev
20100619 17:26:15< kevg> ok, got it
20100619 17:26:33< Crab_> e.g. if there are many nearby healers, with overlapping nearby locations
20100619 17:28:30< Crab_> also, as a side benefit, you'd be able to do a fast check if a location is 'near a healer'
20100619 17:28:40-!- kevg [~kevg@94.232.5.102] has quit [Remote host closed the connection]
20100619 17:29:10-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100619 17:29:45< Crab_> kevg: since std::set allows to find if the element is contained within it faster than with a foreach loop on a vector.
20100619 17:30:12< kevg> Crab_: std::set implemented as a hash?
20100619 17:32:18< kevg> Crab_: nevermind. I see its RBTree or so.
20100619 17:32:22< Crab_> kevg: a tree, I think
20100619 17:37:44< Crab_> kevg: moving next, to get_healer_phase..
20100619 17:39:19< Crab_> you want to move a unit where it can do the 'most' healing, right ?
20100619 17:39:39< kevg> yes
20100619 17:40:23< kevg> do to it we check all units hp in adjacent tiles.
20100619 17:41:41< Crab_> (afk 5 minutes)
20100619 17:47:39< Crab_> let's start with get_healer_phase::get_healing_amount part
20100619 17:48:03< Crab_> you don't need a 'side' argument, since you're only dealing with movement of units of your side (you cannot move allied/enemy units
20100619 17:48:30< Crab_> instead of 'team& healer_team = (*resources::teams)[side-1];' you can use 'const team& healer_team = current_team();'
20100619 17:49:09< boucman> Crab_: btw, there are at least 3 places that implement a current_team() like function, we might want to add it to ressources, at some point
20100619 17:50:05< Crab_> boucman: AI's definition of 'current' is not 'the team whose turn is it now'
20100619 17:50:12< boucman> oh,ok
20100619 17:51:06< Crab_> boucman: but yes, we can add information about 'the side whose turn is now' to resources::, and sync it with play_controller. of course, in the end, it's similar to just making the play_controller static :)
20100619 17:52:01< Crab_> boucman: 'const team& team_of_side(int side)' is alternative
20100619 17:53:20< Crab_> kevg: also, some units are unhealable or have regeneration, so we are unable to heal them further
20100619 17:53:49< Crab_> kevg: also, we need to determine  the value of ' bool cures ' flag differently (look at how src/actions.cpp does it)
20100619 17:54:09< kevg> Crab_: can units with regeneration be poisoned?
20100619 17:54:14< Crab_> yes
20100619 17:54:38< kevg> and they can not cure themselves?
20100619 17:56:00< Crab_>  they will.
20100619 17:56:08< Crab_> see data/core/macros/abilities.cfg
20100619 17:56:22< Crab_> [regenerate] has 'poison=cured'
20100619 17:57:56< Crab_> also note that, if we cure poison, we don't heal.
20100619 17:58:16< Crab_> so, a poisoned unit surrounded by 6 healers and standing on village will be cured of poison, but not healed.
20100619 17:58:29< boucman> I have a doubt, if i am next to a healer and on a village, do I get healed+cured ? 
20100619 17:58:30< fendrin> starting wesnoth takes very long.
20100619 17:58:34< boucman> I think no, but i'm not sure
20100619 17:58:35< Crab_> boucman: no
20100619 17:59:38< Crab_> kevg: then, back to get_healer_phase::evaluate() ...
20100619 18:00:53< Crab_> you currently have 'foreach unit, foreach of moves, search for max healing amount'
20100619 18:01:09-!- meric [~Eric@124-170-166-78.dyn.iinet.net.au] has quit [Quit: meric]
20100619 18:01:10< Crab_> with filtering for healers
20100619 18:01:33< Crab_> it's better (faster) to filter for side and movement_left>0 up-front.
20100619 18:04:05< Crab_> kevg: you can also try to work with get_possible_moves() function
20100619 18:04:29< Crab_> kevg: it gives you (roughtly) a std::map < location_of_unit, possible_movements_of_that_one_unit >
20100619 18:05:37< Crab_> kevg: so,  you'd be able to do a foreach on that map, filtering by non-healers, and inner foreach on possible moves. that way, checks for 'can move' and 'is own unit' will be unnecessary.
20100619 18:14:02< Crab_> kevg: also, in data/core/macros/ai_candidate_actions.cfg - it's better to write 80010 or (80000+10)
20100619 18:14:33< Crab_> otherwise, 2*{AI_CA_HEALER_SCORE} might result in surprising value.
20100619 18:16:01< Crab_> also, to test your code, it might need some modifications. to make them easier, instead of modifying get_healing_phase, add a new phase by copypasting get_healing_phase, and naming it differently
20100619 18:16:20< Crab_> that way, we can test 2 ais, one with old phase, one with new phase, to see the improvement
20100619 18:16:40< Crab_> kevg: that looks like all.
20100619 18:16:44< kevg> ok
20100619 18:19:39< boucman> that's more than enough for a patch round :P
20100619 18:20:11< Crab_> boucman: that's two patches in 1 in there :)
20100619 18:20:16< boucman> hehe*
20100619 18:20:47< Crab_> boucman: i.e., the 'make units consider locations near moved healers as villages' is a separate good thing
20100619 18:31:03-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100619 18:35:44< CIA-86> boucman * r43597 /trunk/data/core/ (11 files in 2 dirs): one more railway specific macro folded
20100619 18:50:28-!- Blueblaze [~nick@adsl-99-186-64-86.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100619 19:10:16-!- norbert_ [~norbert@82-171-70-54.ip.telfort.nl] has joined #wesnoth-dev
20100619 19:16:11-!- Blarumyrran [~Blarumyrr@unaffiliated/blarumyrran] has quit [Read error: Connection reset by peer]
20100619 19:18:39-!- Upth [~ogmar@69.62.144.108] has joined #wesnoth-dev
20100619 19:21:55< fendrin> boucman: Are you making bridges with railways on them?
20100619 19:22:08-!- Upthorn [~ogmar@69.62.144.108] has quit [Ping timeout: 260 seconds]
20100619 19:22:21< zookeeper> what i fail to understand is why everyone keeps calling them "railways".
20100619 19:22:37< zookeeper> railways are what you drive trains on, aren't they?
20100619 19:24:49< fendrin> zookeeper: How would you call them?
20100619 19:25:36< zookeeper> well...mine cart tracks?
20100619 19:25:48< zookeeper> i don't know what the proper english term would be
20100619 19:27:56< zookeeper> obviously there's no trains in wesnoth, just some simple carts to push/pull
20100619 19:31:50-!- ABCD [~abcd@gentoo/developer/abcd] has joined #wesnoth-dev
20100619 19:35:02-!- Blarumyrran [~Blarumyrr@unaffiliated/blarumyrran] has joined #wesnoth-dev
20100619 19:39:58-!- Upth [~ogmar@69.62.144.108] has quit [Ping timeout: 264 seconds]
20100619 19:40:28< norbert_> the resource by Alarantalara is called "Mine Rails"
20100619 19:41:17< norbert_> "metal tracks" is used on http://en.wikipedia.org/wiki/Minecart
20100619 19:44:32< norbert_> http://www.minecraftwiki.net/wiki/Mine_Cart_Tracks
20100619 19:44:51< norbert_> I think your "mine cart tracks" is spot on
20100619 19:47:22< norbert_> Wikipedia has a whole bunch or articles ending with Mine Railroad
20100619 19:47:34< norbert_> like the Hibernia Mine Railroad, Ogden Mine Railroad, Cumberland Mine Railroad, and so on
20100619 19:48:35< fendrin> I wonder how one could code a unit that prefers that terrain type.
20100619 19:51:48-!- noy_ [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100619 19:54:38< norbert_> probably add terrain type code and add a unit_type with [defense] minerailroad=70
20100619 19:57:47< fendrin> ?
20100619 19:58:52-!- ABCD [~abcd@gentoo/developer/abcd] has quit [Remote host closed the connection]
20100619 20:00:02-!- ABCD [~abcd@gentoo/developer/abcd] has joined #wesnoth-dev
20100619 20:00:30< boucman> fendrin: no, but rail macros are 90% like bridges, and i'm making them use bridge macros, and generalize the bridge macros to be used with anything that is track-like
20100619 20:03:20< zookeeper> norbert_, no, won't work. there's no way to do that atm.
20100619 20:03:57< norbert_> can't you add a [terrain] {TERRAIN_BASE whatever
20100619 20:04:04< norbert_> and then create a unit_type with [defense] 70
20100619 20:04:20< norbert_> like this http://forum.wesnoth.org/viewtopic.php?f=21&t=24886
20100619 20:07:17< zookeeper> your question is broken
20100619 20:07:25< zookeeper> of course we could make a new base terrain type for the tracks
20100619 20:07:39< zookeeper> but that's not how it is atm
20100619 20:09:28-!- DesertPanther [~Khalid@unaffiliated/desertpanther] has joined #wesnoth-dev
20100619 20:15:02-!- Electric_Brain [~gerard@164.76.221.87.dynamic.jazztel.es] has joined #wesnoth-dev
20100619 20:21:45< Electric_Brain> Can I ask how the hitting calculation works?, I'm having a hard time thinking how its possible to implement a chance system (like how can I make a certain outcome more likely to happen based on random numbers, maybe that's because I know very little about probability), It's only curiosity, thanks! 
20100619 20:24:36< Crab_> Electric_Brain: take a random number between 0 and 99, if it's less than the attacker chance to hit (a number like 10, 20, 30,.., 90 percent), then it's a hit
20100619 20:25:18< Crab_> src/actions.cpp:1219, attack::perform_hit function
20100619 20:26:00< Electric_Brain> Crab_: but the chance of getting such number is completely random as I understand 
20100619 20:26:12-!- kevg [~kevg@94.232.5.102] has left #wesnoth-dev []
20100619 20:26:18-!- kevg [~kevg@94.232.5.102] has joined #wesnoth-dev
20100619 20:26:32< Crab_> Electric_Brain: yes, the random number is uniformly distributed
20100619 20:27:06< Crab_> so, the appearance of each value ( 0,1,2,...,99 ) has a constant probability of 0.01
20100619 20:29:06< Electric_Brain> Crab_: what diferenciates hitting a unit with a high defense than a unit with a lower defense then? the probabilities of hitting are the same (maybe I'm getting that wrong)
20100619 20:30:02< Crab_> the attacker chance to hit is based on the defense value of the terrain on which the target is standing, and on the abilities of the attacker
20100619 20:30:38< Electric_Brain> Crab_: For example if we tested a unit hitting another with 30% defense and did that millions of times, probabilistically the attacking unit should hit roughly 30% of the times right?
20100619 20:31:05< Crab_> Electric_Brain: no.
20100619 20:31:12< Crab_> 30% defense is 70% chance-to-hit
20100619 20:31:26< Electric_Brain> Crab_: yes sorry
20100619 20:31:48< Crab_> but yes, 'the attacking unit should hit roughly 70% of the times'
20100619 20:32:25< Electric_Brain> Crab_: That's the problem I don't understand how that works taking a random number and comparing it to a treshold
20100619 20:32:35< Electric_Brain> Crab_: I mean its random right?
20100619 20:32:51< Crab_> yes, the number is random each time
20100619 20:33:12< boucman> Electric_Brain: not after you take it :)
20100619 20:33:59< Crab_> Electric_Brain: compare it to betting. if you make a bet 'the next random number of 0..99 will be less than 70' you will win 70% of times.
20100619 20:35:29< Electric_Brain> Crab_: really? maybe the problem it's I don't understand random numbers then :P
20100619 20:36:46 * zookeeper doesn't understand what there's to not understand
20100619 20:36:53< boucman> Electric_Brain: before each strike, we roll a hundred sided dice, if it's less than your chance to be hit, it's a hit
20100619 20:37:57< zookeeper> it's just like flipping a coin. if it's tails then you hit, if it's heads then you miss. there's just more possible results and a threshold somewhere in the middle.
20100619 20:39:57< Crab_> Electric_Brain: or try a geometric interpretation... draw a 10sm 8 10 sm square on a piece of paper, draw a vertical line to divide the square into two parts, the left part - 7sm * 10sm, and the right part - 3sm * 10 sm. like this - http://wesnoth.pastebin.com/yEFWaSwL
20100619 20:40:38< Crab_> Electric_Brain: then, 'the next random point' will have a 70% chance to be in the left part, and 30% chance to be in the right part of the square.
20100619 20:41:20< Electric_Brain> ok I think I understand now, its more likely to be in the 70 zone because there are more numbers in that zone
20100619 20:41:24< Electric_Brain> how stupid of me
20100619 20:41:26< Electric_Brain> :(
20100619 20:41:42< Crab_> well, if you understand, that's not stupid anymore :)
20100619 20:41:58< Electric_Brain> Crab_: Yeah, thanks for helping!
20100619 20:43:18< Electric_Brain> thanks for pointing the cpp file also, I was looking for it but couldn't find it :P
20100619 20:43:33< Crab_> Electric_Brain: fgrep is your friend :)
20100619 20:44:11< Electric_Brain> true
20100619 20:46:26< Crab_> e.g., something like `fgrep -Rn -a5 -b5 random /wesnoth/src | grep hit` to find places in the source where words like 'random' and 'hit' are near each other ;)
20100619 20:50:34< Electric_Brain> Crab: Yeah I will do that next time
20100619 20:51:03< Crab_> (feel free to ask around, too)
20100619 20:56:06< Electric_Brain> Crab: I was thinking, reading the post about luck in wesnoth; it shouldn't be that hard to calculate the luck both sides had in a replay right?, just calculate how near is the result of each hit comparing it with the expected result (I don't see the uses of that though apart from statistic value)
20100619 20:57:14< Crab_> Electric_Brain: all the data about hits and misses is written to replay.
20100619 20:57:31< kevg> I'm trying to get healers healing rate. I wrote that: http://pastie.org/1011649 but it doesn't work. What i do wrong?
20100619 20:57:34< Crab_> Electric_Brain: so, for whatever definition of 'luck' you do, you can try to calculate it using that data
20100619 20:57:36< boucman> Electric_Brain: it's already done, it has been done for some time, and it doesn't solve the controversy
20100619 20:57:49< boucman> the problem is that luck is a very abstract concept...
20100619 20:58:13< boucman> in a perfectly mathematically randomless game, luck can still favor a player...
20100619 20:58:35< boucman> number of strike is not the only issue, which strike hits or miss is at least as important...
20100619 20:58:57< boucman> and there is no mathematical way to measure that aspect of luck
20100619 20:59:21< Electric_Brain> boucman: Why not? you can just do a statistic of every replay and see in how many games there is a considerable diference of luck in the winner side
20100619 20:59:59< Crab_> Electric_Brain: well, it is expected that winner will be more lucky, in most cases :)
20100619 21:00:10< Crab_> Electric_Brain: since the lucky person is more likely to win.
20100619 21:00:21< boucman> Electric_Brain: that's not what I said.
20100619 21:00:51< norbert_> Electric_Brain: I think what boucman means is that it not only matters how many hits/misses, but also _when_, like in critical situations
20100619 21:01:57< norbert_> so someone could miss more than the opponent but suddenly hit everything when attacking a leader
20100619 21:02:10-!- happygrue [~George@wesnoth/developer/wintermute] has quit [Read error: Connection reset by peer]
20100619 21:02:22-!- happygrue [~George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20100619 21:03:02< Electric_Brain> norbert_: yeah but then the problem would be the person letting the leader being attacked (with a chance of being killed despise being low) not how lucky the attacker got
20100619 21:03:13-!- dtiger [~dtiger@dynamic-vpdn-91-149-190-99.telecom.by] has quit [Remote host closed the connection]
20100619 21:04:20< norbert_> it would be both, since you don't count on all - let's say 3 - units that could possibly reach your leader to hit everything
20100619 21:04:23< Crab_> kevg: try comparing the values to integers, not to strings
20100619 21:06:20-!- dtiger [~dtiger@dynamic-vpdn-91-149-190-99.telecom.by] has joined #wesnoth-dev
20100619 21:06:30< kevg> Crab_: atoi? Or there is another preferable way in Wesnoth?
20100619 21:06:51< Crab_> kevg: what if you just write :        if((*heal_it->first)["value"] == 8) {        ?
20100619 21:07:49< kevg> Crab_: its too simple %)
20100619 21:08:00< Crab_> it's not too simple ;)
20100619 21:08:13< Crab_> since the (*heal_it->first)["value"]  is a boost::variant
20100619 21:08:20< Electric_Brain> norbert_: I see the problem, but well I won't add more to the discussion it doesn't really matter for me, I just thought colecting the calculable luck data in the replays would calm somewhat the controversy and as boucman stated it didn't so . . .
20100619 21:08:26< Crab_> so, your "8" is converted to boost::variant too, for comparison
20100619 21:09:07< Crab_> so, boost::variant made from  "8" might not be equal to boost::variant made from 8
20100619 21:10:01< kevg> boost::variant could be of any type?
20100619 21:10:29< Crab_> kevg: see src/config.hpp  - it's  typedef boost::variant<boost::blank, bool, int, double, std::string, t_string> value_type;    for us
20100619 21:12:10< Electric_Brain> boucman: could you give me a link to that existing program or whatever?, it would be useful for me (checking wheter I'm luckier than a insisting friend in hits/misses)
20100619 21:12:39< boucman> it's called "wesnoth"
20100619 21:13:03< boucman> the game itself gives you expected damage vs real damages somewhere in stats IIRC
20100619 21:20:54-!- Upth [ogmar@adsl-75-26-206-73.dsl.scrm01.sbcglobal.net] has joined #wesnoth-dev
20100619 21:20:54-!- Upth is now known as Upthorn
20100619 21:24:25< norbert_> s or Menu->Statistics gives Overall Damage Inflicted and Taken
20100619 21:24:46< norbert_> might be what boucman means
20100619 21:25:06-!- Aethaeryn [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100619 21:25:16< boucman> yes, that's it
20100619 21:36:08-!- gabba [~gabba@wesnoth/developer/gabba] has joined #wesnoth-dev
20100619 21:36:14< gabba> bonjour
20100619 21:36:20< boucman> bonjour gabba
20100619 21:36:23< kevg> gabba: hello
20100619 21:36:27< Crab_> hi, gabba
20100619 21:37:20< gabba> boucman: I haven't got to the cleanup part, but move execution/deletion is in
20100619 21:37:43< boucman> great, we can start to play now ;)
20100619 21:37:54< Electric_Brain> boucman: the expected damage inflicted and taken is the second part? damage_taken/damage_expected, I didn't know about that thanks
20100619 21:37:55< gabba> :)
20100619 21:38:26< boucman> Electric_Brain: yup, and the percent follows
20100619 21:38:36< Electric_Brain> boucman: Ok that's nice
20100619 21:39:07< boucman> gabba: seriously, we can do a short MP on trunk, stopping when we reach the point where our troops are deployed and ready to fight
20100619 21:39:15< boucman> this will allow us to see how clumsy it is...
20100619 21:40:10< gabba> boucman: good idea, but I'd like to fix the crashes first... well, maybe the one on exit can wait, but I noticed another one if you select a unit while another one is animated
20100619 21:41:17< boucman> gabba: ok, tell me when you're ready
20100619 21:43:38< Espreon> gabba: I somehow got this while playing with the wb (probably by spamming "y"): http://wesnoth.pastebin.com/vwumudP0
20100619 21:43:49< kevg> Crab_: i think this http://pastie.org/1011649 is incorrect way. ["poison"]=="cured" doesn't work too. In actions.cpp it was used for healed unit, not for healer. 
20100619 21:43:59< Espreon> Well, normally, spamming "y" just makes it segfault, so, I'm not sure what gave me that backtrace.
20100619 21:45:03< kevg> Crab_: what is cfg in game_events.cpp => WML_HANDLER_FUNCTION(heal_unit, event_info, cfg) ?
20100619 21:45:19-!- ancestral [~ancestral@12.145.225.25] has joined #wesnoth-dev
20100619 21:45:33< Crab_> the config of the tag named [heal_unit]
20100619 21:45:39< Crab_> it's not related
20100619 21:45:52< gabba> Espreon: probably related to the other crash bugs, but I'll try to reproduce it once I have proper memory management back in
20100619 21:45:57< Espreon> OK.
20100619 21:46:41< Crab_> kevg: in actions.cpp, we need to consider both cases 1) unit has ability which affects self and heals/cures him 2) unit is affected by healing ability of some other healing.
20100619 21:46:46< Crab_> s/healing/healer
20100619 21:46:53 * Espreon really wishes that alink were here.
20100619 21:47:59-!- norbert_ [~norbert@82-171-70-54.ip.telfort.nl] has quit [Quit: Leaving]
20100619 21:48:42< Crab_> kevg: so, when we get unit.get_abilities("heals"), we get a list of all abilities affecting unit, both from other potential healers and for him
20100619 21:49:14< Electric_Brain> sometimes in a replay hitting the continuous button more than once in a short time crashes the game, is this known?
20100619 21:49:20< Crab_> kevg: so yes, you are right about ' this http://pastie.org/1011649 is incorrect way'
20100619 21:50:07-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100619 21:53:06< Crab_> kevg: but then, it's possible to add a new method to unit_abilities to return you 'a list of all abilities which will affect unit A from unit B if B would stand on location C which is adjacent to A'
20100619 21:54:11< gabba> boucman: what do you think about using regular footsteps to define moves in planning mode, then having the unit visibly move to its planned position, with the arrow growing behind it (the callback stuff we discussed)?
20100619 21:54:13< Crab_> kevg: you can try to copy  unit_ability_list unit::get_abilities and throw unnecessary things away from it
20100619 21:54:47< kevg> Crab_: what is map_location is unit_ability_list::cfgs?
20100619 21:55:32< Crab_> the location of the origin of the ability affecting unit
20100619 21:55:52< Crab_> see src/unit_ability.cpp: 177
20100619 21:56:05-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Ping timeout: 276 seconds]
20100619 21:56:12< gabba> boucman: we'll need some other visual hint than arrows to indicate when planning mode is on... I was thinking of a different border around the map or whole interface, or something similar
20100619 21:56:28< boucman> gabba: why not... if it's not too hard to do...
20100619 21:56:49< Crab_> kevg: basically, see what unit::get_abilities currently does
20100619 21:56:51< boucman> gabba, the fact that you need to confirm and that units leave arrows behind should be a goood enough clue...
20100619 21:57:09< boucman> I don't think it's necessary, unless we feel it's confusing when using it...
20100619 21:57:54< gabba> boucman: maybe it's the absence of planning mode that needs to be noticed, i.e. you think you're planning, but oops your action has immediate effect
20100619 21:58:14< Crab_> kevg: it takes all abilities of unit on 'loc' which affect self, and adds all abilities of units on locations adjacent to 'loc' which affect adjacent, filtering by active abilities and by ability name
20100619 21:58:51< Crab_> and it returns a list of <ability, origin-location >
20100619 21:59:13< boucman> hmmm, I see your point...
20100619 21:59:30< Crab_> kevg: we need only a  part of that - take all abilities of HEALER standing on ORIGIN_LOC which are active and apply to unit which we will try to heal standing on LOC
20100619 21:59:49< boucman> gabba: that's what I liked with arrow instead of steps, it was a very visible change at the right place... what is your reason for changing that ?
20100619 22:00:01< Crab_> kevg: e.g., "if my healer would stand on (10,10), what his "heals" abilities would apply to that unit on (10,9) ?"
20100619 22:03:25< gabba> boucman: a few reasons, I'll try to summarize: 1- Footsteps are nifty, they'll get underused if planning mode becomes prevalent; 2- I find it doesn't look good to have the unit move over an arrow that's already there; 3- Having the arrow grow behind the unit clearly shows to the player that his "moving" the unit doesn't really move it but creates an arrow/planned move
20100619 22:04:13< kevg> Crab_: thanks
20100619 22:04:51< boucman> gabba: how about recoloring the footsteps/using another arrow style
20100619 22:05:16< Crab_> kevg: no, thanks to you. for it is you who noticed ;)
20100619 22:06:06< gabba> boucman: recoloring the footsteps would be a good solution
20100619 22:06:37< boucman> gabba: ok, let's just use the footsteps ATM, but let's keep in mind to recolor them at some point
20100619 22:07:19< gabba> boucman: I know it would be nice to merge arrows and footsteps eventually, but it's not trivial
20100619 22:07:56< boucman> gabba: no, I said to scrap the footstep code, and replace with arrows, which is slightly different :P
20100619 22:08:07< boucman> but yes, it's not trivial and not urgent
20100619 22:10:26-!- noy_ [~Noy@wesnoth/developer/noy] has quit [Quit: noy_]
20100619 22:11:47-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100619 22:12:07-!- noy [~Noy@wesnoth/developer/noy] has quit [Client Quit]
20100619 22:19:56-!- dtiger [~dtiger@dynamic-vpdn-91-149-190-99.telecom.by] has quit [Remote host closed the connection]
20100619 22:36:20< gabba> in ::move_unit (actions.cpp:2155), what is the 'map_location *next_unit' parameter for?
20100619 22:44:50-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100619 22:54:16-!- happygrue [~George@wesnoth/developer/wintermute] has quit [Read error: Connection reset by peer]
20100619 23:02:38-!- Blarumyrran [~Blarumyrr@unaffiliated/blarumyrran] has quit [Quit: Lahkun]
20100619 23:06:15< Crab_> gabba: it looks like the 'new location of the unit, for ui purposes'
20100619 23:06:58< gabba> Crab_: ok, I'm gonna pretend it's that and see what happens
20100619 23:07:05< Crab_> gabba: it's an output parameter
20100619 23:07:22< Crab_> gabba: if it's not null, the code just puts the new location of the unit to it.
20100619 23:07:39< Crab_> the new location might not match the target location, there's plenty of reasons for not reaching it.
20100619 23:07:47< gabba> hmm ok, since the unit is not guaranteed to reach destination
20100619 23:07:51< gabba> ^yeah
20100619 23:08:11< Crab_> yes. and the unit is not guaranteed to exist at next_unit_, too :) wml can kill it :)
20100619 23:09:06< Espreon> wesbot: seen alink ?
20100619 23:09:06< wesbot> Espreon: The person with the nick alink last spoke 2d 1h ago.  1d 8h ago they left with the message: Remote host closed the connection
20100619 23:33:12-!- ancestral_ [~ancestral@mobile-166-137-141-253.mycingular.net] has joined #wesnoth-dev
20100619 23:34:55-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20100619 23:35:33< kevg> Crab_: its better to write unit::get_healer_abilities or something more generic?
20100619 23:36:07< Crab_> well, it's quite easy to extract the 'heals' part to a parameter
20100619 23:36:42< Crab_> so, 'something more generic' is better
20100619 23:36:48-!- ancestral [~ancestral@12.145.225.25] has quit [Ping timeout: 265 seconds]
20100619 23:36:49-!- ancestral_ is now known as ancestral
20100619 23:37:23-!- Blueblaze is now known as Blueblazed
20100619 23:38:38< CIA-86> gabba * r43598 /trunk/src/ (play_controller.cpp play_controller.hpp): Change initialization order of whiteboard to prevent crash on exit
20100619 23:38:43< CIA-86> gabba * r43599 /trunk/src/whiteboard/ (manager.cpp move.cpp): Whiteboard: General cleanup, and tweaks to the latest interface experiments
20100619 23:38:50< CIA-86> gabba * r43600 /trunk/src/whiteboard/move.cpp: Whiteboard: highlight arrow before move execution.
20100619 23:38:56< kevg> Crab_: get_my_abilities(const std::string ability) ?
20100619 23:39:21< Crab_> kevg: your method signature needs more parameter
20100619 23:39:40< Crab_> kevg: we need const std::string &ability_name  - it's clear
20100619 23:39:52< Crab_> we need 'the unit which is to be affected with ability'
20100619 23:39:55< Espreon> gabba: Did my backtrace help at all?
20100619 23:39:58< Crab_> it's a unit or a location
20100619 23:39:58< kevg> and 2 map_location?
20100619 23:40:14< kevg> no, 1 map_location
20100619 23:40:22< Crab_> also, we need a 'unit which affects our unit with the ability' - it's a unit or a map location
20100619 23:40:37< Crab_> also, we need a hypothetical location of a unit which affects our unit with the ability - it's a map location
20100619 23:40:41< gabba> Espreon: I haven't been able to reproduce after these changes... maybe I'm not enthusiastic enough in spamming the 'y' key :P
20100619 23:40:50< Crab_> one of the parameters can come from 'this'
20100619 23:41:07< Crab_> kevg: let's, return to  "if my healer would stand on (10,10), what his "heals" abilities would apply to that unit on (10,9) ?"
20100619 23:41:37< kevg> 2 parameters at all, ok
20100619 23:41:38< Crab_> it has 'my healer' - unit,  (10,10) - hypothetical locaiton of my healer, "heals" - ability name, "10,9" - a unit to be affected.
20100619 23:41:55< Crab_> so, 4 parameters, one of them can come from this
20100619 23:42:04< Espreon> gabba: I see...
20100619 23:42:55< Crab_> kevg: of course, there's multiple ways to write that, depending on what is `this` - healer or target unit
20100619 23:43:06< Crab_> making `this` be target unit is more similar to current code
20100619 23:45:04< Crab_> kevg: of course, you can optimize away the  it->ability_active(ability, j, adjacent[i]) call
20100619 23:45:21< gabba> Espreon: nope, I tried again, and even holding 'y' continously doesn't seem to crash the game now
20100619 23:45:22< Crab_> kevg: it will return the same for mainline healers, anyway
20100619 23:45:45< Crab_> kevg: if you optimize it away, the formula won't depend on the unit-to-be-healed anymore
20100619 23:45:50< Espreon> gabba: No, no, I was't holding it, I was spamming it.
20100619 23:46:21< Crab_> kevg: and you'll be able to write a `get-all-my-abilities-which-affect-adjacent-units(const string &ability_name)` function for the healer
20100619 23:46:46< Crab_> kevg: which looks similar to what you proposed
20100619 23:47:26< Crab_> kevg: just note that you'll lose unit_abilities::affects_side and ability_active checks that way
20100619 23:47:49< gabba> Espreon: spamming like mad doesn't crash it either
20100619 23:48:17< Crab_> but unit_abilities::affects_side can be simulated with is_enemy() checks for healing; and  ability_active can be discarded for mainline without issues.
20100619 23:49:03< gabba> boucman: wow, I'm running into an annoying problem here... see, to execute actions I need to temporarily move all units back to their original spot (in case WML events trigger, or what not),
20100619 23:50:02< Crab_> gabba: and what is the problem :) ?
20100619 23:50:03< Espreon> gabba: Good.
20100619 23:50:12< boucman> gabba: yes, I thought you expected to do that...
20100619 23:50:19< gabba> boucman, Crab_: problem is, it means I need to avoid any and all screen redraws, or you see weird effects as the units' bars get drawn at their old location
20100619 23:51:19< Crab_> gabba: seems wrong, you need to animate the move, isn't it ?
20100619 23:51:54< gabba> right now I disabled showing moves on execution (the animation is played when defining it), but it causes redraws anyways
20100619 23:53:27< gabba> either way I'll need to display some kind of animation, the arrow disappearing abruptly is not good, so it means I'll have to invalidate at least the arrow path and redraw. The, nearby units (or at least their unit bars) might get redrawn at their old location.
20100619 23:53:28< Crab_> gabba: can you 'return all units to their previous places, and put some temporary units which don't affect anything but are drawn on-screen to avoid weird effects' ? 
20100619 23:53:53< Crab_> gabba: e.g, live with the redraws.
20100619 23:53:54< gabba> s/The/Then
20100619 23:54:24< gabba> Crab_: hmm, so make the real units invisible or something?
20100619 23:54:34< Crab_> gabba: yes
20100619 23:54:58< Crab_> gabba: basically, what is the real reason to modify the unit map on planned moves ?
20100619 23:56:28< gabba> well, right now the approach I've been taking is to apply the result of the planned moves to the unit map at all times. It fits well with the visual aspect of units being at their future position, with a unit ghost left behind
20100619 23:57:17< gabba> I restore the unit map to its "true" condition when needed only (such as, execution actions)
20100619 23:57:18< boucman> Crab_: when a planned move influence another planned move it's easier to keep the "top state' around
20100619 23:57:48< Crab_> gabba: ok, so you need it for visual display, and for interface/pathfinding..
20100619 23:58:17< Crab_> gabba: what prevents you from changing the move map before redraw and changing it back after redraw, during action execution ?
20100619 23:58:30< Crab_> gabba: e.g., the commands are disabled when action is executing anyway
20100619 23:59:23< Crab_> gabba: so, the game engine would use the 'real' unit map and the ui would use the 'fake' unit map.
20100619 23:59:49< gabba> Crab_: hmm, that could work I think
20100619 23:59:51< Crab_> where 'fake' unit map is a cache which can be recalculated from real unit map and applying your whiteboard actions to it.
--- Log closed Sun Jun 20 00:00:43 2010