a quick simple fix is for all spell ID's that are cone based simply replace all with reachsmall, did the trick for about 90% of the spells.
I'm thinking of completely changing how spell shapes are described. Instead of specifying many flags like reach, direction, etc., it would offer you a menu with kinds of spells (like Type A, Type B) so whenever you want to add a new spell, you just specify it's kind. So for example, a normal medium sized frontal cone would be Type A. This would hopefully make the spell shape database more precise since people can't arbitrarily decide a spell has a medium reach when in reality it should be small reach. It would also make the logic more elegant and precise, since it would know exactly what kind of spell it is and not have to work with wrong information. I could make real measurements, like Type A cone spells have a reach of 7.534 yards instead of just a general "Small Reach" value. It would also permit me to code in specific logic for specific spells, like Boss abilities that cover half the room.
I'm not sure I understand. How would separate enums for each combination be effectively better? How does this help you know exactly what kind of spell it is or prevent wrong information? People would be just as likely to choose the wrong types as they would be to choose the wrong attribute flags. With elegance and precision: you would need to declare cumbersome categories inside of the enum to allow you to pull shape/direction or other partial data from the spell type. Flag attributes remove the redundancy of these categories and remove the chance of errors from those declarations. Are the types not going to have length data and you're going to define that on your end? You could do the same thing with attribute flags. If people are choosing types for the size, you can have the same declaration problem :S You could have multiple size categories to get your more accurate measurements. For each spell that requires specific logic: instead of adding another type, all you need to do is add one additional attribute flag.
I'd like to know if I'm doing something wrong, every time my toon need to avoid a spells he runs too far from mob, if he need to dodge a frontal cone spells he runs 10y (too far) and then changes target. When I'm in a fate and any of the mobs cast a spell, he runs so far that CR picks another target. In 3 min he aggroed all fate and killed nothing. (sorry my bad english
You'r right in the points you made Kaihaider. What I meant was I'll keep the flags, but change how people enter new spells. Here's what I'm thinking, Zekken currently has these problems I'd like to address: Even though I convert the Reach flag to a numeric value during avoidance, having only 3 types of reach and width makes some spells be imprecise. I'd like to add more specific dimension flags, but it'll make entering data by users more cumbersome and prone to mistakes. Adding magnitudes and averaging angles of "escape vectors" works when there's few spells going on simultaneously, but in many fates due to the amount of spells going off it can lead to endless kitting like what r4vn0s above me mentions. This method of avoiding is also not optimal. It only considers avoiding spells that are being casted, and once the spell goes off it no longer considers it. This doesn't work for many spells, especially in bosses, where the area where the spell was cast is left affected for some time. Due to only using the Navigator.PlayerMover.MoveTowards() to avoid, it often tries to run into walls or falls off cliffs. So what I'm thinking is doing the following: A) Add a numeric field on spell shapes called "duration", which will be used to know how long to keep considering the spell's area bad after the spell is cast successfully by the mob. B) Since we're adding a numeric field to shapes already, change the flags. Keep the shape, target, and direction flags, but remove the reach and width ones. Replace those with numeric values. C) To make it easy for people to add new spells, I'm going to go and measure the exact reach and width of the most common spell shapes with the console. I'll take a clear picture of the spells, and add a window on the Settings menu of Zekken where you can add a new spell by browsing through these pictures as if it were a catalog, and selecting which one looks the same as the new spell you want to add. It's basically choosing from already made prototypes, copying their values and just changing their ID. This should make it so spell shape values get correct values more often. D) Now that I have exact dimensions for spells, change the avoidance logic to a sort of a "radar with pathfinding" approach. I envision it as having these modules: The spell cast detector that's already there, but extend it's functionality so it uses the "duration" property of spell shapes to also keep active permanently affected areas as bad to step in. A shape intersection calculator, that given a list of active spell shapes and their respective enemy positions taken from the detector, and given a Vector3 position, it tells you if any of the spell's shapes intersect the point. A pathfinder (perhaps A*) which uses the intersection calculator to search for the closest safe spot the player can move to, starting the search from the player's position until it finds a position that no shape intersects. The pathfinder would have a heuristic function that makes it prefer moving towards the player's original position before avoidance started, that way endlessly kiting away would hopefully be minimized. A movement module, that given the pathfinder's result, it asks the Navigator to generate a path towards that position using the mesh. If the navigator is unable to find a path towards it, "blacklist" that area and ask the pathfinder to find another safe spot. Do this until a viable one is found, then move towards it. If I could somehow access the local mesh of the player's vicinity I could check for this during pathfinding itself instead. That's what I'm thinking, but it'll take some time to make it, perhaps a couple of weeks to make something testable with a few shape prototypes.
r4vn0s, right now the best you can do is search for the spell that's giving you trouble in the spell shape database and change it's "Reach" flag to something smaller. To find the spell on the database, you can look at the bot's log when it's avoiding that spell and you'll see a message in purple thrown by Zekken, it shows the spell's ID. Do a Ctrl+F with that ID on the spell shape's database file and change the flag there.
Did you try the approach I mentioned in our pms, with CanFullyNavigateTo? Create a score of points, calculate to check for points that are safe, send 10 of those points into CanFullyNavigateTo and move to the closest one that is navigable? A lot faster than back to back nav calls and will help nav calls failing because move point has it's z axis off of the terrain by a smidge. Not perfect but it's what I was always planning on trying =/
I must have missed that one, but definitely sounds good. Is that method on the player mover or navigator?
You could use it for either movement type. Just tells you which points are on the mesh. So if you use player mover then it won't warn you if there's an obstacle between you and that mesh point but it would stop most of the stucks and you could keep track of your location and switch approach/location when you get stuck. If you're using nav moves then it would be faster than back to back nav call attempts and I've noticed failed nav calls don't always return the correct moveresult.
I love you~ I love you~ I love you~ with this, now people are not going "you noob or bot?" while I use grindbot. Now I think I can actually use fatebot and not look like the obvious bot standing in everything.
Do you mean the XDatabase.xml file? That's the only file that should be left in that folder after a compile. If one of your entries gets deleted, it's because there was already a repetition of it somewhere, so just edit the original entry better. I just tested it and it's working fine for me.
From the XDatabase.xml file? That's strange, it doesn't happen for me. Does it avoid spells that you have entered? It is meant to delete every file that is not XDatabase.xml and combine everything into it.
this plugin is great but there huge with issue with mobs with circle telegraph attacks, specially huge mobs for fate runs and there no way to get out of it. aswell some of rectangle attack dont work well aswell. i hope this is fix asap and thenk for your time
Any chance to get this to work with the assist bot? would see this working great from the HM and EX primals
Yeah don't worry about it deleting the files on compile, that's normal as long as it's still avoiding stuff. The problem with circle spells being done with a lot of mobs is something that I'll try to make better on the next version, but there's no easy fix. You would either have to choose to go in and take the hit, or keep moving out. The plugin doesn't work with combat assist (I recommend you download ExCombatAssist instead of using the normal Combat Assist, it's here on the forums) because that bot base has no autonomous movement since it's meant to just keep your rotation while you control your character.
i did that why i posted my comment. ExCombatAssist doesnt change much of avoid the circle telegraph attacks specially for fates at 44+ and dungeons.
So I downloaded this yesterday and gave it a try overnight. I watched it for a few hours then decided to let it run while I slept and it worked pretty well. It's a little clunky in regards to the way it stops the CR while it's moving to it's position, but I understand why it needs to work that way without a proper API to recognize telegraphed attacks. This is a good plugin and one I would love to see expanded upon. I do have one request from what I noticed when I woke up this morning. I woke up, dead, at the bottom of Witchdrop Cavern (24, 17 In game) in Coerthas lol. What happened was during the fate "Coming to a Head" the plugin went to move out of the way of a telegraphed attack, and it did move, right off the cliff, down into the cavern, and to my imminent demise lol. This hasn't happened again within the last few hours and I'm sure this was a coincidence, but it is something that would benefit the plugin in the long run so I thought I'd mention it. Is there a way to add a height check to the coordinates that it designates "safe" to move to so it does not fall off cliffs? lol That would be great. I apologize for not adding a log. If I can recreate the issue I will try to capture the log when it happens so it's not 7+ hours of data to sift through.
