Gearswap Help Thread!

[Motenten]

Hi all,

recently bought a Terpander. after some modification to mote's brd.lua.
it will auto swap to the Terpander to sing the 3rd song for party songs, however, if it I use the ability Pianissimo to sing to individual member without any songs currently buffed to the party, it does not swap to Terpander to sing the 3rd song for the individual members. is there anyway to get around this? Thanks.

No, because it's impossible to know that the targetted individual is getting their third song (and more particularly, their third song from you). You have to make those decisions yourself, and use use the Daurdable/Dummy flag as appropriate.

I should probably rename those variables.....

[Sechs]

Not sure if fixed, but for example if you have "/ja Nightingale <me> " and if you notice an space AFTER <me>, GS wont trigger... not sure why.. not sure if fixed, but this was a problem before. check your SE Macro to see if you have that extra space, and is the same that if you had /ja Nightingale <me> <wait 1> it would bypass GS too...

I'll check that when I get back home, but I doubt that's the problem.
If that were the issue, then GS should NEVER work for that JA, instead here we're talking about two times over... I dunno, many many other uses where it works correctly.
Same Lua, same macro.

It's strange...
Both times I noticed this happening I was in Delve. I don't remember where the first time, but the second (yesterday) I was buffing just before Calimh pull.
I seriously have no clue how this can happen.
I imagined a random lag issue depending on the newly added Mog Wardrobe but then again it sounds strange, you'd be thinking other people would have noticed and reported such random issues...

[JSHidaka]

I'll check that when I get back home, but I doubt that's the problem.
If that were the issue, then GS should NEVER work for that JA, instead here we're talking about two times over... I dunno, many many other uses where it works correctly.
Same Lua, same macro.

It's strange...
Both times I noticed this happening I was in Delve. I don't remember where the first time, but the second (yesterday) I was buffing just before Calimh pull.
I seriously have no clue how this can happen.
I imagined a random lag issue depending on the newly added Mog Wardrobe but then again it sounds strange, you'd be thinking other people would have noticed and reported such random issues...

you know what, now that you mention it ... again lol... do a //gs showswaps and activate your macro. And tell me if both abilities trigger aftercast...

I remember that I had problem in "lag areas" as monk, when I had a ws macro with boost then ws, my boost aftertaste gear was overtaking my ws precast gear.... then to fix it, in aftercast did add "if spell.name == 'Boost" then return end" and that solved my issue.

Probably it doesn't happen to me as brd coz I don't use a macro to activate those JAs I use the menu, so my delay is more than 1 sec.

[Sechs]

So if I got it right you're saying that becaues of too frequent swaps under a small amount of time (ja1 precast > ja1 aftercast, > ja2 precast > ja2 aftercast) the ones in the middle are overriding or something?
Hmmmm makes sense, because if I recall it's the SECOND ja which didn't get the additional +30 seconds lasting time.
I could solve this the way you said or maybe making that /wait 1 into a /wait 2 or something.

This makes a lot of sense to me. We'd be left only with the question why this happens so rarely and not all the times (maybe only when there's a lot of lag/stuff going on, delve kinda fitting the scenario here).
I'll try with //gs showswaps but it will probably take me a long time before I catch this error again, since it's so rare.

Good tips though, thanks JSH

[Byrthnoth]

That *should* never be an issue with gearswap, because it keeps an internal representation of what your current equipment is, but recent changes might have made it problematic. I'll look in to it tonight or tomorrow.

[Sechs]

If I can help anyway providing you data to work on I'll be glad to do my best, but atm I'm unable to reproduce this small error on will, it's just random.

[Byrthnoth]

There's no need. I have some redundant checks and stuff that shouldn't matter (in theory). I'll start by refactoring them out of GearSwap and changing how it stores the current equipment set, which will simplify a lot of the code. Something that I'll change during this process will probably fix your issue. This will likely take a couple of days to get absolutely perfect, but it will be pushed to -dev each night.


If you guys want to help, just use the -dev launcher ( http://update.windower.net/dev/Windower.exe ) and tell me if you notice that things have broken. Instructions:
1) Duplicate your current Windower folder (the folder with Windower.exe in it) in the same directory. For me it's like this:

Norm Windower: ../Program Files (x86)/Windower/Windower.exe
-dev Windower: ../Program Files (x86)/Windower-dev/Windower.exe

2) Download the -dev launcher from the above link and paste it into the Windower-dev folder.
3) Open the -dev launcher and it should download the things that are different, but your user files should all still be the same because you just duplicated your original folder.
Then you're good to go.

[Staesse]

Hi, I'm using Motenten's SCH lua. Everything has been working fantastically except the weapon lock. When I F9 I set melee mode to Normal and when I F12 I see the Weapon Locked message, but while engaged with a target I am still swapping to cure club/shield. I don't think it has anything to do with Motenten's lua though, because if I call gs disable main from the console it still won't lock my weapon from changing.

[JSHidaka]

That *should* never be an issue with gearswap, because it keeps an internal representation of what your current equipment is, but recent changes might have made it problematic. I'll look in to it tonight or tomorrow.

"should"... but was only happening on "lag areas" like salvage, but it is not "recent" that was the first mnk.lua I made(dic 20 2013 -_- really... the time pass really fast >.>)
http://pastebin.com/6ZcDwYXH

                if spell.name == 'Boost' then
                        return -- Cancel aftercast for boost, coz it was overlapping with the precast of the ws when used all in a macro.
                else

and Since then Im using that code.

probably you already fixed the error when I was engaged and out of range, it would trigger aftercast, but in that file still have the "fix" I used for it.

[roach]

I've been having issues with augmented gear recently. Up until a week ago it was all working, now however it is not.

Spoiler: show

sets.engaged = {ammo="Ginsen",
head="Felistris Mask",neck="Asperity Necklace",ear1="Bladeborn Earring",ear2="Steelflash Earring",
body="Thaumas Coat", hands= {name="Otronif Gloves +1", augments={"Double Attack +2", "Physical Damage Taken -3%", "Magic Damage Taken -4%"}},ring1="Rajas Ring",ring2="Epona's Ring",
back="Atheling Mantle",waist="Windbuffet Belt",legs="Hes. Hose +1",feet="Anch. Gaiters +1"}

sets.engaged.AM = set_combine(sets.engaged,{hands={name="Otronif Gloves +1", augments={"Physical Damage Taken -3%", "Magic Damage Taken -2%", "Critical Hite Rate +2"}}})

sets.engaged.AM.Impetus = set_combine(sets.engaged.AM,{Body="Tantra Cyclas +2",hands= {name="Otronif Gloves +1", augments={"Physical Damage Taken -3%", "Magic Damage Taken -2%", "Critical Hite Rate +2"}},Waist="Cetl Belt",legs={name="Otronif Brais +1", augments={"Physical Damage Taken -3%", "Magic Damage Taken -3%", "Critical Hite Rate +2"}},feet="Otronif Boots +1"})

sets.engaged.Impetus = set_combine(sets.engaged, {hands={name="Otronif Gloves +1", augments={"Physical Damage Taken -3%", "Magic Damage Taken -2%", "Critical Hite Rate +2"}}})

[dlsmd]

I've been having issues with augmented gear recently. Up until a week ago it was all working, now however it is not.

this is because the augments code has changed
but if you want to get all the updated augments you can just equip your gear and use the command 'gs export' this will output a lua file with all your equiped gear with any augments thay might have
the file will look like this

sets.exported={
    main="Darksteel Sword",
    sub="Darksteel Sword",
    head="Tct.Mgc. Hat",
    body="Tct.Mgc. Coat",
    hands="Tct.Mgc. Cuffs",
    legs="Tct.Mgc. Slops",
    feet="Tct.Mgc. Pigaches",
    neck={ name="Hunter's Torque", augments={'AGI+3','MND+3',}},
    waist="Mrc.Cpt. Belt",
    left_ear="Ardent Earring",
    right_ear="Zircon Earring",
    left_ring="Rajas Ring",
    right_ring="Bastokan Ring",
    back="Invisible Mantle",
}

this is an example but i think you can figure out how it works

[Motenten]

@Staesse: Actually, it appears that I completely failed to add the code that locked and unlocked weapons to the sch file. I've updated the version in the repository to fix this.

@roach: What are you seeing when you turn on showswaps and debugmode? Are they not equipping at all, or are they not equipping the correct version? Have you run an export to verify that the augment descriptors match? Is the rest of the gear set being equipped? Have you made any recent changes to your rules? Need more details to even begin to guess at what might be wrong.


@general -- I've just completed a massive rewrite of the TH handling code in the thf lua. It's now based on events instead of polling TP and such, tracks which mobs you've tagged (eg: if you /ra a mob while you're fighting another, it won't equip TH gear when you change to that mob), including AOE hits on multiple mobs (eg: Aeolian Edge), and handles equipping TH gear appropriately when you change targets (either manually, or auto-targetting after a mob is killed).

I'd appreciate anyone using the thf lua to test it out and let me know if it works ok. If you want to see all the ugly details of what it's doing, use the command: //gs c toggle show_th_message

Note that if you use a sidecar file, there are a few small additions in the sets area that you'll want to adjust for, and the default gear variables have been moved to user_setup.

[Johnblaze]

@Mote: I updated to your current THF.lua and the TH tagging works perfectly. Just getting an error with Sneak/Trick Attack, it mentions line 388. I'll have more details once i'm done Salvage.

EDIT: Attempt to index global 'eventArgs' (a nil value) is the error i'm getting. Also seemed to happen when using Feint.

[Motenten]

@Mote: I updated to your current THF.lua and the TH tagging works perfectly. Just getting an error with Sneak/Trick Attack, it mentions line 388. I'll have more details once i'm done Salvage.

EDIT: Attempt to index global 'eventArgs' (a nil value) is the error i'm getting. Also seemed to happen when using Feint.

Ah, right. Fixed. You can grab a new copy, or just edit those lines shown in the link.

[wigmasterflex]

new THF treasure hunter handling seems to be working fine for me!

PS: Is there somewhere else I should be putting the function calls to cancel_conflicting_buffs and refine_waltz so that every time I update a job.lua file I don't have to go do something in game only to realize my stoneskin doesn't auto cancel anymore because I forgot to go add the function call to precast again? Even though all my jobs don't use both of these functions should I just be putting both in the precast of your include instead of individual job.lua's so I only have to remember once? If so I should probably toss in right before the check for show_set I'd assume? I guess I am wondering if there is a better way/location for those function calls to stop being overwritten out of the lua's by file updates, thanks!

PSS: Grats on your D ring sir! 0/39 here now :/

[Motenten]

Is there somewhere else I should be putting the function calls to cancel_conflicting_buffs and refine_waltz so that every time I update a job.lua file I don't have to go do something in game only to realize my stoneskin doesn't auto cancel anymore because I forgot to go add the function call to precast again?

If you use sidecar files for you gear, realize that you can override -any- function from the main job file, including job_precast. On the other hand, that has its own issues with updating stuff (such as the recent tweaks to state.Buff setting).

Hmm. Actually, that's not a bad idea. I'll add a user_precast() function check/call to Mote-Globals, similar to the user_status_change and user_buff_change. And of course you can create your own version in a User-Globals file. That would get called before job_precast.

PSS: Grats on your D ring sir!

^^
Good luck on yours

[wigmasterflex]

If you use sidecar files for you gear, realize that you can override -any- function from the main job file, including job_precast.

Ohhhhhh.... /facepalm.

Hmm. Actually, that's not a bad idea. I'll add a user_precast() function check/call to Mote-Globals, similar to the user_status_change and user_buff_change. And of course you can create your own version in a User-Globals file. That would get called before job_precast.

Perfect solution thanks!

I do use my own globals as I have differently defined global use gear, mostly for my rings but I saw your recent post about adding those to your globals as well... and I had to restructure the default binds (and unbinds @.@) you use to an order that makes more sense to my fingers :D

[wigmasterflex]

So I think I found a typo in your utilities file Mote, there is not value for 'Stoneskin' in the cancel_spells_to_check variable. I added it locally and it works fine of course, and I swear it was working before so must have fallen off at some point.

[Langly]

Nicely done with the THF TH handling. Spot on Motenten!

[Motenten]

So I think I found a typo in your utilities file Mote, there is not value for 'Stoneskin' in the cancel_spells_to_check variable. I added it locally and it works fine of course, and I swear it was working before so must have fallen off at some point.

Ah, ok. I'll get this fixed in the next update.

Nicely done with the THF TH handling. Spot on Motenten!

Good to hear.