[Plugin] Skill-Aware Player Mover

[yfbd]

Ok Yea dodging stuff, should be done inside the CR and not another plugin. This is going to make life a lot harder. It's probaly better to make a dodge class that can be easily incorporated into any routine and called when needed.

 

[stealthy]

Interestingly enough, I've already modified LootItemTask and OpenChestTask to consult the targeting manager OldRoutine uses in order to return early if there are any combat targets near us or the intended interaction target and it's working pretty well.

I agree dodging should be done inside the combat routine... I'd throw kiting in there, too. They're definitely concerns related to the process of fighting monsters.

I've been cleaning up OldRoutine as well - I keep getting the feeling I'm going to need to revisit this plugin system as a whole before we can untangle things very much.

 

[yfbd]

OldRoutine will be depreciated soon I heard, it's been around for 3 years now and pushedx has iterated over and over that when he has time, he will have a predecessor for it.
The thing I do not like about modifying stock classes that EB comes with is, every update it will get overwritten, and the issue with letting the masses use it. You have to teach them how to copy and paste, and 90% of them won't even bother to read, therefore making a post about X and Y not working. So keep that in mind as well if you plan on releasing things.

 

[stealthy]

That would be great. OldRoutine is definitely showing its age, then.

Yeah, agreed - it's not a thing I enjoy walking people through, lol. I think it'd have to be a matter of getting the routines improved and stabilized and forking those, too... but, time will tell

 

[kingpinning]

looks good. using it already

ty for release

 

[yfbd]

The thing with initial old routine design was an all in one routine. That had examples for people to use to make their own. I believe it was designed for comparability across multiple builds, a jack of all trades. It is better and more effrcient to customize a routine for a build. But the sheer amounts of builds one can use is astounding.
Oldroutine has some redundency in it because of that. Keep in mind a profile based routine would work better imho, so I believe that was what tnyx was doing, until he got rekt and is now on diaper duties.

 

[stealthy]

Yeah - the sheer number of possible variations in build is why I've been trying to improve on it. I think a common "jack of all trades" build would cover ~80% of the build variations if done well... but there are always going to be the oddballs out there that needs to start from scratch.

Most of my work so far toward tweaking OldRoutine has been toward making it a bit less slow to react, making it better handle multiple available auras & golems, and making it less suicidal for ranged / fragile characters. A catch-all will never handle a full blown Cyclone build as well as a dedicated routine, but it can at least figure out the "big & tanky meatwall" and "fragile ranged damage" sterotypes well enough to cover most scenarios.

 

[yfbd]

K, I'll see if I can get workarounds for stucks on certain maps, for now for the channel map.

            if (currentWorldArea.IsMap && currentWorldArea.Name == "Channel")
            {
                var seed = LokiPoe.LocalData.AreaHash;
                if (_tgtSeed != seed || _tgts == null)
                {
                    Log.Info($"[{Name}:MoveTowards] Now building TGT info.");
                    _tgts = LokiPoe.TerrainData.TgtEntries;
                    _tgtSeed = seed;
                }
                if (TgtUnderPlayer.TgtName.Equals("Art/Models/Terrain/Act4/Aqueduct/aqueduct_lower_connection_v02_01_c2r2.tgt")
                || TgtUnderPlayer.TgtName.Equals("Art/Models/Terrain/Act4/Aqueduct/aqueduct_lower_connection_v01_01_c2r2.tgt"))
                {
                    Log.Info($"[{Name}:MoveTowards] Channel Map force adjustment being made!");
                    pointOnPath.Y += 9;
                }
            }

For Spider Forest, best solution atm is to log out, the same for Caverns,
Factory I can fix, but the above 2, i'll probably have to use an block object onto the mesh to make it not move there.

Edit Also noticed that when moving to a location, we have to take into account the Min/Max of the skill's movement. I.E Whirling blade has Min value movement distance, therefore if the Min value is lower, don't WB, that removes some back and fourth while trying to get closer objects or whatnot.

 

[stealthy]

We should really extract the map/area-specific custom adjustments to something more suitable. We've already got one in there for Act 3 (which appears to be a direct copy of the logic used in the base PlayerMover) and I can't imagine Channel is the only map that'll require some custom handling.

 

[yfbd]

Can't because using the TGT is expensive I assume, because it will probably check during the async. It's best to perform these on a per map/location basis, so other areas that do not have stucks don't need the checks.

Therefore I concur with your logic for this, and probably need a "List of maps that require specific logic for stucks" list, and process it from there. I gotta get to work, but yea.

Edit also keep in mind. For locations like spider lair, you can get stuck with WB, but you can pass it with Lightning warp. So it's a lot of this we gotta do lol.
I think the best approach is adding an object onto the mesh so pathing ignores pathing to it. I'll have to ask pushedx or Tor again to see what it was they told me a while back.

 

[stealthy]

I've got good news and bad news.
I've spent the last few days playing on a high-latency connection and low-end machine and, as a result, have been working on making the player-mover more tolerant of high-latency situations and further optimizing it. It's going well.

The good news:
In conjunction with these, I've made Old Routine's movement capable of *not* walking face-first into a monster if it encounters one out of line-of-sight.

The bad news:
At this point, my version of Old Routine has diverged from the original enough that in order to get *those* changes to you guys, it'll have to be forked and released as its own combat routine, too.

 

[toNyx]

I've got good news and bad news.
I've spent the last few days playing on a high-latency connection and low-end machine and, as a result, have been working on making the player-mover more tolerant of high-latency situations and further optimizing it. It's going well.

The good news:
In conjunction with these, I've made Old Routine's movement capable of *not* walking face-first into a monster if it encounters one out of line-of-sight.

The bad news:
At this point, my version of Old Routine has diverged from the original enough that in order to get *those* changes to you guys, it'll have to be forked and released as its own combat routine, too.

Well there's plenty of issues when it comes to that. There's already a looooooot of routines forks that it became ridiculous to find a working one because people stop botting/updating them.

Maybe set the routine github, so people (that know how to use github) can play with it if anything happens?

 

[stealthy]

Well there's plenty of issues when it comes to that. There's already a looooooot of routines forks that it became ridiculous to find a working one because people stop botting/updating them.

Maybe set the routine github, so people (that know how to use github) can play with it if anything happens?

That's the plan. It's already on a private Bitbucket repository; all I have to do is make it public.

 

[stealthy]

I've made Skill-Aware Player Mover's Bitbucket repository public and add both it and the Trello board I've been using to the first post.

 

[stealthy]

Version 0.0.1.5 has been uploaded. Here's what's changed since 0.0.1.3:

0.0.1.5:
Improvements:

• Remove unnecessary Coroutines.FinishCurrentAction calls in order to improve responsiveness
• Code cleanup & removal of unnecessary / dead code
• XMLDoc cleanup
• Convert Dodge, Kite, & FleeStrongbox operations into their own yielding coroutines
• Gate Tick() rates to 200ms in order to avoid excess work and FPS loss

Fixes:

• Clear key states before attempting to use a movement skill
• Use skill.CanUse() instead of skill.IsCastable

0.0.1.4 (internal-only):
Improvements:

• Skill-based movement now uses shift-based casting
• Remove some log spam

 

[IeU]

Thank you stealthy, much appreciated!

 

[eatinapineapple]

Version 0.0.1.5 has been uploaded. Here's what's changed since 0.0.1.3:

0.0.1.5:
Improvements:

• Remove unnecessary Coroutines.FinishCurrentAction calls in order to improve responsiveness
• Code cleanup & removal of unnecessary / dead code
• XMLDoc cleanup
• Convert Dodge, Kite, & FleeStrongbox operations into their own yielding coroutines
• Gate Tick() rates to 200ms in order to avoid excess work and FPS loss

Fixes:

• Clear key states before attempting to use a movement skill
• Use skill.CanUse() instead of skill.IsCastable

0.0.1.4 (internal-only):
Improvements:

• Skill-based movement now uses shift-based casting
• Remove some log spam

Thanks man I'll give these a shot. Any particular feedback you are looking for?

 

[cyberbot]

What is the blacklist timeout for? Why does the plugin not use the skill when it is usable and walk instead? I am hoping that the plugin would spam my move skill more (I understand backtracking could happen this way).

Thanks.

 

[IeU]

Yes, there is a global delay if i am not mistaken . . .

 

[darkbluefirefly]

What is the blacklist timeout for? Why does the plugin not use the skill when it is usable and walk instead? I am hoping that the plugin would spam my move skill more (I understand backtracking could happen this way).

Thanks.

Low fps or Vm. It's always going to have a delay. No way around it.