Page 3 of 3 FirstFirst 1 2 3
Results 21 to 28 of 28

Thread: February 23 Bot Update

  1. #21
    Basic Member
    Join Date
    Dec 2016
    Posts
    733
    Quote Originally Posted by ChrisC View Post
    Hm, yeah. I'll ship the initial change (a given unit gets either a MinionThink or a Think but not both), but will need to think about if we need to further divide it up at the API level.
    Perhaps separating movable and non-movable minions could be done as well to special case mines, traps, (and maybe Shadow Shaman's wards)

  2. #22
    Basic Member
    Join Date
    Mar 2012
    Posts
    2,022
    Quote Originally Posted by nostrademous View Post
    Perhaps it would be best to separate the types with specific definition of what is what and then have a:
    * MinionThink()
    * IllusionThink()
    * CloneThink() <-- made this up to tackle Arc Warden and perhaps Meepo clones
    This is so self-explanatory, it might be a helluva lot easier for everyone, including newbies to manage. I'd deffo classify Meepo under CloneThink() (this might actually simplify code for people in some respects if they'd prefer to keep the Meepo "hero" laning but manage each clone separately)

    Normally VS and WK would surely be heroes (so Think() ) for both the real heroes and their "ghosts". However, I'd classify them the same as Arc Warden's double, but that is just my opinion
    Explanations on the normal, high and very high brackets in replays: here, here & here
    Why maphacks won't work in D2: here

  3. #23
    Basic Member
    Join Date
    May 2014
    Posts
    270
    Quote Originally Posted by nostrademous View Post
    Perhaps separating movable and non-movable minions could be done as well to special case mines, traps, (and maybe Shadow Shaman's wards)
    Agreed. When I tried to implement earth spirit, his stone remnant always moving very slowly but surely to him. It's so creepy

  4. #24
    Basic Member
    Join Date
    Nov 2015
    Posts
    108
    Quote Originally Posted by nostrademous View Post
    * CloneThink() <-- made this up to tackle Arc Warden and perhaps Meepo clones
    Please God no. My initial feeling is that this would cause so many more problems than it could solve. I cant even imagine having to duplicate all my code in a new spot for Meepo to make his clones work. Arc warden same idea.

    Now don't get me wrong, there are issues currently with hero clones being full hero copies; clones buying in separate is possible, trying to purchase items on clones can cause issues, meepo doesn't get items on clones except boots which gets confusing (but also can be used to figure out who Meepo Prime is in a pinch) and I'm sure many more. However I fixed most of these with a few lines of code but having a separate CloneThink() for heroes like Meepo and Arc Warden, I can't think of an easy way to do this that wouldn't force you to maintain two separate copies of your entire code base.

    Quote Originally Posted by The Nomad View Post
    I'd deffo classify Meepo under CloneThink() (this might actually simplify code for people in some respects if they'd prefer to keep the Meepo "hero" laning but manage each clone separately)
    It may make that one case easier, but to do anything else you'll have to track clones separately anyway. What if Meepo Prime is low on health and you want to fill the lane with clone 1 while 2,3,4 jungle? Or what if you want to lane with 1 clone so Meepo Prime and other clones can jungle to use Primes Shield and Iron Talon? In any other case but the one you mentioned having the clones separate actually makes it harder to use Meepo as a fluid hero.

    Of course this is all just my opinion, but I've been writing Meepo most of my time since the API released.
    Last edited by ironmano; 02-28-2017 at 04:15 PM.

  5. #25
    Basic Member
    Join Date
    Dec 2016
    Posts
    733
    Quote Originally Posted by ironmano View Post
    Please God no. My initial feeling is that this would cause so many more problems than it could solve. I cant even imagine having to duplicate all my code in a new spot for Meepo to make his clones work. Arc warden same idea.
    But you can just eliminate this by:
    Code:
    function myMeepoLogic()
        blah blah blah...
    end
    
    function Think()
        myMeepoLogic()
    end
    
    function CloneThink()
        myMeepoLogic()
    end
    I mean that's a simple solution to your fears. If you further functionalize your Meepo logic you could easily then have item-usage that only gets called in the main Meepo's think (like using BoTs), but not in the clones.

    I understand your trepidation, but I think there are easy solutions that will alleviate them.

  6. #26
    Basic Member
    Join Date
    Nov 2015
    Posts
    108
    Quote Originally Posted by nostrademous View Post
    But you can just eliminate this by:
    Code:
    function myMeepoLogic()
        blah blah blah...
    end
    
    function Think()
        myMeepoLogic()
    end
    
    function CloneThink()
        myMeepoLogic()
    end
    But with Mode-Overrides this is not that simple. I don't simply have a Think(), I have functions all over the place in all different modes of generic and hero specific files that the game calls for me. With CloneThink() it would be more work for me to go through and add module calls to every single built in function the game calls for the clone think then it would be for me to set GetBot().IsClone on spawn and just use
    Code:
    if GetBot().IsClone then return end
    in the spots I don't want clones to access, which right now is just Buyback and Item Purchasing.

    I guess I just don't see a benefit to CloneThink() after writing a Clone hero. Even in total control, I just can't see the benefit here.

  7. #27
    Basic Member
    Join Date
    Dec 2016
    Posts
    733
    Well I was thinking Valve could protect us from ourselves in a way by preventing UseAbility actions from being executed by illusions for example by performing an assert/check in IllusionThink() against any Action_*() that is of type ABILITY_USE for example.

    I hear what you are saying though, but remember we all benefit of more people have an easier time getting into botting.

  8. #28
    Basic Member
    Join Date
    Nov 2015
    Posts
    108
    I totally agree that we all benefit from easier entry to bot design. I do however think it's a false statement to say that CloneThink() makes it easier to get into Meepo or Arc Warden. That being said, right now there is a definite barrier to entry in that there is no explanation of what needs to be done to successfully control the character and how they work in general. What we really need is better documentation and the possible cheats to be removed.

    Thinking of Meepo as a hero with clones is just not going to help you, there are X otherwise identical Meepo's in the game depending on level/scepter and if you write a Meepo and block buyback and item purchases on the clones (this may very well not matter anymore but it did early on) you are done with all of them. This of course simplified but there is no difference between a Meepo Prime and clones except item purchase and carry (and buying back on a clone is cheating and is one of those things that Valve needs to fix like Monkey King Ult walking around using abilities). If you want Meepo to start to using each individual Meepo acting on their own then you are advanced enough to choose how to do it. It is so trivial to keep track of which Meepo is which that forcing you to control the clones in a different way than the prime (IMO) adds an additional complexity rather than removing it. This may not be entirely true for a total control and I can't answer that as I am not taking that path, but from my point of view I see the exact same debate.

    For Arc Warden i foresee a similar problem but with the added puzzle of limited lifespan and no death consequence. I see more of an argument for this hero to have a CloneThink() but I don't feel adding it only for this hero is a good thing and also don't feel it to be necessary just adding complexity to the system without gaining any benefit.

    What I would like to see as opposed to giving specific heroes special methods to deal with them (which to me is an additional barrier to entry) is better examples and documentation. Maybe I'll write a bare bones clone hero example and guide once I get my code fixed from my current bug issue if nothing changes between now and then. I don't know how much it would really help people but if it seems like there is any interest I'll get on it or Valve could

    Edit: I also see Valve 'protecting us' from ourselves by blocking units from performing certain actions as something that should be separate from giving us specific API calls. The current method of console errors is great and I'd rather get an error trying to cast an invalid action then have a whole new API call for that unit (where I suspect I would still get an error for trying that same action)
    Last edited by ironmano; 02-28-2017 at 11:48 PM.

Posting Permissions

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