For Ranger and Cor I made Macros for a single shot and X-Hit (ie /range x 4 to 100TP) this way I don't get stuck trying to time a WS as you mentioned. My biggest problem has always been not being able to account for those trickey Rapid shots, that wind up doing me no good as it will still take me the same time to build enough TP with an autofire macro.

edit: I'm dumb, just realized I was at 2.44 still and needed to update to 2.45.
edit2: updated and issue is still there, distance trigger isn't working and a few of the other triggers won't either. Idle set is staying in town idle regardless of area as well. Have confirmed that attempting to stun in quick succession crashes me every time as well.

Yugl is those beta s-series able to even run in sc 2.45? I see some calculations and such and didn't even know spellcast had those capabilities. From the looks of it your trying to create a single include file that handles just about any job or situation, which is something I am working on but in a much simplier fashion (mainly cause didn't know alot of alot of what im seeing in yours is possible in SC). If you can give any feedback on what your working on, requirements and such would be appreciated.

The S-Series XML you see is the upcoming XML and will run on 2.45 (Current testing has it working). Basically, I've bundled most stuff I need into a single XML so I can reference that template when making new XMLs. Unlike traditional templates though, I prefer a packed XML so that I can just delete what I don't need instead of having to remember to add to each XML.

Can you set include rules within other include rules? functions calling other functions sorta thing.
Example-
<include name=magic>
----statement
----statement
----<xi:include pointer=ninjitsu/>
</include>

Awsomenessssssss..... if i can get some help, j/k.

First id like to say this thread was long past due, before i quit i remember always comming and wishing this forum had a thread with up to date .xml's, so cudos to those running and maintaining this part of the forum/thread.

Now then lets get down to buisness shall we?, i recently (yesterday) came back to playing the game after a 1 year rest. I say rest as we all know we are doomed to die with ffxi in our hearts, lol., So im trying to get spellcast along with all its goodies fixed so i can start playing again, but i have noticed an ginourmous amount of new (for me @ least) stuff. I.e. Include's, GearCollector, and Binding keys. Again i Remember vaugly how to use them, gearcollector is def. a first i also noticed itemizor plugin, anywho these are things im trying to reaquiring knowledge of, and im posting here to see if anyone would be kind as to help me find a page/website were it explains a bit more in detail. Shouldn't take much to understand it as i do know some of how it works, so if anyone can help even if possible maybe a skype call to just quickly explain some stuff, id be much appreative. Again Great job and have a great day.

Found two major flaws in my spellcasts that led to the horrendous lag people have noticed. After correcting them, play is *much* smoother.

1) I used an inherited group for a handful of sets that the code potentially depends on, but didn't want to force people to remember them or need to add them for irrelevant stuff. Well, Spellcast, when it's searching for a set, searches the entire base group before searching the current group. With 5-10 sets searched for on every action (due to the way I construct $CurrentSet), this increased the amount of searching Spellcast had to do a good bit.

Fix: I no longer use the Base-Group. I'll keep it in the include for reference, and then just copy all those sets when constructing a new xml. The other derived groups (eg: Abyssea-Group, Salvage-Group, etc) will still go through this process, but since most of the sets will be in the base group that's being searched (rather than almost none of them), while the number of sets in the child group are small, this should have a much lower impact on performance.

2) When finally equipping sets, I had the following code in the Include file:

This seemed reasonable, as I expected it to do nothing with the "idle|engaged" equip command for any normal actions. Turns out I was wrong. $CurrentSet was expanded and constructed for that line even though it wasn't being used. Essentially, it was doing a whole lot of wasted work that was just getting thrown out, and all that work really bogged things down.

A test run on thf in Dynamis, where I've been having a lot of this lag problem lately, pretty much cleared out the problems entirely.

Note: I also switched away from the aftercast command that was previously used to (hopefully) alleviate lag. With this change it isn't needed anymore (at least on my system).

Aside from that I also streamlined a bit of the normal processing code, so might get a tiny bit faster from that.

Anyway, I'm noting this here so that people can tweak their own copies and receive the benefits of this change. Unfortunately I'm also in the midst of two other changes to my code, so just uploading my current copies will break things for people.

Other changes I'm working on:

At Yugl's suggestion, I'm splitting up my Include file into two files: Mote-Config-Include.xml (which just includes vars and set definitions) and Mote-Rules-Include.xml (which just includes rules). I think this will be a bit easier to manage. Be sure to get both files when the changeover occurs.

I'm changing several custom trigger parameters to start with periods if they were previously single words. This is to prevent problems with Spellcast automatically matching it with the name of a player, mob or object nearby. EG: "Manual" -> "Field Manual"; changing to ".Manual". "On" -> "Clionid"; changing to ".On". Etc.

That will also require changing some of the keybinds I suggest in the reference notes.

The above mentioned changes have now all been implemented in my spellcasts, and uploaded to Pastebin. The single Mote-Include.xml file has also been modified with the new changes, if you just want to download that rather than reconfiguring your job xml from a newly downloaded version. Just make sure to make the other tweaks that were mentioned, and update your init.txt keybindings.

NOTE: This is not official material for Spellcast. This is something I wrote up for my own use, and I'm sharing in case anyone is interested.

This is a means of refining the validation of the XML you write, beyond mere well-formedness. Well-formedness can tell you whether you closed all your tags correctly, and can be tested by just opening the XML in Firefox. It cannot, however, tell you that you left off the opening <if></if> before a set of <elseif></elseif> blocks. It also can't tell you that "preecast" isn't a valid value for the 'when' attribute. That's where schema validation comes in.

I'm using this by editing in Visual Studio (should work with the free Express version too, which you can download from Microsoft). Other validators may also work, but I haven't tested them, so YMMV.

You need to do the following two things in order to make this work:

1) Copy the following files to the directory you store your Spellcast XMLs: spellcast.xsd (the one I wrote) and XInclude.xsd (this file is from w3.org, and copied locally so that it doesn't cause your computer to do network lookups every time you change something). They are available from my pastebin page.

2) Change the opening <spellcast> element of any given .xml from the typical:

When you open your spellcast XML (eg: mnk.xml) in Visual Studio, it will map to the identified schema by default. You can change this mapping (right click in the code window and select Properties, and you can edit Schemas), but generally there shouldn't be a need to.

Visual Studio will then provide a list of warnings for any errors it finds, and keep it updated as you code. The schema also provides info for IntelliSense to use, which means it will automatically pop up valid elements and attributes as you write your code.

The primary limitation is that XML Schema validation is case-sensitive. That means that the <config> element is different from the <Config> element is different from the <CONFIG> element. Unfortunately the only way to get around this is far too cumbersome with as many elements and attributes as are available in Spellcast (along with the varying casing options for each value). Because of that, I just went with full lower case for everything (eg: spelltargetraw instead of SpellTargetRaw), despite personal preferences, as having multiple options felt like it would just be confusing.

I did, however, put in the work to allow some case-insensitivity for most attribute values that have specifically defined lists. As such, you can use element="fire", element="Fire", or element="FIRE", and they're all considered valid. You just can't use Element="Fire" (capital 'E' on Element).

In addition to the standard Spellcast game values that are allowed in <if> checks, I also included the RadSources Trigger-type values. So things like type="Trigger" or skill="ElementalTrigger" are valid.

I've also built a validation scheme for Include files, though there are some restrictions due to ambiguity in the language definition.

1) The top-level elements under the <include> element must be one of: <group>, <set>, <var> (defining a variable) or any non-var (setting a variable) type of command/action. The <var> element that sets variable values cannot be at the top level of the include, though it can be contained inside an <if> block.

2) <include> blocks cannot directly include additional <xi:include> elements mixed with <group>, <set> or <var> (defining a variable) elements. Nested <xi:includes> can only be considered when matched with rules/commands.

For this, you need to have (in addition to the above XInclude.xsd file) a copy of spellcastInclude.xsd, and the top level <includes> element must be written as:

Caution: Now that I'm having a chance to go over implementing this in more detail, the schema validation isn't working quite as well as I'd hoped. So, anyone trying it, consider it very much 'beta' status.

All company, product, system names and/or company logos and marks are the registered trademarks or trademarks of their respective owners. The copyrighted material on this site is used under the Fair Use or Parody purpose. If you are the copyright holder and believe your material has been used unfairly please contact one of the forum administrators. Seriously don't be an idiot and send your lawyers after us before even trying to contact us. Blue Gartr forums NEVER encouraged any kind of piracy.Digital Point modules: Sphinx-based search