Zer0

4 hours ago, thetaxi said:

Do you know of a better way to detect a debuff by ID? Perhaps some Lua code?

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.

2 hours ago, lachose21 said:

is it possible to stay at 10?

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!

2 hours ago, Zan said:

Temp fix, second check a traceline just slightly different from the original coords beyond the door.

Hopefully there is a way to clear that cache though.

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.

That's normal behaviour.

If you want to control the life cycle of a thread you have created, you need to keep track of it by assigning it to a variable. This way you can start it in Initialize() and then Stop it in Dispose()

// Define the thread and assign it to a variable
Thread myThread = new Thread(() => { });
// Start the thread
myThread.Start();
// Stop the thread
myThread.Abort();

Hi guys, I've created a video showing how to create a C# plugin from scratch. If you have questions or need more info, don't hesitate to ask.

Create a new text file. Copy/paste the code into it. Rename the file something like DungeonAccept.cs (make sure you change the extension). Move the file to your wrobot plugin folder.

I remember having the exact same issue with Matenia's HMP. If at any point during the session you change your public IP (for example by connecting/disconnecting to a VPN), you get locked out of the product for a time. This is a vendor protection to ensure that only one of their product is active at a time per key/IP. It has nothing to do with WRobot itself.

I'm refactoring my inventory plugin from the grounds up and there's still one lasting issue that I can't seem to figure out after days of investigating. 

For context, I'm testing in dungeons, with high drop rates and I occasionally get a LUA error "stack overflow (table too big to unpack)". I can't trace back to its origin. I have only 3 LUA calls that unpack tables on return in the entire plugin. I'm positive they're not the issue, so something else is happening. I've noticed that it happens mostly on group rolls (but not only) and not on all characters. My only way to confirm this is by using BugGrabber and BugSack to get the time stamp of the LUA error, and outputting the time stamp in the chat before each LUA call, but even that is not very reliable since you don't get milliseconds precision, only seconds.

The LUA call I make when rolling is the following:

Lua.LuaDoString($"ConfirmLootRoll({rollId}, 2)");

It's exactly the same as before the rework (which was working flawlessly). As you can see, it's extremely simple. the rollId parameter is always checked in the log and always correct.

I've never had this issue before, so any input is appreciated. Have you ever seen this issue? What could cause it? Is there any way at all to reliably detect which LUA call in the plugin is faulty?