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

**Motenten** · 2011-10-20 17:20

Originally Posted by Masamune

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 ?

Ok, here's some really simple code to help you see:

Code:

<?xml version="1.0" ?>
<spellcast xmlns:xi="http://www.w3.org/2001/XInclude">
    <config Debug="false"
          ShowGearSwaps="false"
          ShowSpellInfo="false"
          RequireVersion="2.30"
          />

    <variables>
        <var name="Test1">0</var>
        <var name="Test2">0</var>
        <var name="Test3">0</var>
    </variables>

    <sets>
    </sets>

    <rules>
        <!-- This outputs the current variable values and then exits.
             It is solely to see what the current state is, and will
             now allow any other changes to the variables -->
        <if Spell="Tranquility">
            <cancelspell />
            <addtochat>Test1 = $Test1</addtochat>
            <addtochat>Test2 = $Test2</addtochat>
            <addtochat>Test3 = $Test3</addtochat>
            <return />
        </if>
        
        <if Spell="autoset">
            <if status="idle">
                <var cmd="set Test1 1" />
                <var cmd="set Test2 0" />
            </if>
            <elseif status="resting">
                <var cmd="set Test1 0" />
                <var cmd="set Test2 1" />
            </elseif>
            <elseif status="engaged">
                <var cmd="set Test1 1" />
                <var cmd="set Test2 1" />
            </elseif>
        </if>
        
        <addtochat>Addtochat test</addtochat>
        
        <!-- Every time the code is run for any reason (except for Tranquility check),
             the Test3 value gets incremented. -->
        <var cmd="setcalc Test3 $Test3+1" />
    </rules>
</spellcast>

Have a macro set up to do "/ja Tranquility" so you can see what the various variable values are, and then check them as you change states (rest, engage, idle, etc).

Now rest, stand up, engage, whatever, and do the Tranquility check each time. The "Addtochat test" text will only ever be output if you use a ja or spell. Normal autosets will not output any text. However you can see that that code is executed each time because the Test3 variable will increment every time you /heal or stand, etc.

Masamune · 2011-10-20 17:34

DoublePost ftw.... my bad

Masamune · 2011-10-20 17:34

Ok thanks Mote, much clearer now.

One question tough: Would that sample code work the same if the <if spell=autoset> were removed ?

EDIT: nvm was idiot question.... i didnot realize "spell" means an action.... nvm i'll test this tomorrow.

**Motenten** · 2011-10-20 17:46

Originally Posted by Masamune

Ok thanks Mote, much clearer now.

One question tough: Would that sample code work the same if the <if spell=autoset> were removed ?

For this specific example, it would. However as a more general case, the variable values (1 and 2) are changed -only- when there's an autoset trigger (ie: %status changed) in the code above; if you removed the <if spell=autoset> check those values would be reevaluated on every action you took. It works fine here because the values being assigned are static, however that might not be the case in any other given rule set.

For example, in my thf xml, I want to equip TH gear only when I actually engage, not any time the code is run just because I happen to be engaged. Therefore it must be enclosed in the <if spell=autoset> check.

**Motenten** · 2011-10-20 18:04

Originally Posted by Syco

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

Almost missed this. Yes, very much so, please comment (as well as anyone else with an interest in this debate). A third-party view would be very helpful in ensuring that the code doesn't get overly confusing for those who aren't hip-deep in writing it. Naming, coding, logic, structure.. anything confusing, or that doesn't work the way you'd naturally expect it to; keep us from getting too complacent

Anything discussed between us on this, feel free to offer your opinion on how you'd *like* it to work, as well as how you'd expect it to work.

**Yugl** · 2011-10-20 22:27

I had a write up but accidentally deleted it. Short version is that we should set some disagreements on the side and focus them piece-by-piece.

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, Equanimity

I would prefer using some of these spells for class specific triggers because not all class specific triggers are class specific (I don't think any are actually). Moreover, another reason for using triggers was to make it easier for people to bind keys. I would also add more Diagas and Poisongas since they're currently at tier 1. At the very most (In the near future), Poisonga/Diaga III might happen retroactively (Added to earlier levels). I also see meteor II in the dats, but with the new 2hrs coming out, that is iffy.

My list
- Fomor spells (9)
- Poisonga V
- Poisonga IV
- Diaga V
- Diaga IV
- Poison V
- Dia V
- Banishga V
- BanishV/BioV/AgaV Elements *

* We need a backup plan in the event that they unlock this. The new meritable 2hrs might unlock AgaV. We could also have one trigger rotate through the elements.

That's 17 without including MDT-Element. BRD spells can be kept reserved (Idk how best to do that tbh).

**Motenten** · 2011-10-21 00:12

We need a backup plan in the event that they unlock this. The new meritable 2hrs might unlock AgaV.

Well, part of the reason for using the -ga5s was that it also gave immediate access to elemental values. Any other spells or JAs used would need some sort of translation mechanism (eg: Scop's Operetta == fire), which would be troublesome and unwieldy. So any backup thoughts you have need to account for that.

And actually, the backup is quite simple: Allow redefinition of the values (same as avoiding issues for someone with Tranquility merited on sch). Default values for all jobs are the -ga5s, but blm can redefine them as, say, Carol II's should the need arise.

Here, tested this and it works:

Code:

    <var name="Trigger-Fire">Firaga V</var>
    <var name="Trigger-Earth">Stonega V</var>
    <var name="Trigger-Water">Waterga V</var>
    <var name="Trigger-Wind">Aeroga V</var>
    <var name="Trigger-Ice">Blizzaga V</var>
    <var name="Trigger-Thunder">Thundaga V</var>
    <var name="Trigger-Light">Banishga V</var>
    <var name="Trigger-Dark">Bio V</var>
    
    <var name="EleTriggers">$Trigger-Fire|$Trigger-Earth|$Trigger-Water|$Trigger-Wind|$Trigger-Ice|$Trigger-Thunder|$Trigger-Light|$Trigger-Dark</var>

Blm would need to redefine all 8 elements, plus the EleTriggers variable, should it wish to properly override these values.

We could also have one trigger rotate through the elements.

I've done that before with blm proc spells. It is far too much of a hassle to be worth it. Definitely would not want to do it that way.

Moreover, another reason for using triggers was to make it easier for people to bind keys.

Ok, I can actually see a reason for using them that way now. I think of approaches using macros first, and keybinds a very distant second, especially as the number of options for keybinds that don't overwrite game commands is extremely limited.

I would suggest a KeybindTriggers variable for any triggers you want to be allowed to be bound to keys, but don't want to define behavior for at the global level. Those triggers must additionally be defined in the JobTriggers variable in each job that expects to use them as job-specific triggers. This is very user-specific code (ie: depends on how they want to approach the whole keybind issue), and by default I would not put any actual triggers in there.

Something that's in the KeybindTriggers but doesn't have behavior defined in a given job xml shouldn't be treated specially; any JA or spell in the KeybindTriggers but not in the JobTriggers can be considered ignorable. Anything in JobTriggers that's not in KeybindTriggers would presumably be a macro, not a keybind.

However this also complicates the ability to redefine triggers. If Tranquility is a keybind, but you need to redefine the $ResetTrigger for sch, redefining the variable is easy, but the keybind is still stuck on Tranquility. Not sure how to handle that; it's far simpler to deal with at the macro level (and part of why I'd expect job-specific triggers to be at the macro level rather than at the keybind level).

BRD spells can be kept reserved (Idk how best to do that tbh).

I just keep a list in an UnusedTriggers variable for reference. When I need a new one, I pull it out of there.

Also, no objection to the general spell list.

**Yugl** · 2011-10-21 00:46

Since we have 17 non-Tranquility/BRD/AgaV triggers available, perhaps we should prioritize those rather than letting tranquility fulfill such a consequential role?

For the keybind stuff, redefinition shouldn't be an issue if we maintain a distinction between Macro and KeyBind triggers. As I mentioned with my earlier set up, I had One-hit triggers/Universal Rotations/Class Specific rotations. Of these, I only need to keep the following bound:
- 2 One-hit trigger (Distance/Resist)
- All universals
- All class specific

It's impossible for a class such as SCH or BLU to maintain them at the macro level due to the burdensome shit we need to do at a moment's notice (Which, according to some jerks, amounts to every damn action possible). Stuff like TPorIdle/EVA/MDT/PDT are more than welcome at the macro level. Beyond that though, keybinds are the way to go. So if we take like 6 of the Fomor spells and make them designated towards macro stuff and give the rest to keybinds, it should work out.

Edit: With the general list determined, we should move onto discussing the action of the trigger spells I guess. Nvm on the $Variable working with scripts.

**Motenten** · 2011-10-21 02:06

I had One-hit triggers/Universal Rotations/Class Specific rotations.

For the sake of clarity, please define these.

Since we have 17 non-Tranquility/BRD/AgaV triggers available, perhaps we should prioritize those rather than letting tranquility fulfill such a consequential role?

Probably, yes. I've become rather attached to it, but you're right, it's not something that should be subject to the vagaries of being overridden and having keybind issues.

It's impossible for a class such as SCH or BLU to maintain them at the macro level due to the burdensome shit we need to do at a moment's notice (Which, according to some jerks, amounts to every damn action possible). Stuff like TPorIdle/EVA/MDT/PDT are more than welcome at the macro level. Beyond that though, keybinds are the way to go. So if we take like 6 of the Fomor spells and make them designated towards macro stuff and give the rest to keybinds, it should work out.

I think your approach is backwards. Anything dealing with macros should always assume macros as the default, not as the "backup". Further, macros are the more flexible of the two modes; you don't have to "reserve" a set of actions for macros since you can freely and safely override them as needed, and just tweak the actual macros used for a given job. Keybinds are the less flexible since they have to remain fixed across all jobs.

So it makes more sense to reserve a set of "absolutely must be keybindable" triggers, and have everything else be "preferably keybindable, but may be overridden as needed". There are only a few actions that I think should absolutely be keybindable for immediate and consistent access:

Reset
PDT switch
MDT switch (not mode)
Light Armor switch (not mode)
Kill switch
Kiting switch

Those should be designated with fixed values that don't have to worry about being overridden. Anything else should be allowed to be flexible in usage. Obviously it's preferable that it be keybind-safe (and most probably will be, given 16 'safe' spells/JAs, along with the 8 elemental triggers), but it isn't a requirement.

That would use 6 of the 'reserved' entries. What is your list of "absolutely must be keybindable"?

Masamune · 2011-10-21 04:02

....autoset idea doesnot work, it even adds another problem with aftercast not processing

Spoiler: show

test: i CHARM a mob, i go auto in charm set but i never come back to IdlePetIdle...i had to rest to trigger it...
...then i make my pet FIGHT a mob, i stay in IdlePetIdle instead of going IdlePetEngaged... i had to rest to trigger that also.
...then i engage the mob, i go into Engaged set no prob.
...then i disengage when mob fighting, i go in IdlePetEngaged set np.
...then i reengage and kill the mob, on disengage i go into IdlePetEngaged instead of IdlePetIdle... i had to rest to trigger that also.

what should i write in my code (in spoiler above) ?

EDIT: for reference the same code without the autoset check doesnot have the 2 first problems but has the last one.

**Syco** · 2011-10-21 05:09

Originally Posted by Masamune

....autoset idea doesnot work, it even adds another problem with aftercast not processing

Spoiler: show

test: i CHARM a mob, i go auto in charm set but i never come back to IdlePetIdle...i had to rest to trigger it...
...then i make my pet FIGHT a mob, i stay in IdlePetIdle instead of going IdlePetEngaged... i had to rest to trigger that also.
...then i engage the mob, i go into Engaged set no prob.
...then i disengage when mob fighting, i go in IdlePetEngaged set np.
...then i reengage and kill the mob, on disengage i go into IdlePetEngaged instead of IdlePetIdle... i had to rest to trigger that also.

what should i write in my code (in spoiler above) ?

EDIT: for reference the same code without the autoset check doesnot have the 2 first problems but has the last one.

I've got a decent whack of game-time tonight, so I'll run a few tests and see if I can make it work. I'll have a go at ironing out the logic on paper now, though, and get back to you if I get anywhere.

@Debate - I'm with Mote on the Bindable-Reserve vs Macro issue: a lot of jobs can get by fine with macros only, so assuming macros onry and providing keybind options is probably better than assuming keybinds.

**Syco** · 2011-10-21 06:00

Originally Posted by Masamune

....autoset idea doesnot work, it even adds another problem with aftercast not processing

Spoiler: show

what should i write in my code (in spoiler above) ?

EDIT: for reference the same code without the autoset check doesnot have the 2 first problems but has the last one.

The issue with autoset is it only procs when you change status.

You've picked up on this when you say you have to rest to trigger equip swaps.

I've spoilered some code that'll work below, and an explanation of what it does. I know you don't like recursive spell calls, but the only way I see to manage this is by utilising this (in the minimised manner in the code).

Spoiler: show

Also, do you want Spur to automatically recast whenever it's ready? 'cos that's what your code is doing.

Masamune · 2011-10-21 06:52

k thanks Syco. Yes for auto-Spur.

Originally Posted by Syco

The issue with autoset is it only procs when you change status.
You've picked up on this when you say you have to rest to trigger equip swaps.

Yes and i thought going from status=engaged to Status=Idle would be considered like a status change in same way as going from Status=idle to Status=engaged, which is clearly NOT the case. Bug or i missed something?

...but somehow my little finger (which could be wrong :D ) is yelling me there is a way to do it without recursive trigger calls. (yur idea to use autoexec event="gainexp" is an example, tough sadly limited to exp-yielding mobs)

i would be curious about Mote and Yugl's opinions on this issue, please.

**Syco** · 2011-10-21 10:25

Engaged > Idle does work as a status change - it should work if you're engaged when the mob dies.

It definitely won't change your gear if you stay idle and make your pet fight, or if you're not engaged when your pet kills a mob, as you're going from Idle > Idle - it's just your pet that's going Engaged > Idle.

If only there were a PetStatus AutoSet.

**Yugl** · 2011-10-21 10:52

Quick points as I have to get stuff done quickly:
- Do you guys use gamepad or PC? For those of us on gamepad, macros for the stuff you listed is easier since we can quickly access stuff like PDT or MDT via macros as opposed to keybinds; hence, it's easier to use binds for stuff we won't need "immediately"
- It's unclear why we should keep reset mode if we have killmode; since these buttons are "on" rather than "on-off" (Toggles) it seems redundant to keep the reset button alongside the other buttons that require pertinent access.

In the next post, I'll show you what BLU/SCH macros look like since it will become clear that macro options are unattractive.

Masamune · 2011-10-21 11:00

Originally Posted by Syco

Engaged > Idle does work as a status change - it should work if you're engaged when the mob dies.
It definitely won't change your gear if you stay idle and make your pet fight, or if you're not engaged when your pet kills a mob, as you're going from Idle > Idle - it's just your pet that's going Engaged > Idle.
If only there were a PetStatus AutoSet.

You didnot get it:

I said clearly "if I kill the mob both me and my pet were fighting", it doesnot change back to IdlePetIdle set.
In other terms, Engaged > Idle status failed to proc for a reason i don't understand at all.

**Motenten** · 2011-10-21 11:29

@Masamune:

I've been sorta following your issue, but to be clear on the parameters, you want:

Equip Engaged/Idle/Resting when in those states
If Pet is not engaged, also equip PetIdle gear
If Pet is engaged, also equip PetEngaged gear

Here's a draft of how I would do it.

Spoiler: show

Code:

Vars:
<var name="PetStatus">None</var>
<var name="CheckOnPet">wait 5; Libra &lt;pet&gt;</var>
<var name="JobTriggers">Libra</var>
Note: using Libra instead of Blizzaga V because Blizzaga V is part of the elemental trigger set in my/Yugl's work.  Using Libra so that it does not conflict with any of the 'universal' triggers, since this is explicitly job-specific and only used for testing state.

Sets:
<set name="None">
    <!-- Empty set -->
</set>
<set name="Engaged">
</set>
<set name="Idle">
</set>
<set name="Resting">
</set>
<set name="PetEngaged">
</set>
<set name="PetIdle">
</set>
~~ other


Rules:
<if PetIsValid="false">
    <var cmd="set PetStatus None"/>
</if>

<if type="JobAbility">
    <aftercastdelay delay=".5" />
    
    <if spell="Libra">
        <cancelspell />
        
        <if PetIsValid="false">
            <var cmd="set PetStatus None" />
        </if>
        <elseif advanced='%IsInCombat=1'>
            <var cmd="set PetStatus PetEngaged" />
            <command>$CheckOnPet</command>
        </elseif>
        <else>
            <var cmd="set PetStatus PetIdle" />
        </else>
    </if>
    <elseif Spell="Call Beast">
        <equip When="precast" Set="CallBeast" />
        <var cmd="set PetStatus PetIdle" />
    </elseif>
    <elseif Spell="Charm" PetIsValid="False">
        <equip When="precast" Set="Charm" />
        <var cmd="set PetStatus PetIdle" />
        <command>$CheckOnPet</command>
    </elseif>
    <elseif Spell="Leave">
        <var cmd="set PetStatus None" />
    </elseif>
    <elseif Spell="Stay">
        <var cmd="set PetStatus PetIdle" />
    </elseif>
    <elseif Spell="Fight|Heel" PetIsValid="true">
        <var cmd="set PetStatus PetEngaged" />
        <command>$CheckOnPet</command>
    </elseif>
    <else>
        <equip when="precast" set="%Spell" />
        <!-- ~~other JA actions -->
    </else>
</if>

<if Spell="autoset">
    <if status="idle|resting">
        <if PetIsValid="false">
            <var cmd="set PetStatus None"/>
        </if>
        <else>
            <command>$CheckOnPet</command>
        </else>
    </if>
</if>

<if status="engaged|resting">
    <equip when="engaged|resting|aftercast" set="%Status" />
</if>
<else>
    <equip when="idle|aftercast" set="%Status|$PetStatus" />
</else>

Fixed a couple bugs in the code samples you two were using as well.

Edit: Tweaked to account for Masa's feedback below.

Edit: Fixed a couple bugs

Masamune · 2011-10-21 11:57

Originally Posted by Motenten

@Masamune:
I've been sorta following your issue, but to be clear on the parameters, you want:

Equip Engaged/Idle/Resting when in those states
If Pet is not engaged, also equip PetIdle gear
If Pet is engaged, also equip PetEngaged gear

Not exactly, i'll fix what you wrote:

Equip Engaged/Resting when in those states
For Idle Status:
-If Pet is not engaged (or no pet at all), equip PetIdle gear (which is basically a standard Idle set with PDT/regen equips)
-If Pet is engaged (or heel'ed), equip PetEngaged set (ie gears with "Pet: xxx" enhancements)

EDIT: for the engaged set, an OCD bst would want 2 engaged sets depending on PetStatus but imho it is useless assuming:
if i'm engageing a mob alongside my pet means i feel safe enough to let my pet handle the mob tanking on its own, so i can feel safe enough to equip a normal DD set, regardless of PetStatus.

Looking at your code suggestion now...
EDIT2: well that's basically what Syco were suggesting earlier :s
Then guess i have 3 choices:
a) use those ChekOnPet vars suggested by Syco/Mote with messages on in game log "...A command error occured." each 5secs on each mob i'm fighting...
b) keep my current simple code requiring to hit in game a macro //sc set IdlePetIdle each time me or my pet kill a mob...
c) pester Yekyaa/Aikar/whoeverisdev to implement a %PetStatus var and pray for before end of year...

Hard choice lawl ...

**Motenten** · 2011-10-21 11:59

Originally Posted by Yugl

Quick points as I have to get stuff done quickly:
- Do you guys use gamepad or PC? For those of us on gamepad, macros for the stuff you listed is easier since we can quickly access stuff like PDT or MDT via macros as opposed to keybinds; hence, it's easier to use binds for stuff we won't need "immediately"
- It's unclear why we should keep reset mode if we have killmode; since these buttons are "on" rather than "on-off" (Toggles) it seems redundant to keep the reset button alongside the other buttons that require pertinent access.

In the next post, I'll show you what BLU/SCH macros look like since it will become clear that macro options are unattractive.

PC/keyboard only.

For me, I want keybinds as accessible actions regardless of macro palette. For several jobs I need to use multiple palettes for all the different spell/JA options (whm, smn, blm, sch and cor are all pretty bad in this regard), while others are viable on a single palette only if I'm able to offload a lot of these universal triggers. Since space is already at a premium just for the normal actions I want to be able to perform, fitting in additional switches/toggle/etc for equipment state (and having to repeat them on every palette) is overly onerous, so I'd prefer to move them to keybinds. Since they'll be on keybinds anyway, for which I have very limited space, they should be equally useful for all jobs.

Just as with Reset vs Aftercast, Reset is not the same as the Kill Switch; they perform separate functions. While I did wrestle with the option to do so in early development, Reset should never turn off user-selected states such as PDT.

Also, while there's the *option* for making the PDT/MDT/etc switches as "on" only rather than toggles, there's also the option to set them as toggles (I gave you a code example earlier to show how that would work). You just define a single variable in the Include file to say that either you hit PDT to turn it on and Kill Switch to turn it off, or you hit PDT to toggle between on and off. That's a user preference, and you should not assume it always works one way or the other.

For sch, yes, I can see wanting to keybind all the strategems so you don't have to use up a half-dozen macro slots per palette for them. However that's clearly outside the scope of the universal triggers being considered.

**Motenten** · 2011-10-21 12:03

Originally Posted by Masamune

Not exactly, i'll fix what you wrote:

Equip Engaged/Resting when in those states
For Idle Status:
-If Pet is not engaged (or no pet at all), equip PetIdle gear (which is basically a standard Idle set with PDT/regen equips)
-If Pet is engaged (or heel'ed), equip PetEngaged set (ie gears with "Pet: xxx" enhancements)

Looking at your code suggestion now...

Ok, then just use the second of the two options for the final lines of the code. Though I am curious as to why you wouldn't apply the same checks for resting as for idle (ie: resting+petengaged if pet is engaged while you're resting). +HMP, I guess? Can adjust that final check to <if status="engaged|resting"> instead of just <if status="engaged">.

Edit: Ok, made a couple adjustments to the code to reflect the above. Also tweaked code flow with respect to Libra.

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

Thread Tools

Similar Threads

Spellcast Shop Thread

time spent on ls events, helping friends and your own time

Latest Threads

Up & Coming Threads

Hottest Threads