ArenaNet talk:AI bugs/unresolvable

Control Panel issues

Hero Control Panel -- Button to drop ashes unavailable

Issue: A hero carrying ashes who is outside of radar range of the player can't be ordered to drop them since the "drop ashes" button reverts to the regular target lock.
How to fix: Fix the bug causing this problem.
Additional info: none

--Draikin 17:07, 26 January 2008 (UTC)

This issue has been reported. I will update when more information is available. Ben Kirsch 22:24, 28 January 2008 (UTC)

Unfortunately this is a limitation of the system. Once Heroes have gone outside radar range the amount of precision in their control drops.--Mike Zadorojny 00:56, 25 July 2008 (UTC)

I assume that means this issue can't be resolved? --Draikin 16:04, 25 July 2008 (UTC)

I'll archive this as unresolvable. --Draikin 18:35, 3 January 2009 (UTC)

Hero Control Panel -- AI losing target lock when outside of radar range

Issue: When a hero is in about 1.3 times aggro range from their locked target, moving your own character out of radar range from that target will cause the hero target lock name to revert to “(Unknown)”, but the hero will in fact remain locked onto their target and continue to attack it. When you come back into radar range of the target, the hero target lock name will display the correct name again. However if you move your own character out of radar range from the target and the hero is also at considerable distance (more than 1.3 times aggro range) from that target when this happens, the hero target lock will be removed altogether. This means the hero will no longer focus attacks on that target.
How to fix: Fix the hero target lock so that it is never canceled when you walk out of range of the target, regardless of the distance between the hero and that target.
Additional info: none

--Draikin 12:52, 14 March 2008 (UTC)

This is intended behavior. If both you and your hero are well outside of Aggro range of a target, that target should indeed be "lost" until you get back in range and target them again. --Andrew Patrick 22:41, 14 May 2008 (UTC)

Hi Andrew. I'd like to add that this behavior, even if it's intended, has a negative impact on gameplay in Hero Battles where heroes often fight outside of radar range and losing a target lock can mean the difference between a win or loss. Taking control away from the player when your heroes are out of range is never a good thing, especially in a format where controlling your heroes means everything. --Draikin 23:33, 14 May 2008 (UTC)

I'll archive this, there are more important issues. --Draikin 18:35, 3 January 2009 (UTC)

Hero Control Panel -- Inconsistent response to interrupted skills

Issue: As I've mentioned in a different report, when you manually click a skill on the Hero Control Panel and the hero gets interrupted while trying to use it, the green check mark will remain on that skill and the hero will not use any other skills until it is recharged. If this is actually intended behavior like QA reported, then this means there's another issue (which was actually introduced after a recent AI update): when the green check mark is not displayed after manually ordering a hero to use a skill (this will always happen with heroes who are idle, and even occasionally when they're not idle) and the hero gets interrupted, the green check mark won't appear and the hero will be free to use other skills. This can be easily verified by letting a hero maintain Shadow Meld on you, ordering it to use Meteor Shower and then canceling Shadow Meld. This is basically a side-effect of another inconsistency I've reported before: once a skill has been queued for activation (and the green check mark is shown), it will remain on the skill icon even during skill activation. On the other hand when the skill is executed immediately, it will not display the green check mark at all. So to summarize there are two possible outcomes after ordering the hero to use a skill:

• The hero activates the skill instantly without any delay: the green check mark is not displayed during skill activation and if the hero is interrupted, it doesn't try to use the skill later on but simply continues using its other skills.
• The hero queues the skill and a green check mark is displayed, showing that they can't use the skill instantly but will execute it as soon as they can: when the hero starts activating the skill, the green check mark is not removed, which is a first inconsistency with the previous example. The second inconsistency is that, if the hero is interrupted, the green check mark remains and the hero will not use any other skills until it can activate the interrupted skill again.

Now I've already explained why I think the first behavior (activation without delay) should be the default one: it clearly uses the green check mark to show that skills are queued and disappears during skill activation, and heroes will resume normal skill usage after interruption instead of being completely shut down. Now regardless of what ArenaNet considers to be the intended behavior, what I described above shows that there's still an issue with the way heroes respond to getting manually ordered skills interrupted.
How to fix: Update the Hero Control Panel so that the reaction to interrupted skills is always the same.
Additional info: I'll be trying to get more opinions from the community regarding what should be the default AI reaction to interrupted skills and update the issue accordingly.

--Draikin 14:59, 19 July 2008 (UTC)

The Hero AI acts on a poll that is taken about once every second which is why you end up seeing two different behaviors. If you order a Hero to perform an action relatively close to the pulse you’ll witness an almost immediate response from them. Conversely if you order a Hero just after the pulse the resulting action will be slightly delayed until the next time the server polls for queued actions. This is a limitation of our system as polling too frequently increases the workload on the servers.

Regarding Heroes becoming entirely focused on manually ordered skills to the point of ignoring all other available skills, this is the designed behavior. In your example using skill interruption if the Hero is free to use other skills while waiting for the ordered skill to recharge it is possible for them to get into situations where they are no longer able to use the ordered skill. For example, if the Hero is interrupted while casting an ordered use of Meteor Shower but while they wait for the recharge they continually cast lower energy skills it is possible for them to be in a situation where they don’t have enough energy to cast it. It would also be possible for the AI to choose to cast spells which take it out of range of the original target. The general design philosophy on Hero AI was to make it as simple as possible, hopefully making it easier to understand and easier to use. The trade off is that there are some limitations to the system, but in this case, you could just override the order to use the skill once they’ve become interrupted and they’ll return to normal.--Mike Zadorojny 00:52, 25 July 2008 (UTC)

In PvE it might not matter that you have to override the skill, but in Hero Battles having to notice the interrupt and uncheck the skill simply to make your hero respond again is far from ideal. It's my opinion that if a hero uses a skill and it's interrupted, the hero followed my order correctly and should return to normal. To clarify, I don't want them to use their other skills while the check mark on a skill is active, I'd simply remove he check mark altogether and let the hero return to normal. That said, regardless of whether or not the current behavior is optimal, what I posted here is basically a bug. After the recent AI update, the hero AI doesn't act on a poll when the heroes are idle (standing still, not using skills, not in battle) but activate skills instantly. In that particular case the check mark is not displayed and ironically they react to interrupts the way I would want them to: they simply return to normal. Since the check mark was never there they aren't shut down in an attempt to use the skill again after it's recharged. So if the current behavior (try to use the skill again after being interrupted) is intended, then what I described above is a bug. A bug which I would prefer to see as the intended behavior, but a bug nonetheless. I changed the icon for this issue since the response actually seemed to be directed at this topic: ArenaNet talk:AI bugs#Hero Control Panel -- Interrupted skills. Feel free to change it back to if this isn't going to be solved. --Draikin 16:04, 25 July 2008 (UTC)

To clarify again: the solution to this bug would be to let the check mark be displayed on skills even when the AI activates them instantly. That way if they're interrupted, they'll stop using skills and wait for the skill to recharge which is the currently intended behavior. Alternatively, the bug could be made the default behavior. --Draikin 16:11, 25 July 2008 (UTC)

There seems to be a bit off miscommunication here so let me see if I can clear it up.

1) There is never a time in which Hero's don't pull, this is actually how all AI works in our game, and it would be difficult to change that even if we wanted to.

2) The check box remaining after interruption is the intended design, the check box is telling a Hero to use this skill next time you can, if it get interrupted disabled, or messed up, it's your job to remove the check box, coming up with rules of when the check box gets removed and when it doesn't adds to the general confusion, when the check box goes aways a player currently knows the skill have executed. In anycase, this is by design and is not likely to change.

3) You talk about a bug a few times in there, but I think we are a bit confused and don't understand which bug your referring to could you clarify which bug your referring too?

Thanks for your feedback! Izzy @-'---- 18:55, 25 July 2008 (UTC)

I explained the issue to Izzy ingame, here's a more detailed example that anyone can reproduce: bring an E/A hero with Shadow Meld, Meteor Shower and Flare to the Isle of the Nameless and disable Shadow Meld and Meteor Shower. Go nearby a target and let the hero use Shadow Meld on your character. Notice that the skill is activated instantly and without showing a check mark. Now target a practice target (don't target lock the hero) and click Meteor Shower. The hero will start to use the skill. Now call the target, which will basically activate "battle mode" on your heroes. This is needed otherwise the hero won't continue to attack the target after the following step: while your hero is still casting Meteor Shower, cancel Shadow Meld. This will interrupt your hero. Now normally there should be a check mark on the skill and he should be waiting to use Meteor Shower again after it's recharged. But because the skill was activated instantly the check isn't there, so you'll notice that the hero will start using Flare immediately after the interrupt. I hope that explains it. Thanks again to everyone here for taking the time to look into these issues, I hope I'm not being too annoying :)

--Draikin 21:26, 25 July 2008 (UTC)

Hahaha, Izzy came by and explained things after he talked with you. With that example, it's a lot more clear. Izzy's working with someone to figure out why that is and if it's something we can adjust easily.

As I've said on your user page, we really appriciate how much time and research you've put into these issues. I know what it's like as a game player to have something stand out to you as just a glaring wrong because it's something you have to work with (or around) so many hours of your life. So I understand how you can get a little exhuberant. Thank you so much for all of the reports you've given and are continuing to give. -Kim Chase 23:10, 28 July 2008 (UTC)

I guess I'll archive it as unresolvable, it's a minor issue anyway. --Draikin 18:35, 3 January 2009 (UTC)

<Ally> -- <Karei>

Issue: <He got stuck in a Canthan chest after I defeated his bound form and thus I could not move to the next boss>
How to fix: <Please check out the spawning of Kahrei, the chests, or both>
Additional info: <This is in the mission Tahnnakai Temple>

71.181.128.83 21:15, 27 June 2009 (UTC)Falling Needles

Flagging and Movement Issues

Heroes & henches -- Heroes running in lava

→ moved from User talk:Gaile Gray

I'm just wondering if there's any particular reason why henchmen and heroes alike seem to think that standing in lava while fighting is a good idea? No matter if you direct them elsewhere, they'll just happy smash the enemy while burning to death... It's reasonably annoying. I first noticed this back when Prophecies was just released and Mhenlo cost me one of the Ring of Fire missions because he just kept walking around in lava instead of resurrecting :/. Do they like the smell of burning flesh? It makes me a sad panda anyway :(. If you could light a fire under the AI guys sometimes, I think they might get some new insights into the situation ;).

Excellent point. I've noticed my group also seems to have a real taste of foot warmers. I'll pass this along, but I think I need to add a new Special Pages for AI issues.... Let me do that now. Thanks! --Gaile 22:12, 1 September 2007 (UTC)

Thanks :). I wasn't sure where exactly to put it. That being said, it took me 4 hours, but in the end me and my 60%DP henchies did manage to kill that nasty Ilsundur, Lord of Fire. Determination pays off, I guess. Thanks for taking note :)

This behavior is not specific to lava. They also love to stand in those flame and ice jets that you find in dungeons. --Ronduwil 06:57, 5 January 2008 (UTC)

Well, I wouldn't say that heroes prefer to be in lava (or flame traps) but they don't seem to mind it too much. Unfortunately we are not expecting to change this behavior at this time. Personally, I thanked the day that Nightfall came out and we were given the ability to flag henchmen. I mean, sometimes you need to run through lava or some other danger, and flagging is the only thing that gives you the control to make that command decision between

Stay Away!" and "Run through really fast!" Now I can't imagine going through Ring of Fire Isles without it. -Kim Chase 00:31, 10 July 2008 (UTC)

Player Characters -- Character

Issue: When clicking on a destination for the Player Character, many times the Character does not find a path to the destination, instead they walk into walls, edges of cliffs, structures, trees, etc..
How to fix: Bring pathing functionality to level of previous installments of guild Wars
Additional info: none

One specific pathing issue I come across regularly is in the Warrior's Isle Guild Hall. When on the middle level, such as near the Storage, and clicking on the Rare Materials Trader, my character will run down the stairs and to the Materials Trader, presumably with the intent to go between the crates and the Material Trader on the way to the Rare Material Trader. However, the character gets stuck next to the boxes instead. Screenshot of location in gallery.

Yukiko 14:20, 7 September 2007 (UTC)

Thank you for giving such a clear specific example in your report. I know exactly what you're talking about. Unfortunatly we aren't planning to make any changes to click-to-walk movement at this time.-Kim Chase 18:24, 10 July 2008 (UTC)

Heroes & Henches: AoE attacks -- Slow reaction to AoE attacks

Issue: The current AI is slow at recognizing Area of Effect attacks and getting out of them. It seems the AI doesn't actually "see" the attack, but rather checks to see if it's hit by the same type of damage twice in a row after which it will try to move away. The problem is not only that it takes them several seconds to notice that they’re standing in a Meteor Shower, but they often fail at running out of it and if they do they usually walk back in. Even worse is that they only start moving away after they finish their current action (casting spells for example).
How to fix: The AI should respond faster to an AoE attack, cancel any skills they’re casting unless forced by the player and also not run back into the attack.
Additional info: The player can control the heroes with flags to overcome this flaw in the AI, but in Hero Battles you’re often out of range and can’t see what’s going on.

--Draikin 00:36, 13 September 2007 (UTC)

I've noticed also the the AI doesn't tend to run far enough when it comes to multiple AoE attacks or snares. One example is against ice imps, where the hero will be hit with mind freeze and then try to walk away from the malestrom(s). When they try to walk away, they walk one direction for a certain period of time, think that they're still in aoe, and then try a different direction, often running further back into the AoE effect, all the while trying to cast spells. The Ai really needs to understand where the centre of each AoE effect actually is, and then attempt to move away from it to beyond adjacent or nearby, depending on which AoE spell it is. --Ckal Ktak 14:14, 5 December 2007 (UTC)

I find they will run in "babySteps" sometimes turning around again after they're almost out 24.141.45.72 04:30, 26 January 2008 (UTC)

We will not be improving the speed and accuracy in which heroes aviod AoE attacks at this time. I don't know the full details on why this call was made, but I understand that there is a necessary response limitation. -Kim Chase 00:22, 10 July 2008 (UTC)

Regrettable, since the latest Hero Battles finale showed once again how this limitation can be easily exploited and even the best players can't prevent their entire team from literally going down in flames. In my opinion this really is the greatest flaw in the hero AI at the moment. In any case, thanks for looking into this issue. --Draikin 00:42, 10 July 2008 (UTC)

Heroes and pets -- Pets not following heroes

Issue: When a hero is out of compass range from the player and the player orders the hero to return to him then their pets won't follow them. The pets only run back to their master when the player (not the hero) is back in compass range of them. If at that moment the hero is out of range of the player, then the pets will try to run back to the hero in a direct line which means they'll get stuck if there's any obstacle in the way. They will only find the correct path again when the hero also returns into compass range of them.
How to fix: Fix the bug that causes pets not to follow heroes when the hero is outside compass range of the player.
Additional info: none

--Draikin 00:43, 5 January 2008 (UTC)

The client really only knows about things that are within radar range, which is an unfortunate limitation of our system. Because of this you see situations similar to the pet problems you mention here.--Mike Zadorojny 01:04, 25 July 2008 (UTC)

Heroes and henchmen -- Exiting junundu by accident

Issue: Sometimes when navigating around the Desolation in junundu form, heroes and henchies will move over rocky terrain, thus causing them to exit the junundu. There is often no obvious feedback to the player when this happens. This can cause them to die when you later enter sulfurous ground, or if you're fighting a large mob. If they die in sulfurous ground, getting them resurrected can be impossible or at least very tricky.
How to fix: Change the AI so that henchies will give rocky terrain a wide berth when in junundu. Alternatively, make it so that travelling over rocky ground is impossible when in junundu form (ie, the henchies will only exit the junundu when you manually use the skill to do so yourself).
Additional info: none

-- Hong 23:01, 28 January 2008 (UTC)

Unfortunately, to upgrade the AI to support this would take a significant amount of time and has the potential to break the functionality of Heroes and henchmen across the board. As such this is not an issue that we currently plan on addressing.--Mike Zadorojny 01:07, 25 July 2008 (UTC)

Mesmer

Hero & Henchmen skill usage -- Inspired Hex, Revealed Hex, Arcane Thievery, Arcane Larceny

Issue: The AI will use spells obtained by using these skills against their opponent regardless of their rank in the attribute line of the spell.
How to fix: Update the AI so that spells obtained this way are only used by heroes when they have a reasonable rank in the attribute line of that spell.
Additional info: none

--Draikin 13:00, 2 October 2007 (UTC)

We have discussed this and we do not intend to make this change. Thank you for the suggestion. -Kim Chase 21:49, 9 July 2008 (UTC)

Fair enough, although I'm interested in hearing the reasoning behind this decision, because the Friday October 26th update mentioned that: "Heroes and Henchmen now take into account Conditions and Exhaustion when choosing which skills to cast. They also consider attribute levels for stolen skills, and combo states for Assassin skills.". --Draikin 22:46, 9 July 2008 (UTC)

That was an attempt made in the past to make heroes more efficient with skills like this. It's simply not feasible for us to make improvements. -Kim Chase 23:55, 9 July 2008 (UTC)

Warrior

Hero & Henchmen skill usage -- Wild Blow

Issue: This skill is often used on recharge and regardless of whether or not the opponent is using a stance. The AI doesn't take charged adrenaline skills into account when using these skills.
How to fix: Update the AI so that wild blow is used only when (very) low on adrenaline or when the opponent is using a stance.
Additional info: none

--Draikin 23:47, 17 September 2007 (UTC)

Adrenaline management for heroes is not going to change. -Kim Chase 18:44, 10 July 2008 (UTC)

In that case, would it be possible to change this skill to match the following behavior: when the hero has no adrenaline skills equipped on its skill bar, they can simply spam the skill (meaning dervish and assassins can use the skill with their non-adrenaline attack skills, this is actually the current behavior for Hammer Bash which I reported here as incorrect usage). If they do have adrenaline skill equipped, the hero should only use Wild Blow to cancel a stance on their target. The only theoretical downside to this is that they wouldn't use Wild Blow at all when their target has no stances and the hero has adrenaline skills, but in reality this isn't a bad thing at all since they would constantly lose all their adrenaline and never get to use their adrenaline skills anyway. --Draikin 18:39, 14 July 2008 (UTC)

I agree that this skill is a difficult one for heroes to use effectively. Wild Blow is one of those tricky abilities that is more effective in a broad sense when used in a very basic manner by the AI. I think it's better for the heroes to reliably remove all stances then to delay the use of this skill and possibly leave their enemy in a stance that is detrimental to the party. Leah Rivera 18:26, 3 June 2009 (UTC)