Zer0

You can check for your pet's spell cooldown like so: local start, duration, enable = GetSpellCooldown(PET_SPELL_INDEX, 'pet') return (duration - (GetTime() - start)) * 1000 This returns the spell cooldown in milliseconds. The spell is ready when it returns a value lower than 0. You'll need to replace PET_SPELL_INDEX with i in your case.

Shouldn't it be 0.5, instead of 50?

Agreed with @Matenia. Having a separate manager that records the state of the ObjectManager on each pulse is ideal, not only because your rotation can reuse these info very fast, but also besaue it gives you a reliable "snapshot" of the game state. There are pitfalls to this and it requires some thorough performance monitoring. It's definitely overkill for a simple rotation, so I think the dictionary solution at the begining of your iteration is a fine compromise if you check on a lot of buffs.

I don't know what you mean by "better way". With Auras, you get all buffs and debuffs alike, and recording them in a dictionary makes them extremely fast to access. The code I gave you does exactly what you need and more.

The idea behind recording the auras in a dictionary is to have them all cached for the entire rotation iteration for better performance. If you only use it once, or repeat the process for multiple spells, then it defeats the purpose.

If I remember correctly, calling HaveBuff() is indeed very slow. Assuming you've built your FC with a standard while loop, ideally, you want to cache all the buffs (aka Auras) of your characters at the beginning of the loop. A good implementation of this would be a dictionary. Dictionary<uint, Aura> auras = new Dictionary<uint, Aura>(); foreach (Aura aura in BuffManager.GetAuras(ObjectManager.Me.GetBaseAddress)) { auras[aura.SpellId] = aura; } What you end up with is a dictionary containing all the spell ids of your character's auras as key, and their corresponding aura as value, which makes it very easy and fast to check for buffs. if (auras.ContainsKey(123456)) { ... } You'll also get additional infos from the Aura class (like the buff owner, stacks, time left etc..). Just be aware that on earlier expansions, some Aura members might always return default values.

GetDistance2D will return the distance from you to the target, ignoring the Z axis, only useful in very specific situations. GetDistanceZ will return only the Z distance from you to the target (ignoring X and Y), again, very specific. GetDistance will return the 3D distance from you to the target. This is the one you want.

The reason your character only moves a little step is because you're still on the fight thread, so your code only executes for one fight loop iteration. The next iteration, you're back on the normal fight loop which forces you to get in your fight class range. There are two ways I know to prevent this. 1 - Lock the thread in your method. Which in your case would mean calling MovementManager.Go(pathList); and the next line, lock the thread in a while (MovementManager.InMovement) loop. I wouldn't necessary recommend this, because you're blocking the entire fight loop and you will need mutliple conditions to set it right. 2 - Cancel the fight event. This is my preferred option, but it's more complicated to set up. The code Nax has linked you is one I've written. It uses a manager that listens to multiple events. On the ObjectManagerEvents.OnObjectManagerPulsed event, I check and record a list of all the AOEs present in the object manager range. On MovementEvents.OnMovementPulse and MovementEvents.OnMoveToPulse I make sure I don't walk into an AOE, and make sure I never cancel an escape On FightEvents.OnFightStart, I make sure I don't start any fight during an escape This code doesn't really fit your need, because it avoids AOEs that stand on the ground (like a puddle of poison), and uses a "grid" to look for a safe position. In your case, you react to a single action. What you need to do is: - Detect the moment you need to escape. - Cancel the current fight, using cancelable.Cancel = true; - Calculate a safe route. - Turn an escape flag to true (a simple boolean) - Make sure you don't start a new fight during the escape using your flag - Turn back the flag to false when your safe condition is met

This product is in alpha. It is not yet intended for public use. We will release it on the forums if/when it's finished, with instructions on how to use it.

Another user on our discord server with the exact same issue has figured out that it was caused by a cracked version of proxifier. If you use a proxy, look into it.

The pathfinder server is down, you have to wait for it to come back online.

Answered on Discord. If you have a similar issue, remember to allow selling of the item rarities you want to mail.

Oui c'est possible si tu codes un peu.

Non, c'est le comportement par défaut du Party product. Dès qu'il est plus loin que la distance max, il va simplement "sur" la personne à suivre.

Interesting. The way I check for hostiles along the path is as follows: I use whatever current path WRobot is on, and every 3 yards ahead on the path (up to a certain distance), I check both LoS and Pathfinding from each node to the closest hostiles, until a positive result is found. I do cache my results (both LoS and PF) in a 3 yards approximation. This is a little intense but has been performing really well on multiple setups, even in tightly crowded areas like dungeons. I Now what I don't cache is the Pathfinding when defending. So I can definitely improve that. Also the AQ uses the Pathfinder for a lot of other stuff, like checking for the closest objectives. I did try and optimize it the best I could but I can definitely see how a slow internet connection can cascade into slowing down the entire product. I'm still not convinced that it's his problem, even after tests with a badly throttled connection, but thanks for the tip!

No worries. After looking again at your log, I think I know what's going on. The issue that appears is the time it takes for your WRobot to calculate a path. WRobot uses a distant server for pathfinding (which is one of its biggest flaws in my opinion) and the AQ uses pathfing a lot, and often. Even very short paths seem to take at least 340ms for you, which is really a lot. VPN, slow internet connection, I don't know. As a comparison, mine takes 40ms max on short paths. [N] 07:41:04 - [Path-Finding] FindPath from -11074.75 ; 898.3192 ; 40.03555 ; "None" to -11129 ; 936.59 ; 36.8307 ; "None" (Azeroth) [N] 07:41:05 - [Path-Finding] Path Count: 5 (133.2519y, 345ms) [N] 07:41:05 - [Path-Finding] FindPath from -11074.75 ; 898.3192 ; 40.03555 ; "None" to -11096.38 ; 886.2285 ; 41.5276 ; "None" (Azeroth) [N] 07:41:05 - [Path-Finding] FindPath from -11074.75 ; 898.3192 ; 40.03555 ; "None" to -11067.94 ; 899.621 ; 38.16179 ; "None" (Azeroth) [N] 07:41:05 - [Path-Finding] Path Count: 3 (24.90453y, 341ms) [N] 07:41:06 - [Path-Finding] Path Count: 2 (7.178874y, 469ms) 07:41:06 - [Wholesome Auto Quester] Defending against Riverpaw Taskmaster As you can see here, even a 2 nodes, 7 yards path took 469ms. This + the Line of sight checks I do on enemy detection might just be enough to make your bot too slow to react, which is what I observe from your gif. But I can't guarantee that this is your issue.

This is indeed not normal behaviour. I can't help you any further. Maybe try your luck with normal questers or grinders.

Yes, by default, WRobot does not engage combat with enemies on your path. It only defends when attacked. The Auto Quester, on the other hand, does clear your path of enemies under certain conditions (mounted or not, level difference, distance from objective etc..). 06:56:16 - [Wholesome Auto Quester] WAQ Clearing path against Stonesplinter Seer The product DID try to clear the path before your death. Now if it's a camp, since you're a paladin and don't have any mean to pull from a safe distance, I don't know what else you expect, apart from running in. The SmoothMove plugin is probably interfering too. Disable it. As said in the AQ description, the product only supports the Wholesome plugins.

Dying occasionally is part of the experience. Your issue comes mainly from the fact that when resurrecting, the bot is not seeking a safe resurrection place around the blacklst zone. I have no idea why it does that for you. This is not something I have ever observed myself. I advise you reinstall WRobot to restart fresh. As for "the bot always ignores mobs", the log you provided (3.1) doesn't reflect that fact. If anything, it proves that the product did in fact defend against mobs. The issue is just the same as before. It died from an elite and didn't manage to find a safe place to resurrect. There is however one, and only one case where the product will ignore fight, and it's when your gear is under 20% durability. I made it this way so that if you're stuck in a bad position, the bot will simply try and run to a repair vendor. I'm seeing that you have our Vendors plugin disabled. I highly advise you turn it on, and enable Repair.

Thank you so much!

Unfortunately, among the many things I've tried, I did that. I even tried to check 10 random tracelines between the ones I wanted. You know, for science. Even then, the results were all cached somewhere, for a time at least.

Hi, I have noticed that TraceLine.TraceLineGo doesn't update its result immediately when called repeatedly. The best example I can give is when I try to check the LoS for a door. I go in front of a closed door, check for LoS, which returns a positive result (so, no LoS). The method takes roughly 15ms to execute. Then I open the door, but even when the door is open, TraceLine.TraceLineGo keeps returning a positive result, and seems to only update at a random time after a few seconds, sometimes minutes. I'm thinking this is a cached result because when returning wrong results, the method takes 0ms. What exactly is going on here? Does this method have a cache? If so, is there a way to not use cached results at all? Any insight is appreciated.