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

  • Originally posted by EriKKo View Post
    1. Having a function that gives the current point in the attack animation for a unit. This would be useful both for your own hero (to know when to animation cancel without trying to keep track of the time yourself), as well as for opponents (to be able to see when the enemy hero goes for a lasthit). Could return nil if the unit is not currently attacking.
    Attack based function were added in the Dec 22 update. In the thread they even discuss how it's for precision timing like last hits. See if this is what you're looking for. You'd probably able to use a combination of them to get what you're looking for otherwise.

    Comment


    • Originally posted by Cornbane View Post
      Attack based function were added in the Dec 22 update. In the thread they even discuss how it's for precision timing like last hits. See if this is what you're looking for. You'd probably able to use a combination of them to get what you're looking for otherwise.
      GetAttackPoint() returns a fixed value, i.e. the point in a unit's animation where the projectile is released (it returns the value in the "Attack Point" column in this table http://dota2.gamepedia.com/Attack_animation). I'm now looking for something like GetTimeSinceAttackAnimationStart(), that would tell the bot how far into its attack animation a unit is. Right now I'm trying to keep track of this for my bot, but it's not entirely reliable since you have to take into consideration things like turn rate. Also, as it is now there is no way to see when an enemy starts their attack animation, which is pretty important for contesting lasthits in lane.

      Comment


      • Do we have an API for Shrines?

        Comment


        • I'm looking to get a function that will return a table of handles to visible heroes through the map.

          Basically a sibling to GetNearbyHeroes(). While that function does its job for nearby situations, I keep getting a repeating warning in the console if I set the radius to 2000 or above. And it's also labeled for "nearby" so I figure a new one for longer distances would be more suitable. Like GetVisibleHeroes( bool Enemy ).

          This is to attach things like :GetLocation(), emulating keeping an eye on the minimap. Or for an over-watching Invoker or Ancient Apparition looking to give from long distance help. Or to just activate Roam mode in general if the activating hero sees an enemy hero via ward in their jungle at low HP. And so on. Things that a single player/bot can make conscious decisions on that don't need team communication or, in scripting case, passing variables all over the place.
          There are situations where you may want to target a seen hero but that hero is not in position to get a handle put on it through other means.

          Comment


          • The new patch is great, but there are far more important things to fix:
            - An API for getting buildings other than racks or tower (shrine, ANCIENT(!), etc). I'm not sure why people aren't complaining about this more.
            - Courier (well you know the issues)

            Workshop:
            - The sorting is still not there (SUPER annoying, specially since it takes 5 minutes to fix it and people are abusing the fact that it sorts alphabetically).
            - A simple "About" page. (for now it doesn't have to be as fancy as the custom games workshop, but still a place for a description longer than 3 lines is essential).

            Comment


            • Originally posted by Cornbane View Post
              I'm looking to get a function that will return a table of handles to visible heroes through the map.

              Basically a sibling to GetNearbyHeroes(). While that function does its job for nearby situations, I keep getting a repeating warning in the console if I set the radius to 2000 or above. And it's also labeled for "nearby" so I figure a new one for longer distances would be more suitable. Like GetVisibleHeroes( bool Enemy ).

              This is to attach things like :GetLocation(), emulating keeping an eye on the minimap. Or for an over-watching Invoker or Ancient Apparition looking to give from long distance help. Or to just activate Roam mode in general if the activating hero sees an enemy hero via ward in their jungle at low HP. And so on. Things that a single player/bot can make conscious decisions on that don't need team communication or, in scripting case, passing variables all over the place.
              There are situations where you may want to target a seen hero but that hero is not in position to get a handle put on it through other means.
              That already exists. Check code below. If health or mana is -1 that means you are getting info bot the enemy hero is not visible (location also is <0, 0> in that case). If "ANY" of your allies see an enemy hero the function will return real values for health, mana, location, etc.

              Code:
              	for p = 1, 5, 1 do
              		local tDelta = RealTime() - X.Enemies[p].last_seen;
              		-- throttle our update to once every 1 second for each enemy
              		if tDelta >= 1.0 then
              			local enemy = GetTeamMember(utils.GetOtherTeam(), p);
              			if ( enemy ~= nil and enemy:GetHealth() ~= -1 ) then
              				X.Enemies[p].obj = enemy;
              				X.Enemies[p].last_seen = RealTime();
              			end
              		end
              	end

              Comment


              • Originally posted by nostrademous View Post
                If "ANY" of your allies see an enemy hero the function will return real values for health, mana, location, etc.
                but what if a ward,tower or a creep have vision of the enemy, will the function return the real info?, if it will not then i agree with Cornbane for having a function that return all visible units globaly.
                EDIT:
                speaking about wards, i dont see too much requests about them(idk how the actual api treat them) so here is some requests about wards:
                -a function that return nearby wards and visible enemy wards.
                -a function to cast abilities on wards (tango,qblade,iron talon).
                Last edited by DzeeRay; 01-09-2017, 09:51 PM.

                Comment


                • Originally posted by DzeeRay View Post
                  but what if a ward,tower or a creep have vision of the enemy, will the function return the real info?, if it will not then i agree with Cornbane for having a function that return all visible units globaly.
                  Or the radar, illusions, Sacred Arrow, Ice Blast, Sun Strike, Rocket Flare, Eyes In The Forest, Thirst, etc.
                  I also think that with GetNearbyHeroes() already in place another function on the large scale is a reasonable option even if only for consistency. It will likely be a lot easier for newbies to use as well. Not to mention reduces the need to use global space, something I'm not very fond of using. That's a me thing.

                  I do appreciate your input though, nostrademous.

                  Originally posted by DzeeRay View Post
                  speaking about wards, i dont see too much requests about them(idk how the actual api treat them) so here is some requests about wards:
                  -a function that return nearby wards and visible enemy wards.
                  -a function to cast abilities on wards (tango,qblade,iron talon).
                  I've been wondering about that. I'm not at the point of having my bots de-ward and assumed there was a way to get handles on them. Guess not. So I'm in favor of this.
                  Last edited by Cornbane; 01-09-2017, 10:04 PM.

                  Comment


                  • Originally posted by DzeeRay View Post
                    but what if a ward,tower or a creep have vision of the enemy, will the function return the real info?, if it will not then i agree with Cornbane for having a function that return all visible units globaly.
                    EDIT:
                    speaking about wards, i dont see too much requests about them(idk how the actual api treat them) so here is some requests about wards:
                    -a function that return nearby wards and visible enemy wards.
                    -a function to cast abilities on wards (tango,qblade,iron talon).
                    my testing shows that tower and allied creep vision properly updates the values in that case too. Haven't had a chance to test ward vision or vision provided by flying projectiles like Mirana arrow yet, but basically I assume that it will.

                    Comment


                    • Have been holding off on putting this in the request list, because other things have been more urgent and I imagine these two will take a significant amount of work. But I think the time might be right to ask for them:

                      1. Can we get better functions for handling summons & sub-units? Right now it appears the only way we can control them is with a generic Think(), and that doesn't work for all of them (e.g. Warlock's golem calls Think(), Beastmaster's summons do not). I think ideally we'd have actual functions we can call from within a bot script (that'll give us behavior that looks more human), but a good-enough shortcut would just be a way to override a minion's Think() without having to disable existing AI entirely.

                      2. Can we get a separate mode for leveling up? That would give us a way to change bot skill builds (including adding flexibility) without overriding the existing AI entirely.

                      Comment


                      • We have the Action_Buyback() and Unit-Scoped:HasBuyback(), but how about Unit-Scoped:BuybackCost() <- returns current gold value needed to be able to buyback, and Unit-Scoped:BuybackCooldown() <- returns 0 if buyback timer is clear or amount of seconds left till buyback is available.

                        Comment


                        • Originally posted by somanyrobots View Post
                          2. Can we get a separate mode for leveling up? That would give us a way to change bot skill builds (including adding flexibility) without overriding the existing AI entirely.
                          Would an additional think function alongside AbilityUsageThink() be sufficient? Something like AbilityLevelUpThink(), which, if implemented, is responsible for leveling up abilities rather than the base AI? I'm hesitant to add a new mode for something as instantaneous as leveling up -- I tend to think of modes as more persistent than that.

                          Comment


                          • Originally posted by ChrisC View Post
                            Would an additional think function alongside AbilityUsageThink() be sufficient? Something like AbilityLevelUpThink(), which, if implemented, is responsible for leveling up abilities rather than the base AI? I'm hesitant to add a new mode for something as instantaneous as leveling up -- I tend to think of modes as more persistent than that.
                            I'd be fine with that myself. Actually that seems like a much more suitable implementation.

                            Comment


                            • I've decided that this isn't a high priority feature for a few reasons. If it's still in the works then it's all good, but I'm not desperate for it.

                              This request is an alternative to a previous request I made that I believe is simpler and easier to implement.

                              My main goal was to try and allow the use of modes and team level thinking while using the single bot_<heroname>.lua files. After some thinking and local testing, I believe my previous suggestion is not the right way to go about it, and mostly unnecessary if fully taking over most of the bots.

                              After tampering around with the team based desire gets ( such as GetPushLaneDesire(), GetFarmLaneDesire(), etc.) I realized you can still do team-level thinking despite what the Complete Takeover section of the wiki says. You just have to read the desires and have your bot respond accordingly. Though, this is probably not news to some of you.

                              So I got thinking that maybe something similar could be done on the Unit-Scoped level for heroes. Such as npcBot:SetModeDesire( nMode, fDesire) to set the active mode based on which one has the highest desire.

                              This will allow the current bot_<heroname>.lua to stay as it is and allow the current methods of creating custom modes to be transitioned over to be able to pass/receive mode information to/from the server/host so that the debugging tools that involve modes will still be of some use. The intention is not to have the default bot scripts running in the full takeover files, but to just have the modes be flipped on and off so they can be used with custom scripts and so that there is an easy/quick visual bug indicator.
                              There are already Bot Mode constants that can be used to send and receive. So after the mode desires have been set we can make use of GetActiveMode() and GetActiveModeDesire() to trigger IFs and functions to emulate the specific modes being active.
                              Last edited by Cornbane; 01-30-2017, 06:21 PM.

                              Comment


                              • Originally posted by ChrisC View Post
                                Would an additional think function alongside AbilityUsageThink() be sufficient? Something like AbilityLevelUpThink(), which, if implemented, is responsible for leveling up abilities rather than the base AI? I'm hesitant to add a new mode for something as instantaneous as leveling up -- I tend to think of modes as more persistent than that.
                                Agree with Cornbane - that sounds excellent, and also easier.

                                Comment

                                Working...
                                X