Skip to content

Auto razing using server side attack queues

I wanted to run some ideas about how I'm going to implement automatic razing using eq/bal queues.  

Let's assume I have all the triggers set up and correct.  If I was just sending queued commands on balance trigger, I'd check if any of my razing variables are sent to on and if they were, I'd send my razing command.  Otherwise, I'd send my regular command.

This is a little more complicated if I actually want to utilize serverside queueing, because I want to be able to handle things like defenses being razed/removed before I regain balance.  

I figure the general process is something like this.  I'll have a variable called queued_command.
Whenever I do an offensive macro, I QUEUE EQBAL the action and also store it in queued_command.
If I see a razeable defense going up, I QUEUE EQBAL the appropriate raze command.
If I see a razeable defense going down, I immediately QUEUE EQBAL a new raze command.  If the target has no more razeable defenses, I QUEUE EQBAL the stored queued_command.
If I see a balance or eq regained message, if the last command performed was queued_command, I set queued_command to nil, otherwise, if the last command was a raze command, I QUEUE EQBAL queued_command.

Does this seem reasonable?  Is this a total overkill?  Am I missing something?

Feedback appreciated.

Thanks

Comments

  • What I've heard a few people do is QUEUE something that can't be interrupted by things, be it a THINK command or w/e (though that can be affected by stupidity), and then just trigger your attack off of that. It has slight latency between the command going through and your trigger firing, but you're able to 'queue' it without needing to watch for balance messages or spam the command.
    image
  • I think that's almost essentially the same thing as queueing your next action handler off of the balance prompt, to be honest (unless I'm not completely understanding what you're suggesting)
  • IniarIniar Australia
    Overkill.

    On balance and equilibrium, clear your variable.
    When you see a razeable defense go up, and your variable does not contain the word raze, clear queue.
    At t = (4 - average latency) after seeing your target smoke linseed, if your variable does not contains the word raze, clear queue.
    When you see all razeable defences go down, and your variable contains the word raze, clear queue.

    No further coding required.
    wit beyond measure is a Sidhe's greatest treasure
  • So you basically only use the code to clear your non-razing commands and do all the razing manually?

    Is there a reason why you wouldn't auto-queue a raze to save time?
  • IniarIniar Australia
    Nope, I queue what is necessary at the time, but clear the queue when the situation no longer fits:

     raze -> non raze
     non raze -> raze

    The new command gets resent by me manually, whether it's a queue or a vanilla.
    wit beyond measure is a Sidhe's greatest treasure
Sign In or Register to comment.