Exilebuddy Project Information
Exilebuddy is not your typical bot project. It's marketed just as a "bot", because that's what people understand. Exilebuddy is more than that though, so this post will try to adequately explain how the project is setup and why things are setup the way they are.
Starting out, Exilebuddy is not just "one" bot. Exilebuddy uses a design of being able to load custom bot implementations. The bots we provide, currently QuestBot and MapBot, are built the same way any user would make their own bot to use in Exilebuddy. This distinction is important to make, because when you talk about what Exilebuddy can or can't do, it's not the same as what the current bot implementations you are using can or can't do.
When you talk about the things Exilebuddy can or can't do, you're really talking about what the API supports and doesn't support. There's only a few things the API provided by Exilebuddy can't do right now. This is always changing because of how often the game changes, but we try our best to provide as close to complete client coverage as possible.
The API we provide though Exilebuddy, allows users full access to the game so they can write advanced bots, plugins, and combat routines. Our vision is to provide basic bots and functionality for the game, but empower the community to do more and create new and amazing things that better fits their needs.
Our setup is significantly different than most other bot projects out there, because our primary focus is writing an API for the game we're targeting. Then, using that API, we and the community, can create all sorts of things for the game that otherwise just wouldn't be possible using the traditional bot project setup.
Everyone has access to the bot implementation code we're using, as well as plugins, and routines. The only thing users don't have access to, is the actual API source itself, as that's our intellectual property we have to protect to keep the project going, and the core components that form the project itself, such as program gui code, auth, and our custom memory library used across all our bots.
Exilebuddy is an out-of-process memory bot. It does not use pixels to operate, so it is not a pixel bot. It does not use packets to directly perform actions, so it is not a packet bot. However, it does full mouse and keyboard input emulation in order to work. Exilebuddy is written in C# and uses several low level libraries written in ASM, C++, and C++/CLI.
Path of Exile has a unique client design that prevents the typical bot design most other Buddy bots use from working correctly. While we cannot get into the details about this matter, Exilebuddy is quite unlike all the other bots Buddy provides. A lot of things work in ways that most botters might not expect, especially ones that use other Buddy products. In most games, bots are able to call client functions to perform actions with 100% accuracy and reliability.
This is not the case for Path of Exile, and as a result, the bot is bound to the limitations a normal user is as well as the client implementation itself. To be more specific, Path of Exile as a game is known for its desync issue (which was mostly solved, but back again). That issue greatly affects the bot, because the bot is reliant on the client for it's information. There are many other client issues that affect the bot, and as a result, there will be noticeable things that happen that might not make sense, but are done in order to have a working bot for this game.
Beta vs Release
Exilebuddy comes in two versions: Release and Beta.
Exilebuddy (Release) is the "stable" version of Exilebuddy that is intended for most users to use. The purpose of Release is to give users something that doesn't change too often, except for bug fixes, to allow them to get comfortable with the bot and build up their own bots, routines, and plugins from the API.
ExilebuddyBeta (Beta) is the "experimental" version of Exilebuddy that is used to try and find new and better ways to make Exilebuddy work with Path of Exile. This version can be expected to change frequently, and is not meant for general use. At times, Beta might break and be completely unusable, so it is not recommenced for users to bot around this version.
Path of Exile is a game that changes very frequently. As a result, Beta has been predominantly used as the new latest and greatest version of the bot/API, as making a stable build becomes really hard when there are large amounts of changes and features that need testing after an update. All game updates are significant in Path of Exile. Unlike most other games, a lot of core game features change in this game, and as a result, the bot/API has to be updated to handle these changes.
Development Model
The model we use for bot development here at Buddy is as follows (for the bots we code):
- Start a project for a game and get a basic API working to build around (pathfinding, movement, skills, etc...).
- Get a simple simple grind/farm bot working that uses that API to get the project started for the masses.
- Extend and refine the API so it covers as much of the game as possible. Improve the basic bot as needed based on API changes.
- Build up and expand the community by offering a design that allows for community development and improvements, with the opportunity of commercial gains.
- Maintain the API and simple bot provided, letting the community take over "bigger and better things" using what is provided.
Unlike a lot of other bot development models, the model we use is to not to try and write and maintain a bot that has every feature possible. We do not sell bots based on features, nor promise any specific types of features. Our original goal was to make a working grind/farm bot and provide it along with an API for users to do the things they need. If the community wants better, they will develop it. If what we provide is good enough, they won't. As long as the basic bot we provide works, and the API allows users to do the things they need, everything is working as it should according to our intentions.
This is
our model, and how Buddy has found the success it has, and unless something changes in the near future, this is the model Exilebuddy is expected to adhere to.
Downtime Model
One of the biggest areas of confusion a lot of users seem to have, for some reason, is why we have frequent downtime, or lengthy downtime cycles after major client updates.
We always see wild conspiracies posted, and a lot of people saying really negative things, or spreading false rumors.
The answer is very simple:
our project is heavily dependent on the entire client as a whole, not just a few parts.
We don't expect anyone to truly understand what this means, but you don't get what Exilebuddy offers with little to no work or effort. Right now, Exilebuddy has just passed being a 4-year investment, and I can't even estimate how many total hours have been spent on this project, but it's exponentially greater than you could ever guess. Yes, it's
that much work.
Exilebuddy is not the type of project where we can throw a few hours of work each day or week, and then have what we currently do. What we have, is the result of a significant time and resource investment that we are really proud of, and we do take pride in what we offer, even though sometimes it doesn't look like much to users.
Because of this, and how much we really do care about the project and are invested, we do things our way, and ensure we're comfortable with the state of the project before doing any new releases.
We will never jeopardize our project for the sake of appeasing users who simply want us to do things their way, and have us abandon the practices that got us here in the first place.
While we try our best to keep downtime limited, Path of Exile is a really complex game, and more things affect us on a regular basis than other projects. We don't talk about every single issue that affects us, because most people wouldn't understand, and it's just part of the job, but when there's downtime, we need it.
Regardless of what nonsense people spam our forums with, please understand we only take as much downtime as we need, and our aim is to have Exilebuddy up and running as soon as possible after any update. If Path of Exile was a game that only updated once a month in a minor way, Exilebuddy would rarely have any downtime. However, that's not the case, so things are the way they are as a result of the game, not anything we're trying to hide from users.
API
The API typically executes in context of a rendered game frame. This means the more API calls and logic that takes place per each bot tick, the higher the frame overhead is on the game itself. Attempting to execute logic outside of the frame results in inaccurate memory reading, a lot of memory exceptions due to the client design, and overall bad bot performance, so that is why we affect the game performance.
There exists a problematic issue with how the API works with the game. This issue is best illustrated as the following:
- Memory valid at Tick X
- Some frame release or coroutine wait that results in a few game ticks (C) going by.
- Memory is now invalid at Tick X + C, because the client object has been moved or deleted, since we're out of process.
This is an issue that has always been present in Exilebuddy. At the start, it was much more common, but as time went on, we found ways to work around it. However, due to changes in the game and how the API has to work, this issue is now more frequently occurring when users don't plan around it.
The best way to work around the issue, is to cache all object data you need to process before you start using coroutine waits or API functions that cause the current frame to be release (pretty much anything that generates an action in the client). This way, if the object is invalid when it returns, you won't have exceptions thrown, because the data is already pre-stored.
This is just an issue we have to live with for the foreseeable future, due to the way this game works.
The main thing to keep in mind when using the API, is that latency and client performance (FPS) have an effect on logic. If you perform an action, you need to wait for a response from the server so the client updates its state. There is no way to handle the responses directly, as the API does not work with packets or hook events in the client, so some rough waiting has to be done, or frequent polling for the desired state. Sometimes, actions might fail, in which case, you need to handle something not happening, even though it should.
The best way to find API documentation is through the Help/Documentation.chm file, browsing the Exilebuddy assembly in Visual Studio, or looking at the code we provide. The game is always changing, so our API is always changing. There's never been a stable enough point in time to provide a useful help reference that would remain valid for long, so we hope with the release of 3.0, this will change.
Community Content
Our vision with the project is to build up a community that is able to make their development dreams for the game come true, as cheesy as that may sound. While it's not always on public display, I've personally seen people who have done some amazing things with our API, and it always feels good that it was possible because of our model.
Here at Buddy, we've seen the power from focusing on the API project approach time and time again. It's not a model we'll abandon for Exilebuddy, because each expansion and each new project cycle, things get bigger and better than ever before, and soon enough, post 3.0, we'll hopefully be where we want to be with a stable game that isn't changing so frequently.
However, there are always major "resets" that happen. This is due to the way the game changes, and how we have to keep changing to keep up with it. It's unfortunate breaking community code and not being able to fully support what everyone wants, but it's just part of the process, and probably why Path of Exile as a game is still around and only getting more and more popular each year.
We understand the frustrations that come along with developing for Path of Exile, as we would know best since we bear most of the labor. It still provides an interesting opportunity for community developers though, so while things are never ideal in terms of how long community content lasts, we hope things continue to improve as time goes on so we can actually achieve our vision to the fullest.
Community interest and involvement is a key part of our plans. We cannot focus on this at all times though, but after major updates and the game settles down, we'll be able to get back to trying to address the needs of the community where possible.
