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

[Ithorien]

Triple! Martel just pointed out that cancel 66 cancels Utsusemi regardless of how many shadows you have active, so my Utsusemi rule does not work properly for quick magic procs. Just pushed v2.11 to fix this.

I've been trying to figure out how to get around this, is this the only syntax pertaining to the issue?-

<elseif BuffActive="Copy Image (3)|Copy Image (4+)">
<cancelspell />
<return />
</elseif>

[Nightfyre]

That one is the precast check, which stops the spell altogether unless I'm in PDT/MDT gear (lets me put shadows up mid-AoE). The portion relevant to Ichi midcast is further down:

<else>
					<if advanced='(int)$Utsusemi == 1'>
						<var cmd="set Utsusemi 0" />
						<if buffactive="Copy Image|Copy Image (2)" when="midcast">
							<cmd when="midcast">cancel 66</cmd>
						</if>
					</if>
				</else>

The bolded part checks for whether or not I have a relatively fresh set of shadows up, with the next line executing only if quick magic didn't proc (since the spell can only fire outside of PDT/MDT gear if I have 0-2 shadows).

[Ithorien]

That one is the precast check, which stops the spell altogether unless I'm in PDT/MDT gear (lets me put shadows up mid-AoE). The portion relevant to Ichi midcast is further down:

<else>
					<if advanced='(int)$Utsusemi == 1'>
						<var cmd="set Utsusemi 0" />
						<if buffactive="Copy Image|Copy Image (2)" when="midcast">
							<cmd when="midcast">cancel 66</cmd>
						</if>
					</if>
				</else>

The bolded part checks for whether or not I have a relatively fresh set of shadows up, with the next line executing only if quick magic didn't proc (since the spell can only fire outside of PDT/MDT gear if I have 0-2 shadows).

If you wouldn't mind, I am hardly any good at XML; can you write a syntax for me with no regard to PDT/MDT gear, just for Ichi cast?

My Utsu at the moment is (borrowed from some other XML)

<if spell="Utsusemi: Ichi">
                                <defaulttarget target="&lt;me&gt;" />
                                <castdelay delay=".2" />
                                        <if mode="or" tpgt = "$locktp" status="Idle">
                                                        <equip when="precast" set="Utsu" />
                                                        <equip when="aftercast" set="Idle" />
                                        </if>
                                        <else>
                                                <equip when="precast" set="Ichi" />
                                                <equip when="aftercast" set="$GearType" />
                                        </else>
                                <!-- The next 4 lines are used to cancel shadows incase you have Ni active -->
                                <!-- 66 is for 1 shadow, 446 is for 2 shadows, 445 is if you  have 3 shadows active -->
                                <!-- No way to program Spellcast to discern if Ichi or Ni is active, deal with it -->
                                <midcastdelay delay="2.5" />
                                <command when="midcast">cancel 66</command>
                                <command when="midcast">cancel 446</command>
                                <command when="midcast">cancel 445</command>
                        </if>
                        <elseif spell="Utsusemi: Ni">
                                <defaulttarget target="&lt;me&gt;" />
                                <castdelay delay=".2" />
                                <equip when="precast" set="Utsu" />
                                <if status="Idle">
                                <equip when="aftercast" set="Idle" />
                        </if>
                        <else>
                                <equip when="aftercast" set="$GearType" />
                        </else>

[Nightfyre]

Martel pointed out that it only half works in that you'll lose all shadows if you quick cast Ichi with Ni shadows up, but Ichi > Ichi or shadowless > Ichi works (along with all non-QC procs obviously). I'm probably going to just scrap the current rule and move to a manually triggered cancel.

[Yugl]

I don't notice any lag, but if you do ever get to that point, you'll want to use Dancing Chains as a trigger to change your gear and remove

                        <!-- Gearswap handling and spell cancelling for all triggers. Gearswaps are disabled if you are
                                in the middle of a Ninjutsu spell to avoid situations such as AutoExec triggering
                                in the middle of Utsusemi and potentially causing you to cast in something other
                                than AF3+2 feet. -->
                
                        <if advanced='"$Active" = "0"'>
                                <if status="idle">
                                        <equip set="Idle|$Armor|Movement" />
                                </if>
                                <elseif status="engaged">
                                        <equip set="$Melee|$Armor|$FastFeet" />
                                </elseif>
                        </if>

And add some code like

                <!--- Auto Update Gear --->
                <if spell="Dancing Chains">
                    <cancelspell />
                    <if status="idle">
                        <equip set="%Status|$Armor-%Status|$Movement-%Status" />
                    </if>
                    <elseif status="engaged">
                        <if advanced='"$VAR-TP"="EVA"'>
                            <equip set="TP-$STYLE-$VAR-TP|$PerfectCounterSet|$Armor-%Status|$Movement-%Status" />
                        </if>
                        <else>
                            <equip set="TP-$STYLE-$VAR-TP|$HundredFists|$ImpetusSet|$PerfectCounterSet|$Armor-%Status|$Movement-%Status" />
                        </else>
                    </elseif>
                    <elseif status="resting">
                        <equip set="%Status" />
                    </elseif>
                </if>

and

<command when="idle|engaged|aftercast">Dancing Chains</command>

[Nightfyre]

I'd be removing the aftercast rules at the end of the xml, not that rule. Not sure how that reduces lag though.

[Yugl]

I don't know the details, but it worked for me and it worked for Motenten when his system (finally) experienced lag.

[Ithorien]

NVM can't read.

[Motenten]

It's a combination of several factors:

1) Comparisons and variable construction are cheap.
2) Set construction, particularly with layered sets, is expensive, and gets more so the more sets you have. (Edit: Total sets, not just sets used in the layer construction.)
2a) This can be alleviated somewhat by using direct <equip> commands within the rules structure instead of <set>s.
3) Precast and midcast construction is usually simple (eg: a single piece of gear to boost a JA, or a single set to be looked up for a weaponskill).
4) Aftercast construction to put you back in your 'active' set is far more complex.


1 and 3 usually combine to make the work done for precast gearing simple and fast. 2 and 4 usually combine to make aftercast gearing complex and slow. When all the work has to take place before Spellcast even starts to send the JA/spell command, this creates 'lag' -- the delay between the physical act of hitting the macro and the game actually recognizing the command.

The solution that Yugl worked out, and I verified once I was able to build something complex enough to actually generate lag on my system, is to defer the resolution of the aftercast sets until the aftercast time period.

All the work doing buff checks and variable modification is cheap. It's only once you get to the point of resolving the final gear set that Spellcast gets slow. The resolution of each individual set used in a layered construction has to be resolved in an O(n) search of all sets within a group (and thus, the more sets the slower it gets for each layer). A sufficient number of layers combined with a sufficient number of sets takes long enough to resolve and combine to actually be perceptible.

However that perception only matters at the front end. An extra quarter second between hitting the macro and the game reacting gets aggravating very quickly. If the aftercast is delayed an extra quarter second or so, no one's really going to notice.

Thus, the command that gets run on aftercast to cause all the set resolution to occur at a less sensitive point in time.

[Nightfyre]

I get the mechanics of what you're saying but not necessarily how it applies here. Are you saying that precast, midcast, and aftercast sets are all built at the start of an action rather than at or at least towards the appropriate time of execution?

[Sekundes]

I get the mechanics of what you're saying but not necessarily how it applies here. Are you saying that precast, midcast, and aftercast sets are all built at the start of an action rather than at or at least towards the appropriate time of execution?

IIRC everything is done before the game even sends a command to the game. You can see this by viewing the debug log.

[Ithorien]

So, reposting my question because I can't find the answer even though I thought I did-

Can't get my triggers to work. Setup macros a'la /ws "Dancing Chains" <t> to trigger certain conditions according to Nightfyre's NIN XML, but no matter what the gear doesn't swap. I get the echo text in chatlog, but nothing besides that. Any ideas? Never used triggers like this, always just did /sc commands to change variables or sets.

[Martel]

I get the mechanics of what you're saying but not necessarily how it applies here. Are you saying that precast, midcast, and aftercast sets are all built at the start of an action rather than at or at least towards the appropriate time of execution?

Now see, this is why I was confused about that buffactive midcast thing you were doing. I didn't think that worked, but from what I've read of your posts, you're competent enough for me to question myself if you think it works. XD

[Motenten]

I get the mechanics of what you're saying but not necessarily how it applies here. Are you saying that precast, midcast, and aftercast sets are all built at the start of an action rather than at or at least towards the appropriate time of execution?

Precisely. Absolutely nothing is sent to the game until all precast/midcast/aftercast stuff is resolved. Once completed, nothing is changed at later time points. Can get around that somewhat by sending another command at a different time point to make it run through the rules section again.

[Motenten]

So, reposting my question because I can't find the answer even though I thought I did-

Can't get my triggers to work. Setup macros a'la /ws "Dancing Chains" <t> to trigger certain conditions according to Nightfyre's NIN XML, but no matter what the gear doesn't swap. I get the echo text in chatlog, but nothing besides that. Any ideas? Never used triggers like this, always just did /sc commands to change variables or sets.

Turn on ShowGearSwaps to see what Spellcast is constructing. Add AddToChat lines within the rules section to see if it's actually reaching those points in the code. Make sure that you've defined gear in the sets that it expects to use, and that it's gear you actually have. Once you have a clearer idea of what it is doing, it's easier to figure out what it isn't doing.

[Sekundes]

So, reposting my question because I can't find the answer even though I thought I did-

Can't get my triggers to work. Setup macros a'la /ws "Dancing Chains" <t> to trigger certain conditions according to Nightfyre's NIN XML, but no matter what the gear doesn't swap. I get the echo text in chatlog, but nothing besides that. Any ideas? Never used triggers like this, always just did /sc commands to change variables or sets.

Turn on ShowGearSwaps to see what Spellcast is constructing. Add AddToChat lines within the rules section to see if it's actually reaching those points in the code. Make sure that you've defined gear in the sets that it expects to use, and that it's gear you actually have. Once you have a clearer idea of what it is doing, it's easier to figure out what it isn't doing.

Too add to this, if you really want to see what is going on and why you can skim through the debug log and watch the path it takes. If anything is overwriting your rules or isn't parsing correctly then you should be able to see it. I'm a little unorganized on my rules sometimes because I like using return commands so this helps me figure out if I screwed up.

[Nightfyre]

Now see, this is why I was confused about that buffactive midcast thing you were doing. I didn't think that worked, but from what I've read of your posts, you're competent enough for me to question myself if you think it works. XD

Just did some tests with debug on and I'm thinking I was mistakenly attributing to Spellcast behavior that was actually caused by AutoExec. I'm on a roll today

Precisely. Absolutely nothing is sent to the game until all precast/midcast/aftercast stuff is resolved. Once completed, nothing is changed at later time points. Can get around that somewhat by sending another command at a different time point to make it run through the rules section again.

Interesting... Yeah, going through the debug log I can see what you're saying.

[Ithorien]

Too add to this, if you really want to see what is going on and why you can skim through the debug log and watch the path it takes. If anything is overwriting your rules or isn't parsing correctly then you should be able to see it. I'm a little unorganized on my rules sometimes because I like using return commands so this helps me figure out if I screwed up.

Thanks for your suggestions, both of you. I'll give it a whirl.

[Darkmagi]

Is it just me or is it not canceling on ichi for anyone else? Not sure if I overlooked anything.

[Nightfyre]

I eliminated the automated cancel entirely earlier this evening in favor of a manual cancel triggered by casting Utsusemi (either one works) a second time mid-cast in order to alleviate the issue with Quick Magic procs and midcast cancels. Guildwork must have picked it up earlier. It's in the update notes now. I was going to experiment with Yugl and Motenten's idea tonight but it's late, I'll mess with it tomorrow. Haven't had any noticeable performance issues thus far even on my shitty computer but it'll be good practice for working with some more complicated scripts later. Besides, everything within 50' of me has tried to blow up at one point or another today