Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Take the assigned path back to the vendor #676

Open
Nablatidis opened this issue Feb 7, 2025 · 4 comments
Open

Take the assigned path back to the vendor #676

Nablatidis opened this issue Feb 7, 2025 · 4 comments
Labels
feature request This is a request for a new feature, or an expansion of an existing feature.

Comments

@Nablatidis
Copy link

Issue: When the bot goes back to the vendor when bags are full or for repairs, it usually picks the shortest way possible back, this sometimes leads it to pass through dangerous territory or it gets stuck. It might run straight through a camp of gnolls and get killed.

Feature request: When it goes back to the vendor, it should take the path it's following, or add the option for that, until it reaches the closest point where the path is relative to the vendor and only then deviate and run to the vendor. That gives us more control over how the bot returns to the vendor.

@Nablatidis Nablatidis added the feature request This is a request for a new feature, or an expansion of an existing feature. label Feb 7, 2025
@Xian55
Copy link
Owner

Xian55 commented Feb 7, 2025

This options is already available and it's a built in feature. Here
I use it as a workaround to be able to visit a vendor which is indoors.

However at its core it does not designed to tackle combat or be aware of the surrounding environment during the time while it reconnects to the FollowRouteGoal. However this aspect can be improved!

All you need to do is record the path to the vendor and save it in example: 1_Gnome_Vendor.json. If that file has more then 1 coordinate in there, it will respect the route instead of purely using the navigation which potentially lead into pack of trash.

  "NPC": {
    "Sequence": [
      {
        "Cost": 6,
        "Name": "Repair",
        "Key": "C",
        "Requirement": "Durability% < 35",
        "PathFilename": "1_Gnome_Vendor.json"
      },
      {
        "Cost": 6,
        "Name": "Sell",
        "Key": "C",
        "Requirements": [
          "BagFull",
          "BagGreyItem"
        ],
        "PathFilename": "1_Gnome_Vendor.json"
      }
    ]
  }

@Nablatidis
Copy link
Author

"However at its core it does not designed to tackle combat or be aware of the surrounding environment during the time while it reconnects to the FollowRouteGoal. However this aspect can be improved!****"

I think is what I'm talking about. Whenever bags are full, the bot will abandon the Grindpath and try to connect to the vendor path (or straight to the vendor). This is the dangerous part. What I'd want is the bot still follows the original grind path until it reaches a point where the Grind path and vendor path are the closest to each other. So that I can connect the grind path and vendor path to each other in a safe way.

Unless I'm misunderstanding you. The bot will head straight for the head of a vendor path (with a path) same as it will to a vendor with a single coord right?

For example if my bot is on one side of Loch modan and I have a vendor path that starts somewhere south of the lake, it will abandon the grind path and take a looong swim to where the start of that vendor path starts.

@Xian55
Copy link
Owner

Xian55 commented Feb 7, 2025

Please upload a *.log file which describes your issue.


I'm using 1_Gnome_Vendor.json and 5_Gnome_Vendor.json as an example and comparison here.

Unless I'm misunderstanding you. The bot will head straight for the head of a vendor path (with a path) same as it will to a vendor with a single coord right?

When the 1_Gnome_Vendor.json only contains a single point, then only through pathfinder the bot will be able to reach the destination.

When 1_Gnome_Vendor.json contains multiple points - a path - the navigation still be used but only to the start location of the path, then it's going to follow the points by each without any pathfinding.

In this case it is expected to the end location be at the vendor / repair guy. When the player sold its grey items, it's going to reverse the previously mentioned path and it will to it in reverse the exact same thing follow the set of path to the point of the start location.

If you need an example of it please try out of low level profiles which has 5_Gnome_Vendor.json mention in them.


The key take away is when multiple points are found in the 1_Gnome_Vendor.json file, you have the control what path it would take.

However it order to make the feature more resilient

  • after selling the items and moving back to the grind location, i have to do some changes to don't just blindly follow the revered 1_Gnome_Vendor.json path

@Nablatidis
Copy link
Author

"after selling the items and moving back to the grind location, i have to do some changes to don't just blindly follow the revered 1_Gnome_Vendor.json path"

Exactly. That is partly the feature request I'm making. But even more importantly how it goes TO the vendor. I understand how the pathing works. I'm talking only about how the bot moves from the grinding path to the vendor path.

The main danger with it is that once the bags are full, the bot will abandon the grinding path and head for the vendor path, taking the closest way there. I cannot control when it decides to head for the vendor path. And since I don't know where on the grinding path the bags will be full, I can't make a vendor path.

So my suggestion is that I'd like an option for the bot to never abandon the grinding path or the vendor path. ONLY stay on those assigned paths. Calculate where the shortest route on the grinding path and the vendor path meet and only there abandon the grinding path.

I'm playing hc by the way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request This is a request for a new feature, or an expansion of an existing feature.
Projects
None yet
Development

No branches or pull requests

2 participants