Problem with area tansitions

[roneo1]

I don't know why this is happening, it has never happened before really.

But lately I've started up several bots and they're all running into area transitions issues. The most noticeable areas are the transition from warehouse sewers to ebony barracks, and ancient pyramid, I've also noticed it having issues entering the lunaris temple at the stairs area. The log stuff looks like this:

[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #3 try.
[LatencyTracker] AverageLatency: 95
[TravelToGrindZoneTask] The area transition to move to is 627 at {827, 2352}.
[WaitForAreaTransition]
[TakeAreaTransition] The Lunaris Temple Level 1
[InteractWith] Now attempting to highlight 627.
[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #4 try.
[TravelToGrindZoneTask] The area transition to move to is 627 at {827, 2352}.
[WaitForAreaTransition]

Not sure why this is happening but apparently the bot can't highlight the area transition/isn't close enough.

I noticed after being away for a while and when I came back the bot had started 100 new instance (or more) not sure how many since I wasn't there, because of this new area transition bug.

I gave up on the account in question as its surely flagged for opening that many instances in such a short amount of time.

Using latest version, anyway a fix would be appreciated.

edit: Also if I may ask, why are there issues with this now? Has GGG changed something that affected the bot?

 

[Boom Fish]

I have noticed this happening but only when I was using the questing plugin. So maybe its just a issue with the plugin rather than the bot.

 

[darkbluefirefly]

I don't know why this is happening, it has never happened before really.

But lately I've started up several bots and they're all running into area transitions issues. The most noticeable areas are the transition from warehouse sewers to ebony barracks, and ancient pyramid, I've also noticed it having issues entering the lunaris temple at the stairs area. The log stuff looks like this:

[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #3 try.
[LatencyTracker] AverageLatency: 95
[TravelToGrindZoneTask] The area transition to move to is 627 at {827, 2352}.
[WaitForAreaTransition]
[TakeAreaTransition] The Lunaris Temple Level 1
[InteractWith] Now attempting to highlight 627.
[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #4 try.
[TravelToGrindZoneTask] The area transition to move to is 627 at {827, 2352}.
[WaitForAreaTransition]

Not sure why this is happening but apparently the bot can't highlight the area transition/isn't close enough.

I noticed after being away for a while and when I came back the bot had started 100 new instance (or more) not sure how many since I wasn't there, because of this new area transition bug.

I gave up on the account in question as its surely flagged for opening that many instances in such a short amount of time.

Using latest version, anyway a fix would be appreciated.

edit: Also if I may ask, why are there issues with this now? Has GGG changed something that affected the bot?

The bold statement is not possible.

 

[roneo1]

The bold statement is not possible.

Well when I had come back after a few hours the bot was just looping, going back to warehouse sewers, failing to take area transition, tp out, go again, the instance creation window was scrolled all the way down so my assumption was that in the time of a few hours while I was gone it had made around 100 new instances, and it hadn't stopped after making all those so I'm not sure if it would have stopped at all at one point. Regardless whether 100 is accurate or not, there were dozens of instances made at least.

Also I don't think that is the point, that's just a consequence of the bug, the problem is the bug itself. Also reading through the patch notes I see something about how the coast area transition had to be manually adjusted, but that is not the only one having issues.

 

[darkbluefirefly]

Well when I had come back after a few hours the bot was just looping, going back to warehouse sewers, failing to take area transition, tp out, go again, the instance creation window was scrolled all the way down so my assumption was that in the time of a few hours while I was gone it had made around 100 new instances, and it hadn't stopped after making all those so I'm not sure if it would have stopped at all at one point. Regardless whether 100 is accurate or not, there were dozens of instances made at least.

Also I don't think that is the point, that's just a consequence of the bug, the problem is the bug itself. Also reading through the patch notes I see something about how the coast area transition had to be manually adjusted, but that is not the only one having issues.

Max is 20 instances, then bot stops. Stuck detection must have kicked in and did re-logs. Regardless, once 20 instance controls are found. Bot will stop. Drew added this because I reported consequences of instance spams when I was building my sacrifice spammer 8 months ago.

 

[LajtStyle]

Same happend to me.
Bot stay 1 screen away from entrance to ebony barracks then tp to town and repeat.

Log:

Spoiler

[TravelToGrindZoneTask] Now exploring to the static location {529, 1219} (154) [15.6051 %].
Adding location ["The Ebony Barracks"][366] = {512, 1207} for area [0x86673021]
[TravelToGrindZoneTask] The area transition's location has been found from AreaStateCache.
[WaitForAreaTransition]
[TakeAreaTransition] The Ebony Barracks
[FinishCurrentAction] Waiting 0 for the action to finish Move.
[FinishCurrentAction] Waiting 87 for the action to finish Move.
[InteractWith] Now attempting to highlight 366.
[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #1 try.
[TravelToGrindZoneTask] The area transition to move to is 366 at {512, 1207}.
[WaitForAreaTransition]
[TakeAreaTransition] The Ebony Barracks
[InteractWith] Now attempting to highlight 366.
[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #2 try.
[LatencyTracker] AverageLatency: 69
[LatencyTracker] LowestLatency: 65
[LatencyTracker] HighestLatency: 65
[TravelToGrindZoneTask] The area transition to move to is 366 at {512, 1207}.
[WaitForAreaTransition]
[TakeAreaTransition] The Ebony Barracks
[InteractWith] Now attempting to highlight 366.
[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #3 try.
[LatencyTracker] HighestLatency: 99
[TravelToGrindZoneTask] The area transition to move to is 366 at {512, 1207}.
[WaitForAreaTransition]
[TakeAreaTransition] The Ebony Barracks
[InteractWith] Now attempting to highlight 366.
[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #4 try.
[LatencyTracker] HighestLatency: 100
[TravelToGrindZoneTask] The area transition to move to is 366 at {512, 1207}.
[WaitForAreaTransition]
[TakeAreaTransition] The Ebony Barracks
[InteractWith] Now attempting to highlight 366.
[InteractWith] The target could not be highlighted.
[TravelToGrindZoneTask] TakeAreaTransition returned InteractFailed. This is the #5 try.
[LatencyTracker] LowestLatency: 67
[LatencyTracker] HighestLatency: 67
[LatencyTracker] HighestLatency: 70
[TravelToGrindZoneTask] The area transition to move to is 366 at {512, 1207}.
[TravelToGrindZoneTask] The bot has failed 5 times to take an area transition to another area. Now returning to town.
[SetNewInstanceOverride] 3_3_10_1 = True
[CreatePortalToTown] Now opening the inventory panel.
[OpenInventoryPanel]
[OpenInventoryPanel] The InventoryPanel is not opened. Now opening it.

 

[darkbluefirefly]

It's because GGG is stupid. They are messing around with Transitions, where the actual transition is a little ahead of the image you see. IDK why, but pushedx knows and is fixing I believe.

 

[pushedx]

edit: Also if I may ask, why are there issues with this now? Has GGG changed something that affected the bot?

Essentially yes. Like you said, these problems have never really been around before, and there's no new changes on our side with the bot (other than trying to patch these random issues), so changes being done on the server are affecting us.

There's not much more I can do for now, other than try to track down exactly what is happening and try to code around it, like any other client issues that's ever existed. For the case of some area transitions that are too far away, I can try to lower the range that I had just increased some to reduce this, but ideally, I need to come up with a new way to move towards unwalkable locations without causing too many side-effects. The pathfinding library we use supports it, but that aspect of it isn't being used to prevent this very problem; attempting to move to a location we can't reach, and ending up not doing anything because the destination is unwalkable (the bot would just get stuck trying to endless move along the partial path).

I noticed after being away for a while and when I came back the bot had started 100 new instance (or more) not sure how many since I wasn't there, because of this new area transition bug.

Please attach a full log of the bot that did this. I coded in a hard limit of 10 instances in the past to help avoid unexpected issues like this, so if you didn't disable it, it shouldn't have happened and I need to see why yours did.

 

[roneo1]

Essentially yes. Like you said, these problems have never really been around before, and there's no new changes on our side with the bot (other than trying to patch these random issues), so changes being done on the server are affecting us.

There's not much more I can do for now, other than try to track down exactly what is happening and try to code around it, like any other client issues that's ever existed. For the case of some area transitions that are too far away, I can try to lower the range that I had just increased some to reduce this, but ideally, I need to come up with a new way to move towards unwalkable locations without causing too many side-effects. The pathfinding library we use supports it, but that aspect of it isn't being used to prevent this very problem; attempting to move to a location we can't reach, and ending up not doing anything because the destination is unwalkable (the bot would just get stuck trying to endless move along the partial path).



Please attach a full log of the bot that did this. I coded in a hard limit of 10 instances in the past to help avoid unexpected issues like this, so if you didn't disable it, it shouldn't have happened and I need to see why yours did.

From what I can tell pushed, the bot stops a little too far from area transition and then tries to take it. I'm not 100%sure but I think it was doing this in the past as well but when ti was trying to take the area transition it would just automatically walk towards it and it would happen. Wish I could tell you more but this seems to be the behavior. If you want to code around it, I would say have the bot close in as close as possible to the area transition (in the walkable area) and then attempt to take it.

As for that log I dont have it anymore but I dont think the bot opened 100 instances, probably way less, but the instance creation bar was scrolled all the way anyway, so it was maybe around a dozen or so, if I encounter the issue again I'll save the log.

 

[darkbluefirefly]

From what I can tell pushed, the bot stops a little too far from area transition and then tries to take it. I'm not 100%sure but I think it was doing this in the past as well but when ti was trying to take the area transition it would just automatically walk towards it and it would happen. Wish I could tell you more but this seems to be the behavior. If you want to code around it, I would say have the bot close in as close as possible to the area transition (in the walkable area) and then attempt to take it.

As for that log I dont have it anymore but I dont think the bot opened 100 instances, probably way less, but the instance creation bar was scrolled all the way anyway, so it was maybe around a dozen or so, if I encounter the issue again I'll save the log.

Probably what pushedx will do is try points near that area, and we hope that will work.

 

[pushedx]

As for that log I dont have it anymore but I dont think the bot opened 100 instances, probably way less, but the instance creation bar was scrolled all the way anyway, so it was maybe around a dozen or so, if I encounter the issue again I'll save the log.

Alright, it would have been exactly 10 then because that's how many GUI entries are tracked. The actual size of each instance entry can vary based on time left, and if it gets assigned a Realm text.

There's a tweak in the next beta for the too far from area transition thing that might help, but I won't be able to deploy the beta until later today (maybe 12+ hours from the time of this post). You can give that a try to see if it helps or not.

 

[roneo1]

Hey pushed, seems like what you changed has fixed transitions for the most part but there's a problem with dominus->aqueduct transition, bot doesn't even walk towards it not sure, it says it can't detect it, I've tried moving the bot right next to it etc, but it just won't go, Could it be an offset problem or maybe it needs a manual code modification?

Log looks like this for the transition:

[HandleBossDominus] Cannot Find The Aqueduct, will use Static Location {3594, 349}
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.
[LatencyTracker] HighestLatency: 363
[StuckDetection] {3511, 388} => 25
[StuckDetection] bounds: {0, 0}
[StuckDetection] TimeInInstance: 00:08:12.0173893
[StuckDetection] TimeInArea: 00:01:40.2065575
[MoveToLocation] Now moving towards {3594, 349}. We have been performing this task for 00:00:00.1262847.
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.
[MoveToLocation] Now moving towards {3594, 349}. We have been performing this task for 00:00:00.2303898.
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.
[MoveToLocation] Now moving towards {3594, 349}. We have been performing this task for 00:00:00.4351136.
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.
[MoveToLocation] Now moving towards {3594, 349}. We have been performing this task for 00:00:00.6290687.
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.
[MoveToLocation] Now moving towards {3594, 349}. We have been performing this task for 00:00:00.7846357.
[MoveTowards] FindPath returned EndNotNavigable.
[MoveToLocation] MoveTowards failed for {3594, 349}.

 

[dakiru]

have explained more in depth my problem, I want to achieve my bot q go from mission to mission while killing

 

[pushedx]

The Dom issue has been brought up, and I think it's just a bug with the logic and changes with post 2.0 changes. Looking into that is still on the todo list! Basically, there's no error handling for that specific error, as it's never really been a problem before, so it just logs what the error is, but it needs to be handled differently.