--- Log opened Sun Jul 08 00:00:20 2012
20120708 00:06:29-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20120708 00:06:59< CIA-87> alarantalara * r54616 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/09_Blood_is_Thicker_Than_Water.cfg: Deduplicate code
20120708 00:08:07-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20120708 00:14:54-!- anonymissimus [~chatzilla@HSI-KBW-078-042-163-105.hsi3.kabel-badenwuerttemberg.de] has quit [Quit: ChatZilla 0.9.88.2 [Firefox 11.0/20120312181643]]
20120708 00:20:29-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20120708 00:32:05-!- oldtopman [~oldtopman@unaffiliated/oldtopman] has quit [Quit: oldtopman has left the house]
20120708 00:42:14-!- elias [~allefant@allefant.com] has quit [Ping timeout: 246 seconds]
20120708 00:43:23-!- stikonas__ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Quit: Konversation terminated!]
20120708 00:50:39< CIA-87> alarantalara * r54617 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/09_Blood_is_Thicker_Than_Water.cfg: 
20120708 00:50:39< CIA-87> Count number of dead merfolk instead of living ones to determine defeat
20120708 00:50:39< CIA-87> Also reorder some statements to allow special dialog for dead Enchantress to be played
20120708 00:55:07< CIA-87> alarantalara * r54618 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/09_Blood_is_Thicker_Than_Water.cfg: Zelgant is a leader so remove his loyal trait
20120708 00:59:30-!- elias [~allefant@allefant.com] has joined #wesnoth-dev
20120708 01:05:46-!- elias [~allefant@allefant.com] has quit [Ping timeout: 252 seconds]
20120708 01:07:05-!- mattsc [~mattsc@d50-92-196-35.bchsia.telus.net] has quit [Quit: bye]
20120708 01:14:25< CIA-87> alarantalara * r54619 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/09_Blood_is_Thicker_Than_Water.cfg: Counting the number of caged merfolk makes the logic slightly simpler than counting the number that were freed
20120708 01:16:08-!- knotwork_ [~markm@142.68.63.54] has joined #wesnoth-dev
20120708 01:16:08-!- knotwork_ [~markm@142.68.63.54] has quit [Changing host]
20120708 01:16:08-!- knotwork_ [~markm@unaffiliated/knotwork] has joined #wesnoth-dev
20120708 01:18:29-!- ancestral [~ancestral@50-78-227-230-static.hfc.comcastbusiness.net] has joined #wesnoth-dev
20120708 01:19:18-!- knotwork [~markm@unaffiliated/knotwork] has quit [Ping timeout: 245 seconds]
20120708 01:19:52-!- Alarantalara [~Adium@CPEc0c1c09e8055-CM00252eac6d62.cpe.net.cable.rogers.com] has quit [Quit: Leaving.]
20120708 01:30:50-!- elias [~allefant@allefant.com] has joined #wesnoth-dev
20120708 01:35:08-!- elias [~allefant@allefant.com] has quit [Ping timeout: 245 seconds]
20120708 01:39:37-!- elias [~allefant@allefant.com] has joined #wesnoth-dev
20120708 01:48:33-!- oldtopman [~oldtopman@unaffiliated/oldtopman] has joined #wesnoth-dev
20120708 01:53:03< ancestral> I feel like a noob asking this, but I'm really having trouble finding this…
20120708 01:54:02< ancestral> I want to place a new unit at a hex. What WML/Lua code do I write?
20120708 01:55:17< Espreon> http://wiki.wesnoth.org/SingleUnitWML
20120708 01:55:42< ancestral> So I write the unit info and set the unit position to the hex?
20120708 01:56:26< ancestral> I bet there's a macro
20120708 01:56:45< ancestral> Sure enough: http://www.wesnoth.org/macro-reference.xhtml#GENERIC_UNIT
20120708 01:57:24< Espreon> Well...
20120708 01:57:25< ancestral> And  UNIT SIDE TYPE X Y WML
20120708 01:57:29< ancestral> That works
20120708 01:57:32< Espreon> Yes.
20120708 01:57:44< ancestral> Cool thanks, that's what I was looking for
20120708 01:57:45< Espreon> [unit] describes the unit as well as its placement.
20120708 01:57:48< Espreon> Yup.
20120708 02:00:37-!- ancestral [~ancestral@50-78-227-230-static.hfc.comcastbusiness.net] has quit [Quit: i go sleeps kthxbai]
20120708 02:18:00-!- trademark [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has quit [Ping timeout: 252 seconds]
20120708 02:18:51-!- trademark [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has joined #wesnoth-dev
20120708 02:20:11-!- ToBeFree [~tobefree@unaffiliated/tobefree] has quit [Remote host closed the connection]
20120708 02:23:53-!- iwaim [~iwaim@gateway.alib.jp] has joined #wesnoth-dev
20120708 03:10:09-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120708 03:18:07-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20120708 03:18:26-!- ancestral [~ancestral@17.232.7.174] has joined #wesnoth-dev
20120708 04:20:49-!- ancestral-macboo [~ancestral@12.145.225.25] has joined #wesnoth-dev
20120708 04:20:52-!- ancestral-macboo is now known as ancestral-mbp
20120708 04:33:25-!- Ivanovic_ [~ivanovic@dtmd-4db22f6a.pool.mediaWays.net] has joined #wesnoth-dev
20120708 04:34:26-!- ancestral-mbp [~ancestral@12.145.225.25] has quit [Quit: And that’s the end of THAT chapter.]
20120708 04:36:24-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 260 seconds]
20120708 04:37:19-!- Ivanovic_ is now known as Ivanovic
20120708 05:16:10< CIA-87> espreon * r54620 /trunk/po/ (10 files in 10 dirs): Updated the Galician translation.
20120708 05:18:27-!- Gallaecio [~quassel@84.120.114.134.dyn.user.ono.com] has quit [Remote host closed the connection]
20120708 05:18:30< CIA-87> espreon * r54621 /branches/1.10/po/ (8 files in 8 dirs): Updated the Galician translation.
20120708 05:50:51-!- natasiel [~natasiel@wesnoth/mp-mod/natasiel] has joined #wesnoth-dev
20120708 05:52:40-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20120708 06:07:31-!- ancestral [~ancestral@17.232.7.174] has quit [Quit: ancestral]
20120708 06:10:28-!- Elvish_Pillager [~eli@71-10-229-241.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 248 seconds]
20120708 06:30:27-!- oldtopman [~oldtopman@unaffiliated/oldtopman] has quit [Quit: oldtopman has left the house]
20120708 06:39:23-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 265 seconds]
20120708 06:43:12-!- vultraz is now known as tiramisu
20120708 06:43:44-!- tiramisu is now known as vultraz
20120708 06:56:53-!- esr [~chatzilla@wesnoth/developer/esr] has quit [Remote host closed the connection]
20120708 06:59:04-!- anakayub [~anakayub@116.197.3.208] has joined #wesnoth-dev
20120708 07:12:10-!- ancestral-mbp [~ancestral@75-168-39-185.mpls.qwest.net] has joined #wesnoth-dev
20120708 07:12:19-!- ancestral-mbp is now known as ancestral
20120708 07:14:36-!- Gambit [~gambit@wesnoth/developer/grickit] has quit [Remote host closed the connection]
20120708 07:19:07-!- anakayub [~anakayub@116.197.3.208] has quit [Ping timeout: 240 seconds]
20120708 07:29:27-!- anakayub [~anakayub@116.197.3.208] has joined #wesnoth-dev
20120708 07:34:21-!- anakayub [~anakayub@116.197.3.208] has quit [Client Quit]
20120708 08:02:50-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20120708 08:22:29-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20120708 08:22:43< mordante> servus
20120708 08:28:39< shadowm> loonycyborg, mordante: Will the foreach->BOOST_FOREACH change be backported to 1.10?
20120708 08:29:06< shadowm> In fact, that isn't a question, but a reminder.
20120708 08:31:39< mordante> indeed is must be backported to/redone for 1.10, I assume(d) loonycyborg was working on that as well
20120708 08:32:04< mordante> if not I can do it, but want to avoid two people doing the same job
20120708 08:33:47-!- Ivanovic [~ivanovic@dtmd-4db22f6a.pool.mediaWays.net] has quit [Changing host]
20120708 08:33:47-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20120708 08:40:09-!- Nephro [~Dmitry@80.233.231.12] has joined #wesnoth-dev
20120708 08:50:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20120708 08:58:22< vultraz> I propose adding the debug_utils.dbms function from the Wesnoth Lua Pack to mainline. I guess I'd have to buzz anonymissimus or Elvish Hunter?
20120708 09:07:09< Nephro> vultraz, I can do that actually
20120708 09:10:57< mordante> Nephro, vultraz it would be good idea to discuss it with the Lua devs around
20120708 09:11:32< mordante> and also look whether the API used in Wesnoth Lua Pack is clean, if not better polish it before adding it
20120708 09:12:11< mordante> (I've never looked at Lua Pack so no idea how clean the API is)
20120708 09:21:58< Nephro> yes, that's what I thought. I'm not really a Lua dev, so I can't make that decision  all by myself
20120708 09:22:15< Nephro> but the dbms function seems really essential
20120708 09:22:22< Nephro> i'll reboot now
20120708 09:26:24< mordante> Akihara, around?
20120708 09:26:49-!- Nephro [~Dmitry@80.233.231.12] has quit [Ping timeout: 246 seconds]
20120708 09:30:55-!- neph [~neph@80.233.231.12] has joined #wesnoth-dev
20120708 09:31:31< mordante> if they are essential it's a good reason to add them
20120708 09:32:21< mordante> it's just and advise to look how polished they are before adding them to mainline
20120708 09:32:42< mordante> changing that after they are part of mainline is more annoying for the user
20120708 09:32:53-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20120708 09:33:03< mordante> also what happens if somebody uses Lua Pack after the functions are added to mainline?
20120708 09:33:22< mordante> does Lua have namespaces or with there be issues when using both
20120708 09:36:20< vultraz> mordante: well, if it was in mainline, it could probably be removed from the WLP
20120708 09:37:46-!- Gallaecio [~quassel@84.120.114.134.dyn.user.ono.com] has joined #wesnoth-dev
20120708 09:38:26< mordante> vultraz, of course, but what happens if somebody has Lua Pack installed and updates Wesnoth
20120708 09:39:59< vultraz> but they would update the pack too. Sorta confused here
20120708 09:40:26< mordante> now I'm confused ;-)
20120708 09:40:58< mordante> suppose I install Lua Pack, Lua Pack becomes mainline, I update Wesnoth, with Lua Pack still installed
20120708 09:40:59< vultraz> :P
20120708 09:41:17< mordante> will this give problems for the user or will it be no problem at all?
20120708 09:41:45< vultraz> I doubt it would cause problems
20120708 09:42:36< vultraz> the functions in the WLP need wesnoth.require in your addon to work, or be copied to your addon
20120708 09:44:55< mordante> ok
20120708 09:48:53-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20120708 09:55:49< vultraz> mordante: http://imagebin.org/219939
20120708 09:56:52< vultraz> seems the chat/warning lines can capture bits of a gui window...
20120708 09:57:04< vultraz> until you mouseover or scroll
20120708 10:03:15< mordante> vultraz, which window is captured?
20120708 10:05:23< vultraz> mordante: one of my custom lua GUI ones
20120708 10:14:47< mordante> hmm, only not sure whether a bug in GUI2 or in the chat window
20120708 10:15:08< mordante> you could file a bug report, but realistically I won't be able to look at it soon
20120708 10:15:31< mordante> I *really* want to get back working on the listbox improvements I started a while ago
20120708 10:15:43< shadowm> vultraz: I think I said already that the problem with the chat backlog and floating labels is that they are repainted on the display refresh method unconditionally.
20120708 10:16:10< shadowm> e.g. display::flip().
20120708 10:16:55< shadowm> This not only causes interaction issues with Lua-path GUI2 dialogs, but also excessive CPU usage due to the indiscriminate repainting.
20120708 10:17:00< mordante> ah yes the flip is rather evil
20120708 10:20:52 * vultraz wishes he knew more C++ so he could actually fix some bugs
20120708 10:21:18< Ivanovic> vultraz: what stopps you from trying to have a look at the bugs?
20120708 10:21:27< Ivanovic> the knowledge in C++ comes over time!
20120708 10:21:42< Ivanovic> ask mordante how he *really* got into C++...
20120708 10:23:10-!- Romster [~Romster@unaffiliated/romster] has joined #wesnoth-dev
20120708 10:31:21< mordante> Ivanovic, indeed, but I was of course already familiar with programming
20120708 10:31:37< mordante> only just not with the C++ language (and all its gory details)
20120708 10:35:22< Ivanovic> sure
20120708 10:35:33< Ivanovic> but i don't know whtat vultraz knows
20120708 10:35:43< Ivanovic> and "knew more" sounds like there is at least some basic coding knowledge
20120708 10:36:21< vultraz> Ivanovic: I know WML, lua, and some *very* basic C++
20120708 10:38:00< mordante> vultraz, you can always try to learn it, find a good C++ book and start
20120708 10:38:51< mordante> I started with http://www.amazon.com/The-Programming-Language-Special-Edition/dp/0201700735/ref=sr_1_2?ie=UTF8&qid=1341736711&sr=8-2&keywords=stroustrup
20120708 10:39:16< mordante> I haven't read http://www.amazon.com/Programming-Principles-Practice-Using-C/dp/0321543726/ref=sr_1_1?ie=UTF8&qid=1341736711&sr=8-1&keywords=stroustrup
20120708 10:39:31< mordante> but that book seems to be more aimed at beginners
20120708 10:41:44-!- neXyon [~neXyon@85-127-226-248.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20120708 10:56:32< vultraz> I probably should get a C++ book. So far all I've contributed are about 8 updated editor tile icons and art for fendrin's editor updates
20120708 10:59:58< mordante> the great thing about Wesnoth (and other open source projects) is that others can help you to learn a language fast
20120708 11:00:23< mordante> so if you really want to learn C++ and get stuck feel free to ask questions on IRC
20120708 11:00:31< mordante> (that's how I learned a lot)
20120708 11:00:38< vultraz> :)
20120708 11:03:26< vultraz> speaking of contributions...I should probably add myself to about.cfg.....
20120708 11:04:20< mordante> yes normally we ask that when submitting a patch
20120708 11:06:26-!- ToBeFree [~tobefree@unaffiliated/tobefree] has joined #wesnoth-dev
20120708 11:13:15< vultraz> I technically haven't gone through patches.wesnoth.org yet, all my art contribs went direct to Alarantalara or fendrin and my XCode stuff (until I got commit access) were delivered on IRC
20120708 11:14:58< mordante> the art also counts as a patch, I've never seen a real art patch ;-) 
20120708 11:19:41-!- MeccaGod [majs@host189-199.bornet.net] has joined #wesnoth-dev
20120708 11:22:47< vultraz> mordante: how do you even make art patches :P
20120708 11:23:21< mordante> exactly :-P
20120708 11:27:17< vultraz> oh BTW, Exasperation is back, he PMed me about a week ago
20120708 11:40:12-!- lipkab [~lipk@apn-94-44-249-225.vodafone.hu] has joined #wesnoth-dev
20120708 11:41:17< vultraz> gah...1.11 editor...y u no use correct lit wall icon....
20120708 11:48:37-!- trademark [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has quit [Ping timeout: 240 seconds]
20120708 11:48:45< vultraz> blaghh...builds still crash...hopefully OS X 10.8 will fix that...
20120708 12:09:11< boucman> mordante: have you seen http://forums.wesnoth.org/viewtopic.php?p=532799#p532799 ?
20120708 12:11:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 12:18:10< mordante> no hadn't seen it thanks boucman 
20120708 12:19:04< lipkab> Are there anything like namespaces in WML?
20120708 12:19:05< boucman> i'm not sure what to answer, it looks promising and all, but it adds new code to maintain...
20120708 12:19:36< mordante> lipkab, no (btw finishing my review of your patch)
20120708 12:19:58< lipkab> mordante: ok (cool)
20120708 12:20:09< mordante> I agree to prefer WML over JSON
20120708 12:21:02-!- Elvish_Pillager [~eli@71-10-229-241.dhcp.oxfr.ma.charter.com] has joined #wesnoth-dev
20120708 12:21:02< mordante> and personally not too happy with moving more stuff to Lua since it still is rather ugly regarding exception handling
20120708 12:25:44< boucman> what version of lua are we using ?
20120708 12:26:01< mordante> the newest IIRC 5.2
20120708 12:26:03< boucman> (I think there was some things done wrt exceptions in 5.2 but i'm not sure...)
20120708 12:26:18< boucman> ok, so the problem is still there, or lua would have become an external dep :P
20120708 12:26:58< mordante> there was in 5.1 as well, but it didn't work (haven't looked at 5.2)
20120708 12:27:31< mordante> we had to make our own modifications to the Lua source to get it somewhat decent
20120708 12:27:42< mordante> and the code is still hacky
20120708 12:33:56-!- mjs-de [~mjs-de@g224178037.adsl.alicedsl.de] has joined #wesnoth-dev
20120708 12:43:25< lipkab> I love how mordante keeps the 80 char limit even in a forum post :D
20120708 12:44:08< vultraz> loll
20120708 12:46:02-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 244 seconds]
20120708 12:47:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 12:52:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 248 seconds]
20120708 12:53:02-!- neph [~neph@80.233.231.12] has quit [Ping timeout: 250 seconds]
20120708 12:55:03-!- stikonas [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 12:55:03-!- stikonas [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 12:55:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 12:57:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 12:58:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 12:58:55< lipkab> zookeeper: around?
20120708 13:03:19-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 13:04:34-!- stikonas__ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 13:05:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 13:07:44-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 244 seconds]
20120708 13:29:26-!- stikonas__ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Quit: Konversation terminated!]
20120708 13:29:35-!- stikonas__ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 13:30:19-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20120708 13:31:34< zookeeper> lipkab, yes
20120708 13:33:29< lipkab> zookeeper: the first part of the modification stuff is getting close to be committed, so I'm starting to make plans about of the second part (the options)
20120708 13:33:39< lipkab> I'd like you to verify the WML interface
20120708 13:33:42< lipkab> http://pastebin.com/Av8Siawy
20120708 13:35:01< lipkab> In particular, I wonder if I should use a unified [option] with a type field instead of different tags for different kinds of variables?
20120708 13:36:16< zookeeper> no, i think that's perfectly good. sure it could be unified, but it's more clear this way
20120708 13:36:58< lipkab> Okay then. Any suggestions for the names?
20120708 13:37:53< loonycyborg> mordante: Actually I was not sure that foreach stuff is supposed to be backported.
20120708 13:38:13< loonycyborg> But I guess it can be considered a bugfix :P
20120708 13:38:40-!- stikonas__ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Read error: Connection reset by peer]
20120708 13:39:12-!- stikonas__ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 13:39:29< zookeeper> lipkab, not really... the only thing that comes to mind is s/boolean/checkbox and s/decimal/slider, but frankly i don't know if that'd be any better. at least this way it's extra clear what sort of values the variables will get.
20120708 13:40:23-!- trademark [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has joined #wesnoth-dev
20120708 13:43:29< zookeeper> lipkab, also, is the name of the modification/era/multiplayer automatically displayed as the title of each set of options in the UI?
20120708 13:44:20< lipkab> zookeeper: yes, I plan so, and the users can still define subsets with [group]
20120708 13:44:28< zookeeper> okay
20120708 13:45:22< zookeeper> i think it's good as it is, then
20120708 13:46:04< lipkab> Great, thanks.
20120708 13:46:19< zookeeper> hmh. one thought:
20120708 13:46:46< lipkab> Yes?
20120708 13:48:19< zookeeper> say you have an add-on which features several variations of the same scenario, let's say a ANL-like scenario. if you don't want to mess with eras at all, you'd need to duplicate the options for each scenario. that's not a problem in itself, but then the game won't remember your previous choices when you switch scenarios
20120708 13:48:56< zookeeper> well, i don't know if it'll remember them even currently, but presumably that'd be nice to have :P
20120708 13:51:12< zookeeper> urgh. there's a bit of thundering here. might have to shutdown.
20120708 13:51:31< lipkab> Uh... I don't know. I will make it so that it remembers the settings for one scenario (that is the way everything works in mp), but transfering options among scenarios?
20120708 13:51:40< lipkab> Ok.
20120708 13:52:11< lipkab> The problem is, that would require a global id for every sinlge option.
20120708 13:52:21< lipkab> *single
20120708 13:52:41< zookeeper> for every [options]s? yeah. but frankly that's not a big problem
20120708 13:52:57< zookeeper> i mean, it's not a big problem for the author if they can't share options among several scenarios
20120708 13:54:06< zookeeper> anyway, just thought i'd mention that
20120708 13:55:08< lipkab> It could be achieved with a workaround, thoug: outsource all the related code to a modification (way simpler than writing an era), and force each scenario to use that modification.
20120708 13:55:13< lipkab> *though
20120708 13:56:01< zookeeper> yeah, the downside is that then that modification will always appear in the list, regardless of what scenario you play
20120708 13:56:15< lipkab> Hmm, that's true.
20120708 13:57:04< lipkab> Another thing, however, I'm not sure if players would really want to share their settings among different scenarios.
20120708 13:57:19< lipkab> ...they're different scenarios, after all.
20120708 13:57:32< trademark> hey
20120708 13:57:38< lipkab> hi trademark
20120708 14:00:09< zookeeper> lipkab, sure
20120708 14:00:28< lipkab> zookeeper: Not speaking of that it could feel utterly random if the player doesn't know about this syncing mechanism. They would probably think that the game simply overrided their settings for some reason. And they would start sending bug reports...
20120708 14:00:30< zookeeper> as i said, not a big problem at all
20120708 14:00:40< lipkab> Okay.
20120708 14:01:41< zookeeper> anyway, i think i'll shutdown now just to be safe... i do have a decent surge protector, but i hate losing power
20120708 14:02:48< lipkab> See you soon.
20120708 14:04:58-!- stikonas [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 14:04:58-!- stikonas [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 14:04:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 14:05:58-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds]
20120708 14:07:24-!- stikonas__ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Read error: Operation timed out]
20120708 14:23:21-!- timotei [~timotei@wesnoth/developer/timotei] has joined #wesnoth-dev
20120708 14:31:58< bloodycoin_m> boucman: around? regarding particle branch update to upstream, I would like to do that before committing my work to trunk. Reason being, it's a bit mess: I have to rebase locally, force push to bitbucket, and then you would have to fetch, change branch, discard other changes...
20120708 14:32:16< bloodycoin_m> I would like to minimize this routine as much as possible.. :)
20120708 14:40:46-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev
20120708 14:43:24-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 14:43:33-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 14:44:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 14:45:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 14:46:37-!- lipkab [~lipk@apn-94-44-249-225.vodafone.hu] has quit [Quit: Whistling winds blow through the bay, alas, my friends, I sail away.]
20120708 14:51:10-!- csarmi_home [csarmi@94-21-80-60.pool.digikabel.hu] has joined #wesnoth-dev
20120708 14:51:10-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 14:51:22-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 14:51:45-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: No route to host]
20120708 14:51:54-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 14:52:54-!- csarmi [csarmi@178-164-141-111.pool.digikabel.hu] has quit [Ping timeout: 264 seconds]
20120708 14:54:54< mordante> loonycyborg, I think it should be backported
20120708 14:55:24< loonycyborg> Well, I'm fucking around with git mergetool right now :P
20120708 14:55:41< mordante> good luck
20120708 15:14:32-!- anonymissimus [~chatzilla@HSI-KBW-078-042-163-105.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth-dev
20120708 15:16:41< anonymissimus> vultraz: I'm not so happy about mainlining dbms, since in an addon I have sort of full control, I can do wjatever I want at any time and to not really have to provide compatibility or wgatever
20120708 15:17:26< anonymissimus> and I wrote that thing alone, so I need to maintain it
20120708 15:19:02< anonymissimus> mordante: we could place a message and then call mainline there or something, I don't see a principle problem with moving stuff from the WLP to mainline
20120708 15:20:31-!- vultraz [~chatzilla@124.109.10.221] has quit [Ping timeout: 244 seconds]
20120708 15:21:36< mordante> anonymissimus, me neither, just wanted to know whether it could break things when having WLP installed when part of the code is mainlined
20120708 15:23:08< anonymissimus> well...if you update the WLP as well to the version which is meant for your mainline version, certainly not
20120708 15:23:53< anonymissimus> if you update only mainline, it can happen that tags from the WLP overwrite tags with the same name from mainline
20120708 15:24:56< mordante> yeah that was the kind of problem I was wondering about, whether it could happen and whether Lua can handle it
20120708 15:26:42< anonymissimus> lua could handle it I think...you could chek whether a tag with the name already exists before you define it...but this is not a severe problem and quickly solved
20120708 15:26:53< anonymissimus> (we don't make such checks)
20120708 15:27:12< mordante> ok
20120708 15:27:45< mordante> well I have no idea about Lua, but C doesn't like two symbols with the same name and different type in its symbol table
20120708 15:34:12< anonymissimus> vultraz: yeahm, basically, I want to keep the ability to possibly make rather hard changes to dbms, so that's why I can't mainline it
20120708 15:38:48< anonymissimus> jamit: those complexity notes could have stayed...
20120708 15:39:58< anonymissimus> great somebody improves that CPU sucker
20120708 15:52:04-!- mattsc [~mattsc@d50-92-196-35.bchsia.telus.net] has joined #wesnoth-dev
20120708 15:56:53-!- oldtopman [~oldtopman@unaffiliated/oldtopman] has joined #wesnoth-dev
20120708 15:58:07-!- bloodycoin_m [~bloodycoi@193.170.135.78] has quit [Ping timeout: 265 seconds]
20120708 15:58:52-!- bloodycoin_m [~bloodycoi@193.170.135.78] has joined #wesnoth-dev
20120708 16:00:47< CIA-87> anonymissimus * r54622 /trunk/projectfiles/VC9/wesnoth.vcproj: vc project update
20120708 16:00:57< CIA-87> anonymissimus * r54623 /trunk/projectfiles/CodeBlocks/wesnoth.cbp: cb project update
20120708 16:23:51-!- vultraz [~chatzilla@124.109.10.221] has joined #wesnoth-dev
20120708 16:26:12< CIA-87> fendrin * r54624 /trunk/src/serialization/ (parser.cpp parser.hpp): Made an argument for the parser's read function const.
20120708 16:26:28< CIA-87> loonycyborg * r54625 /branches/1.10/src/ (195 files in 26 dirs): 
20120708 16:26:28< CIA-87> Backport r54604: Use BOOST_FOREACH directly instead of #define foreach BOOST_FOREACH
20120708 16:26:28< CIA-87> The define is extremely unreliable, will break compile with boost >=
20120708 16:26:28< CIA-87> 1.50 and upstream can't fix issues with it, see
20120708 16:26:29< CIA-87> https://svn.boost.org/trac/boost/ticket/6131
20120708 16:29:36< CIA-87> fendrin * r54626 /trunk/src/mapgen.cpp: Map generator now outputs a map in the new format.
20120708 16:39:49< CIA-87> fendrin * r54627 /trunk/src/multiplayer_create.cpp: 
20120708 16:39:49< CIA-87> Fixed multiple problems with map formats and the multiplayer lobby.
20120708 16:39:49< CIA-87> Fix for bug #19697
20120708 17:05:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20120708 17:09:37-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20120708 17:12:49< fendrin> anonymissimus: Around?
20120708 17:14:57< anonymissimus> fendrin: hm ?
20120708 17:18:17-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20120708 17:23:55< fendrin> anonymissimus: I have a fix for the mask and replace bug.
20120708 17:27:32-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20120708 17:33:26-!- oldtopman [~oldtopman@unaffiliated/oldtopman] has quit [Quit: oldtopman has left the house]
20120708 17:36:14< CIA-87> fendrin * r54628 /trunk/src/game_events.cpp: Support for the new map format in [replace_map].
20120708 17:37:19< CIA-87> fendrin * r54629 /trunk/src/menu_events.cpp: Fixed missing quotes when saving a map from inside a scenario.
20120708 17:40:01< CIA-87> fendrin * r54630 /trunk/src/pathfind/pathfind.cpp: Added a default to the switch over the pathfinding cost types.
20120708 17:46:23-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20120708 17:50:18< jamit> anonymissimus: I suppose, but were those complexity notes understandable? When I make notes for myself like that, they have a tendency to be a bit cryptic to others.
20120708 17:50:35-!- Alarantalara [~Adium@CPEc0c1c09e8055-CM00252eac6d62.cpe.net.cable.rogers.com] has joined #wesnoth-dev
20120708 17:52:51< mordante> AI0867, did you already reply to CHIP magazine?
20120708 17:53:19-!- csarmi_home [csarmi@94-21-80-60.pool.digikabel.hu] has quit [Ping timeout: 250 seconds]
20120708 17:56:05< fendrin> Ivanovic: Hi, I just fixed my last two blockers.
20120708 17:56:17< Ivanovic> fendrin: hey, cool!
20120708 17:56:39< fendrin> Ivanovic: But haven't checked if there are any others still open.
20120708 17:57:23< fendrin> Ivanovic: No, they were the last.
20120708 18:01:13< CIA-87> fendrin * r54631 /trunk/src/unit_types.hpp: Getter for jamming_cost.
20120708 18:01:22< anonymissimus> fendrin: you should probably get the child of a config only once
20120708 18:01:33< anonymissimus> and then reuse it...
20120708 18:02:52< CIA-87> fendrin * r54632 /trunk/changelog: Changelog update for a bug fix in LoW10.
20120708 18:03:21< fendrin> anonymissimus: Please point me to the code line question.
20120708 18:03:54< mordante> fendrin, since the changes to the map format are rather big (and cause possible problems) an entry in RELEASE_NOTES might be a good idea
20120708 18:04:10< mordante> Ivanovic, any idea when you want to release 1.11.0?
20120708 18:04:24< fendrin> mordante: Indeed.
20120708 18:04:57< anonymissimus> fendrin:  what's more, you probably run into the "binding to a temporary tstring when gettign attributes from a vconfig" issue
20120708 18:05:31< Ivanovic> mordante: hmm, not sure yet
20120708 18:05:39< anonymissimus> game_events.cpp:3070
20120708 18:05:45< Ivanovic> next weekend doesn't work for me
20120708 18:05:54< Ivanovic> maybe in two or three weeks
20120708 18:06:52< mordante> ok then I won't rush the CMake patch
20120708 18:08:01< anonymissimus> jamit: looking...well, if I'd understand the code then probably those notes as well (I don't want to dive into it now)
20120708 18:09:40< anonymissimus> Ivanovic: I think we're not ready for a release due to the scenario refactoring
20120708 18:09:58< Ivanovic> anonymissimus: mkay
20120708 18:10:06< anonymissimus> but better ask crab or Ayne
20120708 18:10:07< Ivanovic> mordante: so minimum 2 weeks, more likely "more"
20120708 18:10:38< anonymissimus> scenario transition refactoring
20120708 18:11:06< mordante> :-( has been quite a while since 1.10
20120708 18:11:11< Ivanovic> mordante: yes
20120708 18:11:15< Ivanovic> that is true
20120708 18:11:52< mordante> ah well, can't change it
20120708 18:15:05-!- negusnyul [~negusnyul@dsl4E5CD1DC.pool.t-online.hu] has joined #wesnoth-dev
20120708 18:22:23-!- mordante_ [~mordante@roadie.xs4all.nl] has joined #wesnoth-dev
20120708 18:22:23-!- mordante_ [~mordante@roadie.xs4all.nl] has quit [Changing host]
20120708 18:22:23-!- mordante_ [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20120708 18:22:24-!- mordante__ [~mordante@roadie.xs4all.nl] has joined #wesnoth-dev
20120708 18:25:10-!- mordante__ [~mordante@roadie.xs4all.nl] has quit [Client Quit]
20120708 18:25:13-!- mordante_ [~mordante@wesnoth/developer/mordante] has quit [Client Quit]
20120708 18:29:32< CIA-87> fendrin * r54633 /trunk/src/game_events.cpp: 
20120708 18:29:32< CIA-87> Code cleanup.
20120708 18:29:32< CIA-87> Hopefully fixed a problem with variable substitution.
20120708 18:29:37< fendrin> anonymissimus: ^ better?
20120708 18:35:07< CIA-87> alarantalara * r54634 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/09_Blood_is_Thicker_Than_Water.cfg: Use 1.11 filter_side to modify multiple sides at once, get rid of another instance of a loyal leader
20120708 18:37:11-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 18:37:11-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 18:37:11-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 18:37:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 18:39:47< anonymissimus> mordante: does the const std::string& temp = vcfg["foo"]; issue apply to parameters as well ? that is, do_something(vcfg["foo"]) where do_something(const std::string& param) ?
20120708 18:41:35-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20120708 18:44:06< mordante> the latter should be safe, since temporaries life until the end of the evaluation of the full expression
20120708 18:44:11< mordante> anonymissimus, ^
20120708 18:45:33-!- lipkab [~lipk@apn-94-44-249-225.vodafone.hu] has joined #wesnoth-dev
20120708 18:52:47< anonymissimus> okay, then it's better, fendrin :)
20120708 18:53:32< anonymissimus> mordante: meaning it lives until the do_something(vcfg["foo"]) call has run out
20120708 18:53:34< fendrin> :-)
20120708 18:54:28< mordante> still the vcfg["foo"] issue is ugly :-(
20120708 18:54:31-!- lipkab [~lipk@apn-94-44-249-225.vodafone.hu] has quit [Read error: Connection reset by peer]
20120708 18:54:57< mordante> anonymissimus, yes
20120708 19:01:53< CIA-87> mordante * r54635 /branches/1.10/src/ (gui/widgets/debug.cpp tools/validator/validator_tool.cpp): 
20120708 19:01:53< CIA-87> Some foreach to BOOST_FOREACH fixups.
20120708 19:01:53< CIA-87> They were omitted in r54625 and broke compilation.
20120708 19:02:51< CIA-87> alarantalara * r54636 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/05_A_Subterranean_Struggle.cfg: Apply more effects to multiple sides at once
20120708 19:04:13< loonycyborg> mordante: Yeah. I was unlikely to fix them all since I was guided by error messages from my actual builds.
20120708 19:04:25< mordante> loonycyborg, me too ;-)
20120708 19:06:03< loonycyborg> Of course I could just allow sed to run wild, but I also needed to handle the #include and I wanted to place it among other boost includes.
20120708 19:06:11< loonycyborg> And that couldn't be automated..
20120708 19:07:33< CIA-87> alarantalara * r54637 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06a_In_the_Tunnels_of_Trolls.cfg: No need for upkeep=free and {TRAIT_LOYAL}
20120708 19:07:40< mordante> yes and besides it's a one (two) time fix
20120708 19:12:08-!- lipkab [~lipk@apn-89-223-238-138.vodafone.hu] has joined #wesnoth-dev
20120708 19:12:29-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 19:14:50-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 19:14:50-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 19:14:50-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 19:15:14< CIA-87> alarantalara * r54638 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/01_The_Morning_After.cfg: Remove another condition made redundant by event firing
20120708 19:17:03-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 19:18:47< CIA-87> alarantalara * r54639 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/ (01_The_Morning_After.cfg 03_Stirring_in_the_Night.cfg): The next macro clears its variable
20120708 19:19:08-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 19:19:08-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 19:19:08-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 19:20:58< lipkab> mordante: around?
20120708 19:24:40< boucman> bloodycoin_m: back
20120708 19:24:41-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 19:25:08< zookeeper> lipkab, so was there anything else you wanted to discuss?
20120708 19:25:14< boucman> bloodycoin_m: ok, it was just an idea, if you'd rather do it later its no big deal I don't expect any conflict
20120708 19:25:38< lipkab> zookeeper: No.
20120708 19:26:11< zookeeper> great
20120708 19:28:34-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 19:36:59-!- anakayub [~anakayub@175.136.163.48] has joined #wesnoth-dev
20120708 19:39:15< bloodycoin_m> boucman: so, I was thinking where should I work on next... >.<
20120708 19:39:43< boucman> so, any idea ?
20120708 19:39:53< boucman> it's starting to shape up :)
20120708 19:40:43< bloodycoin_m> not really... is it ok to assume for now, what we are done with units?
20120708 19:40:55-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 244 seconds]
20120708 19:41:19< bloodycoin_m> I mean it looks working.. but maybe I am missing something..
20120708 19:42:11< boucman> bloodycoin_m: did you try adding some sort of particle effect to a movement animation ?
20120708 19:42:32< boucman> those are tricky because of the sliding...
20120708 19:42:57< bloodycoin_m> oh... not yet ;P
20120708 19:44:41< bloodycoin_m> but where should I look for movement definitions in wml? it's mainly macros with arguments to frames...
20120708 19:45:02< boucman> you could change the macros themselves...
20120708 19:45:17< boucman> for example add an effect to all drake movements
20120708 19:46:12< bloodycoin_m> and what about the case, when there is no explicit movement definition in wml for unit?
20120708 19:47:04< boucman> well, you just need one unit to test, don't you ?
20120708 19:48:37< CIA-87> alarantalara * r54640 /trunk/RELEASE_NOTES: Add a release notes section for Under the Burning Suns - playetesters wanted
20120708 19:49:09< bloodycoin_m> well true..
20120708 19:49:45< CIA-87> jamit * r54641 /trunk/src/pathutils.cpp: Adding some comments for my algorithm. This includes revised complexity notes.
20120708 19:49:51-!- wesbot changed the topic of #wesnoth-dev to: 179 bugs, 338 feature requests, 17 patches | Logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org
20120708 19:49:59< boucman> bloodycoin_m: you working on wesnoth right now ?
20120708 19:50:28< bloodycoin_m> yea, why?
20120708 19:51:10< boucman> ok, could you give that mvt thing a quick try ? if it doesn't work, it will mean a bit of work to get it going, if it does work we need to discuss or next step some more
20120708 19:51:11-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 19:51:11-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 19:51:11-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 19:51:31< boucman> and i'll be afk for ~15', sorry
20120708 19:51:42< bloodycoin_m> np
20120708 19:52:50-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20120708 19:52:51< CIA-87> jamit * r54642 /trunk/data/campaigns/tutorial/scenarios/1_Tutorial.cfg: Remove the "End scenario" menu item at the end of tutorial S1.
20120708 19:53:00-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 19:53:24< jamit> ^ Just something I noticed and was quick to fix.
20120708 20:00:34< boucman> and back
20120708 20:00:41< boucman> thought it would be longer :)
20120708 20:00:53< boucman> bloodycoin_m: tell me when you're done testing...
20120708 20:02:33< CIA-87> jamit * r54643 /trunk/src/ (3 files in 2 dirs): 
20120708 20:02:33< CIA-87> Remove some redundant on_board() and is_keep() calls.
20120708 20:02:33< CIA-87> (on_board() is part of is_castle() and
20120708 20:02:33< CIA-87> is_keep() is part of can_recruit_on().)
20120708 20:03:15-!- neph [~neph@80.233.231.12] has joined #wesnoth-dev
20120708 20:08:55-!- Gallaecio [~quassel@84.120.114.134.dyn.user.ono.com] has quit [Remote host closed the connection]
20120708 20:09:44-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 20:12:18-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 20:20:04< bloodycoin_m> boucman: currently new effects gets created on every 3-4 steps.. (at least on my machine)
20120708 20:20:21-!- lipkab [~lipk@apn-89-223-238-138.vodafone.hu] has quit [Read error: Connection reset by peer]
20120708 20:20:48< boucman> not sure what you mean...
20120708 20:21:14< boucman> steps as in 3-4 hex ?
20120708 20:21:24< bloodycoin_m> logically it should create new effect every step.. but I think due to my rather not so fast pc, some frames gets skipped, or unimation dies before effect gets chance to spawn some particles..
20120708 20:21:35< bloodycoin_m> yea... 3-4 hexes
20120708 20:21:57< boucman> hmm, could you commit so I can look at it here, I have a fairly powerfull pc...
20120708 20:22:12< bloodycoin_m> sec
20120708 20:23:44-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 20:23:55< bloodycoin_m> boucman, done
20120708 20:24:27-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 20:24:38< boucman> ok, pulling...
20120708 20:25:19-!- lipkab [~lipk@apn-151-0-77-233.vodafone.hu] has joined #wesnoth-dev
20120708 20:26:07< boucman> bloodycoin_m: what unit type uses the macro you've modified ?
20120708 20:27:55< bloodycoin_m> good old horseman
20120708 20:28:02< boucman> k
20120708 20:29:16< boucman> hmm
20120708 20:29:57< boucman> I don't have it onevery frame either, which means that it's not a perf problem... your callbacks are probably not called at every frame, let's check how they are wired
20120708 20:30:41-!- trademark [~trademark@mon69-1-82-67-23-185.fbx.proxad.net] has quit [Ping timeout: 246 seconds]
20120708 20:31:00< boucman> I see no call to update_effect_position, is that normal ?
20120708 20:32:08< bloodycoin_m> well.. yea, since I am not calling it from unit animation...
20120708 20:32:27< bloodycoin_m> atm it only plays effects with start animation..
20120708 20:32:50-!- Gallaecio [~quassel@84.120.114.134.dyn.user.ono.com] has joined #wesnoth-dev
20120708 20:32:54< boucman> ok, well start animation is not called for every hex, it's called only when the animation is started 
20120708 20:33:14< boucman> and a movement anim stays for multiple hex
20120708 20:33:21< bloodycoin_m> hmm....
20120708 20:34:27< bloodycoin_m> then... should I create new effect on every position change too? because, if I move it would look strange - moving effect till next creation...
20120708 20:34:33< bloodycoin_m> no wait...
20120708 20:34:40< boucman> after that, you probably want to pass to the anim engine the position of the unit within the hex, so that the effect follows the unit when the unit leaves the hex...
20120708 20:35:09< bloodycoin_m> position updating doesn't affect already spawned particles, only spawning point
20120708 20:35:36< boucman> bloodycoin_m: as a first step, make the effect "jump" when the unit changes hex. I have an idea how to make it look better, but that will be a further step
20120708 20:36:10< boucman> bloodycoin_m: some effects should follow the unit, some shouldn't... this will probably depend on the algorithm, but we need to make sure we can support both
20120708 20:36:10-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 20:36:19-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 20:36:48-!- lipkab [~lipk@apn-151-0-77-233.vodafone.hu] has quit [Ping timeout: 245 seconds]
20120708 20:37:02-!- lipkab [~lipk@apn-130-43-254-76.vodafone.hu] has joined #wesnoth-dev
20120708 20:37:19-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20120708 20:37:31-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 20:37:31-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 20:37:31-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 20:37:48< bloodycoin_m> jump? wouldn't it make more sense to let already existing particles to continue on their path, rather than shifting them to new position?
20120708 20:38:29< boucman> depends... for the effect you are currently using, they should start below the unit feet and rise up independantly of the unit
20120708 20:38:50< boucman> but if I want an effect where particles are spiraling around a unit, they should move with the unit...
20120708 20:38:59< boucman> so no hard rule here...
20120708 20:39:21< bloodycoin_m> hmm.. ok, makes sense
20120708 20:39:42< boucman> I would say : call update_effect_position on each redraw with three params, the base hex, and X and Y offsets in pixel
20120708 20:39:53< boucman> some algorithms would use that offset, other wouldn't...
20120708 20:40:55< bloodycoin_m> by offsets you mean like between two hexes?
20120708 20:41:41< boucman> yes, an offset in pixel
20120708 20:42:04< boucman> (to be precise, pixels not taking zoom into account, that's the standard convention)
20120708 20:45:45-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 20:45:55-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 20:46:02-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 20:46:02-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 20:52:18-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 20:53:28-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 20:53:28-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 20:53:28-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 20:59:19< CIA-87> jamit * r54644 /trunk/ (9 files in 4 dirs): 
20120708 20:59:19< CIA-87> Suppress recruit/recall commands from the context menu for shrouded and visibly
20120708 20:59:19< CIA-87> occupied hexes.
20120708 20:59:19< CIA-87> Part of a fix for bug #19844.
20120708 21:00:41-!- neXyon [~neXyon@85-127-226-248.dynamic.xdsl-line.inode.at] has quit [Quit: bye]
20120708 21:03:16< boucman> bloodycoin_m: you fine with that ?
20120708 21:07:16< anonymissimus> jamit: not quite sure that thing is a bug
20120708 21:08:07-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20120708 21:08:11< jamit> You should be able to recruit when you don't know that you can?
20120708 21:08:47-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has joined #wesnoth-dev
20120708 21:08:47-!- stikonas_ [~gentoo@ctv-79-132-164-161.vinita.lt] has quit [Changing host]
20120708 21:08:47-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20120708 21:09:59< mordante> lipkab, I've gotta go, I expect to be around tomorrow
20120708 21:10:03< mordante> I'm off bye
20120708 21:10:27< anonymissimus> I seem to recall some wb bug related to that, and I seem to recall that this basic ability wasn treated as a bug
20120708 21:10:54-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20120708 21:11:37< anonymissimus> perhaps ask gabba
20120708 21:11:53< anonymissimus> he fixed something related to that map IIRC
20120708 21:12:40< jamit> It seems odd to be able to ignore shroud like that, but OK, I can see what gabba remembers.
20120708 21:13:11< jamit> wesbot seen gabba
20120708 21:13:11< wesbot> jamit: The person with the nick gabba last spoke 2d 23h ago.  2d 23h ago they left with the message: Quit: Page closed
20120708 21:13:54< jamit> Taking the weekend off apparently. :)
20120708 21:14:35< anonymissimus> jamit: when reading the commit message for 54642 I thought you removed the menu item entirely instead of clearing it
20120708 21:15:07< anonymissimus> but it makes sense now ;)
20120708 21:17:29< jamit> Heh. I guess it depends on your state of mind when reading it. "At the end" *could* refer to the end of the file instead of the end of playing, I guess.
20120708 21:22:05< CIA-87> alarantalara * r54645 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/ (01_The_Morning_After.cfg 02_Across_the_Harsh_Sands.cfg): Use filter_condition where appropriate in scenarios 1 & 2
20120708 21:22:15< bloodycoin_m> boucman: trying :)
20120708 21:22:29< jamit> anonymissimus: Were you thinking of https://gna.org/bugs/?func=detailitem&item_id=17277 ?
20120708 21:22:36< boucman> :)
20120708 21:23:08< jamit> That one looks to be more about hidden units than hidden tiles, but otherwise it is similar.
20120708 21:27:54< CIA-87> jamit * r54646 /trunk/changelog: Remove changelog entry for a bugfix where the bug was never in a release (SVN only).
20120708 21:29:50< jamit> ^ I think that's the correct approach. Not sure why I added to the change log in the first place for that one.
20120708 21:30:37< anonymissimus> jamit: yes, I think thats the correct bug
20120708 21:32:14< anonymissimus> however, if the option to recruit in unseen tiles is removed at all then one also cannot test with the wb whether they are used ?
20120708 21:32:46-!- stikonas_ is now known as stikonas
20120708 21:33:00< anonymissimus> but anyway, it seems I remembered it right; the option to recruit (without wb on) into unseen tiles wasn't questioned as a bug in that report
20120708 21:33:48< jamit> The way I read the code, both the whiteboard and regular recruiting use the code I changed to see if a leader can recruit in a given hex.
20120708 21:34:43-!- lipkab [~lipk@apn-130-43-254-76.vodafone.hu] has quit [Ping timeout: 245 seconds]
20120708 21:34:54< jamit> There is a second issue of recruiting in an arbitrary hex (e.g. using the hotkey without a castle hex highlighted), and that should also be common code for WB and not-WB.
20120708 21:37:16< jamit> Oh, almost forgot: crab_, r54644 might impact the AI, but it looks like it would be in a beneficial way. Specifically, when the AI verifies that recruiting on a specific hex is possible, it will know that occupied hexes are not valid recruit locations.
20120708 21:37:51-!- lipkab [~lipk@apn-94-44-130-98.vodafone.hu] has joined #wesnoth-dev
20120708 21:37:54-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120708 21:38:11-!- happygrue [~quassel@c-98-222-183-113.hsd1.il.comcast.net] has joined #wesnoth-dev
20120708 21:38:11-!- happygrue [~quassel@c-98-222-183-113.hsd1.il.comcast.net] has quit [Changing host]
20120708 21:38:11-!- happygrue [~quassel@wesnoth/developer/wintermute] has joined #wesnoth-dev
20120708 21:38:21-!- un214 [~un214@108.221.231.209] has joined #wesnoth-dev
20120708 21:39:16< jamit> The affected AI functions are recall_result::test_suitable_recall_location() and recruit_result::test_suitable_recruit_location(), both in ai/actions.cpp, and both only affected if the object has an on-board location to test.
20120708 21:40:59-!- happygrue_ [~quassel@wesnoth/developer/wintermute] has quit [Ping timeout: 256 seconds]
20120708 21:42:03< jamit> I scanned the surrounding code, and it looks like this should be either no- or positive- impact, but I figured I should mention it in case I missed something.
20120708 21:42:42-!- lipkab [~lipk@apn-94-44-130-98.vodafone.hu] has quit [Ping timeout: 264 seconds]
20120708 21:45:47< CIA-87> alarantalara * r54647 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/03_Stirring_in_the_Night.cfg: Do not store casualties on turn 12 - Garak already has his recruits
20120708 21:46:32-!- un214 [~un214@108.221.231.209] has quit [Remote host closed the connection]
20120708 21:51:19< CIA-87> alarantalara * r54648 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/03_Stirring_in_the_Night.cfg: Remove a meaningless #ifdef
20120708 21:59:55-!- neph [~neph@80.233.231.12] has quit [Ping timeout: 246 seconds]
20120708 22:14:33-!- neXyon [~neXyon@85-127-226-248.dynamic.xdsl-line.inode.at] has joined #wesnoth-dev
20120708 22:17:30-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 264 seconds]
20120708 22:18:52-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120708 22:20:10< CIA-87> alarantalara * r54649 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/ (3 files): Use filter condition in scenarios 4-6a
20120708 22:21:17< jamit> I guess I can revert two commits as well as one, so I'll go ahead with the second half of the fix for bug? #19844 while we wait on gabba.
20120708 22:23:10< CIA-87> jamit * r54650 /trunk/src/ (5 files in 4 dirs): 
20120708 22:23:10< CIA-87> Prevent recruitment/recalling into/through shrouded hexes.
20120708 22:23:10< CIA-87> Rest of the fix for bug #19844.
20120708 22:25:54< CIA-87> jamit * r54651 /trunk/ (changelog players_changelog): Changelog entries for r54650
20120708 22:27:18< jamit> OK, three commits to potentially revert... Always forgetting to change the log...
20120708 22:35:16-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 246 seconds]
20120708 22:36:06-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120708 22:41:28-!- timotei [~timotei@wesnoth/developer/timotei] has quit [Read error: Connection reset by peer]
20120708 22:51:11< CIA-87> alarantalara * r54652 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: Use [modify_unit], rather than store/modify/unstore to convert Grog to player side
20120708 23:05:06< CIA-87> alarantalara * r54653 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/06b_In_the_Domain_of_Dwarves.cfg: [filter_condition] in scenario 6b
20120708 23:30:01< CIA-87> alarantalara * r54654 /trunk/data/campaigns/Under_the_Burning_Suns/scenarios/08_Out_of_the_Frying_Pan.cfg: [filter_condition] in scenario 8
20120708 23:31:10< Alarantalara> I'm starting to wonder about the use of filters for events vs. [if]
20120708 23:31:33< zookeeper> why?
20120708 23:31:49< Alarantalara> IN some cases filters have a clear advantage - no need for and else allow_undo with first_time_only = no
20120708 23:32:48< zookeeper> but..?
20120708 23:33:04< Alarantalara> but for an event that only happens the first time someone moves to a location if something else hasn't happened, is it better from the game engine's perspective to run the if and never have to check the event again?
20120708 23:33:35-!- shadowm_laptop2 [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120708 23:33:43-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Killed (cameron.freenode.net (Nickname regained by services))]
20120708 23:33:43-!- shadowm_laptop2 is now known as shadowm_laptop
20120708 23:35:05< anonymissimus> Alarantalara: you suspect that exiting the event due to first_time_only=yes is faster than due to a false filter ?
20120708 23:35:32< zookeeper> the performance difference should be absolutely negligible
20120708 23:35:36 * anonymissimus is confused
20120708 23:35:48< zookeeper> i wouldn't care about that, really
20120708 23:36:31< Alarantalara> For a single instance, yes. UtBS has a lot of them in some scenarios though
20120708 23:36:35< zookeeper> in such a situation, i'd prefer a nested event first, then a flag variable and [filter_condition], and lastly such an [if] usage
20120708 23:37:25< zookeeper> anyways, i gotta be going...
20120708 23:37:29< Alarantalara> For instance, I have a set of 5 that all trigger once until a condition is met, at which point they no longer do anything
20120708 23:37:50< Alarantalara> I think what I really want is [remove_event]
20120708 23:37:50-!- shadowm_laptop2 [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20120708 23:38:09-!- shadowm_laptop [ignacio@wesnoth/developer/shadowmaster] has quit [Read error: Connection reset by peer]
20120708 23:38:12-!- shadowm_laptop2 is now known as shadowm_laptop
20120708 23:38:40< anonymissimus> to remove an event, give the event to remove an id= upon defining it; and later on use [event][event] id=your_id remove=yes
20120708 23:39:41< anonymissimus> (this really removes it from the config the engine keeps, event for events which were defined at scenario toplevel)
20120708 23:39:50< anonymissimus> *even*
20120708 23:39:55< Alarantalara> Excellent! Thanks a lot
20120708 23:40:09< anonymissimus> and I don't get "but for an event that only happens the first time someone moves to a location if something else hasn't happened, is it better from the game engine's perspective to run the if and never have to check the event again?"
20120708 23:40:47< Alarantalara> anonymissimus: I'll try again
20120708 23:40:49< anonymissimus> if it only happens the first time, first_time_only is yes and it doesn't matter whether you use [if] or [filter_condition]
20120708 23:40:52< Alarantalara> Gven a move to event
20120708 23:41:00< Alarantalara> *Given a move to event
20120708 23:41:07< anonymissimus> since first_time_only is checked previously
20120708 23:41:17< Alarantalara> That has first_time_only=yes
20120708 23:41:41-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20120708 23:42:04< Alarantalara> Is it better to call filter_condition to check if something else has not yet happened
20120708 23:42:27< anonymissimus> certainly
20120708 23:42:31< Alarantalara> Or have an if statement that checks the case and does nothing if it hasn't
20120708 23:42:35< anonymissimus> but only since it is less wml code
20120708 23:44:45< anonymissimus> look into game_events.cpp:3169; in case first_time_only=yes and the event was already tried to be executed (or actually was executed) that function exits at once
20120708 23:44:48< Alarantalara> The event at line 1137 of 06b_In_the_Domain_of_the_Dwarves is a good example. I changed it as I was trying to reduce code as you described, and then wondering if I should be going the other way.
20120708 23:45:13< anonymissimus> otherwise it checks whether the event is filtered out (including filter_condition filters)
20120708 23:46:31< Alarantalara> I suppose the difference in speed is negligible, as zookeeper said, it just felt messy to me.
20120708 23:49:02< anonymissimus> well, if it is tried to be executed, but bridge_blown isn't 0 it is a little bit faster with filter_condition I suppose, since the handling of [if] comes once that the wml action tags are processed
20120708 23:49:47< anonymissimus> which happens much laster than the handling of the filters (filter_condition, filter, filter_second etc)
20120708 23:50:50< jamit> For the Jorgi's death event, I would say filter the event on Jorgi, and use an [if] to determine of the bridge was blown. The justification being that you want the event to fire when either the message should be spoken or you know the text will never be spoken.
20120708 23:51:00< anonymissimus> so, not just less wml but also a bit faster :)
20120708 23:52:14< jamit> It would not be that far off to think first_time_only=yes makes an event vanish from the game engine once it fires. It doesn't literally vanish (unless the game is saved?), but looks to be as close as you can get.
20120708 23:53:11< anonymissimus> it just disables the handler after being tried to execute, but it is still saved
20120708 23:53:19< anonymissimus> and also reloaded I think
20120708 23:53:47< Alarantalara> I suppose the fastest option would be to give both events ids and remove both events when either runs
20120708 23:54:01< Alarantalara> As a bonus, the variable goes away
20120708 23:54:08< anonymissimus> jamit: and your sentence above doesn't make sense to me
20120708 23:54:13< jamit> disabled() is also checked in write_events()
20120708 23:55:07< jamit> Which part doesn't make sense? (I had trouble getting rid of the awkwardness in it. Brain must be getting tired.)
20120708 23:56:24< anonymissimus> okay, then first time only events which were tried to execute aren't saved; but it comes into effect only when saving, quitting teh scenario and reloading
20120708 23:58:33< jamit> Right, I meant it vanishes after loading a saved game, not that the event is discarded from the active game when a save is made.
20120708 23:59:35< anonymissimus> ...first time only events which *have been executed*...
--- Log closed Mon Jul 09 00:00:04 2012