Spellcast Help Thread (Link your XML using Pastebin.com for help!)

[Yugl]

On laptop, so I cannot play as effectively (or test aggressively), but I'm betting the issue with <If area> rules. I'll try adding advanced='"$Area"!="Abyssea"' to see if that fixes the issue.

[GoggleHead]

                                <!-- Refresh -->
				<elseif spell="Refresh*">
					<equip when="precast" set="FastCast" />
					<equip when="midcast" set="ConserveMP|EnhancingDuration" />
					<equip when="aftercast" set="$AfterCast" />
					<!-- Composure rules -->
					<if buffactive="Composure"  NotSpellTarget="SELF">
						<equip when="midcast" set="AugmentsComposure" />
					</if>					
				</elseif>

The Composure conditional is acting like an OR statement when I need to act like an AND statement(goes off when I cast on myself with composure active). I'm sure it's a simple fix, but I'm not seeing it.

[Radec]

                                <!-- Refresh -->
				<elseif spell="Refresh*">
					<equip when="precast" set="FastCast" />
					<equip when="midcast" set="ConserveMP|EnhancingDuration" />
					<equip when="aftercast" set="$AfterCast" />
					<!-- Composure rules -->
					<if buffactive="Composure"  NotSpellTarget="SELF">
						<equip when="midcast" set="AugmentsComposure" />
					</if>					
				</elseif>

The Composure conditional is acting like an OR statement when I need to act like an AND statement(goes off when I cast on myself with composure active). I'm sure it's a simple fix, but I'm not seeing it.

I believe it's NotSpellTargetType="SELF", or NotSpellTarget="<your name>"

Edit: Alternative try <if mode="AND" buffactive="composure"... but AND mode is the default and should already be on.

[GoggleHead]

I took a look at a friend's XML and yeah, it looks like I left off Type at the end there. Gonna pass out for the night, I'll test it tomorrow.

Edit: yeah that fixed it. Thanks man.

[Motenten]

@Yugl:

Looking at your build up of the mnk xml. Very interesting. There are several things I'd do differently, but hard to say if they'd be 'better'.

<if notSpell="$TriggerSetOne|$TriggerSetTwo|$TriggerSetThree">
  <xi:include href="include.xml" xpointer="//include[@name='ReturnRules']/*" />
</if>

Since TriggerSetOne/Two/Three should be standardized variables, why not include that as part of the ReturnRules rule instead of having to specify it within each XML? Also, if you forget to include this filter check here, you get locked out of using trigger actions by the ReturnRules section itself.

Not sure why mnk needs the LockWeaponRule.

AutoChangeGear is an interesting approach, but I think has weaknesses. It depends on how you're defining your $Idle and $TP variables.

There's no point in including the PowderBootsRule for mnk; mnk can't wear those shoes.

Your UpdateSet rule is duplicated almost immediately by code inside the mnk.xml.




With mine, I set up trigger toggles in different ways.

You have a cycle through haste/evasion/accuracy. I tried using that a while back, but it got too cumbersome to manage. It seems far easier to work only with specific subsets, mostly using simple toggles.

I have one of three evasion variants: simple toggle, multiple evasion levels, or an evasion/counter cycle. Accuracy also works as a cycle value, though it doesn't need nearly as much fine-tuning as it did back at 75, so I only have 5 tiers for physical accuracy, 3 tiers for magical accuracy.

Also use the T5 elemental nukes plus Bio III as toggles for types of MDT/PDT sets, which add in elemental resist for the appropriate element, or more straight PDT, as needed. I can't use those as general types for blm or sch, but they don't really need those toggles anyway.


I see you make use of the BlankSet set (what I call "None" in mine). Very useful tool for variable-based set construction. Still, I see a huge amount of redundancy in setting variables, which could make maintainance annoying. All your trigger commands should, ideally, only ever be setting their own specific variable value; after all code for checking triggers is done, then you compose your final set out of all the individual values.

Your staff constants are interesting, but you're missing one set: staff for use when testing procs; minimize damage rather than maximize damage. Also, I'm not sure of the need for multiple individual includes. Seems easier to simply have a single "Staff" include that has all the various variables.

Interesting way of working around the weaponskill distance limitation.

I also use an include set for weaponskill gorgets, using piped set names. Since you're setting up custom sets for every weaponskill you wouldn't really encounter this limitation, but it would be important if you have just general weaponskill class groups. Also useful for not having to create a ton of secondary sets within the job xml for jobs that do a lot of procs. And if you use wildcard sets, you don't have about brokenness or error messages just because you didn't set up that particular weaponskill gorget beforehand.


I see from one of your recent posts that you're aware of building sets with layering as opposed to hand-building each individual set. I find that much easier to use, though there have been a couple times where the layering got over-complicated.

Would also suggest setting an additional action filter around trigger actions. If you're using a weaponskill, there's no reason to have to check every single one of those rules that are based on spells.

[Akyrey90]

anybody can find why this xml (nin xml based on yugl's mnk xml) not swapping hands,ear,idlefeet and others variable gears i set?
NIN_XML

[Haborym]

Shouldn't it be..

<action type="Var" cmd="set TPHands  YOURHANDS" />

Instead of

<var cmd="set TPHands YOURHANDS" />

[Yugl]

<if notSpell="$TriggerSetOne|$TriggerSetTwo|$TriggerSetThree">
  <xi:include href="include.xml" xpointer="//include[@name='ReturnRules']/*" />
</if>

Since TriggerSetOne/Two/Three should be standardized variables, why not include that as part of the ReturnRules rule instead of having to specify it within each XML? Also, if you forget to include this filter check here, you get locked out of using trigger actions by the ReturnRules section itself.

Since I use a Template to start my XMLs, I should never forget this additional rule for this include. In the event that I need to exclude other spells or abilities from return rules (No reason to now, but these XMLs were made with the future in mind), applying this rule individually will help.

Not sure why mnk needs the LockWeaponRule.

This is going to need a bit of fixing due to the Utsusemi:Ichi problem, but my original intention was for people to put elemental staffs for ninjutsu (Radec inspired; MNK soloing Azure) and Earth/Terra's Staff for their PDT set. This way, if they're fighting a mob they want full PDT against and do not mind the reduction in TP, they can just unlock the weapon to access Terra's staff.

AutoChangeGear is an interesting approach, but I think has weaknesses. It depends on how you're defining your $Idle and $TP variables.

TP/Idle gear should be defined by the current TP/Idle set you have chosen, so that was intentional. However, if I understand your concern, you're suggesting I could use TP-$VARTP|$PerfectCounter|$Impetus|$Armor or some variation rather than setting the $TP variable. I honestly thought I looked into this issue and found a problem, but that might have been back before I upgraded my XML to v2 and invented the $Armor variable. Prior to that, there would have been no way to know whether you had PDT or not for your TP/Idle set. I'll definitely give this another check, but if I do, that will definitely move the XML out of the include and into each individual XML.

There's no point in including the PowderBootsRule for mnk; mnk can't wear those shoes.

Thanks, I'll remove that (Powder boots is in the general template, so I accidentally left that).

Your UpdateSet rule is duplicated almost immediately by code inside the mnk.xml.

Midway in making the XML I realized I couldn't use that as a universal rule, so I decided to put them in each XML instead of the include. However, when I went to edit the include rule in the MNK XML, I accidentally took out AutoChangeGear instead of UpdateSet. The XML linked has that fixed.




With mine, I set up trigger toggles in different ways.

You have a cycle through haste/evasion/accuracy. I tried using that a while back, but it got too cumbersome to manage. It seems far easier to work only with specific subsets, mostly using simple toggles.

I have one of three evasion variants: simple toggle, multiple evasion levels, or an evasion/counter cycle. Accuracy also works as a cycle value, though it doesn't need nearly as much fine-tuning as it did back at 75, so I only have 5 tiers for physical accuracy, 3 tiers for magical accuracy.

Also use the T5 elemental nukes plus Bio III as toggles for types of MDT/PDT sets, which add in elemental resist for the appropriate element, or more straight PDT, as needed. I can't use those as general types for blm or sch, but they don't really need those toggles anyway.

This is an area of improvement I'll look into as upgrades for the XMLs, but the issue I have is that I'm running out of universal trigger spells. With universal triggers, binding keys becomes easier for less experienced users and they gain familiarity with using bound keys (Since they're hitting the same one across all classes). As for more PDT options, I've included a TP-PDT for people using a cleave type set as opposed to BarbedCrescent PDT, which is a full PDT model. This way, when I get to WAR, they can full PDT while gathering mobs and TP-PDT while cleaving without having to change variables.

I see you make use of the BlankSet set (what I call "None" in mine). Very useful tool for variable-based set construction. Still, I see a huge amount of redundancy in setting variables, which could make maintainance annoying. All your trigger commands should, ideally, only ever be setting their own specific variable value; after all code for checking triggers is done, then you compose your final set out of all the individual values.

I would definitely like to look into this. I'm not experienced with coding at all (No training with computers in general; I just read the spellcast stuff and started making XMLs), so I assumed a code like

Spoiler: show

<if spell="X">
<set variable>
<addtochat>Variable for TP Changed</addtochat>
<equip the gear>
</if>

<if spell="Y">
<set variable>
<addtochat>Variable for Idle Changed</addtochat>
<equip the gear>
</if>

would take less CPU power than

Spoiler: show

<if spell="X">
<set variable>
<addtochat>
</if>

<if spell="Y">
<set variable>
<addtochat>
</if>

<if spell="X|Y">
<equip the set>
</if>

If not, then I'll change that once I finish a few more XMLs.

Your staff constants are interesting, but you're missing one set: staff for use when testing procs; minimize damage rather than maximize damage. Also, I'm not sure of the need for multiple individual includes. Seems easier to simply have a single "Staff" include that has all the various variables.

This is another remnant of the old XML. The old one had Elemental Staffs and MagianDMG staffs working off the same variable name, so I had to split them up. I prefer to keep them separate though to avoid minor edits that would require me to edit/upload/post on BG.

Interesting way of working around the weaponskill distance limitation.

I also use an include set for weaponskill gorgets, using piped set names. Since you're setting up custom sets for every weaponskill you wouldn't really encounter this limitation, but it would be important if you have just general weaponskill class groups. Also useful for not having to create a ton of secondary sets within the job xml for jobs that do a lot of procs. And if you use wildcard sets, you don't have about brokenness or error messages just because you didn't set up that particular weaponskill gorget beforehand.

Do you mean like

<var name="Distortion">WS1|WS2|WS3</var> and such?

I see from one of your recent posts that you're aware of building sets with layering as opposed to hand-building each individual set. I find that much easier to use, though there have been a couple times where the layering got over-complicated.

Would also suggest setting an additional action filter around trigger actions. If you're using a weaponskill, there's no reason to have to check every single one of those rules that are based on spells.[/QUOTE]

[Akyrey90]

Shouldn't it be..

<action type="Var" cmd="set TPHands  YOURHANDS" />

Instead of

<var cmd="set TPHands YOURHANDS" />

that didnt fix it :/ i think i used Yugl code for that, and since it works for other stuff, the code should be right in both ways.
i have another question too: i'd want my thf xml to equip TH gears at the start of the fight if i'm wearing tk in sub hand, but no "working ideas". that's what i got,but not doing the trick!
<if EquipSub="Thief's Knife" TargetHPPGT="90">
<equip when="engaged"><hands lock="true">Assassin's Armlets</hands><feet lock="true">Raid. Poulaines +2</feet></equip>
<command>wait 5;Dancing Chains</command>
</if>
would be great if i could use autoexec to detect when i hit the mob, but didnt find any action that can make me check that (didnt even find a targethpplt var in autoexec, that way i could equip th gears > targethpplt="100" > equip normal tp gears, even tho it would only work if i'm soloing and not if somebody already attacked the mob, but that would be a minor problem)

[Motenten]

I also use an include set for weaponskill gorgets, using piped set names. Since you're setting up custom sets for every weaponskill you wouldn't really encounter this limitation, but it would be important if you have just general weaponskill class groups. Also useful for not having to create a ton of secondary sets within the job xml for jobs that do a lot of procs. And if you use wildcard sets, you don't have [to worry] about brokenness or error messages just because you didn't set up that particular weaponskill gorget beforehand.

Do you mean like

<var name="Distortion">WS1|WS2|WS3</var> and such?

A shortened version for an example:

<include name="WeaponskillGorgets">
  <set name="Asuran Fists-Gorget|Evisceration-Gorget|Retribution-Gorget">
    <neck>Soil Gorget</neck>
  </set>
  
  <set name="Tachi: Gekko-Gorget|Tachi: Yukikaze-Gorget|Raging Rush-Gorget">
    <neck>Snow Gorget</neck>
  </set>
  
  <set name="*-Gorget">
    <!-- Empty -->
  </set>
</include>

....

<equip when="Precast" set="$WeaponskillSet|%Spell-Gorget" />

Piped set names are useful when you want to apply the same gear set to a subset of possible variable values, when the total number of possible variable values is large. I only use it for elemental gorgets and belts, but I know someone who also uses it for some moon phase-based gear changes.

I'm not experienced with coding at all (No training with computers in general; I just read the spellcast stuff and started making XMLs), so I assumed a code like [XXX] would take less CPU power than [YYY].

Technically correct, however the difference in CPU usage is miniscule, and generally more than made up for by better maintainability (in my opinion). Your code is already moderately complex, and at the point where being able to isolate and compartmentalize certain bits of functionality makes fixing or adjusting things much easier.

You have a cycle through haste/evasion/accuracy. I tried using that a while back, but it got too cumbersome to manage. It seems far easier to work only with specific subsets, mostly using simple toggles.

I have one of three evasion variants: simple toggle, multiple evasion levels, or an evasion/counter cycle. Accuracy also works as a cycle value, though it doesn't need nearly as much fine-tuning as it did back at 75, so I only have 5 tiers for physical accuracy, 3 tiers for magical accuracy.

Also use the T5 elemental nukes plus Bio III as toggles for types of MDT/PDT sets, which add in elemental resist for the appropriate element, or more straight PDT, as needed. I can't use those as general types for blm or sch, but they don't really need those toggles anyway.

This is an area of improvement I'll look into as upgrades for the XMLs, but the issue I have is that I'm running out of universal trigger spells. With universal triggers, binding keys becomes easier for less experienced users and they gain familiarity with using bound keys (Since they're hitting the same one across all classes). As for more PDT options, I've included a TP-PDT for people using a cleave type set as opposed to BarbedCrescent PDT, which is a full PDT model. This way, when I get to WAR, they can full PDT while gathering mobs and TP-PDT while cleaving without having to change variables.

I can understand what you want to do with universal triggers, and that's a complex little task in itself. Don't really have any easy solutions there.

However, I was thinking more along the lines of: Say I'm in an evasion set for tanking; mob uses spell, I trigger MDT set on; after spell cast I want to turn MDT off and go back to evasion set. With your XML that's not (as easily) possible. Triggering MDT replaces the evasion set. Turning off MDT drops you to standard TP set. So rather than the player having to think, "I don't need MDT anymore, I can turn it off and return to how I was before.", they have to think "I don't need MDT anymore, I need to turn on evasion now."

There are advantages and disadvantages to each approach. The first approach allows you to set a known state and know that any other toggles are modifications to that state. Thus, you don't need to remember what your base state is, only what change you want to make to it. The second approach means you have to always be mindful of what state you want to move into. However you're less likely to end up forgetting to turn off some obscure state (eg: kiting) and continue using it for another hour of fighting.

The other problem is that your approach makes it more difficult to combine states. You already have a huge number of variants for Berserk, accuracy and Footwork. You can pop PDT when needed, but what happens when you need to kite and want to keep PDT on? Or want to add evasion where you can along with PDT while kiting? Or use fire-resist MDT instead of PDT?

Those are the types of scenarios where I feel stacked sets do better than pre-defined combo sets. Not necessarily in the exact optimal gear set per combo (can never really guarantee that, though it will rarely really be an issue), but in being able to add and remove those layers quickly and easily without having to build every single combination from scratch.

[Nemesio]

Spellcast working for some of my spells, but not working for any healing spells. New to the whole thing. To sum it up, it works sometimes, I load/reload over and over and it works here and there. Don't know how to post my Spellcast to a public area so if anyone can sit down and help me out I can do so on Skype~

[cdgreg]

Spellcast working for some of my spells, but not working for any healing spells. New to the whole thing. To sum it up, it works sometimes, I load/reload over and over and it works here and there. Don't know how to post my Spellcast to a public area so if anyone can sit down and help me out I can do so on Skype~

http://pastebin.com/
then post url here.

[Nemesio]

http://pastebin.com/SDunGpkV

[BloomingArsenal]

I edited my previously functional spellcast for BLM/SCH to take advantage of base sets, but it does not seem to use them. For example, I have a refresh set based on a PDT set, but only the gear specifically in the refresh set loads. Similarly, I have a generic elemental damage set based on an INT set, but again, only the elemental damage gear loads, not the INT stuff it should be using in the free slots. The sets trigger at the appropriate time, they just don't use any base sets. The full XML is here if anyone would be kind enough to look:

pastebin: KU86RruM (can't post URL wah~wah)

Are there any rules to using base sets besides having the correct name/spelling? Also, is there a limit to the number of layers you can do? Example: set="Refresh" baseset="PDT", set="PDT" baseset="MDT", set="MDT" baseset="Evasion". Thanks in advance.

[Radec]

I edited my previously functional spellcast for BLM/SCH to take advantage of base sets, but it does not seem to use them. For example, I have a refresh set based on a PDT set, but only the gear specifically in the refresh set loads. Similarly, I have a generic elemental damage set based on an INT set, but again, only the elemental damage gear loads, not the INT stuff it should be using in the free slots. The sets trigger at the appropriate time, they just don't use any base sets. The full XML is here if anyone would be kind enough to look:

pastebin: KU86RruM (can't post URL wah~wah)

Are there any rules to using base sets besides having the correct name/spelling? Also, is there a limit to the number of layers you can do? Example: set="Refresh" baseset="PDT", set="PDT" baseset="MDT", set="MDT" baseset="Evasion". Thanks in advance.

Take out the <slotname></slotname> stuff, that's telling SC to equip nothing in that slot and it overwrites the base set. Can have more layers than you'll ever need.

[BloomingArsenal]

Take out the <slotname></slotname> stuff, that's telling SC to equip nothing in that slot and it overwrites the base set. Can have more layers than you'll ever need.

Ah, brilliant. Thank you so much!

[Yugl]

If you mean full evasion, you're right, but people using TP-Evasion only have to hit their TP macro as usual.

Lets says you have the macros PDT|TP|MDT|FullEvasion

Full evasion isn't intended for TP purposes, but as an "ohshit!" macro. If you're using TP-EVA, hitting TP will automatically set you to TP-EVA if you already set $VARTP (And this will remain the case even if you hit PDT/MDT/FullEvasion; the only way this is not the case is if you rotate to another TP set like Haste).

It's true that you cannot mix PDT upon EVA, but I imagine people will edit their full evasion set to have PDT where evasion is insignificant. Fire resist sets fall into the same category of /sc set FireSet macros that I would recommend since they're temporary sets. I can also add that as an optional rule for users and it will work as an armor set without a problem.

[Motenten]

Ok, won't fuss anymore about that stuff. Going to try rewriting your template and see what things really stand out that I'd change.

Missing CorsairRoll|CorsairShot|Scholar from action type checks for Amnesia check in ReturnRules.
Missing Omerta (Salvage pathos) and Mute from buff checks for Silence ReturnRule, and Impairment for Amnesia rule.

I found Spellcast didn't work well with stnpc targetting for certain actions (can't remember the specifics now), so I added this as a ReturnRule of my own:

        <!-- If using <stnpc> macro, don't try to process til target is chosen. -->
        <if SpellTargetRaw="&lt;st*">
            <return />
        </if>

ElementalObiRule issues:
1) If the player doesn't have the appropriate obi, the Twilight Cape will never be equipped.
2) There is no variable for setting whether the player has the Twilight Cape.
3) Obi will never be equipped for cures since condition includes requirement that target be MONSTER.
4) Obi will be applied even for spells that don't benefit from it (eg: Shock/Rasp/Drown/etc).
5) Obi and Twilight Cape will not be used when appropriate storm buff is present.
6) Twilight Cape is part of rule set, but Zodiac Ring is not.


That covers the include file. Made a few other tweaks, but either not relevant, or not sure how they'll impact things yet. Will look more carefully into the mnk xml later.

[Cymmina]

I found Spellcast didn't work well with stnpc targetting for certain actions (can't remember the specifics now), so I added this as a ReturnRule of my own:

It was a bug with a specific version of SC, it isn't an issure anymore.

[Gustave]

Take out the <slotname></slotname> stuff, that's telling SC to equip nothing in that slot and it overwrites the base set. Can have more layers than you'll ever need.

So are you using you can some thing like this
<set1>
<set2 baseset="set1">
<set3 baseset="set2">

Will set 3 inherit gear from set2 and set1?

    <if spell="Cure|Cure II|Cure III|Cure IV">
      <if buffactive="Magic shield">
        <equip when="precast" set="Cure_Rampart"></equip>
        <equip when="midcast" set="Cure_Rampart"></equip>
        <equip when="aftercast" set="tp"></equip>
      </if>
      <else>
        <action type="midcastdelay" delay="1.5"></action>
        <equip when="Midcast" set="Cure">
        </equip>
        <equip when="aftercast" set="tp"></equip>
      </else>
    </if>

Is the </equip> and </action> needed on the end? My xml is 3 years old and I was using XML Notepad up until a few weeks ago. Also how could I add a rule in for cast on self but not when rampart is active?

Edit: I'm going to try this

    <if spell="Cure|Cure II|Cure III|Cure IV">
      <if buffactive="Magic shield">
        <equip when="precast|midcast" set="Cure_Rampart" />
        <equip when="aftercast" set="tp" />
      </if>
      <else>
        <if targettype="Self">   
         <action type="midcastdelay" delay="1.5" />
         <equip when="Midcast" set="Cure" />
         <equip when="aftercast" set="tp" />
        </if>
        <else>   
         <action type="midcastdelay" delay="1.5" />
         <equip when="Midcast" set="Cure_Me" />
         <equip when="aftercast" set="tp" />
        </else>
      </else>
    </if>

I might not even be close to correct :/