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

Masamune · 2011-10-21 12:23

oooops i didnot see your answer on next page lol :s
i edited my previous post.

Yea good point for resting set i didnot look over it yet, currently resting set is empty lol, but you have a point there indeed (especially if i'm /mage resting for MP)

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

Originally Posted by Masamune

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...

You should not be seeing that. <cancelspell /> means that the check (Blizzaga V for Syco's, Libra for mine) never actually gets sent to the game. If you're seeing "...A command error occured." then something is wrong with the xml.

**Yugl** · 2011-10-21 13:53

Originally Posted by Motenten

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.

It just looks like we're approaching it from different playstyles since the need to hit a KeyBind for stuff such as Idle/PDT/MDT/EVA means I need to drop the controller (Subsequently, movement, macros, and menu) to use them or, at minimum, change accessories which means I have to ignore what is going on to look at the keyboard for the relative bind (No touch typing while holding a controller!). At the same time, I see how it is incredibly beneficial for you to have them on keybinds because it means less repetition of macros, more macro space, and macros are best for class specific stuff since you don't need to write complex binds. Since it comes down to Gamepad v KB, we cannot reconcile this by looking at which is more convenient since convenience depends on which accessory you use.

That said, we should return to the original debate which was whether to designate other class's abilities/spells to class specific or to use some of the universal triggers. In the event that you use controller, universal triggers are helpful since you need to keybind them and keybinding is relatively "permanent." In the event that you use keyboard, other class's abilities/triggers are helpful since they become macros (flexible) and without the controller limitation, it is actually an "unlimiting" option since you have a finite reserve of universals and a relatively larger number of other class's spells/abilities.

Compromise shouldn't be difficult, but we first need to move onto the next part of the discussion; namely, what do we want to place on triggers. I know you had a list a few pages back (~10 triggers I think), but I would like to reconfirm based on what we've discussed (Namely, the issue with designating TP-EVA as simply a variation of $LightArmor v Ability to add sets such as Convert or Breath to the list). If we can flesh that out:

- List all the triggers in terms of likelihood to remain a trigger (Top-bottom : Likely to remain a trigger-Less likely to remain a trigger)
- List trigger-functions (Like Kill Switch/PDT) in rank of class specificity (Top-bottom : Least class specific-Most class specific)
- Assign for all non-class specific triggers, we can grant the triggers from the top of the triggers list + X blanks (For future use) and then reserve the least stable triggers for class-specific triggers (My idea is the BRD songs tbh); that way, the class specific are somewhat secure in terms of universality and the pertinent ones are incredibly secure

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.

I'll agree with that.

**Motenten** · 2011-10-21 15:16

Originally Posted by Yugl

- List all the triggers in terms of likelihood to remain a trigger (Top-bottom : Likely to remain a trigger-Less likely to remain a trigger)

Do you mean "remain a trigger" in the sense that SE won't make it user-castable (eg: adding -ga5's)?

If that's the case, we already have it pretty well defined:

99.9% safe (unless SE lets Blue Mages learn some fomor ability):
Shackled Fists, Vulcan Shot, Carnal Nightmare, Grim Halo, Aegis Schism, Netherspikes, Foxfire, Barbed Crescent, Dancing Chains

99.8% safe:
Banishga V, Poisonga IV, Poisonga V, Diaga IV, Diaga V, Bio V, Dia V, Poison V, Banish V

99.5% safe:
Stonega V, Waterga V, Aeroga V, Firaga V, Blizzaga V, Thundaga V

99% safe:
Banishga IV, Poisonga III, Diaga III, Dia IV, Bio IV, Poison IV

Safe in the sense that players have no use for the spells:
Scop's Operetta, Puppet's Operetta, Herb Pastoral, Shining Fantasia, Goblin Gavotte, Tranquility, Equanimity

9 tier 1
9 tier 2
6 tier 3
6 tier 4
5 brd songs, 2 JAs

Originally Posted by Yugl

- List trigger-functions (Like Kill Switch/PDT) in rank of class specificity (Top-bottom : Least class specific-Most class specific)

XML utility:
Reset
Equip/aftercast

Defense utility:
Kiting
PDT
MDT
MDT mode
Kill switch

Offense utility:
Target difficulty (including accuracy)

Relevant to melee:
TP mode
WS mode
Distance for weaponskills
Light armor mode & switch

Specialized (and may be integrated into other set configurations)
Convert
Breath sets (drg & blu)
HP set (weakness; may be nearly the same thing as breath sets)

Originally Posted by Yugl

- Assign for all non-class specific triggers, we can grant the triggers from the top of the triggers list + X blanks (For future use) and then reserve the least stable triggers for class-specific triggers

The two XML utility triggers should be top-tier.
Reset: Grim Halo
Equip/aftercast: Dancing Chains

The defense utility triggers are broadly generic, and should probably be considered top-tier.
Kiting: Foxfire
PDT: Netherspikes
MDT: Aegis Schism
Kill switch: Barbed Crescent

That leaves 3 additional tier 1 triggers. Will set those in reserve.

I'd like to reserve 8 spells for elemental triggers (mainly for MDT, but it's possible to use them for more than that; eg: Abyssea procs). This pulls tier 3 and a couple from tier 2:
Stonega V, Waterga V, Aeroga V, Firaga V, Blizzaga V, Thundaga V, Banishga V, Bio V

Other than the elemental triggers, we have the following tier 2's:
Poisonga IV, Poisonga V, Diaga IV, Diaga V, Dia V, Poison V, Banish V

These can be assigned:
TP mode: Dia V
WS mode: Banish V
Distance for weaponskills: Poison V

Remaining configurations are not yet well defined:
Target difficulty (including accuracy)
Light armor mode & switch
Convert
Breath sets (drg & blu)

Though TP Mode also has some ambiguity to it, even if evasion and accuracy are removed from TP Mode it still has other uses (dex build, melee vs tanking for pld, etc), so a trigger for it is explicitly provided regardless.

Currently unused tier 1:
Shackled Fists, Vulcan Shot, Carnal Nightmare

Currently unused tier 2:
Poisonga IV, Poisonga V, Diaga IV, Diaga V

Unused tier 4:
Banishga IV, Poisonga III, Diaga III, Dia IV, Bio IV, Poison IV

So now we just need to untangle the hairball that is Target Difficulty and Light Armor.

**Syco** · 2011-10-21 17:13

I'll agree with Mote on that seemingly exhaustive list, and on the assignments so far.

I've spent today digging through each of your includes and a few of each of your JOB.xmls, trying to see what's already essentially in agreement and what needs to be agreed-upon, and you've fairly well summed it up with your final line,

So now we just need to untangle the hairball that is Target Difficulty and Light Armor.

In response to Yugl's questions, I'm a keyboard onry guy, which I guess is why I so readily agreed with Mote on the keybind issue - it shouldn't be too hard to implement the common stuff and then have a "PlayStyle" var in the [hopefully merged & streamlined] include which calls one implementation of the differing rules for %PlayStyle="Gamepad" and %PlayStyle="Keyboard". That or have a Keyboard_Include.xml and Gamepad_Include.xml and you use whichever suits.

I'm also on board with the "keep the killswitch" idea, I've found it useful. I've a suggestion in this regard, though:

Would you object to a "First in, last out" gear approach (let's call it the FILO button), alongside/instead of a killswitch?

Example: I'm fighting HighAccNM.
I go in with my standard TP gear Queue{0:None}, but realise my shadows are being stripped too quickly.
I then hit my Evasion Switch Queue{0:None,1:Evasion}.
The mob readies a physical WS that ignores shadows, so I hit my PDT Switch Queue{0:None,1:Evasion,2;PDT}.
WS goes off, I recast shadows and hit my FILO button Queue{0:None,1:Evasion} and my Evasion gear is re-equipped.
The mob then casts Firaga V, so I hit my MDT Switch and augment it with FireResist set (whether by cycling or switching, doesn't matter) Queue:{0:None,1:Evasion,2:MDT}.
The spell goes off, I throw up :Ni and hit my FILO button Queue{0:None,1:Evasion} and Evasion gear goes on again.
The mob is then killed, and I hit my FILO button Queue{0:None} and I'm in my normal gear, ready to equip regular TP gear on next mob.

This might be more trouble than it's worth, but in the example where PDT gear is on it requires hitting either:
- Killswitch then Evasion Switch.
- Toggling PDT off.

Obviously it doesn't change anything if you're a toggler, but if you're a killswitcher it removes the secondary keypress. It'd remove even more extra keypresses if you had any Target Difficulty stuff to reset after removing PDT too.

@ Masamune: I think I read your thing right, but responded ambiguously, sorry!

...then i reengage and kill the mob, on disengage i go into IdlePetEngaged instead of IdlePetIdle... i had to rest to trigger that also.

From what you said, I read that Engaged to Idle did indeed proc - you went from Engaged to IdlePetEngaged. Correct me if I'm wrong here.

What didn't proc was it picking up that your pet wasn't engaged anymore.

This should be to do with the order of the calls within your SpellCast. Try replacing your autoset with the below code.

Spoiler: show

However, if it's because game mechanics mean Engaged changes to Idle fractionally earlier than IsInCombat changes from 1 to 0, this won't work no matter how you order it using conventional methods. If this is the case, try this:

Spoiler: show

**Motenten** · 2011-10-21 18:21

@Syco:

That... is an incredibly interesting idea.

That also allows dynamic layer stacking order. Rather than having a fixed $Evasion|$PDT value, depending on ordering you could equip things are $PDT|$Evasion (or PDT|MDT vs MDT|PDT, etc).

With the full killswitch idea you could turn on Evasion, then turn on PDT, but when you hit the killswitch both would be wiped and you'd have to turn the one you wanted back on.

With the toggle mode you could turn each one on and off individually, but the stacking order would always be fixed; you couldn't choose which one would take priority.

With this you don't have to deal with toggles if you don't want to, but are still able to individually remove layers, -and- you can put the layers on in the order you want.

The coding for it will be moderately complex because XML isn't well suited for dealing with these types of data structures, but it's completely doable.

Interested in hearing Yugl's thoughts on it. Will write up the code to make it work just as a little exercise. Still need to consider the other issues, though, as that can impact this.

**Yugl** · 2011-10-21 18:45

To be honest, I find TP-EVA compatible with PDT, but a full EVA set is ultimately mutually exclusive with PDT. If you want PDT in your full evasion set, then it should be in the set. Don't forget that these sets override, so it's not as if we're talking about equipping minimal EVA + PDT for the rest; traditionally, people will maximize PDT or EVA (Slots unfulfilled usually go towards the other). Given that, a VAR-TP including EVA seems more reasonable since all you need to do is switch to TP-EVA and you can easily go between PDT and Full Evasion. If you hit the Kill Switch button, you'll go back to TP-EVA. Also, TP-EVA means we avoid the problem of piping other sets.

Also, I made a chart for the trigger spells:

Code:

Fomor Abilities     Effect
Shackled Fists
Vulcan Shot
Carnal Nightmare
Grim Halo           Rset
Aegis Schism        MDT
Netherspikes        PDT
Foxfire             Movement
Barbed Crescent     Kill Switch
Dancing Chains      Aftercast

Magic Spells        Effect
Firaga V            Fire-Resist
Stonega V           Earth-Resist
Waterga V           Water-Resist
Aeroga V            Wind-Resist
Blizzaga V          Ice-Resist
Thundaga V          Thunder-Resist
Banish V            WS Distance
Bio V               Dark-Resist
Bio IV
Poison V            VAR-TP
Poison IV
Poison III
Poisonga V          VAR-WS
Poisonga IV
Poisonga III
Dia V
Dia IV
Diaga V
Diaga IV
Diaga III
Banishga V          Light-Resist
Banishga IV

Bard Song           Effect
Scop's Operetta     Class Specific
Puppet's Operetta   Class Specific
Herb Pastoral       Class Specific
Shining Fantasia    Class Specific
Goblin Gavotte      Class Specific
Tranquility         Class Specific
Equanimity          Class Specific

Also, convert doesn't need a trigger spell unless the toggle method has no means of reverting to idle gear at any time desired. Breath is a class specific trigger and only applies to BLU (DRG's breath move is different). If you're worried about a HP set for recovery, I would have a user defined variable with the option of using a HP set. You can then trigger this via AutoExec for equipping the set. Personally, I prefer Twilight Set for classes that can use it, so I plan on keeping that as a class specific trigger.

Edit: For your Element-resist sets, what did you have in mind? Use the element to equip the set or set the element value. If setting the value, we need a way to blankslate the value.

**Landsoul** · 2011-10-21 19:49

HTML Code:

    <if type="weaponskill">
      <if spell="Ukko's Fury">
        <if buffactive="Berserk|Attack Boost">
          <equip when="precast" set="ukko-berserk"/>
          <addtochat when="precast">:: [Warrior Ukko's Fury set w/ Berserk] ::</addtochat>
          <equip when="aftercast" set="5-hit" delay="1"/>
          <addtochat when="aftercast">:: [Warrior 5-hit set] ::</addtochat>
        </if>
        <if buffactive="Mighty Strikes">
          <equip when="precast" set="ukko-max"/>
          <addtochat when="precast">:: [Warrior Ukko's Fury Full Buff set] ::</addtochat>
          <equip when="aftercast" set="5-hit" delay="1"/>
          <addtochat when="aftercast">:: [Warrior 5-hit set] ::</addtochat>
          </if>
        <else>
          <equip when="precast" set="ukko-normal"/>
          <addtochat when="precast">:: [Warrior Ukko's Fury set without Berserk] ::</addtochat>
          <equip when="aftercast" set="5-hit" delay="1"/>
          <addtochat when="aftercast">:: [Warrior 5-hit set] ::</addtochat>
        </else>
      </if>
    </if>

How can I fix this code?

Basicly what I'm trying to do is If;
Berserk|Attack boost is up use ukko-berserk set.
Mighty Strikes is up use ukko-max set.
If none of the abovementioned buffs are up use ukko-normal set.

Thanks in advance !

**Syco** · 2011-10-21 20:01

I'm glad you both understood where I was coming from, at least.

I take your point, though, Yugl. There's a lot of mutual exclusivity so it might even be worth making the PDT and FullEva sets include a killswitch in each call (for a one-button switch), whilst allowing MDT over-stacking. I'm not sure which way would work best.

If we don't think the ElementResist triggers would work best straight-up equipping the Ele-set, how about double-call the same element to blankslate? Saves an non-elemental trigger, but you want to be able to pre-tweak your MDT before fighting a Fire-based NM, for example.

**Yugl** · 2011-10-21 20:04

There's a buff called Attack Boost? Also, put Might strikes stuff before the berserk set and do a string of <if> <elseif> <else> instead.

Originally Posted by Syco

I'm glad you both understood where I was coming from, at least.

I take your point, though, Yugl. There's a lot of mutual exclusivity so it might even be worth making the PDT and FullEva sets include a killswitch in each call (for a one-button switch), whilst allowing MDT over-stacking. I'm not sure which way would work best.

If we don't think the ElementResist triggers would work best straight-up equipping the Ele-set, how about double-call the same element to blankslate? Saves an non-elemental trigger, but you want to be able to pre-tweak your MDT before fighting a Fire-based NM, for example.

Not sure what you mean in the second paragraph. I agree with the ElementResist idea though.

**Syco** · 2011-10-21 20:16

Originally Posted by Landsoul

How can I fix this code?

Basicly what I'm trying to do is If;
Berserk|Attack boost is up use ukko-berserk set.
Mighty Strikes is up use ukko-max set.
If none of the abovementioned buffs are up use ukko-normal set.

Thanks in advance !

It looks like it should work. A little re-ordering might help, though:

Code:

    <if type="weaponskill">
      <if spell="Ukko's Fury">
        <action type="castdelay" delay=".2" />
        <if buffactive="Mighty Strikes">
          <equip when="precast" set="ukko-max"/>
          <addtochat when="precast">:: [Warrior Ukko's Fury Full Buff set] ::</addtochat>
        </if>
        <elseif buffactive="Berserk|Attack Boost">
          <equip when="precast" set="ukko-berserk"/>
          <addtochat when="precast">:: [Warrior Ukko's Fury set w/ Berserk] ::</addtochat>
        </elseif>
        <else>
          <equip when="precast" set="ukko-normal"/>
          <addtochat when="precast">:: [Warrior Ukko's Fury set without Berserk] ::</addtochat>
        </else>
        <action type="aftercastdelay" delay="1.3" />
        <equip when="aftercast" set="5-hit" />
        <addtochat when="aftercast">:: [Warrior 5-hit set] ::</addtochat>
      </if>
    </if>

The delays there are ones I found accurate when I wasn't using constant WhenEngaged rules. Hopefully that'll be a little smoother. Test it by changing Spell=MightyStrikes to Spell=Defender or something.

**Landsoul** · 2011-10-21 20:24

Ok thanks I tried elseif before and wouldn't work, but its working now and good point putting Mighty Strikes on top.

And yes there is a buff called Attack Boost it comes from Stalwart's Tonic/Gambir.

**Syco** · 2011-10-21 20:32

@ Yugl:

I mean say your engaged set is StandardTP. You pop MaxEva and it overwrites whatever slots of StandardTP you've chosen. You then pop PDT which turns MaxEva off and PDT on. (Whether this sets a MaxEva variable to 0 and a PDT variable to 1, or changes a HeavyArmor variable from MaxEva to PDT doesn't matter). Like you said, if you want PDT in your MaxEva set, put some in when you're defining your set.

However, MDT is generally thrown on in response to a spell, rather than fulltimed for a whole period in a fight (Chainspell excluded), so we're likely to want to throw MDT on and off. Whether it's a one-button toggle or a MDT-On button and a De-Stack button like I described before doesn't really matter, but in panic situations you're likely to mash your MDT button so having an MDT-On-Only button would make sense. Finding other uses for the De-Stack button would argue away the space it takes up on your keyboard.

Essentially the Set-Stacking stuff is only worthwhile if there're several orders of combining gearsets. If the only optional overlays are HeavyArmor (either PDT or MaxEva - toggle between them) and MDT it's not worth implementing.
However, if we're also gonna overlay MaxAtt, MaxAcc and other variations of gear then it's worth thinking about making a combination-stack as it's easier to dump the last addition with one keypress than kill everything and reapply 3+ options individually.

**Yugl** · 2011-10-21 20:43

Well, it's still going to be worth implementing (necessary even) since you're really looking at:

TP-$TypeOfTPSet|Armor|Movement

The kill switch only affects Armor and Movement. The switch might affect other stuff such as Convert sets and Breath sets (TP-$TypeOfTPSet|Conv|Breath|Armor|Movement), but you would always maintain the damage configuration you choose until you rotate the TP set. The decision to use higher attack or ACC would be two different systems. Regular mobs/HNMs are the groups for "Attack" (Though not specifically attack; just whatever would be better against HNMs rather than trash mobs). You can then have TP-ACC for each group, which amounts to four accuracy variations. Neither the group nor the ACC would be damaged upon using the kill switch.

**Motenten** · 2011-10-21 21:41

You have two entries for WS Distance: Shacked Fists and Banishga V.

Also, I choose Banishga V for the light element trigger to keep similarity with the other -ga spells. Only reason I didn't for dark is that there aren't any available -ga dark spells. If there's no particular reason to change it to Banish V, can just keep it as Banishga V for the similarity.

You didn't include anything for a kill switch or a reset trigger. Barbed Crescent's "TP or Idle" is somewhat vague in its meaning.

Also, convert doesn't need a trigger spell unless the toggle method has no means of reverting to idle gear at any time desired. Breath is a class specific trigger and only applies to BLU (DRG's breath move is different).

You said you wanted "more class-specific" triggers at the bottom of the list, so I just tossed anything else I could think of down there. You hadn't provided your own examples yet.

If you're worried about a HP set for recovery, I would have a user defined variable with the option of using a HP set. You can then trigger this via AutoExec for equipping the set.

Well, it's actually a $WeaknessSet more than an HP set. Just wasn't really thinking in those terms as I wrote it. And no, it's not explicitly triggered; it's updated on $Reset (I do not use AutoExec).

Edit: For your Element-resist sets, what did you have in mind? Use the element to equip the set or set the element value. If setting the value, we need a way to blankslate the value.

For elemental resists, it only sets the value; it doesn't equip the set. You can set the value and then use the MDT switch to toggle the MDT set on and off (if you set the value while MDT is on it will switch to that element, though). Much simpler that way.

For blankslate, you mean setting a general MDT set that's not aligned to any particular element? Yes, I can see that being useful. If we use Banishga V for light element, Shackled Fists for ws distance, Poison V/Poisonga V for TP/WS types, then we can use... Diaga V for neutral element selection?

To be honest, I find TP-EVA compatible with PDT, but a full EVA set is ultimately mutually exclusive with PDT. If you want PDT in your full evasion set, then it should be in the set. Don't forget that these sets override, so it's not as if we're talking about equipping minimal EVA + PDT for the rest; traditionally, people will maximize PDT or EVA (Slots unfulfilled usually go towards the other).

So, essentially what we want is triggers for:

Physical defense mode (cycle trigger): PDT, evasion, counter, shield
Physical defense switch
Magical defense mode (keyed trigger): specific element, or generic
Magical defense switch

And I agree with Syco; the vast majority of the time MDT will be a short term override of PDT, so there's no real need for the complex stacking methodology I was considering. However with only two layers, being able to kill one layer at a time is probably a good idea. Put up MDT or PDT and kill switch takes it off; put up both and kill switch takes off MDT first, leaving you with PDT. Hit a second time to clear back to no extra armor.

You may also want an easy way to directly specify the physical defense mode though, instead of cycling. Have to give that more thought.

In essence, we're getting rid of LightArmor+HeavyArmor and replacing them with PhysicalArmor+MagicalArmor. Equip stacking would be TP~|$PhysicalArmor|$MagicalArmor|$Movement instead of TP~|$LightArmor|$HeavyArmor|$Movement.

Given that, a VAR-TP including EVA seems more reasonable since all you need to do is switch to TP-EVA and you can easily go between PDT and Full Evasion.

At this point we're back to allowing the user/job to fully define which modes are relevant. TP-EVA is generally pretty meaningless for mnk (though a full evasion kit can still be useful) or pld, but far more useful for dnc or thf. However the code for cycling the mode can be kept in the include as long as the variables are properly defined.

The kill switch only affects Armor and Movement. The switch might affect other stuff such as Convert sets and Breath sets (TP-$TypeOfTPSet|Conv|Breath|Armor|Movement), but you would always maintain the damage configuration you choose until you rotate the TP set.

I don't think the kill switch should affect movement. That's already been reworked to automatically be killed when you disengage (though since idle mode will have movement gear on anyway, it's not detrimental should you become disengaged while still kiting a mob).

And adding additional sets that the kill switch will reset is fairly easy to do programmatically.

~~ working on some more code.

**Yugl** · 2011-10-21 22:04

I actually think Syco's idea for removing the MDT element is pretty good. He just makes it so that hitting the relative element twice undoes the element [EX: Hit Firaga V => Set variable to MDT-Fire => Hit Firaga V => Set variable to MDT-Null]

The kill switch wouldn't null the movement variable. What I typed is how the set up with look if using breath sets or w/e. The "kill switch" just sets you up for TP/Idle without armor or wonky stuff basically. Movement and VAR-TP should remain the same.

I'm still not sure of the benefit of killing one layer at a time. At any given moment, a player is either going to want full PDT, full MDT, breath set, convert set, or full evasion, but not any combination of those. The TP set can underlie all of these, but that doesn't require removing one set one-by-one. Even if it doesn't allow us to keep the $VAR-TP stuff in the main class's XML, it's better to just define class-by-class rather than trying to impose a uniform set of TP sets for each class.

**Diablosword** · 2011-10-22 02:13

Sorry if this is somewhere on the previous 174 pages, but does anyone have a decent BLU XML that has AoE burning and normal every day BLU stuff in it?

**Yugl** · 2011-10-22 02:14

http://www.bluegartr.com/threads/107...st-XMLs-Thread

Masamune · 2011-10-22 04:27

Good monring all

I passed a few hours yesterday trying to debug Mote's draft code, because it doesnot work (PetStatus never changed), to finally going back to my code but adding the best of Syco and Mote ideas (Isincombat + CheckOnPet). This mix gave me the below code:

Spoiler: show

So this mixed up code is doing perfectly what i want except one little slight glitch..... pretty annoying :

when mob dies (either from pet or me), the var PetStatus turns back to PetIdle properly as intended but.... not the gears lol... ie the rule <equip set ...> doesnot process...
i'll insert an autoset rule somewhere according to Syco last post (2nd sample code). I'll update this post later on today...

EDIT: tested Syco's 2nd code sample "as it is", doesnot work properly:
- after charming a mob, i stay in Charm set...
- after i fight my pet on a mob, i stay in IdlePetIdle gears...
- after mob is dead, i stay in IdlePetEngaged (and var PetStatus stays = PetEngaged...)
all the above scenarios requires me to rest to make things swap gears...

Thanks again both Mote/Syco.

IMPORTANT EDIT:

Just discovered something very interesting by mistake.
Some posts earlier, Mote learnt me i could avoid those annoying "...A command error occured." messages in game from using trigger spells, with just inserting a <cancelspell/> in the xml...
Since i m using a trigger spell from autoexec for losebuff sneak or trick attack, i inserted a <cancelspell/> in my THF.xml and magic no more annoying message !! but... i werenot returning to engaged set anymore after that trigger spell occured o.O
i remove the <cancelspell/> all works again properly o.O...

So i came back to my bst.xml code i posted above and removed the <cancelspell/>, and it FINALLY WORKS !!! but with annoying "command error occured" messages each 5secs...

i tried putting that cancelspell in the very end of xml, didnot change the problem, still didnot parses the rules "equip set"...

Any alternative solution ?

**Syco** · 2011-10-22 11:56

All I can say is <cancelspell /> works fine for me, and parses everything correctly.

Make sure you're using <cancelspell /> with a space between the last letter and the forward slash, as opposed to the space-less <cancelspell/> that you typed above.

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