--- Log opened Sun Oct 14 00:00:46 2012
20121014 00:00:56< Alarantalara> Another way would be to work backward
20121014 00:02:24< Alarantalara> Count the number of spaces you can currently attack from
20121014 00:02:28< Alarantalara> for each unit
20121014 00:02:33< Alarantalara> of the enemy
20121014 00:04:03< Alarantalara> The thing is I don't know of any human player that calculates an exact CTK
20121014 00:04:49< mattsc> That's one reason why I thought an approximate method is probably be good enough.
20121014 00:05:17< mattsc> The other reasons being the practical ones I already mentioned.
20121014 00:05:25< Alarantalara> The other thing is that human players don't even evaluate the CTK for a lot of the attacks
20121014 00:05:59< Alarantalara> It's more a search for exposed weak units
20121014 00:07:40< Alarantalara> and then maximizing the total chance to kill for the units identifiable as possible to kill
20121014 00:08:26< mattsc> So, I identify the target first, then see how to attack it?
20121014 00:09:00< Alarantalara> More or less
20121014 00:10:16< Alarantalara> What units might you be able to kill
20121014 00:10:23< Alarantalara> Which units do you want be be dead
20121014 00:10:39< Alarantalara> Then try to kill as much as possible from the intersection
20121014 00:12:29< Alarantalara> Units you want dead are ones that can do damage on their attack disproportionate to what they receive (Mages)
20121014 00:13:05< Alarantalara> Units that block access to other units (edges of formations, units that restrict the movement of your units)
20121014 00:13:35< Alarantalara> and units on villages (since you want to capture them)
20121014 00:13:44< mattsc> Hmm.  All that makes sense.  It still leaves the question how to decide which unit we have the highest CTK on.
20121014 00:14:09< mattsc> Even if it's approximate, Fred's not very good at guessing, he wants and equation...
20121014 00:16:41< Alarantalara> Don't evaluate any enemy who has more health than the maximum damage of your best unit + 1 strike from the unit with the most strikes
20121014 00:16:56< Alarantalara> unless they can be targeted by at least 3 untis
20121014 00:17:25< mattsc> Actually, you gave me an idea of how I might be able to do this after all, but I have to think about it for a little...
20121014 00:17:31< mattsc> .. and try a few things
20121014 00:21:49< mattsc> Actually, you don't happen to know how the C++ code does this, do you
20121014 00:21:50< mattsc> ?
20121014 00:22:12< mattsc> The easiest would be if there were a C++ function that could simply be exposed to lua.
20121014 00:22:39< Alarantalara> I can certainly find the C++ code
20121014 00:24:43< Alarantalara> As a recall, it's an example of dynamic programming
20121014 00:25:10< mattsc> dynamic programming?
20121014 00:25:20< Alarantalara> Make a big table
20121014 00:25:24< Alarantalara> Fill in values
20121014 00:25:27< AI0867> mattsc: "dynamic programming" is a PR name
20121014 00:25:50< Alarantalara> As values are filled in, use them to calculate the next ones
20121014 00:26:06< AI0867> during WWII, some mathematicians had found a reasonably tractable way to calculate stuff, but the head of research was opposed to mathematical research in general
20121014 00:26:22< AI0867> so they called it "programming" (which didn't mean quite the same thing back then)
20121014 00:26:32< AI0867> and added "dynamic" because dynamic stuff is always good
20121014 00:27:13< mattsc> I see.  Thanks (to both of you).
20121014 00:27:21< AI0867> basically, you can do recursive calculations, but if many of the branches are equivalent, you're doing a lot of duplicate work
20121014 00:27:31< mattsc> I used to be young and dynamic, but these days ...  :P
20121014 00:27:32< AI0867> you can memoize it, but that still leaves some overhead
20121014 00:27:43< AI0867> dynamic programming means working from the bottom up
20121014 00:28:31< AI0867> that way you may do unnecessary calculations, but you'll only touch each point once
20121014 00:28:32< Alarantalara> The algorithm also special cases 1 strike, no CTK, and possible a few other cases that can be done more quickly
20121014 00:29:14< mattsc> ok.  well, sounds like the idea Alarantalara gave me is along those lines (although I don't claim to understand the concept well enough yet to be certain about that)
20121014 00:30:54< mattsc> It would still be nice if we could simply reuse something that exists in the code already
20121014 00:32:36< Alarantalara> Even then, I think it would be good to have something that eliminated as many evaluations as possible
20121014 00:33:12< mattsc> Agreed
20121014 00:33:59< mattsc> Btw, AI0867, some while ago you asked me something.  Did I ever answer that (whatever it was, can't remember the details right now)?
20121014 00:35:16< mattsc> Alarantalara: I assume you've come across parts of the code where I only evaluate things if the same combination has not already been evaluated.  That might help here as well, in addition to your suggestion.
20121014 00:36:11< AI0867> mattsc: I have no idea (I forgot the question)
20121014 00:37:02< mattsc> Something to do with excluding units from CAS, maybe?  Was that you?
20121014 00:38:14-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20121014 00:43:43< AI0867> doesn't ring any bells
20121014 00:44:29< mattsc> ok, never mind then.
20121014 00:44:45< mattsc> Alarantalara: So, doing 10,000x simulate_combat() of an Orcish Archer vs. and Elvish Archer take just under 2 seconds on my computer.
20121014 00:45:20< mattsc> By contrast, adding two 30-element arrays 10,000 times takes 0.03 seconds.
20121014 00:47:00< mattsc> So, I think I can simulate each attack by itself (which I do anyway), and then add defender stat tables shifted by the outcome of the previous attack for each possible outcome of that previous attack.
20121014 00:47:33< mattsc> That again won't give an exact result under all circumstances, but it should be close enough for the most part.
20121014 00:48:10< Alarantalara> You can always do the cases where the defender might die separately
20121014 00:48:52< mattsc> But for the most part, I don't think I have to.  I just have to make sure I add up the probabilities correctly.
20121014 00:49:10< Alarantalara> If the defender might die, you care about the order of the strikes
20121014 00:49:40< mattsc> That's the one case where it might make a difference.
20121014 00:50:10< Alarantalara> And of course drain make the order matter too
20121014 00:50:21< mattsc> Absolutely.
20121014 00:50:34< mattsc> But then, you have to make some approximations somewhere.  Even the C++ code does.
20121014 00:51:17< mattsc> I think that something that gives us "pretty close to the correct result" is good enough for what we need.
20121014 00:51:34< mattsc> Definitely for the time being.
20121014 00:51:40< Alarantalara> sure
20121014 00:51:56< mattsc> In fact, I think that Fred still has bigger problems even than the errors even my current method uses.
20121014 00:53:21< mattsc> I just figure I should get things right (or close to right) from the beginning, before I have to spend lots of time on refactoring later again.
20121014 00:54:36< mattsc> So I'll see if I can get that to work, and if it's fast enough, maybe I can even get the order of the attacks included, and we don't have to argue whether the one-striker should go first.  :)
20121014 00:55:10< mattsc> Thanks, that was very useful to me!  Hope it wasn't too much of a waste of time for you...
20121014 01:08:25< mattsc> Alarantalara: so I set up a test case: 2 Thunderers against a Grunt with 30 HP.  Damage for the strike if it hits: 18.  Guess what it gives me for CTK for the grunt.
20121014 01:08:38< mattsc> The current method, I mean.
20121014 01:08:56< Alarantalara> Defense of grunt?
20121014 01:09:03< mattsc> 50%
20121014 01:09:21< mattsc> Chosen to be easy.
20121014 01:09:23< Alarantalara> 0
20121014 01:09:34< mattsc> Exactly.  
20121014 01:09:54< Alarantalara> a bit off 25%
20121014 01:10:34< mattsc> Right.  Now, this is about as bad as it gets, but if we want this to work more generally, I better fix that.
20121014 01:10:57< mattsc> So I'm going to use this as the (first) test case to see if my new idea works.
20121014 01:14:14< Alarantalara> Another case for you: orc assassin on mountain (70% defense) with 12 hp
20121014 01:14:27< Alarantalara> Attack with Dark Adept followed by Walking corpse
20121014 01:15:54< mattsc> Hmm, good one.
20121014 01:15:54< Alarantalara> CTK is 59.7%, not 100%
20121014 01:16:52< mattsc> Btw, as you said, this method won't work if you have units with 'slow' attacks, but that's a special case that can quite easily be given special consideration later on.
20121014 01:17:37< mattsc> Sorry, the current method gives 100%?
20121014 01:17:38< Alarantalara> If you replace the adept with a sorcerer and the corpse with a bat, and increase the health a bit, you might even be able to get the actual CTK even lower
20121014 01:18:52< Alarantalara> Average damage is 12.6, which is more than the health of the unit
20121014 01:19:11< Alarantalara> So wouldn't it start dead?
20121014 01:19:23< mattsc> Oh, d'oh!  Yes, of course.
20121014 01:20:26< Alarantalara> I think the game actually assumes 1hp in that case so you don't actually get that result
20121014 01:23:06< Alarantalara> Though you could substitute any other high damage high % to hit followed by a low one and get similar results
20121014 01:24:39< mattsc> Hmm, I tried and I get 51%, must be doing something wrong...
20121014 01:25:00< Alarantalara> 49% DA kills
20121014 01:25:35< Alarantalara> 42% DA hits once
20121014 01:26:15< Alarantalara> 49% chance corpse misses twice
20121014 01:26:26< Alarantalara> so 51% chance corpse gets kill
20121014 01:26:51< Alarantalara> but total chance to kill is 49% + 42%*51%
20121014 01:27:16< mattsc> Sorry, I mean the test case, as currently set up, gives 51%
20121014 01:27:44< Alarantalara> Ah, it should. The game assume units with 0 hp have 1 hp before starting the battle
20121014 01:28:21< mattsc> Ah, that's what you meant earlier.  Ok, yes, that makes sense.
20121014 01:28:44< mattsc> Well, anyway, I now have both test cases set up and will see if I can get my proposed method to work better.
20121014 01:28:59< Alarantalara> Try Skeleton attacked in deep water by elvish fighter then vampire bat
20121014 01:29:17< Alarantalara> Skeleton should have 17hp
20121014 01:29:40< Alarantalara> (I think the max damage of the fighter is 16 hp)
20121014 01:31:01< mattsc> 12, in my case, because I got a quick fighter...
20121014 01:31:32< mattsc> Yes, now it's 16...
20121014 01:32:58< Alarantalara> If I got the numbers right, you should have a very high chance to kill when it's more like 60%
20121014 01:33:36< Alarantalara> And it avoids dealing with the first unit making a possible kill
20121014 01:34:20< mattsc> Test case gives 81% from the old code
20121014 01:35:13< Alarantalara> So the bat is only doing 2 damage? Good
20121014 01:35:25< mattsc> Whereas reality should be slightly below 70%
20121014 01:35:34< mattsc> yes, it is
20121014 01:36:44< mattsc> I think these are enough test cases for now.  I'll see if I can get things to work with those now...
20121014 01:37:29< Alarantalara> I hope you have some normal ones
20121014 01:47:36< Alarantalara> One extreme difference one: Two elvish fighters (not strong) attack orc grunt with 31 hp in shallow water
20121014 01:48:03< Alarantalara> CTK should be 50.3%, I expect existing function to say 81.9%
20121014 01:49:22< mattsc> Ok, will test that one too!
20121014 01:51:34< Alarantalara> Actually almost anything that generates a lot of attacks with a chance to hit other than 50% will probably get similar problems with some values due to rounding
20121014 01:51:55< Alarantalara> Elvish fighters just happen to be convenient
20121014 01:59:30< mattsc> Alarantalara: stupid Lua question: is there an easy way of setting up a lua table of, say, 30 elements containing all zeros?  Other than using a loop?
20121014 02:01:16< Alarantalara> A loop probably runs the fastest
20121014 02:01:54< Alarantalara> Though a metatable could be used if you don't expect to actually use most of the results
20121014 02:02:15< mattsc> Ok.  Actually, I probably don't even need that, as I have a sparse array and I don't need to fill in the zeros.
20121014 02:02:48< Alarantalara> If you're checking and setting to 0, then I definitely recommend a metatable
20121014 02:03:02< mattsc> So array[i] = (array[i] or 0) + new_value will probably be best
20121014 02:03:08< Alarantalara> It can replace all the nils with 0s automatically and avoid cluttering the rest of the logic
20121014 02:03:43< Alarantalara> local mt = {__index = function () return 0 end}
20121014 02:03:44< mattsc> Hmm, yeah, if I need to full array, I might go that way.
20121014 02:04:04< mattsc> *the full array
20121014 02:04:05< Alarantalara> setmetatable(my table, mt)
20121014 02:04:19< mattsc> Grr, I really need to pay more attention to my typing
20121014 02:04:23< Alarantalara> and now all elements are initially 0 at a cost for look up
20121014 02:04:52< Alarantalara> So if it's sparse, it's preferable since oyu only payf or what you use
20121014 02:04:53< mattsc> OH, that's cool!  Thanks.
20121014 02:05:25< mattsc> ... but won't that set it to zero each time I look it up, even if there's something else in it?
20121014 02:05:39< Alarantalara> No, it replaces only empy values
20121014 02:05:43< Alarantalara> *empty
20121014 02:05:52< Alarantalara> so if you set a value in the table it will stay that after
20121014 02:06:34< mattsc> Ah.  Ok.  That's the difference between somebody who knows what he's doing and somebody who doesn't.  :)
20121014 02:06:50< Alarantalara> It's basically doing what you wrote in the background
20121014 02:07:04< mattsc> yeah
20121014 02:07:57< Alarantalara> A loop is almost certainly faster if you use every element though
20121014 02:08:07< mattsc> ok
20121014 02:17:14< mattsc> Alarantalara: Woot!
20121014 02:17:19-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20121014 02:17:37< mattsc> New function gives 25% for the 2 Thunderers vs. Grunt case.
20121014 02:18:17< mattsc> It does give just a tad under 65% for the fighter/bat vs. skeleton in deep water, which is about what I expect
20121014 02:18:32< Alarantalara> Sounds good
20121014 02:18:44< mattsc> I do get 71% for the adpet/WC vs. assassin though.
20121014 02:19:05< Alarantalara> Yeah, I forgot one case when I did the math the first time
20121014 02:19:12< mattsc> I don't have time to look into whether that's my program or the calculation right now.
20121014 02:19:15< mattsc> Oh, ok.
20121014 02:19:26< mattsc> So maybe I did get it right.
20121014 02:19:31< Alarantalara> Looks like it
20121014 02:19:50< mattsc> Anyway, I'll have to head off for dinner now.  I'll clean this up and do a lot more testing later.
20121014 02:22:56< mattsc> The other thing is that I have two nested loops over the full size of the hp_chance table now (so about 1000 iterations) for each combination of 2 units.  I am sure that I can significantly cut that down though, if it turns out to take too much time.
20121014 02:23:54< Alarantalara> I hope so. Level 2 units and Woses often have 50+ health
20121014 02:24:21< mattsc> Ah, actually, not true.  I only go into the second loop if the element from the first is !=0
20121014 02:25:03< mattsc> So we're ok for most anything but 'drain', which we already know is a problem.
20121014 02:25:20< mattsc> drain vs. a berserker is particular fun!
20121014 02:25:20< Alarantalara> And slow
20121014 02:25:35< mattsc> Well, slow needs to be treated separately.
20121014 02:25:53< mattsc> I meant for computation time we should be ok for anything but drain.
20121014 02:26:13< Alarantalara> Slow has this nasty tendency of increasing the number of things to check
20121014 02:26:14< mattsc> Anyway, I'm off for some time now.  Thanks much for all your help!
20121014 02:26:28< Alarantalara> Enjoy your meal
20121014 03:27:36< mattsc> Alarantalara: haven't done anything else yet, but just tested the new code for speed.  At least for these three test cases, the changed part of attack_combo_stats() is also a factor 10 faster than the previous code.
20121014 03:27:56< mattsc> Of course, that's only about 1/3 of the total time needed for the function, but it's something.
20121014 03:28:07< Alarantalara> Indeed it is
20121014 03:28:32< mattsc> And the other part can probably be sped up by caching some results.
20121014 03:30:34< Alarantalara> I have most of what is needed to do movement between castle done now
20121014 03:31:34< Alarantalara> It finds the distance between them too far on Cynsaun Battlefield and it doesn't pick the best castles in Castle Hopping Isle, but that's about all
20121014 03:32:08< mattsc> great
20121014 03:32:20< Alarantalara> I don't expect it to ever properly switch castles in Arcanclave citadel
20121014 03:43:29< mattsc> Well, I think it would be ok to have special AIs for special (unusual) maps.
20121014 03:43:51< mattsc> That might be one use for Micro AIs
20121014 03:46:21< Alarantalara> To be honest, I have no idea how to properly play that map. There are something like 40 keeps one the map and the castle is so huge you can recruit units that are 5+ turns away from each other
20121014 03:47:08< Alarantalara> Recruiting is usually faster than moving to the destination
20121014 03:49:05< mattsc> Hmm.  I wouldn't know ...
20121014 03:50:21< Alarantalara> Try a game against Ron on it if you have half an hour
20121014 03:51:27< Alarantalara> Both AIs play the map terribly
20121014 03:58:48< mattsc> Will do.  Sometime...
20121014 04:08:34-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev
20121014 04:13:15< mattsc> Alarantalara: for the DA+WC vs. Assassin case, I calculate 71.23% by hand, which is exactly what the new code gives.
20121014 04:13:31< Alarantalara> Excellent
20121014 04:55:21< mattsc> Alarantalara: hmm, furthermore, with this method, I always seem to get the same hp_chance distribution, no matter in which order the units attack.
20121014 04:55:38< mattsc> I can probably show mathematically that that has to be that way using this method.
20121014 04:55:51< Alarantalara> If the units are significantly different in their attack, that shouldn't be true
20121014 04:56:13< mattsc> I tried a combination of WC, DA and Blood Bat.
20121014 04:56:48< mattsc> Going WC-BB-DA gives exactly the same result as DA-BB-WC
20121014 04:57:13< mattsc> That is probably where this turns out to be an approximation.
20121014 04:57:35< mattsc> I am only working with statistics, not the order in which the strikes land.
20121014 04:58:05< Alarantalara> All the examples I can think of require slow or drain so far
20121014 04:58:29< mattsc> Yeah ...
20121014 04:58:53< mattsc> We will deal with slow separately.  And for drain I suggest we just work with this approximation.
20121014 04:59:33< mattsc> WEll, maybe we'll deal with drain separately as well.  We'll see.
20121014 04:59:55< mattsc> But for now this is actually good news, because it means that we do not need to go through all the iterations.
20121014 05:00:47< mattsc> And that we can decide to go with the highest-variance hitter first, as you suggested.  Or alternatively, the unit which, by itself, has the highest non-zero CTK.
20121014 05:01:44< Alarantalara> I'd do both - start with the highest non-0 CTK, and if none exist go with the highest variance
20121014 05:02:29< Alarantalara> There is one thing I'd note
20121014 05:02:33< mattsc> Makes sense.  Or maybe the unit which gets the lowest individual HP chance for the enemy?
20121014 05:02:37< mattsc> yes?
20121014 05:02:59< Alarantalara> Some units have multiple attacks with differing variance
20121014 05:04:02< Alarantalara> Sometimes the higher variance one will have a higher chance to kill, but the lower one will give a higher chance when combined with a second unit (since if high variance fails, you have to start from scratch, whereas the low variance is less likely to fail completely)
20121014 05:04:28< mattsc> True.  So far I am actually simply using the attack that the code suggests as the "best weapon"
20121014 05:04:39< mattsc> Hmm...
20121014 05:04:46< Alarantalara> Which will usually give the high variance option
20121014 05:05:06< mattsc> It will usually give the highest-damage option.
20121014 05:05:13< mattsc> I'm not sure if that is the same.
20121014 05:05:19< Alarantalara> If there's a CTK it won't
20121014 05:05:47< Alarantalara> Orc Archers vs Skeletons is a common case
20121014 05:05:57< mattsc> Yes, granted.  (I was counting a kill as "really high damage")
20121014 05:06:10-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20121014 05:06:30< Alarantalara> They can even do the same damage and it will pick the high variance one
20121014 05:06:46< mattsc> true
20121014 05:06:50< Alarantalara> 18 health orc vs orc archer, ad it will try the fire arrow
20121014 05:08:06< Alarantalara> If you use best attack from the game, grunt then archer picks different weapons than archer then grunt
20121014 05:08:20< Alarantalara> when the target has 13 or so hp
20121014 05:08:31< mattsc> So, any suggestions how to deal with that?
20121014 05:09:27< Alarantalara> First, if you stay with best weapon for now, make sure you record what it is, because it may not match when you make the attack if you don't revealuate
20121014 05:10:30< mattsc> Mhm.  I'm actually thinking that I should re-evaluate.  (I don't currently, but already came up with that idea)
20121014 05:11:11-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev
20121014 05:13:35< Alarantalara> It would be nice to run all possible weapons, but multiple units' attacks could get expensiev to calculate then
20121014 05:14:58< Alarantalara> It might still be worth it — watch the best weapon of a mage vs a dark adept when the mage has about 5 hp
20121014 05:14:59< mattsc> Yeah, and that would really mean simulating them all, so that takes quite a bit of time.
20121014 05:15:45< mattsc> staff - makes sense
20121014 05:16:08< Alarantalara> Though in that case, the weapon will switch if you reevaluate after the adpet has taken enough damage
20121014 05:16:46< mattsc> yeah - but wouldn't you want it to switch in that case?
20121014 05:16:52< Alarantalara> Yes
20121014 05:17:08< mattsc> Oh, you mean for the expected damage calculation...
20121014 05:17:45< Alarantalara> But it is a good example of high variance in the initial attack (1 strike) and suddenly not after the gamestate changes
20121014 05:18:02< mattsc> Right
20121014 05:18:23< mattsc> So we reevaluate after each attack, not just after each attack combination.
20121014 05:18:51< mattsc> Btw, I wouldn't want to attack with the 5 HP mage anyway but retreat him to safety, but that's a technicality.  I see your point.
20121014 05:19:15< Alarantalara> And we need to avoid high variance attacks if the unit could do more damage to another unit
20121014 05:19:22< Alarantalara> or with a different attack
20121014 05:20:37< mattsc> So how about this: we choose the best attack combination based on overall highest CTK (well, plus damage taken, exposure, etc.)
20121014 05:20:53< mattsc> Within that combo, we choose the order of attacks based on the criteria mentioned above
20121014 05:21:02< mattsc> And we reevaluate after each individual attack
20121014 05:21:16< mattsc> Does that sound good enough for the time being?
20121014 05:21:21< Alarantalara> It's a good start
20121014 05:21:36< mattsc> Ok, let me do that and we'll just see how it does.
20121014 05:22:11< mattsc> I'm taking off early tomorrow morning and will be traveling until next Saturday.  It's one of those trips on which I might have some time for coding, or not at all.
20121014 05:22:31< Alarantalara> The other thing that would be nice would be trying to use units with fewer options first
20121014 05:23:04< Alarantalara> If I have a mage that can only attack one unit
20121014 05:23:25< Alarantalara> then I want to do that before evaluating the CTK if I think the end location is safe
20121014 05:23:42< mattsc> I see what you're saying...
20121014 05:24:36< Alarantalara> That's part of why I mentioned the "want to kill" set earlier
20121014 05:25:15-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20121014 05:25:25< Alarantalara> Identifying units that would be good to kill could be done separately
20121014 05:26:07< Alarantalara> And trying to kill the units on that list first, even if the CTK is slightly lower, would be useful
20121014 05:28:03< Alarantalara> "want to kill" should include units that pin my units and units in places we want to be (villages)
20121014 05:29:48< mattsc> There is a separate 'attack_weak_units' CA.  Maybe that could be tweaked for that purpose?
20121014 05:30:12< Alarantalara> I don't think so, since they're not necessarily weak
20121014 05:30:35< Alarantalara> They may be stronger units, but ones which represent greater value for killing
20121014 05:31:57< Alarantalara> For instance, if I had a 60% CTK a unit in a village and still have a unit to capture it after, I would probably try for that over a 70% CTK on the unit beside it
20121014 05:32:02< mattsc> What I meant is: generalize that CA from "attack weak units" to "attack units we want to get rid of".  Which would include both weak units and those you are talking about.
20121014 05:32:43< Alarantalara> Doesn't that get rid of the 1-hit kill targets?
20121014 05:33:19< mattsc> You mean in its current state?
20121014 05:33:36< mattsc> IIRC, it attacks if there's a >xx% CTK.
20121014 05:34:08< Alarantalara> A slowed 1hp walking corpse is weak, but at the same time, I really don't need to attack it
20121014 05:34:34< mattsc> Right, but that CA currently would.
20121014 05:35:22< mattsc> Actually, I think that all the attack CAs should be bundled anyway and given some sort of "central supervisor" that makes decisions like that.
20121014 05:36:26< Alarantalara> Would that include the leader?
20121014 05:37:08< mattsc> Without having thought it all the way through: yes
20121014 05:38:10< Alarantalara> I suppose that would work out as long as there was a higher priority CA that could reclaim the leader if it were needed for something else
20121014 05:38:34< mattsc> Like what?
20121014 05:38:39< Alarantalara> recruiting
20121014 05:39:15< mattsc> Ah, yes, recruiting will always be done before the leader is moved off the keep.  I'm doing that already and it will not change.
20121014 05:39:18< Alarantalara> for that matter retreating to heal, since its threshold should be much higher and more unconditional
20121014 05:39:52< Alarantalara> There's nothing wrong with attacking with badly injured units if you can get rid of all the opposition or advance enough that they get covered
20121014 05:39:54< mattsc> The threshold to use the leader for anything but recruiting is much higher than for other units.
20121014 05:40:29< mattsc> agreed.
20121014 05:40:58< mattsc> I get the feeling that we're really thinking about these things along the same lines.  The problem is how to do this in practive.
20121014 05:40:59< Alarantalara> That's the thing — it's also among the best offensive units you have and can usually survive a turn in the front line
20121014 05:41:28< mattsc> Right.  So that's the threshold.  If the worst happens and you have 1HP left, that's ok.
20121014 05:41:39< Alarantalara> If the enemy gets close and you have a reasonable number of units, you want to go out to attack
20121014 05:43:18< mattsc> As I said, we really seem to have pretty much the same goals in mind.
20121014 05:43:36< Alarantalara> I guess I see the CA being more complicated if it has logic to use the leader specially
20121014 05:45:03< mattsc> But you do need to use the leader somewhat differently from the other units.
20121014 05:45:13< Alarantalara> Unless there was a general "keep safe" option
20121014 05:45:22< mattsc> And whether you do that in one CA or two is not really a different.
20121014 05:45:29< mattsc> Or maybe I don't get what you're saying.
20121014 05:46:37< Alarantalara> In addition to the leader, there are also other units you would prefer are protected at the end of the attack
20121014 05:46:57< Alarantalara> it might make sense to mark them and handle them all the same
20121014 05:48:36< Alarantalara> I guess what I was trying to say is that there are more competing options for the leader
20121014 05:49:03< Alarantalara> It may make sense to evaluate all those options before assigning the leader to the attack
20121014 05:49:38< Alarantalara> It may be better to not recruit a unit and instead attack to get a unit there a turn earlier
20121014 05:50:12< Alarantalara> But that means the recruit vs attack decision needs to be made before attacking
20121014 05:51:11< Alarantalara> But if you want to recruit and could attack, recruiting last means that you have to make sure the attack CA knows not to use the leader
20121014 05:51:31< Alarantalara> And it seems to me to make more sense to not have all that logic in the attack CA
20121014 05:52:19< Alarantalara> Once we're advancing/attacking, treat it like any important unit, but make sure that it can be spared separately
20121014 05:52:57< Alarantalara> Does that make more sense?
20121014 05:53:15< mattsc> All of it except one thing.
20121014 05:53:50< mattsc> Why that means that the logic should not be in the same CA.  In fact, it sounds to me like that's an argument for that.
20121014 05:54:11< mattsc> What I have been doing, in fact, is get rid of CAs and centralize more and more of those decisions.
20121014 05:54:38< mattsc> But that's really just "semantics", almost.
20121014 05:54:51< Alarantalara> The problem is that it can get massive enough that it is hard to follow
20121014 05:55:21< mattsc> It's not any different than with individual CAs.
20121014 05:55:35< mattsc> Attack, hold position, recruit, etc. is still in separate functions.
20121014 05:55:53< mattsc> Just that I am doing the "central control" myself, rather than letting the CA system do it.
20121014 05:56:23< Alarantalara> So recruiting would end up in it too?
20121014 05:56:53< mattsc> It could.  In fact, there is one instance where it is already.  Let me just show you...
20121014 06:00:18< mattsc> Hmm, thought I had something like that.  Can't find it right now.  Maybe I got rid of it again or maybe I am thinking about something else.
20121014 06:00:54< mattsc> Anyway, I need to move on to other things, since I am leaving early tomorrow morning.
20121014 06:01:12< Alarantalara> Alright. Part of it is that I get worried by 200 line functions
20121014 06:01:43< mattsc> In my mind, there isn't really a difference between using "normal CAs", and doing the supervisor myself, which gives me somewhat more control over things like:
20121014 06:02:44< mattsc> "Normally I do X first, unless if Y is the case, in which case Z comes first and then I do something completely different"
20121014 06:04:02< mattsc> A lot of that is interconnected and the evaluation of CA 1 depends on the evaluation of CA 2 as well.  Which is easier to do if all that evaluation is done inside the same function.  Or at least if it is controlled by the same function.
20121014 06:05:07< Alarantalara> I guess I rather liked your earlier design for the stats
20121014 06:05:30< Alarantalara> It felt like you had started with high level decisions
20121014 06:05:44< Alarantalara> then other CAs got to decide what to do with them
20121014 06:06:26< mattsc> That won't change.
20121014 06:08:01< mattsc> Really all I am saying is that I am doing the CA selector myself as well.  Which gives me more flexibility.
20121014 06:10:02< mattsc> Look at this example:
20121014 06:10:39< mattsc> I have 4 CAs: A, B, C, D.  Usually, I want to executed them in that order.
20121014 06:11:25< mattsc> However, sometimes, if the eval of A produces a certain result, _and_ the eval of D produces a certain result, I want to change the order to BCDA.
20121014 06:11:51< mattsc> In order to make that decision, I need to have the eval result of both A and D available.  
20121014 06:12:30< mattsc> However, by the time I evaluate the second of those two, the score for the first is already set - and possible the score for B and C, since the evaluation order is not guaranteed.
20121014 06:13:03< mattsc> Situations like that are relatively frequent when you start talking to people like skyfaller.
20121014 06:13:19< Alarantalara> True
20121014 06:14:46< mattsc> Thus, instead of having A return  just a score, I have it return a score and a flag.
20121014 06:15:20< mattsc> If both the score and the flag are set, I wait with execution until I have D evaluated also.
20121014 06:15:35< mattsc> But that isn't possible if all of those are separate and distinct CAs.
20121014 06:16:31< Alarantalara> It wouldn't be as much of a problem if CAs were not blacklisted
20121014 06:17:13< mattsc> yes - I've discussed that with Crab, in fact.
20121014 06:17:24< Alarantalara> Since then A could detect the flag, do nothing, and report a different score next time
20121014 06:17:53< Alarantalara> I can see the desire to avoid infinite loops, though
20121014 06:18:54< mattsc> Right.
20121014 06:22:03< mattsc> So let me try it the way I am thinking about.  I promise I won't do it so that we cannot switch back reasonably easily.
20121014 06:22:20< Alarantalara> Fine with me
20121014 06:22:37< mattsc> But I have hit several limitations of things that I just could not do (at least not easily and elegantly) by only using the "normal" CA system.
20121014 06:23:00< mattsc> And I think I will be able to do them this way.
20121014 06:28:36< mattsc> Ok, I'm off then.  I'll be online sporadically throughout the next week.  Thanks again!
20121014 06:28:54< Alarantalara> Alright, good night
20121014 06:29:02< mattsc> ttyl
20121014 06:33:38-!- esr [~chatzilla@wesnoth/developer/esr] has quit [Quit: ChatZilla 0.9.89 [Firefox 16.0/20121006022900]]
20121014 06:34:55-!- esr [~chatzilla@static-71-162-243-5.phlapa.fios.verizon.net] has joined #wesnoth-umc-dev
20121014 06:35:21-!- esr [~chatzilla@static-71-162-243-5.phlapa.fios.verizon.net] has quit [Changing host]
20121014 06:35:21-!- esr [~chatzilla@wesnoth/developer/esr] has joined #wesnoth-umc-dev
20121014 07:04:41< mattsc> Alarantalara: still around?
20121014 07:08:35-!- mattsc [~mattsc@d154-20-32-241.bchsia.telus.net] has quit [Quit: bye]
20121014 07:18:49-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-umc-dev
20121014 09:21:00-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-umc-dev
20121014 11:10:22-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20121014 12:36:06-!- skyfaller_ [~skyfaller@ool-43551e75.dyn.optonline.net] has joined #wesnoth-umc-dev
20121014 12:36:06-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Read error: Connection reset by peer]
20121014 13:55:07-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev
20121014 14:11:03-!- loonybot [~loonybot@ppp79-139-205-247.pppoe.spdop.ru] has joined #wesnoth-umc-dev
20121014 14:11:04-!- loonybot [~loonybot@ppp79-139-205-247.pppoe.spdop.ru] has quit [Changing host]
20121014 14:11:04-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-umc-dev
20121014 14:11:06-!- mode/#wesnoth-umc-dev [+v loonybot] by ChanServ
20121014 14:40:02-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20121014 17:08:19-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Ping timeout: 260 seconds]
20121014 17:28:30-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev
20121014 18:09:26-!- vultraz [~chatzilla@124.109.10.167] has quit [Read error: Connection reset by peer]
20121014 20:03:19-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-umc-dev
20121014 20:35:16-!- zookeeper2 [~lmsnie@87-100-211-108.bb.dnainternet.fi] has joined #wesnoth-umc-dev
20121014 20:36:43-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 246 seconds]
20121014 20:52:54-!- zookeeper2 is now known as zookeeper
20121014 20:52:59-!- zookeeper [~lmsnie@87-100-211-108.bb.dnainternet.fi] has quit [Changing host]
20121014 20:52:59-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-umc-dev
20121014 21:24:12-!- irker797 [~irker@ai0867.net] has joined #wesnoth-umc-dev
20121014 21:24:12< irker797> wesnoth-umc-dev: doofus-01 * r16074 /trunk/Tales_of_the_Setting_Sun/ (22 files in 5 dirs):
20121014 21:24:12< irker797> updating to run on BfW 1.11.0 from now on.
20121014 21:27:48-!- skyfaller_ is now known as skyfaller
20121014 21:27:49-!- skyfaller [~skyfaller@ool-43551e75.dyn.optonline.net] has quit [Changing host]
20121014 21:27:49-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-umc-dev
20121014 21:43:37-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20121014 21:43:37-!- vultraz [~chatzilla@unaffiliated/vultraz] has joined #wesnoth-umc-dev
20121014 22:56:19-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20121014 23:00:01-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 245 seconds]
20121014 23:07:49-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-umc-dev
20121014 23:50:15-!- Alarantalara [~Adium@173.33.158.188] has quit [Quit: Leaving.]
--- Log closed Mon Oct 15 00:00:51 2012