ExilebuddyBeta
There's a ton of information to cover, so in an attempt to avoid a massive unreadable thread, here's a summarization of everything users need to know.
0. Please use the Support forum to post all the new bugs and issues you run into. I expect there to be a lot of feedback and stuff to look though, so you might not get a reply right away. However, I will read though all poses and comments. As per regular Buddy product rules, please attach a log when making a report, as it helps us identify potential problems that users might not be aware of.
1. Exilebuddy is currently going though a complete project restructuring. Please bear with us as we get the project reorganized, and brought back up to date for PoE 1.2+. In short, EB has been rewritten to work properly with 1.2+, and all previous logic and API stuff has been removed/changed. This was unavoidable, and while a lot of preparations were made for it, the actual amount of changes necessary for 1.2 was more than expected.
2. Users will be compensated for the downtime the past week since the update, as well as some additional time over the next week as everything is retested and updated. More details about this will come when we reach that point.
3. This Beta release has a very specific purpose: test portions of the new API, and the basic grind bot logic created for 1.2. This is not the final version of Exilebuddy. It lacks a lot of basic features and logic, as there was simply not enough time to add old things back without making users wait another week without anything to test.
4. The current state of Beta is as follows: There will most likely be bugs and possibly crashes to work though. Please do not test on a character that you cannot afford to have die.
5. A stable "Release" version of Exilebuddy will not be available for some time. As mentioned in #1, the old bot/API is gone. It would be very helpful if everyone tried out Beta and reported issues with the new setup to help speed up development, but we understand a lot of users are looking for something that Beta is currently not.
Download: ExilebuddyBeta (Please read this entire thread first though.)
Additional Requirements
API
BasicGrindBot
Path of Exile's "Key Pickup" setting needs to be enabled (Options -> Ui)
The "Move only" skill needs to be on your skill bar, and not in Slot 1 or bound to left mouse button.
Make sure your camera is zoomed out to the client max.
This bot implementation is coded to follow a very specific set of logic. All bot logic is implemented though the GrindTask. While users can add their own tasks to this bot implementation by design, it's not recommended due to the incompleteness of this bot implementation. There are a few known issues that users might come across. Due to terrain changes, it is possible for the bot to hug the walls too closely and get stuck. Pathfinding will have to be tweaked some to avoid this. In addition, it's possible for certain blocking objects, such as Strongboxes, to be placed in a way where the bot gets stuck trying to travel near them, Please remember that the current implementation requires user interactions, and do not leave the bot unattended.
First, the GrindTask only executes logic when it's not in town, a hideout, and the map room. If the character is dead, it will execute standard resurrect logic (as before) and choose the checkpoint if possible, and then the town. If neither appears to work, the bot will logout to the character selection screen. The GrindTask does not track deaths in its current implementation, but that feature will be re-added in the future.
The next thing the GrindTask does is clear any level skill gem icons from the main HUD. This is a new feature, and it's done using the new APII as the level skill gem API now uses the Inventory panel. The current GrindTask implementation does not offer skill gem leveling yet, but will in the future.
In the past, there were cases where certain chest clusters would trap the bot, and it would get stuck. GrindTask contains some basic logic to identify this scenario and try to avoid it. It will try to break any destroyable chests within close range before doing anything else.
The GrindTask will then attempt to open any close by doors. Additional logic has been added to try and identify any cases where the bot gets stuck behind a door, and it will logout if it gets trapped for too long and cannot make progress. All varities of doors have been tested, so there should not be any side effects of this logic.
At this point, the GrindTask will now call into the current CRs combat logic. This is a big change compared to how previous versions work, because the bot attempted to dictate when it was in combat. Now, it's the CR's job to handle this. This change was made to allow various long term issues to be properly solved. For example, Shrine logic is now handled though CRs. This allows a CR to try and grab a shrine when it feels is best, based on the current client state. ExampleRoutine does not handle Shrines yet though, but it has placeholder code. This new design, allows the CR to do things that had to be coded around before, such as raising minions when there were no enemies on the screen. The CR can also do things like stop moving if the user is punctured or trigger a town run if flasks are gone before any mobs get close.
When the CR returns false, to signal no combat logic executed, the GrindTask then moves into looting items and chests. The new design for looting is to cache locations of things the bot needs sto pick up or open, and then simply visit those locations one by one. As a result, BasicGrindBot will have a lot of backtracking, but it does it by design. This new design is in place to solve the long time issue of the bot running back and forth between a chest or an item and doing something else. However, as mentioned before, the current implementation is just something basic that should work. If the inventory is full, the bot will create a portal and go to town and then stop to wait for user intervention.
After all chest / item looting is completed, the GrindTask falls back into explore mode. Explore logic has finally been updated to fix a lot of performance issues and other design flaws with the previous systems. It now supports completion %, and is sorely used for visiting the entire area. Users cannot change the completion percent yet, because the current GrindTask is setup specifically to full explore and grind an entire area. However, in other implementations, this can be changed.
Finally, when the GrindTask has nothing left to do, it will create a portal to town and take it. If no portals are in the inventory, it will simply logout to the character selection screen. This behavior is not configurable currently, but it's just for testing short term.
ExampleRoutine
Path of Exile's "Always Highlight" setting will be toggled as needed, far less frequently than it used to. There might be some cases where it doesn't keep the state, but those can be fixed soon.
The new default routine for Exilebuddy is setup in a different way than the previous Release and Beta versions were. The goal with this routine, is to design around what's on the skillbar, rather than trying to handle every skill in the game. Numerous API improvements have been made to make this possible, but there will never be a way for the CR to use your skills as you'd like them to. As a result, CRs can be designed and used anyway devs want them to, but the one we will provide will be setup in the manner described.
At the top of ExampleRoutine.cs are user settings:
These need to be adjusted as needed to test this routine.
This routine will auto-detect and use a specific set of skills as well: Raise Zombie, Raise Spectre, Animate Weapon, Animate Guardian, and Flameblast. The code has to be changed to adjust how they are used, but example logic is there. Flameblast will be used when the character is surround by 4 or more mobs, and the animate skills are used on items that typically wouldn't match item filters, but the item filters are not checked. Zombies and Spectres will be raised as bodies are encountered if needed.
One of the changes from previous versions, is there is no longer a targeting class. Routines are responsible for handling targeting, because the combat responsibility lies with the CR as the bot no longer handles any aspect of it. This doesn't really change much, as specialized CRs would need their own targeting system in the past anyways. The targeting in ExampleRoutine is simply based on distance and the ability to attack. It does not check allies cannot die or other auras, or prioritize things like necros. It will in the future, but for this release, please make sure to watch what the routine does. Support for the new totem is included though, so the bot will not try to target or attack the invincible damaging totems found in some mission areas.
Lastly, the ExampleRoutine implements a system to help avoid getting stuck in back and forth cases. It will store a location it needs to move to, and then move to it. It will only stop if there are mobs close by that it should kill instead. That is necessary for cases where a leaping monster is on the low ground, and the bot is on the high ground and moves towards the low ground, and then the monster jumps up on the high ground. This system might need some more tweaking, but the logic is necessary to avoid that long time bot issue.
One mechanic not implemented in ExampleRoutine which is very useful, is trying to verify a skill was cast. In the previous Beta, the SmartCastCoroutine did this, but it resulted in slower skill casting because it would wait some for the client. While checking to see if the client performed a cast or not is helpful, there was a lot of feedback that the bot was attacking too slow. As a result, that system is not currently in place, and it might be added again in a more limited way to avoid slowing down the bot too much.
Just as a reminder, the logic we provide will always be pretty basic and generic. There will be no planned support for Rampage or Beyond, but users can customize their CRs to make them work better for each league as needed. Beyond Portals are exposed though the object manager, but Rampage hud information is not available though the API. Unless there is a really good reason for Rampage information to be provided, it most likely remain a low priority thing.
Current Plans and Timeline
I cannot stress enough, Exilebuddy is not currently finished. This Beta release is just a step forward in being able to bot in 1.2+ using our new setup. The immediate goal is to start working on more logic and features to test the new API. Town stuff will be worked in as well as things like area looping, doing corrupted areas, and other stuff the previous bot implementation had. More information and progress will be talked about as it happens over this upcoming week.
There's a ton of information to cover, so in an attempt to avoid a massive unreadable thread, here's a summarization of everything users need to know.
0. Please use the Support forum to post all the new bugs and issues you run into. I expect there to be a lot of feedback and stuff to look though, so you might not get a reply right away. However, I will read though all poses and comments. As per regular Buddy product rules, please attach a log when making a report, as it helps us identify potential problems that users might not be aware of.
1. Exilebuddy is currently going though a complete project restructuring. Please bear with us as we get the project reorganized, and brought back up to date for PoE 1.2+. In short, EB has been rewritten to work properly with 1.2+, and all previous logic and API stuff has been removed/changed. This was unavoidable, and while a lot of preparations were made for it, the actual amount of changes necessary for 1.2 was more than expected.
2. Users will be compensated for the downtime the past week since the update, as well as some additional time over the next week as everything is retested and updated. More details about this will come when we reach that point.
3. This Beta release has a very specific purpose: test portions of the new API, and the basic grind bot logic created for 1.2. This is not the final version of Exilebuddy. It lacks a lot of basic features and logic, as there was simply not enough time to add old things back without making users wait another week without anything to test.
4. The current state of Beta is as follows: There will most likely be bugs and possibly crashes to work though. Please do not test on a character that you cannot afford to have die.
User Guide - A new Beta user guide needs to be written. The existing one is still mostly accurate in terms of the GUI, but there are some updates to be made. Before a Release version is made, we'll have an up to date user guide for once, that covers everything people need to know.
API - The API has been updated for 1.2, and includes a lot of new and exciting things. For more information about this, please see the following guide: An Overview of Loki: Exilebuddy's API for Path of Exile. There are a few corrections and updates that still need to be made, but overall the guide is pretty accurate in regards to the current version. Only a few client features have not made it into the API yet, but they will be worked on after other updates are made, because they are low priority features. Lastly, more examples of using the new API are planned, but will be added when time allows.
CR - The basic CR we provide is not finished yet. It does have some advanced logic examples for skills not supported in the past (animate guardian, animate weapon, flameblast), but it needs some more stuff. The current design is such that users choose a skill slot for 1 melee skill, and 1 ranged skill. The CR then uses the melee skill in melee range (configurable) and the ranged skill otherwise. There is an option to configure always attack in place as well as a flameblast setting. All changes have to be done to the actual code file, and the bot must be restarted for the changes to take place. This will change so users can edit settings from the new GUI instead in the near future.
Bot - The basic bot we provide is not finished yet. Right now, users need to travel to an area they wish to grind, click Start, and after it finishes, repeat that process. The bot will not do anything related to Masters, quests, corrupted areas, and will skip opening Strongboxes and breakable chests (unless absolutely necessary). The bot is not able to be customized, because the implementation is very specific (for a number of reasons, other than just time), but this will be talked about in detail later. The bot will not do anything in town. Town run logic is not added, because it'd be too rushed, and the new API for town actions needs to be carefully tested. All in all, the basic bot provided will be changing a lot, but re-adding logic will most likely take weeks, as it all had to be redone.
API - The API has been updated for 1.2, and includes a lot of new and exciting things. For more information about this, please see the following guide: An Overview of Loki: Exilebuddy's API for Path of Exile. There are a few corrections and updates that still need to be made, but overall the guide is pretty accurate in regards to the current version. Only a few client features have not made it into the API yet, but they will be worked on after other updates are made, because they are low priority features. Lastly, more examples of using the new API are planned, but will be added when time allows.
CR - The basic CR we provide is not finished yet. It does have some advanced logic examples for skills not supported in the past (animate guardian, animate weapon, flameblast), but it needs some more stuff. The current design is such that users choose a skill slot for 1 melee skill, and 1 ranged skill. The CR then uses the melee skill in melee range (configurable) and the ranged skill otherwise. There is an option to configure always attack in place as well as a flameblast setting. All changes have to be done to the actual code file, and the bot must be restarted for the changes to take place. This will change so users can edit settings from the new GUI instead in the near future.
Bot - The basic bot we provide is not finished yet. Right now, users need to travel to an area they wish to grind, click Start, and after it finishes, repeat that process. The bot will not do anything related to Masters, quests, corrupted areas, and will skip opening Strongboxes and breakable chests (unless absolutely necessary). The bot is not able to be customized, because the implementation is very specific (for a number of reasons, other than just time), but this will be talked about in detail later. The bot will not do anything in town. Town run logic is not added, because it'd be too rushed, and the new API for town actions needs to be carefully tested. All in all, the basic bot provided will be changing a lot, but re-adding logic will most likely take weeks, as it all had to be redone.
Download: ExilebuddyBeta (Please read this entire thread first though.)
Additional Requirements
API
- Steam offsets are not uploaded yet. A few Steam specific changes need to be made and tested first.
- The login Gateway cannot be set though the API anymore. This has been temporarily disabled as a new method to change it is needed.
BasicGrindBot
Path of Exile's "Key Pickup" setting needs to be enabled (Options -> Ui)
The "Move only" skill needs to be on your skill bar, and not in Slot 1 or bound to left mouse button.
Make sure your camera is zoomed out to the client max.
This bot implementation is coded to follow a very specific set of logic. All bot logic is implemented though the GrindTask. While users can add their own tasks to this bot implementation by design, it's not recommended due to the incompleteness of this bot implementation. There are a few known issues that users might come across. Due to terrain changes, it is possible for the bot to hug the walls too closely and get stuck. Pathfinding will have to be tweaked some to avoid this. In addition, it's possible for certain blocking objects, such as Strongboxes, to be placed in a way where the bot gets stuck trying to travel near them, Please remember that the current implementation requires user interactions, and do not leave the bot unattended.
First, the GrindTask only executes logic when it's not in town, a hideout, and the map room. If the character is dead, it will execute standard resurrect logic (as before) and choose the checkpoint if possible, and then the town. If neither appears to work, the bot will logout to the character selection screen. The GrindTask does not track deaths in its current implementation, but that feature will be re-added in the future.
The next thing the GrindTask does is clear any level skill gem icons from the main HUD. This is a new feature, and it's done using the new APII as the level skill gem API now uses the Inventory panel. The current GrindTask implementation does not offer skill gem leveling yet, but will in the future.
In the past, there were cases where certain chest clusters would trap the bot, and it would get stuck. GrindTask contains some basic logic to identify this scenario and try to avoid it. It will try to break any destroyable chests within close range before doing anything else.
The GrindTask will then attempt to open any close by doors. Additional logic has been added to try and identify any cases where the bot gets stuck behind a door, and it will logout if it gets trapped for too long and cannot make progress. All varities of doors have been tested, so there should not be any side effects of this logic.
At this point, the GrindTask will now call into the current CRs combat logic. This is a big change compared to how previous versions work, because the bot attempted to dictate when it was in combat. Now, it's the CR's job to handle this. This change was made to allow various long term issues to be properly solved. For example, Shrine logic is now handled though CRs. This allows a CR to try and grab a shrine when it feels is best, based on the current client state. ExampleRoutine does not handle Shrines yet though, but it has placeholder code. This new design, allows the CR to do things that had to be coded around before, such as raising minions when there were no enemies on the screen. The CR can also do things like stop moving if the user is punctured or trigger a town run if flasks are gone before any mobs get close.
When the CR returns false, to signal no combat logic executed, the GrindTask then moves into looting items and chests. The new design for looting is to cache locations of things the bot needs sto pick up or open, and then simply visit those locations one by one. As a result, BasicGrindBot will have a lot of backtracking, but it does it by design. This new design is in place to solve the long time issue of the bot running back and forth between a chest or an item and doing something else. However, as mentioned before, the current implementation is just something basic that should work. If the inventory is full, the bot will create a portal and go to town and then stop to wait for user intervention.
After all chest / item looting is completed, the GrindTask falls back into explore mode. Explore logic has finally been updated to fix a lot of performance issues and other design flaws with the previous systems. It now supports completion %, and is sorely used for visiting the entire area. Users cannot change the completion percent yet, because the current GrindTask is setup specifically to full explore and grind an entire area. However, in other implementations, this can be changed.
Finally, when the GrindTask has nothing left to do, it will create a portal to town and take it. If no portals are in the inventory, it will simply logout to the character selection screen. This behavior is not configurable currently, but it's just for testing short term.
ExampleRoutine
Path of Exile's "Always Highlight" setting will be toggled as needed, far less frequently than it used to. There might be some cases where it doesn't keep the state, but those can be fixed soon.
The new default routine for Exilebuddy is setup in a different way than the previous Release and Beta versions were. The goal with this routine, is to design around what's on the skillbar, rather than trying to handle every skill in the game. Numerous API improvements have been made to make this possible, but there will never be a way for the CR to use your skills as you'd like them to. As a result, CRs can be designed and used anyway devs want them to, but the one we will provide will be setup in the manner described.
At the top of ExampleRoutine.cs are user settings:
Code:
private int _meleeSlot = -1; // The slot that has your main melee skill. When set to -1, CR does not use melee skill
private int _rangedSlot = -1; // The slot that has your main ranged skill. When set to -1, CR does not use ranged skill
private int _combatRange = 35; // Only attack mobs within this range. Do not set too high, as the cursor will overlap the GUI.
private int _rangedAttackDistance = 10; // The distance to use a ranged skill. I.e., use melee under this value.
private bool _alwaysAttackInPlace = false; // Should the CR always attack in place.
private const int FlameblastCharges = 5; // How many flameblast charges we want to reach before casting.These need to be adjusted as needed to test this routine.
This routine will auto-detect and use a specific set of skills as well: Raise Zombie, Raise Spectre, Animate Weapon, Animate Guardian, and Flameblast. The code has to be changed to adjust how they are used, but example logic is there. Flameblast will be used when the character is surround by 4 or more mobs, and the animate skills are used on items that typically wouldn't match item filters, but the item filters are not checked. Zombies and Spectres will be raised as bodies are encountered if needed.
One of the changes from previous versions, is there is no longer a targeting class. Routines are responsible for handling targeting, because the combat responsibility lies with the CR as the bot no longer handles any aspect of it. This doesn't really change much, as specialized CRs would need their own targeting system in the past anyways. The targeting in ExampleRoutine is simply based on distance and the ability to attack. It does not check allies cannot die or other auras, or prioritize things like necros. It will in the future, but for this release, please make sure to watch what the routine does. Support for the new totem is included though, so the bot will not try to target or attack the invincible damaging totems found in some mission areas.
Lastly, the ExampleRoutine implements a system to help avoid getting stuck in back and forth cases. It will store a location it needs to move to, and then move to it. It will only stop if there are mobs close by that it should kill instead. That is necessary for cases where a leaping monster is on the low ground, and the bot is on the high ground and moves towards the low ground, and then the monster jumps up on the high ground. This system might need some more tweaking, but the logic is necessary to avoid that long time bot issue.
One mechanic not implemented in ExampleRoutine which is very useful, is trying to verify a skill was cast. In the previous Beta, the SmartCastCoroutine did this, but it resulted in slower skill casting because it would wait some for the client. While checking to see if the client performed a cast or not is helpful, there was a lot of feedback that the bot was attacking too slow. As a result, that system is not currently in place, and it might be added again in a more limited way to avoid slowing down the bot too much.
Just as a reminder, the logic we provide will always be pretty basic and generic. There will be no planned support for Rampage or Beyond, but users can customize their CRs to make them work better for each league as needed. Beyond Portals are exposed though the object manager, but Rampage hud information is not available though the API. Unless there is a really good reason for Rampage information to be provided, it most likely remain a low priority thing.
Current Plans and Timeline
I cannot stress enough, Exilebuddy is not currently finished. This Beta release is just a step forward in being able to bot in 1.2+ using our new setup. The immediate goal is to start working on more logic and features to test the new API. Town stuff will be worked in as well as things like area looping, doing corrupted areas, and other stuff the previous bot implementation had. More information and progress will be talked about as it happens over this upcoming week.
Last edited:
