The Ashita Project goes live!

[Yugl]

Currently unable to access FFEVO and using the Wayback machine stated a ban of sorts, so I cannot look at the API. Generally, I'm speaking of the if/elseif/else, equip command, general command, variable commands, and other nifty features people use. Looking at the current instrument, I'm not even sure what "print" does within the context of FFXI. If you're looking to make the new system and want to discuss features people would like, that would require more discussion that I am absolutely willing to continue.

[Motenten]

Basically, the current API is a major step up from where it started, but is still a lonnnng way from being user-friendly. Unfortunately web site is inaccessible to me as well, so can't give specific examples.

From what I remember, it still had no way of constructing sets other than manually sending /equip commands, never mind layering and timing. I can't remember to what extent it handled parsing the initial user input, either, but I don't remember any easy ways of handling the equivalent of changespell or changetarget. And did it ever delineate the processing order for handling things like <stpc>? IE: the ability to intercept before the <stpc> prompt is generated for the user (and possibly change it), and then the follow-up when processing the completed command? And of course handling the equivalent of Trigger actions and parameter values (though you should at least be able to extract direct values from the command line when using lua, as opposed to Spellcast).

That covers a fairly wide spread of basic and more advanced usages, none of which seemed to be handled or well-specced. And then there's the syntax....

[atom0s]

Hey guys, RZN is having some issues with our server at the moment which hosts everything (Site, release SVN, IRC etc.) so for the time being everything is down.
He's working on getting it back up asap though.

Currently unable to access FFEVO and using the Wayback machine stated a ban of sorts, so I cannot look at the API. Generally, I'm speaking of the if/elseif/else, equip command, general command, variable commands, and other nifty features people use. Looking at the current instrument, I'm not even sure what "print" does within the context of FFXI. If you're looking to make the new system and want to discuss features people would like, that would require more discussion that I am absolutely willing to continue.

I'm not sure if the WBM will have the API anyway since the posts are fairly new. RZN also has auto-ban measures on the site for security and DDoS protection. A lot of the time scrappers like WayBackMachine will trigger these since they are constanty scrapping the site over and over in a short period of time to collect as much data as it can. So it may have been automatically banned during its scrapping of FFEvo.

Currently LuaCast can do everything you mentioned though, and the next update I have almost done is going to add even more.

"print" in Lua is a function used to output data (a string) to the default output method of the application that implements the Lua language. I override the function and force it to literally print out whatever you pass it to the FFXI chat log.

So in simple terms, when you do the following in Lua, it will show in the FFXI chat log:

print( 'Hello world!' );  

I am very interested in more feedback for LuaCast. Sadly I don't think you saw my latest posts on FFEvo about the upcoming new features though, so hopefully RZN gets the server back online soon. But I made a handful of helper scripts for obtaining important information that is used in spell cast such as:
- Recast information for both abilities and spells.
- Vana time information to obtain the current in-game time, day, elemental day etc.
- Weather information to obtain the current weather.

Then along with whats already exposed from the main core Ashita object, you can easily start scripting some logic to do actions based on these and other player data such as your current job / sub job and so on.

Basically, the current API is a major step up from where it started, but is still a lonnnng way from being user-friendly. Unfortunately web site is inaccessible to me as well, so can't give specific examples.

This is where I am hoping others that understand Lua well will step up and help out. The API is basically as good as it's going to get since it is an API. It isn't supposed to do anything more then allow access to information. The scripts built on top of the API are what need to be the most userfriendly.

I personally don't see the API being hard to understand either. Which I know saying that holds little merit given that I wrote the extension, but, the jist of things is very easy to follow and understand.

From what I remember, it still had no way of constructing sets other than manually sending /equip commands, never mind layering and timing.

Again this is where the user-layer of scripts comes in. It's not really the APIs job to hold / construct gear sets. It's the APIs job to do something with data that you give it. Which in this case would be a command.

For example, you could write a wrapper function that took a table as a parameter to handle equipment switching. That table could be considered a gear set.

local idleGear = 
{ 
    [SLOT_MAIN]         = "Some Staff"; 
    [SLOT_SHIELD]       = "Some Shield"; 
    [SLOT_RANGE]        = "Some Ranged"; 
    [SLOT_AMMO]         = "Some Ammo"; 
    [SLOT_HEAD]         = "Some Head"; 
    [SLOT_BODY]         = "Some Body"; 
    [SLOT_HANDS]        = "Some Hands"; 
    [SLOT_LEGS]         = "Some Legs"; 
    [SLOT_FEET]         = "Some Feet"; 
    [SLOT_NECK]         = "Some Neck"; 
    [SLOT_WAIST]        = "Some Waist"; 
    [SLOT_EARLEFT]      = "Some Earring Left"; 
    [SLOT_EARRIGHT]     = "Some Earring Right"; 
    [SLOT_RINGLEFT]     = "Some Ring Left"; 
    [SLOT_RINGRIGHT]    = "Some Ring Right"; 
    [SLOT_BACK]         = "Some Back"; 
}; 
 
function EquipGearSet( gearset ) 
    local slotName = 
    { 
        "main", "sub", "ranged", "ammo", 
        "head", "body", "hands", "legs", "feet", 
        "neck", "waist", "L.Ear", "R.Ear", "L.Ring", "R.Ring", "back" 
    }; 
 
    for k, v in pairs( gearset ) do 
        if (slotName[ k ] ~= nil) then 
            AshitaCore:GetDataModule():SendCommand( string.format( '/equip "%s" "%s"', slotName[ k ], v ), CommandType.Typed ); 
        end 
    end 
end  

I can't remember to what extent it handled parsing the initial user input, either, but I don't remember any easy ways of handling the equivalent of changespell or changetarget. And did it ever delineate the processing order for handling things like <stpc>? IE: the ability to intercept before the <stpc> prompt is generated for the user (and possibly change it), and then the follow-up when processing the completed command? And of course handling the equivalent of Trigger actions and parameter values (though you should at least be able to extract direct values from the command line when using lua, as opposed to Spellcast).

That covers a fairly wide spread of basic and more advanced usages, none of which seemed to be handled or well-specced. And then there's the syntax....

Keep in mind that LuaCast is not a direct clone of Spellcast in anyway. While we are aiming to make things somewhat similar, Lua is a scripting language. It is not limited to the things of XML and can do WAY more than what Spellcast limited in terms of ho restricted XML is.

Parsing user input such as a command like:

/derp arg1 arg2 "this is a long argument as arg3" arg4  

Can be done using the GetArgs string extension I wrote. You can process the command line easily using it like this:

function onHandleCommand( cmd, nType ) 
    -- Parse the command into arguments.. 
    local args = cmd:GetArgs(); 
     
    -- Validate this is a LuaCast command.. 
    if (args[1] ~= "/luacast") then 
        return false; 
    end 
     
    -- Handle LuaCast wave command.. 
    if (args[2] == 'wave') then 
        AshitaCore:GetDataModule():SendCommand( '/wave', CommandType.Typed ); 
        return true; 
    end 
     
    return false; 
end 
events.Add( "onHandleCommand", "luaCast_onHandleCommand", onHandleCommand );  

Almost every command / action your character can do is sent as a command. Which is all passed through our HandleCommand processor. Which with LuaCast this is passed to the onHandleCommand event.

You can process the command line easily with this to catch things like when a spell or ability is being attempted to be used and so on.

For example if you use the command:
/ma "Cure" <me>

The onHandleCmomand will see it exactly like that. Which means you can replace the <me> with whatever you want.

This also works for all the <stnpc> <stpc> etc.



I want to remind everyone that is looking into LuaCast. The object of this extension is yes, to be able to handle what SpellCast does, but the context in which we do it is not to be a replica of Spellcast. LuaCast has a lot more freedom becuase it is a scripting language. It is not a mark up language that confirms to a strict set of rules.

Combined with the Ashita API, you can honestly make an entire packet bot, claim bot, craft bot, navigation bot, etc. whatever you wanted already with whats exposed. (Not saying this is what we expect people to use it for, just giving it as an example of how powerful it can be.)

There is a lot more potential to this extension than just following a strict set of guidelines and rules to change gear sets.

This is something I think everyone needs to remember. We are not looking to make a drop-in replacement for Spellcast. LuaCast is a breath of fresh air in terms of what can be done with creating complex scripts, macros, event driven actions etc.

[Pebbs]

Yugl, Montenten and others,

If you would be willing to explain some of your comments, I'd like to understand the requirements for a "new" system before someone tries to recreate the spellcast system, or even a "replacement".

Please note I've never used spellcast, however I do understand how to read the spellcasts both of you have put together. I am also unable to find original documentation on Spellcast, hence the questions below. I have read the stickies regarding spellcast.

Specific comments from both of you that I would like to discuss/explore are:

"From what I remember, it still had no way of constructing sets other than manually sending /equip commands" - If a system was in place that easily created and equipped sets, would you care if equip commands were the end result, but managed differently?

EG: /please equip TP set number 1 (would swap all 16 slots potentially)

What is meant by "layering and timing" of sets? Would a simple example be:
Start casting freeze in "FastCast" gear.
Switch to ice nuking set after nuke has started, layer on elemental obi if it is ice day.
After the spell is completed, switch back to Idle/refresh gear

What is a "variable" command?

Could you please provide a concrete example of where/how you would use command rewriting to change the <stpc>? From what I know of the framework, intercepting something like /ma cure <stpc> may or may not be possible from a macro/typed command, but from the menu may be problematic.

I did read the "spellcast" help regarding trigger actions/spells, but I'm still unclear on their purpose, and haven't really come across a really good example. Please correct me if the following example incorrectly exemplifys a trigger spell.
EG: On PLD, blood tanking Dynamis-Bastok zone boss stone, you see the stone cast "Death" and you have no way to stun it, you would use a macro to go /so March <me> to force a gear swap to Twilight Body and Twilight Helm, and to lock the pieces when you did that so that they would not swap out.

Again, to re-iterate, I'm not asking for how you want this solved in a plugin or Lua script, I'm asking what problems do you need solving that happen to be solved by SpellCast, autoexec, and arbitrary length macros?

[Yugl]

Very late, so I'll check back to see if I don't cover any points.

If a system was in place that easily created and equipped sets, would you care if equip commands were the end result, but managed differently?

If managing sets is simple, difference isn't an issue. While users may not understand rules, they absolutely must understand equipment management since we cannot hardcode or revise that for each individual.

What is meant by "layering and timing" of sets? Would a simple example be:
Start casting freeze in "FastCast" gear.
Switch to ice nuking set after nuke has started, layer on elemental obi if it is ice day.
After the spell is completed, switch back to Idle/refresh gear

I think he means piping when he says laying. Some ways in which this happens:
- A set is defined by another set (ex: My Evasion-TP set takes my TP set and adds whatever gear I specify)
- A rule layers sets when equipping (ex: <equip set="Fire|$Evasion"> Will take my Fire set and equip my $Evasion set upon that. Since $Evasion is a variable, I can change what type of set is stacked upon the fire set.)

What is a "variable" command?

<var cmd="set TPVariable X" /> Will change the value of "TPVariable" to X
<var cmd="inc TPVariable" /> Will increase the numeric value of TPVariable by 1

LUA likely has these, but in a more complex form. The primary benefit of variables is to adapt sets to changing circumstances such as buffs, weather, HP, monster, event, area, etc without spelling out every combination of conditions.

I did read the "spellcast" help regarding trigger actions/spells, but I'm still unclear on their purpose, and haven't really come across a really good example. Please correct me if the following example incorrectly exemplifys a trigger spell.
EG: On PLD, blood tanking Dynamis-Bastok zone boss stone, you see the stone cast "Death" and you have no way to stun it, you would use a macro to go /so March <me> to force a gear swap to Twilight Body and Twilight Helm, and to lock the pieces when you did that so that they would not swap out.

Your example captures the essence of a trigger spell. Since spellcast only reacts to actions, the only way to force a gear or variable update is to make your character act. Trigger spells let spellcast "react" without taking an action of consequence (i.e. the character does nothing but the gear updates).

[Pebbs]

I'm seeing some requirements, I'll start stating the requirements as I understand them going forward, and add to them as we explore the conversation.

Requirements (so far):
1) Gear set management must be easily understandable to users.
2) There is a need to be able to merge sets, based on the differences in the sets, and then equip the result.
3) A player should be able to lock gear into a slot, until such time that the gear is specifically unlocked from that slot (or until logout/login).
4) A player should be able to equip a set at will.


Items I need clarification on:
1) Timing - this word is ambiguous to me. I need examples of how this plays out. Links to spellcast files will aid in understanding this.
2) For variables, is there a need to be able to assign a set to a variable?

Things I am spending time understanding.
1) Why variables are used.
2) How variables are used.
3) Types of variables used.

I am busy exploring Yugl and Motenten's include files to understand variables. I'm trying to isolate whether we can reduce complexity of the system, which will go a long way to meeting requirement #1.

[Zirael]

Items I need clarification on:
1) Timing - this word is ambiguous to me. I need examples of how this plays out. Links to spellcast files will aid in understanding this.
2) For variables, is there a need to be able to assign a set to a variable?

Things I am spending time understanding.
1) Why variables are used.
2) How variables are used.
3) Types of variables used.

I am busy exploring Yugl and Motenten's include files to understand variables. I'm trying to isolate whether we can reduce complexity of the system, which will go a long way to meeting requirement #1.

Let me give you a snipped of my xml for Scholar to ilustrate some issues of 'timing'. It's not as advanced as Yugl's or Monty's, but I commented some thingsin there to hopefully help you understand timings and variables a bit. Some terminology:
precast: actions performed by Spellcast before an actual action is performed. Ie. if you press macro to perform a weapon skill, Spellcast will load WaeponskillGearSet before actual weaponskill is executed
midcast: actions performed by Spellcast whilst spell/ability is being channeled. Since abilities are instant, this applies only to spells
aftercast: actions performed by Spellcast after ability is executed or spell casting bar on screen reaches 100%. Usually spells finish casting earlier that than progress bar reaches 100%, but Spellcast waits until it's 100%. This sucks when you've got 80% FastCast in gear

Spoiler: show

        <!-- Variable (currently set to 1.2 seconds) used to determine whether it is worth equipping precast-FastCast gearset or equip potency set right at the beginninh of casting of the spell
            ie. for Raise spell you should precast a FastCast set, so it casts faster, but for Stun or Barfira, it is  pointless to use FastCast, because it takes about 0.3s for Spellcast to process changing one gear set into another, and you'd end up casting in FastCast gear by the time a fast spell resolves-->
        <var name="LongSpell">1.2</var> 
        <!-- A variable used to determine how long Spoellcast should wait before swapping from precast gear into midcast gear. When this gets set to 0, precast gear is not loaded and Spellcast proceeds directly to equip midcast gear -->
        <var name="Delayer">0.6</var>

        <!-- A set of variables used to swap a staff appropriate for the spell element. I use variables for Magian Staves for Potency (nuking) and Enfeebling (accuracy), they're not shown in this snippet -->
        <var Name="IceStaff">Chatoyant Staff</var>
        <var Name="WindStaff">Chatoyant Staff</var>
        
        <!-- A variable that dictates if your gear sets for nuking and enfeebling should use full potency (for non resistant enemies) or  toss in some magic accuracy. This can be changed manually or by for example entering a zone. If I enter Legion zone, this get set to "full magic accuracy", if I enter abyssea, this gets set to "full magic attack" etc -->
        <var name="ResistRate">0</var>

        <!-- A variable one can set that dictates if gear used when engaged should be Haste, Accuracy, PDT, MDT, StoreTP, Refresh etc. Yugl and Monteneten have this part more complicated. Myself, for example, I'd use this variable to either tank something in full PDT gear on RDM, or use Haste gear in Dynamis. 
            Let's say I have two gear sets Engaged$Tanking: "Engaged0" and "Engaged1". At the end of this snippet you'll find <action type="equip" when="aftercast" set="Engaged$Tanking" /> - a different gear set would get equipped depending on what the variable below is set to.-->
        <var name="Tanking">0</var>

        <!-- Similarly to Tanking variable, you could set this to equip either Refresh, PDT, MDT gear when not engaged. For pulling in abyssea, you'd want to set this to PDT, for backline curing, a refresh set would get equipped -->
        <var name="Kiting">0</var>
        
<!-- rule below will be processed for all magic, songs and ninjutsu with the exception of Impact -->
<if CommandPrefix="/magic|/ma|/song|/ninjutsu" notSpell="Impact">
        
            <!-- what to do if no ability shortening magic casting time is active -->
            <if notBuffActive="Celerity|Alacrity|Spontaneity">
            
            <!-- check if the spell is long enough for it to be worth equipping a FastCast gear before casting or not -->
                    <if advanced='"%CastTime"&gt;"$LongSpell"'>
            <!-- check if the spell is of curative type, since those spells get a dedicated CureFastCast gear -->
                        <if Spell="Cure*|Cura*">
            <!-- spell is a Cure with casting time greater than 1.2s => set delay for midcast gearset to 0.4s and equip "FastCastCure" before casting spell -->
                            <action type="var" cmd="set Delayer 0.4" />
                            <action type="equip" when="precast" set="FastCastCure"/>
                        </if>
            <!-- spell is not a cure =>  set delay for midcast gearset to 0.4s and equip "FastCast" before casting spell -->
                        <else>
                            <action type="var" cmd="set Delayer 0.4" />
                            <action type="equip" when="precast" set="FastCast"/>
                        </else>
                    </if>

            </if>
            
            <!-- thre was an ability active that lowers casting time of a spell. For Spontaneity, Spellcast will proceed to <else> rule below and not load any precast FastCast gear, but load midcast potency gear instead before casting spell -->
            
            <elseif BuffActive="Celerity|Alacrity">
            <!-- Celerity/Alacrity shorten casting time of spell by 50% - check if it's worth bothering loading FastCast gear before casting spell. If the spell is shorter than 2.4s/2=1.2s, it will be treated as short spell -->
                    <if advanced='%CastTime&gt;=($LongSpell*2)'>
                        <if Spell="Cure*|Cura*">
                            <action type="var" cmd="set Delayer 0.4" />
                            <action type="equip" when="precast" set="FastCastCure"/>
                        </if>
                        <else>
                            <action type="var" cmd="set Delayer 0.4" />
                            <action type="equip" when="precast" set="FastCast"/>
                        </else>
                    </if>
            </elseif>

            <!-- if rules above determine that the spell is going to be cast near-instantenously, variable Delayer will be set to zero and later on cause 
            'precast' to be skipped and 'midcast' to be loaded instead-->
            <else>
                <action type="var" cmd="set Delayer 0.0" />
            </else>
        
            <if Skill="EnfeeblingMagic">
                <action type="midcastdelay" delay="$Delayer" />
            <!-- determine what staff to use depending on spell element. If it was an ice spell, variable      <var Name="IceStaff">Chatoyant Staff</var> would kick in-->
                <action type="equip" when="midcast"><main>$%SpellElementStaff</main></action>
            <!-- Determine if spell is LightEnfeeblingMagic or DarkEnfeeblingMagic and check if $ResistRate is set to low(0) or high(1) -->
                <action type="equip" when="midcast" set="%Skill%Type$ResistRate" />
            </if>
        
            <elseif Skill="DarkMagic">
            <!-- Stun, Kaustra and Klimaform use specific gear sets, rest of the spells like aspirs/drains will use generic DarkMagic potency set -->
                <if notSpell="Stun|Kaustra|Klimaform">
                    <action type="midcastdelay" delay="$Delayer" />
                    <action type="equip"><main>$%SpellElementStaff</main></action>
                    <action type="equip" when="midcast" set="DarkMagicBlackMagic" />
                </if>
            <!-- specific rule for Stun. It check if Thunderstorm and Alacrity buffs are active and equips different gear depending on that -->
                <elseif Spell="Stun">
                    <if advanced='(bool)buffactive("Thunderstorm") AND (bool)buffactive("Alacrity")'>
                        <action type="equip" when="precast" set="Stun-Alacrity" />
                    </if>
                    <else>
                    <action type="equip" when="precast" set="Stun" />
                    </else>
                </elseif>
            
            <!-- specific gear set for Kaustra -->
                <elseif Spell="Kaustra">
                    <action type="midcastdelay" delay="$Delayer" />
                    <action type="equip" when="midcast" set="Kaustra" />
                </elseif>
            </elseif>
        
        [.. gearset rules for other types of magic: elemental, healing, divine, songs etc ..]
        
        <!-- Code below determines what to do after the spell is cast. -->
        <if notstatus="Engaged">
            <action type="equip" when="aftercast" set="Idle$Kiting" />
        </if>
        <if status="Engaged">
            <action type="equip" when="aftercast" set="Engaged$Tanking" />
        </if>
</if>

    <!-- code below causes Impact spell to be cast automatically. The problem with this spell is, a special cloak needs to be equipped before the spell is cast.
        What this code does:
        -detect one is trying to cast Impact.
        -equip TwilightCloak
        -cancel spell casting, since cloak wasn't equipped at the time user wanted to cast the spell
        -wait 1.2s for spellcast/game finish changing gear etc. At this point game will allow Impact to be cast.
        -cast Impact
        -equip Impact accuracy/potency set after 0.5s
        -wait 11s for spell to finish casting
        -change gear to current idle set-->
        
        <elseif Spell="Impact">
            <action type="equip" when="precast" set="Impact-FC" />
            <cancelspell/>
                <action type="command">wait 1.2;input /raw /ma "Impact" &lt;t&gt;;wait 0.5;sc set Impact;wait 11;sc set Idle$Kiting;</action>
                <return/>
        </elseif>
        
[..end of snippet..]

[Pebbs]

What's the difference between an "aftercast" set, and an "idle" or "tp" set?

from what I can tell, the "gear set cycle" is:

Idle / TP -> pre -> mid -> after -> TP / Idle

And from what I've read, each stage of the cycle may be (and generally is) modified by the following environment variables:
Active buffs (songs, rolls, sneak attack, mighty strikes, blood weapon, berserk, etc.)
Current weather
Current day of the week element
Current time of day

There are times when you want to modify the sets further based on player decisions.
EG: make the idle/TP Set a PDT set, or an MDT set.
Use high accuracy gear for TP
Use high m.acc gear for magic spells.

There are automatic gear swap situations that may be determined by the player beforehand.
EG: when TP is above 100%, don't switch the main, sub, or ranged or ammo slots. (this is an example, there's a definite reason to want to swap the ammo piece situationally)
EG2: When MP drops below 75%, equip the Uggalepih Pendant when casting offensive spells.

Is this correct?

[Mafai]

What's the difference between an "aftercast" set, and an "idle" or "tp" set?

from what I can tell, the "gear set cycle" is:

Idle / TP -> pre -> mid -> after -> TP / Idle

And from what I've read, each stage of the cycle may be (and generally is) modified by the following environment variables:
Active buffs (songs, rolls, sneak attack, mighty strikes, blood weapon, berserk, etc.)
Current weather
Current day of the week element
Current time of day

There are times when you want to modify the sets further based on player decisions.
EG: make the idle/TP Set a PDT set, or an MDT set.
Use high accuracy gear for TP
Use high m.acc gear for magic spells.

There are automatic gear swap situations that may be determined by the player beforehand.
EG: when TP is above 100%, don't switch the main, sub, or ranged or ammo slots. (this is an example, there's a definite reason to want to swap the ammo piece situationally)
EG2: When MP drops below 75%, equip the Uggalepih Pendant when casting offensive spells.

Is this correct?

Aftermath is a big buff that needs to be considered as well.

[Yugl]

Items I need clarification on:
1) Timing - this word is ambiguous to me. I need examples of how this plays out. Links to spellcast files will aid in understanding this.

Aside from the usual precast/aftercast/idle etc, you can add manual commands to do actions.

<if Spell="Sleep|Sleepga">
      <var cmd="inc SleepOrder" />
      <command when="aftercast">wait 25; input /echo [%Spell ($SleepOrder) : %target : %Spell wearing in 35s]</command>
       <command when="aftercast">wait 45; input /echo [%Spell ($SleepOrder) : %target : %Spell wearing in 15s]</command>
        <command when="aftercast">wait 55; input /echo [%Spell ($SleepOrder) : %target : %Spell wearing in 5s]; spellcast var dec SleepOrder</command>
</if>

2) For variables, is there a need to be able to assign a set to a variable?

Things I am spending time understanding.
1) Why variables are used.
2) How variables are used.
3) Types of variables used.

Why use variables
1) Avoid spelling out combinations via rules.
2) Centralizes control over every rule utilizing the variable.

How to use variables
1) Assign a variable to a buff so when the buff is active, manipulate the variable
2) Assign a "mode" to a variable so that when you want to change the mode of a set, change the variable value (ex: Evasion-TP mode or Haste-TP mode)
3) Assign a variable to activate or deactivate a rule (If variable is "on", use this rule)

[Motenten]

Been delayed in trying to answer the questions, so let's see what I can trim it down to.


Allow me to answer at more of a programmer's level:

You've written an API into Ashita; that's all well and good. However it's useless at the business logic level. There's an entire interface layer missing between the underlying API and what the user actually needs access to. That interface layer is roughly the equivalent to what Spellcast provides. Luacast initially billed itself as a Spellcast equivalent/superset (implied in the very name used, even), but since it's missing that entire layer of abstraction, it's lacking that "user-friendly" stuff Yugl mentioned.

Essentially, "LuaCast", as originally presented, does not exist. You have an API that can be used to build LuaCast, but not LuaCast itself. You've pretty much said, "Here's a hammer, a saw, a bucket full of nails, and a forest. Enjoy your new house!"

I personally don't see the API being hard to understand either. Which I know saying that holds little merit given that I wrote the extension, but, the jist of things is very easy to follow and understand.

It's not (much) about the API being hard to understand (discounting that the average user isn't going to have clue one about how to deal with a real programming language), it's the issue of the API not matching the actual problem domain. To continue my poor analogy above, a hammer and a saw are perfectly simple and easy-to-understand tools, but it sucks to have to build all my furniture by hand out of raw materials (not to mention a place to put the furniture in, walls to separate one bit of furniture from the next, and a roof to keep the rain out).

I am also unable to find original documentation on Spellcast, hence the questions below.

Documentation: http://forums.windower.net/topic/21364-spellcast/

If a system was in place that easily created and equipped sets, would you care if equip commands were the end result, but managed differently?

The fact that the end result is the creation of those /equip commands is mostly irrelevant. The problem is that that's an implementation detail that should be completely abstracted away, that most users never have to see. A 'system put in place to manage those kinds of details' is exactly the abstraction layer that's needed.

"Equip Twilight Torque on the neck" or "Equip TP set 1" is the extent of the complexity of what the typical user needs to see. He doesn't and shouldn't need to know about dictionary pairs and string constructions and insertion commands and determining the timing of sending the commands and whatever else.

What is meant by "layering and timing" of sets? Would a simple example be:
Start casting freeze in "FastCast" gear.
Switch to ice nuking set after nuke has started, layer on elemental obi if it is ice day.
After the spell is completed, switch back to Idle/refresh gear

Layering: I assert that I want to equip my TP set while engaged; I also assert that I want to equip my MDT set when a spell is being cast on me. For slots that are not defined in the MDT set, it should equip whatever was defined in my TP set.

Timing: Equip "fast cast" gear before sending the command to cast the spell. Immediately after casting the spell, equip midcast gear (potency, accuracy, etc). At some point after that, once the spell has finished casting, equip 'aftercast' gear (may be idle or TP or others). Some may want precast gear equipped with an additional delay before casting the spell. Some may want the delay between midcast and aftercast adjusted to better suit the spell timing (eg: lots of fast cast, or adjustments for when using this on ranged attacks, etc).

All of that together constitutes 'timing'.

What is a "variable" command?

That's just a command to assign a value to a variable.

Could you please provide a concrete example of where/how you would use command rewriting to change the <stpc>? From what I know of the framework, intercepting something like /ma cure <stpc> may or may not be possible from a macro/typed command, but from the menu may be problematic.

Something I just wrote in Spellcast a few days ago. Let me quote my explanation:

Discussion on the official forum about blinking characters reminded me of an annoyance with using <stal> as an alternative: You often don't actually want <stal> behavior, but rather <stpt> behavior, but you also don't want to be prevented from moving across the entire alliance list just because you wrote your macros with <stpt>.

So I added an extra config option to my XMLs. The following commands modify the config value:

/ma CastingMode Cycle(STAL)
/ma CastingMode SetTarget(STAL)
/ma CastingMode SetTarget(STPT)
/ma CastingMode SetTarget(STPC)

The first cycles through stal, stpt and stpc. The others set the value directly. Then add this include:

        <xi:include href="Mote-Rules-Include.xml" xpointer="//include[@name='ConvertSTALTargets']/*" />

This needs to go before the ReturnRules include.

Now if the STALMode variable (ie: 'Targetting Type') is set to 'stal', it won't do anything. However if it's set to 'stpt' or 'stpc', it will change all <stal> targets to <stpt> or <stpc>, respectively (note: it won't have any effect on macros written with <stpt> or <stpc>). This is restricted to white magic spells for now; I don't think there are any non-white magic spells that can use <stal> anyway.

Now you can write your macros with just <stal>, but turn off the alliance targetting if you don't want to deal with it, or change it to <stpc> if you want F-key or outside party/alliance targetting.

I did read the "spellcast" help regarding trigger actions/spells, but I'm still unclear on their purpose, and haven't really come across a really good example. Please correct me if the following example incorrectly exemplifys a trigger spell.
EG: On PLD, blood tanking Dynamis-Bastok zone boss stone, you see the stone cast "Death" and you have no way to stun it, you would use a macro to go /so March <me> to force a gear swap to Twilight Body and Twilight Helm, and to lock the pieces when you did that so that they would not swap out.

That's a simple example, yes. Other uses are to toggle variable values so that the spellcast behavior changes. This is done with triggers because that's something you can put in a macro and have spellcast intercept, interpret, take action on, and then discard so that it has no impact on game play.

In general, triggers are used to change state values. For example, change my TP set to one more focused on accuracy, or put on PDT gear, or determine when to equip TH gear, etc.

Requirements (so far):
1) Gear set management must be easily understandable to users.
2) There is a need to be able to merge sets, based on the differences in the sets, and then equip the result.
3) A player should be able to lock gear into a slot, until such time that the gear is specifically unlocked from that slot (or until logout/login).
4) A player should be able to equip a set at will.

All correct, though point 3 has two variants: One to disable a slot for the remaining duration of processing a command, and one to disable a slot for any and all uses until reenabled.

2) For variables, is there a need to be able to assign a set to a variable?

Yes, though there are several ways it could be done. It doesn't have to be a set object, but could just be a set name.

1) Why variables are used.
2) How variables are used.
3) Types of variables used.

a) Maintain state
b) Define options
c) Select options



Gotta go. Will answer more later.

[Zirael]

What's the difference between an "aftercast" set, and an "idle" or "tp" set?

from what I can tell, the "gear set cycle" is:

Idle / TP -> pre -> mid -> after -> TP / Idle

And from what I've read, each stage of the cycle may be (and generally is) modified by the following environment variables:
Active buffs (songs, rolls, sneak attack, mighty strikes, blood weapon, berserk, etc.)
Current weather
Current day of the week element
Current time of day

There are times when you want to modify the sets further based on player decisions.
EG: make the idle/TP Set a PDT set, or an MDT set.
Use high accuracy gear for TP
Use high m.acc gear for magic spells.

There are automatic gear swap situations that may be determined by the player beforehand.
EG: when TP is above 100%, don't switch the main, sub, or ranged or ammo slots. (this is an example, there's a definite reason to want to swap the ammo piece situationally)
EG2: When MP drops below 75%, equip the Uggalepih Pendant when casting offensive spells.

Is this correct?

You are correct. As for set names, idle, resting and engages are three basic states of your character (there is actually one more: dead, but it's not used for gear swapping as such). Idle set is when you are not engaged, TP set is used when engaged. Aftercast set is a set you use after performing an action, it can be either idle or TP set, depending if you're engaged or not.

In my xml those sets are defined as follows (I presume these can be defined in different ways by different people, but this is what I use):

    <if spell="autoset">
        <action type="equip" when="resting" set="Resting" />
        <action type="equip" when="idle" set="Idle$Kiting" />
        <action type="equip" when="engaged" set="Engaged$Tanking" />
    </if>

[Pebbs]

Thank you for the link to the documentation of the spellcast plugin.

I feel I need to clarify that I am not a core developer for the Ashita project. I am a plugin contributor at the moment, and have no desire to be part of the core team at the moment. My apologies if I conveyed that I was part of the core team.

My aim in continuing to contribute to this thread is so that a solution can be created (whether it be a plugin, Lua script, or some combination of plugins and scripts) that will provide functionality to manage gear swapping in Ashita.

[atom0s]

Allow me to answer at more of a programmer's level:

You've written an API into Ashita; that's all well and good. However it's useless at the business logic level. There's an entire interface layer missing between the underlying API and what the user actually needs access to. That interface layer is roughly the equivalent to what Spellcast provides. Luacast initially billed itself as a Spellcast equivalent/superset (implied in the very name used, even), but since it's missing that entire layer of abstraction, it's lacking that "user-friendly" stuff Yugl mentioned.

Essentially, "LuaCast", as originally presented, does not exist. You have an API that can be used to build LuaCast, but not LuaCast itself. You've pretty much said, "Here's a hammer, a saw, a bucket full of nails, and a forest. Enjoy your new house!"

My apologies for the confusion with the name / and interpretation that everyone got from this. Let me clear this up..
- LuaCast will eventually be a replacement for SpellCast users, BUT it is not intended to be a drag and drop replacement.
- LuaCast has (at least by me) no intention to ever parse SpellCast files and just work.
- LuaCast is written in a programming/scripting language, not a markup language. There is a lot less limitation in LuaCast then there is in SpellCast.

Sadly with FFEvo being down right now you can't see my latest posts about LuaCast.
I am working on a bunch of helper files that will allow users to obtain information for various things easily.

It's not (much) about the API being hard to understand (discounting that the average user isn't going to have clue one about how to deal with a real programming language), it's the issue of the API not matching the actual problem domain. To continue my poor analogy above, a hammer and a saw are perfectly simple and easy-to-understand tools, but it sucks to have to build all my furniture by hand out of raw materials (not to mention a place to put the furniture in, walls to separate one bit of furniture from the next, and a roof to keep the rain out).

And I do understand that. This is the reason I am posting all the API information, all the helper files I've created, examples of what can be done etc.

I can't devote all my time to writing every little thing for LuaCast. I have a real life job as well as being the lead developer of the entire Ashita project, I have other things that need my attention as well. This is why I am hoping there are a few Lua savvy people that will pickup and try the extension out and start helping write a middle-level framework of sorts to help the basic/average user out.

I can ensure you that it is not hard to pickup the API and start making things. A normal user of ours has already recreated Autoexe in LuaCast and he had 0 knowledge of Lua or scripting before he started. So I know the API is not hard to work with or follow.

Once our forums are back up, feel free to check out the new posts I've made in the LuaCast thread as well as the LuaCast support section.



Overall LuaCast needs a userbase to build it up from the ground. Not just a single person. I am hoping that a few people that do know how to use Lua see the project and extension and notice its advantages and power. A lot can be done with the extension once people see its potential. It's just a matter of finding those people that are willing to help out and create a middle-man framework for users to use.


Right now my main focus with LuaCast is working on more middle-man API features that help users pull information from the game that aren't included in Ashita's API.

Which currently includes:

• Inventory helper wrappers.
• Recast information.
• VanaTime information.
• Weather information.

If there are others that are needed feel free to suggest them.



FFEvo Downtime

Since I did get some messages on other sites asking whats up with FFEvo and if we got shutdown etc. here's a quick rundown of what happened:
- Our site is ran on a dedicated server.
- Each portion of the site is ran on a separate VM.
- RZN went to resize on of the VMs and resized the wrong one. (Not a big deal, and he was working on fixing it.)
- While fixing it the entire servers RAIDs SATA controller failed and died.

So at the moment we're waiting on our host to setup a new server for us which should be ready by Monday.

[raol]

So at the moment we're waiting on our host to setup a new server for us which should be ready by Monday.

Do you happen to have a recent build mirrored anywhere? I've been away from ffxi for a long time and would like to give this a whirl.

[atom0s]

Do you happen to have a recent build mirrored anywhere? I've been away from ffxi for a long time and would like to give this a whirl.

At the moment the only build I have is a development build so I'd rather not upload that. I don't want people to get out of sync with updates.

[raol]

Understandable, I can wait.

[atom0s]

Hey everyone, just the heads up. FFEvo is back online again.

[Pebbs]

atom0s, still down for me.

//Edit: nevermind, server is responding now.

[atom0s]

atom0s, still down for me.

Little shaky at the moment. We got moved to a new dedicated machine and they're removing the old hardware for us. We got new hard drives, more RAM and more bandwidth, so they're still doing some things on their end but the site should be up soonish. Keep checking. It is rebooting at the moment due to the removal of some hardware. Expect it to go down a few more times throughout the day though while things settle down.