An Overview of the Beta 2.0 Revamp (Pre-Forsaken Masters Changes)

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.

 

Is the core setup for a bot/poi changed with the new API?

Meaning, is the structure and layout of a bot still the same, and just the co routines/loki information changed, or will we need to change the base layout out bot/plugin/poi to match the new api? I'm asking this because I am writing a lot of Pseudocode while I wait on the new beta, as I want to hash out the structure and design of a new inventory bot. I just want to make sure that how I structured it won't have to change, just the actual coroutines/api that I am using.

Also, more then anything I would love the ability to reload without closing/opening/logging in again (Al through everything else your are working on is probably higher priority).

 

keep in mind. GGG has been known to to put fixes for patches within a day or two, so a few of those fixes will slow things down quite a bit.

 

Great read! I am pleased to read all of this and happy with the work you guys put in to this. Question, With the new "going through the UI" does that mean that we as a user won't be able to use our keyboard and mouse anymore ?

Secondly, for using the new path explorer do you "record" maps or do you have to type in co-ordinates or type out stuff on visual studio ? I'm seriously trying to get into boss farming with this and mapping once the patch is released.

 

I don't have an answer for the first thing yet. I'd like to use a different design that addresses the problems Beta 1 still had with the Poi implementations.

However, there's an inherent design issue that will be the bane of all problems:
When you design around modularity, you sacrifice specialization and the ability to have things to all work together coherently.
When you design around specialization, you sacrifice modularity and the ability for things to be easily changed or tweaked.

You can't have both really, and if you try to settle for the middle ground, you end up with something that doesn't go too far because it's a jack of all trades, and a master of none.

To give a practical example, the grind bot was just a grind bot. The way the logic was designed, was such that it didn't have to worry about things like quest states, or being able to change what it does in town to cater to a different mode (e.g, map running logic). Trying to add in map logic would be impractical, because it changes how the bot works as a whole, and over-complicates it, making tracking down bugs and other state errors a real problem, which was something Release had issues with for the longest time.

While a map bot makes sense to have separate from the normal world grind bot, you then run into conflicts with things like questing. A quest bot on its own doesn't make much sense, because you're just going though each area, grinding until you find what you need to do. OTOH, a grind bot doesn't need full quest logic, as much as just parts of it to not get stuck at various places in the game, e.g., Mud Flats.

Trying to take two separate parts and work them together after the fact is really hard. You end up with problems like Release had with people chickening in an instance, but the bot needs to go though that instance and didn't have the means to start a new instance on demand (by design) so it'd get stuck. In Beta 1, I solved that issue with AreaStateCache, but the reason was knowing we need the ability to do "X" and have persistent area data.

The idea solution would be to code a new bot that takes into consideration questing and grinding, so the logic can handle both. Since 1.2 is adding the new core game content to end game maps, the idea of making a map grinding bot on itself now goes out the window, because it has to be able to handle the other normal game mechanics.

That means we need an entirely new design. So, I'll have to play around with a few ideas and try to come up with something that will end up working well for how the game will now work after 1.2, as the way it was going to work before, is different. This week I'll be doing some thinking on the matter and trying out different things before picking something to go with for the new Beta bot.

As for the second issue, the core cannot be changed to support that, because we already have a runtime code complication/execution system in place to host multiple bots/plugins/routines. However, you can make your own IBot implementation that allows for that, so you get what you want in our current environment. I've just finished writing the Exilebuddy Developer's Guide to Writing Bots, so have a look over that.

For the example, I made what you asked about with a runtime compile setup, but it's just a basic example. There's a lot of different directions you can go with it, or even use a different setup, but I think that should be enough to point you in the right direction. The idea of being able to do that is great, but when it comes to actual implementation, you'll run into some specific issues that you have to work around. There's no silver bullet solution for it though, but using CodeDOM has already proved really beneficial with the Dev Tab as I've been doing stuff in Beta.

I knew I probably should have clarified that first point, but no, you will still be able to use your mouse and keyboard as you currently are. It's just you'll see your client performing the actions as if you were (minus seeing the mouse cursor). User intervention while the bot is doing UI operations can interfere with them though, as there's no way to block the input from a user. For example, let's say the bot is scrolling though your stash tab list. If you switch to the game window and start clicking inside it, the game thinks you are doing a different action now, and will cancel the tab scroll. This can interfere with a few API functions, but I'll make sure to add warnings to the actual guide about these and what users need to be careful of.

Pretty much all areas (except for towns) in this game are dynamically generated with a different layout / set of coordinates. Some areas have less variety in their generation due to their tileset being applied a very limited number of ways, for example, The City of Sarn, but for the most part, most areas are not that way.

The explorer's job is to create a means for the bot to figure out a way to explore the entire map (for standard grind logic) or find a way to explore towards a goal (like in bossfarmbot). There's no way to really know exact coordinates or anything ahead of time due to the way the game works. The server only sends a limited amount of information to the client in terms of things close by it, so you can't see an area transition across the map. However, there are certain things that can be taken advantage of, which is what the BossFarmBot explorer did, and "guess" where to go based on the generated tiles the map currently has. In the case this system were to be changed, it would no longer be possible, and the bot would pretty much have to full explore an area until it finds what it is looking for.

So, for maps and the general case of things, you end up laying out a grid across the world, and visit each cell until you find what you are looking for. That's the approach that you take for any area really, and it applies to maps, corrupted areas, races, and just about anything else the game will add.

 

Good progress pushedx!

 

I have done alot of work with Honorbuddy and Demonbuddy with botbases, profiles, and plugins.

I just picked up Path of Exile today, if I can be of any help with beta development just let me know.

 

Good to hear. 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: Exilebuddy Developer's Guide to Writing Path of Exile Bots as something I'd give to anyone interested in doing stuff with this game. It covers a lot of broad aspects of the game that affect development in ways you might not have seen in previous experiences.

 

not support the TW Garena Path of Exile

 

Garena SG/TW support is not possible for now. It will be considered in the future though!

 

it seems the beta is almost already, any ETA?

 

The goal is to have something basic back in your guys hands by tomorrow, but 1.2.0c has been announced that might interfere, depending when it's released, and cause a little more downtime.

Right now, the API should pretty much be updated and working for 1.2, with perhaps a few missed things in less commonly used parts, or just bugs from new logic (I've been doing as much testing as possible to try and cover all the cases, but this game has a lot of weird things that can happen).

The logic for the new bot is really basic, and that's what's being worked on right now. It's not going to have nearly as many features or support the things the previous versions have for a bit because rewriting an entire bot in a few days is impossible from a time standpoint. 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.

 

Just want to say what a fantastic job the core devs are doing! Keep up the good work and thanks pushedx for the constant updates!

 

What can we expect for the update ? similar to what was left off in the last beta ? ie grindbot, and boss farming ? or just grindbot ? maybe a gem leveler ?

 

Exceptions should be set very low for the grind bot that is being released hopefully today. Basically, this Beta release is for testing the new API and general 1.2 compatibility. As a result, the grind bot being provided will be really simple and not be able to do much. Expect there to be about a week at minimal of testing and bugs and improvements before it's comparable to what the old Release had. I'll explain all this in the new Beta thread later today, but right now the focus is getting something people can test with 1.2 as soon as possible.

Gem leveling is supported by the new API, so that should be doable as a basic feature.

 

Would be in for Testing.
Have Summoners, Melees and Specs

 

The actual CR will be a basic assign melee skill and assign ranged skill, but it will have logic examples for summoners, including some things we never have had support for before, animated guardian and animated weapon. Flameblast had some example logic as well, and incinerate works simply by treating it as a melee spell and simply casting it over and over to build up stacks (that's how it works in the client).

Other random things like totems, curses, traps, and mines might come a later day, but we'll see.