Try giving your VM more CPU. The issue should purely be related to CPU/FPS with how movement works now. Trying to make EB work more friendly under low resources/FPS is not a priority, due to the way things have to work now. I do have something to mess with later to make it not require nearly as many pathfinding calls for each movement, but for now, what's there works well under all normal botting cases of using it on a regular gaming PC.
When I tested those weapon types, I couldn't get them to raise, but rechecking, my skill was only for up to Level 9, so that might be why.
I'm not going to be spending any time soon trying to make it work better. The core of getting the CR to use those skills is in place now, along with the necessary API support. unlike before, so it'll be up to users to find what works best.
That's good to hear, but I'm not exactly happy with how things are setup yet. A few things were put into place to try and get a working bot back up and running asap after the rewrite, and some of those things are causing issues with random reported bugs. The only big thing left to do is fix objects/components, as everything on the API is dependent on them working correctly, which right now won't be the case when you use coroutines or any API function that requires leaving the current frame (which is pretty much all of them).
pushedx, is the auto-login following a chicken supposed to be working yet? I have it turned on, but after chickens, the log says:
[MainCoroutine] AutoLogin returned None.
edit: I guess you must enter a character name for it to work? I was hoping it would just log in as the last character used.
The bot stutters the skills. There's a delay between each casts. Instead of like going full spamming mode it stops for an instant before casting again.
pushedx, is the auto-login following a chicken supposed to be working yet? I have it turned on, but after chickens, the log says:
[MainCoroutine] AutoLogin returned None.
edit: I guess you must enter a character name for it to work? I was hoping it would just log in as the last character used.
You do have to enter the character name, because otherwise, the last character selected, is not always the last character you played (I've observed some strange server issues in regards to this). It's just "safer" for users to set the character name, as it also helps prevent configuration issues when people switch accounts and forget (we've had reported issues in the past that resulted from users doing this).
The bot stutters the skills. There's a delay between each casts. Instead of like going full spamming mode it stops for an instant before casting again.
[Tick] Exception during execution:System.Exception: Process must have frozen or gotten out of sync: InjectionFinishedEvent_was_never_fired
at GreyMagic.Executor.WaitForInjection(Int32 timeout)
at GreyMagic.Executor.Execute(Int32 timeout)
at GreyMagic.Executor.GrabFrame()
at GreyMagic.ExternalProcessMemory.AcquireFrame(Boolean isHardLock)
at Loki.Game.LokiPoe.AcquireFrame(UInt32 frameDropWaitTimeMs, Int32 executionTimeOut, Boolean clearCache)
at Loki.Bot.BotManager.(IBot )
[Stop] Now requesting the BotThread to stop.
[Invoke] Error during execution:System.Exception: Process must have frozen or gotten out of sync: InjectionFinishedEvent_was_never_fired
at GreyMagic.Executor.WaitForInjection(Int32 timeout)
at GreyMagic.Executor.Execute(Int32 timeout)
at GreyMagic.Executor.GrabFrame()
at GreyMagic.ExternalProcessMemory.AcquireFrame(Boolean isHardLock)
at Loki.Game.LokiPoe.AcquireFrame(UInt32 frameDropWaitTimeMs, Int32 executionTimeOut, Boolean clearCache)
at Loki.Bot.BotManager.(IBot , BotEvent )
[Stop] Now requesting the BotThread to stop.
[Start] Exception during execution:System.Exception: Process must have frozen or gotten out of sync: InjectionFinishedEvent_was_never_fired
at GreyMagic.Executor.WaitForInjection(Int32 timeout)
at GreyMagic.Executor.Execute(Int32 timeout)
at GreyMagic.Executor.GrabFrame()
at GreyMagic.ExternalProcessMemory.AcquireFrame(Boolean isHardLock)
at Loki.Game.LokiPoe.AcquireFrame(UInt32 frameDropWaitTimeMs, Int32 executionTimeOut, Boolean clearCache)
at Loki.Bot.BotManager.(IBot )
No, it's setup the same way as the last Beta (but not Release). With a little code, it's really easy to change the way things work, once you understand how everything works together. Users can't really understand how everything works yet, without asking, since you guys don't have the code.
BasicGrindBot is task based, which simply means a bunch of tasks are created to implement the bot specific logic. The current task list looks like this, which if you check your log on start, you'll see the same thing just about.
Code:
TaskManager.Reset();
TaskManager.Add(new ResurrectTask());
TaskManager.Add(new ClearCursorTask());
TaskManager.Add(new AssignMoveSkillTask());
TaskManager.Add(new HandleBlockingChestsTask());
TaskManager.Add(new HandleDoorsTask());
// Handle stuff close by to us first.
TaskManager.Add(new CombatTask(50, false));
TaskManager.Add(new TownRunTask(
v => BasicGrindBotSettings.Instance.CameFromPortal = v,
() => BasicGrindBotSettings.Instance.NeedsTownRun,
v => BasicGrindBotSettings.Instance.NeedsTownRun = v)
);
TaskManager.Add(new LootItemsTask(
50,
false,
v => BasicGrindBotSettings.Instance.NeedsTownRun = v,
v => BasicGrindBotSettings.Instance.NeedsToStash = v,
TriggerOnLoot));
TaskManager.Add(new OpenChestTask(50, false));
// Always loot items before leaving the area.
TaskManager.Add(new LootItemsTask(
-1,
true,
v => BasicGrindBotSettings.Instance.NeedsTownRun = v,
v => BasicGrindBotSettings.Instance.NeedsToStash = v,
TriggerOnLoot));
TaskManager.Add(new MergeInventoryTask());
TaskManager.Add(new IdTask(NeedsToId, IdingComplete, ShouldIdItem));
TaskManager.Add(new SellTask(NeedsToSell, SellingComplete, ShouldAcceptSellOffer, ShouldSellItem));
TaskManager.Add(new StashTask(NeedsToStash, StashingComplete, ShouldStashItem, BestStashTabForItem));
TaskManager.Add(new WithdrawTask());
TaskManager.Add(new HandleInventoryItemsTask());
TaskManager.Add(new ReturnToGrindZoneTask(
() => BasicGrindBotSettings.Instance.CameFromPortal,
v => BasicGrindBotSettings.Instance.CameFromPortal = v
));
TaskManager.Add(new TagWaypointTask());
TaskManager.Add(new TravelToGrindZoneTask());
TaskManager.Add(new TravelThroughBossAreasTask(true));
// Now handle everything else in order.
TaskManager.Add(new OpenChestTask(-1, true));
TaskManager.Add(new CombatTask(-1, true));
TaskManager.Add(new TravelThroughBossAreasTask(false));
// Lastly, explore the rest of the map.
TaskManager.Add(new ExploreTask());
// Once we are done, find an area transition to leave though.
TaskManager.Add(new LeaveCurrentBossAreaTask());
TaskManager.Add(new LeaveCurrentAreaTask());
TaskManager.Add(new FallbackTask());
Right now, LeaveCurrentBossAreaTask and LeaveCurrentAreaTask are responsible for the logic implemented to make the bot leave the current area though an available Area Transition (in most cases). That logic runs after all other tasks no longer need to execute.
The ExploreTask is responsible for exploring the current area. It's implementation is simply:
Code:
public async Task<bool> Execute()
{
if (LokiPoe.Me.IsDead || LokiPoe.Me.IsInTown)
return false;
if (AreaStateCache.Current.Explorer.HasLocation)
{
var location = AreaStateCache.Current.Explorer.Location;
if (_displayStopwatch.ElapsedMilliseconds > 1000)
{
Log.DebugFormat("[ExploreTask] Now exploring to the location {0} ({1}) [{2} %].", location,
LokiPoe.Me.Position.Distance(location), AreaStateCache.Current.Explorer.PercentComplete);
_displayStopwatch.Restart();
}
if (!Functions.MoveTowards(location))
{
Log.ErrorFormat("[ExploreTask] MoveTowards failed for {0}.", location);
AreaStateCache.Current.Explorer.Ignore(location);
}
return true;
}
return false;
}
When ExploreTask returns false, it means all exploration is done, so your "exploration complete" logic can take place, which in this case, is LeaveCurrentBossAreaTask and LeaveCurrentAreaTask.
If you were to add your own task after ExploreTask, it would run when exploration is completed. This means you could do things like change the grind zone, portal out rather than let the current area transition logic take place, or any number of other things.
To actually change the grind zone, all you have to do is change
BasicGrindBotSettings.Instance.GrindZoneDifficulty and BasicGrindBotSettings.Instance.GrindZoneName. Difficulty should be exactly: "Normal", "Cruel", or "Merciless", and the zone name should match what is in game (from world area data). You can simply output all the strings from BasicGrindBotSettings.Instance.AllGrindZoneNames to double check if you need to. Likewise with BasicGrindBotSettings.Instance.AllGrindZoneDifficulty, but those are easy enough.
To get your changed data put into effect, you'll need to stop/start the bot again, or change areas, as the path to the grind zone is re-calculated under those cases and then cached to avoid performance issues.
To make a task, starting with the next version as there will be some interface changes, here's the basic template:
Code:
using System;
using System.Threading.Tasks;
using log4net;
using Loki.Utilities;
namespace Loki.Bot.v3.Tasks
{
/// <summary></summary>
public class Task1 : ITask
{
private static readonly ILog Log = Logger.GetLoggerInstanceForType();
private bool _enabled = true;
/// <summary>The name of this task.</summary>
public string Name
{
get { return ""; }
}
/// <summary>A description of what this task does.</summary>
public string Description
{
get { return ""; }
}
/// <summary>The author of this task.</summary>
public string Author
{
get { return "Bossland GmbH"; }
}
/// <summary>The version of this task.</summary>
public Version Version
{
get { return new Version(0, 0, 1, 1); }
}
/// <summary>
/// The tasks's execution logic.
/// </summary>
/// <returns>true if the TaskManager should not execute any other tasks, and false if it should.</returns>
public async Task<bool> Execute()
{
return false;
}
/// <summary>The bot Start event.</summary>
public void Start()
{
}
/// <summary>The bot Tick event.</summary>
public void Tick()
{
}
/// <summary>The bot Stop event.</summary>
public void Stop()
{
}
/// <summary>Is this task currently enabled?</summary>
public bool IsEnabled
{
get { return _enabled; }
}
/// <summary>Called when the task should be enabled.</summary>
public void Enable()
{
_enabled = true;
}
/// <summary>Called when the task should be disabled.</summary>
public void Disable()
{
_enabled = false;
}
}
}
To register your task, you'd simply call the appropriate function in TaskManager (from Loki.Bot.v3). Included are functions such as: AddBefore, AddAfter, Add (at back), AddAtFront, and other various remove, and reorder things for total customization.
Inside your plugin or routine, you'd simply do the logic in Start, as at that point, the bot's tasks will have been registered, and everything else falls into place by design.
The only thing you have to code around, is that since your task will be getting executed multiple times until another higher priority task runs, you need to keep track of if you actually need to run again for the current area or not.
For example, the basic concept of randomizing the grind zone would be in your Execute function, keep track of the current area hash you have executed for. It'll start out as 0, so in Execute, check the current tile hash (LokiPoe.LocalData.TileHash) and if it doesn't match, assign your copy, then execute your logic to change the grind zone. Typically you want to return true on Execute so no other tasks execute afterwards if you're doing stuff, but for something like changing data at the place you would be, it's fine to return false. The key thing is though, you'll want to return false if you're not doing anything, so other tasks execute that are lower priority.
Once you do that, and the bot leaves the area using the current area transition method, it'll get the new grind zone on the next area change, then make its way to the grind zone. If you want to make the bot go directly to town instead of finishing though the area transition tasks, you can set:
Code:
BasicGrindBotSettings.Instance.NeedsTownRun = 2;
at the time you change the grind zone and return true, so on the next task execution, the TownRunTask executes instead. The value of 2 means to take a waypoint back to town if possible (close enough to your character), and then it'll fallback to using a portal if necessary. When NeedsTownRun is non-zero and not one, the bot won't take the portal back to the previous area, which is what you want. If you were to set it to 1, then the bot would take the portal back, and then loop portals until you ran out.
