I'll need a full log. I just tested chicken and it's working normally for me. It has to open the escape menu, and then it will click on the logout button.
40+ normally, while botting It only happens when logging to character select. Works perfectly fine exiting to login screen.
Perfect! can't wait to get my hands wet with this! this version has polished a lot of stuff! loving the moment use of skills, everything is looking very human like!
I better take a look at the log to make sure nothing else is there before I do anything. It's working for me, but I can add in some delays to slow it done some to try and avoid the issue. Basically, it sounds like the bot tries to open escape state and does, but when it checks to see if it can click on the logout button, the client hasn't fully opened the gui yet. For chickening, I would strongly recommend Title Screen though, since the client handles it differently from Character Selection. If you do a manual logout to character selection, and press Escape right away, you'll see there's a delay between when you logout and when the client starts the process.
The grindzonechanger plugin is stupid but the rest is fine. Btw can you make it so i dont die next time you have an update? ~:]
I'm not sure why you are even using the bot if you refuse to read the notes regarding its use? The Grindzonechanger plugin is an EXAMPLE plugin that provides an example method of changing the area of a grind. Its not stupid in the least bit, and is very helpful to people working on developing for the bot.
wat? how does this work??? If you actually read the plugin, it will say you need to custom it otherwise it won't work out of the box. How did you die? let me guess, you clicked start and went somewhere, came back and dead?
Is there an easy way to make grindzonechanger to be compatiable with the Dominus plugin? If I enable both, the bot will portal out before fighting Dominus. The successful combination of both would add more randomness to the boss fighting.
Well, there's no need to make the two compatible. The whole point of the grind zone changer plugin is to show what you have to do to change the grind zone. To actually change the grind zone after a Dominus run, you just implement the grind zone changing logic inside the plugin itself: Code: // Check to see if the boss fight is over. Logic for actually completing the quest for the first time // is not implemented. var npc = LokiPoe.ObjectManager.GetObjectByName<Npc>("Lady Dialla"); if (npc != null) { // Wait for her to spawn in and be usable. if (npc.IsTargetable) { Log.InfoFormat("[DominusFight] Lady Dialla was found. Now completing the boss fight."); BasicGrindBotSettings.Instance.NeedsTownRun = 2; // Implement grind zone changing logic here // } return true; }
Hi I have a quick question ever since the new build the bot is amazingly picking up junk... the bot is default config, I didn't have any issue in the previous version thanks when I say junk is all grey and magical item that are not even supposed to be picked up
Nothing changed in this version related to item filters or looting. Double check all your client settings to make sure they are setup correctly according to the BasicGrindBot Guide, and make sure you're running a clean copy of the bot and not an older version that you updated.
It seems that the transition to the corrupted area in Catacombs is working excellent - however the exploration of the corrupted area is bad.... it is completely random if the bot ever enters the "boss" area. if the bot explorer 97% (i believe thats what i noticed) prior to finding/exploring the boss room, it will exit the instance, but if the bot encounters the boss prior the exploration limit it will kill the boss take loot and vaal vessel. The bot should explorer 100% of corrupted areas before leaving or at least some sort of check that it have looted vaal vessel - i believe this is an issue in all corrupted areas, please do correct me if I'm wrong. It seems like a waste of time if the bot does not explorer 100% or make sure that it has looted the vessel. I know the bot have been re-written from the bottom, but prior to masters the only reason a bot would not complete the corrupted area was if it kept dying and at some point reached the death limit. Edit: Also this happens every now and then: MoveToLocation] [MoveTowards failed for {194, 171}. [MoveToLocation] MoveTowards failed for {194, 171}. [MoveToLocation] MoveTowards failed for {194, 171}. [MoveToLocation] Now moving towards {194, 171}. We have been performing this task for 00:00:11.8331332. and nothing is in its way as it is in town. eventually the bot continues, however haven't noticed how long it takes Log is wooping 38mb so will try, to get a smaller one at some point.
This is working as intended. It's not mentioned in this new thread (was in previous), but I'll make it more clear in the general information stickies so people don't get confused. The Explorer's job is to explore the entire area, quite literally, cover the entire map so things pop into sync radius. That's it's only job now. What happens along the way is up to other task logic, plugin logic, and the CR currently being used. In the old bot, explore logic was coupled with combat targets, loot targets, chest targets, as well as other things such as area transitions and waypoints. The concept of exploring back then was to divide the map into grid cells, like now, but it would unmark explore nodes if there was anything of interest there. That would force the bot to go back and re-explore that node. That system cannot fundamentally work correctly in Path of Exile, which is why the bot always had explore issues, looping issues, and all sorts of problems doing things (not to mention, it was all hard coded into the bot itself and couldn't be changed by users). When you divide the world into grid cells, you end up with certain cells that overlap an area that is connected from two different sides. This is a problem because you need to know which side to move to, by keeping track of a "navigable center". However, the problem comes when there are more than one object of interest in the cell, which creates two navigable centers, but only one can be the main one used. When you simply move to that center, it might be for the wrong object, so when the logic executes to handle that action, it needs to go to the other side, which it did. What results is the mess that has followed the bot pretty much until I rewrote the current Beta last month and used a totally different approach. For the new bot, all the old problems have been solved by taking a new approach. The only problems left, are ones that stem directly from the design of the game itself, which are unchangeable. By keeping exploration separate and only handling exploration, users now have one way to explore an area and load up things of interest. The only exception with exploration is traveling though boss areas, which users have to implement special logic for, since it cannot work on its own. Even so then, you have one easy to reuse part that opens the door for users to do anything in an area by exploring. In short, exploration is working correctly and doing it's job if it's covering the entire area, which it is. Now, for what you're talking about, the issue comes down to the current design of ExampleRoutine. This is the guide that needs some additional details about actual combat as that is the issue you're seeing. ExampleRoutine does not implement specific boss fighting logic. To be technically specific, ExampleRoutine does not contain logic to track down and kill an enemy if it's outside of CombatRange, which is pretty much what happens in a lot of areas for boss fights. That's basically the issue you are seeing, and many others when they report the CR doesn't kill the bosses, which I've mentioned in most of the previous release threads, is intended. All ExampleRoutine does is handle combat around the player in a specific range. For bosses, users have two choices, either: 1) make a new CR that implements that type of logic into the design to avoid issues or 2) use a plugin, as DominusFight shows, to move the bot into boss range so the current CR can fight it. Trying to make ExampleRoutine or any CR for that mater, track down and kill a target presents a very challenging design issue for those who try it. The problem you end up running into, will be the same problem we saw when we tried to do too much with the previous Explorer system; conflict of execution. As a result, by simplifying the process, as the current design does, you can implement more complex logic in a way that doesn't break down. The actual solution to the problem isn't too hard; you'd make a plugin just like DominusFight (which is why it was provided), except you keep track of any unique mob, and move towards it so it eventually comes into combat range of the CR. That should pretty much solve the problem, because the only reason the CR doesn't attack the boss, is because the boss isn't in combat range or is in a state (buried) that the CR doesn't process because it only cares about active mobs around it, by design. So, everything is working as intended. I have two more planned plugin examples (something for this, and a map example) coming soon, but general boss logic is up to users with the current design. The current bot setup gets the player to the boss for their logic to execute, so it's doing it's job. The bot no longer handles any combat logic. i know non-devs don't understand a lot of this stuff, but after a years worth of rewrites and trying to fix the same problems over and over, this is what has to happen for things to work correctly. My focus right now is getting a final Release done, so we can get users their compensation for the downtime and have a stable release. Everything you need to improve upon this issue is already there though.
RIP'd in Beyond, cruel, ledge. Found bot happily running this morning but in softcore. Saw this in the logs: [Logic] Now moving towards the monster Carrion Swarmer because [canSee: False][pathDistance: 64.34143][blockedByDoor: False] [Logic] Now moving towards the monster Rattling Bones because [canSee: False][pathDistance: 93.96136][blockedByDoor: False] [Tick] Exception during execution:Buddy.Coroutines.CoroutineUnhandledException: Exception was thrown by coroutine ---> System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index at System.ThrowHelper.ThrowArgumentOutOfRangeException() at Loki.Game.Utilities.ComponentInformation.(String ) at Loki.Game.Utilities.ComponentInformation.(String ) at Loki.Game.Utilities.ComponentInformation.get_LifeComponent() at Loki.Game.Objects.Actor.get_Auras() at Loki.Game.Objects.Actor.HasAura(String aura) at Loki.Game.Objects.Actor.get_IsCursedWithPoachersMark() at Loki.Game.Objects.Actor.HasCurseFrom(String skillName) at ExampleRoutine.ExampleRoutine.<Logic>d__40.MoveNext() in c:\ExilebuddyBETA 0.1.2740.914\Routines\ExampleRoutine\ExampleRoutine.cs:line 1024 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Loki.Bot.Logic.Bots.BasicGrindBot.CombatTask..() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Loki.Bot.v3.TaskManager..() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Loki.Bot.Logic.Bots.BasicGrindBot.BasicGrindBot..() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Buddy.Coroutines.Coroutine...() --- End of inner exception stack trace --- at Buddy.Coroutines.Coroutine.(Boolean ) at Buddy.Coroutines.Coroutine.(Boolean ) at Buddy.Coroutines.Coroutine.Resume() at Loki.Bot.Logic.Bots.BasicGrindBot.BasicGrindBot.Tick() at Loki.Bot.BotManager.(IBot ) The bot coroutine has finished in a state of Faulted [Stop] Now requesting the BotThread to stop. [Tick] Attempting to start the bot again. This is bot restart # 1. [Start] The BotThread is already running. Please use BotManager.Stop first. [BasicGrindBot] OnStop [AutoFlask] Stop [Chicken] Stop [StuckDetection] Stop [ExampleRoutine] Stop [Start] Now creating the BotThread. [BasicGrindBot] Start [Start] MsBetweenTicks: 15. [Start] InputEventMsDelay: 50. [Start] LowFpsMode: False. [AddAtBack] Now adding [ResurrectTask] This task handles resurrection.. Log attached. Line 1024 of the CR is: cachedHasCurseFrom.Add(skill.Name, bestTarget.HasCurseFrom(skill.Name)); The CR is heavily modified and also attached. WIMM
Sorry to hear! For issues like that you can make a Support thread so it can be worked with in its own thread. As for what happened, it's a known issue that can only really be band-aided and not really fixed. One thing you need to change with your modifications, is to keep all caching stuff together. I'll go over this at the end though. The actual reason for what happen is as follows: Memory valid in CR at Tick X Some frame release or coroutine wait that results in a few game ticks (C) going by. Memory is now invalid in the CR at Tick X + C, because the client object has been moved or deleted, since we're out of process. In your case: Code: 2014-09-24 22:43:20,895 [62] ERROR BotManager (null) - [Tick] Exception during execution: 2014-09-24 22:43:21,022 [62] DEBUG ResurrectTask (null) - [ResurrectTask] This is the #1 time we have died in this instance. You died in approximately 127 ms, which was faster than the bot could process, because it was starting up right away after the exception. That is why it was happily botting in Standard when you checked back. Since the API can't call client functions, has to use input related actions, it's basically a case where the bot couldn't react (like a player would) to a large spike of damage you received, as chicken did not trigger before the exception. In other words, you received fatal damage in 127 ms (not surprising in Path of Exile, as you should know). Knowing what killed you would most likely help, but there's no object dumping on death logic implemented. Would be a useful plugin though. The obvious question is, if the exception would have not been thrown, would you still have died? The answer most likely is yes, if you died that fast. It's possible there was a latency spike or a performance dip that triggered the exception in the first place. There's no real telling though, but your death wasn't specifically from the exception itself since the bot attempts to startup and resume right away. If there was a long time between when the bot attempted to startup again, then that would be a different issue, but that doesn't seem to the be the case. Were you botting Beyond? As for your CR changes, I didn't go though them all, just the section that matters: You need to register and have one post to see spoilers! Your changes to the caching operations triggered the exception because the object was invalid sometime between HandleShrines() and the curse logic checks. It's not the reason why the exception happened, as I mentioned above, but the caching stuff needs to stay together for that reason. The logic for the cachedHasCurseFrom needs to go back above so it's saved, to help reduce the chance of that component information being invalidated by the client between ticks. Before a Release version is made, I'll have one more section added to the general information threads explaining the issue and what users can do to try and avoid it. In either case though, the problem is not fixable right now because you have to choose either: 1. throw an exception and force a restart of everything in hopes to avoiding the issue again 2. use stale data that doesn't accurately reflect the current client state In either case, you have the wrong data (or none) from the client, so the results will be the same. Botting in hardcore will always be a challenge as a result, specifically since playing in hardcore legit is already as rough as it is. Hopefully this clears up the issue.
