SpellCast (2.17)

Note - here is a list of CPUs supporting SSE2

• AMD K8-based CPUs (Athlon 64, Sempron 64, Turion 64, etc)
• Intel NetBurst-based CPUs (Pentium 4, Xeon, Celeron, Celeron D, etc)
• Intel Pentium M and Celeron M
• Intel Core-based CPUs (Core Duo, Core Solo, etc)
• Intel Core 2-based CPUs (Core 2 Duo, Core 2 Quad, etc)
• Transmeta Efficeon
• Via C7

If your CPU is an older one than those listed above, please make sure you download the version with SSE1.

SpellCast (2.17) is macro and game engine enhancement. SpellCast (2.17) was designed to get around SE's tedium of typing commands instead of using macros, and SE's inability to give us more advanced macros capable of changing ALL our gear in 1 macro instead of only 5 pieces. SpellCast is for all jobs, giving you the power to quickly setup macros and easily change gear in your macros. SpellCast maximizes your potential with fast gear swaps.

SpellCast (2.17):

…will let you type 'simpler' spell commands, where you don't need <t>, you don't need ” ” around double word spells, you dont need :,' or - within spells and you don't need to use roman numerics!

…now gives you the power to change ALL of your gear, when you want, when you need it to, all based on conditions you setup.

…will turn all of your macros into 1 line, the casting line! Since its release, many advanced features have been added, such as conditions with Weather, Day, MP, subjob and more!

…gives you the power to make sets of gear, and put those sets into groups.

Make a group for uncapped events, make a group for level caps. Doing a lv50 cap? Make a group for it, then issue the change group command and set it to the lv50cap group. Now, all your spells are using different sets of gear for level 50 things instead.

The power of this plugin will continue to grow. I hope this makes every caster alive happy and enjoy easier to use macros!

SpellCast was originally designed with mages in mind. This is no longer the case. References to spells within the documentation and xml actually encompass job abilities, weapon skills, etc.

What follows are just some of the features of SpellCast that come along with the advanced equipment set management features.

In FFXI when you want to cast a higher tier spell, you must type the whole name with roman numerals in quotes no less! SpellCast not only allows you to type that spell without quotes, but also allows you to type numbers instead of those roman numerals, and removes the need to type non alphanumeric characters. /ma “Cure IV” <t> becomes /ma Cure4 with SpellCast running.

In FFXI when a ninja wants to use Utsusemi, they must type /ma “Utsusemi: Ichi” <me>. SpellCast removes the necessity of the colon, /ma “Utsusemi Ichi” <me> will work as well. In fact, with SpellCast you can even forget the space between Utsusemi and Ichi and the quotes, and it will still cast correctly. ie. /ma Utsusemiichi <me> will work as well.

SpellCast adds commands that you can use in game to cast a spell. For example, instead of typing /ma “Cure II” <t> in game, with SpellCast you can type //Cure2

SpellCast will automatically correct the pre-command for spells if you specify the wrong type. For example if you type /ma “Dancing Edge” <t> SpellCast will automatically process the command correctly as /ws “Dancing Edge” <t>.

In FFXI when you type /ma “Cure” and forget to add the <t>, your spell does not process and your dunes party dies T T. With SpellCast the same mistake would by default cast on whoever you have targeted! Your dunes party rejoices, for as much as a dunes party can be happy anyway. Also, any spell that is only castable on yourself, will default to <me> instead of <t>. Previously in FFXI all spells defaulted to <t> if no target was specified until one unneeded patch to the game. SpellCast brings that functionality back and improves it with <me> handling.

Additionally, SpellCast allows you to change this functionality on a per spell basis using the DefaultTarget action.

In FFXI when you attempt to cast Cure IV on someone who really needs it, but you are missing that one mp at the wrong time, you have to go back and attempt casting Cure III instead. Using ChangeSpell, you can automate this and have SpellCast cast lower levels of spells when you don't have enough MP for the first one.

Current commands can be invoked via /spellcast or /sc in the chat area or spellcast or sc in the Windower Console followed by the appropriate command.

The following commands are available as of version 2.11.

SpellCast (2.17) uses a special XML file to load your gear sets and spell rules. SpellCast XML files should be placed in your plugins\spellcast\ sub folder of your Windower installation. When SpellCast loads, it automatically loads a file named default.xml. If this is your first time running SpellCast, the default.xml file is created for you on load.

The basic structure of the major SpellCast tags is as follows:

<?xml version="1.0" ?>
<!--The above line tells applications reading the file that it is in XML format.-->
<!--Text within tags like this is a comment in XML-->
<spellcast>
<!--The above line specifies the SpellCast section of the XML file so SpellCast knows where to look when it opens the file-->
	<config>
		<!--Attributes associated with the config section control basic SpellCast settings-->
		<!--This tag is usually closed on the same tag it is opened using a / before the closing greater than symbol-->
	</config>
	<sets>
		<!--This is where you would define your SpellCast equipment sets and groups-->
	</sets>
	<variables>
		<!--This is where you would define custom variables for SpellCast-->
	</variables>
	<rules>
		<!--This is where you would define rules that tell SpellCast what to do and when-->
	</rules>
</spellcast>

Descriptions of these tags, and the tags they contain are provided below.

This is where we setup SpellCast (2.17). The following table lists the possible options for config with a description.

• Deprecated means that the feature has been replaced and that the alternate version should be used. While the current version of SpellCast will support this feature, future compatibility is not guaranteed.

Next we have sets (Required). Sets contain all of your group definitions. Sets have no configuration options but has a sub command called Groups.

Groups are where we define our gear sets that we would like to use. Please refer to the following table for the possible options for groups.

Inside of our group we finally define our various gear sets. The command for this is Set not to be confused with the command Sets. Set has various configuration options as well as additional sub commands we use to specify what gear we want equipped and in which gear slot. The following table shows us the configuration options.

Set supports the following sub options.

Each of these supports the option lock. If this is set to anything, this gear will be 'locked' so that, any set inheriting from this set will not be able to override this gear slot with its own gear, and also any rules will not override this piece either. Example: if SetA has main set to LightStaff, and SetB Inherits SetA, but has main set to DarkStaff, If Main is not locked, Dark Staff will override LightStaff. If Lock is true, main will be kept to LightStaff, and no set inheriting the set can change that. Ex. <Main lock=“yes”>Light Staff</main> or <Main lock>Light Staff</Main>

SpellCast can also remove equipment for you. To do this, instead of specifying a piece of gear for a slot, specify Remove instead. Ex: <main>remove</main> will UNEQUIP that slot.

NOTE: When specifying your gear within the set, you can use variables within the gear names.

The variables section allows you to automate the process of setting up user defined variables. The variables tag itself has one attribute, clear which if true tells SpellCast to clear out all variables when the XML is loaded.

Ex: <variables clear=“true”> will erase ALL custom variables every time your XML is (re)loaded.

For more information on using variables, check the variables section.

The var tag has two attributes, name and nooverwrite. The value specified between the <var> tags is the value that will be assigned to that variable upon XML (re)load. If nooverwrite is true, the variable will retain its current value on XML reload rather than the value specified in the XML.

<variables>
	<var name="LastSummon" nooverwrite="true">Carbuncle</var>
	<var name="CG">Congrats!</var>
</variables>

This is what transforms SpellCast from merely holding sets of equipment, to helping you equip the right sets at the right time. When you cast a spell, SpellCast goes to this section to figure out what actions to do, what equipment to equip, and when to do these.

Within the rules section you can place <if> rules, <elseif> rules, <else> rules, and <action>s. Actions that are not placed within an <if>, <elseif>, or <else> tag will process every time.

Note: you can specify rules on the <rules> tag itself, in order to keep SpellCast from even processing your rules.

<if> bound rules will be checked for “truth” every time they are reached in a SpellCast parse. The way you determine what SpellCast checks against is by adding attributes(rules) to the tag. Click here for a list of all rules. Example rule: <if MainJob=“BLM” Day=“Lightningsday” WeatherElement=“Thunder”>

Within the <if> tag, you can place <actions> and also nest additional <if>, <elseif>, <else> tags as deep as you need.

The Action tag is where you tell SpellCast what you actually want it to do when the time is right. It has one required option called type. Depending on the type attribute set, additional attributes become available.

Example: <action type=“equip” when=“precast” Set=“Nukes” />

WHEN attribute information:
SpellCast has the ability to process actions before casting starts(PreCast), after casting starts(MidCast), after casting completes(AfterCast), and new to 2.11, when an auto set is triggered(AutoSet). The when attribute is used to tell SpellCast at which “time” the action should take place.

• Casting related times:
  • PreCast or pre* or start* or before* will process before casting even begins.
  • MidCast or mid* or during* will process after casting begins.
  • AfterCast or after* or post* or done* will process after casting completes.
• Status related times:
  • autoset processes when any autoset is triggered.
  • resting processes when autoset restingset is triggered.
  • engaged processes when autoset engagedset is triggered.
  • idle processes when autoset normalset is triggered.
• When attributes support piping to cover multiple times. ie. when=“PreCast|MidCast|resting”

NOTE: Some SpellCast commands that relate to the inner workings of SpellCast process immediately as the line is read and do not have a when attribute.

<elseif> bound rule criteria will be checked only if the immediately preceding <if> or <elseif> rule check evaluated to false. Beyond that, it works exactly the same as an <if> rule and supports the same nesting.

<else> rules will only process if the immediately preceding <if> or <elseif> rule criteria check evaluated to false. <else> rules do not check against any rule criteria themselves. Beyond that, it works exactly the same as an <if> rule and supports the same nesting.

As mentioned, you can place actions directly into rules and they will be processed every time. For a list of actions, please refer to the above <action> section under <if>.

Please view the User Submitted XML section for XML examples and starts.

In addition to processing the rules section when you cast a spell, SpellCast (2.17) will also process the rules section when you trigger certain status changes. These include engaging, resting, idle, etc. This was done in order to give you more control over what gear is equipped on autosets by limiting them with conditions, since previous config options for autosets did not parse rules, it was limited to 1 set name, and no way to be specific on what gear it should automatically equip. This also led to requiring the same set names for every group for auto sets. This new autoset parsing gives you more control, and therefor the config options are deprecated and not recommended!

As of SpellCast 2.11, the way these status changes are handled are via a pretend spell. When you change statuses, SpellCast sends to the rules section a spell named “autoset”. This allows you to have special rules that only process on the status triggers. Along with this feature, you can additionally use the when attribute on actions, to specify the different status events.

Example:

<!--This will be caught by autoset events-->
<if spell="autoset">
	<!--Techinally dont need to set the if checks since the only when condition will be the one for the status you want-->
	<if status="resting">
		<!--Note: You need to set the when here to match the status event you want-->
		<action type="equip" when="resting" set="Resting Gear" />
	</if>
	<elseif status="idle">
		<action type="equip" when="idle" set="Idle Gear" />
	</elseif>
	<elseif status="engaged">
		<action type="equip" when="engaged" set="Engaged Gear" />
	</elseif>
</if>

The above example is very verbose to show spellcast features. In a real world configuration it could be reduced to:

<action type="equip" when="resting" set="Resting Gear" />
<action type="equip" when="idle" set="Idle Gear" />
<action type="equip" when="engaged" set="Engaged Gear" />

SpellCast (2.17) supports an old format for dealing with these autosets as well, which is through the config section. This feature has been deprecate however, and you should switch over to this format.

NOTE: Since HELM and Fishing sets are simple and should not require any conditionals on what to equip, those 2 autosets are remaining as <config> options and not being added to rule parsing..

Locking in SpellCast allows you to keep equipment from being overridden without disabling the slot altogether. Locking happens on the <slot> level of sets and equip actions. Locking is set by adding the lock attribute to a <slot>.

Locking in sets allows you to keep inheriting sets from overriding a particular slot. Additionally if a slot is locked in a particular set, no equip actions will be able to override that lock while in that set.

Locking in actions allows you to keep any later actions from overriding a slot. Additionally you can set up rules and actions to keep from changing equipment from what you have equipped in FFXI.

Note: Locking within the rules section only keeps later actions from changing equipment. Autosets like EngagedSet will still change your equipment even if the last pass through of rules locked the slot. If you need to lock on a more global level use SpellCast disable/enable commands.

• To lock equipment to what is currently equipped in FFXI, lock the slot with an empty tag:

<!--"Disables" slots that cause you to loose TP whenever you have over 10 TP-->
<!--Works by locking an empty switch into SpellCast-->
<if TPGT="10">
	<action type="equip" when="precast"> 
		<main lock="t" />
		<sub lock="t" />
		<range lock="t" />
	</action>
	<action type="equip" when="midcast"> 
		<main lock="t" />
		<sub lock="t" />
		<range lock="t" />
	</action>
	<action type="equip" when="aftercast"> 
		<main lock="t" />
		<sub lock="t" />
		<range lock="t" />
	</action>
</if>

• To lock an equipment switch so that it cant be overridden by later equip actions:

<!--Equips MaxMP enhancing gear, and then locks that gear so other actions don't override it-->
<if MPGT="331"> 
	<action type="equip" when="precast|midcast|aftercast"> 
		<lring lock="t">Ether ring</lring> 
		<rring lock="t">Astral ring</rring> 
		<legs lock="t">Custom pants</legs> 
	</action> 
</if>

SpellCast conditionally determines what to do based on various criteria which you set. For a list of the possible rules you can have SpellCast check against, click here.

SpellCast (2.17) supports both predefined variables, and user defined variables. These variables can be used throughout SpellCast in order to perform some more advanced abilities. The basic idea of variables is that when SpellCast reaches a variable in say an action, it translates the variable to whatever value is stored inside before it process the command. SpellCast Variables are also used heavily in Advanced rules. This feature can be used in a growing number of places from actions, to set definition, and even when typing chatlines into FFXI! If you type /p The weather is currently %Weather into chat in FFXI for example, your party will actually be told whatever the weather really is in FFXI at the moment you send the chatline.

SpellCast comes with many predefined variables. SpellCast predefined variables are referenced by pre-pending a % sign before the variable name. For a full list of them, click here.

SpellCast allows you to define your own variables for use. These can be used everywhere the predefined variables can, but have the extra ability to be set to custom values. User defined variables can be set using the <variables> section of your xml, the var type actions, or via SpellCast commands. User defined variables are referenced by pre-pending a $ sign before the variable name.

When chaining parsing between predefined and user defined variables, the predefined variables will parse first.

• Assigning a variable to a value:
  set VariableName Value

• Assigning a variable to another variable's value:
  set Variable1Name $Variable2Name
  Note: When assigning one variable to another, it will only transfer one word unless using quotes when defining the second variable.

• Assigning a variable to reference another variable:
  set Variable1Name \$Variable2Name

• Combining pre-defined and user defined Variables:
  pre-defined variables will process before user defined variables.
  So in the example below you can have a dynamic staff swap.

<!--Have $SetStaff inside of a set-->
<set name="standard">
	<main>$SetStaff</main>
</set>
<!--Create Variables for all your staves, and one to be changed-->
<variables>
	<var name="SetStaff">Apollo's Staff</var>
	<var name="Light">"Apollo's Staff"</var>
	<var name="Dark">"Pluto's Staff"</var>
	<var name="Earth">"Terra's Staff"</var>
	<var name="Water">"Neptune's Staff"</var>
	<var name="Wind">"Auster's Staff"</var>
	<var name="Fire">"Vulcan's Staff"</var>
	<var name="Ice">"Aquillo's Staff"</var>
	<var name="Thunder">"Jupiter's Staff"</var>
</variables>
<!--Insert action inside of your rule-->
<rules>
	<if skill="ElementalMagic"> 
		<!--%SpellElement will process first. If ThunderIV is cast then $SetStaff will be set to $Thunder -->
		<action type="Var" cmd="set SetStaff $%SpellElement" /> 
	</if>
<rules>

When SpellCast processes a string with multiple variable indicators(% and $) in a row, it will attempt to resolve the variable name multiple times. This allows for some nice features. I should note that if mixing between custom and predefined variables, the ordering of indicators is important. SpellCast will remove indicators from right to left, and replace strings from left to right.

One common use of this is to equip the correct obi based on the weather element as follows:

<variables>
  <!--Corresponding Obi per element-->
  <var Name="EarthObi">Dorin Obi</var>
  <var Name="ThunderObi">Rairin Obi</var>
  <var Name="WaterObi">Suirin Obi</var>
  <var Name="FireObi">Karin Obi</var>	
  <var Name="IceObi">Suirin Obi</var>
  <var Name="WindObi">Furin Obi</var>
  <var Name="LightObi">Korin Obi</var>
  <var Name="DarkObi">Anrin Obi</var>
</variables>
 
<rules>
  <!--  Equip The right obi based on weather(and scholar storm) or day-->
  <if Advanced='"%SpellElement" = "%WeatherElement" OR "%SpellElement" = "%DayElement"'> 
    <!--Equip your weather/day related gear here.-->
    <action Type="Equip" When="MidCast"> 
      <waist Lock="Yes">$%SpellElementObi</waist> 
      <!--An alternative would have been to define sets by these names and only parse once-->
    </action> 
  </if>
</rules>

Once you've completed your XML file you can begin using SpellCast (2.17) inside Final Fantasy XI. Without changing a thing you may begin casting spells right from your Spell Menu. SpellCast (2.17) will intercept the command and begin to parse its rules for one that includes the spell you selected. You may also type in the spell to the chat log. See the following example.

/ma Cure III

The above example will cast Cure III on whom ever you have targeted. Notice we do not enclose the spell name with quotation marks or specify <t> as our target. The plugin as mentioned before removes those requirements.

We can also use simpler spell names.

/ma cure3

This has the same effect as our previous example.

Using SpellCast (2.17) with your macro palettes is the same as typing them in to the chat log. For example a macro for Cure III would contain only the following.

/ma Cure III

OR

/ma cure3

Since all of our gear swaps are handled by the rules we defined in our XML file we do not need to include them. Therefore macro's are reduced to a single line while retaining functionality.

Using SpellCast (2.17) in scripts can be achieved using the following syntax. Old Style, Not needed:

input /ma "Cure III"

using ma handler in scripts, no input command needed:

ma Cure3

Using as quick aliases:

cure3

With the addition of the cancel plugin to the windower plugin repertoire, some FFXI annoyances can now be fixed by use of SpellCast.
You must have the Cancel (1.0) plugin loaded in order for these to in fact cancel your buffs. Canceling buffs is not a SpellCast feature itself.

WARNING: The delays used in the following examples have been tested to work in a lag free area. You should test and adjust the delays accordingly for yourself. Anything from lag to planet alignment could delay the canceling to be too late if delay is not set short enough. These suggested delays do not consider equipment that enhances fastcast.

Translation: Be prepared for a misfire of cancel activating too late. These rules are here as a starting point, not a guarantee.

• Casting Utsusemi: Ichi does not override Utsusemi: Ni if shadows still remain. If we use Cancel for buff id 66 we can auto-cancel the remaining shadows. Note: Ichi over Ni is the only case this is needed for.

<!-- Rule for auto-canceling of shadows during Utsusemi: Ichi cast-->
<if spell="Utsusemi: Ichi">
	<action type="Equip" when="precast" set="Evasion" />
	<!--Utsusemi:Ichi cast time is 4 sec-->
	<!--This may be conservative and it may not always be enough. I have seen delay 3 work-->
	<!--Find a delay value that YOU are comfortable relying upon-->
	<action type="midcastdelay" delay="2.5" />
	<!--Cancel currently active shadows(Buff_Id 66). Technically only need for Ni to Ichi, but no way to tell-->
	<action type="Command" when="midcast">cancel 66</action> 
</if>

• Casting Sneak does not override Sneak. If we use Cancel for buff id 71 we can auto-cancel Sneak before the new cast takes effect.
  NOTE: The following code does not differentiate between self casting and casting on others. Currently SpellCast is unable to tell who you have targeted with <t>, so this is setup to only work on <me>.

<!-- Rule for auto-canceling of sneak for sneak recasting-->
<if spell="Sneak" BuffActive="Sneak" advanced='"%target"="&lt;me&gt;"'>>
	<!--Alternatively you can use precast for this if you don't want to worry about canceling too late-->
	<action type="midcastdelay" delay="2.5" />
	<!--Cancel currently active sneak-->
	<action type="Command" when="MidCast">cancel 71</action> 
</if>

• Casting Stoneskin does not override Stoneskin. If we use Cancel for buff id 37 we can auto-cancel Stoneskin before the new cast takes effect.

<!-- Rule for auto-canceling of stoneskin for recasting-->
<if spell="Stoneskin">
	<!--A delay of 6.5 worked fine on my whm, so atleast .5 sec buffer-->
	<action type="midcastdelay" delay="6" />
	<!--Cancel currently active stoneskin-->
	<action type="Command" when="MidCast">cancel 37</action> 
</if>

• Using Spectral Jig does not override Sneak. As a result, the entire effect fails, even Invisible! Since Invisible is removed by using Spectral Jig, we only need to cancel Sneak.

<!-- Rule for auto-canceling Sneak for Spectral Jig-->
<if spell="Spectral Jig">
	<!--CastDelay isn't necessary here, because the commands are sent in the proper order to the server - cancel sneak,
	  then use jig-->
	<action type="Command" when="PreCast">cancel 71</action>
</if>

You may make use of the variable system to create Dynamic sets that you can change based on rules and reuse at a later date.

To do this, you would setup a new set and give each slot you want to be dynamic a value of a variable, as so:

<set name="CustomSet" BaseSet="Standard">
   <main>$CustomMain</main>
   <body>$CustomBody</body>
   <hands>$CustomHands</hands>
   <legs>$CustomLegs</legs>
</set>

Now you can do /sc var set CustomMain “Light Staff” and now any time that set is called it will use light staff. You can also use the <action type=“var”> to set pieces based on rules.

<action type=“var” cmd='set CustomMain “Dark Staff”' />

these sets will not change until you change them by resetting the variables. Be creative!

Do not repeat rules!(Nest when possible)
example of improper use:

<if MainJob="BLM" Element="Thunder">...</if>
<if MainJob="BLM" Element="Fire">...</if>
<if MainJob="BLM" Element="Water">...</if>

See how Main Job is duplicated? That can be changed to:

<if MainJob="BLM">
	<if Element="Thunder">...</if>
	<if Element="Fire">...</if>
	<if Element="Water">...</if>
</if>

This is better, but lets say we cast Thunder, we still have extra checks which brings us to the next tip.

Make use of if, elseif and else rules.
example:

<if MainJob="BLM">
	<if Element="Thunder">...</if>
	<elseif Element="Fire">...</elseif>
	<elseif Element="Water">...</elseif>
</if>

Now if we cast Thunder, SpellCast wont worry about checking if we casted Fire or Water.

Do not wildcard 1 single rule for a full wildcard.
examples of improper use:

<if Group="*">...</if>

or

<if MainJob="*" SubJob="*">...</if>

Get the idea? It will ALWAYS return true… Dont waste CPU power 'checking'. Don't script a rule unless it should be restricting something.

If you want an action to ALWAYS be processed, regardless of group or job, don't put the action in any rule.
example:

<rules>
	<action .... />	<!--This action will process every time-->
	<if MainJob="BLM">
		<action ... /> <!--This action will process only if we are main job BLM-->
	</if>
</rules>

The first action will always be processed, the 2nd one will only be processed if main job is blm.

• SpellCast is changing my gear for everything! How can I stop it for 1 spell?
  Prefixing a command with /raw will prevent the command from being parsed by SpellCast.
  Example: /raw /ma “Cure IV” <t>
  
  Note: You do not get spell rewriting effect with raw!
• SpellCast error “Can not find set“
  The most likely cause of these errors beyond misspelling a set is that a set was declared but not actually defined. Check the autosets declared in your <config> section. SpellCast will assume that these sets are present in every one of your groups. If you are currently using a group that does not have the set inherited or defined, SpellCast will still look for it when you trigger that group. An example would be having a RestingSet declared from when you were writing those BLM rules, but then you started setting up SpellCast for your WAR who might rest but doesn't change gear.
  
  Fixing this error can be as easy as adding an empty set to your group of sets for WAR as follows:

  <!--This is just an empty set so I don't get "Can not find set" errors on WAR when I rest-->
  <set name="RestingSet" />

• FFXI error “You were unable to change your equipped items.”
  This is an error message from FFXI and will actually happen even when not using SpellCast if you do any of the following:
  • Actions that will cause the error:
    • Equipping an item to the wrong slot, ie. a ring to an earring slot will produce this error.
    • Having two of an item, one of them equipped, and requesting to equip that same item to the same slot may produce the error and not actually change equipment(need more testing).
  • Actions that wont cause the error:
    • Misspelling an item will not produce any errors, but will not equip anything.
    • Having two of an item, one of them equipped, and requesting to equip that same item to another slot does not appear to produce an error.
    • Requesting to equip an item that is already equipped, only one of the item in inventory, does not produce the error.
    • Using an invalid tag(one that doesn't exist, not one that is incorrect) for the equipment slot in SpellCast will produce no errors in FFXI or SpellCast but will not do anything.

• “SpellCast is changing gear too early for my aftercast action.”
  SpellCast 2.11 currently has a pretty good idea of when most casts complete, and processes aftercast actions accordingly. If however you find that SpellCast is processing them too early, you can set additional delays. Please see the AfterCastDelay action for more info.

• Problems using < and > in SpellCast command actions
  LessThan and GreaterThan symbols have special meaning in xml files(like the one SpellCast reads.) These are used to define the beginning and end of tags. In order to use them in your xml files for other uses, like putting in FFXI commands, you can use special four character tokens &lt; and &gt; in place of them. SpellCast will know to replace them with < and > respectively when it processes the command.
  
  As an example, suppose you wanted to tell SpellCast the default target for some spell. The following would be incorrectly parsed:

  <!--This action will not work correctly, as it is incorrectly defined-->
  <action type="DefaultTarget" target="<t>" />

  
  The correct format for this would be:

  <!--This action is in the correct format-->
  <action type="DefaultTarget" target="&lt;t&gt;" />

  
  NOTE: While it may be annoying, this is the way the xml standard deals with < and > inside xml files. It is completely proper for SpellCast to use the 4 character tokens for < and >.

• Nighttime rules not processing
  Nightime rules not processing are typically caused by an error in logic. Where as daytime rules are time is greater than 5:59 AND less than 18:00, nighttime rules should be time less than 6:00 OR time greater than 17:59. Check to make sure your nightime rule looks something like this.

  <if mode="OR" TimeLT="6.00" TimeGT="17.59">
  	<!--Whatever you want to do during nighttime goes here-->
  </if>

• Nighttime rules work, but when I engage I get the wrong set
  In the past SpellCast did not process the rules section for autosets. This has been changed as of SpellCast 2.11. Please read the autoset section for information if you are having issues.
  
  What follows is the old explanation of this issue.
  Spellcast does not process the rules section for autosets (normalset, engageset, restingset.) There is hope however ^^. With the new variable system you can specify variablenames as part of the setname for these autosets, and it will try to match up the sets. For an example of how one might implement this in spellcast/autoexec, click here. That being said, through the use of AutoExec and SpellCast groups(one for day and one for night), you could set up different auto sets anyway.

• Unable to set search comments by macro while SpellCast is running
  SpellCast overrides the /sc command in FFXI. In order to update your search comment use either /seacom or /raw /sc in it's place in game.

• Unable to cast tier 2 and tier 3 spells /SMN
  Because of the way SpellCast is setup to add support for quick aliases, when SpellCast detects summoner job it will assume you are attempting to use blood pacts if there is a blood pact equivalent for the spell. Essentially, BLM/SMN is snot supported. ^^

• SpellCast 2.16 is unable to find the time signature for some users and will not load. An alternate method has been found and will be used in SpellCast 2.17. Some users are able to use 2.15 in the meantime available here: http://windower.net/plugins/oldplugins/spellcast/2.15/
• FFXI macro processing continues after spell cancellation for some users when SpellCast is loaded. Windower issue?

• Windower is currently not sending special characters(used for other languages) to FFXI correctly. This means non english language will have issues with gear and spells that have them in their names. Source

Often times, issues are caused by errors in user XML.

Before you ask for help please read the following:

1. Please validate your XML. Syntax errors are enough to render whole parts of your XML useless. To validate your XML, simply open the XML file with Firefox, this will point out most flaws. If you don't have Firefox, we can recommend pasting your XML to http://www.validome.org/xml/ (don't forget to check Well-Formedness Only). There is no use for anyone to look at your XML until either method stops reporting errors. Using an XML editor like Notepad++ can help prevent such errors.
2. Once you have checked that your XML is valid, and you still have trouble, search the forum first.
3. If you can't find anything relevant, post your complete XML on http://paste.windower.net. Don't post just the part that doesn't work. Seeing the whole file will give people helping you a better picture, a chance of figuring out what the values of certain variables might be, and the ability to possibly spot logic errors elsewhere in the file that might have impact on the part that isn't working. Set the syntax highlighting to XML.
4. Make a new post on SpellCast Forum, describe your problem and include a link to your XML on the Pastebin.

To report a new issue, please go to the SpellCast 2.17 Bug Report Thread and check to see that it is not already listed there and just has not been updated on the wiki. If it is a new bug feel free to post, with information on how to reproduce it. If your issue MIGHT be an issue with your XML, please check that before reporting it as an issue.

Power users may directly add the bug to the Bug Tracker: http://forums.windower.net/index.php?autocom=tracker&showproject=3