With the release of Ascendancy, Exilebuddy has undergone several major API design updates. These were done to keep us up with the current state of the game, and should greatly help improve Exilebuddy in the future. Please note, this post covers API related stuff, and not the bot implementation related stuff (that is in the next post!).
Unchanged
Pathfinding
The current pathfinding library is an old copy of ours, from 2012-2013. We have a new updated version to use, but it was not possible to switch to it. The current system works decently, but the design of code that uses it, ExilePather, is in need of some major updates. For example, all pathfinding is done synchronously, so when many pathfinding operations are done, the bot will stop and wait for them to complete. Furthermore, support is limited for being able to correctly handle the terrain nuances of this game, which results in the bot getting stuck tying to go though narrow areas and the like.
Components/Object Manager/Objects
These things need a modernization update. This was partly done at the last big expansion with the simplification of the Item API, which has helped a lot. Further changes will help remove API bloat from over the years, and help improve performance in some places. However, for the time being, they are staying as-is.
Changed
GUI API
Please see the An Overview of Exilebuddy's GUI API Design thread for the new GUI related changes. This is the biggest set of API changes Exilebuddy has seen.
Input
Input has seen some major changes to offer better compatibility with the client and finally provide the expected behavior. The old implementation modeled input events on a global level, meaning if you just performed a mouse click, you'd have to wait the input event delay (default was around 100ms) before another input action was processed. This proved problematic, since you're able to perform mouse input and keyboard inputs at the same time. In addition, you can use multiple keys simultaneously, which is important for using flasks.
The new implementation now sets an input event delay of around 200-250ms each event, but each event is separately tracked. So for example, if you press the 1 key, there is a 200-250ms delay between when you can press the 1 key again, but, you can press any other key or event right away, as long as it too was not already on a cooldown. This design models more human like behavior, as the typical person can only click 4-5 times per second (there's a lot of sites that let you test reaction speed that were used to come up with this value).
In the old design, the average input events per second were 10, which translated into 600 input events per minute. With the new design, the max value (barring the user changing the values) is half that for each event type. However, additional changes have been made to how the Input API is being used by the bot/routine implementation to help greatly reduce this, yet makes things feel more fluid and fast compared to before.
API wise, a new function, SimulateKeyEvent replaces the previous key related functions (PressKey, ReleaseKey). This is to more accurately model keyboard messages, as sometimes you want to only send a down, or down/char/up, or only a up. In any case though, you want to do it all at once, as opposed to across multiple frames, which would happen in the old implementation.
The purpose of these changes is to make the bot play the game more human-like in terms of performing actions, while attempting to avoid looking like a bot due to high input actions per second/minute. We hope these will make a big difference moving forward, as users will definitely notice these changes when they run the bot.
Terrain Data
The implementation of terrain data has changed a bit. In the previous version, the API would cache terrain data per-area, then expose a set of raw data to anyone who wanted it. The new design now exposes the current terrain data, and a new cache class has been added to help avoid the overhead of reading all the terrain data multiple times per-area.
TerrainData.Cache (A CachedTerrainData object) tracks the current terrain data per-area. This data is reloaded on area change, to reduce memory usage as before multiple copies would exist in memory. This does increase some processing time on area-changes back to the old area, but is the first set of changes moving towards a better implementation (which falls under the Pathfinding stuff that didn't make it in).
A new class, WalkabilityGrid, has also been added. This is a wrapper class that operates directly on arrays of pathfinding data. In the old design, a similar class existed to store the walkablity status of a position, but it used a lot of memory and processing as it was a part of the old pathfinding library and never updated. This change should further help to reduce memory use and processing overhead.
Finally, a new function, UnblockTriggerableBlockages has been added to update pathfinding data that has been blocked off by triggerable blockages. For example, if pathfinding data is requested (non-cached) near a closed door, the door blocks off the two adjacent areas, and pathfinding operations would fail, which means the bot could not pathfinding though the area at all. To get around this, the triggerable blockage is "unblocked" in the data so the pathfinding data models what the terrain would look like if it was already opened. This functionality used to be internally applied to pathfinding data but is now exposed.
ExilePather
ExilePather has seen some changes in regards to the set of functions that calculate a walkable position for an object. In the old code, a rather bruteforce algo was used to find walkable locations near an object. These were commonly 30x30 grids at most, but some were much smaller. The problem with this implementation was that a pathfind was done for each point, so if the user was really far away, 100s of really long, time consuming pathfinds were done, which caused the bot to stop and wait since pathfinding is synchronous.
This is why the bot would randomly stop at times in towns when a new area transition came into view. Another problem with the implementation was that it had to code around several area transitions which had very specific nuances. For example, Catacombs has a stairwell that you need to travel down into before being able to interact with the area transition. Without the special handling, a location on the side could be chosen, and the bot would fail taking the area transition.
The new design removed all those functions in favor of a much simpler, smarter algorithm, that should help fix all area transition interactions. So far in testing, things look great, but tweaks will be added as needed if any new issues come up.
Unchanged
Pathfinding
The current pathfinding library is an old copy of ours, from 2012-2013. We have a new updated version to use, but it was not possible to switch to it. The current system works decently, but the design of code that uses it, ExilePather, is in need of some major updates. For example, all pathfinding is done synchronously, so when many pathfinding operations are done, the bot will stop and wait for them to complete. Furthermore, support is limited for being able to correctly handle the terrain nuances of this game, which results in the bot getting stuck tying to go though narrow areas and the like.
Components/Object Manager/Objects
These things need a modernization update. This was partly done at the last big expansion with the simplification of the Item API, which has helped a lot. Further changes will help remove API bloat from over the years, and help improve performance in some places. However, for the time being, they are staying as-is.
Changed
GUI API
Please see the An Overview of Exilebuddy's GUI API Design thread for the new GUI related changes. This is the biggest set of API changes Exilebuddy has seen.
Input
Input has seen some major changes to offer better compatibility with the client and finally provide the expected behavior. The old implementation modeled input events on a global level, meaning if you just performed a mouse click, you'd have to wait the input event delay (default was around 100ms) before another input action was processed. This proved problematic, since you're able to perform mouse input and keyboard inputs at the same time. In addition, you can use multiple keys simultaneously, which is important for using flasks.
The new implementation now sets an input event delay of around 200-250ms each event, but each event is separately tracked. So for example, if you press the 1 key, there is a 200-250ms delay between when you can press the 1 key again, but, you can press any other key or event right away, as long as it too was not already on a cooldown. This design models more human like behavior, as the typical person can only click 4-5 times per second (there's a lot of sites that let you test reaction speed that were used to come up with this value).
In the old design, the average input events per second were 10, which translated into 600 input events per minute. With the new design, the max value (barring the user changing the values) is half that for each event type. However, additional changes have been made to how the Input API is being used by the bot/routine implementation to help greatly reduce this, yet makes things feel more fluid and fast compared to before.
API wise, a new function, SimulateKeyEvent replaces the previous key related functions (PressKey, ReleaseKey). This is to more accurately model keyboard messages, as sometimes you want to only send a down, or down/char/up, or only a up. In any case though, you want to do it all at once, as opposed to across multiple frames, which would happen in the old implementation.
The purpose of these changes is to make the bot play the game more human-like in terms of performing actions, while attempting to avoid looking like a bot due to high input actions per second/minute. We hope these will make a big difference moving forward, as users will definitely notice these changes when they run the bot.
Terrain Data
The implementation of terrain data has changed a bit. In the previous version, the API would cache terrain data per-area, then expose a set of raw data to anyone who wanted it. The new design now exposes the current terrain data, and a new cache class has been added to help avoid the overhead of reading all the terrain data multiple times per-area.
TerrainData.Cache (A CachedTerrainData object) tracks the current terrain data per-area. This data is reloaded on area change, to reduce memory usage as before multiple copies would exist in memory. This does increase some processing time on area-changes back to the old area, but is the first set of changes moving towards a better implementation (which falls under the Pathfinding stuff that didn't make it in).
A new class, WalkabilityGrid, has also been added. This is a wrapper class that operates directly on arrays of pathfinding data. In the old design, a similar class existed to store the walkablity status of a position, but it used a lot of memory and processing as it was a part of the old pathfinding library and never updated. This change should further help to reduce memory use and processing overhead.
Finally, a new function, UnblockTriggerableBlockages has been added to update pathfinding data that has been blocked off by triggerable blockages. For example, if pathfinding data is requested (non-cached) near a closed door, the door blocks off the two adjacent areas, and pathfinding operations would fail, which means the bot could not pathfinding though the area at all. To get around this, the triggerable blockage is "unblocked" in the data so the pathfinding data models what the terrain would look like if it was already opened. This functionality used to be internally applied to pathfinding data but is now exposed.
ExilePather
ExilePather has seen some changes in regards to the set of functions that calculate a walkable position for an object. In the old code, a rather bruteforce algo was used to find walkable locations near an object. These were commonly 30x30 grids at most, but some were much smaller. The problem with this implementation was that a pathfind was done for each point, so if the user was really far away, 100s of really long, time consuming pathfinds were done, which caused the bot to stop and wait since pathfinding is synchronous.
This is why the bot would randomly stop at times in towns when a new area transition came into view. Another problem with the implementation was that it had to code around several area transitions which had very specific nuances. For example, Catacombs has a stairwell that you need to travel down into before being able to interact with the area transition. Without the special handling, a location on the side could be chosen, and the bot would fail taking the area transition.
The new design removed all those functions in favor of a much simpler, smarter algorithm, that should help fix all area transition interactions. So far in testing, things look great, but tweaks will be added as needed if any new issues come up.
Last edited by a moderator: