Hi guys,

Some people on vent have started playing around on Windower and slowly discovering all the neat toys PC has access to. One of these powerful tools is Spellcast.

Spellcast is a programming tool. Essentially you are making your own, personal AI that helps you equip your gear during certain instances. If you set it up, you can make spellcast change between your idle gear to your combat gear when you engage a mob. You can make it change to your movement speed boots if certain conditions are met, like earth weather or at night.

Just like the title suggests, this post is merely to serve as a basic tutorial about Spellcast. This is by no means the master tutorial that will make you into a Spellcast veteran overnight. However, I think I'm knowledgeable enough about Spellcast that I'm able to help my LS mates learn about this extremely useful tool. I hope this will at least help people learn the fundamentals about Spellcast and learn to make their own SC.

Before we begin on Spellcast, allow me to explain a bit how Spellcast works.

SPELLCAST FUNDAMENTALS
0.0 HOW IT WORKS

Spellcast, at its (virtual) heart, is an AI you program. For those who are not familiar with programming, this is how most AI works.
As you play FFXI, SC will only check your rules/conditions when you do an action (go from idle to casting, idle to engaged, etc). (Most SC users call this parsing) Since SC only checks after you've done an action, it does not mean that SC will do weird shit without your knowing, like automatically put your NIN boots on when it's night time. Although sometimes I wish it did it, it helps SC and your computer if SC isn't constantly checking your rules.

When you set it up, this can mean many different things. Let's take your character's status as an example.
So let's say you set your Spellcast so that it will change your idle gear to your resting gear. How does SC do this?
It reads your document, taking note of your gear sets, variables and what and how you want SC to deal with them. First it has to determine: are you idling right now? If this is true, it will put in your idle gear.
If the previous statement is false, then it looks for the next true statement. If you're not idling, are you resting? If this true, then it will put in your resting gear.
Let's say you engage a mob, but you haven't set up any rules concerning when you're engaged. SC will treat your character as if it's idling because, as far as the AI knows, there are no rules for the engaged state and therefore does not do anything.

In laymen's terms, SC (and most AI programs) is kind of like a textbook autistic/savant child (please don't hit me): this child is extremely talented and is capable of doing incredible things despite all odds. However you need to teach SC exactly what it needs to do. If you have not taught SC what you want it to do under X Y circumstances, it will treat the X Y circumstances as if it doesn't exist. Why? Simply because you have not taught it what it has to do when this happens.

If your SC document is terrible, does not perform as you want it to, gives you multiple errors – it's not because of the AI. This happens because you didn't write the rules properly. You made the syntax mistake, you forgot to close the tag. It's all on you.

The deeper your understanding of SC is, the better your AI will become. You and the AI kind of feed off each other - as you understand more, your AI gets better. As your AI gets better, you understand more.

I don't mean to intimidate anyone, but I'm saying all the above because it is important to understand this before you start. Your first SC might be this terrible, clumsy document of code but you will learn a lot after you finish your first functional SC. Your first melee SC will be a nice accomplishment of the basics. Your first mage SC will be the hardest, but it will get easier after that point.

0.1 BEFORE GETTING STARTED

Before we get started, there are a few things you'll want to know about spellcast. These are things you can do even before you set up your SC and it will help you in the development of your SC. The first thing you're going to do is a) have Spellcast and b) log into FFXI.

NOTE: When you make your Spellcast file, you should save it as the SC for your job - i.e. a BLU spellcast should be called BLU. If you do this, Spellcast will pick this up and will automatically load the corresponding SC document. Neat, huh? This can get kinda messy if you dualbox two characters with overlapping jobs.


SPELLCAST THROUGH THE CHAT LOG
So the first thing you can play around with is how you access SC through the chat log. In case you didn't know, SC has a short form for otherwise complicated commands. Let's take a spell example.

I'm a SCH and I want to cast Adloquium on GS. Without Spellcast, I would have to type: /ma "Adloquium" Goldensephiroth. If I muck up the spell, the quotations or even GS's name, FFXI will not process this. This is totally lame banana chunks, especially since I don't remember where Adloquium is in my spell list and typing GS's name without any typos frustrates me.

With spellcast, instead of typing out the command prefix (/ma), you can simply type: //adloquium. The // works for all command prefixes: /weaponskill, /jobability, /magic, etc. That takes care of those pesky quotation marks.

The next thing spellcast can do is it recognizes the names of the characters in your selection range. (50') So instead of typing Goldensephiroth, I can type: //adloquium sep. Since SC is so smart, as long as another person doesn't have "sep" it will recognize that I want to cast Adloquium on GS. If there is, it might cast on another person with "sep" and not GS. It will still work on GS as long as I type any part of his name. (ex: //Adloquium Gold, //adloquium Sephi, //adloquium old, etc…) As long as GS is within range, Spellcast will process the short hand as: /ma "Adloquium" Goldensephiroth.

NOTE: You have to be a bit careful with characters with names that are in game names as well. ex: Shockin and Diggs. If you type //cure Shock, SC will think you are trying to cure and cast shock at the same time. If you type //cure dig SC will think you're trying to cast cure and /dig at the same time.

This short hand also applies to tiered spells. In SC's short hand, you can simply type the numerical number instead of the roman numeral. Oh noes, GS is hurt and needs a cure! Instead of typing out /ma "Cure IV" Goldensephiroth (/baarrrffffffffffffffff), I can type it as: //cure4 gold. Again, as long as "gold" is uniquely him and he's in range, I'll cast Cure IV. If he's out of range, I'll simply get the "out of range" message in my chat log.

This also works with complex names like Tachi: Kasha and Blade: Ei. You can type it out as: //tachikasha and //bladeei. All JAs, WS and magic spells will work as long as you spell the name right. (i.e. you can't type //tachikasah and expect Tachi: Kasha.)

EDIT: Upon experimenting and reading, SC actually has an autocorrect function. I've never noticed 'cause either a) never paid attention or b) I always never misspelled my spells so I never noticed. I'm sure if the typo is minor SC will still read it.

This is so great because once you've set up your SC, you will (potentially) never have to make another spontaneous macro again. For example, if I'm messing around on SMN and I suddenly feel like doing a BP I don't normally use (i.e. Tidal Roar), my Tidal Roar is going to blow extreme and nasty chunks. I don't have macros set for it, so I'm going to be doing it in my -Perp gear instead of macroing in my -delay and wearing my SMN Magic gear. With SC, as long as my rules covers all my BPs, I could type //tidalroar and maximize its potential.
This is also great when you're testing out your SC, especially job abilities with long recast timers. Instead of being ability-blocked by your menu you can type it out. If Garuda did Claw but my rules didn't work out, I don't have to wait 48s for the next BP to try out my new rules. By typing //Claw I bypass the menu and SC will treat it as if the command went through. In this case I'd be able to see if SC is putting in all of my Physical BP gear despite the timer being down.

NOTE: In instances like these, you have to be careful about how quickly you open your equipment window. If you open it too quickly, SC won't have time to fully process your gear swabs. It'll look like SC is not macroing in stuff properly, giving you a headache for nothing.


SPELLCAST THROUGH THE WINDOWER CONSOLE
I know, I know, the windower console looks really scary. It isn't really, you just have to understand the basics. Unless you've changed your Windower console button, most people tend to use the Insert button. How is this going to help your make your SC? First you need to be logged in and have spellcast.
Now open up your Windower console. The console acts sort of like the command prompt on Windows, but you can only input commands to manipulate your plugins. (unload and load in particular). In the console, type in "sc reload" (translation: reload Spellcast). What did this do?
This reboots spellcast. That's kinda cool, but…?
Just as the name implies, it "refreshes" SC, enabling it to load newer content from your SC document. This is so convenient because it enables you to test your SC document immediately after you finish typing it. If you type a new rule about your engaged state, you just need to go into the console and type "sc reload" to load your newer SC.

Now that you're equipped with the necessary know-how about Spellcast in FFXI, you can start building your own SC document.


NOTE: Since this is still a work in progress, the contents of the posts are subject to changes.

TABLE OF CONTENTS
1.0 SETTING UP YOUR GEAR SETS
This section teaches you a small intro to programming and how to get all your gear sets set up.

2.0 BASIC RULES
Once your gear sets are in place, you can start telling Spellcast what you want it to do. You'll also learn how to make a rule and what a rule looks like.

3.0 COMPLEXITY OF THE RULES
Now that you have the basics down, you can give Spellcast more complex conditions to follow.

4.0 BASIC VARIABLES
This is when Spellcast starts to get more complicated. You can start setting rules based off of conditions happening in game in real time.

5.1 USER DEFINED VARIABLES (prt. 1)
For mages, this is arguably the hardest part of Spellcast. This, however, allows you to completely personalize your Spellcast to your needs beyond the basic rules.

5.2 USER DEFINED VARIABLES (prt. 2)
More information about user defined variables. This section will include more complex variables, specifically those that are user defined/basic hybrids. It will also include how you can trigger your latent based off of your hp using variables.


REFINING YOUR SPELLCAST
Now that you are well equipped with the basics, here are some other things that will help you refine your SC.

1.0 <ACTION> TAGS
The action tag is another powerful tool you can use in SC. I will explain some of the different <action x> tags and how these can affect your rules.

2.0 SC WRITING TIPS
While I'd placed notes throughout the tutorial, I want to include others "quirks" about SC you might not otherwise know about/run into/thought about. I'll be using my SMN SC as a source of examples.

?.? SPELLCAST AND SPONTANEOUS CHANGES
Congratulations!! You are now equipped with the tools to write your functional SC. However, just because you're in the game doesn't mean you can't make temporary modifications from FFXI!

SPELLCAST FUNDAMENTALS
1.0 SETTING UP YOUR GEAR SETS

(Before you start, make sure to download spellcast. :3 )

So let's begin.

If you go into your plugins folder and into spellcast, you'll find a .xml file called default. If you open it, you're looking at the skeleton of every spellcast you will ever read/copy and paste.

First thing to note about programming: just like in written English, sentences begin with a capital and end with a period. Spellcast speaks in its own code language, except instead of sentences it speaks in tags. In order to start, you must first open a tag then close the tag. All tags have <blah> and finish with </blah>.

You can see this in the default document:

<spellcast> (spellcast tag is open!)
……..
…….
……..
</spellcast> (the spellcast tag is closed!)

This is very important. If you don't close all the tags, your file won't load. Spellcast will be upset and be all, "wtf you didn't close all your tags :(" this will show up as an error in your windower console.

(NOTE: For the remainder of the tutorial I'll be using SC as a short form of Spellcast.)

So the first thing you wanna do is set up your gear sets. This is your idle set, your melee set, your mnd set, nuking set, etc… So let's focus on the <sets ></sets> tag.

In your <sets>, first you have to make a <group>. The <group> tag groups your different sets together into one, neat little package. It's the equivalent of telling SC the Monopoly box has a monopoly board with Monopoly money, the Monopoly player pieces, the plastic green and red houses, etc.

Unless you want to make different groups, you want to make your only group the main group.

<?xml version="1.0" ?>
<spellcast>
	<config AutoLoadXML="true" ></config>
	<variables ></variables>
	<sets>
		<Group name="Main" default="yes">
		
		</group>
	<rules ></rules>
</spellcast>

(Remember to close your tags!!)

The next step is setting up your first set. This is probably your idle gear or your melee gear, whatever you want. To do this, you have to name your set.

<?xml version="1.0" ?>
<spellcast>
	<config AutoLoadXML="true" ></config>
	<variables ></variables>
	<sets>
		<Group name="Main" default="yes">
			<set name="Idle">
			</set>
		</group>
	</sets>
	<rules ></rules>
</spellcast>

(Note that <set> tag is closed with </set>.)

So how does spellcast know you want to wear that Spike earring and that Brutal earring? What about a Bifrost ring and a Genius ring?

The gear tags are as follows:

<set name="Main" default="yes">
	<head></head>
	<neck></neck>
	<range></range>
	<ammo></ammo>
	<head></head>
	<neck></neck>
	<lear></lear>
	<rear></rear>
	<body></body>
	<hands></hands>
	<lring></lring>
	<rring></rring>
	<back></back>
	<waist></waist>
	<legs></legs>
	<feet></feet>
</set>

Let's say you want to equip two of the same rings (Sapphire rings). When you use Windower scripts (basically a dumbed-down version of SC), sometimes it will muck up and try to equip the same ring into both slots, leading to only one Sapphire ring and the other slot unchanged. With SC, there won't be any mistake.

<sets>
	<Group name="Main" default="yes">
		<Set name="Idle">
			<head></head>
			<neck></neck>
			<range></range>
			<ammo></ammo>
			<head></head>
			<neck></neck>
			<lear></lear>
			<rear></rear>
			<body></body>
			<hands></hands>
			<lring></lring>
			<rring></rring>
			<back></back>
			<waist></waist>
			<legs></legs>
			<feet></feet>
		</Set>
	.....
	</group>
</sets>

Let's say you have a two different sets that mostly use the same gear. Instead of retyping it out all out, you can use Baseset. You place this after the set's name.

<?xml version="1.0" ?>
<spellcast>
....
	<sets>
		<Group name="Main" default="yes">
			<set name="Idle">
			</set>
			<set name="Idunno" Baseset="Idle">
			</set>
		</group>
	</sets>
	<rules ></rules>
</spellcast>

This is really good if your gear needs most of the base set's gear, but it can get a little tricky. For melees this is fine, but for mages I'd try to avoid it. Refer to Variables for an explanation.

You are now ready to make your first gear sets! Remember to close your tags and not misspell anything, particularly with the ear slot: while you are equipping an earring, it goes in the LEFT EAR (<lear></lear>) or the RIGHT EAR (<rear></rear>). I make the mistake of writing it as <learring></learring> a lot more than I should. v_v;;;

SPELLCAST FUNDAMENTALS
2.0 BASIC RULES

Congratulations! You've written your first group of gear sets. Looks pretty, doesn't it? Now you're ready to write up some rules.

The rules section of your SC is going to be your meat and potatoes: without the rules, your gear sets are useless. You may have given SC the pieces to play, but it doesn't know what to do with them.

You must, must, MUST understand that without writing the rules, SC, for all its power and awesomeness, cannot find itself out of a cardboard box. Even if it's digital life depended on it. Seriously. It's one dead puppy.

Before you start writing your own rules, first you should learn how to write up a rule.


ANATOMY OF THE RULE
In programming, conditions/rules use the <if> tags. SC is no different. It will only execute an action if it's true (i.e. the conditions are met) Aside from <if>, you can use two other tags. You can use <elseif>: this functions exactly like <if>, but it's more like, "if the previous condition isn't met, then try this." You can also use <else> which functions as, "if all else fails, do this."

Once you've opened an <if> tag, you have to give it the actual rule. In SC, there are a lot is different rules. I won't list them all, but it's best to use this page as part of your SC bible.

Let's start off with a spell.

<rules>
   <if spell="Fire">
   </if>
</rules>

So this is very lovely. You've made a condition: When I cast Fire…. Unfortunately, you haven't told SC what to do when you cast fire. You're going to have to be a bit more specific than that.

When you tell SC to put in gear, there are two key elements you must tell it: What gear set you want it to change to and when you want it to change. This is written as…

<equip when="Time" set="YourSet" ></equip>

NOTE: In your SC document, you can write it in a short form: (without the parenthesis)
<equip when="time" set="YourSet" (/)>

The / in the tag because it doesn't need to go beyond another line. You could still write it as…
<equip when="Time" set="YourSet">
</equip>
… But it isn't really necessary. Plus it will make your SC much longer than it needs to be. For whatever reason the forums prefer writing the whole thing out.

Luckily SC is tailored to FFXI, so the different times you can equip your set are Precast, Midcast and Aftercast. So the above would look like…

<equip when="Midcast" set="NukingSet" ></equip>

So your rule will look like…

<rules>
   <if spell="Fire">
       <equip when="Midcast" set="NukingSet" ></equip>
   </if>
</rules>

If, for whatever reason, you wanted to stay in your nuking set after casting, you don't have to write two lines. You can add Aftercast with the straight line |. You can even put in a haste/fast cast set.

<rules>
   <if spell="Fire">
       <equip when="Precast" set="FastCast" ></equip>
       <equip when="Midcast|Aftercast" set="NukingSet" ></equip>
   </if>
</rules>

You could try this out ingame. When you cast fire, it will switch to your nuking set. OSHIIIIIIIII

Wait, why doesn't it work with Fire IV?

That's because you only told SC to change when you cast Fire (I). What do you mean you wanted it for Fire and above? You didn't tell it. It's just doing what you're telling it to do. God.

Luckily, you don't have to painstakingly write out Fire|FireII|FireIII…. you can use the asterisk * as short form for any spell that starts with Fire, including tier 1 and up.

<rules>
   <if spell="Fire*">
       <equip when="Midcast|Aftercast" set="NukingSet" ></equip>
   </if>
</rules>

If you wanted it to include the -aga spells, you would place the asterisk at the corresponding prefix. In this case, Fir*.

The special thing about the spell rule is that it isn't limited to magical spells. It acts as a generic term for magic, ws and job abilities. So, in the case of a SAM wanting to use his WS gear for all his WS…

<rules>
   <if spell="Tachi:*">
      <equip when="Precast" set="WS" ></equip>
   </if>
</rules>

Or maybe a DNC using an ACC build for their Flourishes/steps…

<rules>
   <if spell="Box*|Quicks*|Violent*|Stutter*|Desperate*">
      <equip when="Precast" set="ACC" ></equip>
   </if>
</rules>

The asterisk is placed after the colon because all GKT ws start as Tachi: (blah). For the DNC, it's much too tiring to type out "(blah)step) after each JA.

You can also make rules of macro-in pieces or you can make a set with that specific macro piece.
Macro-in set:

<rules>
   <if spell="Meditate">
      <equip when="Precast" set="Meditate" ></equip>
   </if>
</rules>

Macro-in rule:

<rules>
   <if spell="Meditate">
      <equip when="Precast">
         <hands>Saotome kote</hands>
      </equip>
   </if>
</rules>

The first way says, "If I use Meditate, equip my Meditate set before I execute the JA (Precast)". The second way says, "If I use Meditate, equip these (Saotome kote) before I use the JA (Precast)".
There are also different ways to write out the equip action. This can be written as…

<if spell="Meditate">
   <action type="equip" when="Precast">
      <hands>Saotome kote</hands>
   </action>
</if>

When writing your tags, the name of your tag is always the first chunk of word(s) without any spaces. Notice how it's </action> and not </action type>. This <action> tag is a bit more flexible, as it can also be used to change variables. This will come up later.

In one of the newer versions of SC, you can now do something called "autoset". This is a kind of rule you can use for changing gear depending on your status (i.e. idle, engaged or resting). Luckily it's very easy to write:

<rules>
   <if spell="autoset">
      <if status="resting">
         <action type="equip" when="resting" set="resting" ></action>
      </if>
      <elseif status="idle">
         <action type="equip" when="Idle|Aftercast" set="Idle" ></action>
      </elseif>
      <else status="Engaged">
          <equip when="engaged|aftercast" set="Battle" ></equip>
      </else>
   </if>
</rules>

Notice how I opened up the rule with the <if> tag. I'm telling SC, "If I'm resting, wear this. If I'm not resting and I'm Idle, wear this. (<elseif>) If i'm not doing the other things and I'm engaged, wear this.(<else>)" It's possible to use the <if> tag for the resting/idle/engaged, however Sc will act a little different. <if> tag tells SC that it must check this condition.

<rules>
   <if spell="autoset">
      <if status="resting">
         <action type="equip" when="resting" set="resting" ></action>
      </if>
      <if status="idle">
         <action type="equip" when="Idle|Aftercast" set="Idle" ></action>
      </if>
      <if status="Engaged">
          <equip when="engaged|aftercast" set="Battle" ></equip>
      </if>
   </if>
</rules>

SC reads this as: "If I'm idle, wear this. If I'm resting, wear this. If I'm engaged, wear this." Notice how all the rules are independent from each other.
Whether you use <if> for everything or follow the <if><elseif><else> style, all your rules MUST start with <if>. You cannot start with <elseif> or <else>.

If you wanted to lock certain pieces of gear, like your main and your sub you write it as…
<(gearslot) lock="t" />
<main lock="t" ></main>
<sub lock="t" ></sub>

<else status="engaged">
   <equip when="engaged|aftercast" set="Battle" ></equip>
   <main lock="t" ></main>
   <sub lock="t" ></sub>
</else>

When you write these under the "engaged" rule, if will tell SC to only lock your main and sub while you're engaged. This gear locking can also apply to different things:

<rules>
   <if buffactive="Sublimation: Activated">
      <action type="equip" when="Aftercast">
         <head lock="t">Scholar's m.board</head>
         <body lock="t">Argute gown</body>
         <rrear lock="t">Savant's earring</rear>
      </action>
   </if>
</rules>

Now you can write your own basic rules! Play around and remember to bookmark that rules page. I still use to it whenever I make any new rules in my SCs.

SPELLCAST FUNDAMENTALS
3.0 THE COMPLEXITY OF RULES

If you're reading this bit, chances are you play a mage job. How do I know this? No melee would need such complex rules and variables to play their job. With the exception of maybe BLU and NIN, most jobs won't be playing around these parts of SC.


"ADVANCED" TAGS
So SC has been pretty cool… being all smart about setting up the condition and doing whatever you wanted it to do. Things get a little trickier when the condition isn't as simple as "If I use (blah).." and more like, "If the day and/or weather is the same as my spell, equip the corresponding elemental obi."

Yeah. Hmmm….

Advanced tags are more unique than the basic rules. These are probably the most technical tags you will be writing in your SC. I will, however, try my best to explain them as simply as possible.

Advanced tags are complex statements checking to see if all your conditions are being met. Simply put, "If I have an apple AND a kiwi, then I will make an awesome fruit salad." This means if you lack the apple AND the kiwi, you won't be making any fruit salad. It doesn't matter if you have the apple OR the kiwi, or if you have a pineapple and/or a pear, you can't make the fruit salad.

More advanced statements are like, "If I have an apple AND a kiwi OR a banana, I'll make an awesome fruit salad." This means you can only make your fruit salad if you have a) an apple AND a kiwi or b) an apple AND a banana. So it doesn't matter if you have the apple and a grape 'cause you need an apple and a kiwi/banana. It won't even matter if you have the kiwi AND the banana if you don't have the apple. Tough luck fruit salad.

Let's write out the first scenario (Apple AND kiwi needed)

<if advanced='"Fruit1"="Apple" AND "Fruit2"="Kiwi"' ></if>

Each rule or condition has to be in quotations marks. The apostrophes act as giant parenthesis/quotation marks. If you didn't have the apostrophes SC would read the. Statement. Like. This. SC would also read it as incorrect syntax.

Here's the second scenario (Apple and Kiwi/Banana)

<if advanced='"Fruit1"="Apple" AND ("fruit2"="Kiwi" OR "fruit3"="Banana")' ></if>

So you can also use parenthesis to group certain conditions together. Awesome, right?


That's the basic jist of the advanced tags, but it also comes along with its own syntax. (huhwhat)
Here's the list from the Windower wiki.
&lt; - less than
&gt; - greater than
&lt;= - less than or equal
&gt;= - greater than or equal
== - exactly equal
= - exactly equal
!= - not equal

NOTE: The difference between == and = seem negligible, but SC will actually complain when you should be using == over = and not perform the action.

Let's take the Sublimation rule from the previous post. What if you wanted SC to lock it immediately after you use Sublimation? As it is, you would have to wait for SC it notice you have the buff (i.e. resting, after you cast a spell, etc). It would be kind of dumb if it were your last buff before making your way to a zone.

So if we try to verbalize what we're trying to do, it would be, "If Sublimation is active OR I've just used Sublimation, lock these three slots."

<rules>
   <if advanced='"buffactive"="Sublimation: Activated" OR "spell"="Sublimation"'>
      <action type="equip" when="Aftercast">
         <head lock="t">Scholar's m.board</head>
         <body lock="t">Argute gown</body>
         <rear lock="t">Savant's earring</rear>
      </action>
   </if>
</rules>

Tadahh! Now SC will make sure they stay on.

Another way to write advanced statements is the use of <if mode>. It's a simpler version of <if advanced>. Unlike the <if advanced> tag, you don't need apostrophes. You just have to state if it's an AND statement or an OR statement.

<rules>
   <if mode="OR" buffactive="Sublimation: Activated" spell="Sublimation">
      <action type="equip" when="Aftercast">
         <head lock="t">Scholar's m.board</head>
         <body lock="t">Argute gown</body>
         <rear lock="t">Savant's earring</rear>
      </action>
   </if>
</rules>

For the AND statement you could also use &amp;&amp; and for the OR statement you could use ||. It's up to you.

Once you start adding complex rules, there's an easy way to add in "side notes". When you write this in your SC document, it will have a faded colour (mine makes it gray). You signify these notes with <!– blah –>

<rules>
<!-- My very first note on SC about Sublimation. -->
   <if mode="OR" buffactive="Sublimation: Activated" spell="Sublimation">
      <action type="equip" when="Aftercast">
         <head lock="t">Scholar's m.board</head>
         <body lock="t">Argute gown</body>
         <rear lock="t">Savant's earring</rear>
      </action>
   </if>
</rules>

SC won't read it as a possible command to do. These are notes you leave for yourself. I use it to specify what the following rules will be doing. This helps me when I want to change some rules and I don't have to hunt for it.

NOTE: You can also use it while you're making your rules. Let's say you found a way to change your hands to Serpentes cuffs during the night, but your rule won't change your serpentes cuffs out when it's day time. SC isn't very fond of incomplete work, so you can use the <!– –> tag to hide the rough work from SC. When you're tweaking, you can hide your current rule and try out new rules instead of having to delete it. Just make sure to open and close the tag appropriately.

SPELLCAST FUNDAMENETALS
4.0 BASIC VARIABLES

With what has been covered so far, you're able to make some complex rules with SC's preset rules. Once you start using variables, it changes your SC from a static SC to a dynamic SC. This is the stuff you need to play with when you have more complex circumstances. This is also the stuff that will let you automatically put on your Twilight cape when the day/weather corresponds with your spell.

Let's begin with baby steps.


BASIC VARIABLES

In SC, there is a list of preset variables that it can check in real time while you're on the game. When you write preset variables in your rules, you always signify it with %(Variable).

So let's take Ice obi as an example.

<if advanced='""'>
   <equip when="midcast">
      <waist lock="t">Hyorin obi</waist>
   </equip>
</if>

So remember to write out what you want your rule to do. You want SC to equip ice obi when the day/weather (Iceday/Ice weather) corresponds with your spell (blizzard).

<if advanced='"%SpellElement"="Ice" AND ("%WeatherElement"="Ice" OR "%DayElement"="Ice")'>
   <equip when="midcast">
      <waist lock="t">Hyorin obi</waist>
   </equip>
</if>

While this rule will work, it's a little repetitive and not written efficiently. Plus you don't want to be repeating this over and over again for all the other obis, do you? This is where the magic of basic variables comes into play: you can make variables interact with each other.

Let's rewrite the above to include all the obis:

<if advanced='""'>
      <!-- <equip when="midcast">
         <waist lock="t">Hyorin obi</waist>
      </equip> -->
</if>

So you want SC to equip the right obi if your spell corresponds with the day/element. "If my spell's element is the same as the day element OR the weather element, equip the corresponding obi."

<if advanced='"%SpellElement"="%DayElement" OR "%SpellElement"="%WeatherElement"'>
<!-- Based on the above rule, you now have to tell it what element corresponds with what obi. -->
   <if Element="Ice">
      <equip when="midcast">
         <waist lock="t">Hyorin obi</waist>
      </equip>
   </if>
</if>

As stated earlier, SC will only execute actions if they are true. If per chance you don't have the ice obi, you shouldn't be wasting SC's time seeing if you have it. You can help SC out in the variable section at the top of the SC document.

ANATOMY OF A VARIABLE
Now there are three kinda of variables: whether the variable is true (1 or 0), setting it to a specific number and setting it to a specific gear.
Like all things in SC, you have to give your variable a name.

<variables>
<var name="Ihas">1</var>
<var name="Idonthas">0</var>
<var name="SpecificDigit">640</var>
<var name="Specificgear">Serpentes sabots</var>
</variables>

Remember to close your tags!


TRUE OR FALSE VARIABLES
For now let's play around with the true/false variable. Let's put the obis aside for now and play with Twilight cape.

<variables>
<var name="TwilightBack">1</var>
<!-- The neat thing about variables is you can give stuff nicknames! -->
</variables>

For twilight cape, it has the exact same rules as the obis. However, you want to tell SC that you have it and to wear it regardless of the element.
Here's what it would look like if you wrote it in your rules:

<if advanced='"Twilightback"="1" AND ("%SpellElement"="%DayElement" OR "%SpellElement"="%WeatherElement")'>
   <action type="equip" when="midcast">
      <back>Twilight cape</back>
   </action>
</if>

So this tells SC to equip twilight cape ONLY IF the TwilightBack variable is true. It doesn't matter if the spell corresponds with the day/weather, it won't put your cape on if the variable is false. If you don't have twilight cape, you can actually just leave this rule alone. It doesn't affect you ingame. However, if you want, you can make it into a side note so SC doesn't have to check it. It's up to you.

However, you can still equip the Twilight cape without making a new rule at all:

<if advanced='"%SpellElement"="%DayElement" OR "%SpellElement"="%WeatherElement"'>
   <action type="equip" when="midcast">
      <back>Twilight cape</back>
   </action>
   <if Element="Ice">
      <equip when="midcast">
         <waist lock="t">Hyorin obi</waist>
      </equip>
   </if>
</if>

SC reads this as, "If the spell element is the same as the day element or the weather element, put my twilight cape on," versus, ""If the spell element is the same as the day element or the weather element is true, then if my spell's element is ice equip Hyorin Obi." Here you are essentially building more conditions upon conditions you've created. Just be careful not to build too many conditions to do one action. It will clutter your SC and it will make it harder for you to change anything.

SPELLCAST FUNDAMENTALS
5.1 USER DEFINED VARIABLES (prt. 1)

So we've covered a lot of SC; how to set up your gear set, how to tell SC what to do. You can even start telling SC to do certain things depending on the conditions in the game itself.

This is the step up from basic variables. In this section, this is where you really start personalizing your SC to your specific needs. This will also be divided into two or three due to the amount of content I need to cover.


USER DEFINED VARIABLES
If SC were a tribe, user defined variables would be the rite of passage for a boy/girl to be recognized as an adult. You'll be able to set certain variables and to change them if the right circumstances arise. This is really good if you don't want to make 128461946148 different sets for different times, but it is a lot more complicated than "If (condition) do (blah)".

Before we start messing these variables with rules, you can make them interact with your gear sets. I'll take my SCH as an example. As a side note, I'm very specific about what I want SC to do with my gear. Of course there are many other ways to do one rule, so please remember that this is not the be-all end-all of SC. Do what works for you, even if the simpler "If (blah) do (blah)" suits you better.

Here is the basic idle set for my SCH:

<group name="Main" default="yes">
   <set name="Idle">
      <main>Terra's staff</main>
      <sub>Raptor strap +1</sub>
      <ammo>Incantor stone</ammo>
      <head>Scholar's M.board</head>
      <neck>Morgana's choker</neck>
      <rear>Insomnia Earring</rear>
      <lear>Gifted earring</lear>
      <body>Argute gown</body>
      <hands>Weald Gages</hands>
      <lring>Ether ring</lring>
      <rring>Bifrost ring</rring>
      <back>Hexerei cape</back>
      <waist>Hierarch Belt</waist>
      <legs>Tatsumaki Sitagoromo</legs>
      <feet>Wood F Ledelsens</feet>
   </set>
.....
</group>

Here are the things I want to do:

1. I want to idle in desert boots if I have Sandstorm or there's earth weather.
2. Regardless of time, I want to wear desert boots if I have Sandstorm up.
3. I want my Serpentes set to change at the appropriate time.
4. I don't want to type out the names of HQ staves.

Let's start with the simplest: renaming the HQ staves.


SPECIFIC GEAR VARIABLE
As mentioned in the previous post, you can give longer gear names nicknames with variables. Let's rename that pesky terra's staff.

<variables>
<var name="Earthstaff">Terra's staff</var>
</variables>

Right now I'm telling SC that whenever I refer to "Earthstaff", ingame it means Terra's staff. In SC, all user defined variables are signified with $(Name).

<variables>
<var name="Earthstaff">Terra's staff</var>
</variables>
<sets>
   <group name="Main" default="yes">
      <set name="Idle">
         <main>$Earthstaff</main>
         <sub>Raptor strap +1</sub>
	 ......
	 <feet>Wood F Ledelsens</feet>
      </set>
.....
   </group>
</sets>

Now ingame, if you have the NQ and HQ, you will always be wearing the HQ staff. Neat, huh? You should do this for the rest of your HQ staves.

Let's tackle #1: putting my desert boots on. In order to start, I have to make my feet into a variable.

<variables>
<var name="Earthstaff">Terra's staff</var>
<var name="Boots">Wood F Ledelsens</var>
</variables>
<sets>
   <group name="Main" default="yes">
      <set name="Idle">
         <main>$Earthstaff</main>
         <sub>Raptor strap +1</sub>
	 ......
	 <feet>$Boots</feet>
      </set>
   </group>
</sets>

Now you may ask, why do I have to do this? Could I not just make a set and gear it in?
Personally, I'm not very fond of making 736174642 sets for all different occasions. While it's simpler, it requires more manual input from me and making SC work even harder. Since I know SC is able to change my gear dynamically, I want to take advantage of that. I also don't have to make SC work any harder (check desert boots… oh but the conditions for serpentes sabots is true, so I have to put that in instead of the desert boots…).

In order to put my desert boots on, I'm going to have to use an "advanced" tag. If I write the rule out, I want it to say, "If I'm affected by Earth weather OR if I'm affected by "Sandstorm" OR if I cast Sandstorm, idle in desert boots." Due to the nature of the rule, I can simplify it to a <if mode> tag.

<rules>
   <if mode="OR" weatherelement="Earth" buffactive="Sandstorm" spell="Sandstorm">
   </if>
</rules>

NOTE: When I use <if mode> tag, I don't need to put in the % prefix for preset variables.
Remember way back in the beginning I mentioned the <action type> tag? Not only can I use it to put gear on, but I can use it to change variables. Here's what I mean:

<rules>
   <if mode="OR" weatherelement="Earth" buffactive="Sandstorm" spell="Sandstorm">
      <action type="var" cmd='set Boots "Desert Boots +1"' ></action>
      <action type="equip" when="aftercast">
	<feet>$Boots</feet>
      </action>
   </if>
</rules>

Don't freak out. You're probably asking, what did I just do there?
With the <action type> tag, I've changed what $Boot refers to. Before I cast Sandstorm, my $Boots variable refers to my Wood F Ledelsens. However, after the conditions are met (i.e. I've just casted Sandstorm on myself), SC knows that $Boots now refers to Desert Boots +1. If you remember back in my idle gear set, my idle feet are $Boots. As long as I have Sandstorm or there's earth weather, I will always idle in Desert Boots +1.
While this is dandy, this poses a problem when I don't have the above conditions anymore. I haven't told SC to change back to my original idle feet.
Here we use the <action type> tag again:

<rules>
   <if mode="OR" weatherelement="Earth" buffactive="Sandstorm" spell="Sandstorm">
      <action type="var" cmd='set Boots "Desert Boots +1"' ></action>
      <action type="equip" when="aftercast">
	<feet>$Boots</feet>
      </action>
   </if>
   <elseif>
      <action type="var" cmd='set Boots "Wood F Ledelsens"' ></action>
   </elseif>
</rules>

Notice when I'm using the <action type> tag to change variables, the cmd looks a lot like the <if advanced> tag. It needs apostrophes for it to be correct. I also don't need to write a specific rule for <elseif> since I'm referring to the previous proposition. (If these conditions aren't met, do this.)

Here is where BaseSet might start to hinder you. Let's say I've based my nuking set on my idle set.

<sets>
   <group name="Main" default="yes">
      <set name="Idle">
         <main>$Earthstaff</main>
         <sub>Raptor strap +1</sub>
	 ......
	 <feet>$Boots</feet>
      </set>
      <set name="Nuking" Baseset="Idle">
	 ....
	 <neck>Feud Pendant</neck>
      </set>
   </group>
</sets>

Notice how my nuking set only specifies some pieces, like the neck. Take note how the <feet> tag is not specified because it is based on the BaseSet.
Ingame, I've casted Sandstorm on myself. So now my $Boots variable is Desert Boots +1. Oh no, I got aggro! So I quickly sleep the mob and start casting Blizzard IV. Since I did not specifically tell SC that I want Wood F Ledelsens as my feet when I cast nukes, I'll be casting in my Desert Boots +1 in. For mages, this is why you should be careful about using BaseSet if you plan on using user defined variables. Due to how intricately connected SC can become, this is the kind of problems you might run into with BaseSet. While this can be easily fixed by telling SC exactly what you want, sometimes you might want to use different gear for a different situation (MATK and MACC balance in particular).

Note: Sometimes a set of rules will work for one person, but after copy/pasting it won't work for you. In this case you have to sweat a little and work a way around it.

Let's tackle #3: The Serpentes set. By doing this I can also tackle #2 so I don't have to use the <elseif> rule. You'll see why in a little.
Let's write out my rule in words. "If I have Wood F Ledelsens OR Desert Boots +1 as my idle feet, change it to Serpentes sabots."
Man this is so awesome. I can simplify it into the <if mode> tag instead of the <if advanced> tag. However, I'm not really comfortable dealing with user defined variables in <if mode> yet, so I'll be using <if advanced>.
I also took the night/day rules from the SC wiki, so you can use the same rule if you want.

<rules>
<!-- Serpentes stuff -->
   <if mode="OR" TimeLT="6.00" TimeGT="17.59">
	<if advanced='"$boots"="Serpentes sabots" OR "$boots"="Desert boots +1"'>
	   <action type="var" cmd='set Boots "Wood F Ledelsens"' ></action>
	</if>
   </if>
   <elseif mode="OR" TimeGT="6.00" TimeLT="17.59">
	<if advanced='"$boots"="Wood F Ledelsens" OR "$boots"="Desert boots +1"'>
	  <action type="var" cmd='set Boots "Serpentes sabots"' ></action>
	</if>
   </elseif>
</rules>

So the rule says if it's night time (before 6:00AM but after 6:00PM) and my $boots is desert boots +1 or serpentes feet, I want it to change back to Wood F Ledelsens. I'm telling SC two things: if it's night time, put my original feet back on, and if it's night time and the conditions for desert boots don't apply, put on my original feet.
If it's day time (after 6:00AM but before 6:00PM) and my $boots is either my Ledelsens or Desert Boots, wear the Serpentes sabots instead. Take note that Desert boots overrides this rule as long as the conditions for Desert boots remains true.

Let's put in my Serpentess cuffs into the mix. Just like my $boots, I have to make my hands into a variable($hands). In this case, I have to put $hands in my idle set.

<rules>
<!-- Serpentes stuff -->
   <if mode="OR" TimeLT="6.00" TimeGT="17.59">
	<if advanced='"$hands"="Weald gages"'>
	   <action type="var" cmd='set hands "Serpentes cuffs"' ></action>
	</if>
	<if advanced='"$boots"="Serpentes sabots" OR "$boots"="Desert boots +1"'>
	   <action type="var" cmd='set Boots "Wood F Ledelsens"' ></action>
	</if>
   </if>
   <elseif mode="OR" TimeGT="6.00" TimeLT="17.59">
	<if advanced='"$boots"="Wood F Ledelsens" OR "$boots"="Desert boots +1"'>
	  <action type="var" cmd='set Boots "Serpentes sabots"' ></action>
	</if>
	<if advanced='"$hands"="Serpentes cuffs"'>
	   <action type="var" cmd='set hands "Weald gages"' ></action>
	</if>
   </elseif>
</rules>

The rules for the cuffs are a lot simpler :) Thank goodness. Since my idle set has $hands in it, I will only wear the Serpentes cuffs when I'm idling. When I'm casting, since I specified my hands, I won't be casting in Serpentes cuffs. With this rule in place, I seamlessly change between my Serpentes hands/feet. All those times I forgot to put them on are a thing of the past. This is part of the power of SC. :)

SPELLCAST FUNDAMENTALS
5.2 USER DEFINED VARIABLES (prt. 2)

So far we've already covered the True/False variable and the Specific Gear swap variable. Before we continue with the Specific Digit variable, I want to go over a special kind of variable.


USER DEFINED/BASIC VARIABLE HYBRID
This is what happens when a %Variable and a $Variable decide to start a family together. How do these even work?? I haven't made any rules with these in my SCs. However, I do understand how these weird things work and I will do my best to explain it.

Let's go back to those obis.

<if advanced='"%SpellElement"="%DayElement" OR "%SpellElement"="%WeatherElement"'>
   <action type="equip" when="midcast">
      <back>Twilight cape</back>
   </action>
   <if Element="Ice">
      <equip when="midcast">
         <waist lock="t">Hyorin obi</waist>
      </equip>
   </if>
</if>

As the rule is now, it works perfectly fine. However, you'll have to type out each rule for each individual obi. Golly geewhiz, that's rather long and tedious and totally not necessary. How can I shorten this?

The first thing you need to do is make variables for your obis. Try to keep the nicknames simple and related to what SC is familiar with. You will see why soon.

<Variables>
   <var name="FireObi">Karin obi</var>
   <var name="IceObi">Hyorin obi</var>
</variables>
...
<rules>
   <if advanced='"%SpellElement"="%DayElement" OR "%SpellElement"="%WeatherElement"'>
      <action type="equip" when="midcast">
         <back>Twilight cape</back>
      </action>
      <!-- if Element="Ice">
         <equip when="midcast">
            <waist lock="t">Hyorin obi</waist>
         </equip>
      </if -->
<!-- notice how I used the pre-existing <> for my side notes -->
   </if>
</rules>

Now you're ready to try these babies out.


USER DEFINED/BASIC VARIABLE BREAK DOWN
When you use these hybrids, you write it as $%(Variable)x. At its core, these $%Variables are actually really simple, but their function is what makes them complex. If we want to make our obis a $%Variable, it will be written as $%SpellElementObi.

<Variables>
   <var name="FireObi">Karin obi</var>
   <var name="IceObi">Hyorin obi</var>
</variables>
...
<rules>
   <if advanced='"%SpellElement"="%DayElement" OR "%SpellElement"="%WeatherElement"'>
      <action type="equip" when="midcast">
         <back>Twilight cape</back>
      </action>
      <action type="equip" when="midcast">
         <waist="t">%$SpellElementObi</waist>
      </action>
      <!-- if Element="Ice">
         <equip when="midcast">
            <waist lock="t">Hyorin obi</waist>
         </equip>
      </if -->
   </if>
</rules>

Let's pretend you cast Fire IV and your conditions for your obis are true. SC reads all preset variables first. In this case, SC will read $(%SpellElement)Obi. This comes back to SC as $(Fire)Obi. Once your variable is simplified to a user defined variable ($FireObi), SC will look in the variable section and equip your Karin obi. The "x" in the template name is going to be part of your custom nicknames. While it's possible to write it as x%Variable, it can get a little messy with blizzard (ice) and aero (wind).

You know what else this works with? Equipping your elemental staves and grips.

<variables>
<!-- Elemental Staves -->
   <var name="FireStaff">Vulcan's staff</var>
   <var name="IceStaff">Varuna's staff +2</var>
<!-- Elemental Grips -->
   <var name="FireGrip">1</var>
   <var name="IceGrip">1</var>
<!-- Elemental obis -->
   <var name="FireObi">Karin obi</var>
   <var name="IceObi">Hyorin obi</var>
</variables>
...
   <group name="Main" default="yes">
      <set name="Nuking">
	 <main>$SpellElementStaff</main>
<!-- Notice how you don't put % symbols in your gear sets. They belong in the rules section. -->
	 .....
      </set>
   </group>
...
<rules>
   <if skill="ElementalMagic">
      <equip when="Midcast">
         <main>$%SpellElementStaff</main>
      </equip>
      <if advanced='"$%SpellElementGrip"=="1"'>
	 <action type="equip" when="midcast">
	    <sub>$%SpellElementGrip</sub>
	 </action>
      </if>
      <if advanced='"%SpellElement"="%DayElement" OR "%SpellElement"="%WeatherElement"'>
         <action type="equip" when="midcast">
            <back>Twilight cape</back>
         </action>
         <action type="equip" when="midcast">
            <waist="t">%$SpellElementObi</waist>
         </action>
      </if>
   </if>
</rules>

Notice how I use <if> for all the different rules. I don't want them to be related to each other: i.e. if I put my rule for my obi as <elseif>, it is assuming that the rule for the elemental grips returns as false. That means if it returns as true, SC won't check my obi rule.

With this new understanding of $%Variable, this suddenly makes the Digit variable considerably easier to deal with… from a dynamic point of view.


SPECIFIC DIGIT VARIABLE
Now, why would you want to use this in the first place? I've personally never used it. However, when I do see this used in other SCs, it's usually for HP latent gear. I'd imagine you can do it with MP if you wish.

Honestly, if you're looking to activate a HP latent, this is probably the most complex way to go. For simpler SCs, I've usually seen, "If I cast cure, put on my HP latent set during Precast and equip my curing set in Midcast." Again, it depends on how specific you want SC to deal with your gear.

NOTE: For this example, I'll be taking values/SC code from Aikar's BLM SC (side note: Aikar is the original developer of Spellcast).

The first thing Aikar does is set up hp values. These values are going to be SC's point of reference for Aikar's HP.

<variables>
   <var name="RDMRingHP">709</var>
   <var name="WHMRingHP">620</var>
   <var name="NINRingHP">620</var>
   <var name="SorcRing">1</var>
</variables>

Now, using a $%Variable, he makes rules about his hp based on his subjob.

<variables>
   <var name="RDMRingHP">709</var>
   <var name="WHMRingHP">620</var>
   <var name="NINRingHP">620</var>
   <Var name="SorcRing">1</var>
</variables>
....
<rules>
   <if advanced='"$SorcRing"=="1"'>
      <if advanced='"$%SubjobRingHP" !="$%SubjobRingHP"'>
         <if advanced='"%HP" &gt; "$%SubjobRingHP"'>
	    <equip when="Precast" set="SorcLatent" ></equip>
	 </if>
      </if>
      <equip when="midcast">
         <lear>Sorcerer's ring</lear>
      </equip>
   </if>
</rules>

If you remember back in 3.0 (Complexity of the Rules), advanced tags have their own vocabulary. != means "not equal to" and &gt; means "greater than". It looks kind of intimidating, but it's easier to understand when you break it down. (Let's pretend he's /WHM with 720HP)

1. Spellcast, I have Sorcerer's ring.
2. In the event that (as /WHM) my HP does not equal 620… (SC reads: 720 is not equal to 620, hence true)
3. … And my current HP is greater than 620…. (SC reads: 720 is greater than 620. This is true.)
4. …. then put my SorcLatent gear on. (SC: ok!)
5. Now equip my Sorcerer's ring. (This will apply whether lines 2 and 3 return as true or false)

The second line needs to be that complex because he's telling SC do something under very specific conditions. If he made a more general rule like, "If my current HP is greater than 620" instead, this would mess his hp up when he's /RDM. Even a HPGT rule would involve setting specific rules for each sub.

His rule is pretty good. Rather than creating a repetitive rule for each of his subs, he has compressed the same rule to apply to his three subs. If he so wished, he could add more subs to his variables and he wouldn't have to touch his rules. Though arguably you could use a <if HPPGT="75"> rule to simplify triggering the latent.

Important lesson:
If you can't tell, I'm a big advocate for making your own SC and avoiding copying and pasting (especially when you're new to SC). While it's easy to modify other's SCs, it's much harder for you to fix them if your modifications don't work. Lots of things go wrong, namely the level of understanding and how intricate the original author's SC is. In this case, there are BLMs who fumble with this rule due to its complexity. So far I've seen most BLMs just scraping it when problems arise. I suspect they would opt for a HPGT or a HPPGT rule.

REFINING YOUR SPELLCAST
1.0 <ACTION> TAGS

By now, you are well-equipped to make your SC functional. The proceedng sections are an optional read and merely here to help you refine your SC.


In the SC tribe, <action> is the chief/leader: that is, making sure variables follow the rules and getting stuff done. In fact, the <action> is so boss that <action> can control the very fabrics of time. Well, ok, not really, but allow me to elaborate.

<Action> has a lot of stuff it can do. (Search for the <action> header) I don't use even half of what it could do, but the ones I use like to use is <midcastdelay> and <aftercastdelay>.

<ACTION> and DELAYS
As the name implies, with <action> you can actually change what precast, midcast and aftercast means to SC.
Let's take my SMN as an example. Before a BP goes off, I have to put on my Delay and the appropriate SMN gear for the BP before it goes off. While the Delay gear isn't a problem, I want to be absolutely sure SC has my SMN gear, not my Perp gear, on when the BP goes off.

<rules>
   <if type="BloodpactRage|BloodpactWard">
      <!-- Delays for gear swapping -->
      <action type="MidcastDelay" delay="1.0" ></action>
      <action type="AftercastDelay" delay="4.0" ></action>

      <action type="equip" when="precast" set="BP Delay" ></action>
      <action type="equip" when="aftercast" set="AvatarIdle" ></action>
	<if spell="Fire*|Stone*|Water*|...."
	   <action type="equip" when="midcast" set="BPMatk" ></if>
	</if>
   </if>
</rules>

Now when I use a BP in game, SC will put my BPMatk set after 1 second. It will only put my AvatarIdle set out after 4 seconds have elapsed. With these rules, there is about a 1 second delay between changing from my BPMatk set to my AvatarIdle set.
I can actually simplify the <action> tag to its barest components:

<rules>
   <if type="BloodpactRage|BloodpactWard">
      <!-- Delays for gear swapping -->
      <MidcastDelay delay="1.0" ></MidcastDelay>
      <AftercastDelay delay="4.0" ></AftercastDelay>

      <action type="equip" when="precast" set="BP Delay" ></action>
      <action type="equip" when="aftercast" set="AvatarIdle" ></action>
	<if spell="Fire*|Stone*|Water*|...."
	   <action type="equip" when="midcast" set="BPMatk" ></if>
	</if>
   </if>
</rules>

It's up to you which style you prefer.


<ACTION> AND SPELLCANCEL
What is this? Well, SC and another plugin called Cancel actually play really nicely together.
The Cancel plugin allows you to cancel a buff based off of its ID name. With SC, you can now cancel buffs based off of conditions. (NOTE: You must have Cancel plugin v1.0)

Here is a rule from Aikar's SC. Remember all those times you forgot to take off your Ni shadows when you cast Ichi?

<if spell="Utsusemi: Ichi" BuffActive="Copy Image">
   <midcastdelay delay="3.0" ></midcastdelay>
      <command when="midcast">cancel 66</command>
</if>

Or how about Stoneskin?

<elseif Spell="Stoneskin" BuffActive="Stoneskin">
   <command when="midcast">cancel 37</command>
      <midcastdelay delay="4.8" ></midcastdelay>
</if>

Sneak from Spectral jig?!!

<if spell="Spectral Jig">
    <command when="PreCast">cancel 71</command>
</if>

THE POWWWEEERRRR!!!111oneoneoneone…one

CAUTION: These rules look so awesome, but you shouldn't copy/paste them into your SC (not so much for Spectral jig though). This is because your delay is very sensitive. It is mainly based off of your gear (haste/fast cast?), how well your computer can handle FFXI and if you are experiencing lag. Hence these are the rules you should definitively write out yourself. You should do some extensive testing to see what works for you.

REFINING YOUR SPELLCAST
2.0 SC WRITING TIPS

By now, you are well-equipped to make your SC functional. The proceedng sections are an optional read and merely here to help you refine your SC.

Here, I want to tell you about the problems I've run into writing my first SC for SMN.

As a first time programmer with very minimal knowledge, writing my first SC for SMN SC was a terrible, terrible headache. If you want to write your first SC, I would highly recommend to not start with a pet job. Especially SMN. This is because it's a mage pet job: SC has no rules based off of pets, each avatar might have their own unique perp set as well as trying to integrate the day/weather conditions for AF2 head or AF3+2 hands.

The first quirk I'd like to explain is my strong dislike for apostrophes. Here is how I've set up my Avatar Idle set.

<variables>
<!-- Gear swapping stuff slots -->
   <var name="AvatarHead">Caller's horn +2</var>
   <Var name="RageHead">Caller's horn +2</Var>
   <var name="AvatarBody">Caller's doublet +2</var>
   <var name="AvatarHands">Caller's bracers +2</var>
   <var name="AvatarPerp">Fay crozier</var>
		
<!-- Stupid apostrophes -->
   <var name="SMNHorn">Summoner's horn</var>
   <var name="IdleHands">Caller's bracers +2</var>
   <var name="IdleHead">Caller's horn +2</var>
   <var name="IdleBody">Caller's doublet +2</var>
   <var name="Idlefeet">Caller's pigaches +2</var>

</variables>
....
      <set name="AvatarIdle">
         <main>$AvatarPerp</main>
         <sub>Vox grip</sub>
	 <ammo>Clarus stone</ammo>
	 <head>$Avatarhead</head>
	 <neck>Caller's pendant</neck>
	 <lear>Caller's earring</lear>
	 <rear>Gifted earring</rear>
	 <body>$Avatarbody</body>
	 <hands>$Avatarhands</hands>
	 <lring>Evoker's ring</lring>
	 <rring>Ether ring</rring>
	 <back>Hexerei cape</back>
	 <waist>Hierarch belt</waist>
	 <legs>Evoker's spats</legs>
	 <feet>Caller's pigaches +2</feet>
      </set>
....
<rules>
.....
   <if spell="Release">
      <action type="equip" when="Precast" set="Idle" ></action>
      <action type="var" cmd='set AvatarPerp "Fay crozier"' ></action>
      <action type="var" cmd='set Avatarbody "$IdleBody"' ></action>
      <action type="var" cmd='set Avatarhands "$IdleHands"' ></action>
      <action type="var" cmd='set Avatarhead "$IdleHead"' ></action>
      <action type="var" cmd='set RageHead "$IdleHead"' ></action>
   </if>
</rules>

Now why did I make two sets of variables that refer to do the same gear? Allow me to demonstrate.

   <if spell="Release">
      <action type="equip" when="Precast" set="Idle" ></action>
      <action type="var" cmd='set AvatarPerp "Fay crozier"' ></action>
      <action type="var" cmd='set Avatarbody "Caller's doublet +2"' ></action>
      <action type="var" cmd='set Avatarhands "Caller's bracers +2"' ></action>
      <action type="var" cmd='set Avatarhead "Caller's horn +2"' ></action>
      <action type="var" cmd='set RageHead "Caller's horn +2"' ></action>
   </if>
</rules>

Do you see that? This was a very lovely surprise. Due to the apostrophe in my gear, it effectively cut off the command to (cmd='set Avatarhands "caller') and reopened it to ('" />….) Should I highlight my note from the beginning? <!– STUPID APOSTROPHES –> >:(

When you're writing, you should try to not repeat your rules. Also, if possible, you should try compressing your rules as much as possible.

<if spell="Carbuncle">
   <action type="var" cmd='set Avatarhands "Carbuncle Mitts"' ></action>
</if>
<if spell="Ramuh">
   <action type="equip" when="midcast" set="AvatarIdle" ></action>
</if>
<if spell="Shiva"
   <action type="equip" when="midcast" set="AvatarIdle" ></if>
</if>
<!-- Notice how I want to wear the same set for different avatars -->
<if advanced='("%SpellElement"="%WeatherElement")'>
   <action type="var" cmd='set Avatarhead $SMNHorn' ></action>
</if>

Versus…

<if type="Summonerpact">
<!-- Particular gear swaps -->
   <if advanced='("%SpellElement"="%WeatherElement")'>
      <action type="var" cmd='set Avatarhead $SMNHorn' ></action>
   </if>
   <if spell="Carbuncle">
      <action type="var" cmd='set Avatarhands "Carbuncle Mitts" ></action>
   </if>
   <elseif spell="Garuda">
      <action type="var" cmd='set Ragehead "Karura Hachigane"' ></action>
      <action type="var" cmd='set AvatarPerp "Teiwaz"' ></action>
      <if advanced='("%WeatherElement"!="Wind")'>
	 <action type="var" cmd='set AvatarHead "Karura Hachigane"'></action>
	 <action type="equip" when="Precast">
	    <head>$AvatarHead</head>
	 </action>
      </if>
   </elseif>
   <action type="equip" when="midcast" set="AvatarIdle" ></action>
</if>

Even though you can still use <if>, it's much better to make use of the <elseif> and <else> tags. With <action> tags, they don't necessary need a rule to be initiated. If you leave them like in the above example, SC will always process it.

If your SC says there's an open tag and there really isn't, try changing the capital letters to a small latter (<Set name> to <set name>) or vice versa. Sometimes SC gets weird like that.