Gearswap Help Thread!

**dlsmd** · 2014-05-07 22:43

Originally Posted by Sechs

Second:
Am I doing something wrong in "function buff_change"? Afraid it might do too many checks or that I branched the second "if" the wrong way.
Seems to be working altough I did not really understand completely what this part does, I can only grasp it.

the only way i could get the function buff_change to work was like this

Code:

function buff_change(name,gain)
	if name == "sleep" then
		if gain then
			enable("neck","back")
			equip(sets.sleep)
			disable("neck","back","main","sub","range","ammo")
		else
			enable("neck","back","main","sub","range","ammo")
			equip(sets[player.status])
		end
	end
end

name - buff name gain - true if gain false if lose buff
(the cool thing is if i want to add more buff changes i can do it like this)

Code:

function buff_change(name,gain)
	if name == "sleep" then
		if gain then
			enable("neck","back")
			equip(sets.sleep)
			disable("neck","back","main","sub","range","ammo")
		else
			enable("neck","back","main","sub","range","ammo")
			equip(sets[player.status])
		end
	elseif name == "Arcane Circle" then
		if gain then
			equip(sets.drk)
			disable("neck","left_ear")
		else
			disable("neck","left_ear")
			equip(sets[player.status])
		end
	end
end

i have tried
function buff_change(buff, gain) gain - got true false, buff - got me nothing

**Sechs** · 2014-05-08 02:37

Originally Posted by Motenten

If you try to use a JA (or spell), but the recast timer isn't ready, aftercast is called with spell.interrupted == true. Thus, if you try to use sublimation/perpetuance/etc and it's not available because of the recast timer, it won't attempt to change your config.

Ah, didn't know this.
Very useful then! Changed the "if" branching in light of this.

Come back here and provide both what you wrote out for yourself, and what you wrote out as code.

When I gain certain buffs from JAs (Perpetuance, Penury, Parsimony, Sublimation: Activated) I want a specific boolean to change to "true", so that I can use "if boolean == true then" as a way to check for the relative buff being active without having to worry about the client notification delay. I will also need a way to set this boolean to "false" once the buff expires, otherwise it will stay fixed on "true" after the value gets assigned the first time.

Looking back at my code and comparing Function Aftercast with with Buff_change, I'm noticing a bit of redundancy.
They basically do the same thing but at different moments. They change the boolean to true, one after the JA is really performed, one after the ja-related buff is gained.
Only (important!) difference is that Buff_change also changes the boolean to false when the related buff is lost/consumed/cancelled. The same doesn't happen with the aftercast rule.

So, following this and SUPPOSING that the buff_change function doesn't have the delay issues of buffactive['buffname'] I could:
1) remove the "if buff then equip" thing from the buff_change function
2) remove the boolean handling from the aftercast and just leave the "if buff then equip else equip"

Something like this:

Code:

function aftercast(spell,action)
	if state.Buff['Sublimation: Activated'] == true then
		equip(sets.Idle.Sublimation)
	else
		equip(sets.Idle)
	end
end

function buff_change(buff,gain)
	if state.Buff[buff] ~= nil then
		state.Buff[buff] = gain
	end
end

If my supposition is correct (but is it?) this should work.
If it's not, then I'm gonna need the aftercast boolean-handling lines back and the buff_change's role at that point would become that of resetting the booleans to false once the related buffs expire. (and to equip Subli set since the one in aftercast would work for all circumstances except the buffgain one due to delay issues)

**Shadowmeld** · 2014-05-08 12:01

That still shouldn't work because at aftercast you still haven't gained the buff. So when you use sublimation to turn it on it will still equip sets.Idle until your next action.

**theblackdeath** · 2014-05-08 13:29

im back so i have this line of code and it works for using doubleshot but when its used in this way apart from typing it in or selecting it from the menu it doesnt change the double shot head piece but like i said if i use the menu it does any thoughts on how to fix this?

if (spell.english == 'Ranged') and not buffactive.Amnesia and not buffactive.Paralysis and windower.ffxi.get_ability_recasts()[126] < 1 then
print('made it here!')
windower.send_command('Double Shot; wait 1; '..spell.name..' '..spell.target.raw)
cancel_spell()
return
end

**Motenten** · 2014-05-08 14:23

Originally Posted by Sechs

When I gain certain buffs from JAs (Perpetuance, Penury, Parsimony, Sublimation: Activated) I want a specific boolean to change to "true"

Entire response is failing to follow directions.

You don't want to change any boolean. Boolean is code, and you're explicitly not supposed to be dealing with code in this section. The entire post is exactly what you're -not- supposed to be writing, here.

Examples of what I meant:

When I (successfully) use the JA 'Perpetuance', I want to ensure that any Enhancing Magic spell that I cast (aside from prot/shell/erase/warp/teleport) while the buff is active gets the Savant hands equipped while casting it.

When I (successfully) use the JA 'Penury', I want to ensure that any White Magic spell that I cast while the buff is active gets the Savant legs equipped while casting it.

When I use the JA 'Sublimation' and gain the Sublimation: Activated buff (which means I didn't have any sublimation effect active before using the JA), then I want my idle gear to start using items with +sublimation effect.

When I lose the Sublimation: Activated effect (either because it finished filling up, or I used the Sublimation JA again), then I want idle gear to return to using default refresh items.

Etc.

Originally Posted by Sechs

So, following this and SUPPOSING that the buff_change function doesn't have the delay issues of buffactive['buffname'] I could:

The buff_change function doesn't "have" the delay issue, it is merely one boundary of the issue. Remember:

aftercast is called
~delay
buff_change is called

New exercise (since you failed the previous exercise):

Take the above four example statements and translate them into code, step by step. Show exactly which bit of code matches exactly which part of each sentence, and show where you're going to put it in the overall code structure.

Treat each sentence separately -- that is, write the code that represents each sentence (along with the full explanations) as if you were doing this exercise four separate times. Only do a final merge of all code at the end, after all four have been completed.

**Sechs** · 2014-05-08 14:23

Originally Posted by Shadowmeld

That still shouldn't work because at aftercast you still haven't gained the buff.

Which implies my supposition is wrong and that function buff_change has the same "delay issue" as buffactive.
But still, if the role of handing booleans into aftercast is to put those variables to "true" so that I can then perform my check, the role of the buff_change should be single, that is to set the boolean to "false" when the buff is lost.
If I leave that "state.Buff[buff] = gain" it would work both ways: when a buff is gained it would set the boolean to true (redundant with the aftercast) and when the buff is lost it would set the variable to false (necessary step).

Originally Posted by Motenten

aftercast is called
~delay
buff_change is called

Point taken.

/gets back to work

**Shadowmeld** · 2014-05-08 14:48

You should really just look at doing an equip in the buff_change function.

You have two problem cases in your code (which Mote has kind of already alluded to). First is when you activate sublimation. Because of the order of processing, you won't equip your sublimation gear on cast because the buff_change function runs after aftercast. Your second issue is when 'Sublimation: Activated' expires, either because it has changed to Sublimation: Complete or you have again used the ability sublimation, all it does is change the state boolean to false. You will still continue to have your sublimation set equipped until your next job ability or equip packet is sent.

It is infinitely easier and simpler to deal with equipping gear in the buff_change function than trying to manipulate booleans and get your desired result.

Edit: It really isn't so much a delay 'issue' as much as an order of operations problem. Gearswap, unlike spellcast doesn't really have delay issues as such, its just that it performs aftercast functions before buff_change. The delay is virtually 0, it just doesn't do concurrency which would present its own problems.

**JSHidaka** · 2014-05-08 16:19

tl;tr.... actually did read something ~.~

@Sech
Just remember one thing... they are many ways to get what you want when codding... from what I could get, you wanna idle on a Sublimation Set when Subli is "filling", otherwise in the normal idle, here is the "simple" way to do it http://pastebin.com/YxYgH4yU

**Sechs** · 2014-05-09 01:42

Originally Posted by JSHidaka

from what I could get, you wanna idle on a Sublimation Set when Subli is "filling", otherwise in the normal idle

That was the initial situation.
I used this simple coding

Spoiler: show

It WAS working, except in one situation: the moment I activate Subli.
I could have solved the issue very simply creating a precast rule for Subli, but came here lookin for guidance regardless.
Thanks to the replies of other people I found out a bigger issue which was concerning not just Subli, but some other stratagems rules where I had buffactive checks.
So I kinda changed my aftercast and added a buff_change, and in the end they looked like this:

Spoiler: show

This DOES work, everytime, even the second I activate Subli, it automatically changes when it's fully charged and so on.
So you could say I had solved my problems. But the thing is that even without fully understanding those lines of code, I was getting a hunch that something wasn't perfect, that there were some useless lines, some redundancy.
Aftercast was ==> assigning "true" to booleans on the use of JAs, handling my aftercast idle sets with a check on the boolean instead than buffactive
Buffchange was ==> assigning "true" or "false" to the same booleans according to buff gained or lost, equipping my idle sets with a check on the boolean.

So... Aftercast alone wasn't enough because I needed something to set booleans to "false" (otherwise they would have stayed on "true" endlessly once activated the first time). Buff_change was doing that, but it was also doing the "true" part a second time, and that was redundant.
Having if-then-equip in both functions was also useless and redundant.

I was confused by this, and came here to solve it. But it was just a matter of creating better code with less redundancy, because result-wise I had already reached my goal. (not with my own two hands of course

)

**dlsmd** · 2014-05-09 03:11

Originally Posted by Sechs

That was the initial situation.
I used this simple coding

Spoiler: show

It WAS working, except in one situation: the moment I activate Subli.
I could have solved the issue very simply creating a precast rule for Subli, but came here lookin for guidance regardless.
Thanks to the replies of other people I found out a bigger issue which was concerning not just Subli, but some other stratagems rules where I had buffactive checks.
So I kinda changed my aftercast and added a buff_change, and in the end they looked like this:

Spoiler: show

This DOES work, everytime, even the second I activate Subli, it automatically changes when it's fully charged and so on.
So you could say I had solved my problems. But the thing is that even without fully understanding those lines of code, I was getting a hunch that something wasn't perfect, that there were some useless lines, some redundancy.
Aftercast was ==> assigning "true" to booleans on the use of JAs, handling my aftercast idle sets with a check on the boolean instead than buffactive
Buffchange was ==> assigning "true" or "false" to the same booleans according to buff gained or lost, equipping my idle sets with a check on the boolean.

So... Aftercast alone wasn't enough because I needed something to set booleans to "false" (otherwise they would have stayed on "true" endlessly once activated the first time). Buff_change was doing that, but it was also doing the "true" part a second time, and that was redundant.
Having if-then-equip in both functions was also useless and redundant.

I was confused by this, and came here to solve it. But it was just a matter of creating better code with less redundancy, because result-wise I had already reached my goal. (not with my own two hands of course

)

would not this work just as good??

Code:

function precast(spell)
	if spell.english == 'Sublimation' then
		equip(sets.Idle.Sublimation)
		disable("head","body","main","left_ear")
	end
end
function buff_change(name,gain)
	if name == 'Sublimation: Activated' then
		if not gain then
			enable("head","body","main","left_ear")
			equip(sets.Idle)
		else
			equip(sets.Idle.Sublimation)
			disable("head","body","main","left_ear")		
		end
	end
end

**Motenten** · 2014-05-09 03:12

Originally Posted by Sechs

But the thing is that even without fully understanding those lines of code, I was getting a hunch that something wasn't perfect, that there were some useless lines, some redundancy.

Good intuition. Since what you have is fully functional, let's look at improvements.

-- Begin Lesson --

Code:

function aftercast(spell,action)
    if not spell.interrupted then
        if state.Buff[spell.name] ~= nil then
            state.Buff[spell.name] = true
        end
    end
    if state.Buff['Sublimation: Activated'] == true then
        equip(sets.Idle.Sublimation)
    else
        equip(sets.Idle)
    end
end

function buff_change(buff,gain)
    if state.Buff[buff] ~= nil then
        state.Buff[buff] = gain
        if state.Buff['Sublimation: Activated'] == true then
            equip(sets.Idle.Sublimation)
        else
            equip(sets.Idle)
        end
    end
end

First redundancy - This bit of code is repeated in each function:

Code:

        if state.Buff['Sublimation: Activated'] == true then
            equip(sets.Idle.Sublimation)
        else
            equip(sets.Idle)
        end

(Small refinement: We can also shorten the first IF check since the [ == true] is implied.)

It needs to be abstracted out (see part 5 of my tutorial). Since there's no TP gear to worry about, we can just toss a simple function in:

Code:

function aftercast(spell,action)
    if not spell.interrupted then
        if state.Buff[spell.name] ~= nil then
            state.Buff[spell.name] = true
        end
    end
    
    equip_idle_gear()
end

function buff_change(buff,gain)
    if state.Buff[buff] ~= nil then
        state.Buff[buff] = gain
        equip_idle_gear()
    end
end

function equip_idle_gear()
    if state.Buff['Sublimation: Activated'] then
        equip(sets.Idle.Sublimation)
    else
        equip(sets.Idle)
    end
end

Now there's the question you have about setting the state to true in buff_change when it's already true. First, let's look at what would be necessary to not redundantly set the value:

Code:

function buff_change(buff,gain)
    if state.Buff[buff] ~= nil then
        if state.Buff[buff] ~= gain then
            state.Buff[buff] = gain
        end
        equip_idle_gear()
    end
end

And we see that we have to add an extra conditional (this is the simplest form I can get the conditional to take; there are more complicated versions that you're likely to try first) to ensure that we don't set a variable to a value it already contains. It's no longer redundant, but to do that we've actually lost some efficiency.

Next we consider that, in order to set the state value to false we -must- include the statement: state.Buff[buff] = gain. That instruction will be there no matter what, and it's just a matter of it running on its own, or running in combination with other code.

Next we consider how expensive that statement is. If it's an expensive assignment, adding extra conditionals to prevent it from being run unless absolutely necessary would be a sound choice. However, it's an assignment of a boolean value, which is about as cheap an action as we can get.

Thus we have the choice between a single cheap assignment that always runs, or a cheap assignment that sometimes runs combined with a conditional that always runs. The latter option is probably more expensive because the comparison and the assignment will have nearly the same cost, therefore the former option is the better (and simpler, more understandable and maintainable) choice.

Next we look for any other duplicate code. We find one bit of near-duplication:

Code:

    if state.Buff[spell.name] ~= nil then
        state.Buff[spell.name] = true
    end
        
    if state.Buff[buff] ~= nil then
        state.Buff[buff] = gain
        equip_idle_gear()
    end

We can abstract that (somewhat) to this function:

Code:

function update_buff_state(buff, state)
    if state.Buff[buff] ~= nil then
        state.Buff[buff] = state
    end
end

The question then becomes whether equip_idle_gear() -needs- to be inside the check for a buff state change.

Now, equip_idle_ gear is a somewhat expensive call (relatively speaking). Taking it out of the conditional check means that it gets run on -every- buff change, rather than just the ones that we're tracking state for, though realistically that's not going to truly hurt us.

Code:

function update_buff_state(buff, state)
    if state.Buff[buff] ~= nil then
        state.Buff[buff] = state
        equip_idle_gear()
    end
end

We can also consider that equipping idle gear is something we're -always- going to do whenever a tracked buff changes anyway, and just add it to the abstracted function that covers the other three lines. The problem with that is that we'd create a function with a side-effect. That is, it does what it says it does (update buff state), but it also does something else (equip idle gear). That's generally considered a Bad Thing.

So we end up with one of three scenarios:

1) Keep the original duplicated code.
2) Create a function with a side-effect, which requires additional code at the calling site to prevent duplicate efforts (ie: you still need to call equip_idle_gear() on non-state-tracked actions, so either you add a return to prevent calling it twice, or you accept that sometimes it will be called twice).
3) Create a function without a side-effect, but that will call equip_idle_gear() for all buff changes.

The main question is whether the abstraction is worth that extra complication. From a code cleanliness perspective, where the loss of performance can be ignored, I'd go with option 3. If the performance hit is too large a concern, I'd stay with option 1. I'd largely try to avoid option 2 unless absolutely necessary.

Since we already have option 1 written above, I'll write option 3 here:

Code:

-- event functions --

function aftercast(spell,action)
    if not spell.interrupted then
        update_buff_state(spell.name, true)
    end
    
    equip_idle_gear()
end

function buff_change(buff,gain)
    update_buff_state(buff, gain)
    equip_idle_gear()
end


-- user functions --

function update_buff_state(buff, state)
    if state.Buff[buff] ~= nil then
        state.Buff[buff] = state
    end
end

function equip_idle_gear()
    if state.Buff['Sublimation: Activated'] then
        equip(sets.Idle.Sublimation)
    else
        equip(sets.Idle)
    end
end

aftercast() and buff_change() are then extremely simple, and pretty self-explanatory (so the code will still be understandable when you come back to it after a long absence).

-- End Lesson --

**Motenten** · 2014-05-09 03:18

Originally Posted by dlsmd

would not this work just as good??

Code:

function precast(spell)
	if spell.english == 'Sublimation' then
		equip(sets.Idle.Sublimation)
		disable("head","body","main","left_ear")
	end
end
function buff_change(name,gain)
	if name == 'Sublimation: Activated' then
		if not gain then
			enable("head","body","main","left_ear")
			equip(sets.Idle)
		else
			equip(sets.Idle.Sublimation)
			disable("head","body","main","left_ear")		
		end
	end
end

No, because then you're prevented from changing those gear slots for -any reason- while Sublimation is activated. For the most egregious restriction, you cannot cast Impact while Sublimation is active, using that code. Further, it disables the slots on any use of the Sublimation JA. However you also use the Sublimation JA to recover the stored MP, which means that if you use Sublimation, fill up the pool (so the buff_change() function re-enables the gear slots), then use Sublimation again to recover that MP, those gear slots are locked until the -next- time you turn on Sublimation, -plus- the time to refill the pool again.

Overall, very bad bit of code.

**Sechs** · 2014-05-09 04:26

Originally Posted by Motenten

The main question is whether the abstraction is worth that extra complication.

This is a very practical point of view.
Thanks for your whole post, in addition to the help with coding, it offered a very interesting new perspective on the issue, giving me new factors and aspects I had never even considered before.

**JSHidaka** · 2014-05-09 07:15

Originally Posted by Sechs

I was confused by this, and came here to solve it. But it was just a matter of creating better code with less redundancy, because result-wise I had already reached my goal. (not with my own two hands of course

)

That's the point of this thread

Byrth and Mot have work in most(or every) luas made in this thread lol

I suppose Mot works as a programmer or something that have to do with it, if it's just a hobby, man I wish I could be that dedicated with it. Lol

**Yamoman** · 2014-05-09 08:16

Anyone know why adding this line of code to job_precast not working (cancel_conflicting_buffs(spell, action, spellMap, eventArgs)), doesnt overwrite existing jigs or utsemini? Thx in advance. IE

function job_precast(spell, action, spellMap, eventArgs)

cancel_conflicting_buffs(spell, action, spellMap, eventArgs)

-- Don't gearswap for weaponskills when Defense is on.
if spell.type:lower() == 'weaponskill' and state.Defense.Active then
eventArgs.handled = true
elseif spell.type == 'Waltz' then
refine_waltz(spell, action, spellMap, eventArgs)
end

**Falkirk** · 2014-05-09 08:43

Do you have the Cancel add-on installed and active?

**Shadowmeld** · 2014-05-09 15:34

I have set up a few auto rebuff rules for my sch, but for some reason, one of them doesn't work all the time, but it does work sometimes. It is really weird.

Code:

function handle_aftercast_post(spell, action)

	if auto_storm and not buffactive[elements.storms[auto_storm_element]] and spell.english ~= elements.storms[auto_storm_element] then
		windower.send_command('wait 3; input /ma "' .. elements.storms[auto_storm_element] .. '" <me>')
	elseif auto_klimaform and not buffactive.Klimaform and spell.english ~= 'Klimaform' then
		windower.send_command('wait 3; input /ma "Klimaform" <me>')
	end

end

aftercast function calls handle_aftercast_post 100% of the time. For some reason, it will apply Klimaform one time first thing (before my storm spell) and then it will always do the storm spell and never will recast Klimaform. Any ideas why?

I also have a buff change rule that casts Klimaform just fine.

**Motenten** · 2014-05-09 15:44

Add this at the start of the function:

Code:

    add_to_chat(123,'auto_storm='..tostring(auto_storm)..', auto_storm_element='..tostring(auto_storm_element)..', storm='..tostring(elements.storms[auto_storm_element])..', buffactive='..tostring(buffactive[elements.storms[auto_storm_element]])..', spell='..spell.english)

Since you said it skips the storm on first run, see what the values for each of those fields are, and whether the conditional -should- pass.

**Yamoman** · 2014-05-09 22:37

Yes cancel is installed and on from both Addons and plugins.

**Motenten** · 2014-05-09 23:53

Originally Posted by Yamoman

Yes cancel is installed and on from both Addons and plugins.

Note: the plugin version can't handle the formatting that my lua uses (eg: "cancel sneak"). If you have both the plugin and the addon running, the plugin may be interfering.

Thread: Gearswap Help Thread!

Thread Tools

Similar Threads

Spellcast Help Thread (Link your XML using Pastebin.com for help!)

Latest Threads

Up & Coming Threads

Hottest Threads