Same thing is not going to happen in PoE. GGG wants users to play various builds. It's not possible without specific gearing and you can't get it without buying. Disabling animations is very common in Garena version of the game for a long time. They might ban all of the accounts using PoESmoother, that's fact. If you are afraid, you have a choice to not use it.
Hey! First of all thanks for all your work, your script saves so much time! Secondly, Not sure if you'll wanna solve this, but on Daresso's dream Part two, sometimes it stands close to the iron doors, but not close enough so they open, and so gets stuck there, if you click without stopping the bot and the doors get open when you make it move closer, the issue is solved, but I guess there's some smart way to fix that. Have a nice day!
Hello, can you post the log? I've managed to fix it in a few iterations recently, and also what version are you running of QP atm?
Looks like mine is not the newest version, Since you launched an update 2 days ago. Imma boot some chars soon again, will use the new version and make sure to post you a log if they consistenly have the same problem. Thanks!
Yo DarkBlue. The version-number is still 0.0.1.1 btw. Might want to change that. (I always download from https://www.assembla.com/spaces/questplugin/subversion/source btw)
yea I know, I CBA to change a line in the code, it might break the whole plugin seeing as how that's the most important thing in the whole plugin.
HandleOyunInHighGate needs code below before MoveTowards. Ortherwise it may get stucked after stashing items. await Coroutines.CloseBlockingWindows(); Also, guys, don't use PoESmoother. With that shiet my bot couldn't enter Black Core.
Yea, it does not.. Seeing as how. Code: var handleOyunInHighGate = QuestPlugin.TaskManager.GetTaskByName("HandleOyunInHighGate"); if (handleOyunInHighGate == null) { if (!QuestPlugin.TaskManager.AddBefore(new HandleOyunInHighGate(), "TravelToGrindZoneTask")) { QuestPlugin.Log.ErrorFormat("[HandleOyunInHighGate] AddBefore TravelToGrindZoneTask failed."); //BotManager.Stop(); } else { QuestPlugin.Log.InfoFormat("[HandleOyunInHighGate] AddBefore TravelToGrindZoneTask Success."); } Which Means it's ran after ReturnToGrindZoneTask, which already calls CloseBlockingWindows. One of your tasks is derping so don't blame me, and without logs, I can't verify anything. Edit - Just on a whim I checked yout stash buddy Code: TaskHelpers.AddTask(new HandleCurrencyTask(), "SortInventoryTask", TaskHelpers.AddType.After); so... I wonder..
StashBuddy in the new version (not yet released) is not opening the stash at all Shit happened, if it's hard for you to add failproof one line to the code, I can do it myself, no problem.
Tormiasz, Listen to yourself. Not released, so how do I know anything about something not released? Shit happens because you make it happen, don't blame me for your shit that happens. It is fail proof on the assumption that any competent dev can make their plugin work with default tasks. Learn to make your plugin with better, before telling someone else how to do theirs. Edit - See Bold, I need sleep, my Asian eyes be like, what tonyx once said, (-.-)
I don't know why you hate me and you are not answering to my PM's. That shitstorm for one line of code? Really? I don't blame you for not knowing how my unreleased version of StashBuddy works. It's not my plugins fault, user may open inventory, click escape etc. and QuestPlugin would get lost in that case. Competent dev would not let the shit happen My plugins are working fine and I'm not telling you how to do yours but gave you a sugesstion to make your one better. If you can't take criticism then you got a problem.
- I don't hate you, I do not reply to pms, haven't for the longest time, never considered that did you? - Why would the user do those things when EB is running? PHM is there so users's can't do shit, there's no reason to open inventory without stopping the bot, it's like taking parts off of the assembly line, and expecting it to make the final product. No, competent dev accounts for things "His" plugin would do, not for some unforseen reason someone else's plugin would do. And he surely would make sure it's the not his plugin derping before blaming someone else's, especially telling someone else to add something not needed to their plugin. You admitted that your stash whatever task was opening stash in #514, therefore I surmised that the root of the issue was that, and you realized that after I pointed it out. Also, a dev posting an issue to another dev, would be competent to post a full log. - Apparently it is not, when you assume another plugin is at fault, whereas it's yours. The task and the core of adding that task has "never" had issues (from my memory and posts in this thread, I could be wrong.) Because it works on OldRoutine's task. Why should I add a CloseBlockingWindows when my task "never" calls it to open "any" windows? That makes no sense.
Ok, Just checked my pms, Well shit, you did pm me. For the CPU question, The Bots are fully running and not on title screen, it's something someone else did, and they do not want to public it, ever. For the Black Core issue, IDK what revision you are running, but I was fixing that task for the past 2 days, adding optimizations in preparation for something. Rev 395 Should be working, I have 5 heading to A4 atm, to do the piety delivery quest, I'll know it it derps after that. Edit, ok seems Like I can do some client mods so I can make a vid of it steamrolling A1-A4 to prove this works without needing user interaction, ASIDE from Equipping.
I personally call CloseBlockingWindows every time I use movement to avoid such situations, because you never know what can happen. It's not hard to add, won't break anything and make's life easier in case of not your's plugin fault. I didn't feel the need of posting full log because I already checked it before posting on the forum. I have enough knowledge to lurk trough the logs and code (made a visual studio project of QuestPlugin so it's easier to check). Wanted to save your time so I posted a ready solution. IMHO CloseBlockingWindows should be called internally in every movement function. PHM is not blocking keyboard clicks so that would be logical. But pushedx would need to see that post to do that (or block keyboard too). EDIT: The Black Core issue was propably caused by PoESmoother I've used for testing, already mentioned it somewhere. I trust you it can do everything without interaction. I even merged optional and main tasks today (after posting the line the shitstorm is going about!) to do them at once. AutoEquip is next on my todo list
That's cool but don't consider yourself as a competent dev, pushedx will crush you Kappa. EVERY FUCKING DAY THIS GUY HURTS OUR SHIT DEVS FEELINGS! jk bra. But still, QuestPlugin don't really have issues with blocking windows. And tbh, now that AIF is pretty much working fully (well stil some bugs maybe, and still have few things to modify but it shouldn't take long) I'll work on QuestBot, specific to questing. My testing for A1 went pretty well, just gathering ideas from the devs to make it better