Notice of large upcoming api/bot changes

[pushedx]

Exilebuddy will be receiving some major API and structure changes over the next few weeks-months. In the past, most changes have been made to try and avoid changing the API, but it's time we break the API to better position EB so users can have the bot they really want. This mostly means that users should download clean copies of the bot rather than updating, and they might have to update their custom code a lot more than normal. We know this is an inconvenience, but it's required for gearing up EB for long term development.

The first large upcoming change is with the inventory API. The current inventory API was only a placeholder when it was first added a long time ago. We just never got around to properly updating it, due to having to address other things with the bot/API. It is being reworked for the following reasons:

• To support the map device. The map device uses the inventory system the rest of the game does, we need something a little more improved to correctly place items into it. While it is not final, the new method of moving a map or map fragment to the map device when it is open is as follows: InventoryItem.MoveToMapDeviceTopLeft, InventoryItem.MoveToMapDeviceTopRight, InventoryItem.MoveToMapDeviceBottomLeft, InventoryItem.MoveToMapDeviceBottomRight.
• To more easily support CR logic that needs to perform snapshots (RF).
• To support easily taking quest rewards. The future of EB includes being able to do quests, so being able to accept quest rewards is a must.
• To support using currency on Strong Boxes.
• Trading support. Eventually, making a trade bot will be possible with the API. While there are obvious design issues that have to be considered, EB will at least support working with trade dialogs.
• Buying support. Being able to visit a vendor and buy items each level up is a desired feature, and support will be added to the API for this.
• Better support for slots than we currently have. The current system is somewhat messy, but the new changes will simplify this a bit. Rather than accessing the inventory through the Me object, it'll be done through a static class in LokiPoe now.
• More utility functions. A lot of the logic for inventory stuff is contained in Registry, which was just a class that holds a bunch of random stuff. Inventory stuff is being moved to the appropriate places, so users can access the functions is a more intuitive way.
• Changing how stash tabs are requested. The old logic would throw exceptions and request stash tabs in places it probably shouldn't. As a result, the approach for working with stash tabs is being reworked to only search the tabs the client knows about. The user will have to request the tabs it wants to work with instead.
• Various bug fixes with things like the Gem Leveler, which relies on the inventory API and under certain scenarios, it might have been possible for gems to fail to level (but most of those are from caching issues more than likely).
• Support for working with skill gems on the cursor. The bot will eventually be able to place skill gems and remove them, which is needed for fully automated bot logic.
• Support for guild stash pages. There's not been a real need for them, but supporting them in the API would be good. The game actually has an implementation for them that doesn't match Stash tabs, so the API is separate from normal Stash.
• Docs and usage examples. Some new guides and stuff will be made going over the new system.

These api changes will be making their way into the API this week and some of the new stuff will be integrated into the bot the following week. However, don't expect a lot of logic updates, because those are time consuming and require a lot of testing first. As a result, Beta will receive very large updates, followed by minor bug fix patched for the new code rather than a more steady stream of small updates. Before a beta is pushed with the changes, it'll be tested as thoroughly as possible, but some users might want to rely on Release instead.

These changes are just the first of many large upcoming sets. Inventory stuff is changing first, because it's not dependent on other code, while a lot of bot logic is dependent on it. Rather than updating other code first, and using the current inventory api, it makes more sense to update inventory stuff first, so when the other code is rewritten, it can take advantage of the new stuff. More posts similar to this one will be added to this thread as time goes on and the systems are almost ready to be integrated into the bot.

 

[maths]

what would be really awesome to have is an interface to set our flask into the bot instead of going into exile.cs to set them (im to nood to make the setting i want) we could have a case we could check to use the flask we want and a % to adjust them when to use them, i know its must be very complex to add this to the bot, but it would be very user friendly. i would really like to have an easy way to set my atziri flask to, i never been able to add what needed to use it in the exile.cs

 

[imdivesmaintank]

This stuff sounds awesome. I can't wait.

 

[Nixon233]

Great. This is a ton of stuff I like to hear especially the mapping. Questions for you, firstly, regarding to the pickit. Will we be able to filter user specified affixes/ suffixes/ or filter by dps or elemental dps?

Secondly, will we be able to set the bot to use chance orbs on certain gear ?

 

[Crumpet_]

And this is why i pay. yay for EB.

Cheers pushedx

 

[pushedx]

what would be really awesome to have is an interface to set our flask into the bot instead of going into exile.cs to set them (im to nood to make the setting i want) we could have a case we could check to use the flask we want and a % to adjust them when to use them, i know its must be very complex to add this to the bot, but it would be very user friendly. i would really like to have an easy way to set my atziri flask to, i never been able to add what needed to use it in the exile.cs

This is a tricky issue because anything we add a gui and settings for, automatically confines people who use it to the absolute basics, and they miss out on one of the most important aspects of the way Buddy bots works. I do think there are better ways through code to do what we want yet still make it easier for people to customize their stuff than how things are now. Exile is a mess, plain and simple, but only because it was the best way we could think of trying to handle things in this game. By now, we've seen the issues with it, and can look towards alternatives ways to do things and making certain things a lot easier for users. This game is a lot different than the others, and we've learned a lot of new things along the way.

Exile will be changing in the near future, but I'm not sure how much gui stuff will be tied in yet. At minimal, we probably should, and would add a simple edit box for what levels of health/mana to use a flask, but anything else past that will lead to settings bloat, and result in a system worse than what we have now I think. We'll be doing some thinking of how we can improve things while keeping the flexibility we want users to have without all of the complications.

Great. This is a ton of stuff I like to hear especially the mapping. Questions for you, firstly, regarding to the pickit. Will we be able to filter user specified affixes/ suffixes/ or filter by dps or elemental dps?

Secondly, will we be able to set the bot to use chance orbs on certain gear ?

This update is just an inventory API update. The actual item API update will most likely come later, after the new casting/movement features are worked in. I was really hoping to already have that stuff (casting/movement) worked in, but it's just too large of a change to do yet. This inventory api change is rather large too, but it's easily tested for the most part. I just have to write a bunch of examples to test it and it's pretty much done. Only one change actually affects the current bot, which is how stash tabs are processed, but that's not too bad to deal with since it's town stuff.

There's two parts to what you are asking for the second thing. Right now, the API supports doing that, so it's just a matter of having a plugin that does it. However, due to the way the bot was setup when we rewrote it after the flagging issues, actually making a plugin to do that is not easy to say the least, if possible. As a result, rather than trying to hack in a bunch of features like that short term, the plan is to fix the structure of the bot so users can actually use the bot like we intended them to, so you can write a plugin to do that and it'll work seamlessly with the bot.

Once we have the structure back to being what it needs to, then making examples of doing tings like that becomes trivial and we can just take a day, write some code and test it, then post it on the forums for users. Right now, that's not really possible, since the bot lacks various user hooks and stuff.

 

[maths]

This is a tricky issue because anything we add a gui and settings for, automatically confines people who use it to the absolute basics, and they miss out on one of the most important aspects of the way Buddy bots works. I do think there are better ways through code to do what we want yet still make it easier for people to customize their stuff than how things are now. Exile is a mess, plain and simple, but only because it was the best way we could think of trying to handle things in this game. By now, we've seen the issues with it, and can look towards alternatives ways to do things and making certain things a lot easier for users. This game is a lot different than the others, and we've learned a lot of new things along the way.

Exile will be changing in the near future, but I'm not sure how much gui stuff will be tied in yet. At minimal, we probably should, and would add a simple edit box for what levels of health/mana to use a flask, but anything else past that will lead to settings bloat, and result in a system worse than what we have now I think. We'll be doing some thinking of how we can improve things while keeping the flexibility we want users to have without all of the complications.

you could leave the choice to use the gui interface for flask or not, if you add it, I think that could be good for those who need more deep setting and good for noob like me to and a question. when it say 'uncomment this' to activate the flask do i uncomment all the comment or only // and would you be able to add the atziri flask in the setup or give me a copy of the code i could copy past in my exile.cs to make it work as soon as i reach 70%hp, i tried but i just make the bot bug, i never done those thing before

 

[bazookaworm]

you could leave the choice to use the gui interface for flask or not, if you add it, I think that could be good for those who need more deep setting and good for noob like me to and a question. when it say 'uncomment this' to activate the flask do i uncomment all the comment or only // and would you be able to add the atziri flask in the setup or give me a copy of the code i could copy past in my exile.cs to make it work as soon as i reach 70%hp, i tried but i just make the bot bug, i never done those thing before

no, you want to uncomment the /* */

For example if you wanted to dispel shock with your flasks:

[B][COLOR="#FF0000"]/*[/COLOR][/B]new Decorator(ret => _flaskCd.IsFinished && Me.HasAura("shocked") && ShockedFlasks.Count() != 0,
                    new Action(ret =>
                    {
                        ShockedFlasks.First().Use();
                        _flaskCd.Reset();
                    })),[B][COLOR="#FF0000"]]*[/COLOR]/[/B]

Remove the red text

 

[Harmacintyre]

My 2 cents on flasks. There is a flaw in the design where the weight value to keep attacking > using a potion. As humans we realize, hey lets mash buttons, I can use a potion AND attack. From what I have observed, it might use a lot of time targeting, which is not always a bad thing tho, just sometimes with these flask cases. This game is not like others where you shoot an arrow at a mob and it follows it until it gets hit. These monsters dodge your shit. One temporary fix other than getting the coding "Perfect" for POE combat would be to just raise the % like people said. One thing many people aren't considering is that in my mind, a GUI is the least important part of the code. Sure its nice to have the basics of selecting your CR's and enabling plugins. But all of this can technically be done with true false statements that we could enable and disable in the coding itself. Cough Cough. What I mean to say is. I am sure you can find the flask % in the code. Not a rant, just went through all of this with their other bots and the only real solution to a smooth bot is time and experience.

 

[pushedx]

My 2 cents on flasks. There is a flaw in the design where the weight value to keep attacking > using a potion. As humans we realize, hey lets mash buttons, I can use a potion AND attack. From what I have observed, it might use a lot of time targeting, which is not always a bad thing tho, just sometimes with these flask cases. This game is not like others where you shoot an arrow at a mob and it follows it until it gets hit. These monsters dodge your shit. One temporary fix other than getting the coding "Perfect" for POE combat would be to just raise the % like people said. One thing many people aren't considering is that in my mind, a GUI is the least important part of the code. Sure its nice to have the basics of selecting your CR's and enabling plugins. But all of this can technically be done with true false statements that we could enable and disable in the coding itself. Cough Cough. What I mean to say is. I am sure you can find the flask % in the code. Not a rant, just went through all of this with their other bots and the only real solution to a smooth bot is time and experience.

99% sure the behavior you are seeing is related to the way the game works, and not how the current code is setup. That's not to say there aren't flaws with how the flask logic is setup, because there are, but not the thing you are talking about. Basically, it has to do with a lack of visual feedback in the game when you are using a health/mana flask. If they were to display the buff for when you are recovering health/mana, you'd start to realize why the bot isn't using a flask at certain cases, and why it is when it does. It has to do with how flask recovery isn't a lingering effect, as soon as it ends, it ends for good, rather than lasting the entire duration like people expect.

This creates scenarios where the bot seems to pot more than it should, and drains the flasks, but just because your resource pool is too low to be properly refilled when it simply falls under a certain threshold. The opposite case is when your resource pools are too high for the flasks you are using, or the flasks are slow recovering flasks, so it looks like the bot isn't potting, but it actually is; it's just your recovering is not out healing the incoming damage you are taking. Once again, this is just another issue of how the game is designed, as typically most people expect to be able to pot through damage in most games.

As for defaults, no set of defaults would ever satisfy everyone. I think the issue is more the accessibility of editing the changes right now, as Exile is not a good example of how a CR should really be. This will be changed though, as one of the largest updates to the bot is going to pretty much cause the way CRs, plugins, and the bot interface to change. The new exile will function a lot differently than the current one does, but that is not to say it's going to solve all the problems the current one has design wise, though.

As to the things that do need to change about the flask logic:
* It needs to be moved out of the CR into the global bot scope like a plugin (which is what I always wanted) so you can handle cases like puncture and viper orbs killing you, or be able to use flasks on demand out of combat, say, control when quicksilver is used or pop one before opening a chest.
* A simple gui entry for the basic configuration should be added, as either people will just want to use the basics or take the time to customize things how they want via code; there's no middle ground to appease the two. This is more of a limitation of how the gui is coded and it needs a rewrite in some areas.
* More advanced flask logic will be added. For example, if you take a large spike of damage, which is pretty much how this game is right now, it'd be much better to pop a flask and recover rather than pop a flask and continue to face tank. This is more on the issue of a better CR, but it'll be more doable after all the changes are done. I was playing with a new basic CR and added simple return to origin kiting (if mobs get too close, retreat back to a starting point until you are out of range) and it made a huge difference on a new ranged character that had no gear or weapons. Of course, there's only so much the bot can do if you are under geared, but it was at least able to get a lot further than the current one does.

So, we know there are limitations to Exile and the combat is still pretty simple, but there is a plan to address these things through the new changes. They just can't come all at once though, because it's quite literally going to be another new bot by the time everything is done.

 

[Harmacintyre]

My 3 cents. That is a good post but kind of unrelated to what I am saying. I am saying that the bot is getting too caught up in targeting and re-targeting so that sometimes when you are past the point of when you "should" pot it will delay it slightly longer. I think some of this might get fixed when kiting is introduced because there will be downtime when the character is "slight stutterstep(just example of kiting)" kiting and not targeting. Bot should be able to drink a potion in that time where hes moving.

As for the potions in this game versus others. The maps I do, if my hp gets <90% I pop a pot. Why? because like you said, pots are just to stop taking "more" damage rather than fully heal a player. The problem that I am seeing is that, as you said once the potion wears off, your going to keep taking more damage and probably hit your chicken escape. It would be more efficient if the bot figured "before the timer expired" if it should pop another at the last second rather than waiting until it expires and then rechecking. If this is already coded in, correct me, but when my expensive pots aren't being used, its noticeable.

 

[darkbluefirefly]

My 3 cents. That is a good post but kind of unrelated to what I am saying. I am saying that the bot is getting too caught up in targeting and re-targeting so that sometimes when you are past the point of when you "should" pot it will delay it slightly longer. I think some of this might get fixed when kiting is introduced because there will be downtime when the character is "slight stutterstep(just example of kiting)" kiting and not targeting. Bot should be able to drink a potion in that time where hes moving.

As for the potions in this game versus others. The maps I do, if my hp gets <90% I pop a pot. Why? because like you said, pots are just to stop taking "more" damage rather than fully heal a player. The problem that I am seeing is that, as you said once the potion wears off, your going to keep taking more damage and probably hit your chicken escape. It would be more efficient if the bot figured "before the timer expired" if it should pop another at the last second rather than waiting until it expires and then rechecking. If this is already coded in, correct me, but when my expensive pots aren't being used, its noticeable.

Ok first off,
Are these instant heal pots or pots over time?
If it's instant heal, would be better if you hp dropped by pot heal amount / hp you have = percent the pot will heal. That way it won't waste pots, like pushedx says.
If it's heal over time, if you spam pot heal, you will only heal so much over time, so what's the point of healing whenever under 90%? lets say you are dealt damage with 89% hp currently, bot pops heal, you start healing to 90%, then 91%, pot heal is over 6 seconds. You get damaged again within the 6 seconds from a mob or monster doing 1 attackspeed per second, your hp drops to 80%, and you are at 5 seconds from the last pot usage and the pot is still healing you for the X amount over 6 seconds. and it repeats til 0 seconds from last pot usage. Within that time, if you pop the same pot to heal, you will not double up on healing, it will just add X seconds to X amounts after the 6 second cooldown. Hence it's a waste to spam pots, unless it's instant healing pots. It's better to wait the cooldown, as you will not heal faster or more as long as you are on cooldown for the HP pot. Better thing would to allocate life leech or some sort to stay alive longer.

Please correct me if I am wrong.

 

[Harmacintyre]

You don't seem to be grasping what I am saying. My whole point is that there is a delay for the bot to pop pots because of combat.

Instant heal pots I don't use for the fact if I were to need them I would rather have my bot log out to safety.

As for this double upping of pots? I don't know what you are talking about. The .0001 seconds of doubling up a potion is negligible.

By anticipating the potion to end, bot "preemptively" prepares to pop a potion in order for there to be 0 downtime of not healing.

As for the cooldowns of potions? Your potions are whack haha.

Hope this clears up your understanding.

 

[pushedx]

You don't seem to be grasping what I am saying. My whole point is that there is a delay for the bot to pop pots because of combat.

Well, there is a delay, but it's not from the combat running.

private readonly WaitTimer _flaskCd = new WaitTimer(TimeSpan.FromSeconds(0.5));

You can try changing that to something like this if you have really low latency to the server.

private readonly WaitTimer _flaskCd = new WaitTimer(TimeSpan.FromMilliseconds(20));

And see if you get the behavior you want.

Otherwise, what you are saying still doesn't make sense, because the bot/CR is currently coded a very specific way:

The code to enter combat looks like this:

case PoiType.Monster:
Poi.Current.Handled = false;
//yield return EnsureAlwaysHighlightDisabled();
yield return Coroutines.CloseBlockingWindows();
Poi.Current.Handled = true;

var ps = new PrioritySelector(RoutineManager.Current.Buff, RoutineManager.Current.Combat);
yield return LokiCoroutine.CompositeExecutor(ps);
break;

'Buff is the CR's buffing logic, which for example is defined as follows (you have the code for this in Exile.cs)

// inside Initialize
BotMain.OnStart += bot => DoSpellRegistrations();

...

// inside DoSpellRegistrations
BuffComposite = new PrioritySelector(context => BestTarget);

BuffComposite.AddChild(CreateFlaskLogic());

If what I'm saying was not true, then you should be able to add the following code to the bottom of the PrioritySelector in CreateFlaskLogic, and combat should still normally run:

// comma for the previous line, just shown here.
		, new Action(ret =>
                    {
                        return RunStatus.Success;
                    })

However, it doesn't, because the code is designed to run one thing to success, and then re-evaluate the tree, as that's the nature of behavior trees. Running Exile with that modification yields a bot that will pot, but not actually fight, since the BT never makes it to Combat composite.

 

[Harmacintyre]

Okay, I will try out the waitTimer when I get home.

For the

However, it doesn't, because the code is designed to run one thing to success, and then re-evaluate the tree, as that's the nature of behavior trees.

Would there ever be a time when

Bot attacks, hp belowX %, attacks once more first, then pots?

EX: I don't know if it would be from being stunned? maybe something like the code gets enabled but doesnt register because of gameplay or something?

I guess I should consider ingame stun issues too. hmm

 

[pushedx]

Bot attacks, hp belowX %, attacks once more first, then pots?

EX: I don't know if it would be from being stunned? maybe something like the code gets enabled but doesnt register because of gameplay or something?

I guess I should consider ingame stun issues too. hmm

The conditions to use a flask in Exile are as follows:
* _flaskCd.IsFinished - The flask hard use timer has to be expired.
* Me.HealthPercent < 70 - Your health has to be under 70%
* LifeFlasks.Count() != 0 - You have an available flask to use (charges >= max charges)
* !Me.HasAura("flask_effect_life" - You are not already under the effect of another life flask.

If your life is under 70%, and any of those other conditions are false, then a flask will not be used. The flask cooldown was a part of the old system that carried through, and is only really needed for latency issues. It should be based around 2x latency probably. The # of life flasks available is required, since if you don't have any flasks to heal with, then you can't pot. The flask_effect_life check is to prevent wasting pots when you are already being healed with one. There are obvious cases of where if you are using instant pots, you probably not care about that, and would want your flasks separate, but Exile just contains basic code for doing things; users can change it to their specific needs.

In addition to my previous post, there is another thing of note to be aware of. The flask logic is executed top to bottom. As soon as a flask use condition is met, the behavior tree retests. In extreme cases, it would be possible to greatly delay health flask using logic because your other flasks would be setting the CD, and each time the life flask check was done, it was on CD, and wouldn't be used. It probably would be better to not share a global CD between all flask types, but once again, Exile is pretty old now, and at the time it was needed. This falls in line to the _flaskCd.IsFinished check about though. 500ms between using any pots could certainly cause some issues, but like I said you can lower it and see if that fixes the issue you are seeing.

In the new code, this logic will be changing a lot (CRs and the bot in general), but the general design will be similar. Different flasks will have their own CDs to avoid any issues of pot starvation due to the order of flasks being executed, and the delay will be latency bound to make sure you don't double use pots and waste them because the client isn't getting the effect fast enough.

 

[babosasa]

settle the navigation, chest and spell casting stuck, keep town portaling bug, enable boss run and able to do quest asap. thank you

 

[darkbluefirefly]

settle the navigation, chest and spell casting stuck, keep town portaling bug, enable boss run and able to do quest asap. thank you

easier said then done =).

 

[pushedx]

A preview of some of the big changes being made can now be seen in the new ExilebuddyBeta User's Guide.

There's no information on the actual bot, routines, plugins, because they have all been removed and are being reworked. Some more information about those will be added this week as they are implemented.

 

[pd9]

A bit of a comment with regard to flasks.

It would be really nice to have an expanded Loki.Game.Objects.Items.Flask

Right now I am seeing:

public class Flask : Item
{
// Methods
internal Flask(Item entry);

// Properties
public bool CanUse { get; }
public uint ChargesPerUse { get; }
public uint CurrentCharges { get; }
public int ExtraCharges { get; }
public int HealthRecover { get; }
public float HealthRecoveredPerSecond { get; }
public bool IsInstantRecovery { get; }
public int ManaRecover { get; }
public float ManaRecoveredPerSecond { get; }
public uint MaxCharges { get; }
public double MaxChargesModifier { get; }
public TimeSpan RecoveryTime { get; }
}

It would be nice to have this expanded for the various alternate flask functions.

Currently I am just figuring stuff out from the "FullName".

Unfortunately, I can't seem to find any docs, so I'm just going by the names in the exports.

It would be super nice if you could generate some docs from the interface, I'm guessing this is planned in the future


edit: looks like you can check Loki.Game.GameData.StatType.<stat> nvm