Threading for CRs

[birduvprey]

So in the midst of using Death's Agility bot and the predefined combat routines, I started developing questions on what I would want to see happen with combat routines going forward.
The first big issue for me is understanding threading. Likely we'll need at least 2 threads if not three running at a time to truly make combat routines "smart."
One thread for main action handling, spell casting, etc.
A second thread that monitors player telegraphs to face the bot in the proper direction.
And likely a third, now that I think about it, that handles enemy telegraphs for interrupting, avoidance.

Would these be something the frame work should handle or a routine? Forgive my very novice coding skills, I'm attempting to sharpen them more with this bot.

 

[Deathdisguise]

C# and .Net provide us with Async and Await methods which can effectively do what you're thinking, as well as countless frameworks in C# to handle multi-threading if necessary, but I don't think it would be.

These would be things you'd handle at a routine level.

 

[walter]

So in the midst of using Death's Agility bot and the predefined combat routines, I started developing questions on what I would want to see happen with combat routines going forward.
The first big issue for me is understanding threading. Likely we'll need at least 2 threads if not three running at a time to truly make combat routines "smart."
One thread for main action handling, spell casting, etc.
A second thread that monitors player telegraphs to face the bot in the proper direction.
And likely a third, now that I think about it, that handles enemy telegraphs for interrupting, avoidance.

Would these be something the frame work should handle or a routine? Forgive my very novice coding skills, I'm attempting to sharpen them more with this bot.

All easy to do with a Pulsator. Just make plug-ins and try to keep most of stuff out of the routine besides combat. I wouldn't try to mix too much into the main routine since could cause issues in long run.

Default routine has evade code that can be put in but still needs quite a bit of testing. Was tested during beta of wildbuddy but lots of things came up. All the math is done to hard parts but some core API stuff needs adjustment. I could cover more of this in detail if you would like.

Wildbuddy already can handle interrupts but testing of how many left in groups requires more logic. It was working at one time but this game is programmed by fail devs with carbine logic. More bugs than fixes each patch.

Walter

 

[birduvprey]

So essentially, interrupt plugin, facing logic and avoidance plugin? Or keep evade code within the main CR? This is the area I'd like to start my coding adventures with WildBuddy, developing a better core CR for my warrior and engineer.
I'll start looking at the default routine and see waht I can figure out.
Any and all insight in to what may need tweaking or testing from the core routines, would be awesome.

 

[Lukov]

Interrupt and Facing logic are already both in the Default routine, and as of right now, there doesn't exist any fully working telegraph avoidance logic.

If you want to try working on that, the Omnibus routine has some partially implemented dodge code that you can try to port over.

 

[birduvprey]

Thanks Lukov, I'll check it out.
Looking at the defaults now to implement onslaught etc into DD's Agility bot.