Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 21

Thread: Interrupting vs Queueing vs Pushing

  1. #11
    Basic Member
    Join Date
    Jun 2013
    Posts
    274
    Quote Originally Posted by ChrisC View Post
    If you did this:

    Action_MoveTo( X )
    ActionPush_UseAbility( A )
    ActionPush_UseAbility( B )

    the bot would execute Ability B, then execute Ability A, then go back to the original Move command.
    Alright, so whenever a new Push is added it takes priority.

    I can dig this entire concept. I see how it would be a lot more tidy when wanting to add actions to the queue.

  2. #12
    Basic Member
    Join Date
    Jun 2013
    Posts
    274
    So based on your example there, if you were to add an ActionQueue_ to it as well, would it fall behind Action_MoveTo in the queue? As in, Action_*'s will only destroy the queue when initially called, otherwise just become another queued action?
    The answer seems simple, but just want to make sure.

  3. #13
    Valve Developer
    Join Date
    Sep 2011
    Posts
    1,704
    Quote Originally Posted by Cornbane View Post
    So based on your example there, if you were to add an ActionQueue_ to it as well, would it fall behind Action_MoveTo in the queue? As in, Action_*'s will only destroy the queue when initially called, otherwise just become another queued action?
    The answer seems simple, but just want to make sure.
    Correct, if you did this:

    Action_MoveTo( X )
    ActionPush_UseAbility( A )
    ActionPush_UseAbility( B )
    ActionQueue_UseAbility( C )

    It would execute Ability B, then execute Ability A, then when the move command reached its destination, it would use ability C. ActionPush_ puts its action at the front of the list of things to do, and ActionQueue_ puts its action at the end of the list of things to do, and Action_ nukes the lists and makes its action the only thing being done.

  4. #14
    Basic Member
    Join Date
    Jun 2013
    Posts
    274
    Perfect. Then yes, I'm liking how this sounds.
    The current method with the true/false function acting like an on/off switch can be a bit of pain in some situations.

    Does this include courier actions? I'm not sure if you've seen my recent post in API Requests.
    Last edited by Cornbane; 02-08-2017 at 11:39 AM.

  5. #15
    Basic Member
    Join Date
    Dec 2016
    Posts
    731
    I'm thinking about this from a global standpoint as my code is adapting to globalized & compartmentalized decision making soon. As in... I have a global function called by "one" bot that makes decision for all bots by manipulating their action queues (this decision making is modular so the work can be spread across the frame time slices of all 5 bots rather than all of it be done by one bot... not sure if that matters though if I'm still under the 16ms time slice allowed per frame at 60 FPS) and the bots in their "Think()" just basically do their queued actions.

    EDIT: So far I don't see any issues with it... and actually it might improve things
    Last edited by nostrademous; 02-08-2017 at 11:45 AM.

  6. #16
    Valve Developer
    Join Date
    Sep 2011
    Posts
    1,704
    One wrinkle is that currently not all the Action_* functions go through the action queue system. So things like using Glyph or swapping items in your backpack happen immediately and have no affect on the action queue. I don't think that's a huge issue (I don't think you'd want to push/queue most of those kinds of actions anyways?), but it's definitely a bit confusing.

  7. #17
    Basic Member
    Join Date
    Jun 2013
    Posts
    274
    Pretty much. So long as those specific Actions don't clear the queue then, yeah, I don't think I'll want to wait to use the glyph on a neigh destroyed Ancient. XD

    So long as there's documentation noting which Actions this applies to it should be fine.

  8. #18
    Basic Member
    Join Date
    Nov 2015
    Posts
    108
    Maybe rename actions like glyph that don't operate that way to something akin to Atomic_Glyph etc.

  9. #19
    Basic Member
    Join Date
    Dec 2016
    Posts
    731
    Any chance you can create a dummy timed function to use for setting up more elaborate action queues?

    For example: I want to run a Eul's -> Lightning Strike Array -> Dragon Slave -> Laguna Blade combo on Lina. Once I Eul's someone I have to wait a certain amount of time before casting LSA to make it hit exactly as the Eul's end (before they can blink for example). I have an instinctual feel for it as a player doing it in game. How do I replicate this (and really the timing) using ActionQueue_*() without a proper timing function?

  10. #20
    Valve Developer
    Join Date
    Sep 2011
    Posts
    1,704
    That's a great suggestion, will do.

Posting Permissions

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