--- Log opened Sat Jan 19 00:00:07 2013 20130119 00:04:12-!- yann [~dwitch@nan92-1-81-57-214-146.fbx.proxad.net] has quit [Remote host closed the connection] 20130119 00:07:36-!- trewe [~trewe@87.196.32.85] has quit [Ping timeout: 244 seconds] 20130119 00:08:08-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 256 seconds] 20130119 00:10:02-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 252 seconds] 20130119 00:11:48-!- mattsc [~mattsc@fw.hia.nrc.ca] has quit [Ping timeout: 245 seconds] 20130119 00:12:49-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!] 20130119 00:15:09-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev 20130119 00:17:28-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev 20130119 00:44:27-!- mattsc [~mattsc@d154-20-32-241.bchsia.telus.net] has joined #wesnoth-dev 20130119 00:53:02-!- mjs-de [~mjs-de@f053188135.adsl.alicedsl.de] has quit [Remote host closed the connection] 20130119 00:56:07-!- Blueblaze [~Blueblaze@2602:304:cca1:4029:6233:4bff:fe0a:827b] has quit [Remote host closed the connection] 20130119 00:56:28-!- Blueblaze [~Blueblaze@2602:304:cca1:4029:6233:4bff:fe0a:827b] has joined #wesnoth-dev 20130119 01:14:03-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20130119 01:32:04-!- cib0 [~blub@p5DD2353D.dip.t-dialin.net] has quit [Quit: Leaving.] 20130119 01:35:32-!- nejucomo [~nejucomo@gateway/tor-sasl/nejucomo] has joined #wesnoth-dev 20130119 01:40:23-!- Blueblaze2 [~Blueblaze@adsl-76-202-20-2.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev 20130119 01:40:24-!- Blueblaze [~Blueblaze@2602:304:cca1:4029:6233:4bff:fe0a:827b] has quit [Read error: No route to host] 20130119 01:40:24-!- Blueblaze2 is now known as Blueblaze 20130119 02:35:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20130119 02:50:22-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection] 20130119 03:41:42-!- nejucomo [~nejucomo@gateway/tor-sasl/nejucomo] has quit [Ping timeout: 276 seconds] 20130119 04:35:59-!- Upthorn [~ogmar@69.62.144.56] has quit [Ping timeout: 240 seconds] 20130119 04:36:30-!- Ivanovic_ [~ivanovic@dtmd-4db2695b.pool.mediaWays.net] has joined #wesnoth-dev 20130119 04:36:30-!- Ivanovic_ [~ivanovic@dtmd-4db2695b.pool.mediaWays.net] has quit [Changing host] 20130119 04:36:30-!- Ivanovic_ [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev 20130119 04:40:29-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 240 seconds] 20130119 04:42:25-!- Ivanovic_ is now known as Ivanovic 20130119 04:57:48-!- Elvish_Pillager [~eli@dhip-852.mlr.rg-wl.colby.edu] has quit [Ping timeout: 272 seconds] 20130119 04:58:08-!- Elvish_Pillager [~eli@dhip-029.rrw.residences.colby.edu] has joined #wesnoth-dev 20130119 05:12:35-!- nejucomo [~nejucomo@gateway/tor-sasl/nejucomo] has joined #wesnoth-dev 20130119 05:14:07-!- fendrin [~fabi@88-134-21-216-dynip.superkabel.de] has joined #wesnoth-dev 20130119 05:14:07-!- fendrin [~fabi@88-134-21-216-dynip.superkabel.de] has quit [Changing host] 20130119 05:14:07-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20130119 05:26:11-!- Elvish_Pillager [~eli@dhip-029.rrw.residences.colby.edu] has quit [Ping timeout: 255 seconds] 20130119 06:29:21-!- Gambit [~gambit@wesnoth/developer/grickit] has quit [Read error: Connection reset by peer] 20130119 06:39:03-!- csarmi [csarmi@84-236-96-227.pool.digikabel.hu] has quit [Read error: Connection reset by peer] 20130119 06:39:12-!- csarmi [csarmi@84-236-96-227.pool.digikabel.hu] has joined #wesnoth-dev 20130119 07:04:30-!- nejucomo [~nejucomo@gateway/tor-sasl/nejucomo] has quit [Ping timeout: 276 seconds] 20130119 07:29:10-!- nejucomo [~nejucomo@gateway/tor-sasl/nejucomo] has joined #wesnoth-dev 20130119 07:35:03-!- nejucomo [~nejucomo@gateway/tor-sasl/nejucomo] has quit [Ping timeout: 276 seconds] 20130119 07:36:21-!- Upthorn [~ogmar@108-85-91-228.lightspeed.frokca.sbcglobal.net] has joined #wesnoth-dev 20130119 08:02:52-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [] 20130119 09:07:31-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20130119 09:13:37-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20130119 09:28:06< shadowm> zookeeper: So why doesn't the LIMIT_RECRUITS macro in mainline clean up after itself on victory (and seems to account for that fact on prestart?) 20130119 09:46:16-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving] 20130119 09:51:13-!- Appleman1234 [~Appleman1@st0801.nas931.n-yokohama.nttpc.ne.jp] has quit [Ping timeout: 248 seconds] 20130119 09:51:35-!- Appleman1234 [~Appleman1@st0801.nas931.n-yokohama.nttpc.ne.jp] has joined #wesnoth-dev 20130119 10:00:09< zookeeper> shadowm, laziness or an oversight 20130119 10:02:15< shadowm> Which needs to be fixed. 20130119 10:12:30< zookeeper> certainly 20130119 10:31:22-!- mjs-de [~mjs-de@d120107.adsl.hansenet.de] has joined #wesnoth-dev 20130119 10:49:05< boucman> mattsc: around ? 20130119 10:52:10-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 10:59:24-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Quit: And away we go] 20130119 10:59:27-!- lipkabb [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 11:06:44-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 248 seconds] 20130119 11:14:39-!- lipkabb [~lipk@host-91-147-212-174.biatv.hu] has quit [Read error: Connection reset by peer] 20130119 11:14:54-!- lipkabb [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 11:30:38-!- horon [~horon@nttkyo320074.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has joined #wesnoth-dev 20130119 11:37:02-!- Blueblaze [~Blueblaze@adsl-76-202-20-2.dsl.hstntx.sbcglobal.net] has quit [Quit: Blueblaze] 20130119 12:01:10-!- trewe [~trewe@87.196.87.207] has joined #wesnoth-dev 20130119 12:04:26-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 12:04:26-!- lipkabb [~lipk@host-91-147-212-174.biatv.hu] has quit [Read error: Connection reset by peer] 20130119 12:11:59-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 240 seconds] 20130119 12:13:28-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 12:19:06-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Read error: Connection reset by peer] 20130119 12:21:05-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 12:42:55-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 260 seconds] 20130119 12:52:33-!- csarmi_home [~csarmi@94-21-124-223.pool.digikabel.hu] has joined #wesnoth-dev 20130119 12:52:46-!- csarmi [csarmi@84-236-96-227.pool.digikabel.hu] has quit [Ping timeout: 252 seconds] 20130119 13:01:35-!- csarmi_home [~csarmi@94-21-124-223.pool.digikabel.hu] has quit [Ping timeout: 255 seconds] --- Log opened Sat Jan 19 13:56:10 2013 20130119 13:56:19-!- lobby [~wesnoth@wesnoth/bot/lobby] has joined #wesnoth-dev 20130119 13:56:19-!- Topic for #wesnoth-dev: FOSDEM 2013 planning: http://wiki.wesnoth.org/Fosdem2013 | 177 bugs, 333 feature requests, 16 patches | Logs: http://irclogs.wesnoth.org | Don't paste on IRC! Use a pastebin: http://pastebin.com | http://imagebin.org 20130119 13:56:19-!- Topic set by wesbot [~wesbot@wesnoth/bot/wesbot] [Wed Jan 16 23:53:23 2013] 20130119 13:56:19[Users #wesnoth-dev] 20130119 13:56:19[ AI0867 ] [ ejls ] [ horon ] [ loonybot ] [ Smar ] 20130119 13:56:19[ Akihara ] [ elias ] [ Ingmar ] [ loonycyborg] [ timotei ] 20130119 13:56:19[ apoi ] [ enchilado] [ irker258 ] [ LordNasty ] [ ToBeFree] 20130119 13:56:19[ Appleman1234 ] [ Espreon ] [ irker800 ] [ mattsc ] [ trewe ] 20130119 13:56:19[ Arc ] [ esr ] [ isaac ] [ melinath ] [ Upth ] 20130119 13:56:19[ balrog ] [ ettin ] [ Ivanovic ] [ mjs-de ] [ Upthorn ] 20130119 13:56:19[ boucman ] [ exciton ] [ iwaim_ ] [ oldtopman ] [ vultraz ] 20130119 13:56:19[ ChrisOelmueller] [ fendrin ] [ jamit ] [ Rhonda ] [ wesbot ] 20130119 13:56:19[ cjhopman ] [ Gallaecio] [ janebot ] [ Samual ] [ {V} ] 20130119 13:56:19[ cjhopman_ ] [ greg-pdx ] [ knotwork_] [ shadowm ] 20130119 13:56:19[ crimson_penguin] [ happygrue] [ lobby ] [ shikadibot ] 20130119 13:56:19-!- Irssi: #wesnoth-dev: Total of 53 nicks [0 ops, 0 halfops, 0 voices, 53 normal] 20130119 13:56:26-!- Channel #wesnoth-dev created Tue Jan 27 06:28:41 2009 20130119 13:56:42-!- Soliton [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev 20130119 13:57:28-!- Irssi: Join to #wesnoth-dev was synced in 77 secs 20130119 13:58:42-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev 20130119 14:16:15-!- DCW1 [~Thunderbi@cpc3-finc11-0-0-cust651.4-2.cable.virginmedia.com] has joined #wesnoth-dev 20130119 14:35:47-!- stikonas [~gentoo@128.232.247.99] has joined #wesnoth-dev 20130119 14:35:47-!- stikonas [~gentoo@128.232.247.99] has quit [Changing host] 20130119 14:35:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20130119 14:42:21-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 14:46:00-!- irker819 [~irker@ai0867.net] has joined #wesnoth-dev 20130119 14:46:00< irker819> wesnoth: jamit * r56095 /trunk/src/unit_types.cpp: 20130119 14:46:01< irker819> wesnoth: Move processing of child configs from unit_type to unit_type_data::set_config(). 20130119 14:46:01< irker819> wesnoth: It is a bit hacky to have unit_type modify the config passed as a parameter to its constructor, 20130119 14:46:02< irker819> wesnoth: especially when the modifications are not done by the constructor. 20130119 14:46:03< irker819> wesnoth: As for performance, this change has little impact on the net time taken by set_config(). While 20130119 14:46:03< irker819> wesnoth: it does spend more time processing configs, it takes less time building unit_types. The net 20130119 14:46:03< irker819> wesnoth: result might be a small increase in time, but any increase is comparable to the variations 20130119 14:46:04< irker819> wesnoth: (Log message trimmed.) 20130119 14:55:57-!- DCW1 [~Thunderbi@cpc3-finc11-0-0-cust651.4-2.cable.virginmedia.com] has quit [Quit: DCW1] 20130119 15:02:03-!- skyfaller [~skyfaller@ool-43551edd.dyn.optonline.net] has joined #wesnoth-dev 20130119 15:02:03-!- skyfaller [~skyfaller@ool-43551edd.dyn.optonline.net] has quit [Changing host] 20130119 15:02:03-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev 20130119 15:12:02-!- Elvish_Pillager [~eli@dhip-029.rrw.residences.colby.edu] has joined #wesnoth-dev 20130119 15:13:00-!- horon [~horon@nttkyo320074.tkyo.nt.ngn2.ppp.infoweb.ne.jp] has quit [Quit: Leaving...] 20130119 15:39:15-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Read error: Connection reset by peer] 20130119 15:39:22-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 15:44:44-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 252 seconds] 20130119 15:56:43-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20130119 16:07:20< mattsc> boucman: I am now 20130119 16:07:33-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 248 seconds] 20130119 16:07:43< boucman> hey :) 20130119 16:07:55< boucman> an Idea I had bouncing in my head for some time... 20130119 16:08:35< boucman> do we have anything in the AI dedicated to "decide where to move newly recruited units" i.e a part of the AI that only deals with units out of combat and decide in which area they would be the most usefull 20130119 16:08:59< boucman> I think that would be a good candidate for a second "learning AI" like the recruiting one... 20130119 16:09:33< mattsc> If I understand you correctly, that's what the move-to-targets CA does for all units (not just newly recruited units) 20130119 16:09:49< boucman> oh, ok 20130119 16:09:52< boucman> didn't know that 20130119 16:10:15< mattsc> not saying that it does it exactly how you imagine, but MtT moves units to targets more than one move away 20130119 16:10:27< boucman> ok 20130119 16:10:58< mattsc> One of the problems with that is that the only default targets are enemy leaders and villages 20130119 16:11:20< mattsc> (There were a couple topics on that on the forums recently, don't know if you saw those) 20130119 16:11:53< mattsc> But then you can set other targets manually with the [goal] tag (or [target], previously) 20130119 16:12:59-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20130119 16:15:43< jamit> mattsc: Quick question, if you know the answer: Is there an AI setting that will cause a leader to move to targets? 20130119 16:16:05< jamit> If you don't know, I suppose I could be not-lazy and review the wiki. :) 20130119 16:16:41< mattsc> I'll do it for you: http://wiki.wesnoth.org/AiWML#The_.5Bai.5D_Tag:_Defining_Aspects 20130119 16:16:47< mattsc> [leader_goal] 20130119 16:17:09< jamit> Ah... 20130119 16:17:43< mattsc> That only works with x,y coordinates though, not units etc. 20130119 16:17:44< jamit> Hmm... but that only makes locations a goal, not enemy units. 20130119 16:18:05< mattsc> yes 20130119 16:18:35< jamit> So I think I was right when I said a new CA might be needed for http://forum.wesnoth.org/viewtopic.php?f=21&t=38183 20130119 16:18:51< jamit> The situation is that all units are leaders, so no one wants to fight. 20130119 16:20:02< mattsc> yes, that's correct. In fact: 20130119 16:20:37< mattsc> http://wiki.wesnoth.org/Practical_Guide_to_Modifying_AI_Behavior#Ideas_for_Potentially_Easy_AI_Patches 20130119 16:21:02< mattsc> Look at the third bullet. At some point (during the last GSOC) I made the request to be able to do that. 20130119 16:21:28< mattsc> It never happened though, didn't make it high enough up on the priority list. 20130119 16:22:08< jamit> Heh. Here I thought you were going to bring up something in AI demos. :) 20130119 16:22:29< mattsc> Only _almost_ all of the time :) 20130119 16:22:51< mattsc> It links to the thread about AI Demos though ... 20130119 16:23:32< mattsc> Seriously though, maybe I should have a look at that myself and see if that can be done relatively easily 20130119 16:24:48< jamit> It should be easy, once you find the right place in the code. There should be a check for being a leader, and adding another condition based on an AI parameter should do the trick. 20130119 16:25:32< mattsc> That's what I'm hoping ... 20130119 16:25:34< jamit> The only complication I might foresee is that the leader check might be in a place where the AI parameters are not directly accessible. 20130119 16:25:50< jamit> Hmm... 20130119 16:26:36-!- Gambit [~gambit@wesnoth/developer/grickit] has quit [Remote host closed the connection] 20130119 16:27:26< jamit> I would guess it is ai/testing/ca_testing_move_to_targets.cpp, line 283. 20130119 16:28:44-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev 20130119 16:29:07< mattsc> Yeah, just checking it out myself. I want to look around quite a bit more though, to make sure that that doesn't affect other parts as well 20130119 16:29:29-!- Gambit [~gambit@wesnoth/developer/grickit] has quit [Remote host closed the connection] 20130119 16:29:59-!- cib0 [~blub@p5DD23CF1.dip.t-dialin.net] has joined #wesnoth-dev 20130119 16:30:23< jamit> Well, if you want to do things right.... :) Checking side-effects is one of the nasty things about messing with the AI code. 20130119 16:33:04< mattsc> Well, an obvious side effect is that the leader would leave the keep before he's done recruiting, but that could be made the scenario designers responsibility 20130119 16:33:27< mattsc> Well, if he has gold for more than one turn, that is. 20130119 16:34:01< mattsc> Since the MtT CA has essentially the lowest score, I hope you can just do it as simple as that. 20130119 16:34:56< mattsc> I don't have time right now though, will look into it sometime later today (unless you want to give it a shot) 20130119 16:35:11< jamit> Well, for the topic I linked to, recruiting is not an issue, since there are no keeps. 20130119 16:36:15< jamit> I'll leave it to you. 20130119 16:36:19< mattsc> And in other scenarios you can add an event that only sets the aspects after x turns, or when gold is low or ... 20130119 16:37:27< mattsc> I am actually doing something like that in Grnk - my second-favorite thing to point to :) - manually forcing the AI leader to participate in the action once he's done recruiting 20130119 16:37:57< mattsc> O, I think I'll have some time to look into this tonight 20130119 16:38:03< mattsc> s/O/Ok 20130119 16:38:11< jamit> That might be something to (later) write a macro for. A recruit/recall event to turn on "suicidal leader" when gold goes low enough, and a new_turn event to turn it off when gold is high. 20130119 16:38:49< mattsc> Sure, that's easy. 20130119 16:41:22< cib0> Leader not doing anything became painfully obvious to me when I created a map with no keeps and no villages :) 20130119 16:42:30-!- Gambit [~gambit@wesnoth/developer/grickit] has joined #wesnoth-dev 20130119 16:44:39-!- Cookie [~quassel@60-240-54-150.tpgi.com.au] has joined #wesnoth-dev 20130119 16:44:40-!- Cookie [~quassel@60-240-54-150.tpgi.com.au] has quit [Changing host] 20130119 16:44:40-!- Cookie [~quassel@unaffiliated/cookiee] has joined #wesnoth-dev 20130119 16:44:47< mattsc> cib0: yep. You can always force them to do certain things though, e,g, with leader goals or goto. 20130119 16:45:29< cib0> Good to know, I haven't done scenarios in wayyy too long 20130119 16:45:42< cib0> I think that stuff was fairly new when I last did 20130119 16:53:58< irker819> wesnoth: jamit * r56096 /trunk/src/ (unit_types.hpp unit_types.cpp): 20130119 16:53:58< irker819> wesnoth: Add a "const" qualifier to unit_type::cfg_. 20130119 16:53:59< irker819> wesnoth: This was made possible by r56095, and reduces the number of blank attributes inserted 20130119 16:53:59< irker819> wesnoth: into the config. (Almost eliminates the blank attributes in unit_type configs, but 20130119 16:54:00< irker819> wesnoth: variations still get "inherited=" inserted if it was not specified.) 20130119 17:02:37< cib0> Hm.. whom does one contact about forum related problems? 20130119 17:13:33< Cookie> shadowmaster. 20130119 17:13:43< cib0> Thanks 20130119 17:36:10-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev 20130119 17:36:52-!- Blueblaze [~Blueblaze@2602:304:cca1:4029:6233:4bff:fe0a:827b] has joined #wesnoth-dev 20130119 17:44:17-!- Blueblaze [~Blueblaze@2602:304:cca1:4029:6233:4bff:fe0a:827b] has quit [Quit: Blueblaze] 20130119 18:02:01< irker819> wesnoth: jamit * r56097 /trunk/src/ (unit_types.hpp unit_types.cpp): 20130119 18:02:01< irker819> wesnoth: Have [unit_type] variations (including [male]/[female]) inherit their parent's ID, even 20130119 18:02:02< irker819> wesnoth: if inherit=no. 20130119 18:02:02< irker819> wesnoth: If a variation is really supposed to have a blank ID, that can still be accomplished by 20130119 18:02:03< irker819> wesnoth: explicitly setting id="". 20130119 18:19:41-!- csarmi [csarmi@94-21-114-166.pool.digikabel.hu] has joined #wesnoth-dev 20130119 18:23:42-!- Alarantalara [~Adium@CPEc0c1c09e8055-CM00252eac6d62.cpe.net.cable.rogers.com] has joined #wesnoth-dev 20130119 18:25:33-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 18:48:14-!- Cookie [~quassel@unaffiliated/cookiee] has quit [Remote host closed the connection] 20130119 19:11:41-!- un214 [~un214@108.246.8.231] has joined #wesnoth-dev 20130119 19:22:05< irker819> wesnoth: jamit * r56098 /trunk/src/ (unit_types.hpp unit_types.cpp): 20130119 19:22:05< irker819> wesnoth: When logging messages about unit_types, include an indication if the type is a gendered 20130119 19:22:06< irker819> wesnoth: subtype ([male] or [female]; not directly related to gender=) and/or a [variation]. 20130119 19:22:06< irker819> wesnoth: Gender appears in parentheses; variation name in square brackets. 20130119 19:22:17-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Ping timeout: 255 seconds] 20130119 19:28:55-!- EdB [~edb@89-93-184-215.hfc.dyn.abo.bbox.fr] has joined #wesnoth-dev 20130119 19:41:23-!- EdB [~edb@89-93-184-215.hfc.dyn.abo.bbox.fr] has quit [Quit: Konversation terminated!] 20130119 19:44:11-!- EdB [~edb@89-93-184-215.hfc.dyn.abo.bbox.fr] has joined #wesnoth-dev 20130119 19:52:37< cib0> Has anybody ever encountered problems where all connections to wesnoth.org would slow down to less than 1kb/s, whereas the rest of the internet would work fine? 20130119 19:59:18-!- EdB [~edb@89-93-184-215.hfc.dyn.abo.bbox.fr] has quit [Ping timeout: 245 seconds] 20130119 19:59:28-!- EdB [~edb@89-93-184-215.hfc.dyn.abo.bbox.fr] has joined #wesnoth-dev 20130119 20:53:59-!- un214 [~un214@108.246.8.231] has quit [Remote host closed the connection] 20130119 20:57:41-!- EdB [~edb@89-93-184-215.hfc.dyn.abo.bbox.fr] has quit [Quit: Konversation terminated!] 20130119 21:01:21-!- prkc [~negusnyul@2E6BA6A7.dsl.pool.telekom.hu] has joined #wesnoth-dev 20130119 21:02:17< mattsc> jamit: as usual, it's not that simple. At the very least, we also need to disable move_leader_to_keep. Btw, what should I call the new aspect? 20130119 21:02:53< mattsc> I like suicidal_leader= , but that might be too cynical. active_leader= ? Not that it's the opposite of passive_leader= ... 20130119 21:03:12< mattsc> hyperactive_leader = :) 20130119 21:06:23< cib0> mattsc: aggressive_leader ? 20130119 21:07:49< mattsc> cib0: I thought of that (or simply using a special value for leader_aggression). The problem with that is that aggression is used in the RCA AI to parametrize attacks, whereas this is for moving toward targets. 20130119 21:09:12< mattsc> I think that active_leader describes it best, of everything I have come up with so far. 20130119 21:10:42< cib0> Yeah 20130119 21:11:41< jamit> leader_told_by_mattsc_to_kill_stuff = definitely? 20130119 21:12:32< jamit> active_leader seems appropriate, but I'm not sure if it fits given the "passive" leader attribute. 20130119 21:13:18< cib0> If it's too hard to name, the level of abstraction may not be right 20130119 21:13:30< jamit> combative_leader ? 20130119 21:13:37< cib0> I like that 20130119 21:14:04< cib0> Although.. it might again refer too much to the actual combat, as opposed to movement 20130119 21:14:33< jamit> Well, the goal is combat. If the intent was just to move, there is already a way to do that. 20130119 21:15:58< jamit> The problem with "aggressive_leader" is that it looks similar to something that affects attacking, not so much that "aggressive" is a hostile word. 20130119 21:16:09< cib0> Okay 20130119 21:16:49< cib0> Still, the fact this is so hard to name doesn't seem good :) 20130119 21:16:53< mattsc> Yeah, the connotation people might get could be wrong, rather than that the word itself is incorrect 20130119 21:16:57< jamit> It's similar to my (minor) reservation about "active_leader" -- there is a linguistic connection to an unconnected attribute. 20130119 21:17:58< mattsc> I got to run again, will check for follow-up comments later 20130119 21:20:13< jamit> Maybe something like "warleader"? Or something that implies a leader who actually leads the charge into battle, rather than sitting in a tent and giving orders? 20130119 21:21:02-!- anonymissimus [~chatzilla@HSI-KBW-078-042-163-136.hsi3.kabel-badenwuerttemberg.de] has joined #wesnoth-dev 20130119 21:23:18< anonymissimus> jamit: "multiple base units" ? really ? 20130119 21:24:34< anonymissimus> jamit: I recall that I wanted to have a base_unit which has a base_unit itself; but I somehow doubt inheriting from 2+ base units in the same unit type makes sense...and how would I specify what to take from what ? 20130119 21:24:45< AI0867> multiple inheritance 20130119 21:24:59< anonymissimus> yes, but do we need that in wml 20130119 21:25:02< AI0867> though I had to fix a bug with diamond-inheritance at some point 20130119 21:25:10< AI0867> there are usecases 20130119 21:25:21< cib0> Seeing that commit actually made me smile 20130119 21:25:28< cib0> But I'm curious as well what it'd be used for 20130119 21:30:06< shadowm> cib0: What forum problems? 20130119 21:30:17< jamit> anonymissimus: Not sure how useful it is, but it was already implemented. Just with a bug in an obscure case. 20130119 21:30:58< cib0> shadowm: Sent you a PM 20130119 21:30:59-!- Appleman1234 [~Appleman1@st0801.nas931.n-yokohama.nttpc.ne.jp] has quit [Ping timeout: 252 seconds] 20130119 21:31:06< jamit> anonymissimus: One thing you can do is define an incomplete type and use it just as a base type. But putting that into a macro might be a better idea. 20130119 21:31:41< cib0> jamit: Ah, that's interesting 20130119 21:32:03< cib0> Also, unless macros were very much optimized since a few years ago, macro's are very rarely the best idea when an alternative exists :) 20130119 21:32:18< shadowm> cib0: Downgraded to Code & WML Contributor. 20130119 21:32:24< cib0> shadowm: Thank you 20130119 21:32:42< shadowm> THe preprocessor has actually seen some optimizations throughout 1.9.x. and 1.11.x. 20130119 21:33:08< shadowm> And the internal representation of WML (a.k.a. config) was even more greatly optimized for 1.9.0. 20130119 21:33:22< shadowm> At the cost of some unfortunate regressions that haven't been properly addressed yet, of course. 20130119 21:33:59< jamit> shadowm: Which regressions are left? 20130119 21:34:09< anonymissimus> jamit: when I worked with it the last time, it was so that later attributes/tags overwrote the earlier ones 20130119 21:34:29< anonymissimus> jamit: how would I know which overwrites which if I have two base units ? 20130119 21:34:51< anonymissimus> perhaps the base unit specified later overwrites the eralier one ? 20130119 21:35:15< jamit> anonymissimus: That's where an incomplete type comes in. You could define one base type that has no image, and a second one that provides the image. 20130119 21:35:28< anonymissimus> jamit: "One thing you can do is define an incomplete type and use it just as a base type" why do I need mutiple inheritance for that ? 20130119 21:36:09< jamit> For my simplified test case, I had a [unit_type] that defined nothing but hit points. 20130119 21:36:13< cib0> If you use several base types, each contributing different things 20130119 21:36:19-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 21:36:21< shadowm> jamit: Hm. It looks like the one I was thinking of was fixed by you? 20130119 21:36:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20130119 21:36:41< shadowm> https://gna.org/bugs/index.php?19201 20130119 21:36:52< shadowm> Even though it's assigned to that j_daniel dude. 20130119 21:36:57-!- stikonas [~gentoo@bcm-128-232-247-99.girton.cam.ac.uk] has joined #wesnoth-dev 20130119 21:36:58-!- stikonas [~gentoo@bcm-128-232-247-99.girton.cam.ac.uk] has quit [Changing host] 20130119 21:36:58-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20130119 21:37:46< shadowm> There is also something else about unquoted things like name=turn $foobar being turned into "turn$foobar" or something, but I don't remember the issue number atm. 20130119 21:38:10< jamit> shadowm: Oh right. j_daniel had marked it as fixed earlier (and it wither wasn't or it rebroke), and I did not change the assignment. 20130119 21:38:16< shadowm> *is/was 20130119 21:39:11< jamit> I keep forgetting to look into those lost spaces. I should add it to a list somewhere. 20130119 21:39:24< shadowm> That kind of thing would be prime test case material, if only we had a test suite that actually worked correctly. 20130119 21:40:17< jamit> anonymissimus: I really don't know why you need multiple inheritance. It just was already there. 20130119 21:41:16< anonymissimus> shadowm: do you mean this http://gna.org/bugs/index.php?16692 ? 20130119 21:41:19-!- Iulians [050c17ad@gateway/web/freenode/ip.5.12.23.173] has joined #wesnoth-dev 20130119 21:41:30< jamit> anonymissimus: Part of the reason I fixed it up is that inheritance is now more robust against cycles. The program no longer relies on detecting cycles to avoid infinite loops. The algorithm simply cannot loop. 20130119 21:42:03-!- lipkabb [~lipk@host-91-147-212-174.biatv.hu] has joined #wesnoth-dev 20130119 21:42:22-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Read error: Connection reset by peer] 20130119 21:42:32< shadowm> anonymissimus: Apparently. 20130119 21:44:31< anonymissimus> that bug is actually 2 bugs; I at some spot said that I don't mind the original issue I reported and silene closed it; then sapient came with the other issue 20130119 21:48:34< shadowm> Why, oh why, do we still have to mention silene. 20130119 21:48:58< shadowm> That sound you hear are my teeth grinding. 20130119 21:52:09-!- Appleman1234 [~Appleman1@st0801.nas931.n-yokohama.nttpc.ne.jp] has joined #wesnoth-dev 20130119 22:00:43-!- negusnyul [~negusnyul@2E6BA6A7.dsl.pool.telekom.hu] has joined #wesnoth-dev 20130119 22:00:50-!- prkc [~negusnyul@2E6BA6A7.dsl.pool.telekom.hu] has quit [Read error: Connection reset by peer] 20130119 22:03:26-!- exciton [chuck-the-@89.208.169.104] has quit [Ping timeout: 252 seconds] 20130119 22:04:51-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev 20130119 22:05:19-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev 20130119 22:06:48-!- lipkabb is now known as lipkab 20130119 22:09:45-!- Iulians [050c17ad@gateway/web/freenode/ip.5.12.23.173] has quit [Quit: Page closed] 20130119 22:14:34-!- negusnyul is now known as prkc 20130119 22:18:19-!- trewe_ [~trewe@87.196.87.207] has joined #wesnoth-dev 20130119 22:21:23-!- trewe [~trewe@87.196.87.207] has quit [Ping timeout: 245 seconds] 20130119 22:43:33-!- lipkab [~lipk@host-91-147-212-174.biatv.hu] has quit [Quit: And away we go] 20130119 22:48:42-!- anonymissimus [~chatzilla@HSI-KBW-078-042-163-136.hsi3.kabel-badenwuerttemberg.de] has quit [Quit: ChatZilla 0.9.89 [Firefox 11.0/20120312181643]] 20130119 22:50:04-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 252 seconds] 20130119 22:51:36-!- shadowm_desktop [ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev 20130119 23:00:14-!- exciton [chuck-the-@89.208.169.104] has quit [Read error: Connection reset by peer] 20130119 23:00:28-!- exciton [chuck-the-@89.208.169.104] has joined #wesnoth-dev 20130119 23:09:12-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20130119 23:22:52-!- Arc [~arc@pysoy/developer/ArcRiley] has quit [Ping timeout: 260 seconds] 20130119 23:23:37-!- Arc [~arc@pysoy/developer/ArcRiley] has joined #wesnoth-dev 20130119 23:25:50-!- prkc [~negusnyul@2E6BA6A7.dsl.pool.telekom.hu] has quit [Quit: Konversation terminated!] 20130119 23:29:45-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!] 20130119 23:45:52-!- nejucomo [~nejucomo@gateway/tor-sasl/nejucomo] has joined #wesnoth-dev --- Log closed Sun Jan 20 00:00:03 2013