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

API Requests

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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?

    Comment


    • #17
      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.

      Comment


      • #18
        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.)

        Comment


        • #19
          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, 02:22 AM. Reason: grammar

          Comment


          • #20
            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).

            Comment


            • #21
              Originally posted by penguinwizzard View Post
              [*]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.
              I came to ask for something similar but I was imagining a very simple API for it. Simply allows bots (and the team commander AI) to exchange arbitrary messages.

              SendMessage(msg:string, optional bot_index:int);
              ReceiveMessage();


              Essentially each bot would get a queue of incoming messages and can then read messages from their queue (including the team commander AI as conceptually bot number 6). With this structure you can do any kind of team orders you want, or bots can communicate directly with one another. You can even extend this to allow the game itself send messages to bots, so custom games could inform bots about certain events (and if the bot doesn't understand a message it can just ignore it).

              Comment


              • #22
                One note: it's entirely plausible and probable that we'll need to add more modes. Attacking shrines is a good example of something that probably needs to be added.

                Comment


                • #23
                  Originally posted by Delusional Logic View Post
                  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.
                  Absolutely. The reason I mentioned it here is, at this point I'm not sure if I have the tools to do it on my own. i.e. is there a method that lets you target ground?

                  Also, related question (also asked in a separate thread though) are there any sort of official docs of the current API?

                  Comment


                  • #24
                    Me bots need to be able to chat. How else are they going to spam "???" after each kill?

                    Comment


                    • #25
                      Sending chat messages, chat wheel messages and playing hero voice lines.

                      Comment


                      • #26
                        Originally posted by ChrisC View Post
                        One note: it's entirely plausible and probable that we'll need to add more modes. Attacking shrines is a good example of something that probably needs to be added.
                        This is unfortunately one of the reasons that any serious attempt will eschew the existing structure completely though; having to rely on valve to update or extend api calls is a large part of the current pain in the custom game dev experience. There's a good number of people who compare sm.js favorably to the current modding system simply because there was a modicum of responsiveness in terms of getting new api calls implemented. By going more general with some aspects of the api, you can avoid large parts of this reliance and make something that actually has lower maintenance burden in the long run.


                        Originally posted by trevorflux2 View Post
                        Also, related question (also asked in a separate thread though) are there any sort of official docs of the current API?
                        Yes, at https://developer.valvesoftware.com/..._Bot_Scripting.

                        Comment


                        • #27
                          Sleeps and waits should be forbidden. Instead you must count how many time have happen since the CastAbility tick, and if it is enough (50) then trigger Stop.

                          Comment


                          • #28
                            Is there a API function to chat to allies/enemies? Or to play audio?

                            Comment


                            • #29
                              How about an API function to choose a talent for a bot's hero? Not sure if this exists already (Didn't see one in the documentation).

                              Comment


                              • #30
                                This is probably a very large request, but it would be great to be able to query the active and passive effects (and cooldowns etc) of abilities and items. Currently, I'm looking at creating a big lua table containing all of the info from npc_abilities.txt and items.txt, but these are difficult to use (it seems that the ability effects are hardcoded as passive or active and even some of those are inconsistent (e.g. 'bonus_movement_speed' is passive on all items, apart from smoke)). It would be great to be able to query allied or enemy heroes, look at their current builds, then run calculations to figure out how much MR/armor/etc the bot should be aiming for, and then query items to figure out the most efficient way to do it. The added benefit of having this in the API instead of using the npc files is that it would always represent the current balance of the game meaning the bots wouldn't need to be updated constantly.

                                Comment

                                Working...
                                X