Gearswap Support Thread |
||
|
Gearswap Support Thread
You can always make a macro but since doom pretty much always has highest priority whenever it lands and some of the holy water equipment overlaps with cursna equipment anyway why not make doom the if condition:
Code
if buff == "doom" then
if gain then
equip(sets.midcast.Cursna)
disable('ring1','ring2','waist')
else
enable('ring1','ring2','waist')
end
end
make sure to place it in the correct wrapper function, probably something with "buff_change" or use the Code buff_change(name,gain,buff_details) function from the documentation to verify wether doom is active or not. Asura.Sechs said: » Not properly a direct Gearswap question, but hoping to find help in here. So I recently found out that if you use a set_combine with a set that's defined after the one you're currently creating, Gearswap won't give you an error and the Lua will be correctly loaded, but the set won't be really combined. Example: Code set.example = set_combine(set.test, {stuff})
...
...
set.test = {stuff2}Basically set.example will only have "stuff" inside, and the content of the combined set (stuff2) will be ignored. Hopefully I explained the issue! Now, my real problem is another. Basically I know that in my luas I have AT LEAST one example like this and I want to fix it, but... I have no bloody clue in which Lua it could be and I'm lazy and don't wanna read all of them from line 0 to the end. Can anybody think of a system where I could "find" this thing in all of my luas? Couple days later, try this: https://pastebin.com/raw/eUFUCsYN It looks for cases of "set_combine(SETNAME" and "SETNAME =", then records the lines that SETNAME is used in each case. It needs python 3 to run, so get that first. There's no UI, edit in your gearswap folder path directly near the top. It spits interesting lines to console, like so: Code Radec_Blm_Gear.lua sets.idle {'referenced_lines': [132, 133], 'defined_line': 268}
Radec_Blu_Gear.lua sets.precast.FC['Enhancing Magic'] is never defined in this file, but used on [262]
Radec_Bst_Gear.lua sets.engaged.MEva is never defined in this file, but used on [210]
Radec_Cor_Gear.lua sets.precast.WS["Leaden Salute"] is never defined in this file, but used on [203, 205]
Radec_Geo_Gear.lua set_combine(sets.precast.FC is never defined in this file, but used on [102]
Radec_Geo_Gear.lua sets.idle.PDT is never defined in this file, but used on [193]
Radec_Geo_Gear.lua sets.idle.PDT.Pet is never defined in this file, but used on [194]
Radec_Pup_Gear.lua {head="Nyame Helm" is never defined in this file, but used on [138, 140]
Radec_Run_Gear.lua sets.precast['Lunge'] is never defined in this file, but used on [170, 171]
Radec_Run_Gear.lua sets.engaged.TankAnnul {'referenced_lines': [185], 'defined_line': 270}
Radec_Smn_Gear.lua {ammo="Epitaph" is never defined in this file, but used on [184]
Radec_Smn_Gear.lua sets.midcast.Pet.PhysicalBloodPactRage.Acc is never defined in this file, but used on [215, 217, 219, 221, 223]
Radec_Whm_Gear.lua sets.precast.FC['Healing Magic'] is never defined in this file, but used on [68]Looking at one sample line: Code Radec_Blm_Gear.lua sets.idle {'referenced_lines': [132, 133], 'defined_line': 268}Another: Code Radec_Smn_Gear.lua {ammo="Epitaph" is never defined in this file, but used on [184]One more: Code Radec_Bst_Gear.lua sets.engaged.MEva is never defined in this file, but used on [210] I didn't do much for error checking. Example: Code Radec_Cor_Gear.lua sets.precast.WS["Leaden Salute"] is never defined in this file, but used on [203, 205]
[+]
so I have an idea and don't know how feasible it is:
On SAM, I want to be able to lock ranged and ammo when Yoichi is equipped, but also be able to reload my stack of arrows before I hit the Namas macro and see my ammo is empty. As soon as I disable ammo, so melee ammo doesn't overwrite, GS doesn't equip arrows. I'm trying to stay away from a separate combat mode for melee yoichi with the only difference is ranged/ammo. Right now I have a check on engaged/idle so if yoichi is equipped, disable those slots. Is there a better way to do this? I've tried searching but not sure if I have right questions or if I'm overcomplicating things There might be a way but I couldn't find it and I had the same issue with the disable option. When I created my SAM lua I simply added a "Bow mode" var.
If Bow mode is On, then Yoichi and arrows will be equipped, otherwise defaulting to the regular set, whatever it is. Bismarck.Arcos said: » On SAM, I want to be able to lock ranged and ammo when Yoichi is equipped, but also be able to reload my stack of arrows before I hit the Namas macro and see my ammo is empty. For motes based lua you can you can try using Code function job_post_precast() and Code function job_post_midcast() and add this to the end of both Code if player.equipment.range == "Yoichinoyumi" then
equip({ammo="Arrow of Choice"})
endIf you do not use a motes based lua, you can just add the final code block to the end of your Code function precast() and Code function midcast() If you also add this to the end of aftercast, you shouldn't need to disable range and ammo slots. EDIT: Forget the {} around the ammo equip. Is there a way to look up a job ability recast time using just the job ability name within a JOB.lua file?
This is the section I'm trying to do it in, it runs when there is a TP event change. It works currently but I'm struggling to figure out how to Code --[[windower.register_event('tp change', function(tp)
local recasts = windower.ffxi.get_ability_recasts()
if not buffactive['Warcry'] then
if recasts[2] == 0 then
send_command('command')
end
end
Instead of recasts[2] which references the ability_recasts ID, I'd like to be able to use 'Warcry' in some way and have it look up what the correct ID is. I've tried the following with no luck: Code
recasts[require(resources.job_abilities:with('en','Retaliation').id)]any suggestions? can this be done within the JOB.lua file in gearswap or is there more to it ? Add to the top of the file somewhere
Code
res = require('resources')
Then similar to what you have will work: Code
local recasts = windower.ffxi.get_ability_recasts()
if not buffactive['Warcry'] then
if recasts[res.ability_recasts:with('en','Warcry').id] == 0 then
send_command('command')
end
end
Bismarck.Radec said: » Add to the top of the file somewhere Thank you!! Will give this a whirl Ok so I want to do something strange on a new Lua I'm building, and I can't think of anything but two separate methods, having issues with both but maybe there are other means to achieve my goal.
What I want to do Avoid a situation where I ran out of my "regular" bullets and because of that I accidentally attempt to consume my "special" one. Solving Method 1 Each time I try to perform an action that can potentially consume a bullet, I want to set the ammo "empty", right before going through my normal cycle of preshot/midshot. That way, if I ran out of Chrono Bullets, the action will simply abort because of lack of ammo and my special one will be safe. Solving method 2 Each time I attempt to perform an action that can potentially consume bullet, check if I have at least 1 chrono bullet either in my inventory or in my wardrobe7. If I do then proceed, otherwise halt the action. How can I check for the presence of an item in my inv or w7 though? Furthermore I'm trying to have a special behaviour for my Ranged WSs in my precast function. I'm tryin to check for this Code elseif spell.prefix == "/weaponskill" and not (spell.interrupted) then if spell.skill == 26 then But spell.skill is not returning "true" to 26 when I try to use Wildfire or Hot Shot or Last Stand, yet they are skill 26 (Markmanship) indeed. What am I doing wrong in this check here? Why isn't it returning "true" as expected? Shouldn't be doing either of those. Proceeding if you have normal ammo without equipping it first means can potentially shoot special ammo.
On shooting or ws-ing check if current ammo is special bullet and try and equip normal bullet. Don't need to set to empty first, can just check current equip on precast. This should be done on precast for both RA and WS. If no normal bullet abort. Code
if player.equipment.ammo:startswith('Hauksbok') or player.equipment.ammo == "Animikii Bullet" then
<check if normal ammo, equip, disable ammo slot and continue>
<no normal ammo, abort>
Hmm that's keen.
Tested it for /ra, works fine. I need further info for Weaponskills though. I don't want this "check for current ammo" to happen on any ws, I want it to happen only when I'm using ranged WSs. How can I tell ranged WS from all other WS? I thought about using .skill or .range but they don't seem to be working. (.range is "12" for all ranged WS, .skill is "26" for all gun WSs) Can use spell.type and spell.skill. Spell.skill is the skill type, eg archery or masksmanship for ranged WS.
Code
if spell.type == 'Weaponskill' and (spell.skill == 'Marksmanship' or spell.skill == 'Archery') then
<..>
yeah been tryin with that (spell.skill == 'Marksmanship') but it's not passing the check, yet in the weaponskills.lua in RES it clearly states all the WS I'm trying are marked down as 26, i.e. Marskmanship.
Edit: Nvm I finally found the typo... It works! Thanks :D Just hoping for a bit of advice here. Im trying to use a Send command from my main to my brd mule in order to get her to cast Valor Minuet V. She casts it as usual but she has stopped gearswapping for some reason. She swaps as normal if I cast on her directly.
Hope this is in the right thread. Thanks in advance. Whats the send command you are using?
I cannot replicate the issue with Code //send BardNameHere /ma \"Valor Minuet V\" <me> or Code /con send BardNameHere /ma \"Valor Minuet V\" <me> /console send Feyrith /ma 'Valor Minuet V' <me>
It's in a macro. I'll try what you suggested thankyou. The spell goes off no problem, it just doesn't trigger Gearswap for some reason. Second one worked! Thanks very much. Still not sure why that happened though...
Is there a file or folder that lists all the job ability and spell IDs? More specifically, I'm looking for the abil_recasts[#] ID for the THF ability Conspirator.
Odin.Valisk said: » Is there a file or folder that lists all the job ability and spell IDs? More specifically, I'm looking for the abil_recasts[#] ID for the THF ability Conspirator. IIRC Windower/res folder is where the ability database lives.
[+]
I know not to use quick magic in my spells that macc matters but for low cast time spells, say Flash for example, how much fast cast can gearswap actually handle? How much fast cast can I add before GS isn't actually swapping from my precast FC set -> midcast SIRD set -> Enmity set in time?
Shiva.Cerderic said: » FC set -> midcast SIRD set -> Enmity You cannot have 2 midcast sets (SIRD and Enmity). What should be happening is Enmity+SIRD (Enmity base with SIRD replacing pieces of the Enmity set). As for quickcast, I believe GS can catch it and equip midcast in time. drakefs said: » As for quickcast, I believe GS can catch it and equip midcast in time. If it is, then it's not particularly reliable because a lot of times it's gonna be calculated by the game using your Precast gear. Gearswap is incredibly reliable about quick cast. You will finish your cast in midcast gear properly on quickcast procs... provided you cast in a measured manner, and don't spam your macro. Spamming like this can cause an issue, where, as I understand it, you fill the outgoing packet to the limit with spammed equipswaps, and the cuttoff can potentially leave you in precast.
A test I like to do for quickcast, is to cast phalanx in potency gear, then use spontaneity for force a quick magic proc, and cast again. If it overwrites, then your midcast was on when the spell resolved. Reset JA, and repeat. Or just chainspell and keep casting. The only times I've ever found myself finishing casts in precast gear, was when I spammed the macro. Shiva.Cerderic said: » I know not to use quick magic in my spells that macc matters but for low cast time spells, say Flash for example, how much fast cast can gearswap actually handle? How much fast cast can I add before GS isn't actually swapping from my precast FC set -> midcast SIRD set -> Enmity set in time? If you want your SIRD gear to always work, then you must spend the entire midcast to spell completion period wearing it. Fortunately, gearswap can ensure you don't take a hit wearing precast gear, so at least we can still use full fastcast gear. Can test it on BRD with NiTro as well. When it's up songcasting become instant.
Sadly even without macrospamming (I hardly ever use macros to begin with these days, I just type stuff with Shortcuts) I ran into the issue of songs being executed with precast gear more often than I wanted to. Same for any other player-controllable instacast mechanism. Because of that, to handle situations where you're sure you're gonna be instacasting, I added a special rule in my luas where I precast with my intended midcast gear. Never had an issue ever since. Of course you can't do this with "regular" quick magic because it's a 10% chance to happen and you can't know in advance if it's gonna proc or not. Sechs, I wouldn't rule out a human error in your LUA placing the wrong sets in midcasts. It's near if not totally impossible for an error to occur between the transition from pre-cast to mid-cast in GearSwap. If you are typing as you say, and and enter multiple commands in sequence too fast, you could end up with the same situation as spamming a macro.
Bahamut.Balduran said: » Sechs, I wouldn't rule out It's not an error and as a matter of fact is something that happened only sometimes, not every time an "insta cast" happened. Sadly more often than it was acceptable for me, and so I resorted to other means to fix that. On a hunch it's quite likely related to packet loss, regardless of that though, as I mentioned before, its frequency was higher than acceptable for my standards. If I asked you how you are so sure that your spells actually went of in the wrong set, how would you be able to prove it?
Also, in regards to the packet loss point you mentioned, this very point was explained before by Thorny (lolwutt) Quote: The outgoing packet contains precast swaps, action packet, and midcast swaps. The packet handling is single threaded, and thus it will always finish reading the entire packet before doing anything else. This means that the game server reads in precast, reads in action(and determines how long the action will take), then reads in midcast and updates your stats before doing anything else. This means it's not really related to packet loss, because if it was, then entire process wouldn't go through. Thought I'd share this with you to get some facts straight and hopefully figure out what exactly is going on with your casting. Asura.Sechs said: » Can test it on BRD with NiTro as well. I have never seen it miss midcast gear with Nightingale, which would be VERY noticeable because the song duration would be off. Bahamut.Balduran said: » If I asked you how you are so sure that your spells actually went of in the wrong set, how would you be able to prove it? Keep in mind we're talking about Songs here, it's the first instance where I originally noticed this, years ago. It also spun a pretty large conversation here on these boards involving other notorious people like Byrth etc. From there, I noticed it was happening in other similar situations as well. Of course nothing you can do for stuff like "regular" quick magic procs, but for situations where you're sure an "insta cast" is gonna happen 100% of the times, I see no problem in using midcast gear in your precast set, to bring the chance of that bad behaviour to happen pretty close to zero. As for the rest, I'd love to link the original discussion to you but I honestly have no clue in which specific thread it happened. I have vague memories of how it ended but I seem to recall the general consensus was that packet-loss was somewhat related to those occurrencies. I could be wrong of course! I just followed tips that came out from that discussion. For who's being curious, I never had that issue again since when I changed my precast/midcast behaviour. Of course I'm talking about those situations where I'm 100% sure an insta proc is gonna happen. For everything else... nothing you can do about it, I just accept the fact it might happen /shrug drakefs said: » Asura.Sechs said: » Can test it on BRD with NiTro as well. I have never seen it miss midcast gear with Nightingale, which would be VERY noticeable because the song duration would be off. Which is exactly why I noticed it so easily :-D I can say in the original convo I mentioned above, there were other people saying they occasionally experienced the same issue. Not many tbf, but there were a few more. |
||
|
All FFXI content and images © 2002-2024 SQUARE ENIX CO., LTD. FINAL
FANTASY is a registered trademark of Square Enix Co., Ltd.
|
||
