Matenia

That's exactly why people are selling their code. Wrobot as a company doesn't hire anyone. There are no comissions or payouts. Money from our personal sales goes directly to us. Minus the fees for store websites and PayPal (roughly 10-15% - but a flat fee on small transactions, so out of a 6.50 fightclass I am usually left with 5€ before taxes).

Just spend 30 minutes making one. Then you can post your level 1-5 quester with all the other failed projects of people who realized they are in way over their head. Or you can spend roughly 400 hours on getting a more or less 1-40 quester going and then release it for free because you're a good soul. I mean who doesn't like working a fulltime job for 3 months completely for free?

he's talking about a bot for CLASSIC which will not be happening here Read up on it. It's been said multiple times. Blizzard has good anti-cheat now and Droidz doesn't want to get sued either.

Can you just shut up creating drama for no reason? Your previous account was banned because you scammed someone by selling an incomplete profile that you were incapable of finishing. You're not allowed to sell anything now that you've been given another chance. You bother me almost daily because besides a bit of copypasting, you can't really code. Don't come in here shitting on people who have put in actual time and effort to provide decent products.

Yeah, I figured if I'm suspending the CustomClassThread while it's writing to client memory (not allowing it finish whatever work it was doing) it would either deadlock wRobot or the wow client itself (through directx endscene), while I was testing some things. I decided it's time I write my own customclass implementation that allows me to properly pause it from an outside thread and provides more customizability than what wRobot currently offers. Thanks for the insight though, that was very helpful.

I think it has do to with me suspending CustomClass.Thread, like this: private void FightClassWaitForRegen() { List<Thread> threadsToSleep = new List<Thread>(); threadsToSleep.Add(CustomClass.CustomClassThread); var fightClassSleepThread = SleepFightClassThread(threadsToSleep); WaitUntilRegenerated(threadsToSleep); fightClassSleepThread.Abort(); } private Thread SleepFightClassThread(List<Thread> threadsToSleep) { Thread fightClassSleepThread = new Thread(() => { try { foreach (var thread in threadsToSleep) { thread.Suspend(); } while (Conditions.InGameAndConnectedAndAliveAndProductStarted && !Common.IsAttackedByNpc) { Thread.Sleep(500); } } finally { foreach (var thread in threadsToSleep) { thread.Resume(); } } }); fightClassSleepThread.Start(); return fightClassSleepThread; }

Similar issue: Wow stays unfrozen, but wRobot (interface too) is frozen. When I force-kill wRobot.exe process, WoW throws this error: ERROR #132 (0x85100084) Fatal Exception Program: F:\Games\WoW 3.3.5\Wow.exe Exception: 0x80000004 (SINGLE_STEP) at 0023:66D54590 I think it happens when wRobot targets itself (or others) using Interact.InteractGameObject

Not as of right now, no. You would need to write a little plugin that blacklists herbs and such are "guarded" by large groups or elite.

If you put the dll in your fightclass folder, it will see it. If you load it, the class needs be called Main and inherit the ICustomClass interface, so that wRobot can instantiate it through reflection.

Yep, that's Smokie.

I didn't want to start this - but yes, thank you. And as much as I like helping people, I don't quite enjoy getting daily questions (aka please fix this code for me) from people who don't understand what a variable or a function is or how to properly concatenate (or fomat) a string. There's no reason Smokie should be shitting on paid content. We (i.e. other sellers and elite) know his history here and he's not someone I'd call a developer.

No, I do not. But I know you do (CastSpellByName). I think that is causing it eventually to be corrupted. It's just a guess because someone CastSpellByName stops working after a while on WotLK.

That won't work. Mounts aren't spells in vanilla. And wRobot already has working mounts. As long as users disable all addons, things will be fine.

Also if you know a better way to pause fightclass thread than this, let me know: private Thread SleepFightClassThread(List<Thread> threadsToSleep) { Thread fightClassSleepThread = new Thread(() => { try { foreach (var thread in threadsToSleep) { thread.Suspend(); } while (Conditions.InGameAndConnectedAndAliveAndProductStarted && !Common.IsAttackedByNpc) { Thread.Sleep(500); } } finally { foreach (var thread in threadsToSleep) { thread.Resume(); } } }); fightClassSleepThread.Start(); return fightClassSleepThread; }

Mounts works just fine in every expansion... The main problem is people use the bot on their characters with about 100 shitty vanilla addons that break the entire Lua environment.

You can record your own XML path or disable free mode and hope that works. Other than that my BG product does everything.

Hello @Droidz, I found the issue, I think. It's a multi threading issue, I think. If you call Lua.LuaDoString twice within the same framelock there are some Lua variables that get restored to their incorrect state. Pseudo code: -- first thread local _protectedFunctionSave = protectedFunction; protectedFunction = function(abc) return expectedValueForAntiCheat; end -- do actual lua code here -- !first thread -- before this function is restored another thread comes and does this -- second thread: local _protectedFunctionSave = protectedFunction; -- this is now the wrong function we are saving protectedFunction = function(abc) return expectedValueForAntiCheat; end -- !second thread -- first thread protectedFunction = _protectedFunctionSave; -- original is restored correctly -- !first thread -- second thread -- do actual lua code here protectedFunction = _protectedFunctionSave; -- wrong function is restored and breaks client a bit -- !second thread Is this possible? If yes, maybe thread-lock Lua class?

Been trying to get this done with the experimental options in HMP since 2018. I've just given up because it's pretty much impossible to do reliably. I'll probably just write my own grinder base eventually. PS: PM me for an invite to a dev Discord channel.

Q11: My character tries to pull from out of range and/or wRobot thinks it can't fight the target, then switches to another A: Go into advanced wRobot settings and disable "calculate distance by target size". From my Discord. You can (and probably should) also reduce the fight distance in wRobot settings to 35 yards.

These logs stop at July 19th (today is the 22nd) and have level 5 characters in them. If you're going to stream it, at least include wRobot's log window. That doesn't help to debug the specific issue you recorded a few minutes ago at all.

Can you just post a god damn log file already? Clearly something in your setup is selecting new targets mid-combat. It's ignoring your first target and continuing combat onto a new target, similar to how the multi pull plugin works. If you're posting a log file, there will probably be some info in there on what might be causing this. If you're using any of the experimental options in HMP's settings, such as pulling enemies in your way, I can see how this could be happening with low latency settings. Edit: Also in the latest video your bot, instead of turning around still tries to start combat with a new target. Which is exactly what causes this in the first place. Something is really fucked with your general combat settings. If combat isn't recognized properly, HMP also can't stop it to run away.