Gearswap Help Thread!

[dlsmd]

When using gearswap is there a way that when nitro is active to put on my song set and lock it? No need for precast etc cause its instant cast, and tired of disabling my gs and remaking macros over and over. Thanks!

it would be something like this

function buff_change(name,gain)
    if name == "Nitro" then
        if gain then
            send_command('gs enable all')
            equip(sets.song)
            send_command('gs disable all')
        else
            send_command('gs enable all')
            equip(sets[player.status])
        end
    end
end

[ToadieOdie]

Can you use wild cards in GearSwap and if so, how? Namely wondering for zones and spell targets.

[dlsmd]

Can you use wild cards in GearSwap and if so, how? Namely wondering for zones and spell targets.

yes and no it depends on what you are trying to do

example1(slow):

windower.wc_match(spell.english, 'Warp*|Teleport*|Recall*|Retrace|Escape')

exanple 2(fast):

cities = S{"Ru'Lude Gardens","Upper Jeuno","Lower Jeuno","Port Jeuno","Port Windurst","Windurst Waters","Windurst Woods","Windurst Walls",
"Heavens Tower","Port San d'Oria","Northern San d'Oria","Southern San d'Oria","Port Bastok","Bastok Markets","Bastok Mines","Metalworks",
"Aht Urhgan Whitegate","Tavanazian Safehold","Nashmau","Selbina","Mhaura","Norg","Eastern Adoulin","Western Adoulin","Kazham"}

cities:contains(world.area)

[ToadieOdie]

Meaning if the current area matches any of the ones listed in the set it is true? So I wouldn't need to type "cities:contains(world.area) = TRUE" in a conditional, it would just be "cities:contains(world.area)"? And I assume the set itself would need to be placed in the setup with any other variables you may have?

"wc_match" must mean "wild card match" - not really a question, just musing there.

[dlsmd]

Meaning if the current area matches any of the ones listed in the set it is true? So I wouldn't need to type "cities:contains(world.area) = TRUE" in a conditional, it would just be "cities:contains(world.area)"? And I assume the set itself would need to be placed in the setup with any other variables you may have?

"wc_match" must mean "wild card match" - not really a question, just musing there.

in lua statements are only true or false
true:
example1:
test = true
if test then -- true
example2:
test = 5
if test == 5 then -- true

false:
example1:
test = false
if test then -- false in this case you would use if not test then to get true

example2:
test = 5
if test == 6 then -- false

all if/elseif to trigger need to be true
http://www.lua.org/pil/4.3.1.html

and im guessing that wc_match does = wild card match

[ToadieOdie]

So if I wanted to cancel Healing Waltz because I don't want to bother removing a condition when fighting certain monsters would I type it this way:

windower.wc_match(spell.target, '*Pukis|Sharaba|Iktomi')

or should I set up a set listing all the conditional mobs I want and type it this way:

conditionalmobs:contains(spell.target)

Edit: wait spell.target probably wouldn't work for Healing Waltz since the target would always be a player.

[dlsmd]

So if I wanted to cancel Healing Waltz because I don't want to bother removing a condition when fighting certain monsters would I type it this way:

windower.wc_match(spell.target, '*Pukis|Sharaba|Iktomi')

or should I set up a set listing all the conditional mobs I want and type it this way:

conditionalmobs:contains(spell.target)

Edit: wait spell.target probably wouldn't work for Healing Waltz since the target would always be a player.

player.target.name
but yes

with conditionalmobs:contains(spell.target) your actualy building a table not a list and because the table is already defined its fast
with windower.wc_match(spell.target, '*Pukis|Sharaba|Iktomi') it build a table with all possibility(as far as i know) every time it runs

all variables in lua are tables

read this
http://pastebin.com/GLdhjSuR

[Arcon]

with conditionalmobs:contains(spell.target) your actualy building a table not a list and because the table is already defined its fast
with windower.wc_match(spell.target, '*Pukis|Sharaba|Iktomi') it build a table with all possibility(as far as i know) every time it runs

This, basically. windower.wc_match does not build a table, but it still needs to operate on the string, it needs to split it on every pipe and then go through an expensive algorithm for every alternative (expensive because it needs to consider single-place and multiple-place placeholders ? and * respectively). The advantage is that you can match multiple mobs with wild cards (like you did with *Pukis above). If you need that, sets aren't even an option, as you'd need to manually include every possibility in there. If you don't need that, you should definitely use a pre-made set and then call :contains on it.

[dlsmd]

This, basically. windower.wc_match does not build a table, but it still needs to operate on the string, it needs to split it on every pipe and then go through an expensive algorithm for every alternative (expensive because it needs to consider single-place and multiple-place placeholders ? and * respectively). The advantage is that you can match multiple mobs with wild cards (like you did with *Pukis above). If you need that, sets aren't even an option, as you'd need to manually include every possibility in there. If don't need that, you should definitely use a pre-made set and then call :contains on it.

thx i was not sure how it worked so i guessed

[Arcon]

all variables in lua are tables

read this
http://pastebin.com/GLdhjSuR

That statement is not correct and the file linked to uses some confusing terminology, although it probably means the right things. Variables can be non-tables as well:

t = {} -- Table variable
n = 3 -- Number variable
s = 'foo' -- String variable
f = function() end -- Function variable

What the file calls iterators are just strings used to access table elements. Tables are always a mapping from a key to a value.

t = { -- Defining a table called t
    a = 3, -- t's a key is now set to the value of 3
    b = 'foo', -- t's b key is now set to the value of "foo"
    c = {} -- t's c key is now set to the value of another (currently empty) table
}

"a", "b" and "c" here are strings. You access a table with the [] operator. So after you define the above table, and you want to print its "a" key, you would do this:

print(t['a']) -- Prints: 3

However, keys do not need to be strings, they can be numbers as well:

t[4.2] = 'Something'
print(t[4.2]) -- Prints: Something

The only difference is that if keys are strings and only contain letters and underscores and do not start with a numeric character (0-9), you can use the . operator to access them. So instead of t['a'] you could write t.a and they evaluate to exactly the same thing. The latter is called syntactic sugar to the former, because it makes writing it a bit easier.

[dlsmd]

That statement is not correct and the file linked to uses some confusing terminology, although it probably means the right things. Variables can be non-tables as well:

t = {} -- Table variable
n = 3 -- Number variable
s = 'foo' -- String variable
f = function() end -- Function variable

What the file calls iterators are just strings used to access table elements. Tables are always a mapping from a key to a value.

t = { -- Defining a table called t
    a = 3, -- t's a key is now set to the value of 3
    b = 'foo', -- t's b key is now set to the value of "foo"
    c = {} -- t's c key is now set to the value of another (currently empty) table
}

"a", "b" and "c" here are strings. You access a table with the [] operator. So after you define the above table, and you want to print its "a" key, you would do this:

print(t['a']) -- Prints: 3

However, keys do not need to be strings, they can be numbers as well:

t[4.2] = 'Something'
print(t[4.2]) -- Prints: Something

The only difference is that if keys are strings and only contain letters and underscores and do not start with a numeric character (0-9), you can use the . operator to access them. So instead of t['a'] you could write t.a and they evaluate to exactly the same thing. The latter is called syntactic sugar to the former, because it makes writing it a bit easier.

i wrote it out the way i think of it not actuality's
yes it seams more complex but my mind sees it this way and understands it better this way
and if you think about it even this is a table
a=1
b=2
c=3
its just that you dont need to declare the _G or _L
the above is why its easier for me to see all of them as tables
primarily because its useful if you ever use something like this
if _G['debug_'..event_type] then -- modifiable check for function

[Malithar]

Is there a way to extend the time a piece of gear remains on for a JA? Radial Arcana and Mending Halation are both JAs that act more like pet commands; use JA, 1-2 seconds later luopan blows up. Both pieces of gear that enhance these typically don't stay on long enough to gain the effect unless there's lag.

[Damane]

Is there a way to extend the time a piece of gear remains on for a JA? Radial Arcana and Mending Halation are both JAs that act more like pet commands; use JA, 1-2 seconds later luopan blows up. Both pieces of gear that enhance these typically don't stay on long enough to gain the effect unless there's lag.

omg and i was constantly asking myself what i scripted wrong in gearswap lol

[Malithar]

Yeah, I didn't even notice it for the longest time, until a laggy night when I got back like 460 instead of 330 or whatever. After that I kept watching it finally remembered to ask here how to delay the change. XD

[Byrthnoth]

You could do it like this:

function precast(spell)
    if spell.name == "Mending Halation" then
        equip({legs="Bagua Pants +1"})
        disable('legs')
    end
end

function pet_change(pet,gain_or_loss)
    if not gain_or_loss then
        enable('legs')
    end
end

You would want to put this code inside of the current functions, but you can probably see how it works.

[Trumpy]

Would Full Circle work the same way as mending halation and radial arcana. Would i need to put that disable armor slot stuff in for that as well?

[Malithar]

I don't believe so. Full Circle doesn't act like a pet command, you use the JA and the luopan disappears immediately with no delay in the returned HP/MP.

Been busy past few days and just now got a chance to try that out Byrth, but it doesn't seem to be working. Is there a specific place in the functions it needs to be? Leaving the original precast sets in has it equipping the legs/feet for the JAs still, but the disabling/enabling isn't taking place. Removing the original precast sets has nothing taking place. I'm still such a nub about GS. XD It's using Mort's files if that makes a difference.

[Lopan]

How might i lock a slot if i equip a certain item in it, such as for instance, a reraise hairpin/earring. or even more-so; weapons? is there an easy way equip something and have it lock other slots? sometimes i want to melee/dw as a mage and not lose all my tp if i cast a spell and i dont want to have to overhaul my whole file to do it. so maybe if i equip a certain something in my off hand it'll lock my main/sub and ranged slots. can that happen?

[dlsmd]

How might i lock a slot if i equip a certain item in it, such as for instance, a reraise hairpin/earring. or even more-so; weapons? is there an easy way equip something and have it lock other slots? sometimes i want to melee/dw as a mage and not lose all my tp if i cast a spell and i dont want to have to overhaul my whole file to do it. so maybe if i equip a certain something in my off hand it'll lock my main/sub and ranged slots. can that happen?

you could do something like this at the top of your precast but this would require you to do something after you change your gear

if player.equipment.sub == "" then
    disable("slot_name")
end

[Drizzt]

What is the code in Gearswap to automatically switch to the reward neckpiece Ygnas's Resolve +1 when your in a Reive?