Gearswap Help Thread!

[Flippant]

@mote
if i do this it does not work
http://pastebin.com/V073sSJc

but this should work am i correct
http://pastebin.com/ijPt1ynX --the best i could come up with

this works but
http://pastebin.com/S27yaNY2 -- bad because each time you add new sets you would have to add lines to pet_change

As you probably realized based on your second link, the variable is assigned by value once the table has been created, and so even after updating the variable, unless you re-assign the value (like by calling get_sets() again), it won't be dynamically changed. Mote uses tables for these types of variant equipments instead, because tables are assigned by reference.

In other words, pet_main = {name="Eminent Staff"}. Now you can change the value of pet_main.name and it should do what you want.

[gthumbmoogle]

After turning on debugmode, it seems like Mote's SMN lua is equipping my sets.midcast.Pet.PhysicalBloodPactRage set for pet_midcast for Alexander's Perfect Defense. I'd like to have it equip my sets.midcast.Pet.BloodPactWard set at this point, which it used to do properly. Any thoughts?

[dlsmd]

As you probably realized based on your second link, the variable is assigned by value once the table has been created, and so even after updating the variable, unless you re-assign the value (like by calling get_sets() again), it won't be dynamically changed. Mote uses tables for these types of variant equipments instead, because tables are assigned by reference.

In other words, pet_main = {name="Eminent Staff"}. Now you can change the value of pet_main.name and it should do what you want.

the thing is if you do this

pet_main = {name="Eminent Staff"}
function get_sets()
sets.engaged = {main=pet_main}
end

you still have to run function get_sets again even if you change pet_main.name = "blabla" but if pet_main is in get_sets it will get reset to the defaults that are in your file if im understanding lua and gearswap correctly

[Flippant]

get_sets() should only ever be called once, so no, it should never be reset unless your entire file is reloaded. And no, you don't have to call it in order to change the value of pet_main.name.

[dlsmd]

get_sets() should only ever be called once, so no, it should never be reset unless your entire file is reloaded. And no, you don't have to call it in order to change the value of pet_main.name.

but if you have a get sets like this

function get_sets()
	test = {name="blabla"}
	sets.Engaged = {
    main=test,
    sub="Tenax Strap",
    body="Cmb.Cst. Cloak",
    hands="Cmb.Cst. Mitts",
    legs="Cmb.Cst. Slacks",
    feet="Cmb.Cst. Shoes",
    waist="Mrc.Cpt. Belt",
    left_ear="Ardent Earring",
    left_ring="Rajas Ring",
    right_ring="Bastokan Ring",
    back="Invisible Mantle",
	}
	sets.Idle = {
    main=test,
    sub="Tenax Strap",
    body="Cmb.Cst. Cloak",
    hands="Cmb.Cst. Mitts",
    legs="Cmb.Cst. Slacks",
    feet="Cmb.Cst. Shoes",
    left_ear="Ardent Earring",
    left_ring="Rajas Ring",
    right_ring="Bastokan Ring",
    back="Invisible Mantle",
	}
	sets.Resting = {
    main=test,
    sub="Tenax Strap",
    body="Cmb.Cst. Cloak",
    hands="Cmb.Cst. Mitts",
    legs="Cmb.Cst. Slacks",
    feet="Cmb.Cst. Shoes",
    waist="Mrc.Cpt. Belt",
    left_ear="Ardent Earring",
    left_ring="Rajas Ring",
    right_ring="Bastokan Ring",
    back="Invisible Mantle",
	}
end

even if you change test.name it will never change the sets tables with out calling get_sets() again
but with the above get_sets() it will reset all sets to the way thay were when you first loaded your file because there is no way to modify a function once the lua file is running

this is because once you build the table unless you rebuild it you cant dynamically change it no mater what you do
unless you directly modify the table like this

sets.Engaged.main = "blabla"

and just so you know
pet_main = {name="Eminent Staff"}
and
pet_main = "Eminent Staff"
in gearswap are basically the same thing

[Flippant]

I just tested it and it worked fine.

And no, they are not the same thing. Perhaps they accomplish an identical task from the user's end (because GearSwap knows how to properly handle both circumstances), but one is a value and one is a reference. In fact, try printing both of those variables, and you will easily be able to tell which one is the table. If it makes it easier to understand, the following will result "secondTablesecondTable" because only one table exists and it is pointed to by both table1 and table2.

table1 = {title="firstTable"}
table2 = table1
table2.title= "secondTable"
print(table1.title .. table2.title)


Try loading a file with nothing but this:

function get_sets()
    weapon = {name="Terra's Staff"}
    sets.Idle = {main=weapon}
end
  
function status_change(new,old)
    equip(sets.Idle)
end

function self_command(command)
    if command == 'c' then
        weapon.name = "Chatoyant Staff"
    elseif command == 't' then
        weapon.name = "Terra's Staff"
    end
    status_change()
end

and use //gs c c and //gs c t to toggle between them.

[dlsmd]

so why does this work

weapon = {
    [1] = {name="Eminent Pole"},
    [2] = {name="Atar III"},
    } 
table1 = weapon[1]
table2 = {main = table1}
print(table1.name -- shows Eminent Pole
  ..table2.main.name) -- shows Eminent Pole
table1.name = weapon[2].name
print(table1.name -- shows Atar III
  ..table2.main.name) -- shows Atar III

but this does not

weapon = {
    [1] = {name="Eminent Pole"},
    [2] = {name="Atar III"},
    } 
table1 = weapon[1]
table2 = {main = table1}
print(table1.name -- shows Eminent Pole
  ..table2.main.name) -- shows Eminent Pole
table1 = weapon[2]
print(table1.name -- shows Atar III
  ..table2.main.name) -- shows Eminent Pole

i dont understand it

[Flippant]

I'm not familiar with these technical things, so I could be wrong at some point in explaining this.

weapon[1] and weapon[2] are just arbitrary names that you've assigned to point to the tables you've created. Let's say that the real table addresses are AAAA and BBBB, respectively.

When you say table1 = weapon[1], this is creating a new reference to the table AAAA. At this point, weapon[1] and table1 both point to AAAA while weapon[2] points to BBBB.
When you say main = table1, you have now created a third reference pointing to the same table, AAAA. At this point, weapon[1], table1, and table2.main all point to AAAA while weapon[2] points to BBBB.
When you say table1.name = weapon[2].name, you are saying that AAAA.name should now be equal to the same string found at BBBB.name ("Atar III"). At this point, weapon[1], table1, and table2.main all still point to AAAA while weapon[2] points to BBBB, but you have changed table AAAA. In fact, if you print weapon[1].name, it should return "Atar III" (you shouldn't be using a table like that for resources for that reason, you should be using strings so they don't change).

On the other hand, when you say table1 = weapon[2], you are saying that table1 should now point to table BBBB. weapon[1] and table2.main still point to AAAA while weapon[2] and table1 point to BBBB. And since AAAA has not been changed, it will still return the original assigned value.

[Motenten]

Will try to explain this...

We start with two strings:

staff1 = "Eminent Pole"
staff2 = "Chatoyant Staff"

They each point to specific address in memory. That address is permanently fixed. So you could, instead, say:

[xxxx] means an address location
=> means 'stored at'

"Eminent Pole" => [0001]
"Chatoyant Staff => [0002]

staff1 = [0001]
staff2 = [0002]

So when you reference staff1 or staff2, you get whatever string is stored at those specific addresses.

Now, we use that in a set.

sets.Idle = {main=staff1}

{main=staff1} is a key/value pair that's stored in the sets.Idle table. 'main' doesn't contain the variable 'staff1', it contains the -reference- that 'staff1' pointed to when that set was created. We could instead look at it this way:

sets.Idle = {main=[0001]}

So, if we do this:

staff1 = "Chatoyant Staff"

All that we've done is change the string reference that the variable staff1 points to. However 'main' -doesn't- point to 'staff1', it points to [0001].

New values after the above:

staff1 => [0002] (now points to "Chatoyant Staff")
staff2 => [0002]
sets.Idle.main => [0001] (this wasn't changed)

So, even after the above change, sets.Idle.main is still equal to "Eminent Pole".

What I did in my mutable gear variables was add an extra level of indirection: another table.

weapon = {name=staff1}
sets.Idle = {main=weapon}

Now, weapon and sets.Idle are also references. We'll show that they point to addresses after they get created:

weapon => [0003]
weapon.name => [0001] (points to the staff1 string)
sets.Idle => [0004]
sets.Idle.main => [0003] (points to the weapon table)
sets.Idle.main.name => [0001] (the name string currently in 'weapon')

So what can we change here, and what happens when we do? Well, sets.Idle.main is now a fixed reference to the 'weapon' table. If you assign something else to that table, that original reference still remains.

weapon = "Terra Staff"
weapon => [0005] (new string)
sets.Idle.main => [0003] (this didn't change, but we can't reference it from 'weapon' anymore)

On the other hand, what we -can- do is change what 'name' points to. So, ignoring the above Terra Staff assignment, we can do:

weapon.name = staff2
weapon => [0003] (doesn't change)
weapon.name => [0002] (changes to the other string)
sets.Idle => [0004] (doesn't change)
sets.Idle.main => [0003] (doesn't change)
sets.Idle.main.name => [0002] (now points to the other string)


None of this requires that you call get_sets() again.

[dlsmd]

Will try to explain this...

We start with two strings:

staff1 = "Eminent Pole"
staff2 = "Chatoyant Staff"

They each point to specific address in memory. That address is permanently fixed. So you could, instead, say:

[xxxx] means an address location
=> means 'stored at'

"Eminent Pole" => [0001]
"Chatoyant Staff => [0002]

staff1 = [0001]
staff2 = [0002]

So when you reference staff1 or staff2, you get whatever string is stored at those specific addresses.

Now, we use that in a set.

sets.Idle = {main=staff1}

{main=staff1} is a key/value pair that's stored in the sets.Idle table. 'main' doesn't contain the variable 'staff1', it contains the -reference- that 'staff1' pointed to when that set was created. We could instead look at it this way:

sets.Idle = {main=[0001]}

So, if we do this:

staff1 = "Chatoyant Staff"

All that we've done is change the string reference that the variable staff1 points to. However 'main' -doesn't- point to 'staff1', it points to [0001].

New values after the above:

staff1 => [0002] (now points to "Chatoyant Staff")
staff2 => [0002]
sets.Idle.main => [0001] (this wasn't changed)

So, even after the above change, sets.Idle.main is still equal to "Eminent Pole".

What I did in my mutable gear variables was add an extra level of indirection: another table.

weapon = {name=staff1}
sets.Idle = {main=weapon}

Now, weapon and sets.Idle are also references. We'll show that they point to addresses after they get created:

weapon => [0003]
weapon.name => [0001] (points to the staff1 string)
sets.Idle => [0004]
sets.Idle.main => [0003] (points to the weapon table)
sets.Idle.main.name => [0001] (the name string currently in 'weapon')

So what can we change here, and what happens when we do? Well, sets.Idle.main is now a fixed reference to the 'weapon' table. If you assign something else to that table, that original reference still remains.

weapon = "Terra Staff"
weapon => [0005] (new string)
sets.Idle.main => [0003] (this didn't change, but we can't reference it from 'weapon' anymore)

On the other hand, what we -can- do is change what 'name' points to. So, ignoring the above Terra Staff assignment, we can do:

weapon.name = staff2
weapon => [0003] (doesn't change)
weapon.name => [0002] (changes to the other string)
sets.Idle => [0004] (doesn't change)
sets.Idle.main => [0003] (doesn't change)
sets.Idle.main.name => [0002] (now points to the other string)


None of this requires that you call get_sets() again.

so what your saying is it does this
0x01 weapon = {
0x02 [1] = {name="Eminent Pole"},
0x03 [2] = {name="Atar III"},
0x04 }
0x05 table1 = weapon[1] -- makes this table1={name="Eminent Pole"}
0x06 table2 = {main = table1}

so when you change table1 like this
table1 = weapon[2]
it actualy does this
0x01 weapon = {
0x02 [1] = {name="Eminent Pole"},
0x03 [2] = {name="Atar III"},
0x04 }
0x05
0x06 table2 = {main = table1}
0x07 table1 = weapon[2]

but if you change it with
table1.name = weapon[2].name
it does this
0x01 weapon = {
0x02 [1] = {name="Eminent Pole"},
0x03 [2] = {name="Atar III"},
0x04 }
0x05 table1 = weapon[2] -- makes this table1={name="Atar III"}
0x06 table2 = {main = table1}

[Motenten]

If you wrote it that way, then yes. You'd be changing the table itself (and thus the address that it points to), not its contents. table2.main, meanwhile, still points to the original location that table1 pointed to.

With this code:

weapon = {[1] = {name="Eminent Pole"}, [2] = {name="Atar III"}}
table1 = weapon[1]
table2 = {main = table1}

table2.main points to the same -location- as table1 points to. It does not point to the actual table1 variable. If I put in the fake addresses, it would look like:

weapon => [0001]
weapon[1] => [0002]
weapon[2] => [0003]
table1 => [0002] (points to weapon[1])
table2 => [0004]
table2.main => [0002] (points to table1, which points to weapon[1])

After those values have been initialized (get_sets() is run), if you change the value of table1 (ie: table1 = weapon[2]), that has no effect on table2.main. table1 now points to a different location, but table2.main still points to the same original location.

What you want is to have table1 always point to the same location. That way you can manipulate the -contents- of that location, and table2.main will see those same changes because it's pointing at the same location.

To make that work, you'd do:

weapon = {[1] = "Eminent Pole", [2] = "Atar III"}
table1 = {name = weapon[1]}
table2 = {main = table1}

Which looks like:

weapon => [0001]
weapon[1] => [0002]
weapon[2] => [0003]
table1 => [0004]
table1.name => [0002] (points to weapon[1])
table2 => [0005]
table2.main => [0004] (points to table1)
table2.main.name => [0002] (we can reference the contents of table1, which currently points to weapon[1])

Now you don't change table1, you change table1.name

table1.name = weapon[2]

Since table2.main still points to the same location as the original table1, and since table1 itself hasn't changed, they'll both see the change to the -contents- of that location (name=blah).

You never have to run get_sets() again because neither of the table references will ever change. table1 and table2.main will always point to the same location, so they'll always remain in sync. Anything you change inside that location will be reflected on both sides.

[dlsmd]

ok i understand that better

[Trumpy]

The Geo Lua

The Alljobs Include

OK so there is no Geo lua on the gearswap shop thread. So i made one. I dont really like overly complicated stuff likes Motes's luas (no offense) so i generally make my own and incorporate ideas from others Luas i see sometimes. I am not the best coder but I figure id show you guys what i got and it can get submitted to the shop thread or someone can take it and Mote-ify it and post it. Also any improvements are welcome so please hit me with them.

Ok so now here is where i could use some help. When playing Geo i often dont notice luopan dyin or indi spells wearin since there either isnt a message or you cant really see them with all the crap goin on in battle (players, mobs, effects, and what nots). So i put messages in the chat log and also made custom timers for indi/geo spells and now i notice these things a lot better. i believe i have the geo spells taken care of just fine, but the indi spells do have one issue. They let you know (and make a timer when appropriate) when the spell wears or is overwritten by a different indi spell. But do nothing if you recast the same indi spell again. the timer just keeps chuggin along and there's no message in chat log because it doesnt recognize refreshing the same buff as a new buff. Any help would be appreciated.

EDIT: Also how would one go about changin to a particular set in a macro book when one changes subjobs? I have code to change to a book when i switch to geo but wanted to know if its possible to make it change sets based on sub.

function indi_change(indi_table,gain)                                                                   -- Currently wont refresh timer if the same spell is recasted over the same last spell. Could delete the timer up above in precast for indi spells, but would cancel even if interupted! --
        if gain then
                send_command('@timers c Indi-Spell 180 up IndiAura.png')
        else
                send_command('@timers d Indi-Spell;input /echo :::: :::: Indi-Spell Has Expired Or Been Overwritten! Recast If Needed! :::: ::::')
        end
end

[TSFFXI]

EDIT: Also how would one go about changin to a particular set in a macro book when one changes subjobs? I have code to change to a book when i switch to geo but wanted to know if its possible to make it change sets based on sub.

There should be a function in the excel file that is listed as called on support job change.

[Trumpy]

Woohoo! Thank you TSFFXI!

[Orestes]

Mote,

A WHM in my LS has mentioned that her cure casting times were really slow during Incursion this past week. I assumed she had accidentally broke her lua, but that doesn't seem to be the case.

Last night another buddy of mine had to go WHM, and he's also using your latest WHM.lua. He immediately noticed his cures weren't going off as fast as they should, and turned on showswaps.

Apparently, while in Incursion, cures are using sets.precast.FC['Healing Magic'] instead of the more specific set, sets.precast.FC.Cure

My first thought was that lag could be doing this, but I'm not sure. He says the normal set is used outside Incursion, but it's difficult to make sense of that.

I also noticed something similar in my DRK.lua with Absorbs. sets.midcast['Dark Magic'] is being used for all Absorbs, even though I have sets.midcast.Absorb defined. This is on my list to test a little further. I figured the only possibility, is that I should place the sets.midcast.Absorb set above the more general set in my lua.

Could there be something else going on with how Mappings are selected?

Thanks


edit:
Reading into this, it looks like WHM.lua has a job_get_spell_map() function overriding spellMap. The sets this is applying to are only for midcast, but wouldn't this remove the spellMap for sets.precast.FC.Cure and make gearswap look for sets.precast.FC.CureMelee or sets.precast.FC.CureSolace? When it doesn't find them, I'm guessing it defautls to the healing magic set.

I'll have them test without this function.

[Thundro]

Hey guys,

Im having trouble with this GEO.lua here http://pastebin.com/HXqt0J5w

First thing:

I think it is more a general thing, but when I hit f10 or f11 to trigger pdt/mdt mode on, how do I turn them off again? I cant figure out how to go back to idle without reloading the lua

and 2nd:

Is there a way to add a set that equips when I have a luopan out?

[Motenten]

edit:
Reading into this, it looks like WHM.lua has a job_get_spell_map() function overriding spellMap. The sets this is applying to are only for midcast, but wouldn't this remove the spellMap for sets.precast.FC.Cure and make gearswap look for sets.precast.FC.CureMelee or sets.precast.FC.CureSolace? When it doesn't find them, I'm guessing it defautls to the healing magic set.

I'll have them test without this function.

Ah, hmm.. Yes, that could very well be the case. Since my own FC set for cures (compared to healing magic) only adds Tamaxchi/Genbu's Shield, and the only thing that matters is the shield, and I idle in that anyway (along with Bolelabunga), I could have completed missed that problem.

So yes, you'd need FC sets for: Cure, Curaga, CureSolace, and CureMelee.

[Motenten]

Hey guys,

Im having trouble with this GEO.lua here http://pastebin.com/HXqt0J5w

First thing:

I think it is more a general thing, but when I hit f10 or f11 to trigger pdt/mdt mode on, how do I turn them off again? I cant figure out how to go back to idle without reloading the lua

and 2nd:

Is there a way to add a set that equips when I have a luopan out?

Alt-F12 to clear pdt/mdt mode.

Wiki for general docs. Look into setting up .Pet gear sets for the luopan.

[Santi]

Been trying to figure out how to have different engaged sets based on my current main/sub weapons...

Also would like to append an AM3 set ontop of my maxhaste highhaste sets.

Anyone have an example I could look at so I can get this working finally? :>