Zugg Software :: View topic

Beginner Joined: 16 Jan 2010 Posts: 24

Hello -

At the moment, my system does something like this:

When a prompt from the mud appears, it checks if any defenses are missing, and attempts to activate them.

However, to tell it which defenses to handle how, I have them in different places, so it knows what parameters must be met before that defense can be activated. Balance, free, elixir, etc.

I've got this in my balance check, currently:

#if (%ismember( defense, @Auto) and !%ismember( Deffing, @MyFlags)) {#Forall @BalanceDefs {#if (!%ismember( %i, @MyDefs) and %ismember( %i, @DefsOn)) {#exec @DefMap.%i}}

Obviously, 'Forall' tries to send every single defense that's not currently registered as an active def - in MyDefs - at once, which.. it can't do. I'm looking for suggestions how to have it check the whole variable of possible defs against missing defs, without having it send every single one at the same time.

Note, previously, this is how I handled these sort of defs -

#if (%ismember( defense, @Auto) and !%ismember( armor, @MyDefs)) {activate armor}
#if (%ismember( defense, @Auto) and !%ismember( floating, @MyDefs)) {float}

repeat by -every single def- I want kept up, which changes on a character by character basis, or even the needs of my character at a specific point - this method -functions- but it's not at all fluid. I want to be able to add/remove things from the 'DefsOn' variable to tell it what to keep up or ignore from the available defs in the applicable defense type variable.

Thanks for any input.

Posted: Mon Nov 12, 2012 11:47 pm

well seeing as almost everything tests for %ismember( defense, @Auto), why not nest the#IFs to a degree?

#IF (%ismember( defense, @Auto)) {
#IF (!%ismember( armor, @MyDefs)) {activate armor}
#IF (!%ismember( floating, @MyDefs)) {float}
}

and so on, it probably won't speed things up too much (though it might) but it will be much easier to read

you could further simplify it by making a dbVar of powers to test for, and their activators

#ADDKEY defenseCheck.charName {armor=activate armor|floating=float}

and then the previous if could look something more like...

#IF (%ismember( defense, @Auto)) {#FORALL %dbkeys(@defenseCheck.%char) {#IF (!%ismember( %i, @MyDefs)) {#SEND @defenseCheck.%char.%i}}}

or you can add the various activaters to another stringlist.., and assuming you have the various success messages in another list you could do something like...

#TR {{@successfullDefenseActivated}} {#IF (@defensesNeeded) {#SEND %pop(defensesNeeded)}}

Beginner Joined: 16 Jan 2010 Posts: 24

Sorcerer Joined: 15 Apr 2011 Posts: 809

If I understand correctly, your system works, you just need a delay between sending each defense, instead of sending them all at once? That's easily accomplished by adding a #wait x (where x is a number of milliseconds) after your #exec.

Posted: Tue Nov 13, 2012 12:28 am

If you want optional defenses... i would suggest a button setup to toggle off each specific defense as needed for the current spellup

Beginner Joined: 16 Jan 2010 Posts: 24

I've got an alias that'll add whatever I want to the keepup variable. I don't need a button.

My issue is that if I add more than one def to that variable that's not active, it sends all of them at once.

I'm not sure how I could use #wait here to insert a delay between the sending of activation commands, given how forall works.

Posted: Tue Nov 13, 2012 12:45 am

well, how long does the longest defense take to activate? use that time in miliseconds

#WHILE (@defensesNeeded) {#WAIT 60000;#SEND %pop(defensesNeeded)}

that will wait a minute between each defense attempt

Beginner Joined: 16 Jan 2010 Posts: 24

Wouldn't that sort of timer stop other things from happening while it was active?

These defenses would be added / removed during combat - when my whole system needs to be firing on all cylinders.

Posted: Tue Nov 13, 2012 1:25 am

it did in zMUD, it has been fixed to work as expected in CMUD
essentially it creates its own #THREAD to run in

Sorcerer Joined: 15 Apr 2011 Posts: 809

Beginner Joined: 16 Jan 2010 Posts: 24

That wouldn't stop it from sending all six possible defs at once, the first time around. It'd just wait a little before sending the next five. At least, I don't think it would.

I found my answer here.

This is what I've ended up with:

Sorcerer Joined: 15 Apr 2011 Posts: 809

Adding the wait absolutely would put a delay between each one, since the wait runs every time you loop through the forall. This simple example shows that: