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

[Kyte]

I'm getting a "Parsing Error: line 0- Error reading element value" while trying to use the SMN spellcast posted on this page. I'm fairly new to using spellcast, so I have no idea what that means exactly. I'm guessing it's something really simple- can anyone tell me what I might have done wrong?

[Phoenyx]

I'm getting a "Parsing Error: line 0- Error reading element value" while trying to use the SMN spellcast posted on this page. I'm fairly new to using spellcast, so I have no idea what that means exactly. I'm guessing it's something really simple- can anyone tell me what I might have done wrong?

Make sure you have both the SMNinclude.xml -and- the include.xml in the Spellcast folder. His SMN .xml has calls to both includes.

[Kyte]

I do have both of those includes in the folder, so I don't think that is the issue.

[Motenten]

@Byrth:

On the submodes: Yes, they're not all always relevant to everyone. What I've done (for the defensive side, at least) is set up two vars: HasShield and HasCounter. By default those are No, so you won't even see them in the cycle. Mnk, however, will have Counter, and pld will have Shield, so they can set those vars to Yes to have them show up.

Capped attack comes up often enough in build discussions that it seems reasonable to have a set built specifically for that, even if some jobs are less likely to reach it than others (drk and war? highly likely; dnc and thf? not so much). Crit/dex is a specialty build that probably shouldn't be part of the defaults. I was reminded last night of the possibility of a capped crit rate (or dmg?) build for war using Blood Rage, but that's more of a temporary flag than a set. Your idea for a capped delay reduction build for dnc (or nin) is another specialty set.

Basically, those are more 'custom' builds than standard ones, and should probably be purely optional. I'll probably create something like CustomMelee1 and CustomMelee2 for them.


As for the second accuracy tier, the way I originally approached it (not the current design description) was that I could generally tell if I was at or near capped accuracy by eyeballing (I couldn't tell you if I was at 75% or 85%, but I could tell you it wasn't capped), so my gague was "am I capped yet or not?". I then had 7(!) tiers of progressively more accuracy that I could upgrade into until I felt solidly comfortable. Over time most of the options that were "either damage or accuracy" have merged into gear options that are "damage -and- accuracy" (not to mention just fewer evasive mobs in general), so there's less value in multiple tiers.

The primary reason to maintain 3 tiers is to allow for dynamic adjustments. For example, if I have Focus (or Aggressor from /war) up on mnk, I want to drop a tier of accuracy. However there are also mobs for which it doesn't matter how much I buff my accuracy, I'm still going to be whiffing. For those, I want to keep max accuracy gear on even if I have other acc buffs. The easiest way to handle that is to have a third tier setting which basically states, "don't drop back to lower accuracy tier gear sets regardless of what buffs are in place."

Evasion Tiers? Okay, but I kind of already do that. There's the hybrid evasion set (Evasion TP) and FullEvasion. Anything more specific than that is beyond my ability to eyeball, which is really the limiting factor here. By the time I'd have collected a significant sample size with a parser, I'd have already died or swapping gear wouldn't matter because I can obviously survive quite a while without it.

Calling them evasion 'tiers' is a bit of a misnomer. Full evasion isn't so much about "reducing hit rate by a certain amount" as it is about "doing everything possible to make sure the mob can't hit me no matter what the sacrifice in other slots (and anything I can't fit evasion in gets PDT)".

The tank mode evasion set is for your basic hybrid evasion build (you can blend with either accuracy or attack, depending on need). The other evasion set is under PhysicalDefense. Perhaps using the 'Armor' term from the previous iteration would better represent its intended use, though 'MagicalArmor' for the MDT counterpart doesn't quite feel right..

[Byrthnoth]

Okay, but the result you're going to come up with will be functionally equivalent to what we already have. It's the same sets, approximately the same number of button presses away given the number of sets I eliminated. The difference is that you're devoting two buttons (tankset and normal set) to it instead of one.

Initially, I had my spellcast TP sets set up like this:
* DelayCap Set
* Haste/DD TP <- Default
* Evasion Set <- Ballerines, Blur, Evasion Torque, Heed
* Full Evasion <- Max evasion options

One trigger pushed it down the list, and one pushed it up the list. Non-circular, so I didn't have to worry about hitting the trigger too much if I wanted to be in full evasion. I also had two triggers that swapped in PDT and MDT gear as necessary, but no PDT-TP set.

All things considered, all that the changes from the last few months have done to improve this system was add a PDT-TP set that I use sometimes against EP monsters in Dynamis where I'm going to be evasion capped naked. It's a lot to ask people to update their spellcast, fill in the sets again, and get everything working when the changes don't honestly offer any kind of functional improvement.



The "/input" suggestions didn't seem like they were working. Does anyone have another way around the X->Y->X problem?

[Motenten]

Okay, but the result you're going to come up with will be functionally equivalent to what we already have.

To a large degree, that's the entire point. This isn't an attempt to completely redefine how people use spellcast, it's an attempt to codify common behaviors and put them together into a pre-written, consistent, maintainable library that anyone can use. The debates are about how to cover all the common cases, and make it equally useful for people using it in different ways (eg: keyboard vs gamepad).

Likewise, the library should be written in such a way that the user will never have to touch it (well, not much; still have to fill in appropriate staves and such); it will all "just work". Handling gear swaps without lag; handling staff swaps appropriately; handling day/weather based gear (obi, Zodiac Ring, Twilight Cape) in a reasonable fashion; spell recast warnings; etc, etc.

People have copied code that copied code that someone wrote a long time ago to do what they wanted, but is a bit outdated now and maybe difficult to work with at times, or doesn't work quite the way they want, or doesn't account for new gear (eg: rdm AF3 on spell recasts; spell cast time on staves where you may want to switch to a different staff for the actual spell effect; etc). We want to rewrite it so that it accounts for all that, so that it doesn't use locks (since locks in the library impose limitations on what you can do in the job xml), and just generally covers all reasonable use cases.

So now we have a grand compilation of all the 'nuisance' programming, but two very different approaches to certain 'everyday' use aspects (ie: TP Mode, etc). The question is, can we put something together that can fully encompass the majority of the user's needs? And how can we do that in the simplest way possible while still covering all the bases?

Thus the current back-and-forth. What are the absolute minimum necessary controls you need to do what you do? And how can it be written so that it works just as well for a mnk as for a dnc as for a blu as for a pld as for a whm? And, also importantly, make it so that the user can customize it to a certain degree without having to rewrite all the code themselves.

It's a lot to ask people to update their spellcast, fill in the sets again, and get everything working when the changes don't honestly offer any kind of functional improvement.

It's purely optional whether anyone wants to make use of these tools. The primary advantage to doing so is to have a common code base among all your xmls. I know that, personally, it was often a pain to switch between jobs because the manner in which they worked differed (and this is for someone who wrote pretty much everything from scratch myself; for people who are just copying xmls that they pulled off of the windower wiki or from pastebin, the disconnect must be much worse). Over time I had consolidated them into using very similar styles, but there were still a number of 'uniquenesses' among them.

The all-jobs template idea that Yugl came up with has helped a great deal, and even though it's a lot of work to rewrite things to match this new baseline, once it's all done it will be tons easier to move between jobs. I can go back to focusing on just what I need to do to make the job work, rather than fuss with how I configured this particular one to swap between TP gear sets, or where the emergency MDT switch is, or whatever.



Will put some more thought into the af3 hand issue.

[TybudX]

Is these a way I can have my BLM Trigger Monkey's spellcast recognize when a spell is cast from a gkey? The intent is to have it equip Fast Cast, Minus Casting Speed, etc, instead of potency and damage gear. Or is there a better way to handle this?

[Motenten]

I don't think there's any means of identifying a gkey (that's one of the extra keys on the expanded Logitech keyboards, right?). I just have a variable flag set when I intend to do proc testing, which switches to a different logic path that equips -dmg staves and no MAB, etc. Toggle the flag back and forth as needed.

[TybudX]

So you do, that's awesome. What exactly do I need to do in order to toggle that on and off? And while I'm asking about your BLM.xml, how would I add a rule for Carapacho Cuffs? Something like:

<if Spell="Stoneskin">
<equip when="Precast" set="FastCast">
<hands>Carapacho Cuffs</hands>
<equip when="Midcast" set="Haste" />
<lear>Earthcry Earring</lear>
<waist>Siegel Sash</waist>
<legs>Haven Hose</legs>
</equip>

I think that's right. Baby steps.

I have to say that I've been following the discussion about standardizing spellcasts for people like myself, and the work you guys are doing is greatly appreciated. You make me want to learn this stuff, and I'm not a coding kind of guy. Thanks to everybody who keeps this all going.

[Motenten]

You're missing a </equip> on the precast. I'd make sure to include Siegel Sash in the precast section as well.

[Yugl]

The "/input" suggestions didn't seem like they were working. Does anyone have another way around the X->Y->X problem?

Try having two <equip> commands for the flourish? No idea how well that will work.

As for that actual SC discussion, the medications make me lazy, so if I don't communicate stuff properly, just say so. First, I'll let the R-NM v None discussion conclude and remove those options from the group. Thus, I'll be limiting the groups to Abyssea v Non-Abyssea groups. Second, by virtue of popularity, I'll grant the use of eyeballing over predetermination. Given these conditions though, I don't think the division between melee and tank does what you want it to do. The choice to use a dDEX, counter, shield, cappeddelay, capped attack, or generic haste sets doesn't conjure the same thought that you guys are espousing for evasion and accuracy. If you use a dDEX build, it's because you have knowledge of that fact that you're going to hit the dDEX50 range. If you decide to use a counter or shield set, it's typically because you're making a conscious effort to use those; it's generally not because you notice that your counterrate or shield rate is bad. You might use them as justifications, but they're hardly stuff you need to "notice" before you adjust. There seems to be a distinction between what we might call "special sets" and "adaptive measures" (Noticing that you lack accuracy or noticing that you need to evade more often).

The most interesting finding in this discussion is the ability to wildcard sets. With this, we can make extensive parameters, but also add wildcards to reduce redundancy. From a user's end, if they disagree with the broadness of wildcarding (For example, if they think Shield and evasion bonus demands its own set apart from just shield), then they can add the sets themselves. I also maintain that we ought to think of full MDT/PDT/EVA as Armor rather than a type of TP set. These often need instant access and rotations are not favorable to celerity. In short, I propose the following:

TP-$STYLE-$TYPE-$ACC-$EVA

$TYPE = Critical hit, Capped Attack, Generic Haste, Cleave (PDT), Capped Delay, and so forth
$ACC on three tiers (None needed, minor needed to suit using meat, and Einherjar Chigoes craziness)
$EVA on two tiers (Light tanking with minor evasion pieces intended to be sufficient for accessing the next Utsusemi safely, Haste+EVA onry level intended to go beyond maintaining Utsu-to-Utsu transitions and actually being viable for greater durations without utsusemi) with Full Evasion as an armor that sacrifices all haste for evasion

The names of the variables are on-the-spot descriptions and subject to change, but the overall point should be clear (hopefully). Finally, I would like to stress that these XMLs are not made for the present. They are made to handle future modifications without the necessity for large remodification. Ideally, I should be able to quit FFXI and the only additions necessary should be to add a few spells/JAs and perhaps a $TYPE once in a while. Given that stipulation, the idea of a $TYPE enables a free range of sets such that SE cannot throw a TP option that is incompatible with the set up. For evasion and accuracy, I've had several PMs asking for reduction of the latter when under the influence of particular abilities, so I can understand his concern with that. As for evasion, I actually don't have much personal experience with that. I've used evasion sets, but only on BLU in order to try out suggestions in from the BLU thread. DRG, RDM, SCH, and MNK don't necessarily profit from such a set (Perhaps MNK, but I've never been in the circumstance to try). However, I can see the benefit of going from a Mid-EVA-ATT-HASTE set to a Mid-EVA-HASTE set where the latter tightens your "budget", but doesn't sacrifice as much DD prowess as a full evasion set. Thus, I leave you two to return thoughts on this configuration.

[TybudX]

I'm using an altered version of Akyrey's WHM spellcast. The rule above that one is an 'elseif enhancing equip when precast siegel sash' type of thing, won't that cover the Stoneskin layer as well?

[Haborym]

Can anyone tell me why my MDT/PDT sets won't work? They are at line 491-ish.

http://pastebin.com/2Rn29bdj

[Yugl]

All PDT and MDT triggers were part of TriggerSetOne in my XML, so you need to place them under the <elseif Spell="$TriggerSetOne"> branch.

[Fodder]

An idea I've been kicking around for set management is using arrays of weighted lists to build tunable sets.

[type priority][type][status/set name]
--------------------------------------
[1][Haste][TP]
[2][Triple Attack][TP]
[3][DualWield][TP]
[4][CritRate][TP]
[5][Double Attack][TP]
[6][Attack][TP]
[7][Dex][TP]
[8][Whatever][TP]
---------
[1][CritRate][WS]
[2][Str][WS]
[3][Triple Attack][WS]
[4][Double Attack][WS]
[5][Attack][WS]
[6][Dex][WS]
[7][Whatever][WS]

[type][priority][slot][item]
----------------------------
[Haste][1][body][Raider's Vest +2]
[Haste][2][waist][Twilight Belt]
[Haste][3][head][Raider's Bonnet +2] 
[Haste][4][legs][Calmecac Trousers]
[Haste][5][feet][Ballerines]
...
[Haste][14][some slot][some item]
--------
[Triple Attack][1][rring][Epona's Ring]
[Triple Attack][2][lring][Oneiros Ring]
--------
[DualWield][1][lear][Suppanomimi]
--------
[Attack][1][back][Atheling Mantle]
[Attack][2][neck][Agasaya's Collar]
--------
[Acc][1][neck][Peacock Charm]
....
[etc.]

Build ordered lists for the current status 

Set base slot usage from 1 to max # slots used (if Main hand and ranged are ignored, then 14)
[TP]
[type][default slots]
[Haste][5]
[Triple Attack][2]
[Dual Wield][1]
[Double Attack][2]
[Attack][2]
[Acc][0]


Bind hotkeys to toggle assorted types. Say I want to increase Acc, I hit the toggle Acc up. The code then searches the list for the lowest ranked piece of gear on the lowest ranked list that is equipped. In the simplified example above, that'd be for the neck, since it's the only one in the list.  So then the TP set slot list would get altered to increase Acc gear by 1 slot, and decrease Attack by 1. 
[TP]
[type][default slots]
[Haste][5]
[Triple Attack][2]
[Dual Wield][1]
[Double Attack][2]
[Attack][1]
[Acc][1]

It seems like this would be a bitch and a half to write, but once complete it'd make tuning sets for situations as simple as hitting a few hot keys. Eventual integration with a parser would allow for automated target based tuning over time. Have any suggestions on improving this concept? Do you think implementing in XML would result in a responsive enough tool?

[Motenten]

I'm using an altered version of Akyrey's WHM spellcast. The rule above that one is an 'elseif enhancing equip when precast siegel sash' type of thing, won't that cover the Stoneskin layer as well?

Yes, that would be fine. Just wanted to be sure since it wasn't specified in the code fragment.

[Motenten]

Bah, double-post somehow popped up from an edit...

[Motenten]

As for that actual SC discussion, the medications make me lazy, so if I don't communicate stuff properly, just say so. First, I'll let the R-NM v None discussion conclude and remove those options from the group. Thus, I'll be limiting the groups to Abyssea v Non-Abyssea groups.

Though I don't really use it anymore, I've included a Campaign group as well, for all the campaign-buffed items, and generally more solo-oriented gear sets. Was pondering a Voidwatcher group, but not sure if there's any value in that (atmacites are pretty minor buffs, and there's no voidwatch-only type gear that I know of). Someone with more experience at voidwatch could say better.

Second, by virtue of popularity, I'll grant the use of eyeballing over predetermination. Given these conditions though, I don't think the division between melee and tank does what you want it to do. The choice to use a dDEX, counter, shield, cappeddelay, capped attack, or generic haste sets doesn't conjure the same thought that you guys are espousing for evasion and accuracy.

I'm really not sure I understand your point here. First, we're really not approaching evasion and accuracy the same way (for evasion they aren't really 'tiers; rather one is a tank mode and the other is a defense mode. Accuracy has two actual tiers above the basline within just melee mode).

Second, the choice of which to use is still always predicated on a pretty simple set of questions. For Melee: What am I lacking (eg: acc)? What do I have excess of (eg: attack, haste)? For tanking: Which method am I going to use to perform this role (evasion, shield, PDT, etc)? And am I lacking anything in particular (ie: acc)?

If you use a dDEX build, it's because you have knowledge of that fact that you're going to hit the dDEX50 range.

This I'll grant as being slightly different; it's not that you have an excess of dex, it's that you want to create an excess of dex with this gear set.

If you decide to use a counter or shield set, it's typically because you're making a conscious effort to use those; it's generally not because you notice that your counterrate or shield rate is bad. You might use them as justifications, but they're hardly stuff you need to "notice" before you adjust.

I think the only argument being made with respect to 'noticing' anything was the value of multiple tiers of accuracy (part of which had nothing to do with eyeballing, but rather that you wanted to keep acc gear on regardless of other accuracy buffs), though one could evaluate capped attack the same way.

There seems to be a distinction between what we might call "special sets" and "adaptive measures" (Noticing that you lack accuracy or noticing that you need to evade more often).

Sort of. To an extent it's all just "How am I going to approach this fight?"

The most interesting finding in this discussion is the ability to wildcard sets.

Another interesting find that I'm not sure I mentioned was the ability to use variables in BaseSet attributes. I'm still trying to work out if it's actually useful, but it definitely seemed an interesting option in constructing things.

With this, we can make extensive parameters, but also add wildcards to reduce redundancy. From a user's end, if they disagree with the broadness of wildcarding (For example, if they think Shield and evasion bonus demands its own set apart from just shield), then they can add the sets themselves.

I also maintain that we ought to think of full MDT/PDT/EVA as Armor rather than a type of TP set. These often need instant access and rotations are not favorable to celerity.

Indeed. I still have those explicitly separated out.

In short, I propose the following:

TP-$STYLE-$TYPE-$ACC-$EVA

$TYPE = Critical hit, Capped Attack, Generic Haste, Cleave (PDT), Capped Delay, and so forth
$ACC on three tiers (None needed, minor needed to suit using meat, and Einherjar Chigoes craziness)
$EVA on two tiers (Light tanking with minor evasion pieces intended to be sufficient for accessing the next Utsusemi safely, Haste+EVA onry level intended to go beyond maintaining Utsu-to-Utsu transitions and actually being viable for greater durations without utsusemi) with Full Evasion as an armor that sacrifices all haste for evasion

My current tentative config (been rebuilding my nin xml using this revision to see how it works) uses the following:

TP-$TPStyle-$TPMode-Melee|Tank-[Melee|Tank]Mode[-TankModifier]

TP-Katana-Melee-LightAcc
TP-Katana-Tank-Evasion-Normal
etc.

There there are two custom melee modes that can be specified for things like capped haste. Though... I suppose there's actually four jobs where that would make sense: nin, dnc, drk (DB merits) and mnk (2hr). On the other hand, two of those are dependant on certain buffs (and maybe Embrava for everyone else; not sure how it stacks), thus wouldn't be considered an active 'mode'. Needs more thought.

The names of the variables are on-the-spot descriptions and subject to change, but the overall point should be clear (hopefully).

Indeed, though to an extent we're getting into implementation details. If we both agree to include, say, MeleeMode, with a common understanding of what it's intended for and a matched trigger for adjusting it, it doesn't really matter which modes each of us includes. EG: you might include an explicit Dex mode option while I could just leave it as an option under Custom mode, and it doesn't really impact the common framework design.

Finally, I would like to stress that these XMLs are not made for the present. They are made to handle future modifications without the necessity for large remodification. Ideally, I should be able to quit FFXI and the only additions necessary should be to add a few spells/JAs and perhaps a $TYPE once in a while. Given that stipulation, the idea of a $TYPE enables a free range of sets such that SE cannot throw a TP option that is incompatible with the set up. For evasion and accuracy, I've had several PMs asking for reduction of the latter when under the influence of particular abilities, so I can understand his concern with that.

Yeah, dynamically switching modes when certain buffs are up (such as the above haste examples, or accuracy in general) will take some thought on how to approach that.

As for evasion, I actually don't have much personal experience with that. I've used evasion sets, but only on BLU in order to try out suggestions in from the BLU thread. DRG, RDM, SCH, and MNK don't necessarily profit from such a set (Perhaps MNK, but I've never been in the circumstance to try).

It seems a lot of the problems we're having is due to not having the same experience with certain aspects of playing the game. I don't use a gamepad, my blu is only lvl 34, I've never done rdm soloing, etc. On the other hand I have lots of experience with mnk in general, thf evasion tanking, and pld shield/blink tanking under various circumstances, etc, each of which influences things that I feel are important to include, even if they don't explicitly apply to how you (or even I) play any other particular job.

At the same time I'm trying not to make this a micromanaging nightmare of a different gear set for every single gear swap you might want to consider (ok, slight exaggeration...).

[Nightfyre]

Was pondering a Voidwatcher group, but not sure if there's any value in that (atmacites are pretty minor buffs, and there's no voidwatch-only type gear that I know of). Someone with more experience at voidwatch could say better.

Save TP+20 and Regain +2-5 (atmacite + Monarch's Drink) may alter two-hand TP builds.

[Yugl]

I don't see the point of distinguishing between Melee/Tank, but if we agree to use 3 types of triggers for modifying the set, then it shouldn't matter extensively. I've been looking it over, but I'm still not clear on how you plan to implement yours. I'm probably going to go with TP-STYLE-MODE-ACC-EVA. Since we want to keep most of the include stuff separate for flexibility purposes anyways, what's most important is the number of triggers in my opinion.

EX: TP-SWORD-HASTE-ACC1-EVA2 or TP-POLEARM-HASTE-ACC1-EVA1

Edit: Short and halfass response, but I've been having network difficulties since this evening and I have other stuff to attend to.