Announcement

Collapse

Forum Rules

  • No flaming or derogatory remarks, directly or through insinuation.
  • No discussion, sharing or referencing illegal software such as hacks, keygen, cracks and pirated software.
  • No offensive contents, including but not limited to, racism, gore or pornography.
  • No excessive spam/meme, i.e. copious one liners in a short period of time, typing with all caps or posting meme responses (text/image).
  • No trolling, including but not limited to, flame incitation, user provocation or false information distribution.
  • No link spamming or signature advertisements for content not specific to Dota 2.
  • No Dota 2 key requests, sell, trade etc.
  • You may not create multiple accounts for any purpose, including ban evasion, unless expressly permitted by a moderator.

  • Please search before posting. One thread per issue. Do not create another thread if there is an existing one already.
  • Before posting anything, make sure you check out all sticky threads (e.g., this). Do not create new threads about closed ones.
  • It is extremely important that you post in correct forum section.

  • Balance discussion only in Misc.
  • All art related (such as hero model) feedbacks go to Art Feedback Forum.
  • All matchmaking feedback should go here: Matchmaking Feedback
  • All report/low priority issues should go here: Commend/Report/Ban Feedback
  • No specific workshop item feedback. These should go to workshop page of that item.
  • When posting in non-bugs section (such as this), use [Bugs], [Discussion] or [Suggestion] prefix in your thread name.



In case you object some action by a moderator, please contact him directly through PM and explain your concerns politely. If you are still unable to resolve the issue, contact an administrator. Do not drag these issues in public.



All rules are meant to augment common sense, please use them when not conflicted with aforementioned policies.
See more
See less

August 24 Bot Update

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by nostrademous View Post
    Not necessarily. It really depends where the evaluation happens. Currently no timers exist so the remove of any AZ would have to be done by player code. What I suggest is the same with the addition that a termination assertion is embodied with the AZ so that in our bot code we don't have to iterate all the AZ as we have a reference to the termination function which was established when we created the AZ in the first place. This would allow re-use of typical AZ termination assertions (like timers) if it made a new copy of the function when associating with an AZ (rather then just passing it by reference).

    The iteration over all the AZ's and their associated termination assertions could just be another pass complete as part of the player code time (most likely prior to each bot's Think() execution).

    The table we pass would only need to be remembered if the termination assertion evaluation is done on the server code, and not as part of player code.
    Not sure I made myself clear yes, the function is passed but it will be saved as a pointer deep down in the native code. The params you pass it would not be part of it unless they are explicitly saved separately along with the callback in the engine. I was talking about the C++ part, not the Lua part. But that was just a remark

    Originally posted by ChrisC View Post
    Bot pathfinding uses a first-pass pathfind though the bot's pathing grid, using the weights from the built-in bot avoidance system -- it makes pathing through towers, etc more expensive. "Normal" is just a straight-up right-click.
    When is the avoidance system used? If I ask a bot to tower dive, they won't avoid it, but will gladly feed. How would I access the weight-vs-desire algo to make a bot avoid danger areas when moving? Also, is the AttackMove() action using the same pathfinding algo as MoveToLocation() ? What about MoveToUnit() ?

    Originally posted by ChrisC View Post
    The intention of the default-bot avoidance zones is that they're applied to all bots on a team, and have some information contained within them ("does physical damage", "does magical damage") etc, and different bots would react to them differently based on their details (tanky guy can ignore physical damage, if you have bkb active you can ignore the magic ones, etc). In practice, I don't think this actually works that well because they don't really capture the full breadth of the circumstances of avoidance for a given bot. I suspect that managing a moment-to-moment "absolutely do not path through this zone" list for each bot, along with a few generic "this is so bad that one one should go through it" zones works better for the specific details of what each bot wants to avoid. So that's the idea behind these new avoidance zones (and if I had the built-in ones to do over, I think that's how I'd write them).
    Is fissure considered an avoidance zone (in the native AZ functions, not the custom ones) ?
    While similar to Ice Path or Macropyre, those do continous damage, while fissure deals damage only when casting and then is just an annoying impassable wall If not, how do I detect fissure?

    Originally posted by ChrisC View Post
    So I guess my recommendation is to punt on the old avoidance stuff entirely.
    Oh I had a look at the code more closely and I was actually thinking of spicing it up by mixing them. The only thing that stopped me is that the "native" (or should I call them "old" from now on ? ) AZ don't have any expiration time either. Since you said we should either drop them or that if we were to aggressively use it, you'd redo them, I am not sure if you want to invest more time into them (and ATM I don't know if anyone other than nostrademous is using the old AZ), but if it is not too much effort, could you add something like time_remianing or something like that to the old AZ structure?

    If you do plan to update the new AZ with the suggestions you got from me and nostrademous (and most likely others that will start using them) others might want to take advantage of the old ones somehow too (even if to manually to the physical vs magical logic since some plan to upgrade to ML from the SBM logic) and I don't know how much overhead GetAvoidanceZones() since I haven't tried it yet in an actual 60+ minute game. Then again, if iti is too complicated or you say that GetAvoidanceZones() doesn't draw out too much performance power, I guess I can just call it and iterate through it each frame and sync it with AddAvoidanceZone() and RemoveAvoidanceZone().
    Last edited by The Nomad; 08-27-2017, 12:44 AM.
    Explanations on the normal, high and very high brackets in replays: here, here & here
    Why maphacks won't work in D2: here

    Comment


    • #17
      @ChrisC: I tried the path finding functions. Can you please explain the followings a bit:

      1. Sometimes when I generate a path and pass it to the Action_MovePath, the bot gets stuck or the function doesn't return a path (I do that in every frame, and the bot is not in any of the avoidance regions). Can you do a quick check if there is a problem with your code that can cause this? Or doing this in every frame causes a problem?

      2. Why do you need a function in generating path function instead of returning the path and its length? Are the paths generated in parallel (i.e. in a separate thread from the actual script)?

      3. What are the cases in which generate-path fails? (for instance, does it always fail if the beginning/end is in an avoidance zone?)

      4. How computationally heavy is the generate path function? Is it noticeably faster if we add the avoidance zones instead of using them in each call manually?

      5. For all the cases where there exists a valid path that avoids all the zones, does the generate path function returns an actual valid path (at least in theory)? Or is it a heuristic that may or may not generate a path conditional on the existence? If it doesn't have such guarantees, do you know of some scenarios that it doesn't generate a path?

      Comment


      • #18
        Originally posted by Platinum_dota2 View Post
        3. What are the cases in which generate-path fails? (for instance, does it always fail if the beginning/end is in an avoidance zone?)
        This interests me as well. I am curious about reachability (such as if trees are in the way even thought the "target" location is passable (or visible).
        There is also the difference in how a bot controlled hero considers a target destination reachable vs the way a human controlled hero does (e.g. a human controlled one can approximate that hey reached the target within a threshold while a bot insists that their location and the target location must be the same for it to be considered "reached").
        Explanations on the normal, high and very high brackets in replays: here, here & here
        Why maphacks won't work in D2: here

        Comment


        • #19
          it seems that the pathing grid resolution is a little bit small which cause the pathfinding to fail on a lot of juking spots, also the actual state of trees is not considered (the pathfinder will avoid chopped trees).
          i also hope the pathfinding (optionaly) consider units too.(maybe this will help a shapeshifted bot lycan going for a kill while bodyblocked by a creep).
          Last edited by DzeeRay; 09-13-2017, 01:37 AM.

          Comment


          • #20
            Originally posted by Platinum_dota2 View Post
            @ChrisC: I tried the path finding functions. Can you please explain the followings a bit:

            1. Sometimes when I generate a path and pass it to the Action_MovePath, the bot gets stuck or the function doesn't return a path (I do that in every frame, and the bot is not in any of the avoidance regions). Can you do a quick check if there is a problem with your code that can cause this? Or doing this in every frame causes a problem?

            2. Why do you need a function in generating path function instead of returning the path and its length? Are the paths generated in parallel (i.e. in a separate thread from the actual script)?

            3. What are the cases in which generate-path fails? (for instance, does it always fail if the beginning/end is in an avoidance zone?)

            4. How computationally heavy is the generate path function? Is it noticeably faster if we add the avoidance zones instead of using them in each call manually?

            5. For all the cases where there exists a valid path that avoids all the zones, does the generate path function returns an actual valid path (at least in theory)? Or is it a heuristic that may or may not generate a path conditional on the existence? If it doesn't have such guarantees, do you know of some scenarios that it doesn't generate a path?
            1. & 2. Pathfinding is expensive and the pathfinder has a limited amount of time it's allowed to work in any given frame, so path generation is asynchronous and might take multiple frame to complete. In addition, it only allows a few (I believe 5) pathfinds to be in flight at once. Your best bet is to keep track of your location and your target location, and only pathfind when they've deviated significantly.

            3. If there are no paths to the location, which includes the starting or ending locations being in an avoidance zone.

            4. Long pathfinds can definitely be expensive, but avoidance zones don't change it THAT much, and it doesn't really matter at all if they're persistent or passed-in avoidance zones. Tens of avoidance zones is probably free-ish. Hundreds probably start impacting perf a bit, but given that the pathfinder has a per-frame cap, it just means that it will take more frames to get back to you with your path.

            5. I believe it should generate a valid path, where a valid path exists. If it doesn't, I'd consider that a bug.

            Comment


            • #21
              The generate path function is very useful, thank you!
              I'm struggling with one thing though. Because it is async, the callback function is frequently called at a moment in time unrelated to the execution of the calling bots code. The result is that it's very painful to track who called the function when the result comes in since bots use the same variables. the best way I found was to look at the first waypoint in the result and check which of my bots is closest, but that doesn't always work because of the low resolution of the collision map. Occasionally it ends up selecting the wrong hero and so one of my bots starts following the orders of another.
              Is there a way of structuring lua files such that it can easily be kept straight? Or could some way of identifying the caller bot be added? Making GetBot() work inside of the callback would help a ton

              Additionally. I know the coarse grid is for performance reason, but is there some way we could gain access to finer pathing grid for short distances? My bots sometimes get stuck like this:
              Code:
               |   |
              O\___/  
                    X
              Where O is my bot trying to get to waypoint X but gets stuck behind a tiny obstacle.

              Comment


              • #22
                I'm going to change the callback function to take an additional parameter (sorry, this will break scripts!) that is the index returned by the GeneratePath call, so you can tell which callback corresponds to which pathfind.

                Comment


                • #23
                  It'd would be great if you coudl also implement some of the suggestions from this thread as well If you have time of course
                  Explanations on the normal, high and very high brackets in replays: here, here & here
                  Why maphacks won't work in D2: here

                  Comment


                  • #24
                    Thanks Chris! That would certainly do the trick

                    Comment

                    Working...
                    X