Thank you.
Thank you.
anyone know what is wrong with this xml? I am getting an around around line 348
http://pastebin.com/uaAJLaMY
http://pastebin.com/An2vi1au
First problem I have is when I use my Daurdabla toggle and I'm idling, it doesn't switch me to my idle set anymore. Second problem: when I use Troubadour/Nightingale I'm only allowed to cast 1 song via macro. Any macro after that acts like it's a blank macro basically and I have to either menu cast or manually type the spell while the JAs are up.
Posted this on GW also.
This is a bit sloppy. Doubt it's causing any issues but should probably be cleaned up nonetheless.Code:<elseif Spell="Vorpal Blade"> <action type="equip" when="precast" set="Vorpal"> </action> </elseif> <elseif Spell="Requiescat"> <action type="equip" when="precast" set="WS"> </action> </elseif>
Notepad++ isnt giving me any errors. What are you using that is complaining about line 348?
I keep getting a the same error with my Spellcast.
Spellcast: Did not find Set: Idle-$IdleDefense-Refresh in Group: SCH
My goal is to make a Hybrid idle set for SCH just like melee have Hybrid TP sets. So it will swap in certain key pieces if toggled. (terra,Dring etc)
Full SC http://pastebin.com/u/bwool40
Spoiler: show
I do see something funky here addtochat doesn't need input /echo but may just print it in game I ran an xml check and it came up okay.
<if mode="AND" EquipBody="empty" EquipHead="empty">
<addtochat color="4" >input /echo Nudity detected. Situation ameliorated.</addtochat>
<equip set="Standard" />
</if>
Notepad++ has a xml validation plugin I loaded yours into it firefox and chrome with no issue.
I've never used spellcast before and I'm attempting to create a toggle for PDT.
I thought this would work, but it doesn't seem to. I set it to toggle between PDT and MDT only to see if it would work. When pressed once, the value of pdtToggle should have increased from 0 to 1. Then 1 should have been added to the chat and the check cos(1*pi())=1 should have failed, at which point the second check should have passed, resulting in MDT gear being equipped. Instead what happened was that 0 was added to the chat log and PDT was equipped (it checked cos(0*pi())=1). Apparently, the value is incremented, but not immediately updated.Code:<if Spell="Tranquility"> <cancelspell /> <command>input /sc var inc pdtToggle</command> <addtochat>$pdtToggle</addtochat> <if advanced='cos($pdtToggle*pi())="1"'> <equip when="All" set="drg PDT" /> </if> <elseif advanced='cos($pdtToggle*pi())="-1"'> <equip when="All" set="drg MDT" /> </elseif> <return /> </if>
I then spammed the macro and to my disappointment nothing further happened. Equipping random gear and hitting the macro again also did not re-equip PDT gear, regardless of whether the variable was even or odd. It did show the value of the variable in the chat log, but always 1 less than it should have been.
What went wrong?
Man that has to be the one of the most complex ways to make a toggle:
if x==1
x = 0
else
x=1
I have been messing with toggling for gear stances. I had a similiar problem with gear not wanting to switch or at least not switching after only 1 of 4 sets i toggled thru. but i figured out what to do. I had 4 sets TreasureHunter, Melee, Accuracy, Evasion. I have a variable set to what i want to be the default. And since i want TH on to ping TH new mobs i just have the variable get set to TH everytime i go idle.
the magic happened when i put the equip portion after the rest of the code, before that it never worked even with a aftercast delay it never equipped for me. Also for the longest time i mispelled the gloves without realizing so i prolly had it right at some point but didnt know since what i was lookin for was a change of gloves mostly.Code:<var name="stance">TreasureHunter</var> <!-- Sets toggle for Treasure Hunter, Melee, Accuracy, or Evasion --> <if spell="Trigger1"> <if advanced='"$stance" == "TreasureHunter"'> <action type="var" cmd="set stance Melee" /> <addtochat color="158">[::::::::::EQUIP::::::::::] Equipment set to $stance Set [::::::::::EQUIP::::::::::]</addtochat> </if> <elseif advanced='"$stance" == "Melee"'> <action type="var" cmd="set stance Accuracy" /> <addtochat color="158">[::::::::::EQUIP::::::::::] Equipment set to $stance Set [::::::::::EQUIP::::::::::]</addtochat> </elseif> <elseif advanced='"$stance" == "Accuracy"'> <action type="var" cmd="set stance Evasion" /> <addtochat color="158">[::::::::::EQUIP::::::::::] Equipment set to $stance Set [::::::::::EQUIP::::::::::]</addtochat> </elseif> <elseif advanced='"$stance" == "Evasion"'> <action type="var" cmd="set stance TreasureHunter" /> <addtochat color="158">[::::::::::EQUIP::::::::::] Equipment set to $stance Set [::::::::::EQUIP::::::::::]</addtochat> </elseif> <equip when="Engaged|Aftercast" set="$stance" /> </if>
And anytime im engaged i have it set to equip $stance (except on thf i have other stuff there for sneak and trick attack being on when i engage)
EDIT: does putting cancel spell in the code there not stop the code or does it let the rest of it go thru while canceling the actual dummy spell? That would be nice if it worked as sometimes the trigger for the toggle will try to change gears.
Thanks for the responses. I thought trigonometric functions would actually be the simplest way to trigger the toggle since they're cyclical and it shouldn't take very long for a computer to calculate the cosine of something. It doesn't seem to work, though, so I think I'll use something like you've shown here.
It should. The windower wiki says it stops all commands related to the spell except for queued precast commands. If you canceled a spell set up with precast, midcast, and aftercast you should only see the precast go off. However, the cancelspell command isn't the same as the return command, so any statements following the spell command should still be run through before exiting the sub-statement.EDIT: does putting cancel spell in the code there not stop the code or does it let the rest of it go thru while canceling the actual dummy spell? That would be nice if it worked as sometimes the trigger for the toggle will try to change gears.
I borrowed the idea from one of Sylow's posts on ffxiah:
My goal was to create a spellcast that would equip varying ranges of PDT and accuracy, as well as having toggles for full PDT and full MDT armor. I named nine sets: TP00,TP01,TP02,TP10,TP20,TP11,TP12,TP21, TP22, and planned to put together various amounts of PDT and ACC. The first number would signify the amount of accuracy and the second would signify the amount of PDT. TP00 would be the base set (haste), while TP01 would be a hybrid set, TP11 would be a hybrid set with more accuracy, etc. I then named the set to equip when engaging TP$acc$pdt and planned to have spellcast increment the value of $acc and $pdt when I hit a keybind. Would something like that work? I'm going to try it out when I get home.Code:<if spell="Stoneja"> <cancelspell /> <if advanced='"$DD-Type"="PDT"' > <var cmd="set DD-Type DD" /> <addtochat color="100">Current TP Mode: $DD-Type</addtochat> </if> <elif advanced='"$DD-Type"="DD"'> <var cmd="set DD-Type PDT" /> <addtochat color="100">Current TP Mode: $DD-Type</addtochat> </elif> </if>
Motenten, I've been using your MNKr4 xml and I'm noticing the UseAggressive variable isn't switching to AggressiveLayer when AggressiveMode is set to ON. Is there a fix for this? I've looked at the Rules file and found a spelling error but fixing that still didn't seem to solve the problem.
I've actually been clearing out the use of that toggle. It would be better to create a different offense mode to deal with that, particularly since it's counterproductive to have it active with non-Normal defense modes. Plus it has a complicated mix of toggles and set references that make it confusing to use. It's probably not entirely functional in the most recent upload of the mnk xml, and will be removed entirely in the next upload.
However you're not accounting for the fact that Spellcast has to parse that text and translate it into functional code before it can even get around to trying to calculate the cosine. For a text system like this, your best choice is always pure text comparisons; your second best choice is numeric comparisons (this gets complicated when the numbers can become floats, leading to rounding errors); your third choice is function comparisons such as math functions or regexes.Originally Posted by TSFFXI
Sometimes the latter two are needed to do what you want, but you should first be sure that they are actually *needed* before going that route.
<cancelspell /> cancels the actual sending of the command to the game (and, by extension, any midcast or aftercast can't occur because the 'cast' never occurred). It does absolutely nothing about continuing to process the xml. You need to use <return /> to stop further processing of the xml code.Originally Posted by Trumpy
Yes, what you describe would work. It's fairly similar to what I set up on mine, where I have (simplified) TP-$OffenseMode-$DefenseMode, and then can cycle $OffenseMode through Normal, Acc and MaxAcc, and $DefenseMode through Normal, Evasion and PDT.Originally Posted by TSFFXI
I'm guessing the main thing that's going wrong is that you're expecting the <command> to affect the result of the comparison. The <command> won't happen until the precast time period, and will have no impact on the current iteration of the <if> check (or <addtochat> output) since the <if> necessarily occurs before precast.Originally Posted by TSFFXI
The second problem, which is that it will never change gear again after the first attempt, goes back to point #2 above -- using explicit numeric comparisons without considering the effect of floating point rounding. When $pdtToggle is 1, 1 * pi() = pi... for a given estimate of pi. Cos(pi) = 1 in math, but in this case it's cos(a number very close to the true value of pi) = (a number very close to 1). However I can pretty much guarantee that the result will never be *exactly* 1, which means your comparison will inevitably fail.
Edit: Actually, I just noticed that your comparison was advanced='cos($pdtToggle*pi())="1"', which means that you're comparing the numeric float generated by the cos function with the *string* "1". That will, of course, never succeed.
Assuming the above toggle system is designed to support your described acc/pdt system, I'd write it like this:
And cycle it with "/ma ClassTrigger PDT".Code:<var name="PDT">0</var> <if Spell="ClassTrigger"> <cancelspell /> <if SpellTargetRaw="PDT"> <if advanced='"$PDT"="0"'> <var cmd="set PDT 1" /> </if> <elseif advanced='"$PDT"="1"'> <var cmd="set PDT 2" /> </elseif> <else> <var cmd="set PDT 0" /> </else> <addtochat>PDT=$PDT</addtochat> <equip when="precast" set="TP$Acc$PDT" /> <return /> </if> </if>
Note that in this case it would also be acceptable to use numeric comparisons (advanced='$PDT=0' instead of advanced='"$PDT"="0"') since the contents of the variable can be considered exact integer values.
Thank you, Motenten. Also, I made another change that doesn't seem to work as intended. I added another group called "Impetus-Melee" and added the rules for it in the Fourth section of the rules. It doesn't seem to want to swap to the proper group when engaging, but it will use the proper set after I do another action, such as a job ability. Does the rule for it need to be under the Third section under Job Abilities? (I removed all the current rules you used for Impetus since layering Impetus gear over a current TP set wasn't feasilble for what I'm doing atm.)
Oh, I understand. Thanks, that's very helpful. I didn't realize that the command function would be queued and the if statement would be checked immediately.
I assume what really happened is that spellcast read through the rules section, found tranquility > queued the command to increment the variable > checked the if statement (using the yet to be incremented variable) > queued the equipment change. Then during precast it incremented and equipped.
I should have seen the float problem coming, though. Thanks.
To anyone: What is ClassTrigger? I came across the concept of trigger spells while reading through various spellcast forums, but I did not see any mention of that. It seems that it serves the same purpose except you can name it anything you like instead of being limited to existing spells. Is there any other function not mentioned in the windower thread for spellcast?
For the purpose of that sequence of commands, you'd want to just use the normal <var> command instead of a <command>:Originally Posted by TSFFXI
<var cmd="inc pdtToggle" />
That would execute immediately, in line with the rest of the xml code.
It's an extension of the general idea of using a game command that the job class in question would never use themselves, but allows you to initiate a pass through the xml while providing information about what you want to do. EG: using "Invincible" on any non-pld job to trigger equipping a PDT set.Originally Posted by TSFFXI
Open Windower/plugins/resources/spells.xml and go to the bottom of the file. Starting with id="10000" are all the trigger 'spells', which are commands you can use that Spellcast will recognize, even though they're not real game commands. These include trigger0 through trigger99, a set of elementally-linked triggers, several mode triggers, and a few utility triggers.
One of the triggers is ClassTrigger, which is conceptually intended for specialized use within a single job class xml (ie: you might use it for TH mode on thf, shield/pdt setup on pld, changing pet setup on bst, etc). The other triggers tend to be more generic, such as "Update" or "Reset" or "CombatMode".
Of particular note is that you can add one word after the spell in order to use it as a parameter, which you can access via SpellTargetRaw. So, in my above example, "/ma ClassTrigger PDT" becomes type="trigger", Spell="ClassTrigger", SpellTargetRaw="PDT". You have to be careful, however, since the parameter value can be usurped by Spellcast's autotargetting/parameter parsing. EG: "/ma PhysicalDefense on" becomes "/ma PhysicalDefense clionid" when performed near clionids. You can avoid the ambiguity by adding extra punctuation that can never be in a real player/monster/spell name (eg: "/ma PhysicalDefense .on").
As an aside, for the purposes of setting the PDT level, using the PhysicalDefense trigger is probably more appropriate than the ClassTrigger trigger.