This should be in the Bug section.
Printable View
This should be in the Bug section.
While I do agree that dragons can be, well, moronic, in attacks sometimes, that is usually due to the placement of the buildings and where you place the dragons down. Besides, they don't have a specific favorite target so they are going to go wherever they please.
Already been reported. I'm pretty sure I said that already much, much, earlier.
You are missing the point.
It is hard to explain the magnitude of this in words. There are normal 'mornic' actions by troops, and there is '♥♥♥ why?! How?!' actions by troops. We are talking about the latter, where things are just in the absurd and totaly unpredictable, and effectively gameplay ruining at random times.
Just read the whole thread, or the improvement stuff as best you can, and you'll see what we are talking about. This isn't some noob being a moron, this is an uncommon, but spectacular, AI glitch in troops.
Know your AI and how it works no change needed.
As I said in the other thread, I would like to get someone to video this, especially my attack with the MVP dragon killing (cowardly) barbarian, before things clear from the clan's war log.
Yet another one that saw the first page and ASsumed they knew exactly what the thread was about? Or just another person that thinks they are helping by putting thier unhelpful 2¢ in?
If you didn't read, there is a reason why you should read most of a thread. If you didn't, you need to make some effort before just spamming such a comment.
I know it is human nature to 'jab' someone with advice, but after awhile of seeing it, it just has to be pointed out so one less person goes around doing it. I don't, it might start something here, and may get others to follow suit.
This is what I was talking about in my other thread, not the aggro radius that's being discussed here. But since it's all about dragons...
I've been on the fence about the aggro radius (again, which is separate from my other argument). I see both sides - it can help or hurt, but one thing is clear - it needs to be consistent. The more attacks I watch, the more I believe the radius being too large. Success with dragons is in keeping them in 2-3 groups. When aggro pulls them all apart, they are worthless. It's the same principle of a good gowipe. You don't want your pekka's and wizards wandering off, nor do you want your dragons wandering off. Could you imagine the rage that would ensue if hogs split 5 ways after their first defensive building?
Frankly, the apparently "updated" random aspect to AI is out of control with dragons. The smaller the base being attacked, the less noticeable it is. But when attacking a TH9 the sheer number of buildings will frustrate you because you can no longer focus your attacks because you can no longer count on them to attack the next closet building, which is how they are supposed to work. It's not a matter of skill anymore, it's sheer dumb luck, and most of the time, you don't even get that. I know my dragons and know/knew how to use them with surgical precision. It's similar to the archer queen shooting at walls when she could walk through a hole 4 tiles away or when she approaches 3 defensive structures and a storage and the storage always seems to be the best choice.
If you don't believe me, keep watching those attacks. You'll see it.
Far as I can tell, it is constant, just constantly impractical to plan around.
- Defence troops come in
- Normal expected aggro radius kicks in
- Attack troops charge after
- Attack troops usually dispatches defence troops
- New defence troops come into play
- Any attack troops that directly engaged in troops before now rush towards different Defence Troops within a rarely known aggro raduis (12 tiles or more?)
The two questions I have with this whole mess is...
- Why is there even a 12 or more tile radius relating to aggro? (assuming there is a limit)
- Why does the 'stop and attack troops' priority stay locked in place, even when no troops on the field currently?
That is the problem I see in the core AI used by most troops. Reason why the heavy hitting troops, like Dragons, Barbarian Kings, P.E.K.K.A.s and the like demonstrate this often, is because they are more likely to engage defence troops, and live, and then hold onto that locked into attack priority.
I'm willing to bet that most, if not all, cases where a troop singlemindly goes towards defence troops (including skeletons), is because they already took out troops before hand, and are locked into hunting and killing more troops.
Hmm, when I think about dragons, this behavior seems counter-productive. But when you think about it from the point of view of barching, you would want your troops to finish off all the enemy troops (within a reasonable radius) before continuing their assault. Otherwise, they'd constant be switching back and forth between attacking buildings and attacking troops, which would waste a lot of time and lead to more attrition of your troops. Since all the AI in this game seems to boil down to what archers and barbs do (with a few exceptions, like the valkyrie), it makes a little more sense why the dragons are doing this. The 12-13 tile aggro radius is pretty ridiculous though. I'm not sure how that's at all useful. It's as big as the CC lure radius, which might be helpful for pulling your troops in. But the 12-tile radius only seems to kick in after your troops get a taste for blood, as you mentioned. Before that, the aggro radius is a much more reasonable 5-8 tiles. I'll try to pay more attention and see if I can pin down the aggro radius for non-bloodthirsty troops.
For 'first contact' aggro, it is usually ignored (aka 0 radius) until hit. Then what seems to happen is that the from point of first contact, a trigger is sent to the surrounding troops, about 4-5 tiles radius, to attack enemy troops.
Programing wise , this is likely just a blanket priority action to drop any current actions and retarget to nearest enemy troop. Given there are limited numbers of sources for troops, there is no need for extra code to say to attack the source of the trigger, since there is only so many troops in a limited radius from first contact, and if it is a mob of troops, attacking closest is best anyway.
Also programing wise, there normally is no need to turn off the check for troops for that unit, given how there are very limited amount of troops on a given base. Why add extra rules to see if it needs to be turned off, when it is easier to waste some processing time on checking what normally isn't there anymore, than use even more processing time to try figure out when to turn it off to save a little bit of processing time?
Most cases, this shortcuts and cutting corners works; CC troops normally all deploy, tier 1 troops that took out CC troops usually don't last long anyway, and is a moot point to do such 'logic cleanup', which means any new troops that show up to defend cause the same reaction to the fresher attack troops, and everything runs fine.
Reason why people rarely see the glitch we are talking about is because a set of conditions have to be met, and I already gave those in an earlier post. Which means most mass dragon attackers rarely see problems since the defender's troops and skeleton traps usually deploy in a way that doesn't cause any problems. But when they do, utter stupidity happens.
I am questioning if there even is a range limit on 'bloodthirsty' aggro. 12 has been a stated limit, by a replay on an attack on my war base seems to show 13 tiles. I'm willing to bet there is no check, since that would be another rule in the AI actions, and why do a distance check if you are the programer writing code for troop interactions that would only trigger once, and in short distances?
Well, mix of air and ground-only attacking units in a CC, with an attacker with mixed air and ground units, or just the use of skeleton traps, have cause these coding shortcuts to be an issue from time to time.
This also makes me wonder, if this has always been coded like this, but not apparent until recently, why are we talking about it after the clan perk update? This would have been a rare issue early on, but even more of an issue once skeleton traps were introduced.
Guess it took this long for the issue to be accidentally posted here in the wrong forum.
Still need someone to video record the silly incident that shows this glitch rather clearly.