Gearswap Help Thread!

[Motenten]

Multiple variables being returned go into multiple vars on the calling side. Something like:

local jishGorget, jishBelt = set_weaponskill_gorget_belt("Jishnu's Radiance")

Puts the gorget and belt vars in jishGorget and jishBelt, respectively.

Using it that way would allow you to manually manipulate those vars and apply them on the code side. However, that function is called automatically on every precast (and the function ignores everything but weaponskills, so not a big deal), so the default vars of gear.ElementalGorget and gear.ElementalBelt are automatically set for each weaponskill. gear.ElementalGorget and gear.ElementalBelt can be used directly in a set definition, or you can apply them when customizing the weaponskill gear set in precast/midcast.

[haruhigumi]

Multiple variables being returned go into multiple vars on the calling side. Something like:

local jishGorget, jishBelt = set_weaponskill_gorget_belt("Jishnu's Radiance")

Puts the gorget and belt vars in jishGorget and jishBelt, respectively.

Using it that way would allow you to manually manipulate those vars and apply them on the code side. However, that function is called automatically on every precast (and the function ignores everything but weaponskills, so not a big deal), so the default vars of gear.ElementalGorget and gear.ElementalBelt are automatically set for each weaponskill. gear.ElementalGorget and gear.ElementalBelt can be used directly in a set definition, or you can apply them when customizing the weaponskill gear set in precast/midcast.

So something like this:

	if spell.type:lower() == 'weaponskill' then
		-- compatible WS belt check
		if SoilBeltWS[spell.name] then
			equip({waist="Soil Belt"})
		elseif LightBeltWS[spell.name] then
			equip({waist="Light Belt"})
		end
	
		-- compatible WS gorget check
		if LightNeckWS[spell.name] then
			equip({neck="Light Gorget"})
		end
        end

becomes

	if spell.type:lower() == 'weaponskill' then
		equip({waist=gear.ElementalBelt,neck=gear.ElementalGorget})
        end

If I were to have it in job_post_precast. (or do I still need to check against "" to avoid doing something like waist="", if it is "" could the equip function just leave that slot as is? since it's not an empty constant)

[Motenten]

Yes, your code would work. And yes, would need to be in post_precast because the default function call isn't made til the default section of precast, which happens after the first job_precast call.

If gear.default.weaponskill_neck is an empty string (""), then if it doesn't find a gorget to use, nothing will be equipped, and it will use what you were TPing/Idling in. If you put an item in gear.default.weaponskill_neck then it will equip that if it doesn't find an appropriate gorget in inventory.

I'll have to look at what it does if you try to set_combine a "" item on top of an existing item. I think the "" overwrites it, leaving you in TP gear for that slot.

Also, if you're -always- going to try to use the gorget/belt, you can just put those vars in the sets.precast.WS default/inherited set.

sets.precast.WS = {waist=gear.ElementalBelt,neck=gear.ElementalGorge t}

And whatever other common gear you use, and inherit from that using set_combine.

The main thing you'd want to do is make sure that the default item for the slot is always set properly.

[haruhigumi]

Is there a command to lock a piece? For example if the buff Camouflage is up, would I put something in job_post_precast to either set the body the same as engaged/idle and it won't change the body at all during precast (and since it's same body as midcast it shouldn't be in/out either then). The logic is Camo drops if the body piece is removed giving it the extra duration.

Or would just set something like eventArgs.useMidcastGear in precast and just forgo a snapshot precast while under camo.

[JSHidaka]

Is there a command to lock a piece? For example if the buff Camouflage is up, would I put something in job_post_precast to either set the body the same as engaged/idle and it won't change the body at all during precast (and since it's same body as midcast it shouldn't be in/out either then). The logic is Camo drops if the body piece is removed giving it the extra duration.

Or would just set something like eventArgs.useMidcastGear in precast and just forgo a snapshot precast while under camo.

they are many ways to do it... could you when Camo is up use others sets too

this is the one disabling the body piece

function buff_change(status,gain_or_loss)
    if status == "Camouflage" then
        if gain_or_loss == "gain" then
            equip(body="Orion jerkin")
	    send_command('@wait .5;gs disable body')
        else
            enable('body')
        end
    end
end

if equip(body="Orion jerkin") doesnt work, 'coz havent tried it, use make a set with the body and use equip(set.name).

Edit: actually on precast of camo you should equip the body so dont really need to equip it on buff gain..

so would be

function buff_change(status,gain_or_loss)
    if status == "Camouflage" then
        if gain_or_loss == "gain" then
	    send_command('@wait .5;gs disable body') -- or just disable('body') just not sure if this can affect precast, and avoid you equipping the body by disabling it, thats why the 0.5 delay
        else
            enable('body')
        end
    end
end

[Byrthnoth]

GearSwap v0.818 is out:

New features:
* A pet_change event has been introduced. This event will pass the pet table as the first argument and a boolean indicating whether the pet was gained (true) or lost (false) as the second argument. I've updated my SMN example .lua file if you want an example of how it can be used. This does not currently work when charming a pet, but I'll see what I can do.
* (Motenten) //gs validate now has "sets" and "inventory" options. "sets" (default) searches your sets and compares it to your inventory, determining what is in your sets and not in your inventory. "inventory" searches your inventory and compares it to your sets, determining what is in your inventory that is not in your sets. You can also now filter these results if you are interested in a specific piece. Like, //gs validate sets etoile would show only the members of sets that aren't in your inventory and include the word "etoile."

Changes/bugfixes:
* Refined how user event registration works, for when it works.
* Temp items should work from macros now.
* (Motenten) Party/Alliance variables will now . . . update at all <_<
* cancel_spell will work in pretarget again


For Shortcuts, I fixed a target priority bug and prevented it from interpreting a few select chat commands as spells (like "/p Ash" -> /pash -> /ma "Recall-Pashh" <me>).

[haruhigumi]

they are many ways to do it... could you when Camo is up use others sets too

this is the one disabling the body piece

function buff_change(status,gain_or_loss)
    if status == "Camouflage" then
        if gain_or_loss == "gain" then
            equip(body="Orion jerkin")
	    send_command('@wait .5;gs disable body')
        else
            enable('body')
        end
    end
end

if equip(body="Orion jerkin") doesnt work, 'coz havent tried it, use make a set with the body and use equip(set.name).

Edit: actually on precast of camo you should equip the body so dont really need to equip it on buff gain..

so would be

function buff_change(status,gain_or_loss)
    if status == "Camouflage" then
        if gain_or_loss == "gain" then
	    send_command('@wait .5;gs disable body') -- or just disable('body') just not sure if this can affect precast, and avoid you equipping the body by disabling it, thats why the 0.5 delay
        else
            enable('body')
        end
    end
end

The only issue with that logic (in regards to just enabling it at the time of calling camo and nothing else) is the Jerkin gives Camouflage duration +100, and when I go to fire off a ranged attack the body changes from Orion Jerkin to the Empy+2 one as part of the snapshot/precast set. So merely putting the body on wouldn't help that. It's not just a sneak/invisible you can continue to keep shooting normal ranged attacks as a way of keeping enmity down.

So looks like the route of disabling body on gain, then back on off works, since never sure exactly how long the effect will last.

[JSHidaka]

The only issue with that logic (in regards to just enabling it at the time of calling camo and nothing else)

hmm don't really get it... the body slot get disabled when you gain Camo and gets enabled.. when you lost it... so no matter what you do while you have Camo on.. your body will be locked to Orion Jerkin

[haruhigumi]

hmm don't really get it... the body slot get disabled when you gain Camo and gets enabled.. when you lost it... so no matter what you do while you have Camo on.. your body will be locked to Orion Jerkin

Was referring to

Edit: actually on precast of camo you should equip the body so dont really need to equip it on buff gain..

But I Guess you didn't see that I have Orion on as part of my idle/engaged set, so it'll be on when calling Camo, up until I do something like a ranged attack (which puts in snapshot). But the buff gain/loss looks like the best route for it if, I already have the body on at time of casting and would just need disable set.

[haruhigumi]

After the latest GearSwap update my configuration is no longer swapping gear, I have it enabled, I have it reloaded, I got //gs showswaps set to true, I know it's parsing the file because it's showing me the low ammo warning.

In fact the only changes that's happening is when I go into engaged or idle. The .Misc[..] aren't triggering like they were before.

My current config, with the Mote's files updated as of yesterday. http://pastebin.com/9qhnVCxg

To Clarify, Ranged Attacks no longer swap, nothing using .Misc['Ranged'] is working anymore.

Edit #2 , it would seem that Ranged Attacks are no longer midcast/precast.Misc['Ranged'] but now simply .Ranged (where as in the past when I tried .Ranged it wouldn't work). So problem been corrected by switching to sets.*.Ranged

[JSHidaka]

Was referring to



But I Guess you didn't see that I have Orion on as part of my idle/engaged set, so it'll be on when calling Camo, up until I do something like a ranged attack (which puts in snapshot). But the buff gain/loss looks like the best route for it if, I already have the body on at time of casting and would just need disable set.

Ah.. In my file I have a precast for "all ja's", and since is just a line have it for camo... Even that I rarely use it as an Anni RNG.


About the lua not swapping... No idea... Probably something with the include...

[haruhigumi]

I figured out with the lua Swapping. In either GS or Mote's new changes this morning, Misc['Ranged'] appears to no longer trigger on Ranged Attacks, now it's just .Ranged.

[Motenten]

Yeah, I look for action_type == 'Ranged Attack' now, and put it in the Ranged category. That way you can use ranged modes on it, like offense modes on melee.

[haruhigumi]

Hrm except now my Acc and TP modes don't work anymore on sets.midcast.Ranged.TP/Acc

Was working fine before as

sets.midcast.Misc['Ranged']
sets.midcast.Misc['Ranged'].Acc
sets.midcast.Misc['Ranged'].TP

EDIT. found in UserGlobals to change the default binding to RangedMode.

Can I just add inside of get_sets (after binds_on_load) something like :

send_command('bind f9 gs c cycle RangedMode')
send_command('bind ^f9 gs c cycle OffenseMode')
send_command('bind !f9 gs c cycle WeaponskillMode')

to override the default just for that job?

[haruhigumi]

Also I can't seem to find where this function is called to : windower.send_command('bind f12 gs c update user')
Since I'm still only seeing the Melee: */* WS:, Kiting: but no update on Ranged.

[Motenten]

EDIT. found in UserGlobals to change the default binding to RangedMode.

Can I just add inside of get_sets (after binds_on_load) something like :

send_command('bind f9 gs c cycle RangedMode')
send_command('bind ^f9 gs c cycle OffenseMode')
send_command('bind !f9 gs c cycle WeaponskillMode')

to override the default just for that job?

Yes, that would be fine.

[Motenten]

Also I can't seem to find where this function is called to : windower.send_command('bind f12 gs c update user')
Since I'm still only seeing the Melee: */* WS:, Kiting: but no update on Ranged.

That calls send_command, which you'll see on job_send_command; it then passes through update, which you'll see on job_update (and this is normally where you'd trap for update calls); and by default update calls display_current_state, which hooks into the job files at display_current_job_state. The default version just has the basics, not any of the casting or ranged modes. You'd want to create a custom version in display_current_job_state.

[haruhigumi]

That calls send_command, which you'll see on job_send_command; it then passes through update, which you'll see on job_update (and this is normally where you'd trap for update calls); and by default update calls display_current_state, which hooks into the job files at display_current_job_state. The default version just has the basics, not any of the casting or ranged modes. You'd want to create a custom version in display_current_job_state.

Can that be done without having to modify one of the Mote-* files? Like could I override it in the job file or UserGlobals?

[haruhigumi]

I keep getting SCH.lua:240: Attempt to call global 'spellcast_binds_on_unload , but when I look at 240 or any line around it I don't see a spellcast_ function being used, and it's not in any of the mote-* files and I've reloaded and on reload it keeps doing that.

EDIT: had to completely unload/reload (vua lua u/l) GearSwap to stop the message on reload.

[Motenten]

Can that be done without having to modify one of the Mote-* files? Like could I override it in the job file or UserGlobals?

Yes, display_current_job_state is a function in the job file.