I just used ExVault's plugin in a map that I was watching, and i had picking rares off so it was just picking currency+map drops
It went past two 73 maps while running, and left the area without an even nearly full pack to start the next run. This is when i stopped it to get the maps myself.
I have since told it to pick rares, which makes it exit and enter the map multiple times, since then I dont see it missing things really since its doing more sweeps of the map without mobs around. --I feel this is kind of a workaround, i wish the bot would log and item that matches the pickup filter and go back for it 100% of the time, the bot used to do this, but the newest bot doesnt because people didnt like the backtracking it caused (same with having it full explore the map, causes backtracking)
BTW i am playing a ranged character.
I'll still need a full log from a run where it missed an item that you thought it should have looted. The new design works better, and more reliably than the old one did.
If there is an obscure bug with looting, then I'll be able to track it down with enough logs. What you are describing is what the bot does already. It keeps track of all items it needs to loot, via AreaStateCache.ItemLocations. There are two LootItemsTasks registered. One to try and loot nearby things before trying to open nearby by chests, and then a second one that literally moves to every stored location to loot the item.
If the bot is missing an item, and never goes back for it, only three things are possible under normal scenarios (non-boss areas):
1. There was a looting error, which would be logged, so the item was blacklisted since the bot was physically unable to loot it.
2. The bot misses the item because it no longer knows about it. There's some very obscure scenarios where this could happen with how the client works, but it's not something that should be noticeable unless there's a new case to code around.
3. 3rd party code is being used that interferes with the looting processing, preventing the bot from going back to loot.
For #1, there's not much else that can be done if this is actually happening. Between desync, or items dropping in places where the player can't pick them up, or any number of other client oddities that may happen, all the logic can do is try so many times and then give up to prevent getting stuck. If you see your bot standing over an item for a short period of time, then this would be why it's not looting the item. You should be able to watch for this.
For #3, if BasicGrindBotSettings.Instance.NeedsTownRun is ever set to 2 when there's items still to loot, then the bot will go to town, and complete the run, without looting anything else. If user task code is executing before the looting tasks, this would be something they need to check for. If they are executing task code after the looting tasks, then they would not be able to trigger this scenario, since looting has to be finished in the first place before their code would execute. If they ever set the value in a Tick function, then they would be bypassing the system, and certainly would trigger the issue.
For #2, there's two possible cases where I could see there being an issue with the current design.
The first is something specifically coded around, and is most likely not what you are seeing, but I'll still mention it. Ids in PoE are not unique. If an item drops with id X, and you pickup the item, another item could drop with the same id. In order to avoid performance overhead from trying to re-match every item to the current set of item filters each update, which would result in massive slow downs the more items on screen, I have a system that keeps track of an id and a position. If an item drops with a specific id at some position, and then another item drops with the same id at the same position, then the bot would miss that second item. However, that is very unlikely to trigger, as you'd have to loot an item, and then have another item drop exactly where the last item was, with the same id. It's technically possible, but unlikely.
The second issue is the item is being removed from the tracking system prematurely. I can add a bunch of debugging to identify this issue, if it's indeed the problem. In the current design, rather than having to move towards an item location and then trying to loot it, it will eliminate the location if the player is within 100 units and there is no item with the specified id. Under certain scenarios, such as your character having a really fast run speed, higher latency, or any server issues where the object in question is sent to the client slower than expected, it would be technically possible for it to be removed even though it does exist. I can change this distance to be much smaller, and the trade-off is you'll be randomly moving towards a location longer than before, since it'll still think the item is there.
It is possible the entity sync range is a lot more volatile depending on the area you are in, as well as the direction you are travelling, or even be tied to the number of entities currently in the area. The current distance might be too far now, but there's no real way to determine a good distance other than just making it something a lot smaller. This would be the new case to code around I mentioned before, and is very possibly the issue if the issue is happening with the normal bot without any extra 3rd party code in non-boss areas.
Taking all that into account, here are the changes that will be in the next Beta to try and track down the issue:
- TownRunTask will now log all items that will be abandoned due to the bot going to town and not returning.
- AreaStateCache will now log all item adds and removes, so we'll know exactly what is happening with an item that is being ignored.
- The distance to eliminate out of view items has been lowered from 100 to 30.
After the next version is made in a day or so, I'll need you to run the new Beta and provide a full log for any run that it misses an item, if it continues to do so.
As for the other looting issue where the bot does go back for an item as expected, but doesn't pick it up right away when you think it could have, there's no solution to that using our bot design. You'd have to code your own bot implementation that had fixed combat logic, and couple looting logic with combat logic to handle all the cases for more human-like looting based on the current game state.
