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

[Esvedium]

0/1 is binary for off/on, so that is how I use them. Works for me, functionally sound, I'm going to keep it that way for my own xmls, but I are what you're saying about the logic, so I might change it up if writing xmls for non-programming people.

[Slore]

ignore previous post im a idiot, i had 2 diff directories for windower for trying to solve dual box issue and put my mnk xml in wrong folder. sigh i remember the days when i could dualbox for more then 10mins before 2nd windower crashed damn you to hell hook.dll

[Akyrey90]

since i didnt have time to test war xml till now, just found an error with the Restraint variable that i named RES: again old problem of another word starting in the same way, so spellcast was giving an error about the %area-Resist variable!
fixed that and testing everything in pt tomorrow i hope! here's the link: http://pastebin.com/F75U9DMh

[Cymmina]

I've used 0/1 for a while now in Spellcast and elsewhere, it's clearly functional. I try to maintain good practice/"style" in my code though, so sometimes minor aesthetic/backend design choices like this arise. Motenten makes a good point: yes/no or on/off are more explicit and thus friendlier to other users/coders and even yourself if you're working with a lot of code and don't immediately recall what each variable is doing. 0/1 is ambiguous; it could be a variety of things and you have to figure out which applies from the surrounding code.

How is 0/1 ambiguous? False = 0, True = 1 in every programming language I'm familiar with. If a variable is ambiguous, the name is the issue, not the value it contains.

[Yugl]

BLU XML updated to include Utsusemi > Occultation rule and sleep timers. You can copy/pasta your sets. No need to modify any of them.

[Suljin]

So been busy for a few months and havent played, suddenly I come back and am running around on sch (hardly played much before so its been a while) and spellcast is working fine other than it doesn't equip anything in my nuking set. It equips my staff and ugg. pendant when applicable but no other gear. But it does however equip stuff for cures/enfeebles/enh/etc. Any suggestions?

http://pastebin.com/Bxn81PAV

Bump, is anyone able to please help? I can't figure out why the elemental spells don't trigger equipment changes since I hadn't changed anything from a few months prior when they worked

[Yugl]

You have <if>UggyStuff</if> and <else>ElementalMagic</else>.

            <elseif skill="ElementalMagic">
                <if mppsftercastlt="50" advanced="$UggPendant == 1">
                    <equip when="Midcast">
                        <neck lock="yes">Uggalepih Pendant</neck>
                    </equip>
                </if>
                    <equip when="midcast" set="ElementalMagic" />
            </elseif>

Try that.

[Motenten]

How is 0/1 ambiguous? False = 0, True = 1 in every programming language I'm familiar with. If a variable is ambiguous, the name is the issue, not the value it contains.

The *value* is obviously not ambiguous, but the *meaning* (semantic value) is.

Here's a little illustration of the issue. Note that this does not directly apply to Spellcast rules being discussed, but it mirrors the same fundamental problem, and hopefully will be a bit more clear about why this approach is preferred.

Suppose I have a function call in my code:

UpdateWindow(true);

I know that UpdateWindow() redraws the window. However I have absolutely no idea what "true" represents in that context. To find out, I have to search the docs, or find where the function is defined in my code.

public void UpdateWindow(bool updateChildren)

Ahh. Ok, now we know what 'true' is for (though I'll undoubtedly forget it between now and the next time I need to mess with this code). Unfortunately, the information is only obvious at the function declaration, not at the location where the function is called. A better practice (not only for maintainability, but also for extensibility) is to create an enum to describe the option and use that as the parameter instead:

public enum WindowUpdateOptions
{
  SelfOnly,
  UpdateChildren
}

public void UpdateWindow(WindowUpdateOptions option)

And now at the point where you call the function, it's written as

UpdateWindow(WindowUpdateOptions.UpdateChildren);

And we no longer have a confusingly defined value. The meaning of the parameter is clear regardless of where you encounter it.

Internally the enum would be represented as SelfOnly=0 and UpdateChildren=1, which is exactly the same as if we passed in false and true; that is, passing in 1, true or UpdateChildren is all exactly the same in terms of value, but vastly different in terms of meaning, at least with respect to the human reading it, and that's the ultimate arbiter of its value.


So the point is not only to have variables whose names provide useful meaning, but to have those variables hold values that also provide useful meaning. The most difficult part of coding is maintaining, fixing and improving it after it's initially written. This is one of the ways to to make that much easier on yourself or anyone else trying to understand your code at some later point in time.

[JarNoBaka]

Not making promises, but after fixing RDM and BLU (Again, SCH is a logistic terror I'll need more time to work around) I think DRK, SAM, BST, and BRD are the ones not somewhat covered already? I'll need details on those though since I don't play them unless you want a "normal" spellcast for those.

i have DRK, pld and, Sam ones but i cant post urls <.<

they are based off of your stuff ill put them on my page on BG once i update them to make them more user friendly

i have BRD also but that one needs major updating its still 75 based lol

[Cymmina]

Internally the enum would be represented as SelfOnly=0 and UpdateChildren=1, which is exactly the same as if we passed in false and true; that is, passing in 1, true or UpdateChildren is all exactly the same in terms of value, but vastly different in terms of meaning, at least with respect to the human reading it, and that's the ultimate arbiter of its value.

This is a really bad example to illustrate your point. True/False is the same as saying yes/no, as in "do I have a thunder obi or not?" not "what staff do I equip when I cast thunder spells?" The former is appropriate for 1/0 (since there is only 1 possible option for thunder obis), the later is appropriate for enum (there are multiple options: thunder, jupiter, indra, etc).

Using $Utsusemi to describe whether or not you have it active is somewhat inappropriate. The names of ninjutsu spells do follow a numeric naming convention if you know Japanese, so int is more appropriate than bool in this case: 0 = none, 1 = Ichi, 2 = Ni, 3 = San.

[Nightfyre]

Using $Utsusemi to describe whether or not you have it active is somewhat inappropriate. The names of ninjutsu spells do follow a numeric naming convention if you know Japanese, so int is more appropriate than bool in this case: 0 = none, 1 = Ichi, 2 = Ni, 3 = San.

In context there's only two functional values. Either the spell being casted is Ni and thus my cancel rules need to kick in if I cast Ichi next time, or it's Ichi/my shadows wore off and thus they don't (though in retrospect I don't think I had AutoExec set up to cover no shadows). Regardless, it's legacy code because I moved to a manual cancel a while ago and as such I'm removing it from my xml.

[Yugl]

i have DRK, pld and, Sam ones but i cant post urls <.<

they are based off of your stuff ill put them on my page on BG once i update them to make them more user friendly

i have BRD also but that one needs major updating its still 75 based lol

I'll post a completed XML thread in the near future and grab/credit your XML. A quick glance at the DRK XML shows that the script looks good, but I would recommend changing to V3 in order to avoid lag on lesser end systems.

[JarNoBaka]

I'll post a completed XML thread in the near future and grab/credit your XML. A quick glance at the DRK XML shows that the script looks good, but I would recommend changing to V3 in order to avoid lag on lesser end systems.

yeah sounds good im working on doing that with drk/pld/sam/brd now

[JarNoBaka]

Updated DRK

pld/sam/brd need work tho lol sam next

[JarNoBaka]

Oh also i just double checked and This wasnt working and still isnt so if someone knows the right way to do it much love if i could get a hint

        <if Advanced='"%EquipMain"="Caladbolg" AND "$VARSTYLE"="Scythe"'>
            <var cmd="set VARSTYLE GS" />
            <addtochat color="135">Great Sword Art</addtochat>
        </if>
        <if Advanced='"%EquipMain"="Twilight Scythe" AND "$VARSTYLE"="GS"'>
            <var cmd="set VARSTYLE Scythe" />
            <addtochat color="135">Scythe Art</addtochat>
        </if>

[Sirenia]

Anyone have a nice THF spellcast?

[Rehwyn]

Anyone have a nice THF spellcast?

I've recently started using Motenten's and it's working like a charm. Includes the best implementation of SATA and TH rules I've seen so far (thanks Motenten ^^).

http://pastebin.com/u/Motenten

Make sure you get mote-include as well from the list.

[Motenten]

@JarNoBaka: I'd write it as:

    <if EquipMain="Caladbolg" advanced='"$VARSTYLE"!="GS"'>
        <var cmd="set VARSTYLE GS" />
        <addtochat>Style: Greatsword</addtochat>
    </if>
    <elseif EquipMain="Twilight Scythe" advanced='"$VARSTYLE"!="Scythe"'>
        <var cmd="set VARSTYLE Scythe" />
        <addtochat>Style: Scythe</addtochat>
    </elseif>

Which allows you to more easily add in other weapons for each type (and just generally seems cleaner, to me). It also fixes the issue of VARSTYLE possibly being some value other than GS or Scythe (ie: whatever default value is set in the include, or possibly carried over from a previous job xml), in which case both of your rules would fail. And finally, there's no need for two IF checks; if the first succeeds, there's no need to check the second. Thus, changed to an ELSEIF.


@Rehwyn: Glad you're finding it useful, and hopefully haven't come across any major issues. Also, if you haven't updated recently, I modified it the other day to fix a problem with the TP comparison check when the player is sitting at constant 300 TP doing SA/TA (ie: no weaponskills, just attempting TH+ procs). It now short-circuits the retry if you're sitting at 300 TP since there's no way to tell if you landed the hit.

[JarNoBaka]

@JarNoBaka: I'd write it as:

    <if EquipMain="Caladbolg" advanced='"$VARSTYLE"!="GS"'>
        <var cmd="set VARSTYLE GS" />
        <addtochat>Style: Greatsword</addtochat>
    </if>
    <elseif EquipMain="Twilight Scythe" advanced='"$VARSTYLE"!="Scythe"'>
        <var cmd="set VARSTYLE Scythe" />
        <addtochat>Style: Scythe</addtochat>
    </elseif>

Which allows you to more easily add in other weapons for each type (and just generally seems cleaner, to me). It also fixes the issue of VARSTYLE possibly being some value other than GS or Scythe (ie: whatever default value is set in the include, or possibly carried over from a previous job xml), in which case both of your rules would fail. And finally, there's no need for two IF checks; if the first succeeds, there's no need to check the second. Thus, changed to an ELSEIF.


@Rehwyn: Glad you're finding it useful, and hopefully haven't come across any major issues. Also, if you haven't updated recently, I modified it the other day to fix a problem with the TP comparison check when the player is sitting at constant 300 TP doing SA/TA (ie: no weaponskills, just attempting TH+ procs). It now short-circuits the retry if you're sitting at 300 TP since there's no way to tell if you landed the hit.

yeah copy pasted code ftw least this should work and that does look alot better

[GoggleHead]

My XML is borked somewhere. I keep casting stuff in my fast-cast body instead of the AF3 +2 body. Except sometimes it'll cast normally, seemingly at random.

http://pastebin.com/kWrW1v4b