Gearswap Help Thread!

[Motenten]

Because i always see stuff like this in luas

function aftercast(spell)
    if player.status=='Engaged' then
        equip(sets.TP[TP_Set_Names[TP_Index]])
    else
        equip(sets.Idle[Idle_Set_Names[Idle_Index]])
    end
end

function status_change(new,old)
    if T{'Idle','Resting'}:contains(new) then
        equip(sets.Idle[Idle_Set_Names[Idle_Index]])
    elseif new == 'Engaged' then
        equip(sets.TP[TP_Set_Names[TP_Index]])
    end
end

Both seem to do the same thing to me, in spellcast you only needed one thing to put tp equip ment on when you engaged and after casting a spell/using a JA,WS And i would see new and old on status change with out any explanation so i wasnt sure exaclty what it does. jsut like i dont exactly understand the purpose of pretarget coding cause it sounds like the same as precast to me. I am sure there is a reason for 2 different things, but until i know what it is, it just wont make sense to me.

1) Those two functions are, in fact, doing basically the same thing, but for entirely different reasons. Engaging a mob is in no way whatsoever an 'aftercast' event; it is not the result of you completing an action (spell, ability, etc). Therefore those two functions are not and should not be considered the same. Just because they happen to share the same code in your particular example doesn't mean that they will or must always share the same code.

However if you consider it redundant code, that's because it is. Two separate events are each executing the same code logic. It -should- be refactored into having those two functions call a third function, like so:

function aftercast(spell)
    equip_gear()
end

function status_change(new_status, old_status)
    equip_gear()
end

function equip_gear()
    if player.status=='Engaged' then
        equip(sets.TP[TP_Set_Names[TP_Index]])
    else
        equip(sets.Idle[Idle_Set_Names[Idle_Index]])
    end
end

I never write that out in the little example solutions I give because it's a more advanced methodology, and people have a hard enough time understanding the basics as it is. Ultimately, I have to either explain why the two functions use redundant code, or why I'm adding an entirely new function just to do some small bit of logic (which also means explaining code flow and similar topics). If you don't even understand enough to ask the right questions, I'm going with the simpler version.

in spellcast you only needed one thing to put tp equip ment on when you engaged and after casting a spell/using a JA,WS

This is not true.

    <equip when="aftercast|engaged" set="TP" />

That's one 'instruction', but it's not one 'thing'. You have to explicitly note that you're equipping the same set for both engaging an enemy and on aftercast. It's also broken, because it will equip your TP set on aftercast if you're idle. So you in fact need to start adding in conditionals to check your status so that aftercast equips the correct set based on your status. Eventually you end up with enough instructions that it doesn't look that much different from the lua version.

And i would see new and old on status change with out any explanation

I tend to be more explicit in my parameter names (new_status and old_status), but frankly, what explanation is needed? Your status changed; here's the new one, this was the old one.

jsut like i dont exactly understand the purpose of pretarget coding cause it sounds like the same as precast to me.

Pretarget was added because of a specific need: the ability to change the target used by the original command entry. It allows one to take "/ma cure <t>" and change it to "/ma cure <stpc>" or "/ma cure <stpt>", etc., and functionally allow the user to get that targetting arrow for selecting who they want to cast on.

Byrth originally didn't want to add it, but ultimately it was impractical to do something like that without adding an extra event phase. At the point in time when GearSwap is calling precast(), you've already passed the phase where the selection arrow was used. If you wanted to change <stpc> to <stpt> in the precast function, you'd end up having to manually select a target twice, which is just stupid.

The vast majority of people should never need to touch pretarget(), and that should be sort of implied in the event name: pre-"target". If you're not messing with the targetting, you don't need to be using that function.

[TSFFXI]

If this makes no sense, it's my fault.

Gearswap interacts with the game by responding to various events. It does so by calling functions from your user file.
Consider the following scenario from gearswap's perspective:
1.)You see Spiny Spipi and rush over to claim it.
2.)You rush over and provoke Spiny Spipi, narrowly outclaiming the other guy who has been camping it with you.
3.)You engage Spiny Spipi.
4.)You defeat Spiny Spipi, but do not receive the drop (gearswap can't help with that).

From gearswap's perspective:
1.)Gearswap does not share your enthusiasm. Since no events have occurred, gearswap does nothing.
2.)Gearswap sees you use provoke. At the appropriate times, it calls the functions 'pretarget', 'precast', 'midcast', and 'aftercast' from your userfile to see what it should do. In particular, when it reaches the aftercast function, it checks to see if you're engaged.

if player.status=='Engaged' then
        equip(sets.TP[TP_Set_Names[TP_Index]])
    else
        equip(sets.Idle[Idle_Set_Names[Idle_Index]])
    end

In this scenario, you've not yet engaged the monster, so gearswap follows the 'else' instructions.
3.)You engage Spiny Spipi. This causes your status to change from 'idle' to 'engaged.' The change is an event, which gearswap responds to by calling the status_change function, passing engaged and idle in place of new and old. (In the code somewhere, that looks like status_change('engaged','idle'))

 if T{'Idle','Resting'}:contains(new) then
        equip(sets.Idle[Idle_Set_Names[Idle_Index]])
    elseif new == 'Engaged' then
        equip(sets.TP[TP_Set_Names[TP_Index]])
    end

Gearswap reads through the function and sees that the condition "elseif new == 'Engaged'" is met, and follows the instructions from there.
4.)You defeat Spiny Spipi, and in doing so go from engaged to idle. This causes gearswap to call the status_change function again, passing engaged and idle in the opposite order this time. Gearswap reads through the function and sees that the " if T{'Idle','Resting'}:contains(new)" condition is met, and follows those instructions.

The important thing to see in this cheesy example is that if the aftercast and status_change functions had not both contained code related to being 'engaged' vs. being 'idle', gearswap could not have possibly equipped the correct gear. The status_change function is not called at step 2, but your gear is still able to equip based on whether or not you were engaged because the code is contained in the aftercast function. Similarly, the aftercast function is not called in step 3, but the code for idle vs. engaged is still checked because of the status_change function.

[Trumpy]

Is there a reason someone would want to use the old status, if you aren't in that status anymore? Like if i got up from resting and was now in idle, i wouldnt need the resting state info until i rested again (in which case it would be the new status). Is there a situation the old status would become useful? Not sayin all this stuff is redundant and useless, but i may be overlookin a situations where these could be helpful, and if i find out about them i might even come up with better code than i would otherwise. Thank you guys for the explanations.

[JSHidaka]

The vast majority of people should never need to touch pretarget(), and that should be sort of implied in the event name: pre-"target". If you're not messing with the targetting, you don't need to be using that function.

Best thing that defines pretarget lol..

[dlsmd]

This means sets.TP is a table with gear in it, i.e.

sets.TP={head="",body="",etc...}

This means something else: sets.TP contains a key named Pet. Unless I'm mistaken, the table looks something like this:

sets.TP={head="",body="",etc...,Pet={Cure={head="",body="",etc...}}}

That's kind of strange. It would be better to separate the pet table from the TP table.

this is sort of incorrect mote talked about this earlier in this tread(but i can remember ware it was)

i say sort of because you can do things like this

sets.weaponskill.element = {
	Transfixion={neck="Light Gorget",waist="Light Belt"},
	Compression={neck="Shadow Gorget",waist="Shadow Belt"},
	Liquefaction={neck="Flame Gorget",waist="Flame Belt"},
	Scission={neck="Soil Gorget",waist="Soil Belt"},
	Reverberation={neck="Aqua Gorget",waist="Aqua Belt"},
	Detonation={neck="Breeze Gorget",waist="Breeze Belt"},
	Induration={neck="Snow Gorget",waist="Snow Belt"},
	Impaction={neck="Thunder Gorget",waist="Thunder Belt"},
	Gravitation={neck="Soil Gorget",waist="Soil Belt"},
	Distortion={neck="Aqua Gorget",waist="Aqua Belt"},
	Fusion={neck="Flame Gorget",waist="Flame Belt"},
	Fragmentation={neck="Breeze Gorget",waist="Breeze Belt"},
	Light={neck="Light Gorget",waist="Light Belt"},
	Darkness={neck="Shadow Gorget",waist="Shadow Belt"}
}

but its easier to see things if you separate them like this

sets.weaponskill.type['Hand-to-Hand'] = {head="Tokon Hachimaki"}
sets.weaponskill.type['Dagger'] = {head="Issen Hachimaki"}
sets.weaponskill.type['Sword'] = {head="Kensho Hachimaki"}
sets.weaponskill.type['Great Sword'] = {head="Hako Hachimaki"}
sets.weaponskill.type['Axe'] = {head="Ryoshi Hachimaki"}
sets.weaponskill.type['Great Axe'] = {head="Senshin Hachimaki"}
sets.weaponskill.type['Scythe'] = {head="Rekka Hachimaki"}
sets.weaponskill.type['Polearm'] = {head="Shitotsu Hachimaki"}
sets.weaponskill.type['Katana'] = {head="Kanja Hachimaki"}
sets.weaponskill.type['Great Katana'] = {head="Kengo Hachimaki"}
sets.weaponskill.type['Club'] = {head="Rokugo Hachimaki"}
sets.weaponskill.type['Staff'] = {head="Hakke Hachimaki"}
sets.weaponskill.type['Archery'] = {head="Shunten Hachimaki"}
sets.weaponskill.type['Marksmanship'] = {head="Saika Hachimaki"}
sets.weaponskill.type['Throwing'] = {}

[TSFFXI]

Is there a situation the old status would become useful?

I can't think of any, but if the information is available to gearswap, it might as well be available to you.

i say sort of because you can do things like this

I think I was unclear. There's nothing structurally wrong with putting a table inside another table (in general), but I was trying to say that this

sets.TP={
    head="", 
    body="",
    etc...,
    Pet={
        Cure={
            head="",
            body="",
            etc...
        }
    }
}

is less orderly to follow than this:

sets.TP={
    head="", 
    body="",
    etc...,
}
sets.Pet={}
sets.Pet.Cure={
    head="",
    body="",
    etc...
}

It never occurred to me to put a table into a gearset table (one with head,body,legs,hands,etc. keys), although I don't really see any use in doing so even now.

[dlsmd]

Is there a reason someone would want to use the old status

if for instance when you go from engaged to idle and your MP% is below a specific amount you want to equip your idle refresh gear but you dont want it to do so if you just got done healing going from Resting to idle
like:

if new=='Idle' and old == "Engaged" then
	if player.mpp <= 75 then
		equip(sets.Engaged.refresh)
	else
		equip(sets.Engaged)
	end
end

[Motenten]

Is there a reason someone would want to use the old status, if you aren't in that status anymore?

In my thf lua, I reset certain TH gear variables when the status stops being 'Engaged'. While the most common new status will be 'Idle', it's also possible that the new status may be 'Dead'. In addition, there are other statuses besides 'Engaged' that may transition to 'Idle' (such as 'Resting', 'Dead', 'Chocobo', 'Event', etc), and I don't necessarily want those transitions to trigger certain code. 'Event' in particular can be really annoying.

For the most basic code, no, you probably don't need to know the old status. However for certain more advanced coding, not having access to what the old status was can be a severe hindrance.

[Motenten]

It never occurred to me to put a table into a gearset table (one with head,body,legs,hands,etc. keys), although I don't really see any use in doing so even now.

I use that all the time. For example, sets.precast.WS.Evisceration, and sets.precast.WS.Evisceration.SA. sets.precast.WS.Evisceration is a full gear set for normal use of the weaponskill, while sets.precast.WS.Evisceration.SA is a gear set for when using that weaponskill stacked with Sneak Attack. sets.precast.WS.Evisceration.SA is 'contained' in the sets.precast.WS.Evisceration table, which is itself a gear set.

set_combine() and equip() are both designed so that merging sets -only- copies the actual gear slots over, not any contained sub-tables, for exactly the reason of being able to do what I just described. It vastly simplifies certain methods of set selection.

[Trumpy]

Dslmd's example is kind of something i basically tried to do in spellcast for a few mage jobs. unfortunately most times u want something to occur in spellcast at a certain mp % it doesnt seem to actually equip the right gear til the next time after it first hits that mark. for an example id have refresh gear set to be equipped when under 75% mp and weather i just put code to equip it or a variable to be set to a refresh set name and use that variable as the equipment to wear it would never occur properly til something like a spell/JA/WS/status change after that % was hit. Mybe I will have less difficulty with that this time around once i get around to it. Didnt seem to matter if i used mpp or mpaftercast, it just never worked quite right.

Thanks for the info guys I will file that in the stuff i might need a bit later drawer!

[Bukadan]

ever since i did the update to lua just now shit doesnt work, it says something about refresh.lua or something

[TSFFXI]

I use that all the time. For example, sets.precast.WS.Evisceration, and sets.precast.WS.Evisceration.SA. sets.precast.WS.Evisceration is a full gear set for normal use of the weaponskill, while sets.precast.WS.Evisceration.SA is a gear set for when using that weaponskill stacked with Sneak Attack. sets.precast.WS.Evisceration.SA is 'contained' in the sets.precast.WS.Evisceration table, which is itself a gear set.

set_combine() and equip() are both designed so that merging sets -only- copies the actual gear slots over, not any contained sub-tables, for exactly the reason of being able to do what I just described. It vastly simplifies certain methods of set selection.

Ah, I can see a number of cases where this would be useful: sets reliant on certain buffs, +3 instruments for bards, etc. Thanks for clearing that up!

[Armz]

Hi, I don't know if this has been answered, but it seemed like alot to go through. Can someone tell me what to script to use to have it equip my X gearset after using ability, provided im not engaged.

I got it working with spells, and while engaged, but i need to have it do that when im not engaged currently. Please assist, and thank you

[dlsmd]

Hi, I don't know if this has been answered, but it seemed like alot to go through. Can someone tell me what to script to use to have it equip my X gearset after using ability, provided im not engaged.

I got it working with spells, and while engaged, but i need to have it do that when im not engaged currently. Please assist, and thank you

it should work even when not engaged but that depends on your actual coding but you would have to post it

[fantasticdan]

Is there a better way to convert spellcast to gearswap besides http://sc2lua.windower.net/? It turned my stuff into an unworkable mess.

[dlsmd]

Is there a better way to convert spellcast to gearswap besides http://sc2lua.windower.net/? It turned my stuff into an unworkable mess.

i could never get it to give an output on my most simple est sc file so i just rebuilt mine from scratch

[Trumpy]

I get a blank page from sc2lua... and no replies about it on windower thread lol.

[dlsmd]

is there any way this will work
by inputing this /ja "Curing Waltz" NanaaMihgo

Trust.spell = S('Excenmille','Curilla','Trion','Naji','Ayame','Volker','IronEater','Kupipi','Ajido-Marujido','NanaaMihgo','Shantotto','Maat','Cherukiki','Prishe','Ulmia','Gadalar','Gessho','Nashmeira','Zazarg','Ingrid','LehkoHabhoka','Lion','Luzaf','NajaSalaheem','Najelith','Zeid','Joachim','MihliAliapoh','Mnejing','Ovjang','Tenzen','Valaineral','Aldo','Fablinix')

function pretarget (spell)
if Trust.spells:contains(spell.target.raw)
	change_target("<p"..party.position[spell.target.raw] - 1..">") -- this would out put <p3> if NanaaMihgo trust was in location 4 of the party list
end

[Motenten]

Trust.spells ~= Trust.spell

And you'd probably want to verify that the NPC is in your party before trying to reference it in change_target.

[sydok]

is there any way this will work
by inputing this /ja "Curing Waltz" NanaaMihgo

Trust.spell = S('Excenmille','Curilla','Trion','Naji','Ayame','Volker','IronEater','Kupipi','Ajido-Marujido','NanaaMihgo','Shantotto','Maat','Cherukiki','Prishe','Ulmia','Gadalar','Gessho','Nashmeira','Zazarg','Ingrid','LehkoHabhoka','Lion','Luzaf','NajaSalaheem','Najelith','Zeid','Joachim','MihliAliapoh','Mnejing','Ovjang','Tenzen','Valaineral','Aldo','Fablinix')

function pretarget (spell)
if Trust.spells:contains(spell.target.raw)
	change_target("<p"..party.position[spell.target.raw] - 1..">") -- this would out put <p3> if NanaaMihgo trust was in location 4 of the party list
end

Gearswap doesn't seem to call pretarget when you cast on a trust using /ma "Cure IV" Lion or whatever it may be. It looks like gearswap doesn't recognize the cast at all.

Edit: There are a bunch more problems with the code as you had written. Some syntax problems, but also I don't believe there is a way to get the position of a pt member by name. You would have to check each position by name. However, no point if gearswap doesn't recognize the cast in the first place.