Matenia

Pretty sure he's talking about the HMP combat log bug where it might get stuck trying to look the beacon. Sometimes if other code unblacklists mobs it will continue to attempt to loot them rather than ignore them.Best choice would be to disable combat looting in HMP and just enable it in wRobot. It shouldn't happen, but it's hard to tell when/why things are being unblacklisted. Edit: - Looting is (minus the combat loot HMP offers) handled by wRobot - Pathing, including flightmasters is handled by wRobot (if a profile chooses to go to a certain vector, wRobot decides how to) - Tram I can't say, it's not HMP if it's turned off - if it gets stuck it might be wRobot's pathfinding having fucked up meshes - Quest turn in is wRobot. It should cycle through all quests - possibly addons interfering or latency settings too low

Read GameTooltip documentation

Just fyi, a full 1-110 profile for retail takes about the fraction of the time an effort someone has to put into making 1-80 work in WotLK or even worse and even harder 1-60 in Vanilla. If you knew anything about this game and how difficulty has changed over the years, you'd understand that alone.

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.