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

[Yugl]

@ Masa: Do you mean when you disengage of when your pet disengages?

Edit: Woah, this was before Motenten's Post

[Yugl]

When looking at the XMLs, remember that they've been more of a continuation rather than a reconstruction. Even though I've done overhauls, they've generally been based on my previous models rather than building from the ground-up (Always a worry for me since I don't want to forget why I did stuff). The main goals in mind were:
- Make a XML for every class
- Make each XMLs progressive even if that meant overloading; new stuff should be integrated into the existing rules rather than requiring completely new rules (Hence, class specific triggers being blank is not an issue for now)
- Make it as easy as "Read the set, know what it does, add your gear, maybe change a few variables, and done"
- Build people's muscle memory by making similar triggers across classes

Trigger selection:
While I applaud what you did coming up with the universal triggers, one continues to annoy me: Raptor Mazurka. This is a subbable spell, and used frequently on blm/brd. It does not seem appropriate to use it as a trigger.

This is amendable, but the reason I used it was because I didn't think BRDs would use it with access to Chocobo Mazurka (Unless another glitch happens) and I didn't think people would sub BRD (Forgot about Abyssea BLMs).

Use of other non-fomor weaponskill triggers in poorly defined groupings also seems sloppy, though more for aesthetic reasons.

I've personally only found the need for three sets of universal triggers: 7 general triggers, 2 unique triggers (reset and equip) and 8 elemental triggers for MDT sets. You've got 13 general triggers and 5 defined job-specific triggers. While I've got more total triggers, half of them are for elemental alignments that you don't account for, so it's more 9 vs 13 (excluding the job-specific ones).

Overall use of triggers:

Trigger type                   Yugl trigger      Mote trigger
Reset                          Dancing Chains    Tranquility
Equip aftercast                Dancing Chains    Dancing Chains
Set distance                   Shackled Fists    Shackled Fists
Physical accuracy:             Grim Halo*        Vulcan Shot*
Magical accuracy:              Grim Halo*        Carnal Nightmare*
Light Armor cycle  (Eva/etc):                    Grim Halo
Light Armor toggle (HP):                         Aegis Schism
Heavy Armor toggle (PDT/MDT):                    Netherspikes
Heavy Armor mode:                                -ga5 for element, Bio 5 for PDT
Kiting (toggle):               Raptor Mazurka    Foxfire
Armor off                      Vulcan Shot
MDT on                         Aegis Schism
PDT on                         Barbed Crescent
Evasion on                     Carnal Nightmare
VAR-TP cycle                   Poison V
VAR-WS cycle                   Poisonga V

* Accuracy is set in a two-mode system in Yugl's, either normal mobs or NMs; in addition, VAR-TP has an accuracy set. In mine, accuracy is on a three-tier system, with physical and magical accuracy treated separately, and the value indicating how much priority to put on accuracy (1 is lowest, 3 is highest).

Could thought be given into revising both which triggers are actually needed, and which triggers to use for which effects?

Before I continue, I'll say that I am willing to take up any debate/compromise on trigger spells, but bare with the fact that I'm going to be slower responding since I actually need to think when responding in those type of discussions and set up ample RL time to do so. If we do have this discussion, we'll want to discuss 1) How many trigger spells 2) Create a master trigger spell list in rank order of likelihood of use 3) Figure out the preferred set up [I'm guess a voting poll here if there are stuff we cannot compromise on, but we'll see; FFXIAH, and Windower forums will suffice? Will be a problem with repeat voters]For now though, I will justify why I've maintained those so far:

1. The reason I set up the accuracy stuff as Regular mobs/NMs (Regular-NMs for magic) is because I wanted a way for people to change all of their sets at once if they're fighting NMs. It's also somewhat more intuitive for people to think "Use X sets against trash mobs and X+1 against NMs" than adjusting the accuracy. At the time, I found that it was easier on the number of sets you needed. For instance, if we ever come to a point where TPing in DEX become relevant like when WARs used rune choppers, you may wish to use that set against some mobs, but not other mobs; hence, a universal TP set is not acceptable in my opinion. If you're using a rotation of VAR-TP for stuff like DEX/PDT, these seem mutually exclusive with the notion of an ACC set. Thus, I would have multiple "wasted" sets such as TP-GAXE-DEX-ACC3. After looking at your XML, it appears as if you get around this problem using *? I anticipate that the * substitutes for any called upon set, which means I can do TP-DEX-* to cover any ACC1-3 called upon? Knowledge of * within sets makes stuff possible.

2. I prefer TPorIdle/PDT/MDT on rather than toggle because of my muscle pattern from playing on PS2, which dictates that I smash my macros as much as possible. Also, if I hit the macro and I don't change to PDT completely (Lag or w/e throws off the set), I can hit the button again while mobs are on me and not worry about them getting a few non-PDT hits. A "Blank armor" button is useful because 1) On RDM, I can change back to idle set immediately, which means the extra delay post-cast is negligible 2) Sets such as Breath and Convert are structured so that an HP or MP set overlays your non-Armor gear. In cases where I'm done curing myself and I want to return to normal idle gear, I only need to hit the "Blank Armor" button and I'm instantly back to idle.

3. I can see SE giving out Aga V in the future. Even though 99 is approaching and we have yet to see aga IV spells, it would be difficult for SE to suddenly stop spell progression. Compare to Poison V (PII atm), Poisonga V (PsgaI atm), and Diaga V (Diaga I atm). Also, unless people use a g15 KB, they will have to type in the element they wish to resist. Perhaps a single toggle for element resist?

4. I remember you said you use HP set for stuff like recovery, but it's not clear why evasion wouldn't be mutually exclusive with stuff like PDT and MDT unless it's applicable to TP as well. In that case, it reasonable, though I worry whether that will make other gear handles awkward. For example, if I change to more EVA for my TP-Haste set, I might need to make up for haste in other slots. This would mean I need to include haste in slots I normally wouldn't. The issue then is if I get a set that comes between TP|VARTP and LightArmor|HeavyArmor. For example, I would want a convert or breath set to come after the TP|VARTP stuff, but I wouldn't necessarily want it before LightArmor if I'm just using LightArmor for TPing in evasion. I would, however, want those sets prior to LightArmor if I'm using FullEvasion to avoid a sudden TP move. There's also the alacrity at which I can change to full evasion to avoid a TP move. That then leaves a medium EVA absent, which can be covered via class-specific triggers as toggles on the TP-EVA set.

Trigger rules:
With all the work to build up these universal trigger sets, it seems completely wasted by forcing each job xml to define their behavior. Poison V, for example, cycles through VARTP options, however the entire rule has to be written within each job xml. Why was it not incorporated into a general include? Same for pretty much every trigger spell.

In addition, that means there's no guarantee of consistancy between job xmls for the same trigger action, which undermines the value of having universal triggers. For example, mnk defines Scop's Operetta for Utsusemi casting mode; however Scop's is part of TriggerSetTwo, not the expected TriggerSetThree (assuming set 3 is for job-specific triggers).

There are universal triggers for my non-rotational trigger spells, but I don't use them if I need additional stuff from them. For instance, I needed trigger spells to override and cancel breath sets on BLU. The stuff like Poison V/Poisonga V use different options since each class uses different sets. For instance, BLU doesn't need much beyond a DEX/ACC set if they use the R/NM function (Means 4 total WS sets available for them to use per WS).

Trigger1/2/3 were quick and retroactive fixes that I made.

Initial BLU XML: Used non-universal BLM-V spells; forgot to make the return rule ignore them => added them in midplay without listing them within the variables section
Next fix: Made a variable set set for them, but split them up since the list was too much for one variable (Easier for me to look through them when they're broken up)
Next fix: Universal spells using the same variable name

When I did the third fix, I made the listings the following way:
"Settings" modification (Like WS Distance) and One-hit triggers => Trigger set 1
Universal toggles => Trigger set 2
Class specific toggles => Trigger set 3

Trigger 1 = "Settings" and One-hit triggers
Trigger 2 = Universal rotations
Trigger 3 = Class specific triggers

I didn't label them as such since it's easy for me to remember the numbers and I didn't anticipate others needing to edit that. Trigger 3 need to be defined so that the return rule doesn't hit them. Keeping them separate gives me options in the future. For example, if I want to use a specific set of trigger spells for a rule, I can move them to trigger set 1 without damaging other stuff. However, if I labeled them specifically, that could end up being confusing or requiring me to rework the XML.

Variable location:
A large number of your general variables are defined in each job xml rather than being defined in the Include that actually uses them. Since a number of things in the Include won't work without those variables being defined, it doesn't make sense not to include them.

Mine: All variables that are used by the Include are defined in the Include. Job xmls can override the default values if needed, and define their own variables for use solely within that job xml.

Example instance: Delay-Spell is defined in the drg.xml (but not in any other xml), but only used in the include.xml. Lack of locality of definition is problematic for understanding.

I place them within the main XML because 1) They may need to vary from class to class 2) I use a pre-made template when making XMLs, so they're already included 3) If I'm going to let one class override variables, I might as well just include the variable within all XMLs. DRG should have used the variable within the main XML, but due to the structure, I needed to port the same rule across different areas, so I made an include. DelaySpell should be defined in other XMLs.

Elseif Includes:
A number of your includes are defined as <elseif> blocks. That implies an inherent order of processing, which means that those includes have to be entered in a certain order. Entering an <if> include between the <elseif> includes can mess up the logic. While you can force it to work, it seems to go against the spirit of the initial design.

More generally, this seems to be an issue of overly-specific includes. You have an include for a PDT toggle, an MDT toggle, an Evasion toggle, etc, etc. What's important about all those is that they're all based on the universal toggles.

A number of includes are <elseif> due to the lag crisis from earlier and since they work logically, it seemed fine to leave them as such. Since trigger spells are either one or the other, it means the system just checks <elseif> all the way rather than a huge string of <if> statements. It's also uncertain whether changing all <elseif> will affect system performance.

Overly-specific includes:
To expand on the above, you have an include for locking the main weapon, and a separate include for locking Powder Boots. For general purposes, it would seem to be better to encompass all lock rules in a single include.

Again, this was done to avoid overusing <if> statements since initial belief was that <if> caused the lag in most XMLs. It seems unnecessary to add this rule for classes that cannot use Powder boots, for example. Also, remember that I'm working in a manner that would allow me to easily change stuff I need. So if, for example, I need to remove an include or adding a portion of an include to another section of the XML, I would rather have the include be its own rule so I don't need to pluck out the section I need, rewrite the name, and add the include to all the other XMLs.

Obi Rules:
I *know* we went over the changes necessary for obis/Zodiac Ring/Twilight Cape, and we ended up with a fairly comprehensive and flexible system. However none of that is in your include. Is it not updating, or did you never add it?

Yeah, I've been meaning to PM about that since I recall being close to finishing, but then having one issue leftover, which was the BLU rule. I asked on the BLU forums a while back, but because they hate me, they didn't respond, so I eventually forgot about the obi rule. I was in a hurry to make a new BLU XML, so I put off the Obi stuff until I began working on the RDM XMLv3. Atm though, I'm also working on a universal fast cast rule along the following lines:

<var setcalc TotalCTR(1-[FCTrait+FCGear])*(1-[BookTrait+BookGear])*(1-%ElementCTR)*(1-%SkillCTR)/>

[Motenten]

Addressing some individual points before getting to the triggers.

Before I continue, I'll say that I am willing to take up any debate/compromise on trigger spells, but bare with the fact that I'm going to be slower responding since I actually need to think when responding in those type of discussions and set up ample RL time to do so.

Completely understandable. This is a fairly substantial body of work, and takes a while to work through.

Make each XMLs progressive even if that meant overloading; new stuff should be integrated into the existing rules rather than requiring completely new rules (Hence, class specific triggers being blank is not an issue for now)

From an object-oriented point of view (the basic principals of which you're using (as opposed to a compositional model, though there are similarities to that as well); you're essentially creating an inherentance structure from the Include file to the individual job xmls), you're kind of going about it backwards. You want the parent class (the Include) to define the default way that all subclasses (job xmls) behave. The job xmls -may- override that behavior, but ideally it should not be necessary. Any unique behavior in the job xmls, however, should be completely independant of the Include.

The class-specific triggers don't need to fall within the guidelines of the 'universal' triggers. If I use Footwork as a job-specific trigger on pld, no other xml has to know about it, and its existance won't break anything in the Include (as long as it's defined in a known job-specific triggers variable that you can use in your ReturnRules, etc). I don't *need* Scop's Operetta handed to me as someplace I can define extra behavior. It's redundant and useless.

I didn't label them as such since it's easy for me to remember the numbers and I didn't anticipate others needing to edit that. Trigger 3 need to be defined so that the return rule doesn't hit them. Keeping them separate gives me options in the future. For example, if I want to use a specific set of trigger spells for a rule, I can move them to trigger set 1 without damaging other stuff. However, if I labeled them specifically, that could end up being confusing or requiring me to rework the XML.

This doesn't make any sense. How is renaming TriggerSetOne as SettingsTriggers or TriggerSetTwo as UniversalRotations something that could be -more- confusing than it already is? (well, ok, UniversalRotations doesn't make a lot of sense either...)

The basic idea that you state, that you can add new triggers to these sets and still use them as 'group' values, is perfectly valid and reasonable. However if it breaks anything, that's more of an indication that the groupings weren't well-defined or properly segmented in the first place. And, as I mentioned above, there should be no need for you to define 'global' job-specific triggers. The fact that they're job-specific means that they *aren't* global.

Also, it may be easy for you to remember, but anyone else reading your code will have absolutely no clue what those groupings are for, which makes it far more difficult for them to properly modify it for their own needs.

I place them within the main XML because 1) They may need to vary from class to class 2) I use a pre-made template when making XMLs, so they're already included 3) If I'm going to let one class override variables, I might as well just include the variable within all XMLs. DRG should have used the variable within the main XML, but due to the structure, I needed to port the same rule across different areas, so I made an include. DelaySpell should be defined in other XMLs.

1) Those that need to vary can be redefined within each class xml on a case-by-case basis. The vast majority shouldn't need to be individually modified, and makes it far more difficult to make 'global' changes. For example, if you want to change the default distance value for weaponskills, you have to modify every single job xml separately, rather than just changing it in one place and having it apply to all jobs.

2) The premade template can simply have an <xi:include> entry in the var list and have exactly the same functionality.

3) That is absolutely horrible logic. You place the global variable in the Include so that all class xmls have access to the same value. Just because you may need to override the value in one class xml, it does not mean that every single xml needs to have their own copy of that same variable.

A number of includes are <elseif> due to the lag crisis from earlier and since they work logically, it seemed fine to leave them as such. Since trigger spells are either one or the other, it means the system just checks <elseif> all the way rather than a huge string of <if> statements. It's also uncertain whether changing all <elseif> will affect system performance.

If it still contributes to a performance issue, sure, leave as is. However the structure is brittle.

Again, this was done to avoid overusing <if> statements since initial belief was that <if> caused the lag in most XMLs.

Indeed, however we now know better. <If> checks are (relatively speaking) extremely fast. It's the <set> extraction and combination that's slow.

So if, for example, I need to remove an include or adding a portion of an include to another section of the XML, I would rather have the include be its own rule so I don't need to pluck out the section I need, rewrite the name, and add the include to all the other XMLs.

That brittleness I mentioned? It's this kind of action that can cause things to break. Not for this particular chunk of code (both use simple <if> checks), but for the others that use the <elseif>s.

[Motenten]

~ On the idea of a trigger consolidation

First, quick listing of available triggers:

No risk:
Fomor weaponskills: Shackled Fists, Vulcan Shot, Carnal Nightmare, Grim Halo, Aegis Schism, Netherspikes, Foxfire, Barbed Crescent, Dancing Chains

Low risk (I really can't see SE giving out -ga5s without even having -ga4s at this time):
-ga 5 spells: Stonega V, Waterga V, Aeroga V, Firaga V, Blizzaga V, Thundaga V, Banishga V, Poisonga V, Diaga V
Tier 5 spells: Bio V, Dia V, Poison V, Banish V

Unlikely to be used spells:
Brd songs: Scop's Operetta, Puppet's Operetta, Herb Pastoral, Shining Fantasia, Goblin Gavotte
Merit JAs: Tranquility


There are 9 fomor weaponskills, which gives us a fairly good base to work from. The tier 5 stuff gives us elemental specification (7 spells) along with 6 other spells that players are unlikely to ever receive. The brd songs are an option, but seem somewhat excessive given that we already have 15 other options (not counting elemental -gas), and should probably be considered as a last resort.

Tranquility is the only one with a slight bit of risk, but I still very much prefer it for a general reset trigger, and any sch xml can redefine it without breaking anything easily enough.


Now for actual trigger actions. Would like to keep it to about 14 or less (excluding elementals). Will see.

2 basics:
Reset - Force recalculate sets, reexamine status flags, and equip appropriate gear.
Equip - Trigger for delayed aftercast calculations to reduce lag. Smaller scope of action than Reset because this should be as fast as possible.

2 Utility
Set Distance - Simple one, doesn't need much adjustment.
Kiting - Force +move gear to be equipped.


Armor sets: Evasion/PDT/MDT/etc

Technically, there's no reason you can't have a given trigger set to work both as a toggle and a hard switch. Just set a flag that determines whether a given trigger can also turn things "off" (best handled 'universally' from the main Include's var list). You could have, for example:

    <var name="SwitchType">HardSwitch</var>
    <var name="SwitchType">Toggle</var>

    <elseif spell="Aegis Schism">
        <if advanced='"$LightArmor" = "$SetLightArmorHP"'>
            <if  advanced='"$SwitchType"="Toggle"'>
                <var cmd="set LightArmor None" />
            </if>
        </if>
        <else>
            <var cmd="set LightArmor $SetLightArmorHP" />
        </else>

        <addtochat>Light Armor: $LightArmor</addtochat>
    </elseif>

If $SwitchType is set to HardSwitch, you can turn HP armor on, but never turn it off with that trigger. The only thing this requires is one additional trigger specifically for turning the various switches off.

I will grant that mode switching between PDT and MDT is cumbersome. I mainly did it to conserve macro space. However for practical purposes, it's probably best to use separate switches for each.


The Light Armor options, however, are trickier to reconcile. I set up two configurable sets (eg: Thf gets a light evasion and a full evasion; mnk gets evasion and counter; pld gets shield; etc). That inherently means a cycle switch; otherwise you have to set the mode separately from turning it on or off. Of course you also have a switch in your mnk xml for using either an evasion base or a counter base when casting utsusemi. It would also be more convenient for quickly changing in and out of that gear. Hmm. Will include that way for now.

4. I remember you said you use HP set for stuff like recovery, but it's not clear why evasion wouldn't be mutually exclusive with stuff like PDT and MDT unless it's applicable to TP as well. In that case, it reasonable, though I worry whether that will make other gear handles awkward. For example, if I change to more EVA for my TP-Haste set, I might need to make up for haste in other slots. This would mean I need to include haste in slots I normally wouldn't. The issue then is if I get a set that comes between TP|VARTP and LightArmor|HeavyArmor. For example, I would want a convert or breath set to come after the TP|VARTP stuff, but I wouldn't necessarily want it before LightArmor if I'm just using LightArmor for TPing in evasion. I would, however, want those sets prior to LightArmor if I'm using FullEvasion to avoid a sudden TP move. There's also the alacrity at which I can change to full evasion to avoid a TP move. That then leaves a medium EVA absent, which can be covered via class-specific triggers as toggles on the TP-EVA set.

I think this is just going to have to be an implementation difference.


Really not sure if there's a way to reconcile how accuracy is handled. Mine uses levels applied to sets, yours is applied to groups, so the two implementations are going to be markedly different. I could see the point in arguing for a single accuracy type rather than split between physical and magical, though.

Mnk won't care what the magical accuracy is; blm won't care what the physical accuracy is; blu's spell accuracy is dependant on physical accuracy, and anything that requires higher magical accuracy likely requires higher physical accuracy, and vice-versa. Whm may want high physical accuracy even if they don't need high magical accuracy, but they're unlikely to have highly convoluted melee sets anyway; a single melee set could sync with all magic accuracies.

Overall, yeah, may as well merge it into a single switch.



TP set cycles. You say you set different rules in each xml to cover the different sets each job used. I would propose that it would be better to define the sets as variables that you have the option of cycling through, which allows you to leave the generic manipulations in the main Include file. Example:

~in the include.xml and job.xml file (override default Include.xml values):

<var name="TPSetCount">5</var>
<var name="TPSet1">Haste</var>
<var name="TPSet2">Acc</var>
<var name="TPSet3">PDT</var>
<var name="TPSet4">Eva</var>
<var name="TPSet5">Dex</var>
<var name="TPSetNumber">1</var>

~in the Include.xml file:

<if Spell="$TPCycleTrigger">
    <var cmd="setcalc TPSetNumber $TPSetNumber+1" />
    <if advanced='$TPSetNumber &gt; $TPSetCount'>
        <var cmd="set TPSetNumber 1" />
    </if>

    <var cmd="set VAR-TP $TPSet$TPSetNumber" />

    <addtochat>TP Set: $VAR-TP</addtochat>
</if>

(And for Byrth wanting a reverse cycle, just copy/paste to another rule but use -1 instead of +1 for whatever the other trigger is.)


List so far, with preliminary triggers:

Reset                                Tranquility
Equip                                Dancing Chains
Set Distance                         Shackled Fists
Kiting                               Foxfire
PDT Switch                           Netherspikes
MDT Switch                           Aegis Schism
Light Armor Type                     Carnal Nightmare
Light Armor Switch                   Grim Halo
Kill Switch (all armor turned off)   Barbed Crescent
AccLevel                             Vulcan Shot
VAR-TP                               Poison V
VAR-WS                               Poisonga V

Ran out of fomor weaponskills and had to start adding spells. 12 global triggers so far.

[Masamune]

@ Masa: Do you mean when you disengage of when your pet disengages?

When I disengage while my pet is still fighting, the rule <if petisvalid=true AND isincombat=1> fails to keep the var PetStatus=PetEngaged.
i forgot to test what were the value of isincombat once disengaged but pet still fighting.

[Miltani]

let say when i switch to a job, i want my macro set to switch to the specific job. Is this possible with spellcast?

[Masamune]

let say when i switch to a job, i want my macro set to switch to the specific job. Is this possible with spellcast?

With Spellcast yes but impractical.

A correct answer would be to use Autoexec, since you select the correct macro palette only once when job changeing @ moghouse.
If you had to put such rule in a spellcast xml, it would process at every action which is unnecessary... and hit performance.

I'm at work, do some search for common autoexec rules using event="jobchange_*".

[Syco]

When I disengage while my pet is still fighting, the rule <if petisvalid=true AND isincombat=1> fails to keep the var PetStatus=PetEngaged.
i forgot to test what were the value of isincombat once disengaged but pet still fighting.

This might be where my idea of casting a trigger on your pet, pulling pet's %IsInCombat into a variable and checking against that might work better - I know when I disengaged but pet kept fighting I switched to IdlePetEngaged.

I didn't get any time to play last night but if I can tonight I'll play about with the new ideas and see if I can wrangle something nice and simple together.



Edit: Yugl and Mote, I'm very excited about this attempt at Include-coherence - I appreciate (both of) your work, and I'm glad you're realising it would definitely be a help to the non-programmers in the community if things were defined with more clarity. I've several years' experience (from machine code all the way up), yet understanding what some variables/rules were doing took some serious digging!
If you need anyone to make suggestions, logic test, adjudicate, conglomerate or anything else, let me know and I'll do whatever I can. Much love <3

[Yugl]

A more detailed response at another time (I'm out until ~6PM, so no responses until then at minimum), but I would like to get some points clarified:
- What is the effect of using * in sets? Can I do equip set="CardFire" and have a set named "Card*" that will be equipped? If I have a set named "Cardfire" as well, which will be equipped?
- You talk about overriding includes, but I don't know what that means. I learned about includes using Techno's XML, so I have no details on what that entails
- A reminder about accuracy levels in general is that the change between regular mobs and HNMs does not necessarily mean a change in accuracy, which is why I made TP-ACC and stuff like QuickResist (See RDM for example); for example, someone (Foldypaws?) found that THF AF3+2 was better than Loki's against HNMs, but not trash mobs due to sTP/reduced pDIF significance. Thus, pDIF is another concern when relating from regular mobs to HNMs
- If SE adds Aga IV scrolls after 99 and then adds AgaV (Merits afterwards), it's not impossible for them to implement them; the benefit of BRD spells is that we know that they're available (And for one of those songs, I specifically remember finding a tier II version of that song, so that's even more assuring), what they do, and that they're useless
- If we're going to use Tranquility, I don't see how Equanimity is problematic
- Explain the difference between a reset trigger and aftercast trigger?

Edit: Also, BLU will need more than 12 triggers for certain; remember that we will ideally want blank triggers for future content or tricks

[Masamune]

Well, risking to sound repetitive, i tested the code below :

	<if PetIsValid="True" Advanced='"$%IsInCombat"="1"'>
		<var cmd="set PetStatus PetEngaged"/>
	</if>
	<else> <var cmd="set PetStatus PetIdle"/> </else>

the var %IsInCombat stays =1 when i disengage while my pet is still fighting the mob, but for some reason i don't understand at all, PetStatus goes from "PetEngaged" to "PetIdle"...

I rechecked multiple times engageing-disengageing + typing %IsInCombat, while my pet fighting, i always got IsInCombat=1 properly, but WHYTF my spellcast rule don't process ???

Is there a typo?

EDIT: OMFG!!! i found the typo, don't use the dollar symbol in advanced.... $%IsInCombat don't work, but %IsInCombat works !!

EDIT2: now the only case not working as intended, is when i'm idling eating popcorn while watching my pet..... until my pet kills the mob: i stay in IdlePetEngaged set if i don't do an action... so not really a bug since there is no "autoset" for pet, but i have to do an action if my pet kills mob and i'm idle.

Thanks to Syco for turning my attention to this var %IsInCombat

[Sup3rB4d]

Someone mentioned a couple of pages back that he fixed this, but he didn't say what he did... Can anyone tell me what I need to do to make this work?

        <if type="Waltz">
            <CastDelay Delay="0.05" />
            <AfterCastDelay Delay="0.5" />
 
            <if NotSpell="Healing Waltz">
                <if TPAfterCastLT="0" NotBuffActive="Trance">
                    <!-- Insufficient TP to use waltz.  Downgrade to the best waltz possible. -->
                    <!-- Costs:
                        Curing Waltz:     20 TP
                        Curing Waltz II:  35 TP
                        Curing Waltz III: 50 TP
                        Curing Waltz IV:  65 TP
                        Curing Waltz V:   80 TP
                        Divine Waltz:     40 TP
                        Divine Waltz II:  80 TP
                   -->
                   
                    <if Spell="Curing*">
                        <if TPLT="20">
                            <addtochat>Insufficient TP [%TP]. Cancelling</addtochat>
                            <cancelspell />
                            <return />
                        </if>
                        <elseif TPLT="35">
                            <changespell Spell="Curing Waltz" />
                        </elseif>
                        <elseif TPLT="50">
                            <changespell Spell="Curing Waltz II" />
                        </elseif>
                        <elseif TPLT="65">
                            <changespell Spell="Curing Waltz III" />
                        </elseif>
                        <else>
                            <changespell Spell="Curing Waltz IV" />
                        </else>
                    </if>
                    <else>
                        <!-- Only one downgrade for Divine Waltzes -->
                        <if TPLT="40">
                            <addtochat>Insufficient TP [%TP]. Cancelling</addtochat>
                            <cancelspell />
                            <return />
                        </if>
                        <else>
                            <changespell Spell="Divine Waltz" />
                        </else>
                    </else>
                   
                    <addtochat>Insufficient TP [%TP]. Downgrading to %Spell</addtochat>
                </if>
 
                <equip when="Precast" set="Waltz" />
            </if>
        </if>

[Syco]

Someone mentioned a couple of pages back that he fixed this, but he didn't say what he did... Can anyone tell me what I need to do to make this work?

        Waltz spell change stuff

That was me. I'll post it when I get a minute tonight.

[Motenten]

That was me. I'll post it when I get a minute tonight.

Syco also 'fixed' the previous version. Since Syco brought it up, I decided to go ahead and rewrite my own version to handle things a bit more gracefully, which is the code that Arigorn posted.

[Masamune]

mmm actually i still have pb with my bst xml and disengageing a mob...

During my tests i noticed the "action" to engage or disengage or resting is NOT an action that will make a reparsing of the xml...

Is there a way to do so ? i rmember something like "autoset" but i don't remember, or is it something else?

[Syco]

Syco also 'fixed' the previous version. Since Syco brought it up, I decided to go ahead and rewrite my own version to handle things a bit more gracefully, which is the code that Arigorn posted.

Yeah, sorry Mote, I didn't read the code Arigorn posted and assumed it was the old version.
Arigorn, that code you posted looks like it should work as-is.

@Masa - take another look at the code I posted: if you stick a dummy spell call at the end of your If PetEngaged = true rule, and make another rule to cancel the dummy spell as soon as it fires, SpellCast will constantly cycle while your pet's fighting then when it kills the mob your gear'll automatically change.

[Masamune]

Take another look at the code I posted: if you stick a dummy spell call at the end of your If PetEngaged = true rule, and make another rule to cancel the dummy spell as soon as it fires, SpellCast will constantly cycle while your pet's fighting then when it kills the mob your gear'll automatically change.

yea i think i understood the general idea of your code, it's just i dislike constant cycling... got so much probs with that in the past... ie i'm traumatised lol.
so i'm just trying to find a simple way to do it avoiding that.

... hence my question about autoset or something like that ? to make disengageing considered like a real action like if it were Fight or Cure.

[Syco]

I've literally no clue about doing that through spellcast.

Maybe autoexec, but the only thing that would work there would be triggering a spell by something like

<register id="23443" event="gainexp_*">Blizzaga V</register>

with a spellcast rule to auto-cancel Blizzaga V. Your other rules should manage the rest.

This obviously won't work if you don't get EXP from killing the mob.

[Motenten]

@Masa: Check for <if spell="autoset"> for that. The only restriction is that <addtochat> won't output anything (probably for sanity's sake) if it's an autoset call. It *does* reparse the xml code, though.

I treat it the same as a call to my $ResetTrigger in most xmls, but my thf xml handles it separately in order to handle equipping TH gear on engage.

[Motenten]

A more detailed response at another time (I'm out until ~6PM, so no responses until then at minimum), but I would like to get some points clarified:

Sure.

- What is the effect of using * in sets? Can I do equip set="CardFire" and have a set named "Card*" that will be equipped? If I have a set named "Cardfire" as well, which will be equipped?

The name="Name" section of a <set> definition can have aliases included. For example, the "Kite|Move" set, Move is considered an alias of Kite, and either one will refer to that set. Using * in a set name allows for a full wildcard alias. "TP-Club-Acc*" will be used for any set that starts with "TP-Club-Acc", so I can use any accuracy value whatsoever and get that set.

"Card*" as a set name will indeed trap for any set such as "CardFire". If there are multiple sets that could possibly satisfy the set name conditions, such as also having a "Cardfire" set, the first one in the set list will be used (remember, it's searched sequentially).

- You talk about overriding includes, but I don't know what that means. I learned about includes using Techno's XML, so I have no details on what that entails

In my Mote-Include.xml, I have the following variables:
<var name="SetLightArmor1">None</var>
<var name="SetLightArmor2">None</var>

They are part of an include that's imported into each job xml with the line:
<xi:include href="Mote-Include.xml" xpointer="//include[@name='UtilityVars']/*" />

So, by default, every job has those two variables with values set to "None".

In my mnk include, I then redefine those variables after the include:
<var name="SetLightArmor1">Evasion</var>
<var name="SetLightArmor2">Counter</var>

So now whenever they are referenced (whether in the mnk.xml or any code imported from the include.xml), those are the values that are used.

In my pld xml, I only redefine one of them:
<var name="SetLightArmor1">Shield</var>

So now whenever SetLightArmor1 is used, it has the value of "Shield", while whenever SetLightArmor2 is used it still has the value of "None".

And in my blm xml I don't have to redefine those values at all, so they're just not listed in the job xml. However since they're included in the variable import, it won't break anything if I hit the keybind that swaps light armor types.

- A reminder about accuracy levels in general is that the change between regular mobs and HNMs does not necessarily mean a change in accuracy,

Indeed, which is why I made things as straight numeric accuracy tiers. There are some normal mobs that are extremely evasive (eg: Mamool Ja Lurkers back in the day), while there are also NMs that you don't need any extra accuracy gear for at all. Conceptually, the "NM" vs "not an NM" breakdown doesn't match what you really want to do: use more accuracy or magic accuracy gear in place of power or potency.

which is why I made TP-ACC and stuff like QuickResist (See RDM for example); for example, someone (Foldypaws?) found that THF AF3+2 was better than Loki's against HNMs, but not trash mobs due to sTP/reduced pDIF significance. Thus, pDIF is another concern when relating from regular mobs to HNMs

This introduces yet another axis -- attack vs mob defense (ie: cRatio), and in a way is a superset of things like Berserk up vs Berserk down. Unfortunately there's no spellcast variables for attack... Oh well. Interesting, if brief, idea.

Still, I see what you're saying. You have two axes: NM vs non-NM, and various TP modes which may possibly include additional +acc gear. NM mode doesn't necessarily mean you need more accuracy, but you may make choices such as using something besides a Rancor Collar, and get a decent mix of accuracy and attack instead of nothing but pure attack.

Mine, on the other hand, only deals with a single axis -- how much to focus on accuracy compared to "everything else".

This, I think, needs a lot more thought. Conceptually, this is one of the most fundamental aspects of how we're building sets. I'll leave this as an open question for now.

- If SE adds Aga IV scrolls after 99 and then adds AgaV (Merits afterwards), it's not impossible for them to implement them; the benefit of BRD spells is that we know that they're available (And for one of those songs, I specifically remember finding a tier II version of that song, so that's even more assuring), what they do, and that they're useless

It just seems incredibly unlikely to me. We didn't move from tier 3 -gas to tier 4, we went from tier 3 to -jas. I could *maybe* see adding tier 4 -gas as merit spells (though that gets into the whole debate about adding spells as merits), but tier 5...? Consider the scale of power increase that would entail, and just how ludicrously overpowered that would make blms...

- If we're going to use Tranquility, I don't see how Equanimity is problematic

It probably isn't, but I only wanted one of them, and took the one less likely to be used. It's a lot easier to get -enm gear for Light Arts spells and still get most or all effectiveness than it is to get -enm for Dark Arts spells and still be fully effective, so a sch would be less likely to get the -enm Light Arts strategem than the -enm Dark Arts strategem. I've also seen Equanimity discussed for its (minimal) uses, but Tranquility is pretty much never talked about.

- Explain the difference between a reset trigger and aftercast trigger?

The aftercast trigger does exactly one thing: equip the currently defined idle or tp set. In my xmls, it's the very first imported rule, and if it's used it immediately exits out; it does not do any calculations whatsoever.

The reset trigger has the option of doing a lot more. For example, in mine, area checks (ie: Abyssea, Campaign, town, elsewhere) that determine which group to use are in the reset section; the thf TH equip calculations are handled via calls to the reset trigger; changing attack modes (H2H, club, staff, etc) are re-checked; etc. These are things you want to be able to have checked on the fly, but don't want to be calculated on every single action call.

Edit: Also, BLU will need more than 12 triggers for certain; remember that we will ideally want blank triggers for future content or tricks

That's where job-specific triggers come into play. Blu has special needs and can define a whole host of triggers from JAs it won't use (eg: Footwork, Sengikori, No Foot Rise, etc; pretty much any over-50 JA by any other class, plus tons of spells), that could potentially conflict with other jobs that use the include XML if they are included at the global level.

The imortant point is, *it doesn't matter*. It doesn't need to use universal triggers for its job-specific needs. That's the entire point of being able to define job-specific triggers. Universal triggers are explicitly for doing the same thing for all the jobs that use them.

[Masamune]

@Masa: Check for <if spell="autoset"> for that. The only restriction is that <addtochat> won't output anything (probably for sanity's sake) if it's an autoset call. It *does* reparse the xml code, though.

I treat it the same as a call to my $ResetTrigger in most xmls, but my thf xml handles it separately in order to handle equipping TH gear on engage.

I don't get it, where do i put this rule <if spell=autoset> ?
currently, i know my xml is NOT parsed when i disengage (either manually or from killing mob), resulting in variables not changing appropriately (ie staying same value they had before disengageing)
so does this rule make spellcast reparse only whatever is inside the <if></if> ? or whole xml? in that last case the rule position doesnot matter right ?

Good idea Syco with autoexec i'll keep it in mind thanks.

Here is what i have come up so far:

	<if Status="engaged">
        <equip When="precast|engaged|aftercast" Set="Engaged"/>
    </if>
    <elseif Status="Idle">
		<addtochat Color="206">Idle status</addtochat>
		<if PetIsValid"="True" Advanced='"%IsInCombat"="1" OR "%Spell"="Fight" OR "%Spell"="Heel" OR "%Spell"="autoset"'>
			<var cmd="set PetStatus PetEngaged"/>
		</if>
		<else> <var cmd="set PetStatus PetIdle"/> </else>
		<equip When="Idle|engaged|aftercast" Set="Idle$PetStatus"/>
    </elseif>
    <elseif Status="Resting">
        <equip When="Resting" Set="Resting"/>
    </elseif>

PetStatus var changes properly when i send pet on mob, but it doesnot "reset" properly when i disengages from that mob (either manually or from killing)