General Combat Routine [Current: 0.0.1.1] - Picking up where Old Routine left off

General Combat Routine [Current: 0.0.1.5] - Picking up where Old Routine left off

This is a generalized combat routine intended to cover the majority of standard combat scenarios in an effective and more survivable manner. I had realized while working on Skill-Aware Player Mover that many of the perceived movement issues are a result of poor movement logic in Old Routine - in order to fix those, Old Routine needed to be forked. This is the result.
My goal is to cleanup, expand, and improve the existing combat routine so that it will cover most general uses and will serve as a great starting point for specialized builds, with the community able to contribute instead of the code growing stale and dying.

It is very much a work-in-progress and should not yet be considered stable. I primarily test with a ranged glass-cannon caster; melee-centric builds may have been impacted without my notice.

The list of things improved or fixed is already pretty long, but there are definitely more things to do yet. I'll document those as able, primarily on Trello.

Code & Tasks
Public Trello board: General Combat Routine
Bitbucket Git repository: jeremy-sylvis / General Combat Routine — Bitbucket

Credits:
BosslandGmbH, for the routine this is forked from

Downloads:
See 2nd post.

 

Releases & Notes
0.0.1.6:
Improvements:

• Slight optimization to skill discovery
• Add basic support for use of Vaal Discipline - it will trigger when under 40% energy shield, if available
• Move some Monster queries from Tick() to Logic() to avoid unnecessary FPS loss

Fixes:

• Correct range-based movement logic so that it gets closer if outside MaxRangeRange instead of MaxCombatRange

0.0.1.5
Fixes:

• Fix pathfinding's calculation of possible alternate points in line of sight of the target, which was failing due to a misplaced integer cast
• Fix pathfinding's skipping of possible alternate points due to failed raycast

Improvements:

• Avoid combining Raycast and CanObjectSee checks since CanObjectSee just internally calls Raycast

0.0.1.4
Fixes:

• Fix usage of the Discipline aura, which was failing because Skill.IsConsideredAura and Skill.AmIUsingConsideredAuraWithThis fail for Discipline

0.0.1.3
Fixes:

• Fix a NullReferenceException caused by a poor assumption that a user would always have a skill in Slot 4

0.0.1.2
Fixes:

• Raycast in addition to the other checks when pathfinding a ranged point near a monster in order to avoid having an object which blocks projectiles between us and the target

0.0.1.1
Improvements:

• Out-of-sight and out-of-range Movement operations no longer walk face-first into the target monster and, instead, move to...
• The first point in line-of-sight of the target, if the monster isn't too close to that point for safety...
• ... or a point within your maximum range of the target, in line-of-sight, in a 180* arc centered on the line segment defined by that first point to the target monster
• Support for more than one active Golem
• Support for all available Golem and Aura skills, not just those currently active on the Skill HUD
• Skill ID blacklist applies to all available skills, not just auras
• Slot 4 will be used as a temporary slot for using skills (e.g. Auras, Golems) not currently on the Skill HUD
• All Skill usage should be more quick-to-react due to removal of unnecessary waits and re-positioning of the necessary waits
• Targeting now applies high-priority targeting to monsters known to inflict rapid bursts of damage from range (e.g. chaos damage cobras, Nightwane)
• Frost Wall usage is now supported - Frost Walls will be placed between the player and its current target, frequently protecting it from inbound projectiles
• Orb of Storms usage is now supported - Orb of Storms will be placed again whenever it expires or whenever we've moved out of our best-guess of its range of effect
• Logging & Codebase are cleaner - it's easier for others to join in!
• Optimization and improvement of efficiency wherever possible, in order to reduce CPU-intensive work and FPS impact

Fixes:

• Aura activation and Golem summons are done as a pseudo-pre-combat step, avoiding death to minions during pre-combat prep
• In-combat minion summons won't be performed constantly to the neglect of other skills, avoiding another way we commonly die
• Pure ranged builds will no longer get confused when killing Proximity Shield monsters due to attempting to move within 0 distance of the target
• We reset the tracking of whatever skill we're continuously casting when we detect no skill is actively being cast, thus better handling failures to cast due to high latency

 

Here is an example of the settings I'm using for my ranged glass cannon caster.

 

Holy pepperoni!

thank you

 

...are you a god among men? Thanks - Will test.

 

No, just a developer with a love for automation.

Thanks! I could definitely use some other people testing this. I'm sure I've missed something with melee-centric builds.

 

Very glad to see someone working on combat routines publicly. Its an area of development this bot has desperately needed for a long time.

Appreciating your efforts!

 

So far it performs quite nicely from what I have been noticing, only grief I have in is just that strongboxes and obstacles are blocking projectiles, so bot is getting arse handed out with blocking box while monsters are on opposite side (their projectiles are not apparently blocked by these boxes) so question is, how would I go around to navigate around the damn box to kill the monsters? (bend it from barbwire, since I am really coding illiterate)

 

What projectile, out of curiosity? I've noticed Frostbolt's orb seems to be "wider" than other projectiles which may affect it.

I can check for strongboxes during the Line of Sight check. What other objects are acting as obstacles? Chests?

 

Normal chests go past it, trees and other artifacts along with strongboxes are getting the block. I am using Lightning Strike here with wide area spread with 14 projectiles.

 

It's interesting that ExilePather.CanObjectSee is failing to detect those blockers. I suppose it can technically see the target... I'd be willing to bet a raycast would fail due to the blocker.
I'll work on that.

 

I've uploaded 0.0.1.2, which raycasts for blocking objects in addition to the other existing checks. It's worth noting this currently only applies to attempts to find an acceptable point to move to if we've already decided we need to move - it does not, yet, affect whether or not we believe we need to move (e.g. if we consider the monster to currently be out of line-of-sight).

You'll be looking for a debug message starting with "[General Combat Routineathfinding] Discovered collision at position". If you see this, it's skipping a potential point due to raycast-detected collision, which means it's working and I can extend the line-of-sight checks.

This probably sounds a bit flawed - fixing "line of sight" detection in the movement but not in determining whether or not we should move - but it will most definitely be triggered at some point.

 

Getting this error, uncommenting it solve, not sure if it breaks elsewhere . . .

 

It won't break anything important. It is assuming there's a skill in slot 4, which is a bad assumption. If you don't have a skill in Slot 4, it will *definitely* throw that null reference exception. I'll fix that soon.

 

This *should* be fixed in 0.0.1.3.

 

wow this is awesome thanks

i have a problem that it spams discipline aura, other auras work

thanks

 

You're the second person to have reported an issue specifically with Discipline.

I'm going to have to grab a skill gem for it and take a look at why that is. For now, you might want to blacklist the skill.

 

Also keep in mind that when performing calcs to positions, it eats cpu. Therefore VM's will choke.
Also for the discipline thing. The code you are using to cast auras that are not on skillbar but hidden, if you have more then skill on the skillbar that's an aura, it's going to spam it. You need logic to detect which slot was casted.
I haven't tried it yet, but it's from my experience of what happened when I did something similar with a Dual golem Eli aurabot.

 

Perhaps. I'm running this on a Surface Pro 3 with a dual-core i7 currently thermal throttled down to roughly 760mhz and it's running fairly well - negligible difference from pre-pathfinding, at least at this low FPS. I still need to do a before/after comparison on my main machine. My point is, I think your VM will be fine

I currently run 2 auras and 2 golems on my Witch and it's able to figure out which to use by detecting whether or not it has the skill's buff. It appears to not be detecting Discipline's buff for whatever reason... so far it's the only exception to multi-aura builds working well.

 

Here's the problem with Discipline:

As compared to Arctic Armour:

Note: Is considered aura + Am I using considered aura with this