This thread will detail the upcoming changes to Beta in preparation for the Forsaken Masters update. A different thread will contain stuff for 1.2 when it comes and the bot is updated for it. Everything is subject to change as usual, as full information about the 1.2 update will not be known until the day before the patch. There will be noticeable downtime expected, as 1.2 will be a very large update, and it's assumed a lot of client changes will take place. The API/bot will be updated as soon as it can, but user safety and making sure everything still works is a top priority. We'll take as much time as needed to try our best to avoid any update disasters (bans, flags, crashes, etc...).
The state of the Beta (at the time of this post) is as follows: the core API that interacts with the client has been fully rewritten (except for movement/skill use stuff). API support covers almost the entire client, but a few things have to be left out for now (player trading, passive skills, party stuff). This is a massive change, which took about a week to do (if more time was available, it certainly would have been taken, but it's not). The new API fundamentally changes how the bot works with the client. All client interactions are now done though the GUI, so you will notice things you've never see the bot do before. The bot will now interact with the game as if a user were moving the mouse around and pressing keys. Before, the API would emulate a lot of these actions to avoid the complexities of working though the GUI.
To see a preview of the new API: An Overview of Loki: Exilebuddy's API for Path of Exile. Beta currently does not have any bot logic, routines, or plugins. They have to be rewritten for the new API. We hope to get as much as possible updated before the patch, but obviously time is not on our side. Depending on the actual 1.2 patch, this may or may not be a good thing depending on what changes. Not having a lot of existing logic to update means we can finally start building from the ground up, assuming the new API fixes all of the problems it's meant to (which the last rewrite unfortunately didn't).
Beta 1.0, was very useful in understanding how we can structure the project better to keep up with the nature of this game. The majority of the core design changes made in Beta 1, are being used in Beta 2. That is, the GUI is the same, the setting system is still in place, and the overall IBot/IPlugin/IRoutine setup is mostly the same (only some interface changes really). The purpose of this new design is to allow more agile development of plugins, bots, and routines. In short, development with PoE is very volatile and things have a very short lifetime compared to most other games.
The new leagues will be 3 months long. If you were to take, say a month, to develop a highly tuned CR for the Rampage league for a build, it would only be applicable for 2 more months, before the big unknown of seeing if that league's features make it it into the core game or not. Actual development time will vary person to person, but the point is, development with EB has to take the nature of the game into consideration from here on out more so than before. A lot of people are unhappy with the generic nature of the things we provide, but that's the way it has to be, and will continue to be as long as there are things to do with the API and the actual design of the project. We cannot focus on specialized logic that would otherwise be possible by someone in the community under that circumstance. If the game goes though another period of time where it's not changing a lot, and the API is where it needs to be, then we can. Considering the next expansion has already been announced for March, and another set of 3 month leagues will follow these, I think that is highly unlikely though.
Getting back to the Beta itself, quite a few issues need to be addressed after seeing 1.0 feedback. Not everything will be mentioned, just some of the bigger points that seemed to cause waves.
The first is the speed of the bot, and how it uses skills. Beta 1.0 used a new design of performing one action at a time. This was done for several reasons, but it had a side effect of appearing really slow for any builds that had high attack speed. The design of using skills will be changing in Beta 2.0 to address this directly. Certain skills, like Leap Slam, do not need to be cast as fast as possible, because there are cases where the client fails to use them (due to client bugs with pathfinding). The Beta 1.0 design of using skills is very helpful for skills like those, because it tries to see if the client used the skill or not. If it doesn't, then skill logic can recover, and the bot won't get stuck trying to cast the skill over and over (like Release does).
Other skills, such as anything projectile based, are the opposite. They can be cast as fast as possible, and it's actually more useful to stand in a spot and cast continuously rather than cast once, and then check to see if the bot needs to move before casting again. Beta 2.0 will offer a new casting mode for skills like these. The bot will start the first skill use at a position, and then continue to use that skill until the user stops it. The destination can be moved around as needed. The attack mode has to be "in place" though, and it will be up to the user to stop casting when out of mana, or the target is dead, etc... This new design allows for skills like Flameblast to work properly, and skills like Incinerate can have logic more easily coded with the use of coroutines to get the most out of it. That is, start combat and keep attacking towards new targets rather than cast -> stop -> cast -> stop.
The second issue is various client sided behaviors. Always Highlight is used by the bot to fix client bugs with UI labels. Some users were worried about the use of this feature causing bans/flags, but it is impossible for that to happen, because it's a client sided effect. Even so, Beta will take a new approach and throttle the use of Always Highlight to put people's worries to rest. Always Highlight is required by the bot though, as the client has very specific logic that makes doing certain tasks near impossible without it, e.g., looting items.
The third issue, is the use of "Move Only". The bot requiring Move Only on the skill bar was to help solve various issues with the client's "auto-action detection" interfering with movement. That is, if you highlight an object, and click, it determines if you should move, interact, or attack. This makes handling some things more complex, such as moving around portals, waypoints, etc..., but moving forward, the bot will no longer require this action to be used. We feel at this point, the loss of the skill slot, and the results of the bot needing it, could potentially add unnecessary risk, given how aggressive GGG is with bots. That is not to say it's unsafe using Move Only, or we have any reason to believe GGG is looking at accounts who use it, as it's a core feature of the game, but from a botting perspective, we need to improve our logic so it's not required to avoid any worries about that being a possibility.
The forth issue is improved API support for various things. The Beta API exposes more information from the game than any past version has. We now have API support for commonly requested things such as smart filtering (if there was such a thing), vendor buying (which will be a big thing for 1.2), and proper trap support (i.e., it can handle the charges correctly rather than using one then waiting on the CD). Having API support for most things in the client is important, because it allows devs to do things with this game that people might not have though of yet. There is a slow turn around for actually making use of all the new things, but since the bot logic is being rewritten for the new API, more of these things can be considered for use now.
With the significant Beta 2.0 API changes for interacting with the client, the previous issues with inventory should be fixed now as well. The bot will no longer need to request all stash tabs, or a certain number. Instead, the logic will be setup for users to choose the tabs the bot needs to use, and then it will simply switch to them as a user would. This should cut down on time in town for people with a lot of stash tabs, as well as address any worries people have had about spending so much time in town at stash each town run. Due to the way the game works, in order to take advantage of purchase logic, the bot will have to go to stash and request the same stash tabs each time, as otherwise the game cannot find the items used to purchase
Please remember though, our focus is providing a full featured solid API and a basic working bot. Until we have more people in the community writing bots, plugins, and routines, it is not possible to do everything required for maintaining the API and provide an amazing stock bot, especially in a game like this. That leads into to the next issue.
The fifth issue is the nature of this project requiring coding to "get what you want". That aspect will never change in a game like this. It is not possible to offer bots, plugins, routines that work every way each user wants, and is setup in such a way they can just tweak little things to their liking. Trying to do that in a game like this that changes very frequently is not feasible without many people who are dedicated to working on it full time, and considering maintaining the API and trying to keep a basic "dumb" bot working is already more than enough full time work, it will not be attempted. That is not to say improvements to what we provide and allowing people to customize various aspects of it though the GUI aren't going to be made, as Beta 1.0 saw a lot of improvements in this regard over Release, but there's only so much that can be done before just coding a new bot/plugin/routine would be easier and less work to get precisely what you want as opposed to the means to try and configure something large and bulky that works for everyone.
The sixth issue is pathfinding. There's a difference between pathfinding and exploration. Exploration is how the bot explores an area, which in Beta 1.0, was totally configurable for the first time so users can implement their own explore logic for more efficient runs, etc.. The boss farm bot came with a special explorer that would run towards the area it needed to go. Pathfinding, is the actual generation of paths to a target location. A lot of times, in narrow tilesets, the bot will hug walls, or do a short cycle around a door before going though. These are issues with the nature of the game's truly random (but tileset based) area generation and the pathfinding library we are using. In short, there's no way to tweak things per-area to get the best results and avoid those issues. The old Release used to have a lot of issues with movement and pathfinding, but most of those issues have been taken care of now. Beta 1.0 changed how movement logic worked, with the function ClickToMoveTowards, which helped a ton avoiding issues like stuttering. Beta 2.0 will use similar functions with the new API to try and keep things as smooth as possible.
Lastly, I'm sure there's a lot of questions about when will "X" be done, or when will the bot have feature "Y", but the answer to pretty much all those questions is "as soon as it's doable". Testing the new API and making sure it actually works is the top priority for 1.2, as everything new builds on top of it. This new API is pretty much the equivalent of having an entirely new bot, so there might be some early issues that need to be taken care of. As a result, there might not be a stable Release build for some time. However, for the long run, these changes are needed in the continued efforts to providing an API/bot that works for the game, and allows devs to do what they need with as minimal risks as possible.
That about covers the main points. More info on the changes to the actual bot/routine we provide will be made as soon as it's ready to use. The plan is to try and finish up the rest of the mandatory API (movement, skills) and create some API testing scripts within the next few days before publishing an API only Beta. From there, replacement stuff using the new API will be worked on and slowly released up until the 1.2 update itself.
The state of the Beta (at the time of this post) is as follows: the core API that interacts with the client has been fully rewritten (except for movement/skill use stuff). API support covers almost the entire client, but a few things have to be left out for now (player trading, passive skills, party stuff). This is a massive change, which took about a week to do (if more time was available, it certainly would have been taken, but it's not). The new API fundamentally changes how the bot works with the client. All client interactions are now done though the GUI, so you will notice things you've never see the bot do before. The bot will now interact with the game as if a user were moving the mouse around and pressing keys. Before, the API would emulate a lot of these actions to avoid the complexities of working though the GUI.
To see a preview of the new API: An Overview of Loki: Exilebuddy's API for Path of Exile. Beta currently does not have any bot logic, routines, or plugins. They have to be rewritten for the new API. We hope to get as much as possible updated before the patch, but obviously time is not on our side. Depending on the actual 1.2 patch, this may or may not be a good thing depending on what changes. Not having a lot of existing logic to update means we can finally start building from the ground up, assuming the new API fixes all of the problems it's meant to (which the last rewrite unfortunately didn't).
Beta 1.0, was very useful in understanding how we can structure the project better to keep up with the nature of this game. The majority of the core design changes made in Beta 1, are being used in Beta 2. That is, the GUI is the same, the setting system is still in place, and the overall IBot/IPlugin/IRoutine setup is mostly the same (only some interface changes really). The purpose of this new design is to allow more agile development of plugins, bots, and routines. In short, development with PoE is very volatile and things have a very short lifetime compared to most other games.
The new leagues will be 3 months long. If you were to take, say a month, to develop a highly tuned CR for the Rampage league for a build, it would only be applicable for 2 more months, before the big unknown of seeing if that league's features make it it into the core game or not. Actual development time will vary person to person, but the point is, development with EB has to take the nature of the game into consideration from here on out more so than before. A lot of people are unhappy with the generic nature of the things we provide, but that's the way it has to be, and will continue to be as long as there are things to do with the API and the actual design of the project. We cannot focus on specialized logic that would otherwise be possible by someone in the community under that circumstance. If the game goes though another period of time where it's not changing a lot, and the API is where it needs to be, then we can. Considering the next expansion has already been announced for March, and another set of 3 month leagues will follow these, I think that is highly unlikely though.
Getting back to the Beta itself, quite a few issues need to be addressed after seeing 1.0 feedback. Not everything will be mentioned, just some of the bigger points that seemed to cause waves.
The first is the speed of the bot, and how it uses skills. Beta 1.0 used a new design of performing one action at a time. This was done for several reasons, but it had a side effect of appearing really slow for any builds that had high attack speed. The design of using skills will be changing in Beta 2.0 to address this directly. Certain skills, like Leap Slam, do not need to be cast as fast as possible, because there are cases where the client fails to use them (due to client bugs with pathfinding). The Beta 1.0 design of using skills is very helpful for skills like those, because it tries to see if the client used the skill or not. If it doesn't, then skill logic can recover, and the bot won't get stuck trying to cast the skill over and over (like Release does).
Other skills, such as anything projectile based, are the opposite. They can be cast as fast as possible, and it's actually more useful to stand in a spot and cast continuously rather than cast once, and then check to see if the bot needs to move before casting again. Beta 2.0 will offer a new casting mode for skills like these. The bot will start the first skill use at a position, and then continue to use that skill until the user stops it. The destination can be moved around as needed. The attack mode has to be "in place" though, and it will be up to the user to stop casting when out of mana, or the target is dead, etc... This new design allows for skills like Flameblast to work properly, and skills like Incinerate can have logic more easily coded with the use of coroutines to get the most out of it. That is, start combat and keep attacking towards new targets rather than cast -> stop -> cast -> stop.
The second issue is various client sided behaviors. Always Highlight is used by the bot to fix client bugs with UI labels. Some users were worried about the use of this feature causing bans/flags, but it is impossible for that to happen, because it's a client sided effect. Even so, Beta will take a new approach and throttle the use of Always Highlight to put people's worries to rest. Always Highlight is required by the bot though, as the client has very specific logic that makes doing certain tasks near impossible without it, e.g., looting items.
The third issue, is the use of "Move Only". The bot requiring Move Only on the skill bar was to help solve various issues with the client's "auto-action detection" interfering with movement. That is, if you highlight an object, and click, it determines if you should move, interact, or attack. This makes handling some things more complex, such as moving around portals, waypoints, etc..., but moving forward, the bot will no longer require this action to be used. We feel at this point, the loss of the skill slot, and the results of the bot needing it, could potentially add unnecessary risk, given how aggressive GGG is with bots. That is not to say it's unsafe using Move Only, or we have any reason to believe GGG is looking at accounts who use it, as it's a core feature of the game, but from a botting perspective, we need to improve our logic so it's not required to avoid any worries about that being a possibility.
The forth issue is improved API support for various things. The Beta API exposes more information from the game than any past version has. We now have API support for commonly requested things such as smart filtering (if there was such a thing), vendor buying (which will be a big thing for 1.2), and proper trap support (i.e., it can handle the charges correctly rather than using one then waiting on the CD). Having API support for most things in the client is important, because it allows devs to do things with this game that people might not have though of yet. There is a slow turn around for actually making use of all the new things, but since the bot logic is being rewritten for the new API, more of these things can be considered for use now.
With the significant Beta 2.0 API changes for interacting with the client, the previous issues with inventory should be fixed now as well. The bot will no longer need to request all stash tabs, or a certain number. Instead, the logic will be setup for users to choose the tabs the bot needs to use, and then it will simply switch to them as a user would. This should cut down on time in town for people with a lot of stash tabs, as well as address any worries people have had about spending so much time in town at stash each town run. Due to the way the game works, in order to take advantage of purchase logic, the bot will have to go to stash and request the same stash tabs each time, as otherwise the game cannot find the items used to purchase
Please remember though, our focus is providing a full featured solid API and a basic working bot. Until we have more people in the community writing bots, plugins, and routines, it is not possible to do everything required for maintaining the API and provide an amazing stock bot, especially in a game like this. That leads into to the next issue.
The fifth issue is the nature of this project requiring coding to "get what you want". That aspect will never change in a game like this. It is not possible to offer bots, plugins, routines that work every way each user wants, and is setup in such a way they can just tweak little things to their liking. Trying to do that in a game like this that changes very frequently is not feasible without many people who are dedicated to working on it full time, and considering maintaining the API and trying to keep a basic "dumb" bot working is already more than enough full time work, it will not be attempted. That is not to say improvements to what we provide and allowing people to customize various aspects of it though the GUI aren't going to be made, as Beta 1.0 saw a lot of improvements in this regard over Release, but there's only so much that can be done before just coding a new bot/plugin/routine would be easier and less work to get precisely what you want as opposed to the means to try and configure something large and bulky that works for everyone.
The sixth issue is pathfinding. There's a difference between pathfinding and exploration. Exploration is how the bot explores an area, which in Beta 1.0, was totally configurable for the first time so users can implement their own explore logic for more efficient runs, etc.. The boss farm bot came with a special explorer that would run towards the area it needed to go. Pathfinding, is the actual generation of paths to a target location. A lot of times, in narrow tilesets, the bot will hug walls, or do a short cycle around a door before going though. These are issues with the nature of the game's truly random (but tileset based) area generation and the pathfinding library we are using. In short, there's no way to tweak things per-area to get the best results and avoid those issues. The old Release used to have a lot of issues with movement and pathfinding, but most of those issues have been taken care of now. Beta 1.0 changed how movement logic worked, with the function ClickToMoveTowards, which helped a ton avoiding issues like stuttering. Beta 2.0 will use similar functions with the new API to try and keep things as smooth as possible.
Lastly, I'm sure there's a lot of questions about when will "X" be done, or when will the bot have feature "Y", but the answer to pretty much all those questions is "as soon as it's doable". Testing the new API and making sure it actually works is the top priority for 1.2, as everything new builds on top of it. This new API is pretty much the equivalent of having an entirely new bot, so there might be some early issues that need to be taken care of. As a result, there might not be a stable Release build for some time. However, for the long run, these changes are needed in the continued efforts to providing an API/bot that works for the game, and allows devs to do what they need with as minimal risks as possible.
That about covers the main points. More info on the changes to the actual bot/routine we provide will be made as soon as it's ready to use. The plan is to try and finish up the rest of the mandatory API (movement, skills) and create some API testing scripts within the next few days before publishing an API only Beta. From there, replacement stuff using the new API will be worked on and slowly released up until the 1.2 update itself.
We definitely could use people doing things with the API once the 1.2 update is done to get things started up again. I just updated the first part of: 
It will get back to where it was before, using the new API though, it's just going to be a rough few weeks redoing things.