ExilebuddyBeta Developers Testing/Feedback Thread

[pushedx]

When this is released what will the GUI look like? Will it be massively cleaned up so users like me can edit a lot of the bot without opening files and sorting through code? Can we do things like avoid a certain strongbox because it has a specific mod we can't handle all through gui?

Keep up the good work.

Beta has been available for use as soon as this thread was made.

Just click on the Latest Download link in the second post, and you'll get the latest Beta available.

The ExilebuddyBeta User's Guide also goes over most of the basics, but a few of the images need updating. They will be updated soonish, but for the most part, all of the information there is still relevant.

As for your question, the code aspect is always going to be a main part of the project. If you want to avoid it entirely, you're going to be really limited as to what you can do and configure with what we provide. We have to take an approach of general -> specific. So, we'll make sure we have all the capabilities for people to do the things they want, but we can't specialize all of those capabilities into really polished features for end users in the short term. As time goes on, and we have less broad things to do, we'll be able to start focusing on specializing various things, but that's not going to be anytime soon for the short term.

That is where the whole user driven development aspect comes in. If people want to make things better than we have our basics setup, they'll be able to. That's been the driving focus for the Beta rewrite, to get the project setup in a way where people can actually develop meaningful things with what we provide and not be impeded by our code.

To answer your question directly, the answer would be no, you won't be able to completely configure the strongbox logic through a gui with what we provide, because what we provide right now, is the means to do those specific interactions with the strongboxes. How the bot actually does it, is dependent on the implementation used. For just showing off the feature, I added in a basic example that uses transmutations on a white strongbox, but obviously there's a lot of different things that can be done. Writing a fully complete system that was fully configurable through a gui would make for a good plugin, but on the priority list for the things to work on right now, that's pretty low.

The current critial priority list for beta is as follows:
1. Rewrite Exile into something more usable with a minimal gui.
2. Rewrite TspExplorer to fix the performance issues when exploring.

Once those two things are finished, Beta is pretty much ready for more general use and testing, and where we go from there, will be dependent on the feedback we get. Extensive strongbox features would be nice, but those only exist in one league right now, so it would be better for us to work towards general quest support, boss farming, or actual map logic before specializing a feature like that. I do foresee strongboxes becoming a standard feature of the game, like Shrines did, but we're still months away from that possibly happening.

Hopefully that makes sense as to the direction we're going in; general support first, and then specialization later.

 

[babosasa]

need some anti-detection as well, the current release of bot is easily detectable by GGG >_<

 

[randomstraw]

need some anti-detection as well, the current release of bot is easily detectable by GGG >_<

contrary my friend, the bot is not detectable, some sequences of doing things in a certain way are!

 

[IeU]

contrary my friend, the bot is not detectable, some sequences of doing things in a certain way are!

Indeed. He got banned for botting 12h hours a day on 2 accounts under the same IP and come here say that EB is detectable . . .

 

[iargue]

To be fair, if the bot was undetectable, then GGG would never ever know about it running, even if you ran for 24 hours, it would magically find a way to fool riot's logging.

"However, no bot will ever be. This bot is nor any more detectable then any other bot. 99.9% of the problems come from stupidity itself.

 

[pushedx]

Beta #827 was just built. The past few versions have been various bug fixes, improvements based on feedback, and additional ground work for the new default CR.

The new default CR is now implemented into the Beta. The new design is setup to provide a limited set of configurations of how to use a skill, and let the user select which skills to use from the GUI. More advanced logic or settings will be up to users to do, as it's not possible for us to cover all the ground with a generic CR. To get started, simply go to the Settings -> ExilebuddyRoutine. Hoover over the labels for a tooltip as to what each option is for. We'll have a guide on some basic usage later after the CR has some more functianlity added, as it's not done yet. However, it's in a more than usable state to start testing things with for most builds. Totem/Minion options are not added yet, but they will be later. Likewise with buff/aura stuff. Furthermore, another range setting needs to be added, some time on target tracking so the bot doesn't get stuck due to desync, and other improvements like that will be added to give something for users to work with.

As I mentioned in a previous reply, the two biggest issues to address in Beta right now are the default CR, which is well on its way, and rewriting the TspExplorer. Fixing the explorer is now the main focus to address the performance issues that can be seen when the bot is moving around. Once that is done, a few days will be spent updating guides and docs for the new stuff in preparation of more testing/use. From there, some new features and improvements will start making their way into the Beta, such as the start of basic map and quest stuff.

 

[pushedx]

Beta #828 was just built. This version re-adds some previous bot settings and adds corrupted area support.

In addition, some long time problems with new instances was addressed. In the past, there was a conflict between various new instance settings, such as deaths before new instance, abandoning an area, or completing a corrupted area. The old code was not setup to track a new instance override flag, so the bot can make a new instance when needed when default settings otherwise would create negative scenarios such as infinite area loops. This issue should now be resolved, as some global state was added to track these things.

When a corrupted area is now completed, the bot will travel back to the entrance, and return to the area that was before. The corrupted area is then blacklisted so the bot will never take it again, which was another issue the old bot had. There's a few more scenarios that need to have new logic added, such as time in instance, but those core settings are not implemented yet.

Finally, some more tweaking has been done to chest/loot pois to try and address various stuck issues. Unfortunately, there might be times the bot totally skips over things, but it's to keep the bot progressing and not getting stuck due to some really odd scenarios that happen in this game.

 

[cyberbot]

When a corrupted area is now completed, the bot will travel back to the entrance, and return to the area that was before. The corrupted area is then blacklisted so the bot will never take it again, which was another issue the old bot had. There's a few more scenarios that need to have new logic added, such as time in instance, but those core settings are not implemented yet.

The beta is getting more exciting day by day.

I actually like the bot to teleport out when it is finished with a corrupted area, because it would be able to look for the next corrupted area faster, where there is better exp and loot. Could you add an option to keep the old behavior?

 

[pushedx]

The beta is getting more exciting day by day.

I actually like the bot to teleport out when it is finished with a corrupted area, because it would be able to look for the next corrupted area faster, where there is better exp and loot. Could you add an option to keep the old behavior?

Yeap, the next beta will have a new option called NewRunAfterCorruptedAreaExplored. When enabled, the bot will use a portal (and then logout if it can't) when exploration is completed in a corrupted area. The parent area that contained the corrupted area has its new instance override flag set, so the next time the bot tries to enter the area, whether it's accessible via a waypoint or another area, it'll create a new instance. The new default behavior will be as previously mentioned, the bot will take the area transition back into the parent zone, and continue on. If it can't take the area transition for some reason, it'll then fall back to portal, and then logout.

 

[pd9]

Any ETA on the buff logic?

SpellManager seems to have changed a bit in beta vs release

 

[pushedx]

Beta #831 was just built. This version improves some performance issues as well as extend the ExilebuddyRoutine to handle auras correctly now. The layout for skills and curses has also changed, so it's a good idea to delete your old ExilebuddyRoutine.json for your characters and have it re-created. Settings are currently changing a lot, so if anything seems broken, just use a fresh copy of the bot each time.

Any ETA on the buff logic?

SpellManager seems to have changed a bit in beta vs release

Very soon! Curses and Auras were just updated to work using a new layout, and Buffs will be added next. I went ahead and just built the current Beta for people to test the performance changes, so hopefully it's running better now. I'll get Buffs added later tonight or first thing tomorrow for the next version.

Correct, SpellManager has been updated quite a bit to work better with the new setup. Was there anything in particular you want to know or are you just looking at differences between the old CR and the new?

 

[pd9]

I have a bit of a modified exilebuddyroutine that implements some logic for blood rage/molten shell.

I was just wondering why the composite logic/delegate definitions were taken out of SpellManager. Were they too specific to a few operations?

 

[pushedx]

I have a bit of a modified exilebuddyroutine that implements some logic for blood rage/molten shell.

I was just wondering why the composite logic/delegate definitions were taken out of SpellManager. Were they too specific to a few operations?

TreeSharp is no longer being used. We are migrating away from that design in favor of coroutines. The library is still there, and you're free to try to use it with the new coroutine implementations, but it's not recommended.

The reason is primary due to how this game works, and how trying to interact with the client without using coroutines is very verbose, and hard to maintain. I'll give you a basic example, as I have a more in-depth explanation somewhere in another thread as to why the bot has/will have the problems it does.

In most games, there is a ClickToMove client function you can pretty much call with coordinates to make your character move. The bot would call the client's C2M function, the client builds the packet, and sends it off to the server. The client then waits for a server response to actually move, based on the result of the move action. This is the basic client/server model a lot of games use.

In Path of Exile, there is a client sided simulation running in parallel with the servers. When you move your character on the client, it moves right away according to the client's simulation, and then sends the movement packet to the server. The client doesn't handle the movement result smoothly at all, and thus, the desync issues this game has starts to manifest. On your screen, you might be on one side of a wall, but on the server, you're on a totally different side.

This type of system is a nightmare for bots, because the bot is dependent on the client being as accurate as possible to work. Now the problem with PoE, is that there is no true C2M functions. Instead, they have an input system where the current action is built up based on the current state of input, and then they queue and fire events when the button is detected being down and so on, so a polling setup. This presents a problem for single frame actions, because they are not possible. If you do it, you end up desyncing the client even more than normally, and risk breaking the client in ways that trigger flags/bans. As a result, to do anything with the client, it has to be done across multiple frames. Trying to do that using BTs is messy because you have to re-execute the same thing but do different logic depending on which frame you're on.

Coroutines allow us to solve the problem nicely, as we just setup things how they need to be to emulate the action, yield to let the client update its state, and then we can perform the action in one nice continuation without having to do any extra work. Now the downside to the way we have to do things is that everything is pretty inaccurate, but there's not much we can do about that. With the new logic being used in Beta, we tried to make the bot less "spammy" (it's already a spammy game by nature) by performing single actions at a time to try and help reduce desync by making the client do less. Due to the way the bot works, the overhead added to the client when its running does affect it, but enough desync happens in this game as it is playing legit, so that's to be expected.

There's a whole bunch of other things that go on in the client that have to be accounted for, which is why the bot has a lot of random problems that you don't see in others. A lot of these issues have tried to be coded around as best as possible in the new Beta, but they will still happen time to time. There's really not too much else that can be done to resolve those issues, because it's purely a result of how the client works, and what we have to work with in order to make a working bot.

Hopefully that clears up the issue. Basically, non-coroutine designs are not optimal for PoE if you want to solve a lot of the problems you see in Release in places where they aren't used.

 

[pushedx]

#832 was just built. This version adds in some basic buff logic for the main buff skills. The display format for spells was also updated to show the inventory item slot and socket index the skill is in, in case you are leveling more than one copy of a gem and need to distinguish them. A few experimental fixes have also put into place for when the framelock is lost in the middle of bot execution.

#833 was just built. This version adds the logic needed to access some blocked area transitions as well as settings for hp/mp trigger values.

#835 was just built. This version adds the ItemFilterEditor back as well as a few bug fixes.

#836 was just built. This version fixes the Python console and fixes a few dev specific things. This is most likely the last version before waiting for the 1.5.X update tomorrow.

#837 was just built. It fixes an issue in the previous build that went unnoticed and adds the Object Explorer window.

 

[pushedx]

#838 was just built. This version updates for 1.1.5.1 and adds support for most of Act 1's static location detection. The purpose of that system is to allow the bot to work towards a position so it doesn't have to explore the entire map. An example of where this logic will be used, is bot runs, for instance. In addition, for the new explorer, the logic will be able to make its way towards a waypoint for an area if it doesn't have it first, and then get back to general exploration.

Since the client changed some, please report any new issues that seem to pop up if you're testing Beta. It's getting closer and closer to replacing Release, so please don't feel afraid to try it out and leave feedback if you haven't already/

 

[krone6]

So if I get this right, we'd be able to tell it to fight to the waypoint and then explore everything else that it didn't fight when it went there?

 

[cyberbot]

I have started looking into the beta. There are old features/plugins that I am missing.

1) Will gem leveling be part of the new bot? or will it be an official plugin for the new bot?

2) Please consider adding the following plugin to be an official plug or even part of the bot. Showing the dropped items has been very useful for me and probably other users:
https://www.thebuddyforum.com/exile...-profiles/143289-plugin-advanced-itemlog.html

3) Do you have any tips for us on how to write a plugin that regularly switches grind zones using the new API?

Thanks!

 

[pushedx]

1) Will gem leveling be part of the new bot? or will it be an official plugin for the new bot?

Yes, a new plugin will be added to handle it using the new setup. The way the new CR is setup with the skills should allow the issues with the old one to be finally fixed when it comes to selecting skill gems to level.

2) Please consider adding the following plugin to be an official plug or even part of the bot. Showing the dropped items has been very useful for me and probably other users:
https://www.thebuddyforum.com/exile...-profiles/143289-plugin-advanced-itemlog.html

Users can create and share plugins like that. It's why the project is setup how it currently is.

3) Do you have any tips for us on how to write a plugin that regularly switches grind zones using the new API?

ExilebuddyBotSettings.Instance.GrindZoneDifficulty and ExilebuddyBotSettings.Instance.GrindZoneName now control where the bot grinds at. To change it, you'd just directly assign those values. Here's a modified ExamplePlugin that shows doing that:

Spoiler

using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Markup;
using ExamplePlugin;
using log4net;
using Loki.Bot.Logic.Bots.ExilebuddyBot;
using Loki.Bot.Logic.Bots.ExilebuddyBot.Exploration;
using Loki.Bot.v2;
using System;
using Loki.Game;
using Loki.Utilities;
using Loki.Bot.v2.Settings;
using System.Collections.Generic;
using System.Windows.Documents;

// ReSharper disable once CheckNamespace
namespace ExamplePluginNamespace
{
    class ExamplePlugin : IPlugin
    {
        private static readonly ILog Log = Logger.GetLoggerInstanceForType();

        /// <summary> </summary>
        public ExamplePlugin()
        {
        }

        #region Implementation of IPlugin

        /// <summary> The name of the plugin. </summary>
        public string Name
        {
            get
            {
                return "ExamplePlugin";
            }
        }

        /// <summary> The description of the plugin. </summary>
        public string Description
        {
            get
            {
                return "An example plugin for Exilebuddy.";
            }
        }

        /// <summary>The author of the plugin.</summary>
        public string Author
        {
            get
            {
                return "pushedx";
            }
        }

        /// <summary>The version of the plugin.</summary>
        public Version Version
        {
            get
            {
                return new Version(0, 0, 1, 1);
            }
        }

        /// <summary>Initializes this plugin.</summary>
        public void Initialize()
        {
            Log.DebugFormat("[ExamplePlugin] Initialize");

            // Register the settings manager for this plugin with the configuration manager.
            Configuration.Instance.AddSettings(ExamplePluginSettings.Instance);

            // To see if there are specific arguments passed to the program, you can do something like this.
            if (CommandLine.Arguments.Exists("myarg1"))
            {
                var myarg1 = CommandLine.Arguments.Single("myarg1");
                Log.DebugFormat("myarg1: {0}", myarg1);
            }

            ScriptManager.Initialize(null, new List<string> {"Loki.Game"});
        }

        /// <summary> The plugin start callback. Do any initialization here. </summary>
        public void OnStart()
        {
            Log.DebugFormat("[ExamplePlugin] OnStart");
        }

        /// <summary> The plugin tick callback. Do any update logic here. </summary>
        public void OnTick()
        {
        }

        /// <summary> The plugin stop callback. Do any pre-dispose cleanup here. </summary>
        public void OnStop()
        {
            Log.DebugFormat("[ExamplePlugin] OnStop");
        }

        /// <summary> The routine's settings control. This will be added to the Exilebuddy Settings tab.</summary>
        public UserControl SettingsControl
        {
            get
            {
                using (var fs = new FileStream(@"Plugins\ExamplePlugin\SettingsGui.xaml", FileMode.Open))
                {
                    var root = (UserControl)XamlReader.Load(fs);

                    // TODO: Your settings binding here.

                    // TODO: Your settings event handlers here.

                    var configButton = Wpf.FindControlByName<Button>(root, "ConfigButton");
                    configButton.Click += ConfigButtonOnClick;

                    var executePythonButton = Wpf.FindControlByName<Button>(root, "ExecutePythonButton");
                    executePythonButton.Click += ExecutePythonButtonOnClick;

                    _pyInputRichTextBox = Wpf.FindControlByName<RichTextBox>(root, "PyInputRichTextBox");

                    return root;
                }
            }
        }

        private RichTextBox _pyInputRichTextBox;

        private void ExecutePythonButtonOnClick(object sender, RoutedEventArgs routedEventArgs)
        {
            if (_pyInputRichTextBox == null)
            {
                Log.ErrorFormat("[ExecutePythonButtonOnClick] _pyInputRichTextBox == null");
                return;
            }

            var myText = new TextRange(_pyInputRichTextBox.Document.ContentStart, _pyInputRichTextBox.Document.ContentEnd).Text;

            ScriptManager.GetStatement(myText)();
        }

        private void ConfigButtonOnClick(object sender, RoutedEventArgs routedEventArgs)
        {
            new WinForms().ShowDialog();
        }

        /// <summary> The plugin is being enabled.</summary>
        public void OnEnable()
        {
            Log.DebugFormat("[ExamplePlugin] OnEnable");

            // Hooks us up into the main bot gui.
            LokiPoe.OnGuiTick += OnGuiTick;
            GameEventManager.AreaChanged += GameEventManagerOnAreaChanged;
            Explorer.OnExplorationComplete += ExplorerOnOnExplorationComplete;
        }

        /// <summary> The plugin is being disabled.</summary>
        public void OnDisable()
        {
            Log.DebugFormat("[ExamplePlugin] OnDisable");

            // Removes us from the main bot gui.
            LokiPoe.OnGuiTick -= OnGuiTick;
            GameEventManager.AreaChanged -= GameEventManagerOnAreaChanged;
            Explorer.OnExplorationComplete -= ExplorerOnOnExplorationComplete;
        }

        private void ExplorerOnOnExplorationComplete(object sender, ExplorationCompleteEventArgs explorationCompleteEventArgs)
        {
            ExilebuddyBotSettings.Instance.GrindZoneDifficulty = "Normal";
            switch (Utility.Random.Next(0, 3))
            {
                case 0: ExilebuddyBotSettings.Instance.GrindZoneName = "The Ledge";
                    break;
                case 1: ExilebuddyBotSettings.Instance.GrindZoneName = "The Mud Flats";
                    break;
                case 2: ExilebuddyBotSettings.Instance.GrindZoneName = "The Coves";
                    break;
            }
        }

        private void GameEventManagerOnAreaChanged(object sender, AreaChangedEventArgs areaChangedEventArgs)
        {
        }

        #endregion

        #region Implementation of IDisposable

        /// <summary> </summary>
        public void Dispose()
        {
            // Unregister the settings manager for this plugin with the configuration manager.
            Configuration.Instance.RemoveSettings(ExamplePluginSettings.Instance);
        }

        #endregion

        #region Override of Object

        /// <summary>
        /// 
        /// </summary>
        /// <returns></returns>
        public override string ToString()
        {
            return Name + ": " + Description;
        }

        #endregion

        private void OnGuiTick(object sender, GuiTickEventArgs guiTickEventArgs)
        {
            var window = guiTickEventArgs.Window;

            Log.DebugFormat("[ExamplePlugin] OnGuiTick | {0} | {1}", window.Title, Environment.TickCount);
        }
    }
}

The areas relevant are just ExplorerOnOnExplorationComplete and OnEnable/OnDisable. How you want to manage switching and all that is up to you, but that's about all there is to it.

 

[pushedx]

Beta #840 was just built. This version implements a lot of behind the scenes fixes for various things in the main gui. Some basic totem logic has been added, so the bot will use assigned totems during combat, after buffs, but before skills.

Finally, the Log tab is gone and has been moved to be the bottom portion of the entire bot gui similarly to before, except it's always shown. This was done, because being able to always see the log is very useful, especially during development, and having to switch to the Log tab each time to see what was going on was getting annoying. There is a splitter bar you can use to resize the top and bottom portions, and the gui settings save your positions.

The updated skillgem leveler plugin will be the next thing worked on right now and should hopefully be in the next version. There's still a lot of little things to update in the new bot, and some big things, but it's still progressing nicely I think.

 

[IeU]

Nice work pushed! Keep it coming! Now i am just waiting for the 1 month to start . . .

PS: Please add Minions support