Page 2 of 39 FirstFirst 1 2 3 4 12 ... LastLast
Results 11 to 20 of 381

Thread: API Requests

  1. #11
    Quote Originally Posted by trevorflux2 View Post
    I would love to see more mechanics in the API. For now most of the stuff seems related to the bigger picture, the team work, etc.

    But I would love to have, for example:

    * Being able to wait a specific amount of milliseconds after the last action *started* and then cancel it.
    * Being able to target a point IN FRONT of my target enemy, i.e. target a point in front of the enemy nearby hero, towards the direction he is facing, X units away from him. Extremely useful for many aoe skills that require trajectory prediction. Also, the option to deviate this by a certain angle (useful for when enemies usually dodge your aoe skills).

    edit: For clarity, this would be similar to an extrapolation of GetUnitPotentialValue() into the future.
    Surely movement extrapolation is something you would do in the AI? predicting anything but a simple linear extrapolation is a large part of what makes your bot different/better.

    Even if you just want linear extrapolation it's just a single trivial vector operation.

  2. #12
    Basic Member
    Join Date
    Dec 2016
    Posts
    121
    Thought there are something like 'get_location_nearest_tree()' already exist for tango use?
    Can't find it in scripting page but need it for timbersaw/broodmother skill.

  3. #13
    Valve Developer
    Join Date
    Sep 2011
    Posts
    1,660
    There's a GetExtrapolatedLocation() API call which takes a time in the future that probably does most of what you want.

    There's also GetMovementDirectionStability() which indicates how much their movement direction has recently changed. ("Serpentine!")

  4. #14

    This API should probably get another pass before integration into non-test.

    Please restructure your API while you still have the chance - it'll get harder on everyone as time goes on. The approach that you are currently going for has several downsides:


    1. The current system encourages designing AIs that are inflexible, and only work for dota. This means that you're going to get little to no cross-over benefits for custom games, which is a real disappointment.
      Suggestion to fix: Change the structure of the AI API such that there are four different kinds of AIs that you can add: strategic, tactical, hero-macro, and hero-micro, with separate workshop entries and well-defined APIs between them. This means that custom games that use dota heroes in different situations will be able to rely on the hero AIs from dota, and simply override the strategic and tactical AIs with something mode-appropriate.
    2. The structure of the high-level AIs limits systems to certain strategies.
      Suggestion to fix: Change the objectives established by the high-level AI components from explicit enum values to more abstract structures; having the AI have the ability to say "mount an offensive against this object" or "sweep this area for enemies" would be very useful. This also helps with custom games; a general set of capabilities means that developing a strategic AI for a custom game could be a fairly simple finite state machine, with defined objectives structures to use at each state.
    3. The current system only allows a single AI workshop item to be used per team. This is bad for several reasons; firstly, any single group would be hard-pressed to implement good bots for every dota hero. As such, any complete AI would be either very primitive on most heroes or require massive buy-in in terms of combining several AI mods into one super-mod. These groups tend to be somewhat unstable and there's been a lot of issues flying around about the rights to workshop items; I know of multiple people who with custom games have their materials used without permission or license with no effective recourse. This also limits the quality of these AIs; with so much overhead to making a complete AI mod, there's going to be fewer of them, and so less competition to drive progress in the area.
      Suggestion to fix: Split up the AI components in the workshop so that individually excellent pieces can become individually excellent and be used in conjunction with one another.


    I understand that there's an interest in getting something shipped, and simply adding hooks to the existing AI functions is an easy way to do so, but please structure it so that it'll be healthy and versatile in the long term, even if it takes another week.

    I'm very interested to hear your thoughts on the matter, ChrisC.
    Last edited by penguinwizzard; 12-11-2016 at 07:14 PM. Reason: formatting

  5. #15
    Basic Member
    Join Date
    Dec 2016
    Posts
    2
    API requests:
    Missing actions that you would like bots to do:
    1. Hit and run: cancel attacking animation after attack is finished)
    2. Stop/cancel skill casting(tide hunter ultra, axe roar) when condition change during animation
    Just looking through the example scripts it looks like it should be pretty easy to do using "npcBot:IsUsingAbility()".
    ability_item_usage_lina.lua uses this to make sure the hero doesn't accidentally interrupt it's own cast animation but I don't think it would be tricky to make it do the opposite.
    the only problem I can see is if the script only gets called once per second the delay might be too long to cancel the animation but I'm not 100% sure of the actual tick rate.

  6. #16
    Basic Member
    Join Date
    Jan 2013
    Posts
    1,547
    Ugh. What you done is fantastic, but how end user can use my Venomancer bot and say, Earth Spirit bot from a different creator?? Have you thought of that?

  7. #17
    Basic Member
    Join Date
    May 2016
    Posts
    2
    Quote Originally Posted by penguinwizzard View Post
    Please restructure your API while you still have the chance - it'll get harder on everyone as time goes on. The approach that you are currently going for has several downsides:


    1. The current system encourages designing AIs that are inflexible, and only work for dota. This means that you're going to get little to no cross-over benefits for custom games, which is a real disappointment.
      Suggestion to fix: Change the structure of the AI API such that there are four different kinds of AIs that you can add: strategic, tactical, hero-macro, and hero-micro, with separate workshop entries and well-defined APIs between them. This means that custom games that use dota heroes in different situations will be able to rely on the hero AIs from dota, and simply override the strategic and tactical AIs with something mode-appropriate.
    2. The structure of the high-level AIs limits systems to certain strategies.
      Suggestion to fix: Change the objectives established by the high-level AI components from explicit enum values to more abstract structures; having the AI have the ability to say "mount an offensive against this object" or "sweep this area for enemies" would be very useful. This also helps with custom games; a general set of capabilities means that developing a strategic AI for a custom game could be a fairly simple finite state machine, with defined objectives structures to use at each state.
    3. The current system only allows a single AI workshop item to be used per team. This is bad for several reasons; firstly, any single group would be hard-pressed to implement good bots for every dota hero. As such, any complete AI would be either very primitive on most heroes or require massive buy-in in terms of combining several AI mods into one super-mod. These groups tend to be somewhat unstable and there's been a lot of issues flying around about the rights to workshop items; I know of multiple people who with custom games have their materials used without permission or license with no effective recourse. This also limits the quality of these AIs; with so much overhead to making a complete AI mod, there's going to be fewer of them, and so less competition to drive progress in the area.
      Suggestion to fix: Split up the AI components in the workshop so that individually excellent pieces can become individually excellent and be used in conjunction with one another.


    I understand that there's an interest in getting something shipped, and simply adding hooks to the existing AI functions is an easy way to do so, but please structure it so that it'll be healthy and versatile in the long term, even if it takes another week.

    I'm very interested to hear your thoughts on the matter, ChrisC.
    At first I thought you were being a little critical of this new API. But, after starting this reply I found myself agreeing with you on some things, so I thought I'd put my 2 cents in. It should be possible to ignore the existing decision system with a convention or additional library.

    You would have to overwrite each bot's Think() function with bot_lina.lua, bot_puck.lua, etc. And (assuming global data is available still haven't gone through all of this yet) It should be possible to create any decision structure you want.

    As you said, the problem is that you would have bots that follow a different conventions. Bringing "bot compatibility" into the mix. And it most definitely encourages people to make simpler bots, which might not be a bad idea right now, but will become a hurdle for the more complex bots. Since the scripts are being ran on the server it could have an impact on server performance to some degree.

    Given a more flexible system in general you will still run into this issue, it would just be a little less "non-standard". It would also be a lot easier for 2 bots using different meanings for "sweep the area" to be stitched together a since both would be using the same "communication" process.

    Overwriting the Think() function of every bot means that you could theoretically interchange bots assuming they all follow the same, or similar, conventions for decision making. But this will inevitably lead to a fractured bot system if a defacto doesn't take a stronghold.

    This said, I think the aim of this API is to create bot teams, not interchangeable bots. Instead of having a bot for every character you have a bot only for the characters that makeup that bot team. I believe that this is the reason that the API is structured in the current manner. In order to facilitate team-first thinking in the bot creation.

  8. #18
    Quote Originally Posted by Xetama View Post
    At first I thought you were being a little critical of this new API. But, after starting this reply I found myself agreeing with you on some things, so I thought I'd put my 2 cents in. It should be possible to ignore the existing decision system with a convention or additional library.

    You would have to overwrite each bot's Think() function with bot_lina.lua, bot_puck.lua, etc. And (assuming global data is available still haven't gone through all of this yet) It should be possible to create any decision structure you want.

    As you said, the problem is that you would have bots that follow a different conventions. Bringing "bot compatibility" into the mix. And it most definitely encourages people to make simpler bots, which might not be a bad idea right now, but will become a hurdle for the more complex bots. Since the scripts are being ran on the server it could have an impact on server performance to some degree.

    Given a more flexible system in general you will still run into this issue, it would just be a little less "non-standard". It would also be a lot easier for 2 bots using different meanings for "sweep the area" to be stitched together a since both would be using the same "communication" process.

    Overwriting the Think() function of every bot means that you could theoretically interchange bots assuming they all follow the same, or similar, conventions for decision making. But this will inevitably lead to a fractured bot system if a defacto doesn't take a stronghold.

    This said, I think the aim of this API is to create bot teams, not interchangeable bots. Instead of having a bot for every character you have a bot only for the characters that makeup that bot team. I believe that this is the reason that the API is structured in the current manner. In order to facilitate team-first thinking in the bot creation.
    I'm going to address your points in approximately the reverse order of that in which you listed them, simply because that allows for a slightly cleaner structure here:

    While I certainly see why it would appear that the API is intentionally structured to facilitate team-first thinking, looking deeper shows that that is at most a side effect of the design of the pre-existing framework; the bot API that is being offered in this change is essentially just hooks into the existing bot infrastructure in many places. This is evident by looking back at old builds of the game and going through the disassembly/AI debug commands/etc, as was done back in the pre-modding-api days, and taking a look at the bot API there.

    Your point on bot teams is an interesting one; indeed, if the bots are allowed to choose a specific set of 5 heroes immediately, then that is more viable for a single group to produce with high quality. However, given that drafting is a good part of dota (in several modes), and playing against AIs is extremely useful in a large number of cases, such as training and the like, it's extremely desirable to have a wide range of AIs available, even if that means slightly weaker ties between each AI. This is why I added an additional level of tactical AI in my suggestion earlier; there's a weird middle tier between overall strategic direction and hero-specific goal-oriented decision-making where some decisions should be made in order to efficiently and effectively work together.

    I agree with your points about the compatibility of bots using different think functions, and the ability to simply override every bot's think function and implement a custom api between the tiers. With the API as it currently stands, I foresee any serious attempt at making good AIs for dota going this route. However, this approach brings up further issues; since this is already possible using the existing custom games API, then valve's new custom bot API is adding literally nothing (other than a flood-fill implementation for loosely figuring out potential hero locations, and automatically filtering data by vision, which can easily be done with a custom bot framework in a custom games lua). With advanced bots, it's adding just another API for valve to support. By restructuring it so that it properly leverages the advantages of the workshop, as well as serving as an interface for having bots that each developer actually focuses on in particular, we can get a much better experience for both users and developers.

    I agree with your point that a system built around think() entirely would be more flexible. However, I think that the trade-off of standardization is worth taking in the generality it offers. The current bots don't properly handle the new shrines; there's no bot mode (in the small set the system supports) that would direct the bot to attempt to destroy a shrine. By going with a more general approach, these changes wouldn't have to be made in the individual bots; they'd just have to be made on the strategic and tactical levels by defining a target and some value to destroying it. This means that if valve were to decide in 7.03 to add a second roshan, changes to strategic and tactical AIs would allow _almost every single hero AI_ to immediately handle the new target with some degree of competency.

    (This generality further passes into custom games; for example, overthrow may be possible to define on a strategic and tactical level alone, without having to change bot AIs from dota. It's hard to overstate how valuable this could be, especially given the high rate of leavers in custom games and the difficulty in filling lobbies for some of the less-played ones.)

  9. #19
    Basic Member
    Join Date
    May 2016
    Posts
    2
    Quote Originally Posted by penguinwizzard View Post
    I'm going to address your points in approximately the reverse order of that in which you listed them, simply because that allows for a slightly cleaner structure here:

    While I certainly see why it would appear that the API is intentionally structured to facilitate team-first thinking, looking deeper shows that that is at most a side effect of the design of the pre-existing framework; the bot API that is being offered in this change is essentially just hooks into the existing bot infrastructure in many places. This is evident by looking back at old builds of the game and going through the disassembly/AI debug commands/etc, as was done back in the pre-modding-api days, and taking a look at the bot API there.

    Your point on bot teams is an interesting one; indeed, if the bots are allowed to choose a specific set of 5 heroes immediately, then that is more viable for a single group to produce with high quality. However, given that drafting is a good part of dota (in several modes), and playing against AIs is extremely useful in a large number of cases, such as training and the like, it's extremely desirable to have a wide range of AIs available, even if that means slightly weaker ties between each AI. This is why I added an additional level of tactical AI in my suggestion earlier; there's a weird middle tier between overall strategic direction and hero-specific goal-oriented decision-making where some decisions should be made in order to efficiently and effectively work together.

    I agree with your points about the compatibility of bots using different think functions, and the ability to simply override every bot's think function and implement a custom api between the tiers. With the API as it currently stands, I foresee any serious attempt at making good AIs for dota going this route. However, this approach brings up further issues; since this is already possible using the existing custom games API, then valve's new custom bot API is adding literally nothing (other than a flood-fill implementation for loosely figuring out potential hero locations, and automatically filtering data by vision, which can easily be done with a custom bot framework in a custom games lua). With advanced bots, it's adding just another API for valve to support. By restructuring it so that it properly leverages the advantages of the workshop, as well as serving as an interface for having bots that each developer actually focuses on in particular, we can get a much better experience for both users and developers.

    I agree with your point that a system built around think() entirely would be more flexible. However, I think that the trade-off of standardization is worth taking in the generality it offers. The current bots don't properly handle the new shrines; there's no bot mode (in the small set the system supports) that would direct the bot to attempt to destroy a shrine. By going with a more general approach, these changes wouldn't have to be made in the individual bots; they'd just have to be made on the strategic and tactical levels by defining a target and some value to destroying it. This means that if valve were to decide in 7.03 to add a second roshan, changes to strategic and tactical AIs would allow _almost every single hero AI_ to immediately handle the new target with some degree of competency.

    (This generality further passes into custom games; for example, overthrow may be possible to define on a strategic and tactical level alone, without having to change bot AIs from dota. It's hard to overstate how valuable this could be, especially given the high rate of leavers in custom games and the difficulty in filling lobbies for some of the less-played ones.)
    I imagined that you would need to implement more than 5 in any given "team" to accommodate for drafting. But you're a convincing fellow; it had not occurred to me about changes in the game. Those could require significant modification in a large set of bots. Potentially causing a "wasteland" of bots that didn't get updated in time, or require too much modification to continue maintaining.

    If the bots were separate in general, it would be a lot easier for a maintainer of a single bot to fix that bot for the new case, or not fix it if their character should ignore it.

    I am still sketchy on tossing out the enum system since you would need some relatively easy way of deriving an equivalent to "laning" without making that process a hurdle, or make it some side effect of the tactic which sounds convoluted to me. But I definitely can see the benefit that that would give to bots in preventing them from being fragile to updates. It would be pretty fantastic to be able to take your bot and put it under different "leadership" aka a different tactical code. I am wondering though what kind of structure could replace the enum system since you'd have to break down the existing enums into something more basic.
    Last edited by Xetama; 12-12-2016 at 02:22 AM. Reason: grammar

  10. #20
    Basic Member
    Join Date
    Sep 2012
    Posts
    11
    It would be nice if we have a C++ side implementation of matrix multiplication, exp and tanh functions. These are really useful for machine learning and neural nets (which I'm sure is needed for our bots to get to a decent level).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •